diff mbox

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

Message ID 20161226181153.11271-1-bjorn.andersson@linaro.org
State New
Headers show

Commit Message

Bjorn Andersson Dec. 26, 2016, 6:11 p.m. UTC
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

-- 
2.11.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Pavel Machek Dec. 27, 2016, 10:46 a.m. UTC | #1
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
Lee Jones Jan. 4, 2017, 11:54 a.m. UTC | #2
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Bjorn Andersson Jan. 6, 2017, 6:54 p.m. UTC | #3
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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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>;
+		};
+	};
+