[PATCH v4 0/2] tps6105x add devicetree and leds support

[PATCH v4 0/2] tps6105x add devicetree and leds support

[Sven Van Asbroeck]

v3 -> v4:
	Removed tps6105 mfd patch - it was accepted (Mark Brown).
	
	Use the new LED registration API - suggested by Jacek Anaszewski.
	
	Updated led dt bindings to document function, color usage.

v2 -> v3:
	Removed tps6105x regulator patch - it was accepted (Mark Brown).
	
	Removed devicetree/platdata bindings for tps6105x led naming.
	I can test only with a 4.19 vendor kernel, which does not have the
	latest led naming infrastructure (function/color). Drop devicetree/
	fwnode/pdata led naming in favour of hard-coding to "tps6105x::torch",
	so the patch can be tested by me, yet remains acceptable to upstream.

v1 -> v2:
	Select chip operational mode by looking at subnode name, _not_ its
	compatible property. Suggested by Mark Brown.

I needed led operation for this mfd chip, so I added a very simple
driver for this.

My platform (arm imx6q) is devicetree-based, so I added optional
devicetree support for this chip and its sub-drivers.

Sven Van Asbroeck (2):
  leds: tps6105x: add driver for mfd chip led mode
  dt-bindings: mfd: update TI tps6105x chip bindings

 .../devicetree/bindings/mfd/tps6105x.txt      | 47 ++++++++++-
 drivers/leds/Kconfig                          | 10 +++
 drivers/leds/Makefile                         |  1 +
 drivers/leds/leds-tps6105x.c                  | 83 +++++++++++++++++++
 4 files changed, 140 insertions(+), 1 deletion(-)
 create mode 100644 drivers/leds/leds-tps6105x.c

-- 
2.17.1

[PATCH v4 1/2] leds: tps6105x: add driver for mfd chip led mode

[Sven Van Asbroeck]

This driver adds support for the led operational mode of the
tps6105x mfd device.

Tree: next-20191118
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
---
 drivers/leds/Kconfig         | 10 +++++
 drivers/leds/Makefile        |  1 +
 drivers/leds/leds-tps6105x.c | 83 ++++++++++++++++++++++++++++++++++++
 3 files changed, 94 insertions(+)
 create mode 100644 drivers/leds/leds-tps6105x.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 4b68520ac251..7c7ceaa824a2 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -836,6 +836,16 @@ config LEDS_LM36274
 	  Say Y to enable the LM36274 LED driver for TI LMU devices.
 	  This supports the LED device LM36274.
 
+config LEDS_TPS6105X
+	tristate "LED support for TI TPS6105X"
+	depends on LEDS_CLASS
+	depends on TPS6105X
+	default y if TPS6105X
+	help
+	  This driver supports TPS61050/TPS61052 led chips.
+	  It is a single boost converter primarily for white LEDs and
+	  audio amplifiers.
+
 comment "LED Triggers"
 source "drivers/leds/trigger/Kconfig"
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 2da39e896ce8..d7e1107753fb 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_LEDS_LM3601X)		+= leds-lm3601x.o
 obj-$(CONFIG_LEDS_TI_LMU_COMMON)	+= leds-ti-lmu-common.o
 obj-$(CONFIG_LEDS_LM3697)		+= leds-lm3697.o
 obj-$(CONFIG_LEDS_LM36274)		+= leds-lm36274.o
