[PATCH v4 1/5] devicetree: mfd: Add binding for the TI LM3533

[PATCH v4 1/5] devicetree: mfd: Add binding for the TI LM3533

[Bjorn Andersson]

From: Bjorn Andersson <bjorn.andersson@sonymobile.com>

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

Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

I had Acks from Jonathan and Rob on v3, but dropped these due to the added
compatible properties.

Changes since v3:
- Added compatible to sub-nodes, per Lee's requested to treat them as separate
  pieces.

 Documentation/devicetree/bindings/mfd/lm3533.txt | 205 +++++++++++++++++++++++
 1 file changed, 205 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..909281096ba2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,205 @@
+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
+
+- als-supply:
+	Usage: optional
+	Value type: <prop-encoded-array>
+	Definition: reference to regulator powering the V_als input; as
+		    specified in "../regulator/regulator.txt"
+
+- 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,boost-freq-hz:
+	Usage: required
+	Value type: <u32>
+	Definition: switch-frequency of the boost converter, must be either:
+		    500000 or 1000000
+
+- ti,boost-ovp-mv:
+	Usage: required
+	Value type: <u32>
+	Definition: over-voltage protection limit, in mV. Must be one of:
+		    16000, 24000, 32000 or 40000
+
+- #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 ambient light sensor subnode carrying the light sensor related properties.
+
+- compatible:
+	Usage: required
+	Value type: <stringlist>
+	Definition: must be:
+		    "ti,lm3533-als"
+
+- 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 200000 to 1574 Ohm.
+
+- 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 carrying the backlight related properties.
+
+- compatible:
+	Usage: required
+	Value type: <stringlist>
+	Definition: must be:
+		    "ti,lm3533-backlight"
+
+- 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 carrying the LED related properties.
+
+- compatible:
+	Usage: required
+	Value type: <stringlist>
+	Definition: must be:
+		    "ti,lm3533-led"
+
+- 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>;
+
+		als-supply = <&pm8921_l11>;
+		hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
+
+		ti,boost-freq-hz = <500000>;
+		ti,boost-ovp-mv = <24000>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		als {
+			compatible = "ti,lm3533-als";
+			ti,als-resistance-ohm = <200000>;
+		};
+
+		backlight@0 {
+			compatible = "ti,lm3533-backlight";
+			reg = <0>;
+			label = "backlight";
+
+			led-max-microamp = <20200>;
+		};
+
+		led@0 {
+			compatible = "ti,lm3533-led";
+			reg = <0>;
+			label = "red";
+
+			led-max-microamp = <5000>;
+		};
+
+		led@1 {
+			compatible = "ti,lm3533-led";
+			reg = <1>;
+			label = "green";
+
+			led-max-microamp = <5000>;
+		};
+
+		led@2 {
+			compatible = "ti,lm3533-led";
+			reg = <2>;
+			label = "blue";
+
+			led-max-microamp = <5000>;
+		};
+	};
+
-- 
2.11.0

[PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Bjorn Andersson]

From: Bjorn Andersson <bjorn.andersson@sonymobile.com>

Implement support for initialization of the lm3533 driver core and
probing child devices from Device Tree.

Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

Changes since v3:
- Moved parsing of child of nodes into each child driver
- Use of_platform_populate() to instanciate child devices

 drivers/mfd/lm3533-core.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
index 5abcbb2e8849..f147677f05ff 100644
--- a/drivers/mfd/lm3533-core.c
+++ b/drivers/mfd/lm3533-core.c
@@ -18,6 +18,8 @@
 #include <linux/gpio.h>
 #include <linux/i2c.h>
 #include <linux/mfd/core.h>
+#include <linux/of_gpio.h>
+#include <linux/of_platform.h>
 #include <linux/regmap.h>
 #include <linux/seq_file.h>
 #include <linux/slab.h>
@@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
 	lm3533_device_bl_init(lm3533);
 	lm3533_device_led_init(lm3533);
 
