diff mbox series

[1/2] ASoC: dt-bindings: rt9120: Add initial bindings

Message ID 1633396615-14043-1-git-send-email-u0084500@gmail.com
State Superseded, archived
Headers show
Series [1/2] ASoC: dt-bindings: rt9120: Add initial bindings | expand

Checks

Context Check Description
robh/checkpatch warning total: 0 errors, 1 warnings, 53 lines checked
robh/dt-meta-schema success
robh/dtbs-check success

Commit Message

ChiYuan Huang Oct. 5, 2021, 1:16 a.m. UTC 
From: ChiYuan Huang <cy_huang@richtek.com>

Add initial bindings for rt9120 audio amplifier.

Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
 .../devicetree/bindings/sound/richtek,rt9120.yaml  | 53 ++++++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/richtek,rt9120.yaml

Comments

Mark Brown Oct. 5, 2021, 11:49 a.m. UTC | #1 
On Tue, Oct 05, 2021 at 09:16:54AM +0800, cy_huang wrote:

> +  richtek,use-dvdd-1p8v:
> +    description: Indicate DVDD 1P8V is used, default for 3P3V or 5V design
> +    type: boolean

I would expect this to be done through the regulator bindings, they
would allow the driver to query the supply voltage.
Mark Brown Oct. 5, 2021, 11:54 a.m. UTC | #2 
On Tue, Oct 05, 2021 at 09:16:55AM +0800, cy_huang wrote:

> +static const char * const sdo_select_text[] = {
> +	"NONE", "INTF", "FINAL", "RMS Detect"
> +};

Why not None and Final?

> +	if (event == SND_SOC_DAPM_PRE_PMU)
> +		snd_soc_component_write(comp, RT9120_REG_ERRRPT, 0);
> +	else if (event == SND_SOC_DAPM_POST_PMU)
> +		msleep(RT9120_AMPON_WAITMS);
> +	else if (event == SND_SOC_DAPM_POST_PMD)
> +		msleep(RT9120_AMPOFF_WAITMS);

This should be a switch statement, it'd be clearer.

> +	/* Default config volume to 0dB */
> +	snd_soc_component_write(comp, RT9120_REG_MSVOL, 0x180);
> +	/* Mute by default */
> +	snd_soc_component_update_bits(comp, RT9120_REG_VOLRAMP,
> +				      RT9120_MUTE_MASK, RT9120_MUTE_MASK);

As ever you should leave the defaults at whatever the hardware defaults
to, the defaults for one machine may not be suitable for another so we
shouldn't be trying to do that in software.
ChiYuan Huang Oct. 5, 2021, 12:39 p.m. UTC | #3 
Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午8:29寫道：
>
> On Tue, Oct 05, 2021 at 08:25:43PM +0800, ChiYuan Huang wrote:
> > Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午7:49寫道：
> > > On Tue, Oct 05, 2021 at 09:16:54AM +0800, cy_huang wrote:
>
> > > > +  richtek,use-dvdd-1p8v:
> > > > +    description: Indicate DVDD 1P8V is used, default for 3P3V or 5V design
> > > > +    type: boolean
>
> > > I would expect this to be done through the regulator bindings, they
> > > would allow the driver to query the supply voltage.
>
> > It's more like as the I/O pad voltage.
> > Must be the same as I2C and I2S signal high level.
> > It depends on the application SOC design.
> > From my understanding, not all application SOC I/O voltage uses
> > regulator interface.
>
> It doesn't really matter what the SoC is doing here, you can always add
> regulator support to your device - you'd be requesting the supplies to
> your device, if the SoC doesn't request the supplies that go to it that
> doesn't really make a difference to what your driver does.
>
> Please don't take things off-list unless there is a really strong reason
> to do so.  Sending things to the list ensures that everyone gets a
> chance to read and comment on things.

