Linux-RTC Archive on lore.kernel.org
 help / color / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>,
	<mazziesaccount@gmail.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-clk@vger.kernel.org>, <linux-gpio@vger.kernel.org>,
	<linux-leds@vger.kernel.org>, <linux-rtc@vger.kernel.org>
Subject: Re: [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC
Date: Thu, 17 Oct 2019 09:04:48 -0500
Message-ID: <c1e41315-42ad-fb9b-c9db-8b07d4293166@ti.com> (raw)
In-Reply-To: <af1fb3e010d5f34502d354369b88fa28639f587d.1571302099.git.matti.vaittinen@fi.rohmeurope.com>

Matt

On 10/17/19 4:53 AM, Matti Vaittinen wrote:
> ROHM BD71828 power management IC has two LED outputs for charge status
> and button pressing indications. The LED outputs can also be forced
> bs SW so add driver allowing to use these LEDs for other indications
s/bs/by
> as well.
>
> Leds are controlled by SW using 'Force ON' bits. Please note the
> constrains mentioned in data-sheet:
> 1. If one LED is forced ON - then also the other LED is forced.
> 	=> You can't use SW control to force ON one LED and allow HW
> 	   to control the other.
> 2. You can't force both LEDs OFF. If the FORCE bit for both LED's is
>     zero, then LEDs are controlled by HW and indicate button/charger
>     states as explained in data-sheet.
>
> Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
> ---
>   drivers/leds/Kconfig        | 10 ++++
>   drivers/leds/Makefile       |  1 +
>   drivers/leds/leds-bd71828.c | 97 +++++++++++++++++++++++++++++++++++++
>   3 files changed, 108 insertions(+)
>   create mode 100644 drivers/leds/leds-bd71828.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index b0fdeef10bd9..ec59f28bcb39 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -529,6 +529,16 @@ config LEDS_BD2802
>   	  This option enables support for BD2802GU RGB LED driver chips
>   	  accessed via the I2C bus.
>   
> +config LEDS_BD71828
> +	tristate "LED driver for LED pins on ROHM BD71828 PMIC"
> +	depends on LEDS_CLASS
doesn't this have a dependency on MFD_ROHM_BD71828
> +	depends on I2C
> +	help
> +	  This option enables support for LED outputs located on ROHM
> +	   BD71828 power management IC. ROHM BD71828 has two led output pins
> +	   which can be left to indicate HW states or controlled by SW. Say
> +	   yes here if you want to enable SW control for these LEDs.
> +

Add module statement


>   config LEDS_INTEL_SS4200
>   	tristate "LED driver for Intel NAS SS4200 series"
>   	depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index 41fb073a39c1..2a8f6a8e4c7c 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_LEDS_AN30259A)		+= leds-an30259a.o
>   obj-$(CONFIG_LEDS_BCM6328)		+= leds-bcm6328.o
>   obj-$(CONFIG_LEDS_BCM6358)		+= leds-bcm6358.o
>   obj-$(CONFIG_LEDS_BD2802)		+= leds-bd2802.o
> +obj-$(CONFIG_LEDS_BD71828)		+= leds-bd71828.o
>   obj-$(CONFIG_LEDS_CPCAP)		+= leds-cpcap.o
>   obj-$(CONFIG_LEDS_LOCOMO)		+= leds-locomo.o
>   obj-$(CONFIG_LEDS_LM3530)		+= leds-lm3530.o
> diff --git a/drivers/leds/leds-bd71828.c b/drivers/leds/leds-bd71828.c
> new file mode 100644
> index 000000000000..2427619444f5
> --- /dev/null
> +++ b/drivers/leds/leds-bd71828.c
> @@ -0,0 +1,97 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 ROHM Semiconductors
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/kernel.h>
> +#include <linux/leds.h>
> +#include <linux/mfd/rohm-bd71828.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +#define BD71828_LED_TO_DATA(l) ((l)->id == ID_GREEN_LED ? \
> +	container_of((l), struct bd71828_leds, green) : \
> +	container_of((l), struct bd71828_leds, amber))