+obj-$(CONFIG_LEDS_TPS6105X)		+= leds-tps6105x.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_CR0014114)		+= leds-cr0014114.o
diff --git a/drivers/leds/leds-tps6105x.c b/drivers/leds/leds-tps6105x.c
new file mode 100644
index 000000000000..ea2afaa3e3f0
--- /dev/null
+++ b/drivers/leds/leds-tps6105x.c
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/mfd/tps6105x.h>
+#include <linux/regmap.h>
+
+struct tps6105x_priv {
+	struct regmap *regmap;
+	struct led_classdev cdev;
+	struct fwnode_handle *fwnode;
+};
+
+static void tps6105x_handle_put(void *data)
+{
+	struct tps6105x_priv *priv = data;
+
+	fwnode_handle_put(priv->fwnode);
+}
+
+static int tps6105x_brightness_set(struct led_classdev *cdev,
+				  enum led_brightness brightness)
+{
+	struct tps6105x_priv *priv = container_of(cdev, struct tps6105x_priv,
+							cdev);
+
+	return regmap_update_bits(priv->regmap, TPS6105X_REG_0,
+		TPS6105X_REG0_TORCHC_MASK,
+		brightness << TPS6105X_REG0_TORCHC_SHIFT);
+}
+
+static int tps6105x_led_probe(struct platform_device *pdev)
+{
+	struct tps6105x *tps6105x = dev_get_platdata(&pdev->dev);
+	struct tps6105x_platform_data *pdata = tps6105x->pdata;
+	struct led_init_data init_data = { };
+	struct tps6105x_priv *priv;
+	int ret;
+
+	/* This instance is not set for torch mode so bail out */
+	if (pdata->mode != TPS6105X_MODE_TORCH) {
+		dev_info(&pdev->dev,
+			"chip not in torch mode, exit probe");
+		return -EINVAL;
+	}
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+	priv->fwnode = device_get_next_child_node(pdev->dev.parent, NULL);
+	ret = devm_add_action_or_reset(&pdev->dev, tps6105x_handle_put, priv);
+	if (ret)
+		return ret;
+	priv->regmap = tps6105x->regmap;
+	priv->cdev.brightness_set_blocking = tps6105x_brightness_set;
+	priv->cdev.max_brightness = 7;
+	init_data.devicename = "tps6105x";
+	init_data.default_label = ":torch";
+	init_data.fwnode = priv->fwnode;
+
+	ret = regmap_update_bits(tps6105x->regmap, TPS6105X_REG_0,
+		TPS6105X_REG0_MODE_MASK | TPS6105X_REG0_TORCHC_MASK,
+		TPS6105X_REG0_MODE_TORCH << TPS6105X_REG0_MODE_SHIFT);
+	if (ret)
+		return ret;
+
+	return devm_led_classdev_register_ext(&pdev->dev, &priv->cdev,
+					      &init_data);
+}
+
+static struct platform_driver led_driver = {
+	.probe = tps6105x_led_probe,
+	.driver = {
+		.name = "tps6105x-leds",
+	},
+};
+
+module_platform_driver(led_driver);
+
+MODULE_DESCRIPTION("TPS6105x led driver");
+MODULE_AUTHOR("Sven Van Asbroeck <TheSven73@gmail.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.17.1

[PATCH v4 2/2] dt-bindings: mfd: update TI tps6105x chip bindings

[Sven Van Asbroeck]

The driver has been extended to optionally get its operational
mode, regulator init data and led naming from the devicetree.

Tree: next-20191118
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
---
 .../devicetree/bindings/mfd/tps6105x.txt      | 47 ++++++++++++++++++-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt b/Documentation/devicetree/bindings/mfd/tps6105x.txt
index 93602c7a19c8..1fc9aa3ed882 100644
--- a/Documentation/devicetree/bindings/mfd/tps6105x.txt
+++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
@@ -7,11 +7,56 @@ Required properties:
 - compatible:		"ti,tps61050" or "ti,tps61052"
 - reg:			Specifies the I2C slave address
 
-Example:
+Optional sub-node:
+
+This subnode selects the chip's operational mode.
+There can be at most one single available subnode.
+
+- regulator: presence of this sub-node puts the chip in regulator mode.
+	see Documentation/devicetree/bindings/regulator/regulator.txt
+
+- led: presence of this sub-node puts the chip in led mode.
+	Optional properties:
+	- function : see Documentation/devicetree/bindings/leds/common.txt
+	- color : see Documentation/devicetree/bindings/leds/common.txt
+	- label : see Documentation/devicetree/bindings/leds/common.txt
+			(deprecated)
+
+Example (GPIO operation only):
+
+i2c0 {
+	tps61052@33 {
+		compatible = "ti,tps61052";
+		reg = <0x33>;
+	};
+};
+
+Example (GPIO + regulator operation):
 
 i2c0 {
 	tps61052@33 {
 		compatible = "ti,tps61052";
 		reg = <0x33>;
+
+		regulator {
+			regulator-min-microvolt = <5000000>;
+			regulator-max-microvolt = <5000000>;
+			regulator-always-on;
+		};
+	};
+};
+
+Example (GPIO + led operation):
+
+#include <dt-bindings/leds/common.h>
+
+i2c0 {
+	tps61052@33 {
+		compatible = "ti,tps61052";
+		reg = <0x33>;
+
+		led {
+			color = <LED_COLOR_ID_WHITE>;
+		};
 	};
 };
-- 
2.17.1

Re: [PATCH v4 0/2] tps6105x add devicetree and leds support

[Jacek Anaszewski]

Hi Sven,

Thank you for the updated set.

For both patches:

Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

Best regards,
Jacek Anaszewski

On 11/21/19 3:27 PM, Sven Van Asbroeck wrote:
> v3 -> v4:
> 	Removed tps6105 mfd patch - it was accepted (Mark Brown).
> 	
> 	Use the new LED registration API - suggested by Jacek Anaszewski.
> 	
> 	Updated led dt bindings to document function, color usage.
> 
> v2 -> v3:
> 	Removed tps6105x regulator patch - it was accepted (Mark Brown).
> 	
> 	Removed devicetree/platdata bindings for tps6105x led naming.
> 	I can test only with a 4.19 vendor kernel, which does not have the
> 	latest led naming infrastructure (function/color). Drop devicetree/
> 	fwnode/pdata led naming in favour of hard-coding to "tps6105x::torch",
> 	so the patch can be tested by me, yet remains acceptable to upstream.
> 
> v1 -> v2:
> 	Select chip operational mode by looking at subnode name, _not_ its
> 	compatible property. Suggested by Mark Brown.
> 
> I needed led operation for this mfd chip, so I added a very simple
> driver for this.
> 
> My platform (arm imx6q) is devicetree-based, so I added optional
> devicetree support for this chip and its sub-drivers.
> 
> Sven Van Asbroeck (2):
>   leds: tps6105x: add driver for mfd chip led mode
>   dt-bindings: mfd: update TI tps6105x chip bindings
> 
>  .../devicetree/bindings/mfd/tps6105x.txt      | 47 ++++++++++-
>  drivers/leds/Kconfig                          | 10 +++
>  drivers/leds/Makefile                         |  1 +
>  drivers/leds/leds-tps6105x.c                  | 83 +++++++++++++++++++
>  4 files changed, 140 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/leds/leds-tps6105x.c
> 

Re: [PATCH v4 0/2] tps6105x add devicetree and leds support

[Sven Van Asbroeck]

On Thu, Nov 21, 2019 at 1:20 PM Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
>
> For both patches:
>
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

Thank you Jacek. To get accepted in a maintainer tree, does this
patch need more acks/reviews?
Should I continue to include it in new patch set versions if it doesn't
change?

Re: [PATCH v4 0/2] tps6105x add devicetree and leds support

[Jacek Anaszewski]

On 11/22/19 2:36 PM, Sven Van Asbroeck wrote:
> On Thu, Nov 21, 2019 at 1:20 PM Jacek Anaszewski
> <jacek.anaszewski@gmail.com> wrote:
>>
>> For both patches:
>>
>> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> 
> Thank you Jacek. To get accepted in a maintainer tree, does this
> patch need more acks/reviews?

It should get ack from Pavel Machek since he now maintains LED tree.

I'd say that it should be merged in one batch with the related change
to the MFD driver, but this is to be agreed upon by Pavel and Lee, via
which tree it will go.

> Should I continue to include it in new patch set versions if it doesn't
> change?

You can include it, and add my ack.

However, you could remove also below lines, since you switched
to using color DT property and a new LED registration API:

-	init_data.devicename = "tps6105x";
-	init_data.default_label = ":torch";

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v4 2/2] dt-bindings: mfd: update TI tps6105x chip bindings