Sorry, my fault.
I just noticed the mail not reply all. Loop all again.
ChiYuan Huang Oct. 5, 2021, 12:41 p.m. UTC | #4 
ChiYuan Huang <u0084500@gmail.com> 於 2021年10月5日 週二 下午8:36寫道：
>
> Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午7:54寫道：
> >
> > On Tue, Oct 05, 2021 at 09:16:55AM +0800, cy_huang wrote:
> >
> > > +static const char * const sdo_select_text[] = {
> > > +     "NONE", "INTF", "FINAL", "RMS Detect"
> > > +};
> >
> > Why not None and Final?
> >
> Just follow the datasheet to write the text.
> Whatever, Ack in next.
> > > +     if (event == SND_SOC_DAPM_PRE_PMU)
> > > +             snd_soc_component_write(comp, RT9120_REG_ERRRPT, 0);
> > > +     else if (event == SND_SOC_DAPM_POST_PMU)
> > > +             msleep(RT9120_AMPON_WAITMS);
> > > +     else if (event == SND_SOC_DAPM_POST_PMD)
> > > +             msleep(RT9120_AMPOFF_WAITMS);
> >
> > This should be a switch statement, it'd be clearer.
> >
> Ack in next.
> > > +     /* Default config volume to 0dB */
> > > +     snd_soc_component_write(comp, RT9120_REG_MSVOL, 0x180);
> > > +     /* Mute by default */
> > > +     snd_soc_component_update_bits(comp, RT9120_REG_VOLRAMP,
> > > +                                   RT9120_MUTE_MASK, RT9120_MUTE_MASK);
> >
> > As ever you should leave the defaults at whatever the hardware defaults
> > to, the defaults for one machine may not be suitable for another so we
> > shouldn't be trying to do that in software.
> The default volume will be kept in value 0x7ff (mute).
> I just want to follow the ASoC flow to control mute/unmute mask by AMP on/off.
> If to default set volume to 0dB and mute is improper, user have to use
> mixer control to configure the volume.
> Does mute function also need to be removed also?

Sorry, loop all again.
ChiYuan Huang Oct. 6, 2021, 8:47 a.m. UTC | #5 
Hi, Mark:
ChiYuan Huang <u0084500@gmail.com> 於 2021年10月5日 週二 下午8:39寫道：
>
> Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午8:29寫道：
> >
> > On Tue, Oct 05, 2021 at 08:25:43PM +0800, ChiYuan Huang wrote:
> > > Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午7:49寫道：
> > > > On Tue, Oct 05, 2021 at 09:16:54AM +0800, cy_huang wrote:
> >
> > > > > +  richtek,use-dvdd-1p8v:
> > > > > +    description: Indicate DVDD 1P8V is used, default for 3P3V or 5V design
> > > > > +    type: boolean
> >
> > > > I would expect this to be done through the regulator bindings, they
> > > > would allow the driver to query the supply voltage.
> >
> > > It's more like as the I/O pad voltage.
> > > Must be the same as I2C and I2S signal high level.
> > > It depends on the application SOC design.
> > > From my understanding, not all application SOC I/O voltage uses
> > > regulator interface.
> >
> > It doesn't really matter what the SoC is doing here, you can always add
> > regulator support to your device - you'd be requesting the supplies to
> > your device, if the SoC doesn't request the supplies that go to it that
> > doesn't really make a difference to what your driver does.
> >
> > Please don't take things off-list unless there is a really strong reason
> > to do so.  Sending things to the list ensures that everyone gets a
> > chance to read and comment on things.
>
After contacting our HW RD, to support DVDD 1.8V not just SW config,
also HW connections.
To get only DVDD supply voltage is not enough to meet the HW design.
The property seems indeed and need to be used by user's HW connection.

