Re: [PATCH v2 11/11] ASoC: codecs: add Qualcomm Tambora (WCD9378) SDCA codec

[Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>]

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.