[RFC] ASoC: max98373: power up amp before pipeline start #2991
Conversation
RanderWang
changed the title
RanderWang
force-pushed
the
max98373-pre-power
branch
2 times, most recently
from
74cf87c
to
e308e37
Compare
Since amp will be powered up 31ms after pipeline start, overrun will happen in audio dsp fw and result to fw error. This patch powers up amp before pipeline start. Signed-off-by: Rander Wang <rander.wang@intel.com>
| @@ -24,7 +24,7 @@ static int max98373_dac_event(struct snd_soc_dapm_widget *w, | |||
| struct max98373_priv *max98373 = snd_soc_component_get_drvdata(component); | |||
|
|
|||
| switch (event) { | |||
| case SND_SOC_DAPM_POST_PMU: | |||
| case SND_SOC_DAPM_PRE_PMU: | |||
There was a problem hiding this comment.
PRE_PMU and POST_PMD looks symmetric to me, @ryans-lee any comment?
There was a problem hiding this comment.
@keyonjie PRE_PMU means the event will be trigger before the power bit (MAX98373_R202B_PCM_RX_EN) is set and POST_PMU means the event will be trigger after the power bit. PMU and PMD don't have to be symmetric.
There was a problem hiding this comment.
@bardliao do you know if we should set R20FF first or enable R202B first? looks we should enable the global (20FF) first and then enable the PCM_RX_EN? I don't know the codec well, but in case you power on A first and then B, for powering off, we should do with power off B first and then A? That is why symmetric I proposed.
There was a problem hiding this comment.
@bardliao do you know if we should set R20FF first or enable R202B first? looks we should enable the global (20FF) first and then enable the PCM_RX_EN? I don't know the codec well, but in case you power on A first and then B, for powering off, we should do with power off B first and then A? That is why symmetric I proposed.
No, I don't know that. Maybe @ryans-lee can help.
There was a problem hiding this comment.
@RanderWang You have to modify the flag in line 66. ie. It should be
SND_SOC_DAPM_DAC_E("Amp Enable", "HiFi Playback",
MAX98373_R202B_PCM_RX_EN, 0, 0, max98373_dac_event,
SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD),
|
@RanderWang Sorry, I don't get how can codec power up sequence lead to overrun. Data will be transmitted no matter codec power is up or off, right? |
|
@RanderWang I don't see the link between powering up and overflows. The Intel DSP would start sending and capturing data regardless of the state of the device. If the Amp is not powered, it'll discard data for playback and not generate anything on the capture side. Please clarify how a power states has side effects on data streaming, thank you. |
|
@RanderWang We routinely use the SSP in NOCODEC mode, so I really really don't see what your proposal might change. The SSP is the clock master, what happens outside of the DSP is irrelevant for underflows. |
@plbossart the issue Rander is addressing here if for SDW codec mode, not SSP. |
it does not matter @keyonjie, we can have SoundWire in almost-nocodec mode as well with the 'mockup' device support. There is really no reason why power-up a device would cause underflows at the Intel DSP level. |
|
@plbossart @bardliao @keyonjie The issue is caused by delay, not power up of codec. please check #2997. close it since we have a new PR. |
Since amp will be powered up 31ms after pipeline start,
overrun will happen in audio dsp fw and result to fw
error. This patch powers up amp before pipeline start.
The error is caused by : 3a27875
fixes thesofproject/sof#4066