On Thu, Apr 15, 2021 at 03:24:01PM +0900, Kuninori Morimoto wrote: > > It checks symmetry first, and checks each DAI settings if symmetry > > was true. > > But original code checked > > symmetric_rate : DAI_Link / CPU (A) > > symmetric_channels : DAI_Link / CPU / Codec (B) > > symmetric_sample_bits : DAI_Link / CPU / Codec (B) > > (A) was using for_each_rtd_cpu_dais() > > (B) was using for_each_rtd_dais() > > Current code is using (B) for all symmetric_xxx. This is bug. > Oops ? > More older verion was > 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. > 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 > If so, correct solution should be (A2) > (A1) Symmetric checks CPU only > (A2) Symmetric checks both CPU / Codec, but ignores dummy-DAI 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. Is it a case of needing a fixup function, or special handling if a fixup function is there?
Attachment:
signature.asc
Description: PGP signature