Can this property to be kept?
> Sorry, my fault.
> I just noticed the mail not reply all. Loop all again.
ChiYuan Huang Oct. 6, 2021, 9:09 a.m. UTC | #6 
Hi, Mark:

Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午8:44寫道：
>
> On Tue, Oct 05, 2021 at 08:36:44PM +0800, ChiYuan Huang wrote:
> > Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午7:54寫道：
> > > On Tue, Oct 05, 2021 at 09:16:55AM +0800, cy_huang wrote:
>
> > > > +     /* Default config volume to 0dB */
> > > > +     snd_soc_component_write(comp, RT9120_REG_MSVOL, 0x180);
> > > > +     /* Mute by default */
> > > > +     snd_soc_component_update_bits(comp, RT9120_REG_VOLRAMP,
> > > > +                                   RT9120_MUTE_MASK, RT9120_MUTE_MASK);
>
> > > As ever you should leave the defaults at whatever the hardware defaults
> > > to, the defaults for one machine may not be suitable for another so we
> > > shouldn't be trying to do that in software.
>
> > The default volume will be kept in value 0x7ff (mute).
> > I just want to follow the ASoC flow to control mute/unmute mask by AMP on/off.
> > If to default set volume to 0dB and mute is improper, user have to use
> > mixer control to configure the volume.
> > Does mute function also need to be removed also?
>
> It's totally fine and indeed quite common for devices to be muted by
> default - usually systems will have UCM profiles that unmute things by
> the time users actually interact with them.
>
> Please don't take things off-list unless there is a really strong reason
> to do so.  Sending things to the list ensures that everyone gets a
> chance to read and comment on things.

After asking the HW member, there's already builtin HW volume ramp function.
Mute API is still no need. There's already no pop issue without mute function.

So the next change, I'll remove the default volume and mute config,
and also mute API.

Thx.
ChiYuan Huang Oct. 7, 2021, 2:44 a.m. UTC | #7 
Hi,

ChiYuan Huang <u0084500@gmail.com> 於 2021年10月6日 週三 下午4:47寫道：
>
> Hi, Mark:
> ChiYuan Huang <u0084500@gmail.com> 於 2021年10月5日 週二 下午8:39寫道：
> >
> > Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午8:29寫道：
> > >
> > > On Tue, Oct 05, 2021 at 08:25:43PM +0800, ChiYuan Huang wrote:
> > > > Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午7:49寫道：
> > > > > On Tue, Oct 05, 2021 at 09:16:54AM +0800, cy_huang wrote:
> > >
> > > > > > +  richtek,use-dvdd-1p8v:
> > > > > > +    description: Indicate DVDD 1P8V is used, default for 3P3V or 5V design
> > > > > > +    type: boolean
> > >
> > > > > I would expect this to be done through the regulator bindings, they
> > > > > would allow the driver to query the supply voltage.
> > >
> > > > It's more like as the I/O pad voltage.
> > > > Must be the same as I2C and I2S signal high level.
> > > > It depends on the application SOC design.
> > > > From my understanding, not all application SOC I/O voltage uses
> > > > regulator interface.
> > >
> > > It doesn't really matter what the SoC is doing here, you can always add
> > > regulator support to your device - you'd be requesting the supplies to
> > > your device, if the SoC doesn't request the supplies that go to it that
> > > doesn't really make a difference to what your driver does.
> > >
> > > Please don't take things off-list unless there is a really strong reason
> > > to do so.  Sending things to the list ensures that everyone gets a
> > > chance to read and comment on things.
> >
> After contacting our HW RD, to support DVDD 1.8V not just SW config,
> also HW connections.
> To get only DVDD supply voltage is not enough to meet the HW design.
> The property seems indeed and need to be used by user's HW connection.
>
> Can this property to be kept?

After thinking, This property name may be improper.
I think this change depends on HW external circuit for lowv application.
Currently, I'm modifying the V3 change, this property name also affect
the property parsing code change.
May I directly change the name to 'richtek,dvdd-lowv-application' and
submit the patch v3?

Any comment is appreciated.
> > Sorry, my fault.
> > I just noticed the mail not reply all. Loop all again.
Mark Brown Oct. 7, 2021, 1:45 p.m. UTC | #8 
On Thu, Oct 07, 2021 at 10:44:49AM +0800, ChiYuan Huang wrote:
> ChiYuan Huang <u0084500@gmail.com> 於 2021年10月6日 週三 下午4:47寫道：
> > ChiYuan Huang <u0084500@gmail.com> 於 2021年10月5日 週二 下午8:39寫道：
> > > Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午8:29寫道：

> > > > > > I would expect this to be done through the regulator bindings, they
> > > > > > would allow the driver to query the supply voltage.