+	if (lm3533->dev->of_node) {
+		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
+				     lm3533->dev);
+	}
+
 	ret = sysfs_create_group(&lm3533->dev->kobj, &lm3533_attribute_group);
 	if (ret < 0) {
 		dev_err(lm3533->dev, "failed to create sysfs attributes\n");
@@ -588,10 +595,73 @@ static const struct regmap_config regmap_config = {
 	.precious_reg	= lm3533_precious_register,
 };
 
+static int lm3533_of_parse_enum(struct device *dev, const char *propname,
+				const unsigned int *match, size_t num_matches)
+{
+	size_t i;
+	int ret;
+	u32 val;
+
+	ret = of_property_read_u32(dev->of_node, propname, &val);
+	if (ret < 0) {
+		dev_err(dev, "failed to parse %s\n", propname);
+		return ret;
+	}
+
+	for (i = 0; i < num_matches; i++) {
+		if (val == match[i])
+			return i;
+	}
+
+	dev_err(dev, "unsupported value of %s\n", propname);
+	return -EINVAL;
+}
+
+static int lm3533_pdata_from_of_node(struct device *dev)
+{
+	struct lm3533_platform_data *pdata;
+	int ret;
+	const unsigned int freqs[] = {
+		[LM3533_BOOST_FREQ_500KHZ] = 500000,
+		[LM3533_BOOST_FREQ_1000KHZ] = 1000000,
+	};
+	const unsigned int ovps[] = {
+		[LM3533_BOOST_OVP_16V] = 16000,
+		[LM3533_BOOST_OVP_24V] = 24000,
+		[LM3533_BOOST_OVP_32V] = 32000,
+		[LM3533_BOOST_OVP_40V] = 40000,
+	};
+
+	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		return -ENOMEM;
+
+	pdata->gpio_hwen = of_get_named_gpio(dev->of_node, "hwen-gpios", 0);
+	if (pdata->gpio_hwen < 0)
+		return pdata->gpio_hwen;
+
+	ret = lm3533_of_parse_enum(dev, "ti,boost-freq-hz",
+				   freqs, ARRAY_SIZE(freqs));
+	if (ret < 0)
+		return ret;
+	pdata->boost_freq = ret;
+
+	ret = lm3533_of_parse_enum(dev, "ti,boost-ovp-mv",
+				   ovps, ARRAY_SIZE(ovps));
+	if (ret < 0)
+		return ret;
+	pdata->boost_ovp = ret;
+
+	dev->platform_data = pdata;
+
+	return 0;
+}
+
 static int lm3533_i2c_probe(struct i2c_client *i2c,
 					const struct i2c_device_id *id)
 {
 	struct lm3533 *lm3533;
+	int ret;
 
 	dev_dbg(&i2c->dev, "%s\n", __func__);
 
@@ -608,6 +678,12 @@ static int lm3533_i2c_probe(struct i2c_client *i2c,
 	lm3533->dev = &i2c->dev;
 	lm3533->irq = i2c->irq;
 
+	if (i2c->dev.of_node) {
+		ret = lm3533_pdata_from_of_node(lm3533->dev);
+		if (ret < 0)
+			return ret;
+	}
+
 	return lm3533_device_init(lm3533);
 }
 
-- 
2.11.0

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Lee Jones]

On Mon, 26 Dec 2016, Bjorn Andersson wrote:

> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> 
> Implement support for initialization of the lm3533 driver core and
> probing child devices from Device Tree.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> Changes since v3:
> - Moved parsing of child of nodes into each child driver
> - Use of_platform_populate() to instanciate child devices
> 
>  drivers/mfd/lm3533-core.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 76 insertions(+)
> 
> diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
> index 5abcbb2e8849..f147677f05ff 100644
> --- a/drivers/mfd/lm3533-core.c
> +++ b/drivers/mfd/lm3533-core.c
> @@ -18,6 +18,8 @@
>  #include <linux/gpio.h>
>  #include <linux/i2c.h>
>  #include <linux/mfd/core.h>
> +#include <linux/of_gpio.h>
> +#include <linux/of_platform.h>
>  #include <linux/regmap.h>
>  #include <linux/seq_file.h>
>  #include <linux/slab.h>
> @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
>  	lm3533_device_bl_init(lm3533);
>  	lm3533_device_led_init(lm3533);
>  
> +	if (lm3533->dev->of_node) {
> +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> +				     lm3533->dev);
> +	}

I think it's save to call of_platform_populate(), even if !of_node.
It will just fail and return an error code, which you are ignoring
anyway.

>  	ret = sysfs_create_group(&lm3533->dev->kobj, &lm3533_attribute_group);
>  	if (ret < 0) {
>  		dev_err(lm3533->dev, "failed to create sysfs attributes\n");
> @@ -588,10 +595,73 @@ static const struct regmap_config regmap_config = {
>  	.precious_reg	= lm3533_precious_register,
>  };
>  
> +static int lm3533_of_parse_enum(struct device *dev, const char *propname,
> +				const unsigned int *match, size_t num_matches)
> +{
> +	size_t i;
> +	int ret;
> +	u32 val;
> +
> +	ret = of_property_read_u32(dev->of_node, propname, &val);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to parse %s\n", propname);
> +		return ret;
> +	}
> +
> +	for (i = 0; i < num_matches; i++) {
> +		if (val == match[i])
> +			return i;
> +	}
> +
> +	dev_err(dev, "unsupported value of %s\n", propname);
> +	return -EINVAL;
> +}
> +
> +static int lm3533_pdata_from_of_node(struct device *dev)
> +{
> +	struct lm3533_platform_data *pdata;
> +	int ret;
> +	const unsigned int freqs[] = {
> +		[LM3533_BOOST_FREQ_500KHZ] = 500000,
> +		[LM3533_BOOST_FREQ_1000KHZ] = 1000000,
> +	};
> +	const unsigned int ovps[] = {
> +		[LM3533_BOOST_OVP_16V] = 16000,
> +		[LM3533_BOOST_OVP_24V] = 24000,
> +		[LM3533_BOOST_OVP_32V] = 32000,
> +		[LM3533_BOOST_OVP_40V] = 40000,
> +	};
> +
> +	pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> +	if (!pdata)
> +		return -ENOMEM;
> +
> +	pdata->gpio_hwen = of_get_named_gpio(dev->of_node, "hwen-gpios", 0);
> +	if (pdata->gpio_hwen < 0)
> +		return pdata->gpio_hwen;
> +
> +	ret = lm3533_of_parse_enum(dev, "ti,boost-freq-hz",
> +				   freqs, ARRAY_SIZE(freqs));
> +	if (ret < 0)
> +		return ret;
> +	pdata->boost_freq = ret;
> +
> +	ret = lm3533_of_parse_enum(dev, "ti,boost-ovp-mv",
> +				   ovps, ARRAY_SIZE(ovps));
> +	if (ret < 0)
> +		return ret;
> +	pdata->boost_ovp = ret;
> +
> +	dev->platform_data = pdata;
> +
> +	return 0;
> +}
> +
>  static int lm3533_i2c_probe(struct i2c_client *i2c,
>  					const struct i2c_device_id *id)
>  {
>  	struct lm3533 *lm3533;
> +	int ret;
>  
>  	dev_dbg(&i2c->dev, "%s\n", __func__);
>  
> @@ -608,6 +678,12 @@ static int lm3533_i2c_probe(struct i2c_client *i2c,
>  	lm3533->dev = &i2c->dev;
>  	lm3533->irq = i2c->irq;
>  
> +	if (i2c->dev.of_node) {

I'd prefer this check to be placed in lm3533_pdata_from_of_node().

Just return silently if !dev->of_node.

> +		ret = lm3533_pdata_from_of_node(lm3533->dev);
> +		if (ret < 0)
> +			return ret;
> +	}
> +
>  	return lm3533_device_init(lm3533);
>  }
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Bjorn Andersson]