[Rob Herring]

On Thu, 21 Nov 2019 09:27:26 -0500, Sven Van Asbroeck wrote:
> The driver has been extended to optionally get its operational
> mode, regulator init data and led naming from the devicetree.
> 
> Tree: next-20191118
> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
> ---
>  .../devicetree/bindings/mfd/tps6105x.txt      | 47 ++++++++++++++++++-
>  1 file changed, 46 insertions(+), 1 deletion(-)
> 

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

Re: [PATCH v4 0/2] tps6105x add devicetree and leds support

[Sven Van Asbroeck]

Hi Pavel,

On Thu, Nov 21, 2019 at 1:20 PM Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
>
> For both patches:
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>

Is there anything I can do to help get these into your tree?
The other patches in the set have already been taken by their
respective maintainers.

Re: [PATCH v4 2/2] dt-bindings: mfd: update TI tps6105x chip bindings

[Lee Jones]

On Thu, 21 Nov 2019, Sven Van Asbroeck wrote:

> The driver has been extended to optionally get its operational
> mode, regulator init data and led naming from the devicetree.

s/led/LED/

> Tree: next-20191118

Why is this in your commit message?

> Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
> ---
>  .../devicetree/bindings/mfd/tps6105x.txt      | 47 ++++++++++++++++++-
>  1 file changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt b/Documentation/devicetree/bindings/mfd/tps6105x.txt
> index 93602c7a19c8..1fc9aa3ed882 100644
> --- a/Documentation/devicetree/bindings/mfd/tps6105x.txt
> +++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
> @@ -7,11 +7,56 @@ Required properties:
>  - compatible:		"ti,tps61050" or "ti,tps61052"
>  - reg:			Specifies the I2C slave address
>  
> -Example:
> +Optional sub-node:
> +
> +This subnode selects the chip's operational mode.
> +There can be at most one single available subnode.
> +
> +- regulator: presence of this sub-node puts the chip in regulator mode.
> +	see Documentation/devicetree/bindings/regulator/regulator.txt
> +
> +- led: presence of this sub-node puts the chip in led mode.
> +	Optional properties:
> +	- function : see Documentation/devicetree/bindings/leds/common.txt
> +	- color : see Documentation/devicetree/bindings/leds/common.txt
> +	- label : see Documentation/devicetree/bindings/leds/common.txt
> +			(deprecated)

