[alsa-devel] regression: bad sound card type detection in audio graph

[Arnaud Pouliquen]

Hi kuninori,


On 3/28/19 1:55 AM, Kuninori Morimoto wrote:
> 
> Hi  Arnaud
> 
> Thank you for checking/testing driver
> 
>> In our sound card (described here:
>> https://github.com/STMicroelectronics/linux/blob/v4.19-stm32mp/arch/arm/boot/dts/stm32mp157c-ev1.dts)
>> 
>> We declare a normal sound card using the WM8994 codec:
>> 
>>   Playback: CPU-DAI (SAI2a)-> CODEC-DAI/port0
>>   Record: CPU-DAI (SAI2B)<- CODEC-DAI/port1
>>   ...
>> 
>> The WM8994 codec is declared with 2 ports as it supports 2 interfaces.
>> 
>> When we probe the sound card we are detecting a wrong dai link type
>> because the condition
>> if (of_get_child_count(codec_port) > 1) return true. The dai link is
>> detected as DPCM instead of the expected normal link.
> 
> It seems difficult to use WM8994 on my test environment.
> And I tried to add 2 ports on my sound codec driver/DT,
> but I can't reproduce your issue.
> But, I want to solve your issue.
> 
> In my understanding, in your case, cpu/codec will be below.
> 
>         for Playback
>         cpu_ep          = sai2a_endpoint
>         codec_ep        = wm8994_tx_endpoint
>         codec_port      = wm8994_tx_port
> 
>         for Record
>         cpu_ep          = sai2b_endpoint
>         codec_ep        = wm8994_rx_endpoint
>         codec_port      = wm8994_rx_port
> 
>> Please could you elaborate a little bit on this criteria for the
>> normal/DPCM selection?
>> 
>> What is you feeling about this limitation. Do you see a way to refine
>> the condition to allow normal sound card with multi-port codecs. Or do
>> we have to migrate our sound card to DPCM.
> 
> If it was DPCM, 1 port is connected from multiple "endpoint".
> So, audio-graph-card is checking if it was "multi-endpoint" or not.
> "multi-port" is not related to this judgment.
> 
> And in your case, if my understanding was correct,
> wm8994_tx/rx only have single-endpoint.
> so, if (of_get_child_count(codec_port) > 1) return true is a
> little bit strange for me.
> Can you check what is this codec_port ? I think you can use
> printk("%pOF\n", codec_port) for it.
> 
Thanks for your answer and my apologize. I found the issue: it was
located between my keyboard and my seat...

I merged a bad branch, which contains following declaration for the the
wolfson node:

ports {
	#address-cells = <1>;
        #size-cells = <0>;
	wm8994_tx_endpoint: endpoint at 0 {
		reg = <0>;
                remote-endpoint = <&sai2a_endpoint>;
       };
       wm8994_rx_endpoint: endpoint at 1 {
		reg = <1>;
                remote-endpoint = <&sai2b_endpoint>;
       };
};

This was probing before the audio graph update, not now, but this is not
a valid way to declare it.

With the configuration described in the github, it is perfectly working.

This trig me an extra question: how to manage a configuration using only
one codec DAI (bidir) connected to 2 unidirectional CPU-DAI?
  Playback: CPU-DAI (slave)-> (master)CODEC-DAI/port0
  Record: CPU-DAI (slave)<- (master)CODEC-DAI/port0

In this case it seems logic to declare for the codec, one port with 2
endpoints so this imply to use DPCM mechanism... right?
In this case we should use a static routing to conncet FE and BE...?
Do you know if this kind of configuration has been tested?

FYi, This configuration is available on the stm32mp157c-dk2 board. Today
we have not an upstreamable solution (we have hacked the codec to
duplicate the DAI to create 2 ports with one endpoint, instead of one
port with 2 endpoints).

Thanks,

Arnaud