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@xxxxxxxxxx> 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@xxxxxxxxxx/
[2] http://patchwork.ozlabs.org/project/linux-tegra/patch/1582180492-25297-4-git-send-email-spujar@xxxxxxxxxx/
[3] https://www.kernel.org/doc/html/v5.6/sound/soc/dpcm.html