On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:

> On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> 
> > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > 
> > Implement support for initialization of the lm3533 driver core and
> > probing child devices from Device Tree.
> > 

[..]

> > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> >  	lm3533_device_bl_init(lm3533);
> >  	lm3533_device_led_init(lm3533);
> >  
> > +	if (lm3533->dev->of_node) {
> > +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > +				     lm3533->dev);
> > +	}
> 
> I think it's save to call of_platform_populate(), even if !of_node.
> It will just fail and return an error code, which you are ignoring
> anyway.
> 

I thought so too, but that's apparently how you trigger probing children
of the root node. So we're stuck with a conditional.

[..]

> >  static int lm3533_i2c_probe(struct i2c_client *i2c,
> >  					const struct i2c_device_id *id)
> >  {

[..]

> >  
> > +	if (i2c->dev.of_node) {
> 
> I'd prefer this check to be placed in lm3533_pdata_from_of_node().
> 
> Just return silently if !dev->of_node.
> 

I agree, will update this.

> > +		ret = lm3533_pdata_from_of_node(lm3533->dev);
> > +		if (ret < 0)
> > +			return ret;
> > +	}
> > +
> >  	return lm3533_device_init(lm3533);
> >  }
> >  

Regards,
Bjorn

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Lee Jones]

On Wed, 04 Jan 2017, Bjorn Andersson wrote:

> On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> 
> > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > 
> > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > 
> > > Implement support for initialization of the lm3533 driver core and
> > > probing child devices from Device Tree.
> > > 
> 
> [..]
> 
> > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > >  	lm3533_device_bl_init(lm3533);
> > >  	lm3533_device_led_init(lm3533);
> > >  
> > > +	if (lm3533->dev->of_node) {
> > > +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > +				     lm3533->dev);
> > > +	}
> > 
> > I think it's save to call of_platform_populate(), even if !of_node.
> > It will just fail and return an error code, which you are ignoring
> > anyway.
> > 
> 
> I thought so too, but that's apparently how you trigger probing children
> of the root node. So we're stuck with a conditional.

Ah, so this is to protect against the case where DT is present, but a
node for this device is not (or is disabled), so is left unprobed.
Then the bind is initiated via I2C?  Or something else?

> > >  static int lm3533_i2c_probe(struct i2c_client *i2c,
> > >  					const struct i2c_device_id *id)
> > >  {
> 
> [..]
> 
> > >  
> > > +	if (i2c->dev.of_node) {
> > 
> > I'd prefer this check to be placed in lm3533_pdata_from_of_node().
> > 
> > Just return silently if !dev->of_node.
> > 
> 
> I agree, will update this.
> 
> > > +		ret = lm3533_pdata_from_of_node(lm3533->dev);
> > > +		if (ret < 0)
> > > +			return ret;
> > > +	}
> > > +
> > >  	return lm3533_device_init(lm3533);
> > >  }
> > >  
> 
> Regards,
> Bjorn

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Bjorn Andersson]

On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:

> On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> 
> > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > 
> > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > 
> > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > 
> > > > Implement support for initialization of the lm3533 driver core and
> > > > probing child devices from Device Tree.
> > > > 
> > 
> > [..]
> > 
> > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > >  	lm3533_device_bl_init(lm3533);
> > > >  	lm3533_device_led_init(lm3533);
> > > >  
> > > > +	if (lm3533->dev->of_node) {
> > > > +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > +				     lm3533->dev);
> > > > +	}
> > > 
> > > I think it's save to call of_platform_populate(), even if !of_node.
> > > It will just fail and return an error code, which you are ignoring
> > > anyway.
> > > 
> > 
> > I thought so too, but that's apparently how you trigger probing children
> > of the root node. So we're stuck with a conditional.
> 
> Ah, so this is to protect against the case where DT is present, but a
> node for this device is not (or is disabled), so is left unprobed.
> Then the bind is initiated via I2C?  Or something else?
> 

In the event that a new lm3533 is spawned from sysfs we would not have
platform_data when entering lm3533_device_init() and just bail early.

Therefor, this issue would be limited to the odd case of lm3533 being
initiated from code (e.g. a board file) on a DT enabled system. In which
case it will create and probe new devices from the root of the DT.

Regards,
Bjorn

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Lee Jones]

On Thu, 05 Jan 2017, Bjorn Andersson wrote:

> On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> 
> > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> > 
> > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > > 
> > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > > 
> > > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > > 
> > > > > Implement support for initialization of the lm3533 driver core and
> > > > > probing child devices from Device Tree.
> > > > > 
> > > 
> > > [..]
> > > 
> > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > >  	lm3533_device_bl_init(lm3533);
> > > > >  	lm3533_device_led_init(lm3533);
> > > > >  
> > > > > +	if (lm3533->dev->of_node) {
> > > > > +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > +				     lm3533->dev);
> > > > > +	}
> > > > 
> > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > It will just fail and return an error code, which you are ignoring
> > > > anyway.
> > > > 
> > > 
> > > I thought so too, but that's apparently how you trigger probing children
> > > of the root node. So we're stuck with a conditional.
> > 
> > Ah, so this is to protect against the case where DT is present, but a
> > node for this device is not (or is disabled), so is left unprobed.
> > Then the bind is initiated via I2C?  Or something else?
> > 
> 
> In the event that a new lm3533 is spawned from sysfs we would not have
> platform_data when entering lm3533_device_init() and just bail early.
> 
> Therefor, this issue would be limited to the odd case of lm3533 being
> initiated from code (e.g. a board file) on a DT enabled system. In which
> case it will create and probe new devices from the root of the DT.

Eewww, do we really want to support that?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Bjorn Andersson]

On Fri 06 Jan 01:53 PST 2017, Lee Jones wrote:

> On Thu, 05 Jan 2017, Bjorn Andersson wrote:
> 
> > On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> > 
> > > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> > > 
> > > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > > > 
> > > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > > > 
> > > > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > > > 
> > > > > > Implement support for initialization of the lm3533 driver core and
> > > > > > probing child devices from Device Tree.
> > > > > > 
> > > > 
> > > > [..]
> > > > 
> > > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > > >  	lm3533_device_bl_init(lm3533);
> > > > > >  	lm3533_device_led_init(lm3533);
> > > > > >  
> > > > > > +	if (lm3533->dev->of_node) {
> > > > > > +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > > +				     lm3533->dev);
> > > > > > +	}
> > > > > 
> > > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > > It will just fail and return an error code, which you are ignoring
> > > > > anyway.
> > > > > 
> > > > 
> > > > I thought so too, but that's apparently how you trigger probing children
> > > > of the root node. So we're stuck with a conditional.
> > > 
> > > Ah, so this is to protect against the case where DT is present, but a
> > > node for this device is not (or is disabled), so is left unprobed.
> > > Then the bind is initiated via I2C?  Or something else?
> > > 
> > 
> > In the event that a new lm3533 is spawned from sysfs we would not have
> > platform_data when entering lm3533_device_init() and just bail early.
> > 
> > Therefor, this issue would be limited to the odd case of lm3533 being
> > initiated from code (e.g. a board file) on a DT enabled system. In which
> > case it will create and probe new devices from the root of the DT.
> 
> Eewww, do we really want to support that?
> 

As long as we support non-DT probing of the driver this is a possible
scenario. And with modern ARM being DT-centric I think that if anyone
uses this driver with a modern version of the Linux kernel it's likely
that they would have this kind of hybrid solution.

So, although ugly, I think we should keep this conditional and hope that
anyone using the driver will transition to use the DT binding.

Regards,
Bjorn

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Lee Jones]

On Fri, 06 Jan 2017, Bjorn Andersson wrote:

> On Fri 06 Jan 01:53 PST 2017, Lee Jones wrote:
> 
> > On Thu, 05 Jan 2017, Bjorn Andersson wrote:
> > 
> > > On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> > > 
> > > > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> > > > 
> > > > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > > > > 
> > > > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > > > > 
> > > > > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > > > > 
> > > > > > > Implement support for initialization of the lm3533 driver core and
> > > > > > > probing child devices from Device Tree.
> > > > > > > 
> > > > > 
> > > > > [..]
> > > > > 
> > > > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > > > >  	lm3533_device_bl_init(lm3533);
> > > > > > >  	lm3533_device_led_init(lm3533);
> > > > > > >  
> > > > > > > +	if (lm3533->dev->of_node) {
> > > > > > > +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > > > +				     lm3533->dev);
> > > > > > > +	}
> > > > > > 
> > > > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > > > It will just fail and return an error code, which you are ignoring
> > > > > > anyway.
> > > > > > 
> > > > > 
> > > > > I thought so too, but that's apparently how you trigger probing children
> > > > > of the root node. So we're stuck with a conditional.
> > > > 
> > > > Ah, so this is to protect against the case where DT is present, but a
> > > > node for this device is not (or is disabled), so is left unprobed.
> > > > Then the bind is initiated via I2C?  Or something else?
> > > > 
> > > 
> > > In the event that a new lm3533 is spawned from sysfs we would not have
> > > platform_data when entering lm3533_device_init() and just bail early.
> > > 
> > > Therefor, this issue would be limited to the odd case of lm3533 being
> > > initiated from code (e.g. a board file) on a DT enabled system. In which
> > > case it will create and probe new devices from the root of the DT.
> > 
> > Eewww, do we really want to support that?
> > 
> 
> As long as we support non-DT probing of the driver this is a possible
> scenario. And with modern ARM being DT-centric I think that if anyone
> uses this driver with a modern version of the Linux kernel it's likely
> that they would have this kind of hybrid solution.
> 
> So, although ugly, I think we should keep this conditional and hope that
> anyone using the driver will transition to use the DT binding.

Very well, but can you add a comment describing the reason for its
existence with a view to removing it further down the line?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 2/5] mfd: lm3533: Support initialization from Device Tree

[Bjorn Andersson]

On Mon 09 Jan 00:36 PST 2017, Lee Jones wrote:

> On Fri, 06 Jan 2017, Bjorn Andersson wrote:
> 
> > On Fri 06 Jan 01:53 PST 2017, Lee Jones wrote:
> > 
> > > On Thu, 05 Jan 2017, Bjorn Andersson wrote:
> > > 
> > > > On Wed 04 Jan 23:49 PST 2017, Lee Jones wrote:
> > > > 
> > > > > On Wed, 04 Jan 2017, Bjorn Andersson wrote:
> > > > > 
> > > > > > On Wed 04 Jan 03:54 PST 2017, Lee Jones wrote:
> > > > > > 
> > > > > > > On Mon, 26 Dec 2016, Bjorn Andersson wrote:
> > > > > > > 
> > > > > > > > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > > > > > > > 
> > > > > > > > Implement support for initialization of the lm3533 driver core and
> > > > > > > > probing child devices from Device Tree.
> > > > > > > > 
> > > > > > 
> > > > > > [..]
> > > > > > 
> > > > > > > > @@ -512,6 +514,11 @@ static int lm3533_device_init(struct lm3533 *lm3533)
> > > > > > > >  	lm3533_device_bl_init(lm3533);
> > > > > > > >  	lm3533_device_led_init(lm3533);
> > > > > > > >  
> > > > > > > > +	if (lm3533->dev->of_node) {
> > > > > > > > +		of_platform_populate(lm3533->dev->of_node, NULL, NULL,
> > > > > > > > +				     lm3533->dev);
> > > > > > > > +	}
> > > > > > > 
> > > > > > > I think it's save to call of_platform_populate(), even if !of_node.
> > > > > > > It will just fail and return an error code, which you are ignoring
> > > > > > > anyway.
> > > > > > > 
> > > > > > 
> > > > > > I thought so too, but that's apparently how you trigger probing children
> > > > > > of the root node. So we're stuck with a conditional.
> > > > > 
> > > > > Ah, so this is to protect against the case where DT is present, but a
> > > > > node for this device is not (or is disabled), so is left unprobed.
> > > > > Then the bind is initiated via I2C?  Or something else?
> > > > > 
> > > > 
> > > > In the event that a new lm3533 is spawned from sysfs we would not have
> > > > platform_data when entering lm3533_device_init() and just bail early.
> > > > 
> > > > Therefor, this issue would be limited to the odd case of lm3533 being
> > > > initiated from code (e.g. a board file) on a DT enabled system. In which
> > > > case it will create and probe new devices from the root of the DT.
> > > 
> > > Eewww, do we really want to support that?
> > > 
> > 
> > As long as we support non-DT probing of the driver this is a possible
> > scenario. And with modern ARM being DT-centric I think that if anyone
> > uses this driver with a modern version of the Linux kernel it's likely
> > that they would have this kind of hybrid solution.
> > 
> > So, although ugly, I think we should keep this conditional and hope that
> > anyone using the driver will transition to use the DT binding.
> 
> Very well, but can you add a comment describing the reason for its
> existence with a view to removing it further down the line?
> 

Sounds reasonable, I will prepare an updated patch with this.

Regards,
Bjorn

[PATCH v4 3/5] backlight: lm3533: Support initialization from Device Tree

[Bjorn Andersson]

From: Bjorn Andersson <bjorn.andersson@sonymobile.com>

Implement support for initialization of the lm3533 backlight from Device
Tree.

Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---

This patch only depends on the acceptance of the DT binding (doesn't have to be
merged together with the mfd patch).

Changes since v3:
- Moved backlight DT parsing from mfd driver
- Gave driver its own compatible

 drivers/video/backlight/lm3533_bl.c | 98 +++++++++++++++++++++++++++++++++++--
 1 file changed, 95 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index 0e2337f367b6..2f132199e604 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -22,6 +22,7 @@
 
 
 #define LM3533_HVCTRLBANK_COUNT		2
+#define LM3533_BL_DEFAULT_BRIGHTNESS	200
 #define LM3533_BL_MAX_BRIGHTNESS	255
 
 #define LM3533_REG_CTRLBANK_AB_BCONF	0x1a
@@ -269,6 +270,86 @@ static int lm3533_bl_setup(struct lm3533_bl *bl,
 	return lm3533_ctrlbank_set_pwm(&bl->cb, pdata->pwm);
 }
 
