Re: ASoC: tas2783-sdw: no stereo channel split for two mono amps -> mono output (AMD ACP SoundWire, ASUS ProArt PX13)

[Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>]

On 8/7/26 07:21, Andrey Golovko wrote:
> On 7/27/26 13:21, Antoine Monnet wrote:
>> I logged name_prefix against the resulting ch_mask and got tas2783-1 = 0x8
>> = left, tas2783-2 = 0xb = right; the split is correct by ear and by per-amp
>> mixer mute. Since your unit is the same HN7306EAC the prefix ordering is
>> identical, so this should give correct L/R for you too - a Tested-by from
>> the second machine would be welcome if you get a chance, but nothing needs
>> re-deriving.
> 
> Tested-by: Andrey Golovko <andrey@golovko.me>
> 
> Confirmed on the second machine: ASUS ProArt PX13 HN7306EAC, v7.2-rc4 based
> kernel, same two TAS2783 at unique_id 0x8 / 0xB plus RT721 on SoundWire
> link 1.
> 
> With your patch applied both amps render, and the assignment is correct by
> physical placement, not merely by control name:
> 
>   speaker-test -Dpipewire -c2 -s1  ->  physically left speaker only
>   speaker-test -Dpipewire -c2 -s2  ->  physically right speaker only
> 
> Both amps at full scale, all four Left/Right Spk[2] switches on. Before the
> patch, -s1 was audible and -s2 was silent, with only one amp contributing at
> all - so this is exactly the behaviour you predicted for an identical
> HN7306EAC: the prefix ordering matches, tas2783-1 takes the left channel and
> tas2783-2 the right, and that lines up with the physical speakers.
> 
> One caveat, measured since by Robin Everaars, who reported the same
> issue on yet another HN7306EAC (added to Cc):
> 
>   https://lore.kernel.org/all/20260805183517.8665-1-robineveraars@pm.me/
> 
> The ch_mask *value* is not what selects the channel:
> sdw_compute_slave_ports() assigns payload offsets positionally along
> slave_rt_list, and Robin showed that inverting the two masks between the
> amps does not move the audio. A one-channel mask fixes mono because it
> stops the mirror-mode offset reset; L/R then follows the codec order in
> the DAI link, which on this platform happens to match the speakers. The
> Tested-by stands - the split the patch produces is correct on both
> machines - but the name_prefix -> BIT(n) mapping reads as if the bit
> picks the channel, which is worth a comment or a reword before a formal
> submission. Where the binding should really come from is being discussed
> in Robin's thread.

Selecting a mono channel at the port level is indeed a solution but not
quite what SDCA designs are supposed to implement. As discussed in the
other thread, all amps are supposed to receive *all* channels and use
mapping/processing to generate the per-amp desired output. That
generation can be dynamic depending on 'posture'.

Looking at the SmartAmp topology in the SDCA spec, my guess would be
that the mapping is really handled in the UDMPU23 and FU 23 entities.
The topology has a 'Amp Transducer Mapping' label which seems to be the
right location to make the left/right speaker selection.

FU23 looks like a dead-end, it is a 'platform' FU not supposed to be
modified by the class driver. The Channel Gain is a platform-specific
value set with OEM defaults, the drivers shouldn't muck with those values.

The UDMPU23 has a 'ClusterIndex' control at offset 0x10, it's not
exposed to userspace but is part of regmap

case SDW_SDCA_CTL(1, TAS2783_SDCA_ENT_UDMPU23,
			  TAS2783_SDCA_CTL_UDMPU_CLUSTER, 0):

It might be worth experimenting with different non-zero cluster indices
for each amp. If the index is zero then the channel selection is
bypassed, whatever is provided to the UDMPU input pin will flow on the
output.

Unfortunately the cluster index is not a direct representation of the
channel selection, it points to a table in which the channel selection
is defined. Nothing requires that the indices be continuous, and that
table can in theory be platform-specific...

One would hope that the codec vendor has guidelines on which cluster
uses what index... Someone at TI should really comment on whether this
UDMPU cluster selection is the correct direction, as usual the caveat
that such experiments might blow the speakers...