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

[Srinivas Kandagatla]

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:
>> At Linux Plumbers 2025 in the Devicetree MC I raised the "SDCA and the
>> classic ACPI-DT problem" [1]: MIPI SDCA is built around ACPI/DisCo
>> firmware descriptors, and the in-tree ASoC SDCA framework
>> (sound/soc/sdca/) enumerates functions, entities, controls and PDEs by
>> walking those tables. On ARM64 DT platforms there is no DisCo, so the
>> framework is unreachable and sdca codecs will not be able to use the
>> generic sdca drivers and duplicating.
>>
>> 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.

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.

> 
> I guess there is also a slightly risk the standard committee
> eventually get round to device tree and adds support differently,
> but an existing large user would be an excellent steer on them.
> 
I think whole Disco has not considered DT at all.


>>  * 1: hw_params fix for OT DAI upstream Input Terminals (found while
>>    bringing up Tambora capture).
> 
> Thanks that is indeed something that needs some work.
> 
>>  * 2: allow sound/soc/sdca/ to build without ACPI.
>>  * 3: turn sdca_class into an exported library and introduce
>>    struct sdca_class_hw_ops with hw_init + get_function_data, so a
>>    codec driver registers its own sdw_driver, supplies static function
>>    descriptors when there is no DisCo node, and owns regulators/reset
>>    at probe time.  The built-in class_sdw_driver stays for
>>    pure-generic parts (hw_ops = NULL).
> 
> Yeah, we have not really implemented any XU type stuff yet. Some
> discussion about whether we want to proceed with adding custom
> callbacks into the class driver or just call the core functions
> from the end driver. The later was really the original intention
> although I do grant that there has ended up being slightly more
> boiler plate in the class driver than would have been ideal.

XU should be opaque to class drivers.

> 
>>  * 4: pde_pre_pmu / pde_post_pmu hooks in hw_ops so vendor drivers
>>    can stage/commit register writes around PDE PS0 transitions.
>>  * 5: of_xlate_dai_name that resolves sound-dai cells by entity index
>>    rather than positional DAI order.
>>  * 6: register SDCA_FUNCTION_TYPE_SIMPLE_JACK in the class function
>>    driver.
> 
> We can probably just merge the simple jack support as is. I will
> have a look.
> 
> Going to likely take me a few days to work my way through things,
> but please bear with me. Great to see the SDCA stuff getting some
> proper usage outside of us :-)

Thanks for the positive note.

Plan is to get all the Qualcomm SDCA codecs to use existing sdca drivers
than writing duplicate code.

We do have couple of more SDCA drivers, the one I could include in next
version is a Simple Amp driver which has pretty much in similar lines
WCD9378 codec, everything leveraged from generic drivers.


--srini
> 
> Thanks,
> Charles