Re: [RFC PATCH 0/8] ASoC: SDCA: enable on DT platforms and add Qualcomm WCD9378 (Tambora) codec

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

On Fri, Jul 24, 2026 at 03:31:51PM +0100, Srinivas Kandagatla wrote:
> On 7/24/26 1:36 PM, Charles Keepax wrote:
> > On Thu, Jul 23, 2026 at 02:24:19PM +0100, Srinivas Kandagatla wrote:
> >> Thanks Charles, for the feedback.
> >> On 7/23/26 11:17 AM, Charles Keepax wrote:
> >>> On Thu, Jul 23, 2026 at 12:42:10AM +0100, Srinivas Kandagatla wrote:
> > Yeah agree be good to get the DT guys thoughts on this. It seems
> > like a misstep to me to insist that the SDCA spec implements a
> > completely different system of storing information for DT. SDCA
> > is what SDCA is now, and supporting two different parsers seems
> > like work no one needs when the one parser we have would work
> > fine for both.
> Am not sure I understood the two parser concern, what we are
> representing in the table is something that sdca core already does after
> parsing acpi tables. So we are reusing the same structures. Its like
> result of already parsed acpi tables.
> 
> I did try

Apologies for not being clear. It wasn't strictly a review
comment on the code in the series. It was a wider point that at
some point the world likely will want to put SDCA data in DT,
when that happens there are basically two choices:

1) Use the "same" representation as ACPI, in this case we can
share all the parsing code we have now. But some of the things
might be a little unusual for DT.

2) Do something more idiomatic for DT, which would likely end
up looking very different. But this would require a whole new
parser and lengthy standardisation process.

Mostly what I am interested in here is getting at what the end
goal is. The impression I got was that really everyone from
Plumbers was really more aligned to 2). I am not sure I agree
that is the right choice, although willing to be convinced here.

> > That said I don't totally object to the idea of an option to
> > supply a static block of information as you are in the series. It
> > could be useful for transitional and work around situations. But
> > it doesn't seem like a good choice for SDCA on DT going forward,
> > it is basically going back to the board files that DT was saving
> > us from.
> 
> Either we have this at driver level or at dt level, both of them have
> pros and cons.
> 
> If we decide to go with dt, this how the dt entries will look like, this
> should give fair bit of idea to DT maintianers for discussion.

Thank you so much for mocking this up, that is very helpful.

Are there additional constraints from your side pushing you
one way or another on this? Or are you happy to do either? I am
thinking things like DT needing to be flashed onto systems that
have now shipped or something.

Thanks,
Charles