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

On 29/07/2026 15:02, Srinivas Kandagatla wrote:
> 
> 
> On 7/29/26 1:43 PM, Krzysztof Kozlowski wrote:
>> On 29/07/2026 14:36, Srinivas Kandagatla wrote:
>>> On 7/29/26 1:30 PM, Krzysztof Kozlowski wrote:
>>>> 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 <[email protected]>
>>>>>>> ---
>>>>>>>  .../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 <[email protected]>
>>>>>>> +  - Srinivas Kandagatla <[email protected]>
>>>>>>> +
>>>>>>> +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.
>>>
>>> That is not true, its clearly a hardware topology thing.
>>> Codec has two devices tx and rx, Only one of the device (tx) has access
>>> to CSR registers of the codec, so rx and tx are pretty much a single
>>> aggregate codec device which is why we have top-level representation of
>>> the aggregate device.
>>
>> So two devices, but not three. If TX has access to RX, it does not mean
>> there is third device. If there was a third device (that top level
>> thingy) you would have it here as well. You don't have, because it is
>> purely for Linux.
> 
> WCD codec is a single Codec IP Hardware block which contains two
> soundwire interface devices. Effectively we have one aggregate device
> representing codec which encompasses two soundwire devices.

You have only two devices.

> 
> Third device is the only place where we could represent entire Codec

No, any of these devices could. The top-level is a fake being.

> rather than just soundwire interface devices of the codec.
> 
> Am not sure what is Linux specific here, its purely hardware topology.

The Linux specific is because you needed a placeholder for power
sequencing. It is not a pure hardware topology.

Otherwise, please point me on which/what hardware bus that top-level
codec resides on if it represents hardware topology.

Best regards,
Krzysztof