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?
Regards,
Czarek
