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

[Srinivas Kandagatla]

On 9/8/26 11:37 AM, Richard Fitzgerald wrote:
> On 08/09/2026 10:09 am, Srinivas Kandagatla wrote:
>> 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.
> 
> But in your previous message in this thread you said the opposite:
> 

Yes I did say that, and I still think an intermediate DT
representation would be a better A in principle.  What I'm
highlighting is the cost side, any intermediate representation, by
definition, deviates from the original MIPI representation.  That
deviation has to be kept in sync with the SDCA spec, tracked across
spec revisions, and translated back to struct sdca_function_data at
runtime.  It's a real overhead, not a blocker, just something to
weigh against the "concepts read cleaner in DT" benefit.

That's why the current series takes the lower-overhead path
(mechanical transcription in C) rather than proposing an intermediate
DT format as part of this submission.  If the concept-DT direction
gets traction at LPC 2026 DT MC, we can revisit.

> "I agree a DT expression of the *concepts*  not a literal DisCo
> mirror would be a better A."
--srini