> > > > Please don't take things off-list unless there is a really strong reason
> > > > to do so.  Sending things to the list ensures that everyone gets a
> > > > chance to read and comment on things.

> > After contacting our HW RD, to support DVDD 1.8V not just SW config,
> > also HW connections.
> > To get only DVDD supply voltage is not enough to meet the HW design.
> > The property seems indeed and need to be used by user's HW connection.

> > Can this property to be kept?

> After thinking, This property name may be improper.
> I think this change depends on HW external circuit for lowv application.
> Currently, I'm modifying the V3 change, this property name also affect
> the property parsing code change.
> May I directly change the name to 'richtek,dvdd-lowv-application' and
> submit the patch v3?

I still don't understand why you wouldn't describe this through the
regulator bindings, those exist to describe the physical supplies ont he
board and their constraints.
ChiYuan Huang Oct. 8, 2021, 12:25 a.m. UTC | #9 
Mark Brown <broonie@kernel.org> 於 2021年10月7日 週四 下午9:45寫道：
>
> On Thu, Oct 07, 2021 at 10:44:49AM +0800, ChiYuan Huang wrote:
> > ChiYuan Huang <u0084500@gmail.com> 於 2021年10月6日 週三 下午4:47寫道：
> > > ChiYuan Huang <u0084500@gmail.com> 於 2021年10月5日 週二 下午8:39寫道：
> > > > Mark Brown <broonie@kernel.org> 於 2021年10月5日 週二 下午8:29寫道：
>
> > > > > > > I would expect this to be done through the regulator bindings, they
> > > > > > > would allow the driver to query the supply voltage.
>
> > > > > Please don't take things off-list unless there is a really strong reason
> > > > > to do so.  Sending things to the list ensures that everyone gets a
> > > > > chance to read and comment on things.
>
> > > After contacting our HW RD, to support DVDD 1.8V not just SW config,
> > > also HW connections.
> > > To get only DVDD supply voltage is not enough to meet the HW design.
> > > The property seems indeed and need to be used by user's HW connection.
>
> > > Can this property to be kept?
>
> > After thinking, This property name may be improper.
> > I think this change depends on HW external circuit for lowv application.
> > Currently, I'm modifying the V3 change, this property name also affect
> > the property parsing code change.
> > May I directly change the name to 'richtek,dvdd-lowv-application' and
> > submit the patch v3?
>
> I still don't understand why you wouldn't describe this through the
> regulator bindings, those exist to describe the physical supplies ont he
> board and their constraints.

Not to oppose your comment, from the initial idea, I'm just thinking
'how' to make the user easy to use.
But if this way  is more flexible, I'll change it to check the
regulator voltage.

This will be put in patch v3.
Thanks.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml b/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml
new file mode 100644
index 00000000..4d47a78
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/richtek,rt9120.yaml
@@ -0,0 +1,53 @@ 
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/richtek,rt9120.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Richtek RT9120 Class-D audio amplifier
+
+maintainers:
+  - ChiYuan Huang <cy_huang@richtek.com>
+
+description: |
+  The RT9120 is a high efficiency, I2S-input, stereo audio power amplifier
+  delivering 2*20W into 8 Ohm BTL speaker loads. It supports the wide input
+  voltage  range from 4.5V to 26.4V to meet the need on most common
+  applications like as TV, monitors. home entertainment, electronic music
+  equipment.
+
+properties:
+  compatible:
+    enum:
+      - richtek,rt9120
+
+  reg:
+    description: I2C device address
+    maxItems: 1
+
+  pwdnn-gpios:
+    description: GPIO used for power down, low active
+    maxItems: 1
+
+  richtek,use-dvdd-1p8v:
+    description: Indicate DVDD 1P8V is used, default for 3P3V or 5V design
+    type: boolean
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+      rt9120@1a {
+        compatible = "richtek,rt9120";
+        reg = <0x1a>;
+        pwdnn-gpios = <&gpio26 2 0>;
+        richtek,use-dvdd-1p8v;
+      };
+    };