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

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.

Best regards,
Krzysztof