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

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Thu, Aug 13, 2026 at 08:56:26AM +0000, Ville Saarinen wrote:
> > Ville measured that UDMPU23 ClusterIndex is simply not implemented on
> > his TAS2783 revision, answering COMMAND_IGNORED to writes and to a
> > plain read alike, so that route is closed at least on that silicon.
> 
> Since this is headed for a changelog: the conclusion is right, but the
> stated reason was not something I had measured. COMMAND_IGNORED was my
> word, in an earlier mail, and it was an overstatement -- the host never
> sees it. find_response_code() (drivers/soundwire/bus.c) maps
> SDW_CMD_IGNORED to -ENODATA, and a control the peripheral does not
> implement arrives as -ENODATA too, so the return code cannot tell a
> deferral from an absence.
> 
> Charles, this is why you are on Cc: the same assumption is the premise
> of the .deferrable annotation on UDMPU23 Cluster Index in the patch you
> picked up, and it does not survive the measurement below.
> 
> The discriminator is Entity 0 Function Status bit 7 (FUNCTION_BUSY),
> which a deferred command sets until the Function finishes. I have now
> read it, on this board's two amps, via the SoundWire debugfs raw command
> interface -- sdw_nread_no_pm()/sdw_nwrite_no_pm(), so the driver's
> regmap is not in the path and readable_reg/mbq_size cannot colour the
> result:
> 
>   UDMPU23 Cluster Index, read:            -ENODATA
>   UDMPU23 Cluster Index, write:           -ENODATA
>   Function Status, 20 reads after each:   0x63, unchanged, ~200 us/read
>                                           FUNCTION_BUSY never set
> 
> in three states -- idle at PDE23 PS3, during playback at PS0, and forced
> to PS0 through PDE23 -- and identically on both amps.
> 
> Controls, so the result is falsifiable in both directions: PDE23 Actual
> Power State reads correctly, and a PDE23 Requested Power State write is
> accepted and moves Actual to PS0, so reads and writes both reach the
> device. A deliberately absent entity (0x3D) returns -ENODATA in every
> one of those states, indistinguishable from Cluster Index.
> 
> So the control is not deferring, powered or unpowered, on read or on
> write. "Not implemented" remains an inference rather than a datasheet,
> and a deferral shorter than one Function Status round trip (~200 us)
> would have been missed, but the deferral reading is the one thing this
> does rule out -- and that reading is what the .deferrable annotation
> encodes.

I am not sure I totally follow this, so apologies if I am getting
the wrong end of the stick, but this sounds like the solution
here is don't use a register in the driver that isn't implemented
in the device.

Thanks,
Charles