I don't think we should be defining the color as the variable. The 
outputs can drive any color LED.


> +
> +enum {
> +	ID_GREEN_LED,
> +	ID_AMBER_LED,
> +	ID_NMBR_OF,
> +};
> +

Please use the color_id in linux/include/dt-bindings/leds/common.h


> +struct bd71828_led {
> +	int id;
> +	struct led_classdev l;
> +	u8 force_mask;
> +};
> +
> +struct bd71828_leds {
> +	struct rohm_regmap_dev *bd71828;
> +	struct bd71828_led green;
> +	struct bd71828_led amber;
> +};
> +
> +static int bd71828_led_brightness_set(struct led_classdev *led_cdev,
> +				      enum led_brightness value)
> +{
> +	struct bd71828_led *l = container_of(led_cdev, struct bd71828_led, l);
> +	struct bd71828_leds *data;
> +	unsigned int val = BD71828_LED_OFF;
> +
> +	data = BD71828_LED_TO_DATA(l);
> +	if (value != LED_OFF)
> +		val = BD71828_LED_ON;
> +
> +	return regmap_update_bits(data->bd71828->regmap, BD71828_REG_LED_CTRL,
> +			    l->force_mask, val);
> +}
> +
> +static int bd71828_led_probe(struct platform_device *pdev)
> +{
> +	struct rohm_regmap_dev *bd71828;
> +	struct bd71828_leds *l;
> +	struct bd71828_led *g, *a;
> +	static const char *GNAME = "bd71828-green-led";
> +	static const char *ANAME = "bd71828-amber-led";
The LED class creates the name it can get it from the DT.
> +	int ret;
> +
> +	pr_info("bd71828 LED driver probed\n");
> +
> +	bd71828 = dev_get_drvdata(pdev->dev.parent);
> +	l = devm_kzalloc(&pdev->dev, sizeof(*l), GFP_KERNEL);
> +	if (!l)
> +		return -ENOMEM;
> +	l->bd71828 = bd71828;
> +	a = &l->amber;
> +	g = &l->green;
> +	a->id = ID_AMBER_LED;
> +	g->id = ID_GREEN_LED;
> +	a->force_mask = BD71828_MASK_LED_AMBER;
> +	g->force_mask = BD71828_MASK_LED_GREEN;
> +
> +	a->l.name = ANAME;
> +	g->l.name = GNAME;
> +	a->l.brightness_set_blocking = bd71828_led_brightness_set;
> +	g->l.brightness_set_blocking = bd71828_led_brightness_set;
> +
> +	ret = devm_led_classdev_register(&pdev->dev, &g->l);
> +	if (ret)
> +		return ret;
> +
> +	return devm_led_classdev_register(&pdev->dev, &a->l);
> +}
> +

This looks different.  Not sure why you register both LEDs in this probe.

You can use the DT to define both LEDs and then each will be probed and 
registered separately.

This is how it is commonly done.

You can reference the LM36274 led driver as this is a MFD device to the 
ti-lmu.c in the MFD directory.


