About Cleanup ASoC

Mark Brown broonie at kernel.org
Tue May 31 14:25:47 CEST 2022


On Fri, May 27, 2022 at 06:50:34AM +0000, Kuninori Morimoto wrote:

> > Because there will be at some point an ACPI device for the machine
> > driver. I can't give more details on a public mailing list just yet, but
> > the approach based on the PCI driver creating a platform device is NOT
> > future-proof.

> I'm sorry but I'm not well understanding what does "machine device"
> is meaning here.

The card (eg, audio-graph-card).

> If [DeviceA] doesn't need complex DAPM/clocks control,
> my indicated style can be one of the solution for it (?).
> But in such case, *general* DAPM/clock solution is difficult.
> One note is we can still use AVS style on this style.

It can definitely work for some simpler cases, but working out
which cases and making sure that for example things don't break
if someone improves the driver for a piece of hardware gets fun -
things might not be linked up with current code, but the hardware
might actually have more features that cause some cross
connection.

> If my indicated (remove Component vs Card restriction
> as fist step) was correct direction, and if we can agree about that,
> I'm very happy to work for it (not including DAPM/clock
> *generic* solution for now though ;).

On the one hand there does seem to be some demand for it, on the
other hand I do worry that it will end up eventually just running
into things that mean we're effectively pulling everything back
together into a single card again, even if what's exposed to
userspace looks like multiple cards somehow.
-------------- 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/20220531/5dc581f9/attachment.sig>


More information about the Alsa-devel mailing list