Date:   Wed, 6 May 2020 19:42:25 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     Jerome Brunet <jbrunet@...libre.com>, <broonie@...nel.org>,
        <perex@...ex.cz>, <tiwai@...e.com>,
        <kuninori.morimoto.gx@...esas.com>
CC:     <spujar@...dia.com>, <nicoleotsuka@...il.com>,
        <alsa-devel@...a-project.org>, <swarren@...dia.com>,
        <linux-kernel@...r.kernel.org>, <nwartikar@...dia.com>,
        <lgirdwood@...il.com>, <jonathanh@...dia.com>,
        <viswanathl@...dia.com>, <sharadg@...dia.com>,
        <thierry.reding@...il.com>, <atalambedu@...dia.com>,
        <linux-tegra@...r.kernel.org>, <digetx@...il.com>,
        <rlokhande@...dia.com>, <mkumard@...dia.com>, <dramesh@...dia.com>
Subject: Re: [RFC] DPCM for Tegra



On 5/6/2020 5:21 PM, Jerome Brunet wrote:
> External email: Use caution opening links or attachments
>
>
> On Thu 30 Apr 2020 at 14:41, Sameer Pujar <spujar@...dia.com> wrote:
>
>> At a high level Tegra Audio HW is depicted as below.
>>
>> |     Front End PCMs     |  SoC DSP   |     Back End DAIs    |
>>
>>                           *************
>> ADMAIF<0> <------------> *           * <----DAI<0>-----> I2S
>>                           *           *
>> ADMAIF<1> <------------> *           * <----DAI<1>-----> DMIC
>>                           *    XBAR   *
>> ADMAIF<2> <------------> *           * <----DAI<2>-----> DSPK
>>                           *           *
>> ADMAIF<N> <------------> *           * <----DAI<3>-----> SFC (Resampler)
>>                           *           *
>>                           *           * <----DAI<4>-----> MIXER
>>                           *           *
>>                           *           * <----DAI<N>-----> ...
>>                           *************
>>
>>
>> Follow up queries
>> =================
>> Based on the above experience I do have few follow up queries and request
>> for your inputs on this.
>>
>>   a) Can I use a DAPM Mux control to activate a BE path? This in turn can
>>      program required switch in XBAR.
> My 2 cents:

> DPCM should activate any BE which has:
> * a valid DAPM path from the current FE
> * a valid BE stream (ex: can handle the stream direction)

Yes, this is taken care.
>
> AFAIK, you can use any combination of DAPM elements to model your
> components, including the XBAR. Then, it is the job of the card driver to
> link the DAPM widgets of the different components together and bring the
> system to life.

XBAR currently exports all routing widgets which can be used to 
interconnect multiple components and thus implements Mux widgets. Fixing 
the routing paths in driver would limit anyone to try a different 
combination as per the need, unless driver is modified. Device tree (DT) 
can be one of the solutions here, but currently static paths can only be 
added AFAIK. Even if this is extended to include routes with Mux 
widgets, still it won't give the real flexibility. I cannot re-use a 
component for a different routing path, unless DT is modified again.

Hence a Mux widget with user space control could offer required 
flexibility.
>
> If your XBAR is widgets are not provided by a component which also
> provides a dai_link in the sound card, you'll need to add the component
> to the auxiliary device list of the card for the widget to be available
> in the card.

I registered XBAR device as a component having a dummy DAI just to allow 
routing paths to be available for the given sound card. Are you 
suggesting I can register XBAR as an auxiliary device so that all the 
routing paths are available?
>
>>      This is needed for following reasons:
>>
>>      - For an open platform like Jetson, we want to give maximum flexibility
>>        for a user to customize their audio paths. Number of connected
>>        components and order of these can vary depending on a use case.
>>
>>      - Allow re-use of audio components across multiple use cases.
>>        For example, number of SFC instances are lesser than PCM playback or
>>        capture devices.
>>
>>   b) I have modelled SFC and MIXER as backends. Is this allowed?
>>
>>      This was done to include SFC or MIXER HW components as part of the
>>      sound card and use like below in one of the audio use cases.
>>
>>      ADMAIF1(FE) --> SFC(BE1) --> I2S(BE2) ... OR
>>      ADMAIF2(FE) --> SFC(BE1) --> I2S(BE2) ...

