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

[Charles Keepax]

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:
> >> The direction from that discussion was to let DT platforms reuse the
> >> same class/function auxiliary driver plumbing and have codec drivers
> >> supply the small amount of static function/entity metadata that DisCo
> >> would otherwise carry, plus hooks for device-specific bring-up.  This
> >> series is a first cut at that, with the Qualcomm WCD9378 ("Tambora")
> >> SDCA codec on the Glymur CRD as the first consumer. Static table that in
> >> part of this codec is generated from acpi tables.
> > 
> > Fascinating, a shame I missed the discussion. Main question
> > I have is what was the reasoning behind using static tables
> > rather than just putting the data in device tree? All the core
> > code uses the generic firmware parsing function so should be
> > perfectly capable of parsing the data out of device tree. The
> > only bit that is missing is really the sdca_lookup_functions
> > bit you ifdef out, but updating that to also support DT should
> > be pretty simple.
> Two reasons
> 
> 1. This is laptop platform primarily works on windows with proper acpi
> tables, These tables are directly derived for ACPI asl tables in
> windows. Ideally I want to use it the way it is supposed to work.

This is a little confusing, could we not just the ACPI in those
cases?

> 2. replicating full Disco specs in DT is going to be challenge, Because
> DT describes hardware but not necessarily at a level of register init
> tables or to an extent where class drivers need it.
> 
> > Looking through your presentation (thanks for linking that),
> > am I to guess this was mostly a device tree people didn't like
> > the stuff SDCA contains problem? I do see that some of the SDCA
> > stuff isn't an exact match for how Linux has traditionally liked
> > to handle DT but also really not sure I see any benefit to DT
> > and ACPI support being different.
> 
> I think there is fine line on what can go into DT, some of the hardware
> init tables are big No No i guess, Power and other ACPI things are not
> something DT does.
> 
> I will let DT maintainers comment on this.

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.

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.

Thanks,
Charles