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

[Srinivas Kandagatla]

On 7/29/26 2:23 PM, Krzysztof Kozlowski wrote:
> 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 <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.
>>>>
>>>> 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.

Not just power sequencing we have

1.  tx and rx register read/write interactions happen as part of this
device ex: reading and writing rx blocks inside codec needs to go via tx
device.
2. connecting/interacting TX and rx processing blocks ex: mbhc
3. power and codec internal clock management


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

Its external codec to the SoC.


--srini
> 
> Best regards,
> Krzysztof