Re: [RFC PATCH 7/8] dt-bindings: sound: qcom: add Tambora WCD9378 SDCA codec

From: Krzysztof Kozlowski

Date: Wed Jul 29 2026 - 08:58:11 EST


On 29/07/2026 14:17, Srinivas Kandagatla wrote:
> On 7/29/26 12:40 PM, Krzysztof Kozlowski wrote:
>> On 23/07/2026 01:42, Srinivas Kandagatla wrote:
>>> Describe the WCD9378 SDCA peripheral node (compatible sdw20217011000)
>>> driven by the wcd9378-sdca codec driver for headphone playback, headset
>>> mic capture and jack detection via the SimpleJack SDCA function type.
>>>
>>> WCD9378 codec can be wired up in 2 different modes.
>>> "mobile mode" on phone/tablet SoCs is enumerated as tx and rx device,
>>> each of which has dedicated control and data lines.
>>> "compute mode" on compute platforms such as Glymur is enumerated as
>>> single standard MIPI SDCA class device.
>>>
>>> Both modes share same Device ID, compatible; qcom,compute-mode selects
>>> which driver path is taken. Supplies, reset GPIO and mic-bias voltages
>>> live on the SoundWire slave node in compute mode and are forbidden in
>>> mobile mode (owned by the top-level codec parent there).
>>>
>>> Assisted-by: Claude:claude-opus-4-7
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxxxxxxxx>
>>> ---
>>> .../bindings/sound/qcom,wcd9378-sdw.yaml | 200 ++++++++++++++++++
>>> 1 file changed, 200 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/sound/qcom,wcd9378-sdw.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd9378-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd9378-sdw.yaml
>>> new file mode 100644
>>> index 000000000000..2ed4ad92958e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/sound/qcom,wcd9378-sdw.yaml
>>> @@ -0,0 +1,200 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/sound/qcom,wcd9378-sdw.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Qualcomm SoundWire Slave devices on WCD9378
>>> +
>>> +maintainers:
>>> + - Jorijn van der Graaf <jorijnvdgraaf@xxxxxxxxxxxxx>
>>> + - Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxxxxxxxx>
>>> +
>>> +description: |
>>> + The Qualcomm WCD9378 codec presents its SoundWire slave devices with
>>> + class ID sdw20217011000 in both operating modes:
>>> +
>>> + * mobile mode -- two slave instances sit on separate SoundWire
>>> + masters carrying data only. A separate top-level codec node
>>> + owns the codec's supplies, mic-bias voltages and reset GPIO.
>>> +
>>> + * SDCA / compute mode -- one aggregated slave sits on a multi-lane
>>> + master and carries both control and data. There is no separate
>>> + top-level codec node, so the SoundWire slave node itself owns
>>> + supplies, reset GPIO and mic-bias voltage configuration. It is
>>> + marked with qcom,compute-mode.
>>> +
>>> + Codec drivers that match sdw20217011000 use qcom,compute-mode to
>>> + decide which mode to serve; the presence or absence of this property
>>> + also gates whether the supply and mic-bias properties on this node
>>> + are required or forbidden.
>>> +
>>> +properties:
>>> + compatible:
>>> + const: sdw20217011000
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + qcom,compute-mode:
>>> + description: |
>>> + Marks this SoundWire slave as the single aggregated slave that
>>> + implements the codec in SDCA / compute mode. Only present when
>>> + the codec has no separate top-level codec parent; in that case
>>> + this slave node also owns the codec's supplies, reset GPIO and
>>> + mic-bias voltage configuration. Absent in mobile mode.
>>
>> I doubt there is really "compute" or "mobile" mode, so you just wrote to
>> match use case, but that does not match hardware.
>>
> This is hardware fuse setting, its not just usecase based but it changes
> complete wcd9378 hardware topology, in mobile mode we have 2 soundwire
> devices representing tx and rx side of wcd9378 however in compute mode
> it only has one soundwire device dealing with both tx and rx. compute
> mode is sdca class compliant device.
>
>
>> I think there should be no separate top-level codec parent in the first
>> place, thus this property is not needed. You always list here all resources.
> There is no top level aggregated device when the codec is fused in
> compute mode.

There should not be a top-level in either case. This was always Linux
driver limitation.

Best regards,
Krzysztof