+static int lm3533_of_parse_pwm_zones(struct device_node *node)
+{
+	const char *propname = "ti,pwm-zones";
+	u32 zones[5];
+	int count;
+	int ret;
+	int i;
+
+	count = of_property_count_u32_elems(node, propname);
+	if (count == -EINVAL)
+		return 0;
+	if (count <= 0)
+		return count;
+	if (count >= ARRAY_SIZE(zones))
+		return -EINVAL;
+
+	ret = of_property_read_u32_array(node, propname, zones, count);
+	if (ret < 0)
+		return ret;
+
+	/* Enable pwm input, and enable the selected zones */
+	ret = BIT(0);
+	for (i = 0; i < count; i++)
+		ret |= BIT(zones[i] + 1);
+
+	return ret;
+}
+
+static struct lm3533_bl_platform_data *lm3533_bl_of_parse(struct device *dev,
+							  int *id)
+{
+	struct lm3533_bl_platform_data *bl_pdata;
+	struct device_node *node = dev->of_node;
+	int ret;
+	u32 reg;
+	u32 val;
+
+	bl_pdata = devm_kzalloc(dev, sizeof(*bl_pdata), GFP_KERNEL);
+	if (!bl_pdata)
+		return NULL;
+
+	ret = of_property_read_u32(node, "reg", &reg);
+	if (ret < 0) {
+		dev_err(dev, "invalid reg property\n");
+		return NULL;
+	}
+	*id = reg;
+
+	ret = of_property_read_string(node, "label",
+				      (const char **)&bl_pdata->name);
+	if (ret < 0) {
+		dev_err(dev, "unable to parse label\n");
+		return NULL;
+	}
+
+	ret = of_property_read_u32(node, "led-max-microamp", &val);
+	if (ret < 0) {
+		dev_err(dev, "unable to parse led-max-microamp\n");
+		return NULL;
+	}
+	bl_pdata->max_current = val;
+
+	val = LM3533_BL_DEFAULT_BRIGHTNESS;
+	ret = of_property_read_u32(node, "default-brightness", &val);
+	if (ret < 0 && ret != -EINVAL) {
+		dev_err(dev, "unable to parse default-brightness\n");
+		return NULL;
+	}
+	bl_pdata->default_brightness = val;
+
+	ret = lm3533_of_parse_pwm_zones(node);
+	if (ret < 0) {
+		dev_err(dev, "failed to parse ti,pwm-zones\n");
+		return NULL;
+	}
+	bl_pdata->pwm = ret;
+
+	return bl_pdata;
+}
+
 static int lm3533_bl_probe(struct platform_device *pdev)
 {
 	struct lm3533 *lm3533;
@@ -277,6 +358,7 @@ static int lm3533_bl_probe(struct platform_device *pdev)
 	struct backlight_device *bd;
 	struct backlight_properties props;
 	int ret;
+	int id;
 
 	dev_dbg(&pdev->dev, "%s\n", __func__);
 
@@ -284,14 +366,17 @@ static int lm3533_bl_probe(struct platform_device *pdev)
 	if (!lm3533)
 		return -EINVAL;
 
+	id = pdev->id;
 	pdata = dev_get_platdata(&pdev->dev);
+	if (!pdata)
+		pdata = lm3533_bl_of_parse(&pdev->dev, &id);
 	if (!pdata) {
 		dev_err(&pdev->dev, "no platform data\n");
 		return -EINVAL;
 	}
 
-	if (pdev->id < 0 || pdev->id >= LM3533_HVCTRLBANK_COUNT) {
-		dev_err(&pdev->dev, "illegal backlight id %d\n", pdev->id);
+	if (id < 0 || id >= LM3533_HVCTRLBANK_COUNT) {
+		dev_err(&pdev->dev, "illegal backlight id %d\n", id);
 		return -EINVAL;
 	}
 
@@ -300,7 +385,7 @@ static int lm3533_bl_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	bl->lm3533 = lm3533;
-	bl->id = pdev->id;
+	bl->id = id;
 
 	bl->cb.lm3533 = lm3533;
 	bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
@@ -394,10 +479,17 @@ static void lm3533_bl_shutdown(struct platform_device *pdev)
 	lm3533_ctrlbank_disable(&bl->cb);
 }
 
+static const struct of_device_id lm3533_bl_of_match[] = {
+	{ .compatible = "ti,lm3533-backlight", },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, lm3533_bl_of_match);
+
 static struct platform_driver lm3533_bl_driver = {
 	.driver = {
 		.name	= "lm3533-backlight",
 		.pm	= &lm3533_bl_pm_ops,
+		.of_match_table = lm3533_bl_of_match,
 	},
 	.probe		= lm3533_bl_probe,
 	.remove		= lm3533_bl_remove,
-- 
2.11.0

Re: [PATCH v4 3/5] backlight: lm3533: Support initialization from Device Tree

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

On Mon 2016-12-26 10:11:51, Bjorn Andersson wrote:
> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> 
> Implement support for initialization of the lm3533 backlight from Device
> Tree.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Acked-by: Pavel Machek <pavel@ucw.cz>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v4 3/5] backlight: lm3533: Support initialization from Device Tree

[Jingoo Han]

On Tuesday, December 27, 2016 5:47 AM, Pavel Machek wrote:
> 
> On Mon 2016-12-26 10:11:51, Bjorn Andersson wrote:
> > From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> >
> > Implement support for initialization of the lm3533 backlight from Device
> > Tree.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>

Acked-by: Jingoo Han <jingoohan1@gmail.com>

Best regards,
Jingoo Han

> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH v4 3/5] backlight: lm3533: Support initialization from Device Tree

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 5603 bytes --]

On Mon 2016-12-26 10:11:51, Bjorn Andersson wrote:
> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> 
> Implement support for initialization of the lm3533 backlight from Device
> Tree.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Bjorn, you may want to fix your email system:

<bjorn.andersson@sonymobile.com>: host
    seldsegrel01.sonyericsson.com[37.139.156.29] said: 550 Rule
    imposed mailbox
        access for this user is refused: user invalid (in reply to
    RCPT TO command)


									Pavel