> What your are trying to achieve here is DAI chaining. From the DAPM
> perspective, it is alright. Unfortunately this kind of chaining are
> not supported (not yet, at least) from the dai_link perspective, even
> with DPCM.

In the current design we achieve this by using codec-to-codec links and 
attempt here is if we can use DPCM to simplify few things.
>
>
>  From the DPCM perspective, I think your patch does the following:
>
> ADMAIF1(FE) ---> SFC(BE1)
>              |--> I2S(BE2)
> ADMAIF2(FE) ---> SFC(BE1)
>              |--> I2S(BE2)
>
> Your DAIs are not chained, but put in parallel. Maybe all your DAI
> callbacks are called in a way that is convinient enough for your
> use cases, but it is not what you intended.

Yes this seems to be the case. All of my BE DAIs are added to the list 
and callbacks happen for all. DPCM is viewing these as parallel paths.
>
> For the example, the rate passed to 'I2S(BE2)' in hw_params() will
> be the one provided by the 'ADMAIF', not the output rate of the 'SFC'.

I was earlier thinking if dpcm_be_dai_hw_params() can be enhanced to 
propagate PCM parameters (sample rate, channels, sample size) from BE to 
BE. This is a rough idea, I have not tried this. But because of above it 
will be a problem unless real parallel paths are not differentiated.
For example:
ADMAIF1(FE) ---> SFC1 ---> I2S1 (operated at 48 kHz)
             |--> SFC2 ---> I2S2 (operated at 16 kHz)

If I understand correctly, this problem will be there if I want to drive 
multiple paths with the "same FE". I am not sure how often we have such 
requirements.
For example below would work fine (though it is functionally not same as 
above example):
ADMAIF1(FE) ---> SFC1 ---> I2S1 (operated at 48 kHz)
ADMAIF2(FE) ---> SFC2 ---> I2S2 (operated at 16 kHz)
>
>>      I used following workaround to connect multiple BE components.
>>      With this I can see PCM callbacks happen for all BE DAIs along the DAPM
>>      path. The obective was to connect multiple components together and (a)
>>      was used to connect one component to another. Each "-->" here connects
>>      two components and it is a switch in XBAR.
>>
>>      ---
>>        sound/soc/soc-pcm.c | 2 +-
>>        1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>        diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
>>        index e256d43..ee7af55 100644
>>        --- a/sound/soc/soc-pcm.c
>>        +++ b/sound/soc/soc-pcm.c
>>        @@ -1494,7 +1494,7 @@ int dpcm_path_get(struct snd_soc_pcm_runtime *fe,
>>
>>          /* get number of valid DAI paths and their widgets */
>>          paths = snd_soc_dapm_dai_get_connected_widgets(cpu_dai, stream, list,
>>        -                       dpcm_end_walk_at_be);
>>        +                       NULL);
>>
>>        dev_dbg(fe->dev, "ASoC: found %d audio %s paths\n", paths,
>>                        stream ? "capture" : "playback");
>>      --
. . .
>> References
>> ==========
>> [0] http://patchwork.ozlabs.org/project/linux-tegra/list/?series=159664&archive=both&state=*
>> [1] http://patchwork.ozlabs.org/project/linux-tegra/patch/1582180492-25297-6-git-send-email-spujar@nvidia.com/
>> [2] http://patchwork.ozlabs.org/project/linux-tegra/patch/1582180492-25297-4-git-send-email-spujar@nvidia.com/
>> [3] https://www.kernel.org/doc/html/v5.6/sound/soc/dpcm.html

Powered by blists - more mailing lists