Re: ASoC component/card relationship

[Cezary Rojewski <cezary.rojewski@intel.com>]

On 2022-05-04 5:26 PM, Pierre-Louis Bossart wrote:

>>> b) the hardware/board level parts. That is a weak part of the topology
>>> today, it should come from a hardware description instead of being
>>> hard-coded in each topology. We must have dozens of identical topology
>>> files that differ only because of the SSP index or SoundWire link ID
>>> used on specific board. There should be a way to 'remap' BEs for
>>> specific boards.
>>>
>>> It doesn't mean we should toss the topology and redo everything, the
>>> latter part can be addressed by providing the 'real' hardware
>>> information to the topology and dynamically modify defaults.
>>>
>>
>> I already showed how we tried to solve this for i2s use cases in links
>> above.
> 
> You still have N identical topologies, completely identical with the
> exception of 1 SSP index to maintain.
> 
> Just to make this point stronger, with the recent support of the ES8336
> codecs, we had to generate the following topologies to account for all
> permutations:
> 
> sof-apl-es8336-ssp0.tplg
> sof-apl-es8336-ssp2.tplg
> sof-cml-es8336-dmic2ch-ssp0.tplg
> sof-cml-es8336-dmic2ch-ssp2.tplg
> sof-cml-es8336-dmic4ch-ssp0.tplg
> sof-cml-es8336-dmic4ch-ssp2.tplg
> sof-cml-es8336-ssp0.tplg
> sof-cml-es8336-ssp2.tplg
> sof-glk-es8336-ssp0.tplg
> sof-glk-es8336-ssp2.tplg
> sof-jsl-es8336-dmic2ch-ssp0.tplg
> sof-jsl-es8336-dmic2ch-ssp2.tplg
> sof-jsl-es8336-dmic4ch-ssp0.tplg
> sof-jsl-es8336-dmic4ch-ssp2.tplg
> sof-jsl-es8336-ssp0.tplg
> sof-jsl-es8336-ssp2.tplg
> sof-tgl-es8336-dmic2ch-ssp0.tplg
> sof-tgl-es8336-dmic2ch-ssp2.tplg
> sof-tgl-es8336-dmic4ch-ssp0.tplg
> sof-tgl-es8336-dmic4ch-ssp2.tplg
> sof-tgl-es8336-ssp0.tplg
> sof-tgl-es8336-ssp2.tplg
> 
> All these topologies come from the same file, and generated using
> macros. That makes no sense to me, this should be the same topology that
> is remapped at run-time.


What Amadeo is explaining here is that AVS driver already addresses this 
too - at least in our opinion - see parse_link_formatted_string() in 
sound/soc/intel/avs/topology.c.

User is allowed to specify widget name as: ssp%d within the topology 
file, leaving kernel with responsibility to fill the missing index. And 
this is something I (perhaps we all) would like to see within the 
framework in the future.

In consequence, avs-driver user does NOT need to define N identical 
topologies. For example, SSP-test board [1] and its definition in 
board_selection.c [2] clearly show that all 6 SSP boards look at the 
exact same file. The same approach is used when speaking of other, 
simple i2s codecs, e.g.: rt274, rt286, rt298. Difference between rt298 
on APL and GML comes down to SSP port number. Here, board_selection.c 
shows different prefixes (apl- vs gml-) but the reality is that both 
files are symlinks looking at the exact same actual topology file with 
ssp%d specified as widget names.

At the same time, compound machine boards are still permitted and made 
use of, example being TDF8532/Dirana board for Automotive (not yet 
present on the list).

Really, flexibility is key here. As long as devices found on given 
platform are not connected or dependent on each other, there are no 
major objections preventing card split. Such code scales better and has 
good reuseability.


Regards,
Czarek


[1]: 
https://lore.kernel.org/alsa-devel/20220427081902.3525183-6-cezary.rojewski@intel.com/
[2]: 
https://lore.kernel.org/alsa-devel/20220426172346.3508411-11-cezary.rojewski@intel.com/