On 2022-06-03 1:57 AM, Kuninori Morimoto wrote:
Thanks.
"my Sound" mean "my sound driver".
The Device image is like this
+-- DeviceA --+
|+-----------+|
||Component ||
|| [DAI]
|| [DAI]
...
|| [DAI]
|| [DAI]
|+-----------+|
+-------------+
It calls devm_snd_soc_register_component() here.
Number of DAIs = rsnd_rdai_nr(priv) is based on the SoC (= DT settings),
but these are same DAI.
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sh/rcar/core.c?h=v5.18#n1923>
The DAIs are setuped here.
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sh/rcar/core.c?h=v5.18#n1350>
Component driver is here
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sh/rcar/core.c?h=v5.18#n1810>
DAI ops is here
<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/sh/rcar/core.c?h=v5.18#n1067>
Hello Kuninori,
Thank you for the links - helped me speed up the learning process.
So, together with Amadeo we spent some time analyzing your audio stack.
The equivalent of avs's pci_driver (sound/soc/intel/avs/core.c) seems to
be rcar_sound platform_driver defined in sound/soc/sh/rcar/core.c.
There is no firmware or topology involved. Instead, we have hardware
components, each representing some processing function e.g.: sample rate
conversion. There is also a component which does not represent any of
such functions - represents ASoC side of things instead. It's called
*DAI*. And that's the component we were looking at mostly.
I believe each *DAI* exposes up to four FEs depending on the board, and
during PCM operations, every FE enlists one or more hw components
(rsnd_mod instances) to do the actual job.
Earlier in the thread you specified the following example as being
problematic:
+-- basic board --------+
|+--------+ |
|| CPU ch0| <--> CodecA |
|| ch1| <-+ |
|+--------+ | |
+-------------|---------+
+-- expansion board ----+
| | |
| +-> CodecB|
+-----------------------+
with suggestion to solve it with 1xComponent:NxCard relation which is
not supported by ASoC. However, we believe ASoC already presents
solutions to such problem, either through 1) compound card or less
commonly, by 2) splitting one big CPU-Card pair into several smaller pairs.
Relation that ASoC does support is NxComponent:1xCard. As both CPU and
Codec are components, this roughly translates to: NxCPU:1xCard:NxCodec.
Your case is an example of 1xCPU:1xCard:2xCodec. Such
1xCPU:1xCard:NxCodec combinations are arguably the most common ones and
developers majority of time are picking option 1). Less hassle. See
sound/soc/intel/boards for examples.
As I believe the expansion board has some identifier, we will be able to
fetch whether we are dealing with basic board or basic+expansion board.
Or at least the board name should differ between the two devices. If so,
two machine board drivers are needed - one servicing just the basic
board (basic sound card) and the other for combo board (combo sound card).
Another option is registration of many components allowing developer to
represent each logical block with a single component. This comes down to
invoking snd_soc_register_component() multiple times.
This is especially useful if one or more of your four FEs available on
the R-Car board has nothing to do with CodecA. Let's say FEs 1,2,3 are
actually routed through CodecA whereas FE 4 through CodecB. It is
logical to split the CPU functionality so that FE 4 is being serviced by
the CPU component that is responsible for just that one part. This can
be modified further if we want to expose entire set of FEs for both
CodecA and CodecB. In such case the essence of PCM operations should be
moved to some common code so that functions exposed via dai->ops become
wrappers - eliminates code duplication. Then just create two instances
of your CPU component, assign dai_driver(s) and register them both.
Currently, you're calling snd_soc_register_component() just once in your
driver so option 2) is not possible without altering
rsnd_dai_probe()/rsnd_probe().
Perhaps there is something I'm missing but considering that ASoC does
have solutions to the raised problem, I do not see why either 1) or 2)
cannot be made use of to deal with the problem. I and Amadeo can
definitely help with 2) should you select it :)
Regards,
Czarek
