On 11/18/2022 6:17 PM, Patrick Lai wrote:

Hi Amadeusz,

On the product I am working on, a hostless PCM device is defined for purpose of activating CODEC driver to setup the path inside CODEC. So, CPU DAI and PCM Platform are defined to use dummy dai & DMA supplied by sound/soc/soc-utils.c.

After upgrading to newer kernel, hostless PCM device failed to open. After doing a bit of digging, the root cause is that dummy_dma_hardware is not set in dummy_dma_open() due to new conditional check logic introduced in this commit - 6c504663ba2ee2abeaf5622e27082819326c1bd4.

In order to fix problem I am encountering properly without regressing your scenario, I would like to get a better understanding of problem you were addressing. My understanding, from looking through other drivers under sound/soc, is that pcm hardware info is usually set by PCM platform/DMA drivers. For your scenario, do you have other component e.g CPU/CODEC DAI, set PCM hardware definition? I am not sure conditional check logic from 6c504663ba2ee2abeaf5622e27082819326c1bd4 guarantees that other component would be setting pcm hardware info. Appreciate if you can provide more insight to your scenario?

Thanks Patrick

Hi Patrick,

Call path is: ... -> __soc_pcm_open() -> soc_pcm_components_open -> snd_soc_component_open -> open callback, where for dummy device open callback is dummy_dma_open.

Expanding on the issue in question which was cause of the patch.

With following debug log: diff --git a/sound/soc/soc-component.c b/sound/soc/soc-component.c index e12f8244242b..b086ec05da25 100644 --- a/sound/soc/soc-component.c +++ b/sound/soc/soc-component.c @@ -290,6 +290,8 @@ int snd_soc_component_open(struct snd_soc_component *component, { int ret = 0;

+ pr_err("%s\n", component->name); + if (component->driver->open) ret = component->driver->open(component, substream);

that's what I get in dmesg on one of our test platforms: [ 95.522577] avs_rt274.1-platform [ 95.526019] i2c-INT34C2:00 [ 95.528837] snd_soc_core:dpcm_fe_dai_startup: audio: ASoC: open FE audio [ 95.528849] avs_rt274.1-platform [ 95.532249] snd-soc-dummy [ 95.534989] snd-soc-dummy [ 95.537800] snd_soc_avs:avs_dai_fe_startup: snd_soc_avs 0000:00:1f.3: avs_dai_fe_startup fe STARTUP tag 1 str 0000000064defd29

"avs_rt274.1-platform" component is handled in sound/soc/intel/avs/pcm.c it calls avs_component_open() which sets hwparams to generic set supported by i2s devices in AVS driver.

"i2c-INT34C2:00" is codec driver sound/soc/codecs/rt274.c it does not have open callback.

And finally "snd-soc-dummy" which as mentioned above calls dummy_dma_open which originally overridden hwparams set in avs_component_open() with its own limited ones.

(When topology is loaded it also creates FEs, which further limit allowed hwparams, they are a subset of the ones set above).

As mentioned in the patch: "Alternative approach would be to copy whole dummy handling and rename it to "snd-soc-null" or something similar. And remove hwparams assignment to make it really do nothing."

However, looking at it again, I would consider the existence of dummy_dma_open() to be scope creep. If component is really a dummy one it should not affect any other components in any way. And if any drivers depends on dummy setting parameters for it, I would consider it partially broken. And would say that issue should rather be fixed on driver side by making a dedicated component for it instead of using a dummy one.

I hope that I cleared up situation a bit.

Thanks, Amadeusz