On 9/7/26 8:47 PM, Pierre-Louis Bossart wrote:
My take is that rather than encode all properties in C, it's probably
worth exploring a DT representation of the concepts that *can* be used
fairly easily and make the life of codec vendors easier - not as a> literal translation of ACPI.
Two things are getting mixed here:
A. Representation: how the SDCA info is expressed as ACPI
DisCo, DT properties, static C tables, or a firmware blob.
B. Reuse of the generic class function drivers, which ultimately
consume struct sdca_function_data.
Whatever A looks like, we end up at the same struct sdca_function_data
that B consumes. sdca_parse_function() converts ACPI DisCo to it
today; populate_function() does the same from static C tables; a DT
parser would do it from DT. Same runtime after that.
Static C tables at least mirror the SDCA spec's own entity/control
structure, so the code stays readable against the spec rather than
inventing a new shape. They are also a byte-for-byte match against
Qualcomm's QcSimpleJack.asl and a live Lenovo T14s DSDT, so we are not
maintaining them as a fork of the vendor source, they are a
mechanical transcription with a verifiable origin.
We landed on static C tables here because the previous DT round was
clear: "if it's derivable from the compat string, keep it out of DT"
(https://lkml.org/lkml/2026/7/29/1166).
As Mark pointed out, DT + SDCA has two use-cases today:
1. Devices that have a reference ACPI table but boot Linux with DT
because no ACPI enablement package (PEP) exists on the SoC yet.
this is what I'm working on.
2. Devices with no ACPI reference at all. I'm not sure any of the
SDCA codecs in sound/soc/codecs/*sdca* today falls into that category.
Solving both in one shot requires SDCA DT bindings that either
translate to struct sdca_function_data, or represent the SDCA spec
fully in DT and share the same parser flow.
I agree a DT expression of the *concepts* not a literal DisCo
mirror would be a better A. I want to bring that back to LPC 2026
DT MC as a concrete proposal grounded in the earlier DT-maintainer
feedback rather than re-litigating it inline on this series. Because
B stays put, switching A later is a change inside populate_function,
not an ABI break. so landing this series does not close the door on
the representation you're asking for.
--srini
Putting everything in C seems like a code management nightmare to me.