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

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Tue, Sep 08, 2026 at 01:31:37PM +0100, Srinivas Kandagatla wrote:
> 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.

I am very sorry but this reads quite strangely and I am really
struggling to understand your position. I think I am reading it
as you are happy to go with the group concensus on how the DT is
represented and don't favour either approach.

> 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.

This part I follow slightly better, I would be happy to proceed,
pending reviews with the current approach, although if Pierre
is or not probably remains to be seen.

I would assume the DT guys would be happy with a completely
different representation that was more idiomatic DT, that is
essentially what they have already said. The question I was
aiming for was less whether they will be on board with that
and more if it is a good idea.

Thanks,
Charles