Message-ID: <487c91f9-f6ea-75c2-9150-52db2de42a3a@linaro.org>
Date:   Thu, 21 Jan 2021 18:41:30 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        vkoul@...nel.org, yung-chuan.liao@...ux.intel.com
Cc:     gregkh@...uxfoundation.org, sanyog.r.kale@...el.com,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] soundwire: add support for static port mapping



On 21/01/2021 18:00, Pierre-Louis Bossart wrote:
> 
> 
> On 1/21/21 9:41 AM, Srinivas Kandagatla wrote:
>>
>>
>> On 21/01/2021 14:56, Pierre-Louis Bossart wrote:
>>>
>>>
>>>> Port allocations are something like this:
>>>>
>>>> RX: (Simple)
>>>> Port 1 -> HPH L/R
>>>> Port 2 -> CLASS H Amp
>>>> Port 3 -> COMP
>>>> Port 4 -> DSD.
>>>>
>>>> TX: (This get bit more complicated)
>>>> Port 1: PCM
>>>> Port 2: ADC 1 & 2
>>>> Port 3: ADC 3 & 4
>>>> Port 4: DMIC-0, DMIC-1, DIMC-2 , DMIC-3 and MBHC
>>>> Port 5: DMIC-4, DMIC-5, DMIC-6 and DMIC-7
>>>>
>>>> We handle the port allocation dynamically based on mixer and dapm 
>>>> widgets in my code! Also channel allocations are different for each 
>>>> function!
>>>
>>> Sorry, I am not following here. What is dynamic here and use-case 
>>> dependent? And is this a mapping on the master or the codec sides 
>>> that you want to modify?
>>
>> [SLAVE]-------[MASTER]
>> NA-------------Port 1: PCM
>> Port 1---------Port 2: ADC 1 & 2
>> Port 2---------Port 3: ADC 3 & 4
>> Port 3---------Port 4: DMIC-0, DMIC-1, DIMC-2 , DMIC-3 and MBHC
>> Port 4---------Port 5: DMIC-4, DMIC-5, DMIC-6 and DMIC-7
>>
>>
>> Mapping is still static however Number of ports selection and channel 
>> mask will be dynamic here.
>>
>>
>> Example: for Headset MIC usecase we will be using Slv Port1, Slv Port3 
>> along with Mstr Port2 and Master Port4
>>
>> Similarly for usecases like Digital MIC or other Analog MICs.
> 
> Sorry, I must be thick here, but in my experience the choice of Digital 
> or analog mics is a hardware design level not a use-case one. Using ADC 
> 1 & 2 at the same time as DMICs is very surprising to me. You'd have 
> different sensitivities/performance, not sure how you would combine the 
> results.

In this particular case, ADC2 on Port2 is used along with the MBHC(Multi 
Button and Headset Detection) channel on Master Port4. This is intended 
for Headset Button Click Suppression!. This again can be  dynamically 
selected based on if headset button Click Suppression is enabled or not.

So this is not really mixing ADC with DMICs here!


> 

> I also don't see how a headset mic can both use Analog and digital, 
> unless we have a different definition of what a 'headset' is.
> 
>>>>> Does this help and can you align on what Intel started with?
>>>>
>>>> Firstly, This is where the issue comes, if we go with the 
>>>> suggested(dai->id) solution, we would end up with a long list of 
>>>> dai-links with different combinations of both inputs/output 
>>>> connections and usecases. Again we have to deal with limited DSP 
>>>> resources too!
>>>>
>>>> Secondly, The check [1] in stream.c will not allow more than one 
>>>> master port config to be added to master runtime. Ex: RX Port 1, 2, 
>>>> 3 is used for Headset Playback.
>>>
>>> I am confused here, we do have examples in existing codec drivers 
>>> where we use multiple ports for a single stream, e.g. for IV feedback 
>>> we use 2 ports.
>>
>> Is this on multi_link? which is why it might be working for you.
> 
> no, this is done at the codec driver level, which has no notion of 
> multi-link. we pass a port_config as a array of 2.
> 

Am referring to sdw_stream_add_master() not sdw_stream_add_slave().

>> Currently we have below check in sdw_stream_add_master().
>>
>> if (!bus->multi_link && stream->m_rt_count > 0) {
>>      dev_err(bus->dev, "Multilink not supported, link %d\n", 
>> bus->link_id);
>>      ret = -EINVAL;
>>      goto unlock;
>> }
>>
>> If we have single master(like my case) and dai-links which have more 
>> then one port  will be calling  sdw_stream_add_master() for each port, 
>> so m_rt_count above check will fail for the second call!
> 
> if you use multiple ports in a given master for the same stream, you 
> should have the m_rt_count == 1. That's a feature, not a bug.
> 
> A port is not a stream... You cannot call sdw_stream_add_master() for 
> each port, that's not what the concept was. You allocate ONE master_rt

Am looking at intel_hw_params(). Isn't sdw_stream_add_master() called 
for every dai in the dai link.

> per master, and that master_rt deals with one or more ports - your choice. >
> A 'stream' is an abstract data transport which can be split across 
> multiple masters/sales and for each master/slave use multiple ports.
> When calling sdw_stream_add_master/slave, you need to provide a 
> port_config/num_ports to state which ports will be used on that 
> master/slave when using the stream. That's how we e.g. deal with 4ch 
> streams that are handled by two ports on each side.
> 
> To up-level a bit, the notion of 'stream' is actually very very similar 
> to the notion of dailink. And in fact, the 'stream' is actually created 
> for Intel in the dailink .startup callback, so I am quite in the dark on 
> what you are trying to accomplish.
In qcom case stream is also allocated for in dai startup().

I think we are talking about two different issues,

1>one is the failure I see in sdw_stream_add_master() when I try to use 
dai-link dai-id style approach suggested. I will dig this bit more and 
collect more details!

2>(Main issue) Ability for slave to select different combination of 
ports at runtime based on the mixer setting or active dapm.

All this patch is trying do is the pass this *CURRENT/ACTIVE* static 
port mapping between slave and master while setting up the stream.
With the dailink approach number of ports are pretty much static and may 
not be required for particular use case. As above example if we have a 
headset with button click suppression we would need 2 Ports and 
similarly without we only need one port.

This is not possible with dai-link approach, unless we create two 
different dai links for the above example usecase!

Hopefully this adds some light to the issue :-)

--srini

Powered by blists - more mailing lists