On Wed, Jun 07, 2023 at 01:13:49PM -0500, Pierre-Louis Bossart wrote:
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: 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.
Indeed, not so good. I had a chat with Richard and we were wonder if this is really one of those we have started down a path and it's a bit late to change course now situations. I don't think either of us have a great objection to the within the DAI link hook up table really, just hard to get my head around what a DAI link means in that case. I guess if I just think of DAI links as being more a logical grouping, that is being treated as a single stream, rather than representing physical links?
To provide the other side, in my head, where most things are C2C links rather than DPCM, the situation really looks something like this:
+----------+ +---------+ + SDW A + <-> + CODEC A + +-----+ + + +---------+ + CPU + <-> + DSP + +-----+ + + +---------+ + SDW B + <-> + CODEC B + +----------+ +---------+
And the responsibility for starting the bank switch would lie with the DSP driver. It gets a single trigger from its DAI to the CPU, which provides the sync point. But this seems fairly removed from how things are presently implemented and it perhaps feels like the effort to get there isn't worth it, especially since me and Richard are unlikely to have the time in the near term to do a lot of it.
Thanks, Charles