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.
Attachment:
signature.asc
Description: PGP signature
