About Cleanup ASoC

[Pierre-Louis Bossart]

On 5/24/22 10:06, Cezary Rojewski wrote:
> On 2022-05-24 3:24 PM, Mark Brown wrote:
>> On Tue, May 24, 2022 at 04:40:24AM +0000, Kuninori Morimoto wrote:
>>
>>> I have very interesting to clean up ASoC.
>>> I think it is still very complex, thus, non flexible.
>>> I'm thinking that we want to cleanup...
>>>
>>>     - Component with multi Card connection
>>
>> I'm really not certain that we want components in multiple cards at all,
>> I know the Intel AVS people wanted this but I'm concerned that if a
>> single component is in multiple cards we'll inevitably have connections
>> between the cards which each needs to take into consideration, that
>> could be routing or something else like clock configuration.
> 
> Hello,
> 
> It seems explanation of design of the avs-driver had some shortcomings.
> The AVS people (like me) are to blame for this :S
> 
> The exact opposite is true - we do not want 1:N component:card relation.
> Separate set of components and a separate card (machine board) per
> logically separate audio device is the approach of choice here. It has
> its benefits of simplifying PM and allowing for better user experience -
> probe() failure of one device does not prevent other devices from
> enumerating.

The separate card solution works for ACPI devices only because we don't
have any structured information. I don't know how it would work for
Device Tree. There's no mechanism I am aware of by which the platform
driver would be informed of board requirements and would split its DAIs
in different components required by that board. It might be
worked-around by having one component per DAI though, but that
waters-down the notion of component driver quite a bit.

If you have any data connection or loopbacks between cards, or shared
clocks, then you have DAPM events that are interesting to propagate.
Power management is not 'simple' or even 'simpler' to me.

We can also debate forever on probe failures, the user will only see a
problem when they try to use the missing devices. Fail big and fail
early is the best model I've seen so far, much easier to support and report.

I am not saying having multiple cards is a bad idea, just that there are
a number of technical opens with strong implications on the
implementation and scaling.