On Fri, Sep 25, 2020 at 03:04:37PM -0500, Pierre-Louis Bossart wrote: > On 9/25/20 2:22 PM, Mark Brown wrote: > > difficulties today. I'm not sure if we need this for more modern buses > > like SoundWire, I'd hope we can dynamically assign slots at runtime more > > easily, but ICBW. > SoundWire doesn't have a notion of 'slot'. Instead you program the data > ports for the type of audio data to be transmitted/received. ... > In most cases, a sink port receives exactly what it needs, but for playback > we have cases where all amplifiers receive the same data (we call this > 'mirror mode', and each amplifier will be configured to render a specific > channel from the data received. This is useful to deal with Channels are essentially the same as timeslots on a TDM bus TBH. > That said, the mapping of data ports between CPU and codec sides is rather > static, mostly because devices typically dedicate specific data ports to > specific functionality. SDCA will not change this, quite the opposite, the > mapping between ports and audio functionality behind the port will be > defined in platform firmware. > It's a bit of a stretch but conceptually there is some level of overlap > between SoundWire data ports and TDM slots, e.g. if in a TDM link you used > slots 4,5 for headset playback, you might use data port 2 on a SoundWire > link. It's however a 'logical' mapping, the actual position of the bits in > the frame is handled by the bit allocation. If a device is hard limited to particular slots we can presumably discover that (either through the spec or by keying off the ID registers) and do the right thing? In any case if we need a firmware mapping for DT systems it sounds like something that works for TDM should be mappable onto SoundWire channels easily enough.
Attachment:
signature.asc
Description: PGP signature