Nit:

Could you please use relative paths here.

If you line up the ':', it would look slightly cleaner.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 2/2] dt-bindings: mfd: update TI tps6105x chip bindings

[Sven Van Asbroeck]

Hi Lee, thank you for the review.

On Mon, Dec 9, 2019 at 7:32 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> > Tree: next-20191118
>
> Why is this in your commit message?

I have been posting patches against various maintainer trees lately, which
will not apply to mainline or next. So I have been including base tree
information in the patch itself.

Base-tree info on patches is high on developers' wish list, but not yet
standardized. This was discussed at the 2019 kernel maintainers
summit:
https://lwn.net/Articles/803619/

Re: [PATCH v4 2/2] dt-bindings: mfd: update TI tps6105x chip bindings

[Lee Jones]

On Mon, 09 Dec 2019, Sven Van Asbroeck wrote:

> Hi Lee, thank you for the review.
> 
> On Mon, Dec 9, 2019 at 7:32 AM Lee Jones <lee.jones@linaro.org> wrote:
> >
> > > Tree: next-20191118
> >
> > Why is this in your commit message?
> 
> I have been posting patches against various maintainer trees lately, which
> will not apply to mainline or next. So I have been including base tree
> information in the patch itself.
> 
> Base-tree info on patches is high on developers' wish list, but not yet
> standardized. This was discussed at the 2019 kernel maintainers
> summit:
> https://lwn.net/Articles/803619/

NB: I haven't seen this discussion (or opened this link just yet).

It's no problem to have it in the submission, but it would be better
to have it *below* the '--' with the diff, such that if it is applied,
it doesn't end up in the kernel's Git history.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v4 2/2] dt-bindings: mfd: update TI tps6105x chip bindings

[Lee Jones]

On Tue, 10 Dec 2019, Lee Jones wrote:

> On Mon, 09 Dec 2019, Sven Van Asbroeck wrote:
> 
> > Hi Lee, thank you for the review.
> > 
> > On Mon, Dec 9, 2019 at 7:32 AM Lee Jones <lee.jones@linaro.org> wrote:
> > >
> > > > Tree: next-20191118
> > >
> > > Why is this in your commit message?
> > 
> > I have been posting patches against various maintainer trees lately, which
> > will not apply to mainline or next. So I have been including base tree
> > information in the patch itself.
> > 
> > Base-tree info on patches is high on developers' wish list, but not yet
> > standardized. This was discussed at the 2019 kernel maintainers
> > summit:
> > https://lwn.net/Articles/803619/
> 
> NB: I haven't seen this discussion (or opened this link just yet).
> 
> It's no problem to have it in the submission, but it would be better
> to have it *below* the '--' with the diff, such that if it is applied,
> it doesn't end up in the kernel's Git history.

Obviously that was meant to be '---'.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog