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

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

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.

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

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

>  * 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,
Charles