On 5/26/22 04:57, Amadeusz Sławiński wrote: > On 5/26/2022 4:13 AM, Kuninori Morimoto wrote: >> >> Hi Pierre-Louis >> >> Thank you for your feedback >> >>>> +-- basic board --------+ >>>> |+--------+ | >>>> || CPU ch0| <--> CodecA | >>>> || ch1| <-+ | >>>> |+--------+ | | >>>> +-------------|---------+ >>>> >>>> +-- expansion board ----+ >>>> | | | >>>> | +-> CodecB| >>>> +-----------------------+ >> (snip) >>>> I'm not sure how to count the Card, but >>>> "basic board sound" is 1st card, >>>> "expansion board sound" is 2nd card for us in intuitively. >> (snip) >>> did you mean 'channels' or 'streams'? >> (snip) >>> If however the 'ch0' and 'ch1' can be independent content then this >>> configuration would make sense indeed, and it would be quite similar to >>> the ideas on the Intel side. >> >> These are independent sounds. >> It is working for us if we merge these into one Cards, but... >> I'm OK and will do nothing if no one want to have multi Card connection. >> but I'm happy to work for it if someone needs it. > > 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. > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/intel/avs/board_selection.c > > [2] > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/intel/avs/pcm.c#n946 > > [3] > https://lore.kernel.org/alsa-devel/20220511162403.3987658-8-cezary.rojewski@xxxxxxxxx/T/#u >
