Hi Rob, James,
> On 12. 3. 2025, at 13:58, Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Mon, Mar 10, 2025 at 07:30:07PM +1000, James Calligeros wrote:
>> On Sat, Mar 8, 2025 at 6:51 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>>> 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?
For this setup there are 6 codecs on the same bus but 3 of those are on one
data line and the other 3 are on another data line. Within the SoC these two
data lines (both for codec->SoC direction) are ORed together in front of the
receiver peripheral.
This means we need at least one codec within each group of the three to zero
out the bus for the duration of the slots used by the other group of three.
I solved this by attaching
ti,sdout-force-zero-mask = <0xf0f0f0>;
on one codec from the first group, and
ti,sdout-force-zero-mask = <0x0f0f0f>;
on one from the other group.
FWIW the right form of these masks is not an implementation detail of the
machine driver spilling into the device tree (so that the mask would need
to be different if the machine driver was implemented differently). This is
because the slots used by each codec are specified via a DT property too, e.g.
ti,imon-slot-no = <8>;
ti,vmon-slot-no = <10>;
Martin
> Rob
>
