Message ID | 87a6q0z4xt.wl-kuninori.morimoto.gx@renesas.com |
---|---|
State | New |
Headers | show |
Series | ASoC: soc-pcm: fixup soc_pcm_params_symmetry() | expand |
Hi Mark Thank you for your feedback > > symmetric_rate : DAI_Link / CPU / Codec (B) > > symmetric_channels : DAI_Link / CPU / Codec (B) > > symmetric_sample_bits : DAI_Link / CPU / Codec (B) > > Right, this is what I'd expect. Yes, I agree > > Does this issue had been happen since older versoin ?? > > > > # aplay 44100.wav > > # aplay 44100.wav > > => [kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: 44100 - 48000 > > [kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22 I confirmed. Unfortunately there was copy miss (= bug) on soc_pcm_params_symmetry() (= A) which didn't check Codec. But is back by (B). A: v5.7: commit c840f7698d26 ("ASoC: soc-pcm: Merge for_each_rtd_cpu/codec_dais()") B: v5.12: commit 3a9067211122 ("ASoC: soc-pcm: cleanup soc_pcm_params_symmetry()") In total, old - v5.6 (= Generation-1): symmetric_rate : DAI_Link / CPU / Codec symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec v5.7 - v5.11 (= Generation-2): (= because of bug by (A)) symmetric_rate : DAI_Link / CPU symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec v5.12 - (= Generation-3): (= back by (B)) symmetric_rate : DAI_Link / CPU / Codec symmetric_channels : DAI_Link / CPU / Codec symmetric_sample_bits : DAI_Link / CPU / Codec Because of these, Generation-1 / Generation-3 have DPCM issue if it was.. 1) using .be_hw_params_fixup 2) exchanged BE's rate The issue is below. I didn't confirm but maybe same things happen if .be_hw_params_fixup exchanged channels/sample_bits, I guess. # aplay 44100.wav # aplay 44100.wav => [kernel] be.ak4613-hifi: ASoC: unmatched rate symmetry: 44100 - 48000 [kernel] be.ak4613-hifi: ASoC: hw_params BE failed -22 ... > I think this is something that gets confused by DPCM breaking > assumptions :/ . Not sure if *ignoring* the dummy DAI is the best > option though, the general way the dummy works is that it has extremely > loose constraints so it ends up not restricting anything else it gets > paired with but then the dummy DAI might end up in multiple links. Ignoring dummy-DAI is not so bad idea, and it is possible to lose any constraints, I think. soc_probe_component() is also ignoring it. static int soc_probe_component(...) { ... => if (!strcmp(component->name, "snd-soc-dummy")) return 0; ... } > Is it a case of needing a fixup function, or special handling if a fixup > function is there? Above issue will gone if soc_pcm_params_symmetry() didn't check dummy-DAI's rate/channels/sample_bits. I will post the patches. Thank you for your help !! Best regards --- Kuninori Morimoto
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 02968a4e52b4..92e95e4aef9f 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -388,7 +388,7 @@ static int soc_pcm_params_symmetry(struct snd_pcm_substream *substream, #define __soc_pcm_params_symmetry(name) \ symmetry = rtd->dai_link->symmetric_##name; \ - for_each_rtd_dais(rtd, i, dai) \ + for_each_rtd_cpu_dais(rtd, i, dai) \ symmetry |= dai->driver->symmetric_##name; \ \ if (symmetry) \