Hi > >> It works for ACPI because the platform driver can check if specific > >> _HIDs are present or not, and decide to create different platform > >> devices for different cards, with resources split in different > >> components. In other words, there is no strict boundary between platform > >> and machine driver, the platform has all the information needed. (snip) > 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. But anyway, if my understanding is correct, AVS solution was like this ? +-- DeviceA --+ +-- DeviceB -+ |+-----------+| |+----------+| ||ComponentA1|| ||ComponentB|| || [DAI] <-> [DAI] || Card-1 |+-----------+| |+----------+| | | +------------+ | | | | +-- DeviceC -+ |+-----------+| |+----------+| ||ComponentA2|| ||ComponentC|| || [DAI] <-> [DAI] || Card-2 |+-----------+| |+----------+| +-------------+ +------------+ If [DeviceA] could separate feature into [ComponentA1] and [ComponentA2], it can use multi Cards on current ASoC, but it is not a generic solution, as Pierre-Louis explained. I can agree about it if my understanding was correct. At least my Sound can't use this style. My indicated was like this +-- DeviceA --+ +- DeviceB --+ |+-----------+| |+----------+| ||ComponentA || ||ComponentB|| || [DAI] <-> [DAI] || Card-1 || || |+----------+| || || +------------+ || || || || +- DeviceC --+ || || |+----------+| || || ||ComponentC|| || [DAI] <-> [DAI] || Card-2 |+-----------+| |+----------+| +-------------+ +------------+ [DeviceA]/[ComponentA] is using more generic style, but we can't use this on current ASoC because of Component vs 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. Am I understanding well ? Current ASoC basic style was created very long time ago, and thus, some of them are becoming unnecessary restrictions or mismatch to current system or not intuitively today, I think. My opinion is I don't think we can create perfect solution from the beginning and/or by one patch. What we can do is small update with many deep test to go to correct direction. 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 ;). Thank you for your help !! Best regards --- Kuninori Morimoto
