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

[Ville Saarinen]

> 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.

The hweight32() sentence is worth having in the changelog for the reason
you give.

Measurement scripted and analysed with AI assistance (Claude Opus 5);
the register addresses come from the kernel's own SDW_SDCA_CTL() macro
and the numbers are from this laptop, so both are checkable.

Ville