ASoC component/card relationship

[Mark Brown]

On Tue, May 03, 2022 at 01:59:54PM -0500, Pierre-Louis Bossart wrote:

> > This means we get back to the assumption we started off with - what are
> > we gaining by partitioning things into cards when that's not really
> > what's going on with the hardware?

> The main benefit is reuse of 'generic' cards.

> Take for example HDMI support, it's typically exactly the same from one
> board to the other - it's completely standard. And yet, for every card,
> we have to add a path in the topology and the machine driver to
> represent exactly the same information multiple times. see below how
> many times we add the same 'late_probe' callback for HDMI support in
> machine drivers.

> BT audio is a similar case, the interface configuration and settings are
> defined by profiles, so there's almost no variation from one board to
> the other except for which I2S number is used.

> A peripheral directly attached to an SOC or chipset, such as digital
> microphones, is a similar case.

> The point is really to try to split what will be variable from board to
> board due to different choices of headset codecs, amplifiers,
> microphones, from what is generic and reusable.

There's a reusability thing here which does seem somewhat valid, but it
does feel to me like separate cards is a bit of a case of having a
hammer so everything looks like a nail kind of solution to the issue.
The issue you've got is not that these are disconnected bits of hardware
which operate independently, it's that you don't have a good way of
dropping the board variations into a template machine driver or
otherwise customising one.

Off the top of my head you could probably get some way with this if
there were a way to tell the core to skip over some links during
instantiation, that might help keep a common core of these bits you wan
to split out into cards more static.  Perhaps also being able to add
multiple sets of DAIs to a component rather than having to compose the
full list and then add everything in one shot?

> The logic can be pushed further, as done in the AVS patch series, to
> split the card by codec type. This would avoid having to deal with the
> permutations that we have to handle in machine drivers. See e.g. how
> complicated the initially generic sof-rt5682 machine driver has become,
> it now supports rt5682s, rt1011, rt1015, rt1015p, max98373 and
> max98360a. I will accept this comes from ACPI limitations, but if we
> could split cards it would also reduce the machine driver complexity.

If you want to split the cards up more as things stand there's nothing
really standing in your way there.  As you say though I do think this is
just that your firmware doesn't describe most of the hardware and so you
end up with a large element of bikeshedding the deckchairs on the Titanic
which limits how good things can get.  I do wonder what happens if we
split things into cards and then get better at letting userspace
dynamically manage what the DSP is doing rather than relying so much on
fixed topologies...

> In terms of functionality, I don't think there will be any performance
> or power improvement coming from a multi-card solution, it's mostly a
> maintenance simplification: less duplicated code, more reuse.

> One key point is "who defines the split". That's really one of the main
> problems and different people could have different opinions - Cezary and
> I have a shared goal of enabling multiple cards but different takes on
> what the 'optimal' split might be.

> My take is that the integrator for a given hardware is responsible for
> making the decision - not the provider of a DSP driver. In case you have
> coupling between interfaces, playback or capture, it can become really
> difficult to define a split that will work for all cases, or conversely
> if you don't have 'self-contained' cards that can be tested
> independently then splitting the functionality was probably a really bad
> idea. If one needs to add dependencies and quirks for a local device,

Looks like something got dropped here.  It does sound a bit concerning
that the split into machine drivers could be done using quirks.

> In other words, I think we need to agree on the means to create and
> expose multiple cards, and agree not to debate on what the functionality
> of individual cards might be.

> Hope this helps clarify the ask?

It's still not clear to me if the problem you're facing couldn't be
addressed as well with better interfaces for adding dai_links to the
card, that (mainly around BEs) seems to be the main thing you're having
trouble with as far as I can see?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20220503/4f794635/attachment.sig>