Re: [PATCH 1/2] ASoC: soc-pcm.c: fixup validation check of multi CPU/Codec on soc_get_playback_capture()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed 04 Oct 2023 at 09:06, Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> wrote:

> Hi Morimoto-san,
>
>> Current soc_get_playback_capture() are checking validation of CPU/Codec
>> like below
>> 
>> 	static int soc_get_playback_capture(...)
>> 	{
>> 		...
>>  ^		if (dai_link->dynamic || dai_link->no_pcm) {
>> (X)				...
>>  v		} else {
>>  ^			...
>>  |			for_each_rtd_codec_dais(rtd, i, codec_dai) {
>>  |				...
>>  |				if (snd_soc_dai_stream_valid(codec_dai, ...) &&
>>  |				    snd_soc_dai_stream_valid(cpu_dai,   ...))
>> (Y)(a)					has_playback = 1;
>>  |				if (snd_soc_dai_stream_valid(codec_dai, ...) &&
>>  |				    snd_soc_dai_stream_valid(cpu_dai,   ..))
>>  | (b)					has_capture = 1;
>>  |			}
>>  v		}
>> 		...
>> 	}
>> 
>> (X) is for DPCM connection, (Y) is for Normal connection.
>> In Normal connection (Y), it is handling CPU/Codec, and it will set
>> has_playback/capture = 1 at (a)(b), but it means today is "at least one
>> of CPU/Codec pair was valid" in multi CPU/Codec case.
>> 
>> This is wrong, it should be handled when "all CPU/Codec are valid".
>> This patch fixup it.
>
> I knew this code looked familiar and sure enough we've been there before
> in 2020. This code was introduced by
>
> 4f8721542f7b ASoC: core: use less strict tests for dailink capabilities
>
> the initial stricter tests caused a number of regressions reported by
> Jerome Brunet so we lowered the bar from "all dais" to "at least one
> dai" to be backwards-compatible.
>
> I don't think we can revisit this without hitting the same sort of issues.

Good memory :)

Hi Morimoto-san,

Here is an example:
1 CPU - 1 dai link - 2 codecs:
* 1 codec handles the playback and just that
* the other does same capture

I have fair number of boards doing just that.

This is valid from the HW i2s/TDM point of view.

Going with 'all must be valid for the direction' makes this use case
impossible. Each codec would disable the direction of the other one.

As long as there is component, at least one, capable of handling the
stream direction then it is fine to do it.

Do you have an actual problem because/error because of this ?

>
> Regards,
> -Pierre




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux