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
[BUG]: Sound card failed in initailization if SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC is not enabled #1968
Describe the bug
If some machine driver, such as sof-soundwire, if SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC, sound card will fail to be created.
This is because HDMI audio need SND_SOC_SOF_HDA_AUDIO_CODEC to be enabled as it will use hda codec core to probe.
To Reproduce
Disable SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC manually in make menuconfig and compile the kernel to test on the platforms, such as Olympic using sof-soundwire.
Reproduction Rate
10/10
Expected behavior
card can be created successfully
I will make a patch to select the SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC if HDMI is used and do some corresponding code change in the driver.
@libinyang@ranj063 ack, this is a bug in Kconfig dependencies. Like most others, there needs to be a dependency to HDA_AUDIO_CODEC. E.g. for UP2 we have this:
» depends on (SND_SOC_SOF_HDA_AUDIO_CODEC && (MFD_INTEL_LPSS || COMPILE_TEST)) ||\
» » (SND_SOC_SOF_BAYTRAIL && (X86_INTEL_LPSS || COMPILE_TEST))
» depends on SND_HDA_CODEC_HDMI
@libinyang@ranj063 ack, this is a bug in Kconfig dependencies. Like most others, there needs to be a dependency to HDA_AUDIO_CODEC. E.g. for UP2 we have this:
» depends on (SND_SOC_SOF_HDA_AUDIO_CODEC && (MFD_INTEL_LPSS || COMPILE_TEST)) ||\
» » (SND_SOC_SOF_BAYTRAIL && (X86_INTEL_LPSS || COMPILE_TEST))
» depends on SND_HDA_CODEC_HDMI
@kv2019i Yes, both 'depends' and 'select' can fix it. I will make a patch for it
I'd like to understand the issue better when SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC are not enabled
a) does the build fail?
b) does the probe fail?
We don't have a topology without hdmi, so it'd be a feature that the machine driver is not selected.
@plbossart The build is successful. It failed in the driver probe. We still use the topology with hdmi as we enabled SND_HDA_CODEC_HDMI in kernel config. And HDMI in sof needs SND_SOC_SOF_HDA_AUDIO_CODEC. With SND_SOC_SOF_HDA_AUDIO_CODEC, the codec will probe fail.
--- correct: "With SND_SOC_SOF_HDA_AUDIO_CODEC, the codec will probe fail. " => "Without SND_SOC_SOF_HDA_AUDIO_CODEC, the codec will probe fail. "
@plbossart The build is successful. It failed in the driver probe. We still use the topology with hdmi as we enabled SND_HDA_CODEC_HDMI in kernel config. And HDMI in sof needs SND_SOC_SOF_HDA_AUDIO_CODEC. With SND_SOC_SOF_HDA_AUDIO_CODEC, the codec will probe fail.
@libinyang@plbossart this is the same issue that we brought up with the chrome config a while ago. If there is a conflict between topology and kernel config, which side is responsible to fix it?
@libinyang@plbossart this is the same issue that we brought up with the chrome config a while ago. If there is a conflict between topology and kernel config, which side is responsible to fix it?
@ranj063 Are you talking about the mismatch between topology and kernel config, especially the mismatch of supporting hdmi or not? If so, our current solution is we always enable hdmi in driver and topology. And if config doesn't enable HDMI, driver will use dummy codec. However, I found there might be a dai config conflicts between driver and topology, which will cause hw_params() error. For such conflict, I have an idea: we can dynamically pick up the topology based on the kernel config. For example, if hdmi is enabled in kernel config and i915 is loaded successfully, machine driver will use xxx-hdmi.tplg; and if hdmi is not enabled, machine driver will use xxx-nohdmi.tplg. With this, the tplg and kernel config can always be well matched.
Besides the mismatch issue, I found even topology and kernel config match, let's say, both support hdmi. If we don't enable SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC, the card probe will fail.
Activity
libinyang commentedon Apr 1, 2020
I will make a patch to select the SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC if HDMI is used and do some corresponding code change in the driver.
What do you think of the solution?
libinyang commentedon Apr 1, 2020
The dmesg
dmesg.txt
ranj063 commentedon Apr 1, 2020
@libinyang we've discussed this in the past and as far as I can remember it is a feature and not a bug.
@kv2019i any thoughts?
libinyang commentedon Apr 1, 2020
@ranj063 Thanks for the update. Do we have some conclusion how to implement it or fix it?
kv2019i commentedon Apr 1, 2020
@libinyang @ranj063 ack, this is a bug in Kconfig dependencies. Like most others, there needs to be a dependency to HDA_AUDIO_CODEC. E.g. for UP2 we have this:
plbossart commentedon Apr 1, 2020
I'd like to understand the issue better when SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC are not enabled
a) does the build fail?
b) does the probe fail?
We don't have a topology without hdmi, so it'd be a feature that the machine driver is not selected.
libinyang commentedon Apr 2, 2020
@kv2019i Yes, both 'depends' and 'select' can fix it. I will make a patch for it
libinyang commentedon Apr 2, 2020
@plbossart The build is successful. It failed in the driver probe. We still use the topology with hdmi as we enabled SND_HDA_CODEC_HDMI in kernel config. And HDMI in sof needs SND_SOC_SOF_HDA_AUDIO_CODEC. With SND_SOC_SOF_HDA_AUDIO_CODEC, the codec will probe fail.
--- correct: "With SND_SOC_SOF_HDA_AUDIO_CODEC, the codec will probe fail. " => "Without SND_SOC_SOF_HDA_AUDIO_CODEC, the codec will probe fail. "
ranj063 commentedon Apr 2, 2020
@libinyang @plbossart this is the same issue that we brought up with the chrome config a while ago. If there is a conflict between topology and kernel config, which side is responsible to fix it?
libinyang commentedon Apr 2, 2020
@ranj063 Are you talking about the mismatch between topology and kernel config, especially the mismatch of supporting hdmi or not? If so, our current solution is we always enable hdmi in driver and topology. And if config doesn't enable HDMI, driver will use dummy codec. However, I found there might be a dai config conflicts between driver and topology, which will cause hw_params() error. For such conflict, I have an idea: we can dynamically pick up the topology based on the kernel config. For example, if hdmi is enabled in kernel config and i915 is loaded successfully, machine driver will use xxx-hdmi.tplg; and if hdmi is not enabled, machine driver will use xxx-nohdmi.tplg. With this, the tplg and kernel config can always be well matched.
Besides the mismatch issue, I found even topology and kernel config match, let's say, both support hdmi. If we don't enable SND_SOC_SOF_HDA_LINK & SND_SOC_SOF_HDA_AUDIO_CODEC, the card probe will fail.
net: pktgen: fix code style (WARNING: Missing a blank line after decl…