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

[Krzysztof Kozlowski]

On 29/07/2026 15:34, Srinivas Kandagatla wrote:
> 
> 
> 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

All this should be part of TX. You cannot use argument that you moved
some logic outside as reason why you need to move that logic. That's
circular.

> 
> 
>>
>> 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.

No, that's irrelevant. On which external bus does it sit? I2C devices
sit on I2C bus. Do you see them in top-level?

Best regards,
Krzysztof