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

[Srinivas Kandagatla]

On 9/8/26 9:49 AM, Charles Keepax wrote:
> On Mon, Sep 07, 2026 at 11:37:49PM +0100, Srinivas Kandagatla wrote:
>> 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.
>>
>> 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.
> 
> I am still not sure I really see what the value is in a
> completely different DT representation of the DisCo information,
> all it does is give us potential issues with future spec versions
> and create a whole bunch of new code than needs maintained. The
> ACPI representation translates perfectly well to DT, should work
> perfectly fine using the existing code.

I totally agree with both of your comments, there is no way we can
replicate MiPi spec into an different DT representation, this brings
both maintenance overhead and is fragile. This a very big effort.

Either we represent full ACPI into DT or use some know representation
that linux understands and is maintained along with ACPI which is the C
structure.

> 
> However, that said if people want to work on doing so I am not
> going to stand in the way. It does have the advantage it might
> unblock things with the DT maintainers, since we can focus on
> doing stuff in a more traditional DT style.

This is really going to be a very very long shot, but as of today the
need for this is slim, unless we see some platforms which have SDCA
compliant codecs without a reference ACPI fw entires.

> 
> I would also agree that this is reasonable as a half way house,
> it seems like a good fallback mechanism to have for emergency
> work arounds as well. If we can't reuse the existing parser then
> there is a lot of work to define a new representation for DT.
+1

> Ideally that would be worked through with the MIPI group as well
> to avoid future specs causing catastrophic issues. But all that
> will take significant time so we probably need an interim
> solution.
> 

--srini
> Thanks,
> Charles