Re: [PATCH v2 2/2] ASoC: tas2783-sdw: do not cache read-only Controls

[Andrey Golovko <andrey.golovko@gmail.com>]

On Tue, Aug 18, 2026 at 09:16:19AM +0100, Charles Keepax wrote:

> One thing that is worth noting, is that sometimes in SDCA values
> are DisCo constants, these are registers where the value is just
> hard coded in the ACPI and typically not implemented in the
> hardware. Generally, these are implemented as non-read/non-write
> registers with an entry in the default array. This allows the
> constant value to be read through the regmap, and driver code
> generally doesn't need to care that the register is fictional.

Thank you - that sent me to the ACPI, and what is there says something
about the whole read-only list rather than only those two Controls.

The Function is described in DisCo on this machine, in some detail: both
amplifiers carry an identical Function node with 27 Entities and their
Controls.  The driver ignores all of it and works from its own tables,
so the two descriptions can be compared.  They disagree, and they
disagree in a way that lines up with what the peripheral answers.

tas2783_read_only_control() names 33 Controls.  DisCo declares seven of
them: the Latency of FU21, the Clock Valid of CS21, CS25, CS26 and CS28,
the Actual Power State of PDE23 and the Protection Status of SAPU29.
For eighteen the Entity is described but the Control is not - that is
every remaining Latency, and the XU_ID and XU_Version of XU22.  The last
eight belong to six Entities that do not appear in DisCo at all: CS24,
OT24, OT127, CS127, MFPU21 and MFPU26.

The three of those I have read off the bus agree with the description.
PDE23 Actual PS answers 0x0 and SAPU29 Protection Status 0x3 on both
amplifiers, both declared.  XU22 XU_ID answers COMMAND_IGNORED, powered
or not, and is not declared.  (XU22 0x12 answers COMMAND_IGNORED too and
is declared, so the correspondence is not perfect, but for the read-only
list it holds so far.)

So of the 21 Latency Controls in that list, DisCo describes exactly one:
FU21 0x10.  Which is one of the two I wrote to you about, the ones
tas2783_sdca_mbq_size() has no case for and which are therefore
unreachable through the regmap.  The single Latency the platform
actually describes is the one the driver cannot read, while twenty
Latencies that nothing describes are declared four bytes wide and
answered from a 0x0 placeholder in the cache.

That reads to me as two separate things rather than one, and the DSDT
settles the first.  FU21 0x10 is declared with access mode 0x05 - DC,
your DisCo constant - and mipi-sdca-control-dc-value 0x0.  So it is
exactly the case you described: fictional in the hardware, constant in
the ACPI, and it wants a default-array entry with no readable or
writeable case rather than a size case.  The other twenty Latencies have
no DisCo entry at all to be constants of.

Reading the access modes for the whole Function turned up the rest of
the disagreement, which runs in both directions.  Of the seven Controls
the driver's read-only list and DisCo have in common, six are declared
RO - the four Clock Valids, PDE23 Actual PS, SAPU29 Protection Status -
and the seventh is that DC.  Meanwhile DisCo marks as DC or RO several
Controls the driver treats as ordinary writable registers:

  XU22 0x09 and 0x0a  DC, dc-value 0x0   (the two Selectors SDCA does
                                          not define - so they are
                                          constants, not registers)
  UDMPU23 0x10        DC, dc-value 0x1   (driver default says 0x0)
  SAPU29 0x10         RO                 (Protection Mode)
  XU22 0x15           RO
  IT21 and IT26 0x10 and 0x11, IT28 0x11, OT25 and OT28 0x11,
  FU127 0x01, 0x04 and 0x05, MU26 0x01      all DC

None of that is reachable from the read-only series as posted, and I am
not proposing to chase it there.  But it does mean the list 2/2 acts on
was assembled independently of what the platform says, and agrees with
it in six places out of thirty-three.

So for the series I would rather narrow than guess: keep 2/2 for the six
Controls DisCo declares RO, which are also the ones I have measured
answering real values off the bus, and leave everything else - the
constants, the phantom Latencies, the writable-but-RO ones - to TI,
whose mail goes out today.  FU21 0x10 would then be a separate small
patch giving it the DC treatment, once TI confirm the driver should
follow this platform's description.

Would you rather review that, or have me hold 2/2 entirely until TI
answer and send only 1/2, which stands on its own?

Andrey