> ---
> 
> This patch only depends on the acceptance of the DT binding (doesn't have to be
> merged together with the mfd patch).
> 
> Changes since v3:
> - Moved backlight DT parsing from mfd driver
> - Gave driver its own compatible
> 
>  drivers/video/backlight/lm3533_bl.c | 98 +++++++++++++++++++++++++++++++++++--
>  1 file changed, 95 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> index 0e2337f367b6..2f132199e604 100644
> --- a/drivers/video/backlight/lm3533_bl.c
> +++ b/drivers/video/backlight/lm3533_bl.c
> @@ -22,6 +22,7 @@
>  
>  
>  #define LM3533_HVCTRLBANK_COUNT		2
> +#define LM3533_BL_DEFAULT_BRIGHTNESS	200
>  #define LM3533_BL_MAX_BRIGHTNESS	255
>  
>  #define LM3533_REG_CTRLBANK_AB_BCONF	0x1a
> @@ -269,6 +270,86 @@ static int lm3533_bl_setup(struct lm3533_bl *bl,
>  	return lm3533_ctrlbank_set_pwm(&bl->cb, pdata->pwm);
>  }
>  
> +static int lm3533_of_parse_pwm_zones(struct device_node *node)
> +{
> +	const char *propname = "ti,pwm-zones";
> +	u32 zones[5];
> +	int count;
> +	int ret;
> +	int i;
> +
> +	count = of_property_count_u32_elems(node, propname);
> +	if (count == -EINVAL)
> +		return 0;
> +	if (count <= 0)
> +		return count;
> +	if (count >= ARRAY_SIZE(zones))
> +		return -EINVAL;
> +
> +	ret = of_property_read_u32_array(node, propname, zones, count);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Enable pwm input, and enable the selected zones */
> +	ret = BIT(0);
> +	for (i = 0; i < count; i++)
> +		ret |= BIT(zones[i] + 1);
> +
> +	return ret;
> +}
> +
> +static struct lm3533_bl_platform_data *lm3533_bl_of_parse(struct device *dev,
> +							  int *id)
> +{
> +	struct lm3533_bl_platform_data *bl_pdata;
> +	struct device_node *node = dev->of_node;
> +	int ret;
> +	u32 reg;
> +	u32 val;
> +
> +	bl_pdata = devm_kzalloc(dev, sizeof(*bl_pdata), GFP_KERNEL);
> +	if (!bl_pdata)
> +		return NULL;
> +
> +	ret = of_property_read_u32(node, "reg", &reg);
> +	if (ret < 0) {
> +		dev_err(dev, "invalid reg property\n");
> +		return NULL;
> +	}
> +	*id = reg;
> +
> +	ret = of_property_read_string(node, "label",
> +				      (const char **)&bl_pdata->name);
> +	if (ret < 0) {
> +		dev_err(dev, "unable to parse label\n");
> +		return NULL;
> +	}
> +
> +	ret = of_property_read_u32(node, "led-max-microamp", &val);
> +	if (ret < 0) {
> +		dev_err(dev, "unable to parse led-max-microamp\n");
> +		return NULL;
> +	}
> +	bl_pdata->max_current = val;
> +
> +	val = LM3533_BL_DEFAULT_BRIGHTNESS;
> +	ret = of_property_read_u32(node, "default-brightness", &val);
> +	if (ret < 0 && ret != -EINVAL) {
> +		dev_err(dev, "unable to parse default-brightness\n");
> +		return NULL;
> +	}
> +	bl_pdata->default_brightness = val;
> +
> +	ret = lm3533_of_parse_pwm_zones(node);
> +	if (ret < 0) {
> +		dev_err(dev, "failed to parse ti,pwm-zones\n");
> +		return NULL;
> +	}
> +	bl_pdata->pwm = ret;
> +
> +	return bl_pdata;
> +}
> +
>  static int lm3533_bl_probe(struct platform_device *pdev)
>  {
>  	struct lm3533 *lm3533;
> @@ -277,6 +358,7 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>  	struct backlight_device *bd;
>  	struct backlight_properties props;
>  	int ret;
> +	int id;
>  
>  	dev_dbg(&pdev->dev, "%s\n", __func__);
>  
> @@ -284,14 +366,17 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>  	if (!lm3533)
>  		return -EINVAL;
>  
> +	id = pdev->id;
>  	pdata = dev_get_platdata(&pdev->dev);
> +	if (!pdata)
> +		pdata = lm3533_bl_of_parse(&pdev->dev, &id);
>  	if (!pdata) {
>  		dev_err(&pdev->dev, "no platform data\n");
>  		return -EINVAL;
>  	}
>  
> -	if (pdev->id < 0 || pdev->id >= LM3533_HVCTRLBANK_COUNT) {
> -		dev_err(&pdev->dev, "illegal backlight id %d\n", pdev->id);
> +	if (id < 0 || id >= LM3533_HVCTRLBANK_COUNT) {
> +		dev_err(&pdev->dev, "illegal backlight id %d\n", id);
>  		return -EINVAL;
>  	}
>  
> @@ -300,7 +385,7 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>  		return -ENOMEM;
>  
>  	bl->lm3533 = lm3533;
> -	bl->id = pdev->id;
> +	bl->id = id;
>  
>  	bl->cb.lm3533 = lm3533;
>  	bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
> @@ -394,10 +479,17 @@ static void lm3533_bl_shutdown(struct platform_device *pdev)
>  	lm3533_ctrlbank_disable(&bl->cb);
>  }
>  
> +static const struct of_device_id lm3533_bl_of_match[] = {
> +	{ .compatible = "ti,lm3533-backlight", },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, lm3533_bl_of_match);
> +
>  static struct platform_driver lm3533_bl_driver = {
>  	.driver = {
>  		.name	= "lm3533-backlight",
>  		.pm	= &lm3533_bl_pm_ops,
> +		.of_match_table = lm3533_bl_of_match,
>  	},
>  	.probe		= lm3533_bl_probe,
>  	.remove		= lm3533_bl_remove,

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v4 1/5] devicetree: mfd: Add binding for the TI LM3533

[Jonathan Cameron]

On 26/12/16 18:11, Bjorn Andersson wrote:
> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> 
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> I had Acks from Jonathan and Rob on v3, but dropped these due to the added
> compatible properties.
Looks sensible to me

Acked-by: Jonathan Cameron <jic23@kernel.org>
> 
> Changes since v3:
> - Added compatible to sub-nodes, per Lee's requested to treat them as separate
>   pieces.
> 
>  Documentation/devicetree/bindings/mfd/lm3533.txt | 205 +++++++++++++++++++++++
>  1 file changed, 205 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..909281096ba2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,205 @@
> +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
> +
> +- als-supply:
> +	Usage: optional
> +	Value type: <prop-encoded-array>
> +	Definition: reference to regulator powering the V_als input; as
> +		    specified in "../regulator/regulator.txt"
> +
> +- 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,boost-freq-hz:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: switch-frequency of the boost converter, must be either:
> +		    500000 or 1000000
> +
> +- ti,boost-ovp-mv:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: over-voltage protection limit, in mV. Must be one of:
> +		    16000, 24000, 32000 or 40000
> +
> +- #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 ambient light sensor subnode carrying the light sensor related properties.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "ti,lm3533-als"
> +
> +- 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 200000 to 1574 Ohm.
> +
> +- 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 carrying the backlight related properties.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "ti,lm3533-backlight"
> +
> +- 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 carrying the LED related properties.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "ti,lm3533-led"
> +
> +- 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>;
> +
> +		als-supply = <&pm8921_l11>;
> +		hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> +
> +		ti,boost-freq-hz = <500000>;
> +		ti,boost-ovp-mv = <24000>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		als {
> +			compatible = "ti,lm3533-als";
> +			ti,als-resistance-ohm = <200000>;
> +		};
> +
> +		backlight@0 {
> +			compatible = "ti,lm3533-backlight";
> +			reg = <0>;
> +			label = "backlight";
> +
> +			led-max-microamp = <20200>;
> +		};
> +
> +		led@0 {
> +			compatible = "ti,lm3533-led";
> +			reg = <0>;
> +			label = "red";
> +
> +			led-max-microamp = <5000>;
> +		};
> +
> +		led@1 {
> +			compatible = "ti,lm3533-led";
> +			reg = <1>;
> +			label = "green";
> +
> +			led-max-microamp = <5000>;
> +		};
> +
> +		led@2 {
> +			compatible = "ti,lm3533-led";
> +			reg = <2>;
> +			label = "blue";
> +
> +			led-max-microamp = <5000>;
> +		};
> +	};
> +
> 

