Re: [PATCH v2] ASoC: dt-bindings: Convert cirrus,cs35l36 to DT schema

"Rhodes, David" <[email protected]> Wed, 24 Jun 2026 15:05:57 -0500
Newsgroups org.kernel.vger.phone-devel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.kernel.vger.linux-sound
Message-ID <[email protected]>
On 6/24/26 2:45 PM, Rob Herring wrote:
> On Wed, Jun 24, 2026 at 08:39:28PM +0200, David Heidelberg wrote:
>> On 24/06/2026 20:17, Rob Herring wrote:
>>> On Wed, Jun 24, 2026 at 11:02 AM David Heidelberg via B4 Relay
>>> <[email protected]> wrote:
>>>>
>>>> From: David Heidelberg <[email protected]>
>>>>
>>>> Convert CS35L36 Speaker Amplifier to yaml.
>>>>
>>>> Changes:
>>>>    - maintainers email to the generic Cirrus email
>>>>    - Both the codec and downstream worked just fine without
>>>>      VP-supply provided. Align with datasheet for similar models.
>>>>    - add dai-common.yaml to cover for '#sound-dai-cells',
>>>>      'sound-name-prefix'
>>>>
>>>> Reviewed-by: David Rhodes <[email protected]>
>>>
>>> If you are going to take stuff I haven't fixed:
>>>
>>> Assisted-by: OpenAI:gpt-4
>>>
>>> (I don't remember the exact flavor I used)
>>>
>>>> Co-developed-by: Rob Herring (Arm) <[email protected]>
>>>> Signed-off-by: Rob Herring (Arm) <[email protected]>
>>>> Signed-off-by: David Heidelberg <[email protected]>
>>>> ---
>>>> Relevant for Pixel 3 / 3XL / 4.
>>>> ---
>>>> Changes in v2:
>>>> - Rename the commit. (Mark)
>>>> - Link to v1: https://lore.kernel.org/r/[email protected]
>>>> ---
>>>>    .../devicetree/bindings/sound/cirrus,cs35l36.yaml  | 224 +++++++++++++++++++++
>>>>    .../devicetree/bindings/sound/cs35l36.txt          | 168 ----------------
>>>>    2 files changed, 224 insertions(+), 168 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
>>>> new file mode 100644
>>>> index 0000000000000..af0acaaefb68e
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/sound/cirrus,cs35l36.yaml
>>>> @@ -0,0 +1,224 @@
>>>> +# SPDX-License-Identifier: GPL-2.0-only
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/cirrus,cs35l36.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Cirrus Logic CS35L36 Speaker Amplifier
>>>> +
>>>> +maintainers:
>>>> +  - [email protected]
>>>> +  - Bjorn Helgaas <[email protected]>
>>>
>>> Bjorn is not correct. Generally we want a person, not a company list.
>>
>> I'm adding back James, can I keep the patches at 2nd place?
> 
> Yes.

Please put me down and the patches list as well. James will not respond 
at that address any longer.

> 
>>>> +      cirrus,vpbr-thld:
>>>> +        description: Initial VPBR threshold voltage
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
minimum: 2
maximum: 31

>>>> +
>>>> +      cirrus,vpbr-atk-rate:
>>>> +        description: Attenuation attack step rate
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 7

>>>> +      cirrus,vpbr-atk-vol:
>>>> +        description: VP brownout prevention step size
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 7

>>>> +      cirrus,vpbr-max-attn:
>>>> +        description: Maximum attenuation during VP brownout prevention
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 15
this is just an integer dB value

>>>> +      cirrus,vpbr-wait:
>>>> +        description: Delay between brownout clearance and attenuation release
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +enum:
- 0 # 10ms
- 1 # 100ms (Default)
- 2 # 250ms
- 3 # 500ms

>>>> +      cirrus,vpbr-rel-rate:
>>>> +        description: Attenuation release step rate
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +
minimum: 0
maximum: 7

>>>> +      cirrus,vpbr-mute-en:
>>>> +        description: Mute audio if maximum attenuation reached
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>
minimum: 0
maximum: 1

>>> Constraints on any of these?
>>
>> Code just applies whatever is thrown at it, maybe David knows more?
>>
>> #nodatasheet (but would be lovely to have one)
> 
> Unless the driver just takes these values and shoves them straight into
> a 32-bit register, the driver should give some clue about the size or
> possible values.
> 
> Rob
> 
Got some constraints for you.

Thanks,
David