Re: [PATCH 2/3] ASoC: dt-bindings: add the Qualcomm WCD9378 audio codec
From: Jorijn van der Graaf
Date: Mon Jul 06 2026 - 18:22:58 EST
On Mon, 6 Jul 2026 22:17:56 +0100, Srinivas Kandagatla wrote:
>> +properties:
>> + compatible:
>> + const: sdw20217011000
>
> Interestingly this same codec with same compatible is wiredup
> differently on compute devices like Glymur but only with one slave,
> rather than tx and rx. This is how the codec works in SDCA mode.
>
> So these binding would need some room to accommodate those changes.
Good to know, thanks - the Fairphone 6 uses the split RX/TX wiring
throughout, so the single-slave SDCA presentation wasn't on my radar.
For v2 I would reword both binding descriptions so the split wiring is
one of two presentations of the chip rather than the only one, keeping
the port-mapping properties optional, so a single-slave node with neither
property still validates against this schema. The parent
qcom,wcd9378-codec binding then documents the split wiring only
(presumably SDCA mode has no parent node aggregating two slaves).
Given the single-driver exploration you mentioned on patch 3/3, I'll
keep v2 minimal on this point (reworded descriptions, mappings
optional). If the Glymur wiring turns out to need more room
reserved here, happy to shape it so the compute devicetrees don't need a
binding rework later.
>> + qcom,tx-channel-mapping:
>
> Do you need these channel mapping(both tx and rx), are they different to
> what slave ch-map is?
They only remap the master-side channel masks; the slave-side channel
map is fixed in the driver. Both properties were inherited from
qcom,wcd937x-sdw.yaml, and the Fairphone 6 doesn't use them (the
defaults match the downstream tx_swr_ch_map). So not needed today -
v2 will drop both properties and the driver parsing for them; the
qcom,pm4125-sdw.yaml binding likewise documents no channel mapping
(though that driver still carries the parsing). They can come back
with a board that actually needs the remap. (Dropping
the parsing also removes the static ch_info mutation the bot review
flagged, superseding the devm-copy fix promised in that triage.)
>> + items:
>> + enum:
>> + - 1 # WCD9378_SWRM_CH1
>> + - 2 # WCD9378_SWRM_CH2
>> + - 3 # WCD9378_SWRM_CH3
>> + - 4 # WCD9378_SWRM_CH4
>
> What is this enum imply? channel mask? or ch-index?
A 1-based master channel index; the driver converts it to a bit mask
(BIT(index - 1)). Same semantics as wcd937x-sdw, and moot in v2 with
the properties gone.
Thanks,
Jorijn