[PATCH] ASoC: soc-pcm: fixup soc_pcm_params_symmetry()

[Mark Brown]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20210415/dcd09eb6/attachment-0001.sig>