* [PATCH v26 15/15] leds: lp5523: Fix various formatting issues in the code
From: Dan Murphy @ 2020-06-04 12:05 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Fix checkpatch errors and warnings for the LP5523.c device
driver.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/leds/leds-lp5523.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 9776dc72a764..f55d97258d5e 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -23,13 +23,13 @@
#define LP5523_PROGRAM_LENGTH 32 /* bytes */
/* Memory is used like this:
- 0x00 engine 1 program
- 0x10 engine 2 program
- 0x20 engine 3 program
- 0x30 engine 1 muxing info
- 0x40 engine 2 muxing info
- 0x50 engine 3 muxing info
-*/
+ * 0x00 engine 1 program
+ * 0x10 engine 2 program
+ * 0x20 engine 3 program
+ * 0x30 engine 1 muxing info
+ * 0x40 engine 2 muxing info
+ * 0x50 engine 3 muxing info
+ */
#define LP5523_MAX_LEDS 9
/* Registers */
@@ -326,7 +326,7 @@ static int lp5523_update_program_memory(struct lp55xx_chip *chip,
const u8 *data, size_t size)
{
u8 pattern[LP5523_PROGRAM_LENGTH] = {0};
- unsigned cmd;
+ unsigned int cmd;
char c[3];
int nrchars;
int ret;
@@ -468,6 +468,7 @@ static int lp5523_mux_parse(const char *buf, u16 *mux, size_t len)
static void lp5523_mux_to_array(u16 led_mux, char *array)
{
int i, pos = 0;
+
for (i = 0; i < LP5523_MAX_LEDS; i++)
pos += sprintf(array + pos, "%x", LED_ACTIVE(led_mux, i));
@@ -506,7 +507,7 @@ static int lp5523_load_mux(struct lp55xx_chip *chip, u16 mux, int nr)
if (ret)
return ret;
- ret = lp55xx_write(chip, LP5523_REG_PROG_MEM , (u8)(mux >> 8));
+ ret = lp55xx_write(chip, LP5523_REG_PROG_MEM, (u8)(mux >> 8));
if (ret)
return ret;
--
2.26.2
^ permalink raw reply related
* [PATCH v26 13/15] leds: lp5521: Add multicolor framework multicolor brightness support
From: Dan Murphy @ 2020-06-04 12:05 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Add the multicolor brightness call back to support the multicolor
framework. This function allows setting the brightness across
grouped LED channels in a single call.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp5521.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8b28f73c810c..bdf8fc2652fb 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -398,6 +398,7 @@ config LEDS_LP55XX_COMMON
config LEDS_LP5521
tristate "LED Support for N.S. LP5521 LED driver chip"
depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
select LEDS_LP55XX_COMMON
help
If you say yes here you get support for the National Semiconductor
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 6ff81d6be789..ef8c3bfa8f3c 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -349,6 +349,25 @@ static int lp5521_run_selftest(struct lp55xx_chip *chip, char *buf)
return 0;
}
+static int lp5521_multicolor_brightness(struct lp55xx_led *led)
+{
+ struct lp55xx_chip *chip = led->chip;
+ int ret;
+ int i;
+
+ mutex_lock(&chip->lock);
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ ret = lp55xx_write(chip,
+ LP5521_REG_LED_PWM_BASE +
+ led->mc_cdev.subled_info[i].channel,
+ led->mc_cdev.subled_info[i].brightness);
+ if (ret)
+ break;
+ }
+ mutex_unlock(&chip->lock);
+ return ret;
+}
+
static int lp5521_led_brightness(struct lp55xx_led *led)
{
struct lp55xx_chip *chip = led->chip;
@@ -490,6 +509,7 @@ static struct lp55xx_device_config lp5521_cfg = {
.max_channel = LP5521_MAX_LEDS,
.post_init_device = lp5521_post_init_device,
.brightness_fn = lp5521_led_brightness,
+ .multicolor_brightness_fn = lp5521_multicolor_brightness,
.set_led_current = lp5521_set_led_current,
.firmware_cb = lp5521_firmware_loaded,
.run_engine = lp5521_run_engine,
--
2.26.2
^ permalink raw reply related
* [PATCH v26 12/15] leds: lp5523: Update the lp5523 code to add multicolor brightness function
From: Dan Murphy @ 2020-06-04 12:05 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
in a single function.
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp5523.c | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index c127a931e250..8b28f73c810c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -408,6 +408,7 @@ config LEDS_LP5521
config LEDS_LP5523
tristate "LED Support for TI/National LP5523/55231 LED driver chip"
depends on LEDS_CLASS && I2C
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
select LEDS_LP55XX_COMMON
help
If you say yes here you get support for TI/National Semiconductor
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index b076c16df9ab..9776dc72a764 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -791,6 +791,25 @@ static ssize_t store_master_fader_leds(struct device *dev,
return ret;
}
+static int lp5523_multicolor_brightness(struct lp55xx_led *led)
+{
+ struct lp55xx_chip *chip = led->chip;
+ int ret;
+ int i;
+
+ mutex_lock(&chip->lock);
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ ret = lp55xx_write(chip,
+ LP5523_REG_LED_PWM_BASE +
+ led->mc_cdev.subled_info[i].channel,
+ led->mc_cdev.subled_info[i].brightness);
+ if (ret)
+ break;
+ }
+ mutex_unlock(&chip->lock);
+ return ret;
+}
+
static int lp5523_led_brightness(struct lp55xx_led *led)
{
struct lp55xx_chip *chip = led->chip;
@@ -857,6 +876,7 @@ static struct lp55xx_device_config lp5523_cfg = {
.max_channel = LP5523_MAX_LEDS,
.post_init_device = lp5523_post_init_device,
.brightness_fn = lp5523_led_brightness,
+ .multicolor_brightness_fn = lp5523_multicolor_brightness,
.set_led_current = lp5523_set_led_current,
.firmware_cb = lp5523_firmware_loaded,
.run_engine = lp5523_run_engine,
--
2.26.2
^ permalink raw reply related
* [PATCH v26 08/15] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
CC: Shawn Guo <shawnguo@kernel.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Pengutronix Kernel Team <kernel@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: NXP Linux Team <linux-imx@nxp.com>
---
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
index 2b9423d55c37..77aa90640052 100644
--- a/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
+++ b/arch/arm/boot/dts/imx6dl-yapp4-common.dtsi
@@ -258,29 +258,35 @@ leds: led-controller@30 {
reg = <0x30>;
clock-mode = /bits/ 8 <1>;
status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
- chan0 {
+ chan@0 {
chan-name = "R";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
+ reg = <0>;
};
- chan1 {
+ chan@1 {
chan-name = "G";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
+ reg = <1>;
};
- chan2 {
+ chan@2 {
chan-name = "B";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
+ reg = <2>;
};
- chan3 {
+ chan@3 {
chan-name = "W";
led-cur = /bits/ 8 <0x0>;
max-cur = /bits/ 8 <0x0>;
+ reg = <3>;
};
};
--
2.26.2
^ permalink raw reply related
* [PATCH v26 09/15] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy, Linus Walleij
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
CC: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
arch/arm/boot/dts/ste-href.dtsi | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/ste-href.dtsi b/arch/arm/boot/dts/ste-href.dtsi
index 33e3b0b3c53d..ff47cbf6ed3b 100644
--- a/arch/arm/boot/dts/ste-href.dtsi
+++ b/arch/arm/boot/dts/ste-href.dtsi
@@ -58,16 +58,21 @@ lp5521@33 {
reg = <0x33>;
label = "lp5521_pri";
clock-mode = /bits/ 8 <2>;
- chan0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ chan@0 {
+ reg = <0>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
linux,default-trigger = "heartbeat";
};
- chan1 {
+ chan@1 {
+ reg = <1>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
- chan2 {
+ chan@2 {
+ reg = <2>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
@@ -77,15 +82,20 @@ lp5521@34 {
reg = <0x34>;
label = "lp5521_sec";
clock-mode = /bits/ 8 <2>;
- chan0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ chan@0 {
+ reg = <0>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
- chan1 {
+ chan@1 {
+ reg = <1>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
- chan2 {
+ chan@2 {
+ reg = <2>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
--
2.26.2
^ permalink raw reply related
* [PATCH v26 07/15] ARM: dts: n900: Add reg property to the LP5523 channel node
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy, Tony Lindgren,
Benoît Cousson
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Add the reg property to each channel node. This update is
to accommodate the multicolor framework. In addition to the
accommodation this allows the LEDs to be placed on any channel
and allow designs to skip channels as opposed to requiring
sequential order.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
CC: Tony Lindgren <tony@atomide.com>
CC: "Benoît Cousson" <bcousson@baylibre.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
---
arch/arm/boot/dts/omap3-n900.dts | 29 ++++++++++++++++++++---------
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 4089d97405c9..ebe93b06b4f7 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -618,63 +618,74 @@ indicator {
};
lp5523: lp5523@32 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "national,lp5523";
reg = <0x32>;
clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
enable-gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */
- chan0 {
+ chan@0 {
chan-name = "lp5523:kb1";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <0>;
};
- chan1 {
+ chan@1 {
chan-name = "lp5523:kb2";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <1>;
};
- chan2 {
+ chan@2 {
chan-name = "lp5523:kb3";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <2>;
};
- chan3 {
+ chan@3 {
chan-name = "lp5523:kb4";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <3>;
};
- chan4 {
+ chan@4 {
chan-name = "lp5523:b";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <4>;
};
- chan5 {
+ chan@5 {
chan-name = "lp5523:g";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <5>;
};
- chan6 {
+ chan@6 {
chan-name = "lp5523:r";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <6>;
};
- chan7 {
+ chan@7 {
chan-name = "lp5523:kb5";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <7>;
};
- chan8 {
+ chan@8 {
chan-name = "lp5523:kb6";
led-cur = /bits/ 8 <50>;
max-cur = /bits/ 8 <100>;
+ reg = <8>;
};
};
--
2.26.2
^ permalink raw reply related
* [PATCH v26 06/15] dt-bindings: leds: Convert leds-lp55xx to yaml
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Convert the leds-lp55xx.txt to yaml binding.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/leds/leds-lp55xx.txt | 228 ------------------
.../devicetree/bindings/leds/leds-lp55xx.yaml | 220 +++++++++++++++++
2 files changed, 220 insertions(+), 228 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
deleted file mode 100644
index 1b66a413fb9d..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-Binding for TI/National Semiconductor LP55xx Led Drivers
-
-Required properties:
-- compatible: one of
- national,lp5521
- national,lp5523
- ti,lp55231
- ti,lp5562
- ti,lp8501
-
-- reg: I2C slave address
-- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
-
-Each child has own specific current settings
-- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
-- max-cur: Maximun current at each led channel.
-
-Optional properties:
-- enable-gpio: GPIO attached to the chip's enable pin
-- label: Used for naming LEDs
-- pwr-sel: LP8501 specific property. Power selection for output channels.
- 0: D1~9 are connected to VDD
- 1: D1~6 with VDD, D7~9 with VOUT
- 2: D1~6 with VOUT, D7~9 with VDD
- 3: D1~9 are connected to VOUT
-
-Alternatively, each child can have a specific channel name and trigger:
-- chan-name (optional): name of channel
-- linux,default-trigger (optional): see
- Documentation/devicetree/bindings/leds/common.txt
-
-example 1) LP5521
-3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
-'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
-on channel 0.
-
-lp5521@32 {
- compatible = "national,lp5521";
- reg = <0x32>;
- label = "lp5521_pri";
- clock-mode = /bits/ 8 <2>;
-
- chan0 {
- led-cur = /bits/ 8 <0x2f>;
- max-cur = /bits/ 8 <0x5f>;
- linux,default-trigger = "heartbeat";
- };
-
- chan1 {
- led-cur = /bits/ 8 <0x2f>;
- max-cur = /bits/ 8 <0x5f>;
- };
-
- chan2 {
- led-cur = /bits/ 8 <0x2f>;
- max-cur = /bits/ 8 <0x5f>;
- };
-};
-
-example 2) LP5523
-9 LED channels with specific name. Internal clock used.
-The I2C slave address is configurable with ASEL1 and ASEL0 pins.
-Available addresses are 32/33/34/35h.
-
-ASEL1 ASEL0 Address
--------------------------
- GND GND 32h
- GND VEN 33h
- VEN GND 34h
- VEN VEN 35h
-
-lp5523@32 {
- compatible = "national,lp5523";
- reg = <0x32>;
- clock-mode = /bits/ 8 <1>;
-
- chan0 {
- chan-name = "d1";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan1 {
- chan-name = "d2";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan2 {
- chan-name = "d3";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan3 {
- chan-name = "d4";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan4 {
- chan-name = "d5";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan5 {
- chan-name = "d6";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan6 {
- chan-name = "d7";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan7 {
- chan-name = "d8";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan8 {
- chan-name = "d9";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-};
-
-example 3) LP5562
-4 channels are defined.
-
-lp5562@30 {
- compatible = "ti,lp5562";
- reg = <0x30>;
- clock-mode = /bits/8 <2>;
-
- chan0 {
- chan-name = "R";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-
- chan1 {
- chan-name = "G";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-
- chan2 {
- chan-name = "B";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-
- chan3 {
- chan-name = "W";
- led-cur = /bits/ 8 <0x20>;
- max-cur = /bits/ 8 <0x60>;
- };
-};
-
-example 4) LP8501
-9 channels are defined. The 'pwr-sel' is LP8501 specific property.
-Others are same as LP5523.
-
-lp8501@32 {
- compatible = "ti,lp8501";
- reg = <0x32>;
- clock-mode = /bits/ 8 <2>;
- pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
-
- chan0 {
- chan-name = "d1";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan1 {
- chan-name = "d2";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan2 {
- chan-name = "d3";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan3 {
- chan-name = "d4";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan4 {
- chan-name = "d5";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan5 {
- chan-name = "d6";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan6 {
- chan-name = "d7";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan7 {
- chan-name = "d8";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-
- chan8 {
- chan-name = "d9";
- led-cur = /bits/ 8 <0x14>;
- max-cur = /bits/ 8 <0x20>;
- };
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
new file mode 100644
index 000000000000..9d6ded5fbc14
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
@@ -0,0 +1,220 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-lp55xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI/National Semiconductor LP55xx and LP8501 LED Drivers
+
+maintainers:
+ - Jacek Anaszewski <jacek.anaszewski@gmail.com>
+ - Pavel Machek <pavel@ucw.cz>
+
+description: |
+ Bindings for the TI/National Semiconductor LP55xx and LP8501 multi channel
+ LED Drivers.
+
+ For more product information please see the link below:
+ https://www.ti.com/lit/gpn/lp5521
+ https://www.ti.com/lit/gpn/lp5523
+ https://www.ti.com/lit/gpn/lp55231
+ https://www.ti.com/lit/gpn/lp5562
+ https://www.ti.com/lit/gpn/lp8501
+
+properties:
+ #allOf:
+ #- $ref: "common.yaml#"
+ #- $ref: "leds-class-multicolor.yaml#"
+
+ compatible:
+ enum:
+ - national,lp5521
+ - national,lp5523
+ - ti,lp55231
+ - ti,lp5562
+ - ti,lp8501
+
+ reg:
+ maxItems: 1
+ description: I2C slave address
+
+ clock-mode:
+ $ref: /schemas/types.yaml#definitions/uint8
+ maxItems: 1
+ description: |
+ Input clock mode
+ 0 - automode
+ 1 - internal
+ 2 - external
+
+ enable-gpio:
+ maxItems: 1
+ description: |
+ GPIO attached to the chip's enable pin
+
+ pwr-sel:
+ $ref: /schemas/types.yaml#definitions/uint8
+ maxItems: 1
+ description: |
+ LP8501 specific property. Power selection for output channels.
+ 0 - D1~9 are connected to VDD
+ 1 - D1~6 with VDD, D7~9 with VOUT
+ 2 - D1~6 with VOUT, D7~9 with VDD
+ 3 - D1~9 are connected to VOUT
+
+ child-node:
+ type: object
+ properties:
+ led-cur:
+ $ref: /schemas/types.yaml#definitions/uint8
+ maxItems: 1
+ description: |
+ Current setting at each LED channel (mA x10, 0 if LED is not connected)
+
+ max-cur:
+ $ref: /schemas/types.yaml#definitions/uint8
+ maxItems: 1
+ description: Maximun current at each LED channel.
+
+ reg:
+ maxItems: 1
+ description: |
+ Output channel for the LED. This is zero based channel identifier and
+ the data sheet is a one based channel identifier.
+ reg value to output to LED output number
+ D1 = reg value is 0
+ D2 = reg value is 1
+ D3 = reg value is 2
+ D4 = reg value is 3
+ D5 = reg value is 4
+ D6 = reg value is 5
+ D7 = reg value is 6
+ D8 = reg value is 7
+ D9 = reg value is 8
+
+ chan-name:
+ $ref: /schemas/types.yaml#definitions/string
+ description: name of channel
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@32 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lp8501";
+ reg = <0x32>;
+ clock-mode = /bits/ 8 <2>;
+ pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
+
+ led@0 {
+ reg = <0>;
+ chan-name = "d1";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@1 {
+ reg = <1>;
+ chan-name = "d2";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@2 {
+ reg = <2>;
+ chan-name = "d3";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@3 {
+ reg = <3>;
+ chan-name = "d4";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@4 {
+ reg = <4>;
+ chan-name = "d5";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@5 {
+ reg = <5>;
+ chan-name = "d6";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@6 {
+ reg = <6>;
+ chan-name = "d7";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@7 {
+ reg = <7>;
+ chan-name = "d8";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+
+ led@8 {
+ reg = <8>;
+ chan-name = "d9";
+ led-cur = /bits/ 8 <0x14>;
+ max-cur = /bits/ 8 <0x20>;
+ };
+ };
+
+ led-controller@33 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "national,lp5523";
+ reg = <0x33>;
+ clock-mode = /bits/ 8 <0>;
+
+ multi-led@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STANDBY;
+ linux,default-trigger = "heartbeat";
+
+ led@0 {
+ led-cur = /bits/ 8 <50>;
+ max-cur = /bits/ 8 <100>;
+ reg = <0x0>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@1 {
+ led-cur = /bits/ 8 <50>;
+ max-cur = /bits/ 8 <100>;
+ reg = <0x1>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+
+ led@6 {
+ led-cur = /bits/ 8 <50>;
+ max-cur = /bits/ 8 <100>;
+ reg = <0x6>;
+ color = <LED_COLOR_ID_RED>;
+ };
+ };
+ };
+ };
--
2.26.2
^ permalink raw reply related
* [PATCH v26 05/15] leds: lp50xx: Add the LP50XX family of the RGB LED driver
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Introduce the LP5036/30/24/18/12/9 RGB LED driver.
The difference in these parts are the number of
LED outputs where the:
LP5036 can control 36 LEDs
LP5030 can control 30 LEDs
LP5024 can control 24 LEDs
LP5018 can control 18 LEDs
LP5012 can control 12 LEDs
LP5009 can control 9 LEDs
The device has the ability to group LED output into control banks
so that multiple LED banks can be controlled with the same mixing and
brightness. Inversely the LEDs can also be controlled independently.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp50xx.c | 778 +++++++++++++++++++++++++++++++++++++
3 files changed, 790 insertions(+)
create mode 100644 drivers/leds/leds-lp50xx.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index fe7d90d4fa23..07dde638b23d 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -374,6 +374,17 @@ config LEDS_LP3952
To compile this driver as a module, choose M here: the
module will be called leds-lp3952.
+config LEDS_LP50XX
+ tristate "LED Support for TI LP5036/30/24/18/12/9 LED driver chip"
+ depends on LEDS_CLASS && REGMAP_I2C
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
+ help
+ If you say yes here you get support for the Texas Instruments
+ LP5036, LP5030, LP5024, LP5018, LP5012 and LP5009 LED driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-lp50xx.
+
config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 53bf92f30258..5ac6ed3ed075 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_LEDS_LM3697) += leds-lm3697.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
obj-$(CONFIG_LEDS_LP3952) += leds-lp3952.o
+obj-$(CONFIG_LEDS_LP50XX) += leds-lp50xx.o
obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o
obj-$(CONFIG_LEDS_LP5562) += leds-lp5562.o
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
new file mode 100644
index 000000000000..888bb54be55f
--- /dev/null
+++ b/drivers/leds/leds-lp50xx.c
@@ -0,0 +1,778 @@
+// SPDX-License-Identifier: GPL-2.0
+// TI LP50XX LED chip family driver
+// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
+
+#include <linux/led-class-multicolor.h>
+
+#include "leds.h"
+
+#define LP50XX_DEV_CFG0 0x00
+#define LP50XX_DEV_CFG1 0x01
+#define LP50XX_LED_CFG0 0x02
+
+/* LP5009 and LP5012 registers */
+#define LP5012_BNK_BRT 0x03
+#define LP5012_BNKA_CLR 0x04
+#define LP5012_BNKB_CLR 0x05
+#define LP5012_BNKC_CLR 0x06
+#define LP5012_LED0_BRT 0x07
+#define LP5012_LED1_BRT 0x08
+#define LP5012_LED2_BRT 0x09
+#define LP5012_LED3_BRT 0x0a
+#define LP5012_OUT0_CLR 0x0b
+#define LP5012_OUT1_CLR 0x0c
+#define LP5012_OUT2_CLR 0x0d
+#define LP5012_OUT3_CLR 0x0e
+#define LP5012_OUT4_CLR 0x0f
+#define LP5012_OUT5_CLR 0x10
+#define LP5012_OUT6_CLR 0x11
+#define LP5012_OUT7_CLR 0x12
+#define LP5012_OUT8_CLR 0x13
+#define LP5012_OUT9_CLR 0x14
+#define LP5012_OUT10_CLR 0x15
+#define LP5012_OUT11_CLR 0x16
+#define LP5012_RESET 0x17
+
+/* LP5018 and LP5024 registers */
+#define LP5024_BNK_BRT 0x03
+#define LP5024_BNKA_CLR 0x04
+#define LP5024_BNKB_CLR 0x05
+#define LP5024_BNKC_CLR 0x06
+#define LP5024_LED0_BRT 0x07
+#define LP5024_LED1_BRT 0x08
+#define LP5024_LED2_BRT 0x09
+#define LP5024_LED3_BRT 0x0a
+#define LP5024_LED4_BRT 0x0b
+#define LP5024_LED5_BRT 0x0c
+#define LP5024_LED6_BRT 0x0d
+#define LP5024_LED7_BRT 0x0e
+
+#define LP5024_OUT0_CLR 0x0f
+#define LP5024_OUT1_CLR 0x10
+#define LP5024_OUT2_CLR 0x11
+#define LP5024_OUT3_CLR 0x12
+#define LP5024_OUT4_CLR 0x13
+#define LP5024_OUT5_CLR 0x14
+#define LP5024_OUT6_CLR 0x15
+#define LP5024_OUT7_CLR 0x16
+#define LP5024_OUT8_CLR 0x17
+#define LP5024_OUT9_CLR 0x18
+#define LP5024_OUT10_CLR 0x19
+#define LP5024_OUT11_CLR 0x1a
+#define LP5024_OUT12_CLR 0x1b
+#define LP5024_OUT13_CLR 0x1c
+#define LP5024_OUT14_CLR 0x1d
+#define LP5024_OUT15_CLR 0x1e
+#define LP5024_OUT16_CLR 0x1f
+#define LP5024_OUT17_CLR 0x20
+#define LP5024_OUT18_CLR 0x21
+#define LP5024_OUT19_CLR 0x22
+#define LP5024_OUT20_CLR 0x23
+#define LP5024_OUT21_CLR 0x24
+#define LP5024_OUT22_CLR 0x25
+#define LP5024_OUT23_CLR 0x26
+#define LP5024_RESET 0x27
+
+/* LP5030 and LP5036 registers */
+#define LP5036_LED_CFG1 0x03
+#define LP5036_BNK_BRT 0x04
+#define LP5036_BNKA_CLR 0x05
+#define LP5036_BNKB_CLR 0x06
+#define LP5036_BNKC_CLR 0x07
+#define LP5036_LED0_BRT 0x08
+#define LP5036_LED1_BRT 0x09
+#define LP5036_LED2_BRT 0x0a
+#define LP5036_LED3_BRT 0x0b
+#define LP5036_LED4_BRT 0x0c
+#define LP5036_LED5_BRT 0x0d
+#define LP5036_LED6_BRT 0x0e
+#define LP5036_LED7_BRT 0x0f
+#define LP5036_LED8_BRT 0x10
+#define LP5036_LED9_BRT 0x11
+#define LP5036_LED10_BRT 0x12
+#define LP5036_LED11_BRT 0x13
+
+#define LP5036_OUT0_CLR 0x14
+#define LP5036_OUT1_CLR 0x15
+#define LP5036_OUT2_CLR 0x16
+#define LP5036_OUT3_CLR 0x17
+#define LP5036_OUT4_CLR 0x18
+#define LP5036_OUT5_CLR 0x19
+#define LP5036_OUT6_CLR 0x1a
+#define LP5036_OUT7_CLR 0x1b
+#define LP5036_OUT8_CLR 0x1c
+#define LP5036_OUT9_CLR 0x1d
+#define LP5036_OUT10_CLR 0x1e
+#define LP5036_OUT11_CLR 0x1f
+#define LP5036_OUT12_CLR 0x20
+#define LP5036_OUT13_CLR 0x21
+#define LP5036_OUT14_CLR 0x22
+#define LP5036_OUT15_CLR 0x23
+#define LP5036_OUT16_CLR 0x24
+#define LP5036_OUT17_CLR 0x25
+#define LP5036_OUT18_CLR 0x26
+#define LP5036_OUT19_CLR 0x27
+#define LP5036_OUT20_CLR 0x28
+#define LP5036_OUT21_CLR 0x29
+#define LP5036_OUT22_CLR 0x2a
+#define LP5036_OUT23_CLR 0x2b
+#define LP5036_OUT24_CLR 0x2c
+#define LP5036_OUT25_CLR 0x2d
+#define LP5036_OUT26_CLR 0x2e
+#define LP5036_OUT27_CLR 0x2f
+#define LP5036_OUT28_CLR 0x30
+#define LP5036_OUT29_CLR 0x31
+#define LP5036_OUT30_CLR 0x32
+#define LP5036_OUT31_CLR 0x33
+#define LP5036_OUT32_CLR 0x34
+#define LP5036_OUT33_CLR 0x35
+#define LP5036_OUT34_CLR 0x36
+#define LP5036_OUT35_CLR 0x37
+#define LP5036_RESET 0x38
+
+#define LP50XX_SW_RESET 0xff
+#define LP50XX_CHIP_EN BIT(6)
+
+/* There are 3 LED outputs per bank */
+#define LP50XX_LEDS_PER_MODULE 3
+
+#define LP5009_MAX_LED_MODULES 2
+#define LP5012_MAX_LED_MODULES 4
+#define LP5018_MAX_LED_MODULES 6
+#define LP5024_MAX_LED_MODULES 8
+#define LP5030_MAX_LED_MODULES 10
+#define LP5036_MAX_LED_MODULES 12
+
+#define LP5009_MAX_LEDS (LP5009_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5012_MAX_LEDS (LP5012_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5018_MAX_LEDS (LP5018_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5024_MAX_LEDS (LP5024_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5030_MAX_LEDS (LP5030_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5036_MAX_LEDS (LP5036_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+
+static const struct reg_default lp5012_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5012_BNK_BRT, 0xff},
+ {LP5012_BNKA_CLR, 0x0f},
+ {LP5012_BNKB_CLR, 0x0f},
+ {LP5012_BNKC_CLR, 0x0f},
+ {LP5012_LED0_BRT, 0x0f},
+ {LP5012_LED1_BRT, 0xff},
+ {LP5012_LED2_BRT, 0xff},
+ {LP5012_LED3_BRT, 0xff},
+ {LP5012_OUT0_CLR, 0x0f},
+ {LP5012_OUT1_CLR, 0x00},
+ {LP5012_OUT2_CLR, 0x00},
+ {LP5012_OUT3_CLR, 0x00},
+ {LP5012_OUT4_CLR, 0x00},
+ {LP5012_OUT5_CLR, 0x00},
+ {LP5012_OUT6_CLR, 0x00},
+ {LP5012_OUT7_CLR, 0x00},
+ {LP5012_OUT8_CLR, 0x00},
+ {LP5012_OUT9_CLR, 0x00},
+ {LP5012_OUT10_CLR, 0x00},
+ {LP5012_OUT11_CLR, 0x00},
+ {LP5012_RESET, 0x00}
+};
+
+static const struct reg_default lp5024_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5024_BNK_BRT, 0xff},
+ {LP5024_BNKA_CLR, 0x0f},
+ {LP5024_BNKB_CLR, 0x0f},
+ {LP5024_BNKC_CLR, 0x0f},
+ {LP5024_LED0_BRT, 0x0f},
+ {LP5024_LED1_BRT, 0xff},
+ {LP5024_LED2_BRT, 0xff},
+ {LP5024_LED3_BRT, 0xff},
+ {LP5024_LED4_BRT, 0xff},
+ {LP5024_LED5_BRT, 0xff},
+ {LP5024_LED6_BRT, 0xff},
+ {LP5024_LED7_BRT, 0xff},
+ {LP5024_OUT0_CLR, 0x0f},
+ {LP5024_OUT1_CLR, 0x00},
+ {LP5024_OUT2_CLR, 0x00},
+ {LP5024_OUT3_CLR, 0x00},
+ {LP5024_OUT4_CLR, 0x00},
+ {LP5024_OUT5_CLR, 0x00},
+ {LP5024_OUT6_CLR, 0x00},
+ {LP5024_OUT7_CLR, 0x00},
+ {LP5024_OUT8_CLR, 0x00},
+ {LP5024_OUT9_CLR, 0x00},
+ {LP5024_OUT10_CLR, 0x00},
+ {LP5024_OUT11_CLR, 0x00},
+ {LP5024_OUT12_CLR, 0x00},
+ {LP5024_OUT13_CLR, 0x00},
+ {LP5024_OUT14_CLR, 0x00},
+ {LP5024_OUT15_CLR, 0x00},
+ {LP5024_OUT16_CLR, 0x00},
+ {LP5024_OUT17_CLR, 0x00},
+ {LP5024_OUT18_CLR, 0x00},
+ {LP5024_OUT19_CLR, 0x00},
+ {LP5024_OUT20_CLR, 0x00},
+ {LP5024_OUT21_CLR, 0x00},
+ {LP5024_OUT22_CLR, 0x00},
+ {LP5024_OUT23_CLR, 0x00},
+ {LP5024_RESET, 0x00}
+};
+
+static const struct reg_default lp5036_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5036_LED_CFG1, 0x0},
+ {LP5036_BNK_BRT, 0xff},
+ {LP5036_BNKA_CLR, 0x0f},
+ {LP5036_BNKB_CLR, 0x0f},
+ {LP5036_BNKC_CLR, 0x0f},
+ {LP5036_LED0_BRT, 0x0f},
+ {LP5036_LED1_BRT, 0xff},
+ {LP5036_LED2_BRT, 0xff},
+ {LP5036_LED3_BRT, 0xff},
+ {LP5036_LED4_BRT, 0xff},
+ {LP5036_LED5_BRT, 0xff},
+ {LP5036_LED6_BRT, 0xff},
+ {LP5036_LED7_BRT, 0xff},
+ {LP5036_OUT0_CLR, 0x0f},
+ {LP5036_OUT1_CLR, 0x00},
+ {LP5036_OUT2_CLR, 0x00},
+ {LP5036_OUT3_CLR, 0x00},
+ {LP5036_OUT4_CLR, 0x00},
+ {LP5036_OUT5_CLR, 0x00},
+ {LP5036_OUT6_CLR, 0x00},
+ {LP5036_OUT7_CLR, 0x00},
+ {LP5036_OUT8_CLR, 0x00},
+ {LP5036_OUT9_CLR, 0x00},
+ {LP5036_OUT10_CLR, 0x00},
+ {LP5036_OUT11_CLR, 0x00},
+ {LP5036_OUT12_CLR, 0x00},
+ {LP5036_OUT13_CLR, 0x00},
+ {LP5036_OUT14_CLR, 0x00},
+ {LP5036_OUT15_CLR, 0x00},
+ {LP5036_OUT16_CLR, 0x00},
+ {LP5036_OUT17_CLR, 0x00},
+ {LP5036_OUT18_CLR, 0x00},
+ {LP5036_OUT19_CLR, 0x00},
+ {LP5036_OUT20_CLR, 0x00},
+ {LP5036_OUT21_CLR, 0x00},
+ {LP5036_OUT22_CLR, 0x00},
+ {LP5036_OUT23_CLR, 0x00},
+ {LP5036_OUT24_CLR, 0x00},
+ {LP5036_OUT25_CLR, 0x00},
+ {LP5036_OUT26_CLR, 0x00},
+ {LP5036_OUT27_CLR, 0x00},
+ {LP5036_OUT28_CLR, 0x00},
+ {LP5036_OUT29_CLR, 0x00},
+ {LP5036_OUT30_CLR, 0x00},
+ {LP5036_OUT31_CLR, 0x00},
+ {LP5036_OUT32_CLR, 0x00},
+ {LP5036_OUT33_CLR, 0x00},
+ {LP5036_OUT34_CLR, 0x00},
+ {LP5036_OUT35_CLR, 0x00},
+ {LP5036_RESET, 0x00}
+};
+
+static const struct regmap_config lp5012_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5012_RESET,
+ .reg_defaults = lp5012_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5012_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct regmap_config lp5024_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5024_RESET,
+ .reg_defaults = lp5024_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5024_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct regmap_config lp5036_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5036_RESET,
+ .reg_defaults = lp5036_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5036_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+enum lp50xx_model {
+ LP5009,
+ LP5012,
+ LP5018,
+ LP5024,
+ LP5030,
+ LP5036,
+};
+
+/*
+ * struct lp50xx_chip_info -
+ * @num_leds: number of LED outputs available on the device
+ * @led_brightness0_reg: first brightness register of the device
+ * @mix_out0_reg: first color mix register of the device
+ * @bank_brt_reg: bank brightness register
+ * @bank_mix_reg: color mix register
+ * @reset_reg: device reset register
+ */
+struct lp50xx_chip_info {
+ const struct regmap_config *lp50xx_regmap_config;
+ int model_id;
+ u8 max_modules;
+ u8 num_leds;
+ u8 led_brightness0_reg;
+ u8 mix_out0_reg;
+ u8 bank_brt_reg;
+ u8 bank_mix_reg;
+ u8 reset_reg;
+};
+
+static const struct lp50xx_chip_info lp50xx_chip_info_tbl[] = {
+ [LP5009] = {
+ .model_id = LP5009,
+ .max_modules = LP5009_MAX_LED_MODULES,
+ .num_leds = LP5009_MAX_LEDS,
+ .led_brightness0_reg = LP5012_LED0_BRT,
+ .mix_out0_reg = LP5012_OUT0_CLR,
+ .bank_brt_reg = LP5012_BNK_BRT,
+ .bank_mix_reg = LP5012_BNKA_CLR,
+ .reset_reg = LP5012_RESET,
+ .lp50xx_regmap_config = &lp5012_regmap_config,
+ },
+ [LP5012] = {
+ .model_id = LP5012,
+ .max_modules = LP5012_MAX_LED_MODULES,
+ .num_leds = LP5012_MAX_LEDS,
+ .led_brightness0_reg = LP5012_LED0_BRT,
+ .mix_out0_reg = LP5012_OUT0_CLR,
+ .bank_brt_reg = LP5012_BNK_BRT,
+ .bank_mix_reg = LP5012_BNKA_CLR,
+ .reset_reg = LP5012_RESET,
+ .lp50xx_regmap_config = &lp5012_regmap_config,
+ },
+ [LP5018] = {
+ .model_id = LP5018,
+ .max_modules = LP5018_MAX_LED_MODULES,
+ .num_leds = LP5018_MAX_LEDS,
+ .led_brightness0_reg = LP5024_LED0_BRT,
+ .mix_out0_reg = LP5024_OUT0_CLR,
+ .bank_brt_reg = LP5024_BNK_BRT,
+ .bank_mix_reg = LP5024_BNKA_CLR,
+ .reset_reg = LP5024_RESET,
+ .lp50xx_regmap_config = &lp5024_regmap_config,
+ },
+ [LP5024] = {
+ .model_id = LP5024,
+ .max_modules = LP5024_MAX_LED_MODULES,
+ .num_leds = LP5024_MAX_LEDS,
+ .led_brightness0_reg = LP5024_LED0_BRT,
+ .mix_out0_reg = LP5024_OUT0_CLR,
+ .bank_brt_reg = LP5024_BNK_BRT,
+ .bank_mix_reg = LP5024_BNKA_CLR,
+ .reset_reg = LP5024_RESET,
+ .lp50xx_regmap_config = &lp5024_regmap_config,
+ },
+ [LP5030] = {
+ .model_id = LP5030,
+ .max_modules = LP5030_MAX_LED_MODULES,
+ .num_leds = LP5030_MAX_LEDS,
+ .led_brightness0_reg = LP5036_LED0_BRT,
+ .mix_out0_reg = LP5036_OUT0_CLR,
+ .bank_brt_reg = LP5036_BNK_BRT,
+ .bank_mix_reg = LP5036_BNKA_CLR,
+ .reset_reg = LP5036_RESET,
+ .lp50xx_regmap_config = &lp5036_regmap_config,
+ },
+ [LP5036] = {
+ .model_id = LP5036,
+ .max_modules = LP5036_MAX_LED_MODULES,
+ .num_leds = LP5036_MAX_LEDS,
+ .led_brightness0_reg = LP5036_LED0_BRT,
+ .mix_out0_reg = LP5036_OUT0_CLR,
+ .bank_brt_reg = LP5036_BNK_BRT,
+ .bank_mix_reg = LP5036_BNKA_CLR,
+ .reset_reg = LP5036_RESET,
+ .lp50xx_regmap_config = &lp5036_regmap_config,
+ },
+};
+
+struct lp50xx_led {
+ struct led_classdev led_dev;
+ struct led_classdev_mc mc_cdev;
+ struct lp50xx *priv;
+ unsigned long bank_modules;
+ int led_intensity[LP50XX_LEDS_PER_MODULE];
+ u8 ctrl_bank_enabled;
+ int led_number;
+};
+
+/**
+ * struct lp50xx -
+ * @enable_gpio: hardware enable gpio
+ * @regulator: LED supply regulator pointer
+ * @client: pointer to the I2C client
+ * @regmap: device register map
+ * @dev: pointer to the devices device struct
+ * @lock: lock for reading/writing the device
+ * @chip_info: chip specific information (ie num_leds)
+ * @num_of_banked_leds: holds the number of banked LEDs
+ * @leds: array of LED strings
+ */
+struct lp50xx {
+ struct gpio_desc *enable_gpio;
+ struct regulator *regulator;
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct device *dev;
+ struct mutex lock;
+ const struct lp50xx_chip_info *chip_info;
+ int num_of_banked_leds;
+
+ /* This needs to be at the end of the struct */
+ struct lp50xx_led leds[];
+};
+
+static struct lp50xx_led *mcled_cdev_to_led(struct led_classdev_mc *mc_cdev)
+{
+ return container_of(mc_cdev, struct lp50xx_led, mc_cdev);
+}
+
+static int lp50xx_brightness_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
+ struct lp50xx_led *led = mcled_cdev_to_led(mc_dev);
+ const struct lp50xx_chip_info *led_chip = led->priv->chip_info;
+ u8 led_offset, reg_val;
+ int ret = 0;
+ int i;
+
+ mutex_lock(&led->priv->lock);
+ if (led->ctrl_bank_enabled)
+ reg_val = led_chip->bank_brt_reg;
+ else
+ reg_val = led_chip->led_brightness0_reg +
+ led->led_number;
+
+ ret = regmap_write(led->priv->regmap, reg_val, brightness);
+ if (ret) {
+ dev_err(&led->priv->client->dev,
+ "Cannot write brightness value %d\n", ret);
+ goto out;
+ }
+
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ if (led->ctrl_bank_enabled) {
+ reg_val = led_chip->bank_mix_reg + i;
+ } else {
+ led_offset = (led->led_number * 3) + i;
+ reg_val = led_chip->mix_out0_reg + led_offset;
+ }
+
+ ret = regmap_write(led->priv->regmap, reg_val,
+ mc_dev->subled_info[i].intensity);
+ if (ret) {
+ dev_err(&led->priv->client->dev,
+ "Cannot write intensity value %d\n", ret);
+ goto out;
+ }
+ }
+out:
+ mutex_unlock(&led->priv->lock);
+ return ret;
+}
+
+static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[])
+{
+ u8 led_config_lo, led_config_hi;
+ u32 bank_enable_mask = 0;
+ int ret;
+ int i;
+
+ for (i = 0; i < priv->chip_info->max_modules; i++) {
+ if (led_banks[i])
+ bank_enable_mask |= (1 << led_banks[i]);
+ }
+
+ led_config_lo = (u8)(bank_enable_mask & 0xff);
+ led_config_hi = (u8)(bank_enable_mask >> 8) & 0xff;
+
+ ret = regmap_write(priv->regmap, LP50XX_LED_CFG0, led_config_lo);
+ if (ret)
+ return ret;
+
+ if (priv->chip_info->model_id >= LP5030)
+ ret = regmap_write(priv->regmap, LP5036_LED_CFG1,
+ led_config_hi);
+
+ return ret;
+}
+
+static int lp50xx_reset(struct lp50xx *priv)
+{
+ if (priv->enable_gpio)
+ return gpiod_direction_output(priv->enable_gpio, 1);
+ else
+ return regmap_write(priv->regmap, priv->chip_info->reset_reg,
+ LP50XX_SW_RESET);
+}
+
+static int lp50xx_enable_disable(struct lp50xx *priv, u8 enable_disable)
+{
+ return regmap_write(priv->regmap, LP50XX_DEV_CFG0, enable_disable);
+}
+
+static int lp50xx_probe_dt(struct lp50xx *priv)
+{
+ u32 led_banks[LP5036_MAX_LED_MODULES] = {0};
+ struct fwnode_handle *child = NULL;
+ struct fwnode_handle *led_node = NULL;
+ struct led_init_data init_data = {};
+ struct led_classdev *led_cdev;
+ struct mc_subled *mc_led_info;
+ struct lp50xx_led *led;
+ int num_colors;
+ u32 color_id;
+ int led_number;
+ size_t i = 0;
+ int ret = -EINVAL;
+
+ priv->enable_gpio = devm_gpiod_get_optional(priv->dev,
+ "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(priv->enable_gpio)) {
+ ret = PTR_ERR(priv->enable_gpio);
+ dev_err(&priv->client->dev, "Failed to get enable gpio: %d\n",
+ ret);
+ return ret;
+ }
+
+ priv->regulator = devm_regulator_get(priv->dev, "vled");
+ if (IS_ERR(priv->regulator))
+ priv->regulator = NULL;
+
+ device_for_each_child_node(priv->dev, child) {
+ led = &priv->leds[i];
+ if (fwnode_property_present(child, "ti,led-bank")) {
+ ret = fwnode_property_count_u32(child, "ti,led-bank");
+ priv->num_of_banked_leds = ret;
+ if (priv->num_of_banked_leds >
+ priv->chip_info->max_modules) {
+ dev_err(&priv->client->dev,
+ "led-bank property is invalid\n");
+ ret = -EINVAL;
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ ret = fwnode_property_read_u32_array(child,
+ "ti,led-bank",
+ led_banks,
+ ret);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "led-bank property is missing\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ ret = lp50xx_set_banks(priv, led_banks);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "Cannot setup banked LEDs\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+ led->ctrl_bank_enabled = 1;
+
+ } else {
+ ret = fwnode_property_read_u32(child, "reg",
+ &led_number);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "led reg property missing\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ if (led_number > priv->chip_info->num_leds) {
+ dev_err(&priv->client->dev,
+ "led-sources property is invalid\n");
+ ret = -EINVAL;
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ led->led_number = led_number;
+ }
+
+ init_data.fwnode = child;
+ fwnode_property_read_string(child, "linux,default-trigger",
+ &led->led_dev.default_trigger);
+ num_colors = 0;
+
+ /* There are only 3 LEDs per module otherwise they should be
+ * banked which also is presented as 3 LEDs
+ */
+ mc_led_info = devm_kcalloc(priv->dev, LP50XX_LEDS_PER_MODULE,
+ sizeof(*mc_led_info), GFP_KERNEL);
+ if (!mc_led_info)
+ return -ENOMEM;
+
+ fwnode_for_each_child_node(child, led_node) {
+ ret = fwnode_property_read_u32(led_node, "color",
+ &color_id);
+ if (ret)
+ dev_err(priv->dev, "Cannot read color\n");
+
+ mc_led_info[num_colors].color_index = color_id;
+ num_colors++;
+ }
+
+ led->priv = priv;
+ led->mc_cdev.num_colors = num_colors;
+ led->mc_cdev.subled_info = mc_led_info;
+ led_cdev = &led->mc_cdev.led_cdev;
+ led_cdev->brightness_set_blocking = lp50xx_brightness_set;
+ ret = devm_led_classdev_multicolor_register_ext(&priv->client->dev,
+ &led->mc_cdev,
+ &init_data);
+ if (ret) {
+ dev_err(&priv->client->dev, "led register err: %d\n",
+ ret);
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+ i++;
+ }
+
+child_out:
+ return ret;
+}
+
+static int lp50xx_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct lp50xx *led;
+ int count;
+ int ret;
+
+ count = device_get_child_node_count(&client->dev);
+ if (!count) {
+ dev_err(&client->dev, "LEDs are not defined in device tree!");
+ return -ENODEV;
+ }
+
+ led = devm_kzalloc(&client->dev, struct_size(led, leds, count),
+ GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ mutex_init(&led->lock);
+ led->client = client;
+ led->dev = &client->dev;
+ led->chip_info = &lp50xx_chip_info_tbl[id->driver_data];
+ i2c_set_clientdata(client, led);
+ led->regmap = devm_regmap_init_i2c(client,
+ led->chip_info->lp50xx_regmap_config);
+ if (IS_ERR(led->regmap)) {
+ ret = PTR_ERR(led->regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = lp50xx_reset(led);
+ if (ret)
+ return ret;
+
+ ret = lp50xx_probe_dt(led);
+ if (ret)
+ return ret;
+
+ return lp50xx_enable_disable(led, LP50XX_CHIP_EN);
+}
+
+static int lp50xx_remove(struct i2c_client *client)
+{
+ struct lp50xx *led = i2c_get_clientdata(client);
+ int ret;
+
+ ret = lp50xx_enable_disable(led, LP50XX_CHIP_EN);
+ if (ret) {
+ dev_err(&led->client->dev, "Failed to disable regulator\n");
+ return ret;
+ }
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 0);
+
+ if (led->regulator) {
+ ret = regulator_disable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ mutex_destroy(&led->lock);
+
+ return 0;
+}
+
+static const struct i2c_device_id lp50xx_id[] = {
+ { "lp5009", LP5009 },
+ { "lp5012", LP5012 },
+ { "lp5018", LP5018 },
+ { "lp5024", LP5024 },
+ { "lp5030", LP5030 },
+ { "lp5036", LP5036 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, lp50xx_id);
+
+static const struct of_device_id of_lp50xx_leds_match[] = {
+ { .compatible = "ti,lp5009", .data = (void *)LP5009 },
+ { .compatible = "ti,lp5012", .data = (void *)LP5012 },
+ { .compatible = "ti,lp5018", .data = (void *)LP5018 },
+ { .compatible = "ti,lp5024", .data = (void *)LP5024 },
+ { .compatible = "ti,lp5030", .data = (void *)LP5030 },
+ { .compatible = "ti,lp5036", .data = (void *)LP5036 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lp50xx_leds_match);
+
+static struct i2c_driver lp50xx_driver = {
+ .driver = {
+ .name = "lp50xx",
+ .of_match_table = of_lp50xx_leds_match,
+ },
+ .probe = lp50xx_probe,
+ .remove = lp50xx_remove,
+ .id_table = lp50xx_id,
+};
+module_i2c_driver(lp50xx_driver);
+
+MODULE_DESCRIPTION("Texas Instruments LP50XX LED driver");
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
+MODULE_LICENSE("GPL v2");
--
2.26.2
^ permalink raw reply related
* [PATCH v26 04/15] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
can control RGB LEDs individually or as part of a control bank group.
These devices have the ability to adjust the mixing control for the RGB
LEDs to obtain different colors independent of the overall brightness of
the LED grouping.
Datasheet:
http://www.ti.com/lit/ds/symlink/lp5012.pdf
http://www.ti.com/lit/ds/symlink/lp5024.pdf
http://www.ti.com/lit/ds/symlink/lp5036.pdf
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/leds/leds-lp50xx.yaml | 136 ++++++++++++++++++
1 file changed, 136 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
new file mode 100644
index 000000000000..02fcdc13262f
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for LP50XX RGB LED from Texas Instruments.
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+description: |
+ The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into
+ a LED group or control them individually.
+
+ The difference in these RGB LED drivers is the number of supported RGB
+ modules.
+
+ For more product information please see the link below:
+ http://www.ti.com/lit/ds/symlink/lp5012.pdf
+ http://www.ti.com/lit/ds/symlink/lp5024.pdf
+ http://www.ti.com/lit/ds/symlink/lp5036.pdf
+
+properties:
+ #allOf:
+ #- $ref: "common.yaml#"
+ #- $ref: "leds-class-multicolor.yaml#"
+
+ compatible:
+ enum:
+ - ti,lp5009
+ - ti,lp5012
+ - ti,lp5018
+ - ti,lp5024
+ - ti,lp5030
+ - ti,lp5036
+
+ reg:
+ maxItems: 1
+ description:
+ I2C slave address
+ lp5009/12 - 0x14, 0x15, 0x16, 0x17
+ lp5018/24 - 0x28, 0x29, 0x2a, 0x2b
+ lp5030/36 - 0x30, 0x31, 0x32, 0x33
+
+ enable-gpios:
+ maxItems: 1
+ description: GPIO pin to enable/disable the device.
+
+ vled-supply:
+ description: LED supply.
+
+ child-node:
+ type: object
+ properties:
+ ti,led-bank:
+ description:
+ This property denotes the LED module numbers that will be controlled as
+ a single RGB cluster. Each LED module number will be controlled by a
+ single LED class instance.
+ There can only be one instance of the ti,led-bank
+ property for each device node. This is a required node if the LED
+ modules are to be banked.
+ $ref: /schemas/types.yaml#definitions/uint32-array
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@14 {
+ compatible = "ti,lp5009";
+ reg = <0x14>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-gpios = <&gpio1 16>;
+
+ multi-led@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_CHARGING;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
+ multi-led@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STANDBY;
+ ti,led-bank = <2 3 5>;
+
+ led@6 {
+ reg = <0x6>;
+ color = <LED_COLOR_ID_RED>;
+ led-sources = <6 9 15>;
+ };
+
+ led@7 {
+ reg = <0x7>;
+ color = <LED_COLOR_ID_GREEN>;
+ led-sources = <7 10 16>;
+ };
+
+ led@8 {
+ reg = <0x8>;
+ color = <LED_COLOR_ID_BLUE>;
+ led-sources = <8 11 17>;
+ };
+ };
+ };
+ };
--
2.26.2
^ permalink raw reply related
* [PATCH v26 03/15] leds: multicolor: Introduce a multicolor class definition
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Introduce a multicolor class that groups colored LEDs
within a LED node.
The multi color class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../ABI/testing/sysfs-class-led-multicolor | 34 +++
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 88 ++++++++
MAINTAINERS | 8 +
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile | 1 +
drivers/leds/led-class-multicolor.c | 210 ++++++++++++++++++
include/linux/led-class-multicolor.h | 121 ++++++++++
8 files changed, 473 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/leds/leds-class-multicolor.rst
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 include/linux/led-class-multicolor.h
diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor
new file mode 100644
index 000000000000..7d33a82a4b07
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-multicolor
@@ -0,0 +1,34 @@
+What: /sys/class/leds/<led>/brightness
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <dmurphy@ti.com>
+Description: read/write
+ Writing to this file will update all LEDs within the group to a
+ calculated percentage of what each color LED intensity is set
+ to. The percentage is calculated for each grouped LED via the
+ equation below:
+
+ led_brightness = brightness * multi_intensity/max_brightness
+
+ For additional details please refer to
+ Documentation/leds/leds-class-multicolor.rst.
+
+ The value of the color is from 0 to
+ /sys/class/leds/<led>/max_brightness.
+
+What: /sys/class/leds/<led>/multi_index
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <dmurphy@ti.com>
+Description: read
+ The multi_index array, when read, will output the LED colors
+ by name as they are indexed in the multi_intensity file.
+
+What: /sys/class/leds/<led>/multi_intensity
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <dmurphy@ti.com>
+Description: read/write
+ Intensity level for the LED color within the array.
+ The intensities for each color must be entered based on the
+ multi_index array.
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index 060f4e485897..bc70c6aa7138 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -9,6 +9,7 @@ LEDs
leds-class
leds-class-flash
+ leds-class-multicolor
ledtrig-oneshot
ledtrig-transient
ledtrig-usbport
diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst
new file mode 100644
index 000000000000..2dcde711c51c
--- /dev/null
+++ b/Documentation/leds/leds-class-multicolor.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================================
+MultiColor LED handling under Linux
+====================================
+
+Description
+===========
+The multicolor class groups monochrome LEDs and allows controlling two
+aspects of the final combined color: hue and lightness. The former is
+controlled via the multi_intensity array file and the latter is controlled
+via brightness file.
+
+Multicolor Class Control
+========================
+The multicolor class presents files that groups the colors as indexes in an
+array. These files are children under the LED parent node created by the
+led_class framework. The led_class framework is documented in led-class.rst
+within this documentation directory.
+
+Each colored LED will be indexed under the multi_* files. The order of the
+colors will be arbitrary. The multi_index file can be read to determine the
+color name to indexed value.
+
+The multi_index file is an array that contains the string list of the colors as
+they are defined in each multi_* array file.
+
+The multi_intensity is an array that can be read or written to for the
+individual color intensities. All elements within this array must be written in
+order for the color LED intensities to be updated.
+
+Directory Layout Example
+========================
+root:/sys/class/leds/multicolor:status# ls -lR
+-rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness
+-r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness
+-r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index
+-rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity
+
+Multicolor Class Brightness Control
+===================================
+The multicolor class framework will calculate each monochrome LEDs intensity.
+
+The brightness level for each LED is calculated based on the color LED
+intensity setting divided by the global max_brightness setting multiplied by
+the requested brightness.
+
+led_brightness = brightness * multi_intensity/max_brightness
+
+Example:
+A user first writes the multi_intensity file with the brightness levels
+for each LED that are necessary to achieve a certain color output from a
+multicolor LED group.
+
+cat /sys/class/leds/multicolor:status/multi_index
+green blue red
+
+echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity
+
+red -
+ intensity = 138
+ max_brightness = 255
+green -
+ intensity = 43
+ max_brightness = 255
+blue -
+ intensity = 226
+ max_brightness = 255
+
+The user can control the brightness of that multicolor LED group by writing the
+global 'brightness' control. Assuming a max_brightness of 255 the user
+may want to dim the LED color group to half. The user would write a value of
+128 to the global brightness file then the values written to each LED will be
+adjusted base on this value.
+
+cat /sys/class/leds/multicolor:status/max_brightness
+255
+echo 128 > /sys/class/leds/multicolor:status/brightness
+
+adjusted_red_value = 128 * 138/255 = 69
+adjusted_green_value = 128 * 43/255 = 21
+adjusted_blue_value = 128 * 226/255 = 113
+
+Reading the global brightness file will return the current brightness value of
+the color LED group.
+
+cat /sys/class/leds/multicolor:status/brightness
+128
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db31497..e5f0c3c17bea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9533,6 +9533,14 @@ F: Documentation/devicetree/bindings/leds/
F: drivers/leds/
F: include/linux/leds.h
+LED MULTICOLOR FRAMEWORK
+M: Dan Murphy <dmurphy@ti.com>
+L: linux-leds@vger.kernel.org
+S: Maintained
+F: Documentation/leds/leds-class-multicolor.rst
+F: drivers/leds/led-class-multicolor.c
+F: include/linux/led-class-multicolor.h
+
LEGACY EEPROM DRIVER
M: Jean Delvare <jdelvare@suse.com>
S: Maintained
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9cdc4cfc5d11..fe7d90d4fa23 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -30,6 +30,16 @@ config LEDS_CLASS_FLASH
for the flash related features of a LED device. It can be built
as a module.
+config LEDS_CLASS_MULTI_COLOR
+ tristate "LED MultiColor LED Class Support"
+ depends on LEDS_CLASS
+ help
+ This option enables the multicolor LED sysfs class in /sys/class/leds.
+ It wraps LED class and adds multicolor LED specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for multicolor LEDs that are grouped together. This class is not
+ intended for single color LEDs. It can be built as a module.
+
config LEDS_BRIGHTNESS_HW_CHANGED
bool "LED Class brightness_hw_changed attribute support"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d0dff504f108..53bf92f30258 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
+obj-$(CONFIG_LEDS_CLASS_MULTI_COLOR) += led-class-multicolor.o
obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers (keep this sorted, M-| sort)
diff --git a/drivers/leds/led-class-multicolor.c b/drivers/leds/led-class-multicolor.c
new file mode 100644
index 000000000000..c108f4860fd7
--- /dev/null
+++ b/drivers/leds/led-class-multicolor.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+// LED Multi Color class interface
+// Copyright (C) 2019-20 Texas Instruments Incorporated - http://www.ti.com/
+// Author: Dan Murphy <dmurphy@ti.com>
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/led-class-multicolor.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+#include "leds.h"
+
+int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev *led_cdev = &mcled_cdev->led_cdev;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++)
+ mcled_cdev->subled_info[i].brightness = brightness *
+ mcled_cdev->subled_info[i].intensity /
+ led_cdev->max_brightness;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(led_mc_calc_color_components);
+
+static ssize_t multi_intensity_store(struct device *dev,
+ struct device_attribute *intensity_attr,
+ const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int nrchars, offset = 0;
+ int intensity_value[LED_COLOR_ID_MAX];
+ int i;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ ret = sscanf(buf + offset, "%i%n",
+ &intensity_value[i], &nrchars);
+ if (ret != 1) {
+ dev_dbg(led_cdev->dev,
+ "Incorrect number of LEDs expected %i values intensity was not applied\n",
+ mcled_cdev->num_colors);
+ ret = -EINVAL;
+ goto err_out;
+ }
+ offset += nrchars;
+ }
+
+ /* account for the space at the end of the buffer */
+ offset++;
+ if (offset < size) {
+ dev_dbg(led_cdev->dev,
+ "Incorrect number of LEDs expected %i values intensity was not applied\n",
+ mcled_cdev->num_colors);
+ ret = -EINVAL;
+ goto err_out;
+ }
+
+ for (i = 0; i < mcled_cdev->num_colors; i++)
+ mcled_cdev->subled_info[i].intensity = intensity_value[i];
+
+ led_set_brightness(led_cdev, led_cdev->brightness);
+ ret = size;
+err_out:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t multi_intensity_show(struct device *dev,
+ struct device_attribute *intensity_attr,
+ char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int len = 0;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ len += sprintf(buf + len, "%d",
+ mcled_cdev->subled_info[i].intensity);
+ if (i < mcled_cdev->num_colors)
+ len += sprintf(buf + len, " ");
+ }
+
+ len += sprintf(buf + len, "\n");
+ return len;
+}
+static DEVICE_ATTR_RW(multi_intensity);
+
+static ssize_t multi_index_show(struct device *dev,
+ struct device_attribute *multi_index_attr,
+ char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int len = 0;
+ int index;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ index = mcled_cdev->subled_info[i].color_index;
+ len += sprintf(buf + len, "%s", led_colors[index]);
+ if (i < mcled_cdev->num_colors)
+ len += sprintf(buf + len, " ");
+ }
+
+ len += sprintf(buf + len, "\n");
+ return len;
+}
+static DEVICE_ATTR_RO(multi_index);
+
+static struct attribute *led_multicolor_attrs[] = {
+ &dev_attr_multi_intensity.attr,
+ &dev_attr_multi_index.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(led_multicolor);
+
+int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ struct led_classdev *led_cdev;
+
+ if (!mcled_cdev)
+ return -EINVAL;
+
+ if (!mcled_cdev->num_colors)
+ return -EINVAL;
+
+ if (mcled_cdev->num_colors > LED_COLOR_ID_MAX)
+ return -EINVAL;
+
+ led_cdev = &mcled_cdev->led_cdev;
+ mcled_cdev->led_cdev.groups = led_multicolor_groups;
+
+ return led_classdev_register_ext(parent, led_cdev, init_data);
+}
+EXPORT_SYMBOL_GPL(led_classdev_multicolor_register_ext);
+
+void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev)
+{
+ if (!mcled_cdev)
+ return;
+
+ led_classdev_unregister(&mcled_cdev->led_cdev);
+}
+EXPORT_SYMBOL_GPL(led_classdev_multicolor_unregister);
+
+static void devm_led_classdev_multicolor_release(struct device *dev, void *res)
+{
+ led_classdev_multicolor_unregister(*(struct led_classdev_mc **)res);
+}
+
+int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ struct led_classdev_mc **dr;
+ int ret;
+
+ dr = devres_alloc(devm_led_classdev_multicolor_release,
+ sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ ret = led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ init_data);
+ if (ret) {
+ devres_free(dr);
+ return ret;
+ }
+
+ *dr = mcled_cdev;
+ devres_add(parent, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_multicolor_register_ext);
+
+static int devm_led_classdev_multicolor_match(struct device *dev,
+ void *res, void *data)
+{
+ struct led_classdev_mc **p = res;
+
+ if (WARN_ON(!p || !*p))
+ return 0;
+
+ return *p == data;
+}
+
+void devm_led_classdev_multicolor_unregister(struct device *dev,
+ struct led_classdev_mc *mcled_cdev)
+{
+ WARN_ON(devres_release(dev,
+ devm_led_classdev_multicolor_release,
+ devm_led_classdev_multicolor_match, mcled_cdev));
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_multicolor_unregister);
+
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
+MODULE_DESCRIPTION("Multi Color LED class interface");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/led-class-multicolor.h b/include/linux/led-class-multicolor.h
new file mode 100644
index 000000000000..50bd986497f0
--- /dev/null
+++ b/include/linux/led-class-multicolor.h
@@ -0,0 +1,121 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* LED Multicolor class interface
+ * Copyright (C) 2019-20 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#ifndef _LINUX_MULTICOLOR_LEDS_H_INCLUDED
+#define _LINUX_MULTICOLOR_LEDS_H_INCLUDED
+
+#include <linux/leds.h>
+#include <dt-bindings/leds/common.h>
+
+struct mc_subled {
+ int color_index;
+ int brightness;
+ int intensity;
+ int channel;
+};
+
+struct led_classdev_mc {
+ /* led class device */
+ struct led_classdev led_cdev;
+ int num_colors;
+
+ struct mc_subled *subled_info;
+};
+
+static inline struct led_classdev_mc *lcdev_to_mccdev(
+ struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct led_classdev_mc, led_cdev);
+}
+
+#if IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR)
+/**
+ * led_classdev_multicolor_register_ext - register a new object of led_classdev
+ * class with support for multicolor LEDs
+ * @parent: the multicolor LED to register
+ * @mcled_cdev: the led_classdev_mc structure for this device
+ * @init_data: the LED class Multi color device initialization data
+ *
+ * Returns: 0 on success or negative error value on failure
+ */
+int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data);
+
+static inline int led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
+}
+
+/**
+ * led_classdev_multicolor_unregister - unregisters an object of led_classdev
+ * class with support for multicolor LEDs
+ * @mcled_cdev: the multicolor LED to unregister
+ *
+ * Unregister a previously registered via led_classdev_multicolor_register
+ * object
+ */
+void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev);
+
+/* Calculate brightness for the monochrome LED cluster */
+int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness);
+
+int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data);
+
+static inline int devm_led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return devm_led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ NULL);
+}
+
+void devm_led_classdev_multicolor_unregister(struct device *parent,
+ struct led_classdev_mc *mcled_cdev);
+#else
+
+static inline int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ return -EINVAL;
+}
+
+static inline int led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
+}
+
+static inline void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev) {};
+static inline int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness)
+{
+ return -EINVAL;
+}
+
+static inline int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ return -EINVAL;
+}
+
+static inline int devm_led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return devm_led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ NULL);
+}
+
+static inline void devm_led_classdev_multicolor_unregister(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{};
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR) */
+#endif /* _LINUX_MULTICOLOR_LEDS_H_INCLUDED */
--
2.26.2
^ permalink raw reply related
* [PATCH v26 01/15] dt: bindings: Add multicolor class dt bindings documention
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy, Rob Herring
In-Reply-To: <20200604120504.32425-1-dmurphy@ti.com>
Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID to the color ID list for device tree bindings.
CC: Rob Herring <robh@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../bindings/leds/leds-class-multicolor.yaml | 39 +++++++++++++++++++
include/dt-bindings/leds/common.h | 3 +-
2 files changed, 41 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
new file mode 100644
index 000000000000..6cab2a1405e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for the multicolor LED class.
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+description: |
+ Bindings for multi color LEDs show how to describe current outputs of
+ either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV
+ etc.) or standalone LEDs, to achieve logically grouped multi-color LED
+ modules. This is achieved by adding multi-led nodes layer to the
+ monochrome LED bindings.
+ The nodes and properties defined in this document are unique to the multicolor
+ LED class. Common LED nodes and properties are inherited from the common.txt
+ within this documentation directory.
+
+patternProperties:
+ "^multi-led@([0-9a-f])$":
+ type: object
+ description: Represents the LEDs that are to be grouped.
+ properties:
+ #allOf:
+ #- $ref: "common.yaml#"
+
+ color:
+ $ref: /schemas/types.yaml#definitions/uint32
+ const: 8 # LED_COLOR_ID_MULTI
+ description: |
+ For multicolor LED support this property should be defined as
+ LED_COLOR_ID_MULTI which can be found in include/linux/leds/common.h.
+
+ required:
+ - color
+...
diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
index 0ce7dfc00dcb..a463ce6a8794 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -30,7 +30,8 @@
#define LED_COLOR_ID_VIOLET 5
#define LED_COLOR_ID_YELLOW 6
#define LED_COLOR_ID_IR 7
-#define LED_COLOR_ID_MAX 8
+#define LED_COLOR_ID_MULTI 8
+#define LED_COLOR_ID_MAX 9
/* Standard LED functions */
/* Keyboard LEDs, usually it would be input4::capslock etc. */
--
2.26.2
^ permalink raw reply related
* [PATCH v26 00/15] Multicolor Framework v26
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
Hello
This is the multi color LED framework. This framework presents clustered
colored LEDs into an array and allows the user space to adjust the brightness
of the cluster using a single file write. The individual colored LEDs
intensities are controlled via a single file that is an array of LEDs
Dan
Dan Murphy (15):
dt: bindings: Add multicolor class dt bindings documention
leds: Add multicolor ID to the color ID list
leds: multicolor: Introduce a multicolor class definition
dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
leds: lp50xx: Add the LP50XX family of the RGB LED driver
dt-bindings: leds: Convert leds-lp55xx to yaml
ARM: dts: n900: Add reg property to the LP5523 channel node
ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
leds: lp55xx: Convert LED class registration to devm_*
leds: lp55xx: Add multicolor framework support to lp55xx
leds: lp5523: Update the lp5523 code to add multicolor brightness
function
leds: lp5521: Add multicolor framework multicolor brightness support
leds: lp55xx: Fix checkpatch file permissions issues
leds: lp5523: Fix checkpatch issues in the code
.../ABI/testing/sysfs-class-led-multicolor | 34 +
.../bindings/leds/leds-class-multicolor.yaml | 39 +
.../devicetree/bindings/leds/leds-lp50xx.yaml | 136 +++
.../devicetree/bindings/leds/leds-lp55xx.txt | 228 -----
.../devicetree/bindings/leds/leds-lp55xx.yaml | 220 +++++
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 88 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 +-
arch/arm/boot/dts/omap3-n900.dts | 29 +-
arch/arm/boot/dts/ste-href.dtsi | 22 +-
drivers/leds/Kconfig | 24 +
drivers/leds/Makefile | 2 +
drivers/leds/led-class-multicolor.c | 210 +++++
drivers/leds/led-core.c | 1 +
drivers/leds/leds-lp50xx.c | 778 ++++++++++++++++++
drivers/leds/leds-lp5521.c | 43 +-
drivers/leds/leds-lp5523.c | 62 +-
drivers/leds/leds-lp5562.c | 22 +-
drivers/leds/leds-lp55xx-common.c | 212 +++--
drivers/leds/leds-lp55xx-common.h | 16 +-
drivers/leds/leds-lp8501.c | 23 +-
include/dt-bindings/leds/common.h | 3 +-
include/linux/led-class-multicolor.h | 121 +++
include/linux/platform_data/leds-lp55xx.h | 8 +
25 files changed, 1989 insertions(+), 355 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
create mode 100644 Documentation/leds/leds-class-multicolor.rst
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 drivers/leds/leds-lp50xx.c
create mode 100644 include/linux/led-class-multicolor.h
--
2.26.2
^ permalink raw reply
* [PATCH v26 00/15] Multicolor Framework v25
From: Dan Murphy @ 2020-06-04 12:04 UTC (permalink / raw)
To: jacek.anaszewski, pavel; +Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
Hello
This is the multi color LED framework. This framework presents clustered
colored LEDs into an array and allows the user space to adjust the brightness
of the cluster using a single file write. The individual colored LEDs
intensities are controlled via a single file that is an array of LEDs
Dan
Dan Murphy (15):
dt: bindings: Add multicolor class dt bindings documention
leds: Add multicolor ID to the color ID list
leds: multicolor: Introduce a multicolor class definition
dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
leds: lp50xx: Add the LP50XX family of the RGB LED driver
dt-bindings: leds: Convert leds-lp55xx to yaml
ARM: dts: n900: Add reg property to the LP5523 channel node
ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
leds: lp55xx: Convert LED class registration to devm_*
leds: lp55xx: Add multicolor framework support to lp55xx
leds: lp5523: Update the lp5523 code to add multicolor brightness
function
leds: lp5521: Add multicolor framework multicolor brightness support
leds: lp55xx: Fix checkpatch file permissions issues
leds: lp5523: Fix checkpatch issues in the code
.../ABI/testing/sysfs-class-led-multicolor | 34 +
.../bindings/leds/leds-class-multicolor.yaml | 39 +
.../devicetree/bindings/leds/leds-lp50xx.yaml | 136 +++
.../devicetree/bindings/leds/leds-lp55xx.txt | 228 -----
.../devicetree/bindings/leds/leds-lp55xx.yaml | 220 +++++
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 88 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 +-
arch/arm/boot/dts/omap3-n900.dts | 29 +-
arch/arm/boot/dts/ste-href.dtsi | 22 +-
drivers/leds/Kconfig | 24 +
drivers/leds/Makefile | 2 +
drivers/leds/led-class-multicolor.c | 210 +++++
drivers/leds/led-core.c | 1 +
drivers/leds/leds-lp50xx.c | 778 ++++++++++++++++++
drivers/leds/leds-lp5521.c | 43 +-
drivers/leds/leds-lp5523.c | 62 +-
drivers/leds/leds-lp5562.c | 22 +-
drivers/leds/leds-lp55xx-common.c | 212 +++--
drivers/leds/leds-lp55xx-common.h | 16 +-
drivers/leds/leds-lp8501.c | 23 +-
include/dt-bindings/leds/common.h | 3 +-
include/linux/led-class-multicolor.h | 121 +++
include/linux/platform_data/leds-lp55xx.h | 8 +
25 files changed, 1989 insertions(+), 355 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
delete mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.txt
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp55xx.yaml
create mode 100644 Documentation/leds/leds-class-multicolor.rst
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 drivers/leds/leds-lp50xx.c
create mode 100644 include/linux/led-class-multicolor.h
--
2.26.2
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8250: add watchdog device
From: Sai Prakash Ranjan @ 2020-06-04 11:51 UTC (permalink / raw)
To: Manivannan Sadhasivam, Bjorn Andersson
Cc: Dmitry Baryshkov, Andy Gross, Rob Herring, linux-arm-msm,
devicetree, patches, linaro-kernel, devicetree-owner
In-Reply-To: <20200604113544.GF16719@Mani-XPS-13-9360>
On 2020-06-04 17:05, Manivannan Sadhasivam wrote:
> On Thu, Jun 04, 2020 at 04:37:01PM +0530, Sai Prakash Ranjan wrote:
>> On 2020-06-04 06:13, Dmitry Baryshkov wrote:
>> > Add on-SoC watchdog device node.
>> >
>> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>> > ---
>> > arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++++++
>> > 1 file changed, 6 insertions(+)
>> >
>> > diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> > b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> > index 972d8e04c8a2..f1641c6fe203 100644
>> > --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> > +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
>> > @@ -1662,6 +1662,12 @@ config {
>> > };
>> > };
>> >
>> > + watchdog@17c10000 {
>> > + compatible = "qcom,apss-wdt-sm8250", "qcom,kpss-wdt";
>>
>> Need to add this compatible to bindings.
>>
>
> I did look into this but the binding says,
> "compatible : shall contain only one of the following"
>
> So clearly the fallback is not going to work and there is no need to
> add a
> dedicated compatible in the driver. The binding is not in the YAML
> format to
> be validated but still... Other option is to convert the binding to
> YAML and
> make the compatibles listed as 'enum' and 'const' elements
> appropriately.
>
I already converted the bindings to YAML and added the missing
compatibles for
other SoCs[1] . I thought it was already merged since Rob has already
reviewed
them, but seems like it was missed. Bjorn, can you please take it?
[1] https://lore.kernel.org/patchwork/cover/1192757/
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8250: add watchdog device
From: Manivannan Sadhasivam @ 2020-06-04 11:35 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Herring,
linux-arm-msm, devicetree, patches, linaro-kernel,
devicetree-owner
In-Reply-To: <1a23cf8a6386e8b78c52199bdcde9b5e@codeaurora.org>
On Thu, Jun 04, 2020 at 04:37:01PM +0530, Sai Prakash Ranjan wrote:
> On 2020-06-04 06:13, Dmitry Baryshkov wrote:
> > Add on-SoC watchdog device node.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> > arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > index 972d8e04c8a2..f1641c6fe203 100644
> > --- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
> > @@ -1662,6 +1662,12 @@ config {
> > };
> > };
> >
> > + watchdog@17c10000 {
> > + compatible = "qcom,apss-wdt-sm8250", "qcom,kpss-wdt";
>
> Need to add this compatible to bindings.
>
I did look into this but the binding says,
"compatible : shall contain only one of the following"
So clearly the fallback is not going to work and there is no need to add a
dedicated compatible in the driver. The binding is not in the YAML format to
be validated but still... Other option is to convert the binding to YAML and
make the compatibles listed as 'enum' and 'const' elements appropriately.
Thanks,
Mani
> Thanks,
> Sai
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings
From: Lukas Wunner @ 2020-06-04 11:21 UTC (permalink / raw)
To: Mark Brown
Cc: Florian Fainelli, linux-kernel, Rob Herring,
Nicolas Saenz Julienne, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
open list:SPI SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Martin Sperl
In-Reply-To: <20200604111325.GC6644@sirena.org.uk>
On Thu, Jun 04, 2020 at 12:13:25PM +0100, Mark Brown wrote:
> On Thu, Jun 04, 2020 at 06:20:38AM +0200, Lukas Wunner wrote:
> > On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote:
> > > The BCM2711 SoC features 5 SPI controllers which all share the same
> > > interrupt line, the SPI driver needs to support interrupt sharing,
> > > therefore use the chip specific compatible string to help with that.
>
> > You're saying above that the 5 controllers all share the interrupt
> > but below you're only changing the compatible string of 4 controllers.
>
> > So I assume spi0 still has its own interrupt and only the additional
> > 4 controllers present on the BCM2711/BCM7211 share their interrupt?
>
> Regardless of what's going on with the interrupts the compatible string
> should reflect the IP version so unless for some reason someone taped
> out two different versions of the IP it seems odd that the compatible
> strings would vary within a given SoC.
Hm. I guess it may be possible to search the DT for other devices
sharing the same interrupt line and thereby determine whether
IRQF_SHARED is necessary. The helper to perform this search could
live in drivers/of/irq.c as I imagine it might be useful in general.
^ permalink raw reply
* Re: [Freedreno] [PATCH] drm/msm/dpu: ensure device suspend happens during PM sleep
From: kalyan_t @ 2020-06-04 11:19 UTC (permalink / raw)
To: Doug Anderson
Cc: Sean Paul,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
mkrishn, travitej, linux-arm-msm, LKML, dri-devel, Rob Clark,
nganji, Kristian H. Kristensen, freedreno, Jeykumar Sankaran
In-Reply-To: <CAD=FV=XphGpmBwZdL0jZ5HEFdxY3L7nH+s9_A0Kjamtg7j3R9w@mail.gmail.com>
On 2020-05-28 03:41, Doug Anderson wrote:
> Hi,
>
> On Fri, May 15, 2020 at 9:37 AM Doug Anderson <dianders@chromium.org>
> wrote:
>>
>> Hi,
>>
>> On Fri, May 15, 2020 at 5:06 AM <kalyan_t@codeaurora.org> wrote:
>> >
>> > On 2020-05-14 21:47, Doug Anderson wrote:
>> > > Hi,
>> > >
>> > > On Fri, May 1, 2020 at 6:31 AM Kalyan Thota <kalyan_t@codeaurora.org>
>> > > wrote:
>> > >>
>> > >> "The PM core always increments the runtime usage counter
>> > >> before calling the ->suspend() callback and decrements it
>> > >> after calling the ->resume() callback"
>> > >>
>> > >> DPU and DSI are managed as runtime devices. When
>> > >> suspend is triggered, PM core adds a refcount on all the
>> > >> devices and calls device suspend, since usage count is
>> > >> already incremented, runtime suspend was not getting called
>> > >> and it kept the clocks on which resulted in target not
>> > >> entering into XO shutdown.
>> > >>
>> > >> Add changes to force suspend on runtime devices during pm sleep.
>> > >>
>> > >> Changes in v1:
>> > >> - Remove unnecessary checks in the function
>> > >> _dpu_kms_disable_dpu (Rob Clark).
>> > >>
>> > >> Changes in v2:
>> > >> - Avoid using suspend_late to reset the usagecount
>> > >> as suspend_late might not be called during suspend
>> > >> call failures (Doug).
>> > >>
>> > >> Changes in v3:
>> > >> - Use force suspend instead of managing device usage_count
>> > >> via runtime put and get API's to trigger callbacks (Doug).
>> > >>
>> > >> Changes in v4:
>> > >> - Check the return values of pm_runtime_force_suspend and
>> > >> pm_runtime_force_resume API's and pass appropriately (Doug).
>> > >>
>> > >> Changes in v5:
>> > >
>> > > Can you please put the version number properly in your subject? It's
>> > > really hard to tell one version of your patch from another.
>> > >
>> > >
>> > >> - With v4 patch, test cycle has uncovered issues in device resume.
>> > >>
>> > >> On bubs: cmd tx failures were seen as SW is sending panel off
>> > >> commands when the dsi resources are turned off.
>> > >>
>> > >> Upon suspend, DRM driver will issue a NULL composition to the
>> > >> dpu, followed by turning off all the HW blocks.
>> > >>
>> > >> v5 changes will serialize the NULL commit and resource unwinding
>> > >> by handling them under PM prepare and PM complete phases there by
>> > >> ensuring that clks are on when panel off commands are being
>> > >> processed.
>> > >
>> > > I'm still most definitely not an expert in how all the DRM pieces all
>> > > hook up together, but the solution you have in this patch seems wrong
>> > > to me. As far as I can tell the "prepare" state isn't supposed to be
>> > > actually doing the suspend work and here that's exactly what you're
>> > > doing. I think you should find a different solution to ensure
>> > > ordering is correct.
>> > >
>> > > -Doug
>> > >
>> >
>> > Hi,
>>
>> Quite honestly I'm probably not the right person to be reviewing this
>> code. I mostly just noticed one of your early patches and it looked
>> strange to me. Hopefully someone with actual experience in how all
>> the DRM components work together can actually review and see if this
>> makes sense. Maybe Sean would know better?
>>
>> That being said, let me at least look at what you're saying...
>>
>>
>> > Prepare and Complete are callbacks defined as part of Sleep and Resume
>> > sequence
>> >
>> > Entering PM SUSPEND the phases are : prepare --> suspend -->
>> > suspend_late --> suspend_noirq.
>> > While leaving PM SUSPEND the phases are: resume_noirq --> resume_early
>> > --> resume --> complete.
>>
>> Sure, it's part of the sequence. It's also documented in pm.h as:
>>
>> * The principal role of this callback is to prevent new children of
>> * the device from being registered after it has returned (the
>> driver's
>> * subsystem and generally the rest of the kernel is supposed to
>> prevent
>> * new calls to the probe method from being made too once @prepare()
>> has
>> * succeeded).
>>
>> It does not feel like that matches your usage of this call.
>>
>>
>> > The reason to push drm suspend handling to PM prepare phase is that
>> > parent here will trigger a modeset to turn off the timing and
>> > subsequently the panel.
>> > the child devices should not turn of their clocks before parent unwinds
>> > the composition. Hence they are serialized as per the sequence mentioned
>> > above.
>>
>> So the general model in Linux is that children suspend before their
>> parents, right? So you're saying that, in this case, the parent needs
>> to act on the child before the child suspends. Is that correct?
>>
>> Rather than hijacking the prepare/complete, I'd be at least slightly
>> inclined to move the other driver to turn off its clocks in
>> suspend_late and to turn them back on in resume_early? That seems to
>> be what was done in "analogix_dp-rockchip.c" to solve a similar
>> problem.
>>
>>
>> > A similar approach is taken by other driver that use drm framework. In
>> > this driver, the device registers for prepare and complete callbacks to
>> > handle drm_suspend and drm_resume.
>> > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/exynos/exynos_drm_drv.c#L163
>>
>> OK, if there is another driver in DRM then I guess I won't object too
>> strongly. Note that when searching for other drivers I noticed this
>> bit in todo.rst:
>>
>> * Most drivers (except i915 and nouveau) that use
>> * drm_atomic_helper_suspend/resume() can probably be converted to use
>> * drm_mode_config_helper_suspend/resume(). Also there's still
>> open-coded version
>> * of the atomic suspend/resume code in older atomic modeset drivers.
>>
>> Does anything get fixed if you do that? It seems like it'd cleanup
>> your code a bit so maybe worth doing anyway...
>>
>> ---
>>
>> I guess the last question I'd want resolved is why you have this
>> asymmetry:
>>
>> SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, msm_pm_resume)
>>
>> Why couldn't you use pm_runtime_force_resume()?
>
> I'm curious if you had answers to any of the questions I posed in my
> review.
>
> -Doug
1) i'll update the patch to use "drm_mode_config_helper_suspend/resume".
This will help in additional cleanup such as enabling FBDEV emulation in
the build.
2) For the asymmetry part,
pm_runtime_force_resume() was not waking up the device forcefully if
the usage count is 1. PM core thinks that if usage count is 1 then
device can be runtime resumed after suspend/resume sequence is complete.
This is true for all the child nodes and the parent node. Hence to
overcome that i used pm_runtime_resume on parent.
I have explored a bit on how to handle this cleanly, found an old thread
discussing on the similar problem
(https://lists.gt.net/linux/kernel/1556562 post no#4 Alan Stern ) the
suggestion was to use runtime API's directly in PM Suspend/Resume.
I have found few example implementations on similar lines.
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/media/platform/mtk-mdp/mtk_mdp_core.c#L279
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/media/i2c/ak7375.c#L273
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gnss/sirf.c#L377
I have changed the implementation on those lines in v6.
Summary of the flow now:
PM Sleep --> pm_prepare for parent ( Disable all the DRM CRTCs) -->
Suspend for child1, child2 ( turn off child clocks )--> Suspend for
parent (turn off parent clocks )
PM Wakeup --> Resume for child1, child2 ( force resume is inactive due
to usage count 1, but the call is needed to undo the force suspend
things ) --> Resume for Parent (turn on parent clocks ) --> PM_complete
for Parent.( By the time we reach here, PM core will remove the usage
count for all the children and they are ready for runtime resume. Parent
enables CRTCs which will runtime resume all the child clocks)
Let me know your views on it.
--Kalyan
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* [PATCH V2 0/2] Add SDHC interconnect bandwidth scaling
From: Pradeep P V K @ 2020-06-04 11:14 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
Add interconnect bandwidths for SDHC driver using OPP framework that
is required by SDHC driver based on the clock frequency and bus width
of the card. Otherwise, the system clocks may run at minimum clock
speed and thus affecting the performance.
This change is based on
[1] [Patch v8] Introduce OPP bandwidth bindings
(https://lkml.org/lkml/2020/5/12/493)
[2] [Patch v3 09/17] mmc: sdhci-msm: Fix error handling
for dev_pm_opp_of_add_table()
(https://lkml.org/lkml/2020/5/5/491)
[3] [RFC v6 2/2] dt-bindings: mmc: sdhci-msm: Add interconnect BW
scaling strings
(https://lkml.org/lkml/2020/3/23/409)
as there were no extra changes made on [3], retaining the Acked-by and
Reviewed-by sign-off from [3].
Pradeep P V K (2):
mmc: sdhci-msm: Add interconnect bandwidth scaling support
dt-bindings: mmc: sdhci-msm: Add interconnect BW scaling strings
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 18 ++++++++++++++++++
drivers/mmc/host/sdhci-msm.c | 13 +++++++++++++
2 files changed, 31 insertions(+)
--
changes since V1:
- Added dev_pm_opp_find_icc_paths() to check for icc paths.
^ permalink raw reply
* [PATCH V2 1/2] mmc: sdhci-msm: Add interconnect bandwidth scaling support
From: Pradeep P V K @ 2020-06-04 11:14 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
In-Reply-To: <1591269283-24084-1-git-send-email-ppvk@codeaurora.org>
Interconnect bandwidth scaling support is now added as a
part of OPP [1]. So, make sure interconnect driver is ready
before handling interconnect scaling.
This change is based on
[1] [Patch v8] Introduce OPP bandwidth bindings
(https://lkml.org/lkml/2020/5/12/493)
[2] [Patch v3] mmc: sdhci-msm: Fix error handling
for dev_pm_opp_of_add_table()
(https://lkml.org/lkml/2020/5/5/491)
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
---
drivers/mmc/host/sdhci-msm.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
index b277dd7..a13ff1b 100644
--- a/drivers/mmc/host/sdhci-msm.c
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -14,6 +14,7 @@
#include <linux/slab.h>
#include <linux/iopoll.h>
#include <linux/regulator/consumer.h>
+#include <linux/interconnect.h>
#include "sdhci-pltfm.h"
#include "cqhci.h"
@@ -2070,6 +2071,18 @@ static int sdhci_msm_probe(struct platform_device *pdev)
}
msm_host->bulk_clks[0].clk = clk;
+ /* Make sure that ICC driver is ready for interconnect bandwdith
+ * scaling before registering the device for OPP.
+ */
+ ret = dev_pm_opp_of_find_icc_paths(&pdev->dev, NULL);
+ if (ret) {
+ if (ret == -EPROBE_DEFER)
+ dev_info(&pdev->dev, "defer icc path: %d\n", ret);
+ else
+ dev_err(&pdev->dev, "failed to get icc path:%d\n", ret);
+ goto bus_clk_disable;
+ }
+
msm_host->opp_table = dev_pm_opp_set_clkname(&pdev->dev, "core");
if (IS_ERR(msm_host->opp_table)) {
ret = PTR_ERR(msm_host->opp_table);
--
1.9.1
^ permalink raw reply related
* [PATCH V2 2/2] dt-bindings: mmc: sdhci-msm: Add interconnect BW scaling strings
From: Pradeep P V K @ 2020-06-04 11:14 UTC (permalink / raw)
To: bjorn.andersson, adrian.hunter, robh+dt, ulf.hansson, vbadigan,
sboyd, georgi.djakov, mka
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree,
linux-mmc-owner, rnayak, sibis, matthias, Pradeep P V K
In-Reply-To: <1591269283-24084-1-git-send-email-ppvk@codeaurora.org>
Add interconnect bandwidth scaling supported strings for qcom-sdhci
controller.
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
index b8e1d2b..3b602fd 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
@@ -54,6 +54,21 @@ Required properties:
- qcom,dll-config: Chipset and Platform specific value. Use this field to
specify the DLL_CONFIG register value as per Hardware Programming Guide.
+Optional Properties:
+* Following bus parameters are required for interconnect bandwidth scaling:
+- interconnects: Pairs of phandles and interconnect provider specifier
+ to denote the edge source and destination ports of
+ the interconnect path.
+
+- interconnect-names: For sdhc, we have two main paths.
+ 1. Data path : sdhc to ddr
+ 2. Config path : cpu to sdhc
+ For Data interconnect path the name supposed to be
+ is "sdhc-ddr" and for config interconnect path it is
+ "cpu-sdhc".
+ Please refer to Documentation/devicetree/bindings/
+ interconnect/ for more details.
+
Example:
sdhc_1: sdhci@f9824900 {
@@ -71,6 +86,9 @@ Example:
clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
clock-names = "core", "iface";
+ interconnects = <&qnoc MASTER_SDCC_ID &qnoc SLAVE_DDR_ID>,
+ <&qnoc MASTER_CPU_ID &qnoc SLAVE_SDCC_ID>;
+ interconnect-names = "sdhc-ddr","cpu-sdhc";
qcom,dll-config = <0x000f642c>;
qcom,ddr-config = <0x80040868>;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v7 2/4] usb: dwc3: qcom: Add interconnect support in dwc3 driver
From: Stephen Boyd @ 2020-06-04 11:16 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Doug Anderson, Felipe Balbi,
Greg Kroah-Hartman, Mark Rutland, Matthias Kaehlcke, Rob Herring,
Sandeep Maheswaram
Cc: linux-arm-msm, linux-usb, devicetree, linux-kernel, Manu Gautam,
Chandana Kishori Chiluveru
In-Reply-To: <d9ccf188-4f00-d3ac-ba0f-73f06c087553@codeaurora.org>
Quoting Sandeep Maheswaram (Temp) (2020-06-04 02:43:09)
>
> On 6/3/2020 11:06 PM, Stephen Boyd wrote:
> > Quoting Sandeep Maheswaram (2020-03-31 22:15:43)
> >> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> >> index 1dfd024..d33ae86 100644
> >> --- a/drivers/usb/dwc3/dwc3-qcom.c
> >> +++ b/drivers/usb/dwc3/dwc3-qcom.c
> >> @@ -285,6 +307,101 @@ static int dwc3_qcom_resume(struct dwc3_qcom *qcom)
> >> return 0;
> >> }
> >>
> >> +
> >> +/**
> >> + * dwc3_qcom_interconnect_init() - Get interconnect path handles
> >> + * @qcom: Pointer to the concerned usb core.
> >> + *
> >> + */
> >> +static int dwc3_qcom_interconnect_init(struct dwc3_qcom *qcom)
> >> +{
> >> + struct device *dev = qcom->dev;
> >> + int ret;
> >> +
> >> + if (!device_is_bound(&qcom->dwc3->dev))
> >> + return -EPROBE_DEFER;
> > How is this supposed to work? I see that this was added in an earlier
> > revision of this patch series but there isn't any mention of why
> > device_is_bound() is used here. It would be great if there was a comment
> > detailing why this is necessary. It sounds like maximum_speed is
> > important?
> >
> > Furthermore, dwc3_qcom_interconnect_init() is called by
> > dwc3_qcom_probe() which is the function that registers the device for
> > qcom->dwc3->dev. If that device doesn't probe between the time it is
> > registered by dwc3_qcom_probe() and this function is called then we'll
> > fail dwc3_qcom_probe() with -EPROBE_DEFER. And that will remove the
> > qcom->dwc3->dev device from the platform bus because we call
> > of_platform_depopulate() on the error path of dwc3_qcom_probe().
> >
> > So isn't this whole thing racy and can potentially lead us to a driver
> > probe loop where the wrapper (dwc3_qcom) and the core (dwc3) are probing
> > and we're trying to time it just right so that driver for dwc3 binds
> > before we setup interconnects? I don't know if dwc3 can communicate to
> > the wrapper but that would be more of a direct way to do this. Or maybe
> > the wrapper should try to read the DT property for maximum speed and
> > fallback to a worst case high bandwidth value if it can't figure it out
> > itself without help from dwc3 core.
> >
> This was added in V4 to address comments from Matthias in V3
>
> https://patchwork.kernel.org/patch/11148587/
>
Yes, that why I said:
"I see that this was added in an earlier
revision of this patch series but there isn't any mention of why
device_is_bound() is used here. It would be great if there was a comment
detailing why this is necessary. It sounds like maximum_speed is
important?"
Can you please respond to the rest of my email?
^ permalink raw reply
* [PATCH net-next v6 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
Add the internal delay values into the header and update the binding
with the internal delay properties.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/net/ti,dp83869.yaml | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
index 5b69ef03bbf7..71e90a3e4652 100644
--- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
+++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
@@ -8,7 +8,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: TI DP83869 ethernet PHY
allOf:
- - $ref: "ethernet-controller.yaml#"
+ - $ref: "ethernet-phy.yaml#"
maintainers:
- Dan Murphy <dmurphy@ti.com>
@@ -64,6 +64,18 @@ properties:
Operational mode for the PHY. If this is not set then the operational
mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
+ rx-internal-delay-ps:
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
+ tx-internal-delay-ps:
+ description: Delay is in pico seconds
+ enum: [ 250, 500, 750, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000 ]
+ default: 2000
+
required:
- reg
@@ -80,5 +92,7 @@ examples:
ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
ti,max-output-impedance = "true";
ti,clk-output-sel = <DP83869_CLK_O_SEL_CHN_A_RCLK>;
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
};
};
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v6 0/4] RGMII Internal delay common property
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
Hello
The RGMII internal delay is a common setting found in most RGMII capable PHY
devices. It was found that many vendor specific device tree properties exist
to do the same function. This creates a common property to be used for PHY's
that have tunable internal delays for the Rx and Tx paths.
Dan Murphy (4):
dt-bindings: net: Add tx and rx internal delays
net: phy: Add a helper to return the index for of the internal delay
dt-bindings: net: Add RGMII internal delay for DP83869
net: dp83869: Add RGMII internal delay configuration
.../devicetree/bindings/net/ethernet-phy.yaml | 13 ++++
.../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++-
drivers/net/phy/dp83869.c | 53 ++++++++++++++-
drivers/net/phy/phy_device.c | 68 +++++++++++++++++++
include/linux/phy.h | 4 ++
5 files changed, 150 insertions(+), 4 deletions(-)
--
2.26.2
^ permalink raw reply
* [PATCH net-next v6 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
Add RGMII internal delay configuration for Rx and Tx.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/dp83869.c | 53 ++++++++++++++++++++++++++++++++++++---
1 file changed, 50 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83869.c b/drivers/net/phy/dp83869.c
index cfb22a21a2e6..801341edbe31 100644
--- a/drivers/net/phy/dp83869.c
+++ b/drivers/net/phy/dp83869.c
@@ -64,6 +64,10 @@
#define DP83869_RGMII_TX_CLK_DELAY_EN BIT(1)
#define DP83869_RGMII_RX_CLK_DELAY_EN BIT(0)
+/* RGMIIDCTL */
+#define DP83869_RGMII_CLK_DELAY_SHIFT 4
+#define DP83869_CLK_DELAY_DEF 7
+
/* STRAP_STS1 bits */
#define DP83869_STRAP_OP_MODE_MASK GENMASK(2, 0)
#define DP83869_STRAP_STS1_RESERVED BIT(11)
@@ -78,9 +82,6 @@
#define DP83869_PHYCR_FIFO_DEPTH_MASK GENMASK(15, 12)
#define DP83869_PHYCR_RESERVED_MASK BIT(11)
-/* RGMIIDCTL bits */
-#define DP83869_RGMII_TX_CLK_DELAY_SHIFT 4
-
/* IO_MUX_CFG bits */
#define DP83869_IO_MUX_CFG_IO_IMPEDANCE_CTRL 0x1f
@@ -99,6 +100,10 @@
#define DP83869_OP_MODE_MII BIT(5)
#define DP83869_SGMII_RGMII_BRIDGE BIT(6)
+static const int dp83869_internal_delay[] = {250, 500, 750, 1000, 1250, 1500,
+ 1750, 2000, 2250, 2500, 2750, 3000,
+ 3250, 3500, 3750, 4000};
+
enum {
DP83869_PORT_MIRRORING_KEEP,
DP83869_PORT_MIRRORING_EN,
@@ -108,6 +113,8 @@ enum {
struct dp83869_private {
int tx_fifo_depth;
int rx_fifo_depth;
+ s32 rx_id_delay;
+ s32 tx_id_delay;
int io_impedance;
int port_mirroring;
bool rxctrl_strap_quirk;
@@ -182,6 +189,7 @@ static int dp83869_of_init(struct phy_device *phydev)
struct dp83869_private *dp83869 = phydev->priv;
struct device *dev = &phydev->mdio.dev;
struct device_node *of_node = dev->of_node;
+ int delay_size = ARRAY_SIZE(dp83869_internal_delay);
int ret;
if (!of_node)
@@ -232,6 +240,20 @@ static int dp83869_of_init(struct phy_device *phydev)
&dp83869->tx_fifo_depth))
dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
+ dp83869->rx_id_delay = phy_get_internal_delay(phydev, dev,
+ &dp83869_internal_delay[0],
+ delay_size, true);
+ if (dp83869->rx_id_delay < 0)
+ dp83869->rx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+
+ dp83869->tx_id_delay = phy_get_internal_delay(phydev, dev,
+ &dp83869_internal_delay[0],
+ delay_size, false);
+ if (dp83869->tx_id_delay < 0)
+ dp83869->tx_id_delay =
+ dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
+
return ret;
}
#else
@@ -394,6 +416,31 @@ static int dp83869_config_init(struct phy_device *phydev)
dp83869->clk_output_sel <<
DP83869_IO_MUX_CFG_CLK_O_SEL_SHIFT);
+ if (phy_interface_is_rgmii(phydev)) {
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIIDCTL,
+ dp83869->rx_id_delay |
+ dp83869->tx_id_delay << DP83869_RGMII_CLK_DELAY_SHIFT);
+ if (ret)
+ return ret;
+
+ val = phy_read_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL);
+ val &= ~(DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ val |= (DP83869_RGMII_TX_CLK_DELAY_EN |
+ DP83869_RGMII_RX_CLK_DELAY_EN);
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ val |= DP83869_RGMII_TX_CLK_DELAY_EN;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ val |= DP83869_RGMII_RX_CLK_DELAY_EN;
+
+ ret = phy_write_mmd(phydev, DP83869_DEVADDR, DP83869_RGMIICTL,
+ val);
+ }
+
return ret;
}
--
2.26.2
^ permalink raw reply related
* [PATCH net-next v6 2/4] net: phy: Add a helper to return the index for of the internal delay
From: Dan Murphy @ 2020-06-04 11:14 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree, Dan Murphy
In-Reply-To: <20200604111410.17918-1-dmurphy@ti.com>
Add a helper function that will return the index in the array for the
passed in internal delay value. The helper requires the array, size and
delay value.
The helper will then return the index for the exact match or return the
index for the index to the closest smaller value.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/net/phy/phy_device.c | 68 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 4 +++
2 files changed, 72 insertions(+)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 04946de74fa0..611d4e68e3c6 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -31,6 +31,7 @@
#include <linux/mdio.h>
#include <linux/io.h>
#include <linux/uaccess.h>
+#include <linux/property.h>
MODULE_DESCRIPTION("PHY library");
MODULE_AUTHOR("Andy Fleming");
@@ -2657,6 +2658,73 @@ void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause)
}
EXPORT_SYMBOL(phy_get_pause);
+/**
+ * phy_get_delay_index - returns the index of the internal delay
+ * @phydev: phy_device struct
+ * @dev: pointer to the devices device struct
+ * @delay_values: array of delays the PHY supports
+ * @size: the size of the delay array
+ * @is_rx: boolean to indicate to get the rx internal delay
+ *
+ * Returns the index within the array of internal delay passed in.
+ * Or if size == 0 then the delay read from the firmware is returned.
+ * The array must be in ascending order.
+ * Return errno if the delay is invalid or cannot be found.
+ */
+s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
+ const int *delay_values, int size, bool is_rx)
+{
+ int ret;
+ int i;
+ s32 delay;
+
+ if (is_rx)
+ ret = device_property_read_u32(dev, "rx-internal-delay-ps",
+ &delay);
+ else
+ ret = device_property_read_u32(dev, "tx-internal-delay-ps",
+ &delay);
+ if (ret) {
+ phydev_err(phydev, "internal delay not defined\n");
+ return -EINVAL;
+ }
+
+ if (delay < 0)
+ return -EINVAL;
+
+ if (size <= 0)
+ return delay;
+
+ if (delay < delay_values[0] || delay > delay_values[size - 1]) {
+ phydev_err(phydev, "Delay %d is out of range\n", delay);
+ return -EINVAL;
+ }
+
+ if (delay == delay_values[0])
+ return 0;
+
+ for (i = 1; i < size; i++) {
+ if (delay == delay_values[i])
+ return i;
+
+ /* Find an approximate index by looking up the table */
+ if (delay > delay_values[i - 1] &&
+ delay < delay_values[i]) {
+ if (delay - delay_values[i - 1] <
+ delay_values[i] - delay)
+ return i - 1;
+ else
+ return i;
+ }
+ }
+
+ phydev_err(phydev, "error finding internal delay index for %d\n",
+ delay);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(phy_get_internal_delay);
+
static bool phy_drv_supports_irq(struct phy_driver *phydrv)
{
return phydrv->config_intr && phydrv->ack_interrupt;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8c05d0fb5c00..917bfd422e06 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -1430,6 +1430,10 @@ void phy_set_asym_pause(struct phy_device *phydev, bool rx, bool tx);
bool phy_validate_pause(struct phy_device *phydev,
struct ethtool_pauseparam *pp);
void phy_get_pause(struct phy_device *phydev, bool *tx_pause, bool *rx_pause);
+
+s32 phy_get_internal_delay(struct phy_device *phydev, struct device *dev,
+ const int *delay_values, int size, bool is_rx);
+
void phy_resolve_pause(unsigned long *local_adv, unsigned long *partner_adv,
bool *tx_pause, bool *rx_pause);
--
2.26.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox