ASoC component/card relationship

[Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>]

Hi,
In the existing ASoC code, there is a fixed mapping between ASoC card and component. A component relies on a ->card pointer that is set during the probe. A component cannot be used by or "bound to" more than one card [1]

This has interesting impacts on how a codec or DSP driver need to be implemented.

In the AVS series posted this week, multiple components are registered by the DSP driver, following an interface-based split. There's in addition a second-level split, where the logic is pushed further: the DSP driver partitions the SSP DAIs in different set of 'dai_driver's used by different components, which are in turn used by different cards. What is done in these patches is not wrong, and is probably the only solution to support a real-world platform with the existing ASoC code, but are the framework assumptions correct? In this example, the board-level information on which interface is used for what functionality trickles down to the lowest level of the DSP driver implementation.

I believe this breaks to some extent the 'clean' split between platform and machine driver(s), and it's not quite aligned with the usual notion of register/probe used across frameworks, be it for drivers/clocks/you name it.

A similar case could happen in a codec driver, if independent functionality such as headset and amplifier support was exposed by separate cards, that would in turn mandate that the codec driver exposed N components, each handling different functionality but the same type of DAI.

An alternative approach would be that the DSP driver exposes all the possible DAIs that can be used, and the binding is refined to allow for more flexibility. I think it's really the individual DAI that cannot be used by more than one card.

I figured I would ask on this mailing list if

a) I am not mistaken on the component/card relationship and

b) if this is by design, or if we want to clarify what a component is and what its restrictions might be.

Thanks for your feedback/comments
-Pierre

[1] https://elixir.bootlin.com/linux/latest/source/sound/soc/soc-core.c#L1364