> +static struct platform_driver bd71828_led_driver = {
> +	.driver = {
> +		.name  = "bd71828-led",
> +	},
> +	.probe  = bd71828_led_probe,
> +};
> +
> +module_platform_driver(bd71828_led_driver);
> +
> +MODULE_AUTHOR("Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>");
> +MODULE_DESCRIPTION("ROHM BD71828 LED driver");
> +MODULE_LICENSE("GPL");
GPL v2

  reply index

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-17  9:40 [RFC PATCH 00/13] Support " Matti Vaittinen
2019-10-17  9:41 ` [RFC PATCH 01/13] mfd: bd71828: Support ROHM BD71828 PMIC - core Matti Vaittinen
2019-10-17  9:42 ` [RFC PATCH 02/13] mfd: input: bd71828: Add power-key support Matti Vaittinen
2019-10-17  9:43 ` [RFC PATCH 03/13] clk: bd718x7: Support ROHM BD71828 clk block Matti Vaittinen
2019-10-17  9:44 ` [RFC PATCH 04/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts Matti Vaittinen
2019-10-17  9:44 ` [RFC PATCH 05/13] regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators Matti Vaittinen
2019-10-17  9:48 ` [RFC PATCH 06/13] regulator: bd71828: Add GPIO based run-level control for regulators Matti Vaittinen
2019-10-17  9:50 ` [RFC PATCH 07/13] regulator: bd71828: enhanced run-level support Matti Vaittinen
2019-10-17  9:51 ` [RFC PATCH 08/13] regulator: bd71828: Support in-kernel APIs to change run-level Matti Vaittinen
2019-10-17  9:52 ` [RFC PATCH 09/13] mfd: rtc: support RTC on ROHM BD71828 with BD70528 driver Matti Vaittinen
2019-10-17 10:12   ` Alexandre Belloni
2019-10-17 10:36     ` Vaittinen, Matti
2019-10-17 10:48       ` Alexandre Belloni
2019-10-21  5:29         ` Vaittinen, Matti
2019-10-23 10:27         ` Vaittinen, Matti
2019-10-29 13:50           ` Alexandre Belloni
2019-10-29 14:08             ` Vaittinen, Matti
2019-10-17  9:53 ` [RFC PATCH 10/13] gpio: bd71828: Initial support for ROHM BD71828 PMIC GPIOs Matti Vaittinen
2019-10-17 12:45   ` Bartosz Golaszewski
2019-10-21  7:00     ` Vaittinen, Matti
2019-10-21 14:36       ` Bartosz Golaszewski
2019-10-21 14:56         ` Vaittinen, Matti
2019-10-22 13:19         ` Vaittinen, Matti
2019-10-17  9:53 ` [RFC PATCH 11/13] led: bd71828: Support LED outputs on ROHM BD71828 PMIC Matti Vaittinen
2019-10-17 14:04   ` Dan Murphy [this message]
2019-10-17 14:28     ` Alexandre Belloni
2019-10-21  8:00     ` Vaittinen, Matti
2019-10-21 19:09       ` Jacek Anaszewski
2019-10-22 12:40         ` Vaittinen, Matti
2019-10-22 17:40           ` Jacek Anaszewski
2019-10-23  8:37             ` Vaittinen, Matti
2019-10-23 21:59               ` Jacek Anaszewski
2019-10-24  8:15                 ` Vaittinen, Matti
2019-10-24 22:04                   ` Jacek Anaszewski
2019-10-25  7:07                     ` Vaittinen, Matti
2019-10-25 13:24                       ` Rob Herring
2019-10-25 14:37                         ` Vaittinen, Matti
2019-10-25 15:47                           ` Rob Herring
2019-10-29 13:29                             ` Vaittinen, Matti
2019-10-17  9:55 ` [RFC PATCH 12/13] dt-bindings: mfd: Document ROHM BD71282 bindings Matti Vaittinen
2019-10-17 14:18   ` Dan Murphy
2019-10-21  8:03     ` Vaittinen, Matti
2019-10-17  9:57 ` [RFC PATCH 13/13] dt-bindings: regulator: Document ROHM BD71282 regulator bindings Matti Vaittinen

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1e41315-42ad-fb9b-c9db-8b07d4293166@ti.com \
    --to=dmurphy@ti.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jacek.anaszewski@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matti.vaittinen@fi.rohmeurope.com \
    --cc=mazziesaccount@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-RTC Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-rtc/0 linux-rtc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-rtc linux-rtc/ https://lore.kernel.org/linux-rtc \
		linux-rtc@vger.kernel.org
	public-inbox-index linux-rtc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rtc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git