Re: [PATCH v4 1/5] devicetree: mfd: Add binding for the TI LM3533

[Rob Herring]

On Mon, Dec 26, 2016 at 10:11:49AM -0800, Bjorn Andersson wrote:
> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> 
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> 
> I had Acks from Jonathan and Rob on v3, but dropped these due to the added
> compatible properties.
> 
> Changes since v3:
> - Added compatible to sub-nodes, per Lee's requested to treat them as separate
>   pieces.

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v4 1/5] devicetree: mfd: Add binding for the TI LM3533

[Lee Jones]

On Mon, 26 Dec 2016, Bjorn Andersson wrote:

> From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> 
> Add the binding for the Texas Instruments LM3533 lighting power
> solution.
> 
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>

For my own reference:
  Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>

> ---
> 
> I had Acks from Jonathan and Rob on v3, but dropped these due to the added
> compatible properties.
> 
> Changes since v3:
> - Added compatible to sub-nodes, per Lee's requested to treat them as separate
>   pieces.
> 
>  Documentation/devicetree/bindings/mfd/lm3533.txt | 205 +++++++++++++++++++++++
>  1 file changed, 205 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..909281096ba2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
> @@ -0,0 +1,205 @@
> +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
> +
> +- als-supply:
> +	Usage: optional
> +	Value type: <prop-encoded-array>
> +	Definition: reference to regulator powering the V_als input; as
> +		    specified in "../regulator/regulator.txt"
> +
> +- 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,boost-freq-hz:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: switch-frequency of the boost converter, must be either:
> +		    500000 or 1000000
> +
> +- ti,boost-ovp-mv:
> +	Usage: required
> +	Value type: <u32>
> +	Definition: over-voltage protection limit, in mV. Must be one of:
> +		    16000, 24000, 32000 or 40000
> +
> +- #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 ambient light sensor subnode carrying the light sensor related properties.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "ti,lm3533-als"
> +
> +- 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 200000 to 1574 Ohm.
> +
> +- 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 carrying the backlight related properties.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "ti,lm3533-backlight"
> +
> +- 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 carrying the LED related properties.
> +
> +- compatible:
> +	Usage: required
> +	Value type: <stringlist>
> +	Definition: must be:
> +		    "ti,lm3533-led"
> +
> +- 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>;
> +
> +		als-supply = <&pm8921_l11>;
> +		hwen-gpios = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> +
> +		ti,boost-freq-hz = <500000>;
> +		ti,boost-ovp-mv = <24000>;
> +
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		als {
> +			compatible = "ti,lm3533-als";
> +			ti,als-resistance-ohm = <200000>;
> +		};
> +
> +		backlight@0 {
> +			compatible = "ti,lm3533-backlight";
> +			reg = <0>;
> +			label = "backlight";
> +
> +			led-max-microamp = <20200>;
> +		};
> +
> +		led@0 {
> +			compatible = "ti,lm3533-led";
> +			reg = <0>;
> +			label = "red";
> +
> +			led-max-microamp = <5000>;
> +		};
> +
> +		led@1 {
> +			compatible = "ti,lm3533-led";
> +			reg = <1>;
> +			label = "green";
> +
> +			led-max-microamp = <5000>;
> +		};
> +
> +		led@2 {
> +			compatible = "ti,lm3533-led";
> +			reg = <2>;
> +			label = "blue";
> +
> +			led-max-microamp = <5000>;
> +		};
> +	};
> +

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog