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

[Krzysztof Kozlowski]

On 30/07/2026 11:08, Charles Keepax wrote:
> On Wed, Jul 29, 2026 at 01:41:57PM +0200, Krzysztof Kozlowski wrote:
>> On 23/07/2026 12:17, 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.
>>>
>>> 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.
>>
>> We do not describe in DT properties which are implied/deducible from the
>> compatible, because it is redundant and we do not like redundancy.
>>
>> The device is WCD9378 as defined by compatible, thus all or most of SDCA
>> properties do not belong to DT.
> 
> Do we really want to take this line? It basically forces us to
> do "board files" again, which is the problem DT was solving in

Again? We since long, long, long do board files and they are approved.
Although now they are called software nodes, but same stuff.

> the first place. I can't speak for Qualcomm, but at least for
> our devices the SDCA properties can change a fair amount
> between different laptops.

Sure, all properties which are not implied by compatible make sense for DT.

> 
> Also there is the fact SDCA is already a thing and is gaining a
> fair amount of traction pushing against it does really feel like
> it is just making life much harder for ourselves.

I do not understand this comment. I am not pushing against SDCA. I am
giving you guideline what can go to DT. Are you saying that SDCA somehow
received review/approval of DT maintainers, so that we are bound by it now?


Best regards,
Krzysztof