On 6/7/23 12:18, Mark Brown wrote:
On Wed, Jun 07, 2023 at 05:05:20PM +0000, Charles Keepax wrote:
On Wed, Jun 07, 2023 at 05:22:45PM +0100, Mark Brown wrote:
This is questionable when the CPUs are connected to different links. SoundWire is not a giant switch matrix, there's a clear parent-child dependency and limited scope.
Example topology for a 2 link/4 amplifier solution.
Or a system with two distinct I2S DAIs (TDM is another thing).
I guess the bit that slightly phases me here is, historically a DAI link has been the thing that specifies what is connected to what. What kinda happened when we added multi-cpu is we bent that assumption, at least for the N -> N case, and now even more so for the N -> M case, where only a subset of the DAI link is actually connected.
If your system looks like:
CPU A -> CODEC A CPU B -> CODEC B
What makes this a single DAI link, rather than 2 DAI links? And does the information within the DAI link about what is connected to what not just start looking like DAI links?
Ah, indeed. My expectation would be that for things on the same physical set of wires we'd at some point be able to get to a point where the the SoundWire routing would be exposed to userspace for control, probably at the point where we get digital routing working (whenever in the far far future that might be, it's only been a bit more than a decade thus far). I have to say Pierre's example looked like two separate buses.
They are separate buses indeed at the hardware level, and even on the Linux side we have one manager device per link.
The key point is that all buses are synchronized with a common hardware signal, typically 4kHz, on the SOC/PCH side.
The dailink .trigger is translated as a multi-link bank switch which will start transmission exactly at the same time on all links.
That's the big difference with using multiple dailinks, if we had one dailink per physical pair of (clock, data) wires, we would not be able to synchronize amplifiers, leading to random phase offsets between amplifiers. Not so good.