You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[PM] Audio device failed to suspend with HDA support enabled on APL-nocodec #512
@markyang I believe that the issue can be fixed by adding HDMI support to nocodec machine driver and topology. The question is do we really need to enable HDMI support in the kconfig if we don't use it?
@bardliao This can be a solution. But probably we need a clean isolation of HDA-stuff in case we want to use the nocodec machine driver/topology to verify non-HDA audio on soe platforms that don't require HDA. In addition, HDMI audio depends on i915 display driver and usually i915 is not stable for early platforms. We don't want audio to be impacted.
On 1/8/19 8:29 PM, Mengdong Lin wrote:
@bardliao <https://github.com/bardliao> This can be a solution. But
probably we need a clean isolation of HDA-stuff in case we want to use
the nocodec machine driver/topology to verify non-HDA audio on soe
platforms that don't require HDA. In addition, HDMI audio depends on
i915 display driver and usually i915 is not stable for early
platforms. We don't want audio to be impacted.
@plbossart <https://github.com/plbossart> Would you please comment?
There's already a Kconfig to take HDaudio links out (which removes HDMI)
and another to take out HDaudio codecs. Not sure what else you need for
testing?
If the ask is to add HDMI to the nocodec stuff by default, then we'd
need a longer discussion. I'd prefer to handle HDMI as a separate card
that can be added without having to copy/paste all the time. Or at least
we need HDMI to be more like a turn-key component that can be added in a
simpler way than mucking with the machine driver.
@xiulipan@xun2z Could you help to check if current kconfig used by daily build server has disabled both HDaudio links and HDaudio codecs (both legacy HD-A codecs and asoc HDMI audio codec) ?
@mengdonglin Kconfig is OK. nocodec is isolated well from HDA.
This issue is caused by no pm_runtime_suspend support in nocodec, we have only machine driver. As pierre said, we don't want to add hard-coded HDA. I perfer to try a virtual codec driver supporting PM, or disable PM in nocodec.
@ranj063 well, sure, we can make sure to avoid this issue when using nocodec, but is that enough? I think there are multiple other situations when for one reason or for another a codec driver would not probe correctly, would this be a reason enough to keep the HDA device active? Since the HDA driver isn't SOF specific, I think we can do some preliminary discussing here and then take this to the ALSA ML?
@lyakh your initial explanations threw me off ("It's about whether HDMI codecs are included in the topology or not"). This is really not about the topology file but about the Kconfigs. If we have the HDaudio link enabled, then indeed we will initialize codecs but the card will never make any reference to those codecs so we can't suspend them, right?
if we are aligned on the analysis, I see three ways of fixing this.
we make NOCODEC incompatible with HDA_LINK - and move the NOCODEC to a different defconfig that's not selected. simple but we lose a bit in terms of flexibility.
we are smarter and modify hda_init_caps() so that when only a single codec is detected but we are in NOCODEC mode we don't initialize those codecs.
we add another option where we specify that we want NOCODEC to support suspend/resume, and this disables HDA_LINK. That might be the best case for testing.
To choose one of the above options I'd like to understand - is this really only a problem with nocodec? What if nocodec isn't used but the real codec, that is supposed to probe, hasn't succeeded for some reason, or haven't even attempted? Isn't it better to let the HDA driver autosuspend itself at the end of its probing and let any further users (codecs) "get()" it again?
Making CONFIG_SND_SOC_SOF_HDA_LINK incompatible with nocodec in kconfig is a solution for this issue. will close this issue when corresponding patch is merged
Activity
bardliao commentedon Jan 9, 2019
@markyang I believe that the issue can be fixed by adding HDMI support to nocodec machine driver and topology. The question is do we really need to enable HDMI support in the kconfig if we don't use it?
mengdonglin commentedon Jan 9, 2019
@bardliao This can be a solution. But probably we need a clean isolation of HDA-stuff in case we want to use the nocodec machine driver/topology to verify non-HDA audio on soe platforms that don't require HDA. In addition, HDMI audio depends on i915 display driver and usually i915 is not stable for early platforms. We don't want audio to be impacted.
@plbossart Would you please comment?
plbossart commentedon Jan 9, 2019
mengdonglin commentedon Jan 22, 2019
@xiulipan @xun2z Could you help to check if current kconfig used by daily build server has disabled both HDaudio links and HDaudio codecs (both legacy HD-A codecs and asoc HDMI audio codec) ?
xun2z commentedon Jan 28, 2019
@mengdonglin Kconfig is OK. nocodec is isolated well from HDA.
This issue is caused by no
pm_runtime_suspendsupport in nocodec, we have only machine driver. As pierre said, we don't want to add hard-coded HDA. I perfer to try a virtual codec driver supporting PM, or disable PM in nocodec.15 remaining items
lyakh commentedon Feb 7, 2019
@ranj063 well, sure, we can make sure to avoid this issue when using nocodec, but is that enough? I think there are multiple other situations when for one reason or for another a codec driver would not probe correctly, would this be a reason enough to keep the HDA device active? Since the HDA driver isn't SOF specific, I think we can do some preliminary discussing here and then take this to the ALSA ML?
plbossart commentedon Feb 7, 2019
I am having difficulties following this thread. We already have multiple Kconfig options to support HDaudio and nocodec:
SND_SOC_SOF_NOCODEC
SND_SOC_SOF_HDA_LINK
SND_SOC_SOF_HDA_AUDIO_CODEC
We don't look for the codecs in all cases, so what combination of these three exposes the problem on Up2?
lyakh commentedon Feb 7, 2019
@plbossart I think I attached my .config above ;-) But anyway - enable and force nocodec and keep all the HDA options too. That should do it.
plbossart commentedon Feb 7, 2019
@lyakh your initial explanations threw me off ("It's about whether HDMI codecs are included in the topology or not"). This is really not about the topology file but about the Kconfigs. If we have the HDaudio link enabled, then indeed we will initialize codecs but the card will never make any reference to those codecs so we can't suspend them, right?
if we are aligned on the analysis, I see three ways of fixing this.
ranj063 commentedon Feb 7, 2019
@plbossart I agree option 3 sounds like the best thing to do.
lyakh commentedon Feb 7, 2019
To choose one of the above options I'd like to understand - is this really only a problem with nocodec? What if nocodec isn't used but the real codec, that is supposed to probe, hasn't succeeded for some reason, or haven't even attempted? Isn't it better to let the HDA driver autosuspend itself at the end of its probing and let any further users (codecs) "get()" it again?
bardliao commentedon Feb 11, 2019
Agree with @lyakh This issue will happen if SND_SOC_HDAC_HDMI is selected but HDMI is not used. Similar issue is discussed in #140 (comment)
xun2z commentedon Mar 1, 2019
Making CONFIG_SND_SOC_SOF_HDA_LINK incompatible with nocodec in kconfig is a solution for this issue. will close this issue when corresponding patch is merged
net: sched: verify that q!=NULL before setting q->flags
media: vivid: fix compose size exceed boundary
media: vivid: fix compose size exceed boundary