Message ID | 20161226181153.11271-1-bjorn.andersson@linaro.org |
---|---|
State | Not Applicable, archived |
Headers | show |
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>
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", ®); > + 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,
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 -- 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
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>; > + }; > + }; > + > -- 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
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> -- 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
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); > } >
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>; > + }; > + }; > +
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 -- 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
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
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 -- 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
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?
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
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?
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 -- 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 --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>; + }; + }; +