On Mon, Mar 10, 2025 at 07:30:07PM +1000, James Calligeros wrote:

On Sat, Mar 8, 2025 at 6:51 AM Rob Herring [off-list ref] wrote:

quoted

How would it work when you need a mask? "dai-tdm-slot-tx-mask" is
enough?

The existing TX/RX slot masks are used to control which slots the codec
is operating on, AIUI. I don't know if it makes sense to alter how codecs
deal with this. Could we combine the suggested dai-tdm-slot-tx-idle
with an optional dai-tdm-slot-tx-idle-mask property? From the machine
driver's perspective, the API would then be similar to the existing
set_tdm_slot ops. The current downstream macaudio machine driver builds
its links by allowing multiple codecs and CPUs to be linked to a DAI,
like so:

Wouldn't the NOT of dai-tdm-slot-tx-mask be the idle mask?

Don't think about the Linux APIs here. The DT is separate. So think in 
terms of what you need to describe the TDM timing/waveform.

dai-link@0 {
	cpu {
		sound-dai = <&cpu0>, <&cpu1>;
	};
	codec {
		sound-dai = <&speaker0>,
			  ...,
			  <&speaker6>;
	};
};

In this case, the codec-specific mask property was added so that a mask
could be applied to a specific codec rather than the whole dai, however
from upstream drivers tt looks like the way this should be handled is to
have "dai-tdm-slot-tx-idle-mask-n" properties at the dai level, then have
the machine driver set the mask for the appropriate codec during setup. So
for macaudio, assuming speaker5 requires this zerofill mask, we would
have something like this:

I'm now confused why you need n masks and what does n represent?

Rob