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

[Srinivas Kandagatla]

On 7/24/26 4:40 PM, Charles Keepax wrote:
> 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.
> 
I'm inclined to go with this approach as well, provided the Device Tree
maintainers are satisfied with the initialization sequences. The rest of
the topology bindings appears solid.

This decision would also establish a precedent for handling other
DisCo-based devices in Device Trees.

> 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.
No restrictions as such, its just consensuses with DT maintainers.

--srini
> 
> Thanks,
> Charles