[v2,1/3] devicetree: mfd: Add binding for the TI LM3533

Commit Message

Bjorn Andersson Oct. 27, 2015, 4:29 p.m. UTC

Add the binding for the Texas Instruments LM3533 lighting power
solution.

Signed-off-by: Bjorn Andersson <[e-mail]>
---

Changes since v1:
- Added unit to boost-freq and als-resistance (as the frequency now comes with
  a unit specifier I changed it to be expressed in kHz)

 Documentation/devicetree/bindings/mfd/lm3533.txt | 183 +++++++++++++++++++++++
 1 file changed, 183 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt

Comments

Rob Herring Oct. 27, 2015, 7:21 p.m. UTC | #1

On Tue, Oct 27, 2015 at 11:29 AM, Bjorn Andersson
<[e-mail]> wrote:
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
>
> Signed-off-by: Bjorn Andersson <[e-mail]>

Acked-by: Rob Herring <[e-mail]>

> ---
>
> Changes since v1:
> - Added unit to boost-freq and als-resistance (as the frequency now comes with
>   a unit specifier I changed it to be expressed in kHz)
>
>  Documentation/devicetree/bindings/mfd/lm3533.txt | 183 +++++++++++++++++++++++
>  1 file changed, 183 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt b/Documentation/devicetree/bindings/mfd/lm3533.txt
> new file mode 100644
> index 000000000000..399df39ec7e7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,183 @@
> +Texas Instruments LM3533 binding
> +
> +This binding describes the Texas Instruments LM3533, a lighting power solution
> +for smartphone handsets. The common properties are described directly in the
> +node, while each individual component are described in an optional subnode.
> +
> +- compatible:
> +       Usage: required
> +       Value type: <stringlist>
> +       Definition: must be:
> +                   "ti,lm3533"
> +
> +- reg:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: i2c address of the LM3533 chip
> +
> +- ti,hwen-gpios:
> +       Usage: required
> +       Value type: <prop-encoded-array>
> +       Definition: reference to gpio pin connected to the HWEN input; as
> +                   specified in "gpio/gpio.txt"
> +
> +- ti,als-supply:
> +       Usage: optional
> +       Value type: <prop-encoded-array>
> +       Definition: reference to regulator powering the V_als input; as
> +                   specified in "regulator/regulator.txt"
> +
> +- ti,boost-freq-khz:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: switch-frequency of the boost converter, must be either:
> +                   500 or 1000
> +
> +- ti,boost-ovp:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: over voltage protection limit, must be one of: 16, 24, 32
> +                   or 40
> +
> +- #address-cells:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: must be 1
> +
> +- #size-cells:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: must be 0
> +
> += ALS SUBNODE
> +The als subnode must be named "als", it carries the als related properties.
> +
> +- ti,als-resistance-ohm:
> +       Usage: required (unless ti,pwm-mode is specified)
> +       Value type: <u32>
> +       Definition: specifies the resistor value (R_als), in Ohm. Valid values
> +                   ranges from 200kOhm to 1574Ohm.
> +
> +- ti,pwm-mode:
> +       Usage: optional
> +       Value type: <empty>
> +       Definition: specifies, if present, that the als should operate in pwm
> +                   mode - rather than analog mode
> +
> += BACKLIGHT NODES
> +Backlight subnodes must be named "backlight", they carry the backlight related
> +properties.
> +
> +- reg:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: specifies which of the two backlights this node corresponds
> +                   to
> +
> +- default-brightness:
> +       Usage: optional
> +       Value type: <32>
> +       Definition: specifies the default brightness for the backlight, in
> +                   units of brightness [0-255]
> +
> +- label:
> +       Usage: required
> +       Value type: <string>
> +       Definition: specifies a name of this backlight
> +
> +- led-max-microamp:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: specifies the max current for this backlight, in uA, as
> +                   described in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +       Usage: optional
> +       Value type: <u32 list>
> +       Definition: lists the ALS zones to be PWM controlled for this backlight,
> +                   the values in the list are in the range [0 - 4]
> +
> += LED NODES
> +LED subnodes must be named "led", they carry the LED related properties.
> +
> +- reg:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: specifies which of the four LEDs this node corresponds to
> +
> +- linux,default-trigger:
> +       Usage: optional
> +       Value type: <string>
> +       Definition: specifies the default trigger for the LED, as described in
> +                   "leds/common.txt"
> +
> +- label:
> +       Usage: required
> +       Value type: <string>
> +       Definition: specifies a name of this LED, as described in
> +                   "leds/common.txt"
> +
> +- led-max-microamp:
> +       Usage: required
> +       Value type: <u32>
> +       Definition: specifies the max current for this LED, in uA, as described
> +                   in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +       Usage: optional
> +       Value type: <u32 list>
> +       Definition: lists the ALS zones to be PWM controlled for this LED, the
> +                   values in the list are in the range [0 - 4]
> +
> += EXAMPLE
> +
> +i2c@12460000 {
> +       compatible = "qcom,i2c-qup-v1.1.1";
> +       ...
> +
> +       lm3533@36 {
> +               compatible = "ti,lm3533";
> +               reg = <0x36>;
> +
> +               ti,hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> +               ti,als-supply = <&pm8921_l11>;
> +
> +               ti,boost-freq = <500000>;
> +               ti,boost-ovp = <24>;
> +
> +               #address-cells = <1>;
> +               #size-cells = <0>;
> +
> +               als {
> +                       ti,als-resistance = <200000>;
> +               };
> +
> +               backlight@0 {
> +                       reg = <0>;
> +                       label = "backlight";
> +
> +                       led-max-microamp = <20200>;
> +               };
> +
> +               led@0 {
> +                       reg = <0>;
> +                       label = "red";
> +
> +                       led-max-microamp = <5000>;
> +               };
> +
> +               led@1 {
> +                       reg = <1>;
> +                       label = "green";
> +
> +                       led-max-microamp = <5000>;
> +               };
> +
> +               led@2 {
> +                       reg = <2>;
> +                       label = "blue";
> +
> +                       led-max-microamp = <5000>;
> +               };
> +       };
> +
> --
> 2.4.2
>

Lee Jones Oct. 30, 2015, 6:42 p.m. UTC | #2

On Tue, 27 Oct 2015, Bjorn Andersson wrote:

> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
> 
> Signed-off-by: Bjorn Andersson <[e-mail]>
> ---
> 
> Changes since v1:
> - Added unit to boost-freq and als-resistance (as the frequency now comes with
>   a unit specifier I changed it to be expressed in kHz)
> 
>  Documentation/devicetree/bindings/mfd/lm3533.txt | 183 +++++++++++++++++++++++
>  1 file changed, 183 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt b/Documentation/devicetree/bindings/mfd/lm3533.txt
> new file mode 100644
> index 000000000000..399df39ec7e7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,183 @@
> +Texas Instruments LM3533 binding
> +
> +This binding describes the Texas Instruments LM3533, a lighting power solution
> +for smartphone handsets. The common properties are described directly in the
> +node, while each individual component are described in an optional subnode.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "ti,lm3533"
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: i2c address of the LM3533 chip
> +
> +- ti,hwen-gpios:
> +	Usage: required
> +	Value type: <prop-encoded-array>
> +	Definition: reference to gpio pin connected to the HWEN input; as
> +		    specified in "gpio/gpio.txt"

Why have you made this a vendor binding?

*-gpios is a generic property.

> +- ti,als-supply:
> +	Usage: optional
> +	Value type: <prop-encoded-array>
> +	Definition: reference to regulator powering the V_als input; as
> +		    specified in "regulator/regulator.txt"

Same goes for *-supply.

> +- ti,boost-freq-khz:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: switch-frequency of the boost converter, must be either:
> +		    500 or 1000

Quite a few vendors are using 'boost' now.

Perhaps we need to create a set of generic bindings.

Also, we usually measure DT bindings in HZ, not kHz.

> +- ti,boost-ovp:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: over voltage protection limit, must be one of: 16, 24, 32
> +		    or 40

Is this in volts?  If so, it should be microvolts.

> +- #address-cells:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: must be 1
> +
> +- #size-cells:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: must be 0
> +
> += ALS SUBNODE
> +The als subnode must be named "als", it carries the als related properties.

Perfect time to tell us what ALS is/means.

> +- ti,als-resistance-ohm:
> +	Usage: required (unless ti,pwm-mode is specified)
> +	Value type: <u32>
> +	Definition: specifies the resistor value (R_als), in Ohm. Valid values
> +		    ranges from 200kOhm to 1574Ohm.

Might be worth specifying the values which you are actually going to
use here i.e. "200kOhm" is not a valid u32.

> +- ti,pwm-mode:
> +	Usage: optional
> +	Value type: <empty>
> +	Definition: specifies, if present, that the als should operate in pwm

Suggest s/pwm/PWM/

> +		    mode - rather than analog mode
> +
> += BACKLIGHT NODES
> +Backlight subnodes must be named "backlight", they carry the backlight related
> +properties.
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: specifies which of the two backlights this node corresponds
> +		    to
> +
> +- default-brightness:
> +	Usage: optional
> +	Value type: <32>
> +	Definition: specifies the default brightness for the backlight, in
> +		    units of brightness [0-255]
> +
> +- label:
> +	Usage: required
> +	Value type: <string>
> +	Definition: specifies a name of this backlight
> +
> +- led-max-microamp:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: specifies the max current for this backlight, in uA, as
> +		    described in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +	Usage: optional
> +	Value type: <u32 list>
> +	Definition: lists the ALS zones to be PWM controlled for this backlight,
> +		    the values in the list are in the range [0 - 4]
> +

It's usually a good idea to point to where all of the aforementioned
generic properties are documented.  I personally like the format
(See: ../<subsystem>/<binding>.txt)

> += LED NODES
> +LED subnodes must be named "led", they carry the LED related properties.
> +
> +- reg:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: specifies which of the four LEDs this node corresponds to
> +
> +- linux,default-trigger:
> +	Usage: optional
> +	Value type: <string>
> +	Definition: specifies the default trigger for the LED, as described in
> +		    "leds/common.txt"

No such file.  I think you mean "../leds/common/txt".

> +- label:
> +	Usage: required
> +	Value type: <string>
> +	Definition: specifies a name of this LED, as described in
> +		    "leds/common.txt"
> +
> +- led-max-microamp:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: specifies the max current for this LED, in uA, as described
> +		    in "leds/common.txt"
> +
> +- ti,pwm-zones:
> +	Usage: optional
> +	Value type: <u32 list>
> +	Definition: lists the ALS zones to be PWM controlled for this LED, the
> +		    values in the list are in the range [0 - 4]
> +
> += EXAMPLE
> +
> +i2c@12460000 {
> +	compatible = "qcom,i2c-qup-v1.1.1";
> +	...
> +
> +	lm3533@36 {
> +		compatible = "ti,lm3533";
> +		reg = <0x36>;
> +
> +		ti,hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> +		ti,als-supply = <&pm8921_l11>;
> +
> +		ti,boost-freq = <500000>;
> +		ti,boost-ovp = <24>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		als {
> +			ti,als-resistance = <200000>;
> +		};
> +
> +		backlight@0 {
> +			reg = <0>;
> +			label = "backlight";
> +
> +			led-max-microamp = <20200>;
> +		};
> +
> +		led@0 {
> +			reg = <0>;
> +			label = "red";
> +
> +			led-max-microamp = <5000>;
> +		};
> +
> +		led@1 {
> +			reg = <1>;
> +			label = "green";
> +
> +			led-max-microamp = <5000>;
> +		};
> +
> +		led@2 {
> +			reg = <2>;
> +			label = "blue";
> +
> +			led-max-microamp = <5000>;
> +		};
> +	};
> +

Bjorn Andersson Oct. 30, 2015, 7:41 p.m. UTC | #3

On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:

Rob, please see the discussion regarding ti,boost-freq-khz below. Should
we both specify unit at the same time as we use standard units? (This is
not the first time I have to change this back and forth)

> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
> 
[..]
> > +- ti,hwen-gpios:
> > +	Usage: required
> > +	Value type: <prop-encoded-array>
> > +	Definition: reference to gpio pin connected to the HWEN input; as
> > +		    specified in "gpio/gpio.txt"
> 
> Why have you made this a vendor binding?
> 
> *-gpios is a generic property.
> 

Because the hwen gpio is a ti lm3533 specific thing, but I get what
you're saying. Will drop the prefix.

> > +- ti,als-supply:
> > +	Usage: optional
> > +	Value type: <prop-encoded-array>
> > +	Definition: reference to regulator powering the V_als input; as
> > +		    specified in "regulator/regulator.txt"
> 
> Same goes for *-supply.
> 

Same here

> > +- ti,boost-freq-khz:
> > +	Usage: required
> > +	Value type: <u32>
> > +	Definition: switch-frequency of the boost converter, must be either:
> > +		    500 or 1000
> 
> Quite a few vendors are using 'boost' now.
> 

The ti,boost-low-freq from the bq25890 binding is the only other
property I can find that describes the same thing. So I'm not sure I
follow you here.

> Perhaps we need to create a set of generic bindings.
> 
> Also, we usually measure DT bindings in HZ, not kHz.
> 

I thought we had defined frequencies to be in HZ and HZ only, but then
Rob's comment that I need to actually specify the unit doesn't make any
sense.

Do we want these properties in a standard unit or do we want them
specifying the unit? Having both seems excessive.

> > +- ti,boost-ovp:
> > +	Usage: required
> > +	Value type: <u32>
> > +	Definition: over voltage protection limit, must be one of: 16, 24, 32
> > +		    or 40
> 
> Is this in volts?  If so, it should be microvolts.
> 

Okay, will update.

[..]
> > += ALS SUBNODE
> > +The als subnode must be named "als", it carries the als related properties.
> 
> Perfect time to tell us what ALS is/means.
> 

You're right, I'll expand this.

> > +- ti,als-resistance-ohm:
> > +	Usage: required (unless ti,pwm-mode is specified)
> > +	Value type: <u32>
> > +	Definition: specifies the resistor value (R_als), in Ohm. Valid values
> > +		    ranges from 200kOhm to 1574Ohm.
> 
> Might be worth specifying the values which you are actually going to
> use here i.e. "200kOhm" is not a valid u32.
> 

I'll drop the units.

> > +- ti,pwm-mode:
> > +	Usage: optional
> > +	Value type: <empty>
> > +	Definition: specifies, if present, that the als should operate in pwm
> 
> Suggest s/pwm/PWM/
> 

OK

[..]
> > +- ti,pwm-zones:
> > +	Usage: optional
> > +	Value type: <u32 list>
> > +	Definition: lists the ALS zones to be PWM controlled for this backlight,
> > +		    the values in the list are in the range [0 - 4]
> > +
> 
> It's usually a good idea to point to where all of the aforementioned
> generic properties are documented.  I personally like the format
> (See: ../<subsystem>/<binding>.txt)
> 

OK

> > += LED NODES

Regards,
Bjorn

Rob Herring Oct. 30, 2015, 8:18 p.m. UTC | #4

On Fri, Oct 30, 2015 at 2:41 PM, Bjorn Andersson
<[e-mail]> wrote:
> On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
>
> Rob, please see the discussion regarding ti,boost-freq-khz below. Should
> we both specify unit at the same time as we use standard units? (This is
> not the first time I have to change this back and forth)
>
>> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
>>
> [..]
>> > +- ti,hwen-gpios:
>> > +   Usage: required
>> > +   Value type: <prop-encoded-array>
>> > +   Definition: reference to gpio pin connected to the HWEN input; as
>> > +               specified in "gpio/gpio.txt"
>>
>> Why have you made this a vendor binding?
>>
>> *-gpios is a generic property.
>>
>
> Because the hwen gpio is a ti lm3533 specific thing, but I get what
> you're saying. Will drop the prefix.

Actually, that is fine. -gpios is common, but the rest is specific to
a binding. But if it is a common function, then a common name would be
fine. Enable gpios are common for example.

>> > +- ti,als-supply:
>> > +   Usage: optional
>> > +   Value type: <prop-encoded-array>
>> > +   Definition: reference to regulator powering the V_als input; as
>> > +               specified in "regulator/regulator.txt"
>>
>> Same goes for *-supply.
>>
>
> Same here
>
>> > +- ti,boost-freq-khz:
>> > +   Usage: required
>> > +   Value type: <u32>
>> > +   Definition: switch-frequency of the boost converter, must be either:
>> > +               500 or 1000
>>
>> Quite a few vendors are using 'boost' now.
>>
>
> The ti,boost-low-freq from the bq25890 binding is the only other
> property I can find that describes the same thing. So I'm not sure I
> follow you here.
>
>> Perhaps we need to create a set of generic bindings.
>>
>> Also, we usually measure DT bindings in HZ, not kHz.

Surprisingly, there are not enough examples to draw much conclusion.

> I thought we had defined frequencies to be in HZ and HZ only, but then
> Rob's comment that I need to actually specify the unit doesn't make any
> sense.

I don't think we decided, but let's decide now. Go with Hz.

Really, I first prefer the property name has units and second having
standardized units. But if there is a common property without units, I
prefer that even more.

> Do we want these properties in a standard unit or do we want them
> specifying the unit? Having both seems excessive.

You mean "freq" would imply the units? No, we want the actual units in
the property.

Rob

Bjorn Andersson Oct. 30, 2015, 9:16 p.m. UTC | #5

On Fri 30 Oct 13:18 PDT 2015, Rob Herring wrote:

> On Fri, Oct 30, 2015 at 2:41 PM, Bjorn Andersson
> <[e-mail]> wrote:
> > On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
> >
> > Rob, please see the discussion regarding ti,boost-freq-khz below. Should
> > we both specify unit at the same time as we use standard units? (This is
> > not the first time I have to change this back and forth)
> >
> >> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
> >>
[..]
> > The ti,boost-low-freq from the bq25890 binding is the only other
> > property I can find that describes the same thing. So I'm not sure I
> > follow you here.
> >
> >> Perhaps we need to create a set of generic bindings.
> >>
> >> Also, we usually measure DT bindings in HZ, not kHz.
> 
> Surprisingly, there are not enough examples to draw much conclusion.
> 
> > I thought we had defined frequencies to be in HZ and HZ only, but then
> > Rob's comment that I need to actually specify the unit doesn't make any
> > sense.
> 
> I don't think we decided, but let's decide now. Go with Hz.
> 

+1

> Really, I first prefer the property name has units and second having
> standardized units. But if there is a common property without units, I
> prefer that even more.
> 

You can find this property in a variety of hardware, but I don't think
it would make much sense to define this single property in a common
place today.

This seems to be the first case where we specify the unit on one of
these properties though.

> > Do we want these properties in a standard unit or do we want them
> > specifying the unit? Having both seems excessive.
> 
> You mean "freq" would imply the units? No, we want the actual units in
> the property.
> 

You're right, frequency can be measured in other units than Hz, I can't
think of one that would be applicable here though.

Either way, I'll slap on a unit to the property name - Hz that is...

Thanks for your input.

Regards,
Bjorn

Patch

diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt b/Documentation/devicetree/bindings/mfd/lm3533.txt
new file mode 100644
index 000000000000..399df39ec7e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,183 @@ 
+Texas Instruments LM3533 binding
+
+This binding describes the Texas Instruments LM3533, a lighting power solution
+for smartphone handsets. The common properties are described directly in the
+node, while each individual component are described in an optional subnode.
+
+- compatible:
+	Usage: required
+	Value type: <stringlist>
+	Definition: must be:
+		    "ti,lm3533"
+
+- reg:
+	Usage: required
+	Value type: <u32>
+	Definition: i2c address of the LM3533 chip
+
+- ti,hwen-gpios:
+	Usage: required
+	Value type: <prop-encoded-array>
+	Definition: reference to gpio pin connected to the HWEN input; as
+		    specified in "gpio/gpio.txt"
+
+- ti,als-supply:
+	Usage: optional
+	Value type: <prop-encoded-array>
+	Definition: reference to regulator powering the V_als input; as
+		    specified in "regulator/regulator.txt"
+
+- ti,boost-freq-khz:
+	Usage: required
+	Value type: <u32>
+	Definition: switch-frequency of the boost converter, must be either:
+		    500 or 1000
+
+- ti,boost-ovp:
+	Usage: required
+	Value type: <u32>
+	Definition: over voltage protection limit, must be one of: 16, 24, 32
+		    or 40
+
+- #address-cells:
+	Usage: required
+	Value type: <u32>
+	Definition: must be 1
+
+- #size-cells:
+	Usage: required
+	Value type: <u32>
+	Definition: must be 0
+
+= ALS SUBNODE
+The als subnode must be named "als", it carries the als related properties.
+
+- ti,als-resistance-ohm:
+	Usage: required (unless ti,pwm-mode is specified)
+	Value type: <u32>
+	Definition: specifies the resistor value (R_als), in Ohm. Valid values
+		    ranges from 200kOhm to 1574Ohm.
+
+- ti,pwm-mode:
+	Usage: optional
+	Value type: <empty>
+	Definition: specifies, if present, that the als should operate in pwm
+		    mode - rather than analog mode
+
+= BACKLIGHT NODES
+Backlight subnodes must be named "backlight", they carry the backlight related
+properties.
+
+- reg:
+	Usage: required
+	Value type: <u32>
+	Definition: specifies which of the two backlights this node corresponds
+		    to
+
+- default-brightness:
+	Usage: optional
+	Value type: <32>
+	Definition: specifies the default brightness for the backlight, in
+		    units of brightness [0-255]
+
+- label:
+	Usage: required
+	Value type: <string>
+	Definition: specifies a name of this backlight
+
+- led-max-microamp:
+	Usage: required
+	Value type: <u32>
+	Definition: specifies the max current for this backlight, in uA, as
+		    described in "leds/common.txt"
+
+- ti,pwm-zones:
+	Usage: optional
+	Value type: <u32 list>
+	Definition: lists the ALS zones to be PWM controlled for this backlight,
+		    the values in the list are in the range [0 - 4]
+
+= LED NODES
+LED subnodes must be named "led", they carry the LED related properties.
+
+- reg:
+	Usage: required
+	Value type: <u32>
+	Definition: specifies which of the four LEDs this node corresponds to
+
+- linux,default-trigger:
+	Usage: optional
+	Value type: <string>
+	Definition: specifies the default trigger for the LED, as described in
+		    "leds/common.txt"
+
+- label:
+	Usage: required
+	Value type: <string>
+	Definition: specifies a name of this LED, as described in
+		    "leds/common.txt"
+
+- led-max-microamp:
+	Usage: required
+	Value type: <u32>
+	Definition: specifies the max current for this LED, in uA, as described
+		    in "leds/common.txt"
+
+- ti,pwm-zones:
+	Usage: optional
+	Value type: <u32 list>
+	Definition: lists the ALS zones to be PWM controlled for this LED, the
+		    values in the list are in the range [0 - 4]
+
+= EXAMPLE
+
+i2c@12460000 {
+	compatible = "qcom,i2c-qup-v1.1.1";
+	...
+
+	lm3533@36 {
+		compatible = "ti,lm3533";
+		reg = <0x36>;
+
+		ti,hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+		ti,als-supply = <&pm8921_l11>;
+
+		ti,boost-freq = <500000>;
+		ti,boost-ovp = <24>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		als {
+			ti,als-resistance = <200000>;
+		};
+
+		backlight@0 {
+			reg = <0>;
+			label = "backlight";
+
+			led-max-microamp = <20200>;
+		};
+
+		led@0 {
+			reg = <0>;
+			label = "red";
+
+			led-max-microamp = <5000>;
+		};
+
+		led@1 {
+			reg = <1>;
+			label = "green";
+
+			led-max-microamp = <5000>;
+		};
+
+		led@2 {
+			reg = <2>;
+			label = "blue";
+
+			led-max-microamp = <5000>;
+		};
+	};
+