On 5/26/22 09:17, Cezary Rojewski wrote: > On 2022-05-26 3:48 PM, Pierre-Louis Bossart wrote: >> On 5/26/22 04:57, Amadeusz Sławiński wrote: >>> Well, this sounds like what we did in avs, namely we split cards >>> separately based on endpoint. Main driver decides what endpoints to >>> expose, based on ACPI detection and ACPI match rules, see [1]. For >>> example in our model it is possible to have 2 separate i2s codecs >>> connected and each having its own card. From avs driver we expose >>> snd_soc_dai_driver with 2 streams (playback and capture), see [2] and >>> then tell machine driver to just connect them to codec [3] - look for >>> "SSP%d Pin", "ssp%d Tx" and "ssp%d Rx". Connections between "ssp%d >>> Tx"/"ssp%d Rx" and userspace FE are handled by topology in our case, but >>> should be easy to expose without it, if you don't use topologies. >> >> 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. >> >> I don't know if it's feasible in a Device Tree environment: the DT blob >> exposes the machine device, which uses *references* to resources exposed >> by platform and codec drivers. If there were multiple machine devices >> for different cards, how would that split of resources between different >> components be done? >> >> The current ACPI approach will also not work if we move to a generic >> machine driver for SoundWire platform, with one or more devices exposed >> in ACPI for the board-level composition. If the machine devices are NOT >> created by the platform driver, I don't see a clear solution to support >> multiple cards. > > > Hmm.. I don't see why SDW is a problem here. Could you elaborate? I > could boost avs-driver to support SDW configurations if we need a POC. > Why would machine devices not be created by the platform (e.g. PCI) driver? 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.
