Hello
This is a re-send of the v17 multi color LED framework. I removed the last
patch from the series. In addition I rebased this series on Pavel's for-next
LED branch and added all ACKs from the list.
Dan
Dan Murphy (17):
dt-bindings: leds: Add multicolor ID to the color ID list
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: lp55xx: Be consistent in the document with LED acronym
dt: bindings: lp55xx: Update binding for Multicolor Framework
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
dt: bindings: Update lp55xx binding to recommended LED naming
.../ABI/testing/sysfs-class-led-multicolor | 36 +
.../devicetree/bindings/leds/leds-lp50xx.txt | 148 ++++
.../devicetree/bindings/leds/leds-lp55xx.txt | 163 +++-
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 100 +++
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 | 22 +
drivers/leds/Makefile | 2 +
drivers/leds/led-class-multicolor.c | 272 ++++++
drivers/leds/led-core.c | 1 +
drivers/leds/leds-lp50xx.c | 799 ++++++++++++++++++
drivers/leds/leds-lp5521.c | 43 +-
drivers/leds/leds-lp5523.c | 62 +-
drivers/leds/leds-lp5562.c | 22 +-
drivers/leds/leds-lp55xx-common.c | 235 ++++--
drivers/leds/leds-lp55xx-common.h | 14 +-
drivers/leds/leds-lp8501.c | 23 +-
include/dt-bindings/leds/common.h | 3 +-
include/linux/led-class-multicolor.h | 139 +++
include/linux/platform_data/leds-lp55xx.h | 8 +
22 files changed, 1998 insertions(+), 160 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.txt
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.25.0
Update the document to be consistent in case when using "LED".
This acronym should be capital throughout the document.
Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
Documentation/devicetree/bindings/leds/leds-lp55xx.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
index 1b66a413fb9d..bfe2805c5534 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -1,4 +1,4 @@
-Binding for TI/National Semiconductor LP55xx Led Drivers
+Binding for TI/National Semiconductor LP55xx LED Drivers
Required properties:
- compatible: one of
@@ -12,8 +12,8 @@ Required properties:
- 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.
+- 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
--
2.25.0
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.
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp50xx.c | 799 +++++++++++++++++++++++++++++++++++++
3 files changed, 811 insertions(+)
create mode 100644 drivers/leds/leds-lp50xx.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 37dcdb06a29b..01c879005b83 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -363,6 +363,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
+ 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 310b5518783a..b5305b7d43fb 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_LEDS_GPIO_REGISTER) += leds-gpio-register.o
obj-$(CONFIG_LEDS_GPIO) += leds-gpio.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_LP55XX_COMMON) += leds-lp55xx-common.o
obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
new file mode 100644
index 000000000000..52246565f15d
--- /dev/null
+++ b/drivers/leds/leds-lp50xx.c
@@ -0,0 +1,799 @@
+// 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>
+
+#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 int lp50xx_brightness_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct lp50xx_led *led = container_of(cdev, struct lp50xx_led, led_dev);
+ const struct lp50xx_chip_info *led_chip = led->priv->chip_info;
+ struct led_mc_color_entry *color_data;
+ u8 led_offset, reg_val, reg_color_offset;
+ int ret = 0;
+
+ 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;
+ }
+
+ list_for_each_entry(color_data, &led->mc_cdev.color_list, list) {
+ if (color_data->led_color_id == LED_COLOR_ID_RED) {
+ reg_color_offset = 0;
+ } else if (color_data->led_color_id == LED_COLOR_ID_GREEN) {
+ reg_color_offset = 1;
+ } else if (color_data->led_color_id == LED_COLOR_ID_BLUE) {
+ reg_color_offset = 2;
+ } else {
+ dev_err(&led->priv->client->dev,
+ "LED color not found\n");
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (led->ctrl_bank_enabled) {
+ reg_val = led_chip->bank_mix_reg + reg_color_offset;
+ } else {
+ led_offset = (led->led_number * 3) + reg_color_offset;
+ reg_val = led_chip->mix_out0_reg + led_offset;
+ }
+
+ ret = regmap_write(led->priv->regmap, reg_val,
+ color_data->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 enum led_brightness lp50xx_brightness_get(struct led_classdev *cdev)
+{
+ struct lp50xx_led *led = container_of(cdev, struct lp50xx_led, led_dev);
+ const struct lp50xx_chip_info *led_chip = led->priv->chip_info;
+ unsigned int brt_val;
+ u8 reg_val;
+ int ret;
+
+ 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_read(led->priv->regmap, reg_val, &brt_val);
+
+ mutex_unlock(&led->priv->lock);
+
+ return brt_val;
+}
+
+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->num_leds; 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];
+ struct fwnode_handle *child = NULL;
+ struct fwnode_handle *led_node = NULL;
+ struct led_init_data init_data;
+ 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->client->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->client->dev, "vled");
+ if (IS_ERR(priv->regulator))
+ priv->regulator = NULL;
+
+ device_for_each_child_node(&priv->client->dev, child) {
+ led = &priv->leds[i];
+ if (fwnode_property_present(child, "ti,led-bank")) {
+ ret = fwnode_property_read_u32_array(child,
+ "ti,led-bank",
+ NULL, 0);
+ 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;
+
+ fwnode_for_each_child_node(child, led_node) {
+ ret = fwnode_property_read_u32(led_node, "color",
+ &color_id);
+ if (ret)
+ dev_err(&priv->client->dev,
+ "Cannot read color\n");
+
+ set_bit(color_id, &led->mc_cdev.available_colors);
+ num_colors++;
+
+ }
+
+ led->priv = priv;
+ led->mc_cdev.num_leds = num_colors;
+ led->mc_cdev.led_cdev = &led->led_dev;
+ led->led_dev.brightness_set_blocking = lp50xx_brightness_set;
+ led->led_dev.brightness_get = lp50xx_brightness_get;
+ 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 <[email protected]>");
+MODULE_LICENSE("GPL v2");
--
2.25.0
Add the reg property to each channel node. This update is
to accomodate the multicolor framework. In addition to the
accomodation 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 <[email protected]>
CC: Shawn Guo <[email protected]>
CC: Sascha Hauer <[email protected]>
CC: Pengutronix Kernel Team <[email protected]>
CC: Fabio Estevam <[email protected]>
CC: NXP Linux Team <[email protected]>
---
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 80ed5f16a76e..fe1a723b4dc9 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.25.0
Update the DT binding to include the properties to use the
multicolor framework for the devices that use the LP55xx
framework.
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Dan Murphy <[email protected]>
CC: Tony Lindgren <[email protected]>
CC: "Benoît Cousson" <[email protected]>
CC: Linus Walleij <[email protected]>
CC: Shawn Guo <[email protected]>
CC: Sascha Hauer <[email protected]>
CC: Pengutronix Kernel Team <[email protected]>
CC: Fabio Estevam <[email protected]>
CC: NXP Linux Team <[email protected]>
---
.../devicetree/bindings/leds/leds-lp55xx.txt | 149 +++++++++++++++---
1 file changed, 124 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
index bfe2805c5534..0ccc1efc2499 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -1,6 +1,8 @@
Binding for TI/National Semiconductor LP55xx LED Drivers
Required properties:
+- #address-cells: 1
+- #size-cells: 0
- compatible: one of
national,lp5521
national,lp5523
@@ -14,6 +16,18 @@ Required properties:
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.
+- reg: 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
Optional properties:
- enable-gpio: GPIO attached to the chip's enable pin
@@ -35,23 +49,28 @@ example 1) LP5521
on channel 0.
lp5521@32 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "national,lp5521";
reg = <0x32>;
label = "lp5521_pri";
clock-mode = /bits/ 8 <2>;
- chan0 {
+ 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>;
};
@@ -70,59 +89,70 @@ ASEL1 ASEL0 Address
VEN VEN 35h
lp5523@32 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "national,lp5523";
reg = <0x32>;
clock-mode = /bits/ 8 <1>;
- chan0 {
+ chan@0 {
+ reg = <0>;
chan-name = "d1";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan1 {
+ chan@1 {
+ reg = <1>;
chan-name = "d2";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan2 {
+ chan@2 {
+ reg = <2>;
chan-name = "d3";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan3 {
+ chan@3 {
+ reg = <3>;
chan-name = "d4";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan4 {
+ chan@4 {
+ reg = <4>;
chan-name = "d5";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan5 {
+ chan@5 {
+ reg = <5>;
chan-name = "d6";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan6 {
+ chan@6 {
+ reg = <6>;
chan-name = "d7";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan7 {
+ chan@7 {
+ reg = <7>;
chan-name = "d8";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan8 {
+ chan@8 {
+ reg = <8>;
chan-name = "d9";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
@@ -133,29 +163,35 @@ example 3) LP5562
4 channels are defined.
lp5562@30 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "ti,lp5562";
reg = <0x30>;
clock-mode = /bits/8 <2>;
- chan0 {
+ chan@0 {
+ reg = <0>;
chan-name = "R";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
- chan1 {
+ chan@1 {
+ reg = <1>;
chan-name = "G";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
- chan2 {
+ chan@2 {
+ reg = <2>;
chan-name = "B";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
- chan3 {
+ chan@3 {
+ reg = <3>;
chan-name = "W";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
@@ -167,62 +203,125 @@ example 4) LP8501
Others are same as LP5523.
lp8501@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 */
- chan0 {
+ chan@0 {
+ reg = <0>;
chan-name = "d1";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan1 {
+ chan@1 {
+ reg = <1>;
chan-name = "d2";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan2 {
+ chan@2 {
+ reg = <2>;
chan-name = "d3";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan3 {
+ chan@3 {
+ reg = <3>;
chan-name = "d4";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan4 {
+ chan@4 {
+ reg = <4>;
chan-name = "d5";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan5 {
+ chan@5 {
+ reg = <5>;
chan-name = "d6";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan6 {
+ chan@6 {
+ reg = <6>;
chan-name = "d7";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan7 {
+ chan@7 {
+ reg = <7>;
chan-name = "d8";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan8 {
+ chan@8 {
+ reg = <8>;
chan-name = "d9";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
};
+
+Multicolor Framework Support
+In addition to the nodes and properties defined above for device support the
+properties below are needed for multicolor framework support as defined in
+Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
+
+Required child properties for multicolor framework
+ - color : Must be LED_COLOR_ID_MULTI
+ - function : see Documentation/devicetree/bindings/leds/common.txt
+
+Required grandchildren properties
+ - reg : This is the LED output of the device
+ - color : see Documentation/devicetree/bindings/leds/common.txt
+
+Multicolor LED example:
+led-controller@32 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "national,lp5523";
+ reg = <0x32>;
+ clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */
+
+ multi-led@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ 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.25.0
Update the LP55xx DT binding examples to the recommended node
naming convention. There are no changes to the DT properties.
Signed-off-by: Dan Murphy <[email protected]>
CC: Rob Herring <[email protected]>
CC: Tony Lindgren <[email protected]>
CC: "Benoît Cousson" <[email protected]>
CC: Linus Walleij <[email protected]>
CC: Shawn Guo <[email protected]>
CC: Sascha Hauer <[email protected]>
CC: Pengutronix Kernel Team <[email protected]>
CC: Fabio Estevam <[email protected]>
CC: NXP Linux Team <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
.../devicetree/bindings/leds/leds-lp55xx.txt | 58 +++++++++----------
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
index 0ccc1efc2499..5475f45ef51f 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -48,7 +48,7 @@ example 1) LP5521
'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
on channel 0.
-lp5521@32 {
+led-controller@32 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "national,lp5521";
@@ -56,20 +56,20 @@ lp5521@32 {
label = "lp5521_pri";
clock-mode = /bits/ 8 <2>;
- chan@0 {
+ led@0 {
reg = <0>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
linux,default-trigger = "heartbeat";
};
- chan@1 {
+ led@1 {
reg = <1>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
};
- chan@2 {
+ led@2 {
reg = <2>;
led-cur = /bits/ 8 <0x2f>;
max-cur = /bits/ 8 <0x5f>;
@@ -88,70 +88,70 @@ ASEL1 ASEL0 Address
VEN GND 34h
VEN VEN 35h
-lp5523@32 {
+led-controller@32 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "national,lp5523";
reg = <0x32>;
clock-mode = /bits/ 8 <1>;
- chan@0 {
+ led@0 {
reg = <0>;
chan-name = "d1";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@1 {
+ led@1 {
reg = <1>;
chan-name = "d2";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@2 {
+ led@2 {
reg = <2>;
chan-name = "d3";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@3 {
+ led@3 {
reg = <3>;
chan-name = "d4";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@4 {
+ led@4 {
reg = <4>;
chan-name = "d5";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@5 {
+ led@5 {
reg = <5>;
chan-name = "d6";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@6 {
+ led@6 {
reg = <6>;
chan-name = "d7";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@7 {
+ led@7 {
reg = <7>;
chan-name = "d8";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@8 {
+ led@8 {
reg = <8>;
chan-name = "d9";
led-cur = /bits/ 8 <0x14>;
@@ -162,35 +162,35 @@ lp5523@32 {
example 3) LP5562
4 channels are defined.
-lp5562@30 {
+led-controller@30 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,lp5562";
reg = <0x30>;
clock-mode = /bits/8 <2>;
- chan@0 {
+ led@0 {
reg = <0>;
chan-name = "R";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
- chan@1 {
+ led@1 {
reg = <1>;
chan-name = "G";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
- chan@2 {
+ led@2 {
reg = <2>;
chan-name = "B";
led-cur = /bits/ 8 <0x20>;
max-cur = /bits/ 8 <0x60>;
};
- chan@3 {
+ led@3 {
reg = <3>;
chan-name = "W";
led-cur = /bits/ 8 <0x20>;
@@ -202,7 +202,7 @@ example 4) LP8501
9 channels are defined. The 'pwr-sel' is LP8501 specific property.
Others are same as LP5523.
-lp8501@32 {
+led-controller@32 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "ti,lp8501";
@@ -210,63 +210,63 @@ lp8501@32 {
clock-mode = /bits/ 8 <2>;
pwr-sel = /bits/ 8 <3>; /* D1~9 connected to VOUT */
- chan@0 {
+ led@0 {
reg = <0>;
chan-name = "d1";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@1 {
+ led@1 {
reg = <1>;
chan-name = "d2";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@2 {
+ led@2 {
reg = <2>;
chan-name = "d3";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@3 {
+ led@3 {
reg = <3>;
chan-name = "d4";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@4 {
+ led@4 {
reg = <4>;
chan-name = "d5";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@5 {
+ led@5 {
reg = <5>;
chan-name = "d6";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@6 {
+ led@6 {
reg = <6>;
chan-name = "d7";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@7 {
+ led@7 {
reg = <7>;
chan-name = "d8";
led-cur = /bits/ 8 <0x14>;
max-cur = /bits/ 8 <0x20>;
};
- chan@8 {
+ led@8 {
reg = <8>;
chan-name = "d9";
led-cur = /bits/ 8 <0x14>;
--
2.25.0
Add multicolor framework support for the lp55xx family.
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/Kconfig | 1 +
drivers/leds/leds-lp5521.c | 14 +-
drivers/leds/leds-lp5523.c | 14 +-
drivers/leds/leds-lp5562.c | 13 +-
drivers/leds/leds-lp55xx-common.c | 200 +++++++++++++++++++---
drivers/leds/leds-lp55xx-common.h | 12 +-
drivers/leds/leds-lp8501.c | 14 +-
include/linux/platform_data/leds-lp55xx.h | 8 +
8 files changed, 228 insertions(+), 48 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 01c879005b83..5dc6535a88ef 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -377,6 +377,7 @@ config 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
+ depends on OF
select FW_LOADER
select FW_LOADER_USER_HELPER
help
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 6d2163c0f625..6ff81d6be789 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -505,9 +505,16 @@ static int lp5521_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;
+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp5521_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -516,10 +523,6 @@ static int lp5521_probe(struct i2c_client *client,
}
}
- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;
-
led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
if (!led)
@@ -527,7 +530,6 @@ static int lp5521_probe(struct i2c_client *client,
chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp5521_cfg;
mutex_init(&chip->lock);
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index 15e7051392f5..b076c16df9ab 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -872,9 +872,16 @@ static int lp5523_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;
+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp5523_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -883,10 +890,6 @@ static int lp5523_probe(struct i2c_client *client,
}
}
- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;
-
led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
if (!led)
@@ -894,7 +897,6 @@ static int lp5523_probe(struct i2c_client *client,
chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp5523_cfg;
mutex_init(&chip->lock);
diff --git a/drivers/leds/leds-lp5562.c b/drivers/leds/leds-lp5562.c
index 1c94422408b0..7ecdd199d7ef 100644
--- a/drivers/leds/leds-lp5562.c
+++ b/drivers/leds/leds-lp5562.c
@@ -520,9 +520,16 @@ static int lp5562_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;
+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp5562_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -531,9 +538,6 @@ static int lp5562_probe(struct i2c_client *client,
}
}
- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;
led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
@@ -542,7 +546,6 @@ static int lp5562_probe(struct i2c_client *client,
chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp5562_cfg;
mutex_init(&chip->lock);
diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c
index 882ef39e4965..c2087a654ea8 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -131,14 +131,62 @@ static struct attribute *lp55xx_led_attrs[] = {
};
ATTRIBUTE_GROUPS(lp55xx_led);
+#if IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR)
+static int lp55xx_map_channel(struct lp55xx_led *led, int color_id,
+ enum led_brightness brightness)
+{
+ int i;
+
+ for (i = 0; i < led->mc_cdev.num_leds; i++) {
+ if (led->color_components[i].color_id == color_id) {
+ led->color_components[i].brightness = brightness;
+ return 0;
+ }
+ }
+
+ return -EINVAL;
+}
+#endif
+
+static int lp55xx_set_mc_brightness(struct lp55xx_led *led,
+ struct lp55xx_device_config *cfg,
+ enum led_brightness brightness)
+{
+ int ret = -EINVAL;
+#if IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR)
+ struct led_mc_color_conversion color_components[LP55XX_MAX_GROUPED_CHAN];
+ int i;
+
+ if (!cfg->multicolor_brightness_fn)
+ return -EINVAL;
+
+ led_mc_calc_color_components(&led->mc_cdev, brightness,
+ color_components);
+
+ for (i = 0; i < led->mc_cdev.num_leds; i++) {
+ ret = lp55xx_map_channel(led, color_components[i].color_id,
+ color_components[i].brightness);
+ if (ret)
+ return ret;
+ }
+
+ ret = cfg->multicolor_brightness_fn(led);
+#endif
+ return ret;
+}
+
static int lp55xx_set_brightness(struct led_classdev *cdev,
enum led_brightness brightness)
{
struct lp55xx_led *led = cdev_to_lp55xx_led(cdev);
struct lp55xx_device_config *cfg = led->chip->cfg;
- led->brightness = (u8)brightness;
- return cfg->brightness_fn(led);
+ if (led->mc_cdev.num_leds > 1) {
+ return lp55xx_set_mc_brightness(led, cfg, brightness);
+ } else {
+ led->brightness = (u8)brightness;
+ return cfg->brightness_fn(led);
+ }
}
static int lp55xx_init_led(struct lp55xx_led *led,
@@ -147,9 +195,9 @@ static int lp55xx_init_led(struct lp55xx_led *led,
struct lp55xx_platform_data *pdata = chip->pdata;
struct lp55xx_device_config *cfg = chip->cfg;
struct device *dev = &chip->cl->dev;
+ int max_channel = cfg->max_channel;
char name[32];
int ret;
- int max_channel = cfg->max_channel;
if (chan >= max_channel) {
dev_err(dev, "invalid channel: %d / %d\n", chan, max_channel);
@@ -159,10 +207,34 @@ static int lp55xx_init_led(struct lp55xx_led *led,
if (pdata->led_config[chan].led_current == 0)
return 0;
+ if (pdata->led_config[chan].name) {
+ led->cdev.name = pdata->led_config[chan].name;
+ } else {
+ snprintf(name, sizeof(name), "%s:channel%d",
+ pdata->label ? : chip->cl->name, chan);
+ led->cdev.name = name;
+ }
+
+ if (pdata->led_config[chan].num_colors > 1) {
+ led->mc_cdev.led_cdev = &led->cdev;
+ led->cdev.brightness_set_blocking = lp55xx_set_brightness;
+ led->cdev.groups = lp55xx_led_groups;
+ led->mc_cdev.num_leds = pdata->led_config[chan].num_colors;
+ led->mc_cdev.available_colors =
+ pdata->led_config[chan].available_colors;
+ memcpy(led->color_components,
+ pdata->led_config[chan].color_components,
+ sizeof(led->color_components));
+ } else {
+
+ led->cdev.default_trigger =
+ pdata->led_config[chan].default_trigger;
+ led->cdev.brightness_set_blocking = lp55xx_set_brightness;
+ } led->cdev.groups = lp55xx_led_groups;
+
led->led_current = pdata->led_config[chan].led_current;
led->max_current = pdata->led_config[chan].max_current;
led->chan_nr = pdata->led_config[chan].chan_nr;
- led->cdev.default_trigger = pdata->led_config[chan].default_trigger;
if (led->chan_nr >= max_channel) {
dev_err(dev, "Use channel numbers between 0 and %d\n",
@@ -170,18 +242,13 @@ static int lp55xx_init_led(struct lp55xx_led *led,
return -EINVAL;
}
- led->cdev.brightness_set_blocking = lp55xx_set_brightness;
- led->cdev.groups = lp55xx_led_groups;
+#if IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR)
+ if (pdata->led_config[chan].num_colors > 1)
+ ret = devm_led_classdev_multicolor_register(dev, &led->mc_cdev);
+ else
+#endif
+ ret = devm_led_classdev_register(dev, &led->cdev);
- if (pdata->led_config[chan].name) {
- led->cdev.name = pdata->led_config[chan].name;
- } else {
- snprintf(name, sizeof(name), "%s:channel%d",
- pdata->label ? : chip->cl->name, chan);
- led->cdev.name = name;
- }
-
- ret = devm_led_classdev_register(dev, &led->cdev);
if (ret) {
dev_err(dev, "led register err: %d\n", ret);
return ret;
@@ -525,14 +592,103 @@ void lp55xx_unregister_sysfs(struct lp55xx_chip *chip)
}
EXPORT_SYMBOL_GPL(lp55xx_unregister_sysfs);
+static int lp55xx_parse_common_child(struct device_node *np,
+ struct lp55xx_led_config *cfg,
+ int led_number, int *chan_nr)
+{
+ int ret;
+
+ of_property_read_string(np, "chan-name",
+ &cfg[led_number].name);
+ of_property_read_u8(np, "led-cur",
+ &cfg[led_number].led_current);
+ of_property_read_u8(np, "max-cur",
+ &cfg[led_number].max_current);
+
+ ret = of_property_read_u32(np, "reg", chan_nr);
+ if (ret)
+ return ret;
+
+ if (*chan_nr < 0 || *chan_nr > cfg->max_channel)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int lp55xx_parse_mutli_led_child(struct device_node *child,
+ struct lp55xx_led_config *cfg,
+ int child_number, int color_number)
+{
+ int chan_nr, color_id, ret;
+
+ ret = lp55xx_parse_common_child(child, cfg, child_number, &chan_nr);
+ if (ret)
+ return ret;
+
+ ret = of_property_read_u32(child, "color", &color_id);
+ if (ret)
+ return ret;
+
+ cfg[child_number].color_components[color_number].color_id = color_id;
+ cfg[child_number].color_components[color_number].output_num = chan_nr;
+ set_bit(color_id, &cfg[child_number].available_colors);
+
+ return 0;
+}
+
+static int lp55xx_parse_mutli_led(struct device_node *np,
+ struct lp55xx_led_config *cfg,
+ int child_number)
+{
+ struct device_node *child;
+ int num_colors = 0, ret;
+
+ for_each_child_of_node(np, child) {
+ ret = lp55xx_parse_mutli_led_child(child, cfg, child_number,
+ num_colors);
+ if (ret)
+ return ret;
+ num_colors++;
+ }
+
+ return 0;
+}
+
+static int lp55xx_parse_logical_led(struct device_node *np,
+ struct lp55xx_led_config *cfg,
+ int child_number)
+{
+ int led_color, ret;
+
+ cfg[child_number].default_trigger =
+ of_get_property(np, "linux,default-trigger", NULL);
+
+ ret = of_property_read_u32(np, "color", &led_color);
+
+ if (ret) {
+ int chan_nr;
+ ret = lp55xx_parse_common_child(np, cfg, child_number,
+ &chan_nr);
+ if (ret < 0)
+ return ret;
+ cfg[child_number].chan_nr = chan_nr;
+ } else if (led_color == LED_COLOR_ID_MULTI) {
+ return lp55xx_parse_mutli_led(np, cfg, child_number);
+ }
+
+ return ret;
+}
+
struct lp55xx_platform_data *lp55xx_of_populate_pdata(struct device *dev,
- struct device_node *np)
+ struct device_node *np,
+ struct lp55xx_chip *chip)
{
struct device_node *child;
struct lp55xx_platform_data *pdata;
struct lp55xx_led_config *cfg;
int num_channels;
int i = 0;
+ int ret;
pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -550,16 +706,12 @@ struct lp55xx_platform_data *lp55xx_of_populate_pdata(struct device *dev,
pdata->led_config = &cfg[0];
pdata->num_channels = num_channels;
+ cfg->max_channel = chip->cfg->max_channel;
for_each_child_of_node(np, child) {
- cfg[i].chan_nr = i;
-
- of_property_read_string(child, "chan-name", &cfg[i].name);
- of_property_read_u8(child, "led-cur", &cfg[i].led_current);
- of_property_read_u8(child, "max-cur", &cfg[i].max_current);
- cfg[i].default_trigger =
- of_get_property(child, "linux,default-trigger", NULL);
-
+ ret = lp55xx_parse_logical_led(child, cfg, i);
+ if (ret)
+ return ERR_PTR(-EINVAL);
i++;
}
diff --git a/drivers/leds/leds-lp55xx-common.h b/drivers/leds/leds-lp55xx-common.h
index b9b1041e8143..18476051d3d2 100644
--- a/drivers/leds/leds-lp55xx-common.h
+++ b/drivers/leds/leds-lp55xx-common.h
@@ -12,6 +12,8 @@
#ifndef _LEDS_LP55XX_COMMON_H
#define _LEDS_LP55XX_COMMON_H
+#include <linux/led-class-multicolor.h>
+
enum lp55xx_engine_index {
LP55XX_ENGINE_INVALID,
LP55XX_ENGINE_1,
@@ -109,6 +111,9 @@ struct lp55xx_device_config {
/* access brightness register */
int (*brightness_fn)(struct lp55xx_led *led);
+ /* perform brightness value to multiple LEDs */
+ int (*multicolor_brightness_fn)(struct lp55xx_led *led);
+
/* current setting function */
void (*set_led_current) (struct lp55xx_led *led, u8 led_current);
@@ -159,6 +164,8 @@ struct lp55xx_chip {
* struct lp55xx_led
* @chan_nr : Channel number
* @cdev : LED class device
+ * @mc_cdev : Multi color class device
+ * @color_components: Multi color LED map information
* @led_current : Current setting at each led channel
* @max_current : Maximun current at each led channel
* @brightness : Brightness value
@@ -167,6 +174,8 @@ struct lp55xx_chip {
struct lp55xx_led {
int chan_nr;
struct led_classdev cdev;
+ struct led_classdev_mc mc_cdev;
+ struct led_mc_color_conversion color_components[LP55XX_MAX_GROUPED_CHAN];
u8 led_current;
u8 max_current;
u8 brightness;
@@ -196,6 +205,7 @@ extern void lp55xx_unregister_sysfs(struct lp55xx_chip *chip);
/* common device tree population function */
extern struct lp55xx_platform_data
-*lp55xx_of_populate_pdata(struct device *dev, struct device_node *np);
+*lp55xx_of_populate_pdata(struct device *dev, struct device_node *np,
+ struct lp55xx_chip *chip);
#endif /* _LEDS_LP55XX_COMMON_H */
diff --git a/drivers/leds/leds-lp8501.c b/drivers/leds/leds-lp8501.c
index a58019cdb8c3..ac2c31db4a65 100644
--- a/drivers/leds/leds-lp8501.c
+++ b/drivers/leds/leds-lp8501.c
@@ -308,9 +308,16 @@ static int lp8501_probe(struct i2c_client *client,
struct lp55xx_platform_data *pdata = dev_get_platdata(&client->dev);
struct device_node *np = client->dev.of_node;
+ chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
+ if (!chip)
+ return -ENOMEM;
+
+ chip->cfg = &lp8501_cfg;
+
if (!pdata) {
if (np) {
- pdata = lp55xx_of_populate_pdata(&client->dev, np);
+ pdata = lp55xx_of_populate_pdata(&client->dev, np,
+ chip);
if (IS_ERR(pdata))
return PTR_ERR(pdata);
} else {
@@ -319,10 +326,6 @@ static int lp8501_probe(struct i2c_client *client,
}
}
- chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
- if (!chip)
- return -ENOMEM;
-
led = devm_kcalloc(&client->dev,
pdata->num_channels, sizeof(*led), GFP_KERNEL);
if (!led)
@@ -330,7 +333,6 @@ static int lp8501_probe(struct i2c_client *client,
chip->cl = client;
chip->pdata = pdata;
- chip->cfg = &lp8501_cfg;
mutex_init(&chip->lock);
diff --git a/include/linux/platform_data/leds-lp55xx.h b/include/linux/platform_data/leds-lp55xx.h
index 96a787100fda..dca21b19a283 100644
--- a/include/linux/platform_data/leds-lp55xx.h
+++ b/include/linux/platform_data/leds-lp55xx.h
@@ -12,17 +12,25 @@
#ifndef _LEDS_LP55XX_H
#define _LEDS_LP55XX_H
+#include <linux/led-class-multicolor.h>
+
/* Clock configuration */
#define LP55XX_CLOCK_AUTO 0
#define LP55XX_CLOCK_INT 1
#define LP55XX_CLOCK_EXT 2
+#define LP55XX_MAX_GROUPED_CHAN 4
+
struct lp55xx_led_config {
const char *name;
const char *default_trigger;
u8 chan_nr;
u8 led_current; /* mA x10, 0 if led is not connected */
u8 max_current;
+ int num_colors;
+ unsigned int max_channel;
+ unsigned long available_colors;
+ struct led_mc_color_conversion color_components[LP55XX_MAX_GROUPED_CHAN];
};
struct lp55xx_predef_pattern {
--
2.25.0
Fix checkpatch errors and warnings for the LP5523.c device
driver.
Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
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 609288077917..cb402b5b4495 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.25.0
Add a new color ID that is declared as MULTICOLOR as with the
multicolor framework declaring a definitive color is not accurate
as the node can contain multiple colors.
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/led-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index f1f718dbe0f8..846248a0693d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -34,6 +34,7 @@ const char * const led_colors[LED_COLOR_ID_MAX] = {
[LED_COLOR_ID_VIOLET] = "violet",
[LED_COLOR_ID_YELLOW] = "yellow",
[LED_COLOR_ID_IR] = "ir",
+ [LED_COLOR_ID_MULTI] = "multicolor",
};
EXPORT_SYMBOL_GPL(led_colors);
--
2.25.0
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 <color>_intensity files and the latter is controlled
via brightness file.
Signed-off-by: Dan Murphy <[email protected]>
---
.../ABI/testing/sysfs-class-led-multicolor | 36 +++
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 100 +++++++
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile | 1 +
drivers/leds/led-class-multicolor.c | 272 ++++++++++++++++++
include/linux/led-class-multicolor.h | 139 +++++++++
7 files changed, 559 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..3d1f9d726c70
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-multicolor
@@ -0,0 +1,36 @@
+What: /sys/class/leds/<led>/brightness
+Date: Sept 2019
+KernelVersion: 5.5
+Contact: Dan Murphy <[email protected]>
+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 * <color>_intensity/<color>_max_intensity
+
+ 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>/colors/<color>_intensity
+Date: Sept 2019
+KernelVersion: 5.5
+Contact: Dan Murphy <[email protected]>
+Description: read/write
+ The <color>_intensity file is created based on the color
+ defined by the registrar of the class.
+ There is one file per color presented.
+
+ The value of the color is from 0 to
+ /sys/class/leds/<led>/colors/<color>_max_intensity.
+
+What: /sys/class/leds/<led>/colors/<color>_max_intensity
+Date: Sept 2019
+KernelVersion: 5.5
+Contact: Dan Murphy <[email protected]>
+Description: read only
+ Maximum intensity level for the LED color.
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..8f7b62dd856e
--- /dev/null
+++ b/Documentation/leds/leds-class-multicolor.rst
@@ -0,0 +1,100 @@
+====================================
+Multi Color LED handling under Linux
+====================================
+
+Description
+===========
+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 <color>_intensity files and the latter is controlled
+via brightness file.
+
+For more details on hue and lightness notions please refer to
+https://en.wikipedia.org/wiki/CIECAM02.
+
+Note that intensity files only cache the written value and the actual
+change of hardware state occurs upon writing brightness file. This
+allows for changing many factors of the perceived color in a virtually
+unnoticeable way for the human observer.
+
+Multicolor Class Control
+========================
+The multicolor class presents the LED groups under a directory called "colors".
+This directory is a child 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 have two files created under the colors directory
+<color>_intensity and <color>_max_intensity. These files will contain
+one of LED_COLOR_ID_* definitions from the header
+include/dt-bindings/leds/common.h.
+
+Directory Layout Example
+========================
+root:/sys/class/leds/multicolor:grouped_leds# ls -lR colors/
+-rw-r--r-- 1 root root 4096 Jul 7 03:10 blue_intensity
+-r--r--r-- 1 root root 4096 Jul 7 03:10 blue_max_intensity
+-rw-r--r-- 1 root root 4096 Jul 7 03:10 green_intensity
+-r--r--r-- 1 root root 4096 Jul 7 03:10 green_max_intensity
+-rw-r--r-- 1 root root 4096 Jul 7 03:10 red_intensity
+-r--r--r-- 1 root root 4096 Jul 7 03:10 red_max_intensity
+
+Multicolor Class Brightness Control
+===================================
+The multiclor 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 color LED max intensity setting multiplied by
+the requested brightness.
+
+led_brightness = brightness * <color>_intensity/<color>_max_intensity
+
+It is important to note that for each LED within the cluster the
+<color>_max_intensity value should be the same. This will help maintain a
+consistent hue across brightness levels.
+
+Example:
+Three LEDs are present in the group as defined in "Directory Layout Example"
+within this document.
+
+A user first writes the color LED brightness file with the brightness level that
+is necessary to achieve a blueish violet output from the RGB LED group.
+
+echo 138 > /sys/class/leds/rgb:grouped_leds/red_intensity
+echo 43 > /sys/class/leds/rgb:grouped_leds/green_intensity
+echo 226 > /sys/class/leds/rgb:grouped_leds/blue_intensity
+
+red -
+ intensity = 138
+ max_intensity = 255
+green -
+ intensity = 43
+ max_intensity = 255
+blue -
+ intensity = 226
+ max_intensity = 255
+
+The user can control the brightness of that RGB group by writing the parent
+'brightness' control. Assuming a parent 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
+parent brightness file then the values written to each LED will be adjusted
+base on this value
+
+cat /sys/class/leds/rgb:grouped_leds/max_brightness
+255
+echo 128 > /sys/class/leds/rgb:grouped_leds/brightness
+
+adjusted_red_value = 128 * 138/255 = 69
+adjusted_green_value = 128 * 43/255 = 21
+adjusted_blue_value = 128 * 226/255 = 113
+
+Reading the parent brightness file will return the current brightness value of
+the color LED group.
+
+cat /sys/class/leds/rgb:grouped_leds/max_brightness
+255
+
+echo 128 > /sys/class/leds/rgb:grouped_leds/brightness
+
+cat /sys/class/leds/rgb:grouped_leds/brightness
+128
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index d82f1dea3711..37dcdb06a29b 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 Mulit Color 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 d7e1107753fb..310b5518783a 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
diff --git a/drivers/leds/led-class-multicolor.c b/drivers/leds/led-class-multicolor.c
new file mode 100644
index 000000000000..62669c9435c2
--- /dev/null
+++ b/drivers/leds/led-class-multicolor.c
@@ -0,0 +1,272 @@
+// SPDX-License-Identifier: GPL-2.0
+// LED Multi Color class interface
+// Copyright (C) 2019 Texas Instruments Incorporated - http://www.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"
+
+#define INTENSITY_NAME "_intensity"
+#define MAX_INTENSITY_NAME "_max_intensity"
+
+int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness,
+ struct led_mc_color_conversion color_components[])
+{
+ struct led_mc_color_entry *priv;
+ int i = 0;
+
+ list_for_each_entry(priv, &mcled_cdev->color_list, list) {
+ color_components[i].color_id = priv->led_color_id;
+ color_components[i].brightness = brightness *
+ priv->intensity / priv->max_intensity;
+ i++;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(led_mc_calc_color_components);
+
+static ssize_t intensity_store(struct device *dev,
+ struct device_attribute *intensity_attr,
+ const char *buf, size_t size)
+{
+ struct led_mc_color_entry *priv = container_of(intensity_attr,
+ struct led_mc_color_entry,
+ intensity_attr);
+ struct led_classdev *led_cdev = priv->mcled_cdev->led_cdev;
+ unsigned long value;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ ret = kstrtoul(buf, 10, &value);
+ if (ret)
+ goto unlock;
+
+ if (value > priv->max_intensity) {
+ ret = -EINVAL;
+ goto unlock;
+ }
+
+ priv->intensity = value;
+ ret = size;
+
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t intensity_show(struct device *dev,
+ struct device_attribute *intensity_attr,
+ char *buf)
+{
+ struct led_mc_color_entry *priv = container_of(intensity_attr,
+ struct led_mc_color_entry,
+ intensity_attr);
+
+ return sprintf(buf, "%d\n", priv->intensity);
+}
+
+static ssize_t max_intensity_show(struct device *dev,
+ struct device_attribute *max_intensity_attr,
+ char *buf)
+{
+ struct led_mc_color_entry *priv = container_of(max_intensity_attr,
+ struct led_mc_color_entry,
+ max_intensity_attr);
+
+ return sprintf(buf, "%d\n", priv->max_intensity);
+}
+
+static struct attribute *led_color_attrs[] = {
+ NULL,
+};
+
+static struct attribute_group led_color_group = {
+ .name = "colors",
+ .attrs = led_color_attrs,
+};
+
+static int led_multicolor_init_color(struct led_classdev_mc *mcled_cdev,
+ int color_id)
+{
+ struct led_classdev *led_cdev = mcled_cdev->led_cdev;
+ struct led_mc_color_entry *mc_priv;
+ char *intensity_file_name;
+ char *max_intensity_file_name;
+ size_t len;
+ int ret;
+
+ mc_priv = devm_kzalloc(led_cdev->dev, sizeof(*mc_priv), GFP_KERNEL);
+ if (!mc_priv)
+ return -ENOMEM;
+
+ mc_priv->led_color_id = color_id;
+ mc_priv->mcled_cdev = mcled_cdev;
+
+ sysfs_attr_init(&mc_priv->intensity_attr.attr);
+ len = strlen(led_colors[color_id]) + strlen(INTENSITY_NAME) + 1;
+ intensity_file_name = kzalloc(len, GFP_KERNEL);
+ if (!intensity_file_name)
+ return -ENOMEM;
+
+ snprintf(intensity_file_name, len, "%s%s",
+ led_colors[color_id], INTENSITY_NAME);
+ mc_priv->intensity_attr.attr.name = intensity_file_name;
+ mc_priv->intensity_attr.attr.mode = 0644;
+ mc_priv->intensity_attr.store = intensity_store;
+ mc_priv->intensity_attr.show = intensity_show;
+ ret = sysfs_add_file_to_group(&led_cdev->dev->kobj,
+ &mc_priv->intensity_attr.attr,
+ led_color_group.name);
+ if (ret)
+ goto intensity_err_out;
+
+ sysfs_attr_init(&mc_priv->max_intensity_attr.attr);
+ len = strlen(led_colors[color_id]) + strlen(MAX_INTENSITY_NAME) + 1;
+ max_intensity_file_name = kzalloc(len, GFP_KERNEL);
+ if (!max_intensity_file_name) {
+ ret = -ENOMEM;
+ goto intensity_err_out;
+ }
+
+ snprintf(max_intensity_file_name, len, "%s%s",
+ led_colors[color_id], MAX_INTENSITY_NAME);
+ mc_priv->max_intensity_attr.attr.name = max_intensity_file_name;
+ mc_priv->max_intensity_attr.attr.mode = 0444;
+ mc_priv->max_intensity_attr.show = max_intensity_show;
+ ret = sysfs_add_file_to_group(&led_cdev->dev->kobj,
+ &mc_priv->max_intensity_attr.attr,
+ led_color_group.name);
+ if (ret)
+ goto max_intensity_err_out;
+
+ mc_priv->max_intensity = LED_FULL;
+ list_add_tail(&mc_priv->list, &mcled_cdev->color_list);
+
+max_intensity_err_out:
+ kfree(max_intensity_file_name);
+intensity_err_out:
+ kfree(intensity_file_name);
+ return ret;
+}
+
+static int led_multicolor_init_color_dir(struct led_classdev_mc *mcled_cdev)
+{
+ struct led_classdev *led_cdev = mcled_cdev->led_cdev;
+ int ret;
+ int i;
+
+ ret = sysfs_create_group(&led_cdev->dev->kobj, &led_color_group);
+ if (ret)
+ return ret;
+
+ for (i = 0; i < LED_COLOR_ID_MAX; i++) {
+ if (test_bit(i, &mcled_cdev->available_colors)) {
+ ret = led_multicolor_init_color(mcled_cdev, i);
+ if (ret)
+ break;
+
+ }
+ }
+
+ return ret;
+}
+
+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;
+ int ret;
+
+ if (!mcled_cdev)
+ return -EINVAL;
+
+ led_cdev = mcled_cdev->led_cdev;
+ INIT_LIST_HEAD(&mcled_cdev->color_list);
+
+ /* Register led class device */
+ ret = led_classdev_register_ext(parent, led_cdev, init_data);
+ if (ret)
+ return ret;
+
+ return led_multicolor_init_color_dir(mcled_cdev);
+}
+EXPORT_SYMBOL_GPL(led_classdev_multicolor_register_ext);
+
+void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev)
+{
+ struct led_mc_color_entry *priv, *next;
+
+ if (!mcled_cdev)
+ return;
+
+ list_for_each_entry_safe(priv, next, &mcled_cdev->color_list, list)
+ list_del(&priv->list);
+
+ sysfs_remove_group(&mcled_cdev->led_cdev->dev->kobj, &led_color_group);
+ 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 <[email protected]>");
+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..94ec5d1ff154
--- /dev/null
+++ b/include/linux/led-class-multicolor.h
@@ -0,0 +1,139 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* LED Multicolor class interface
+ * Copyright (C) 2019 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 led_classdev_mc;
+
+struct led_mc_color_conversion {
+ int color_id;
+ int brightness;
+ int output_num;
+};
+
+struct led_mc_color_entry {
+ struct led_classdev_mc *mcled_cdev;
+
+ struct device_attribute max_intensity_attr;
+ struct device_attribute intensity_attr;
+
+ enum led_brightness max_intensity;
+ enum led_brightness intensity;
+
+ struct list_head list;
+
+ int led_color_id;
+};
+
+struct led_classdev_mc {
+ /* led class device */
+ struct led_classdev *led_cdev;
+ struct list_head color_list;
+
+ unsigned long available_colors;
+ int num_leds;
+};
+
+static inline struct led_classdev_mc *lcdev_to_mccdev(
+ struct led_classdev *lcdev)
+{
+ return container_of(lcdev, 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,
+ struct led_mc_color_conversion color_components[]);
+
+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,
+ struct led_mc_color_conversion color_components[])
+{
+ 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.25.0
Fix the checkpatch warnings for the use of the file permission macros.
In converting the file permissions to the DEVICE_ATTR_XX macros the
call back function names needed to be updated within the code.
This means that the lp55xx_ needed to be dropped in the name to keep in
harmony with the ABI documentation.
Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
drivers/leds/leds-lp55xx-common.c | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c
index c2087a654ea8..41d8c5e41306 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -78,7 +78,7 @@ static int lp55xx_post_init_device(struct lp55xx_chip *chip)
return cfg->post_init_device(chip);
}
-static ssize_t lp55xx_show_current(struct device *dev,
+static ssize_t led_current_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -87,7 +87,7 @@ static ssize_t lp55xx_show_current(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%d\n", led->led_current);
}
-static ssize_t lp55xx_store_current(struct device *dev,
+static ssize_t led_current_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
@@ -111,7 +111,7 @@ static ssize_t lp55xx_store_current(struct device *dev,
return len;
}
-static ssize_t lp55xx_show_max_current(struct device *dev,
+static ssize_t max_current_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -120,9 +120,8 @@ static ssize_t lp55xx_show_max_current(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%d\n", led->max_current);
}
-static DEVICE_ATTR(led_current, S_IRUGO | S_IWUSR, lp55xx_show_current,
- lp55xx_store_current);
-static DEVICE_ATTR(max_current, S_IRUGO , lp55xx_show_max_current, NULL);
+static DEVICE_ATTR_RW(led_current);
+static DEVICE_ATTR_RO(max_current);
static struct attribute *lp55xx_led_attrs[] = {
&dev_attr_led_current.attr,
@@ -292,7 +291,7 @@ static int lp55xx_request_firmware(struct lp55xx_chip *chip)
GFP_KERNEL, chip, lp55xx_firmware_loaded);
}
-static ssize_t lp55xx_show_engine_select(struct device *dev,
+static ssize_t select_engine_show(struct device *dev,
struct device_attribute *attr,
char *buf)
{
@@ -302,7 +301,7 @@ static ssize_t lp55xx_show_engine_select(struct device *dev,
return sprintf(buf, "%d\n", chip->engine_idx);
}
-static ssize_t lp55xx_store_engine_select(struct device *dev,
+static ssize_t select_engine_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
@@ -344,7 +343,7 @@ static inline void lp55xx_run_engine(struct lp55xx_chip *chip, bool start)
chip->cfg->run_engine(chip, start);
}
-static ssize_t lp55xx_store_engine_run(struct device *dev,
+static ssize_t run_engine_store(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t len)
{
@@ -369,9 +368,8 @@ static ssize_t lp55xx_store_engine_run(struct device *dev,
return len;
}
-static DEVICE_ATTR(select_engine, S_IRUGO | S_IWUSR,
- lp55xx_show_engine_select, lp55xx_store_engine_select);
-static DEVICE_ATTR(run_engine, S_IWUSR, NULL, lp55xx_store_engine_run);
+static DEVICE_ATTR_RW(select_engine);
+static DEVICE_ATTR_WO(run_engine);
static struct attribute *lp55xx_engine_attributes[] = {
&dev_attr_select_engine.attr,
--
2.25.0
Add the multicolor brightness call back to support the multicolor
framework. This call back allows setting brightness on grouped channels
in a single function.
Signed-off-by: Dan Murphy <[email protected]>
---
drivers/leds/leds-lp5523.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index b076c16df9ab..609288077917 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_leds; i++) {
+ ret = lp55xx_write(chip,
+ LP5523_REG_LED_PWM_BASE +
+ led->color_components[i].output_num,
+ led->color_components[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.25.0
Add the reg property to each channel node. This update is
to accomodate the multicolor framework. In addition to the
accomodation 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 <[email protected]>
CC: Linus Walleij <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
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 4f6acbd8c040..8a873da102d3 100644
--- a/arch/arm/boot/dts/ste-href.dtsi
+++ b/arch/arm/boot/dts/ste-href.dtsi
@@ -56,16 +56,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>;
};
@@ -75,15 +80,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.25.0
Add the reg property to each channel node. This update is
to accomodate the multicolor framework. In addition to the
accomodation 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 <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
CC: Tony Lindgren <[email protected]>
CC: "Benoît Cousson" <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
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 a638e059135b..ac32f53948f3 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -613,63 +613,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.25.0
Add a new color ID that is declared as MULTICOLOR as with the
multicolor framework declaring a definitive color is not accurate
as the node can contain multiple colors.
Signed-off-by: Dan Murphy <[email protected]>
---
include/dt-bindings/leds/common.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
index 9e1256a7c1bf..7006d15f71e8 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -29,7 +29,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 */
#define LED_FUNCTION_ACTIVITY "activity"
--
2.25.0
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
Signed-off-by: Dan Murphy <[email protected]>
---
.../devicetree/bindings/leds/leds-lp50xx.txt | 148 ++++++++++++++++++
1 file changed, 148 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.txt b/Documentation/devicetree/bindings/leds/leds-lp50xx.txt
new file mode 100644
index 000000000000..291d418642e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.txt
@@ -0,0 +1,148 @@
+* Texas Instruments - LP5009/12/18/24/30/36 RGB LED driver
+
+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.
+
+Required parent properties:
+ - compatible:
+ "ti,lp5009"
+ "ti,lp5012"
+ "ti,lp5018"
+ "ti,lp5024"
+ "ti,lp5030"
+ "ti,lp5036"
+ - reg : I2C slave address
+ lp5009/12 - 0x14, 0x15, 0x16, 0x17
+ lp5018/24 - 0x28, 0x29, 0x2a, 0x2b
+ lp5030/36 - 0x30, 0x31, 0x32, 0x33
+ - #address-cells : 1
+ - #size-cells : 0
+
+Optional parent properties:
+ - enable-gpios : gpio pin to enable/disable the device.
+ - vled-supply : LED supply
+
+Required child properties:
+ - #address-cells : 1
+ - #size-cells : 0
+ - reg : This is the LED module number.
+ - color : Must be LED_COLOR_ID_MULTI
+ - function : see Documentation/devicetree/bindings/leds/common.txt
+
+Required child properties only if LED modules will be banked:
+ - ti,led-bank : 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.
+
+Required grandchildren properties:
+ - reg : A single entry denoting the LED output that controls
+ the monochrome LED.
+ - color : see Documentation/devicetree/bindings/leds/common.txt
+ - led-sources : see Documentation/devicetree/bindings/leds/common.txt
+
+The LED outputs associated with the LED modules are defined in Table 1 of the
+corresponding data sheets.
+
+LP5009 - 3 Total RGB cluster LED outputs 0-2
+LP5012 - 4 Total RGB cluster LED outputs 0-3
+LP5018 - 6 Total RGB cluster LED outputs 0-5
+LP5024 - 8 Total RGB cluster LED outputs 0-7
+LP5030 - 10 Total RGB cluster LED outputs 0-9
+LP5036 - 12 Total RGB cluster LED outputs 0-11
+
+Optional child properties:
+ - label : see Documentation/devicetree/bindings/leds/common.txt
+ - linux,default-trigger :
+ see Documentation/devicetree/bindings/leds/common.txt
+
+Examples:
+led-controller@29 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lp5024";
+ reg = <0x29>;
+ enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
+ vled-supply = <&vmmcsd_fixed>;
+
+ multi-led@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STATUS;
+
+ led@3 {
+ reg = <3>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@4 {
+ reg = <4>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@5 {
+ reg = <5>;
+ 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>;
+ };
+ };
+
+ multi-led@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_ACTIVITY;
+
+ led@12 {
+ reg = <12>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@13 {
+ reg = <13>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@14 {
+ reg = <14>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+};
+
+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
--
2.25.0
Convert the LED class registration calls to the LED devm_*
registration calls.
Signed-off-by: Dan Murphy <[email protected]>
Acked-by: Pavel Machek <[email protected]>
---
drivers/leds/leds-lp5521.c | 9 +++------
drivers/leds/leds-lp5523.c | 9 +++------
drivers/leds/leds-lp5562.c | 9 +++------
drivers/leds/leds-lp55xx-common.c | 15 +--------------
drivers/leds/leds-lp55xx-common.h | 2 --
drivers/leds/leds-lp8501.c | 9 +++------
6 files changed, 13 insertions(+), 40 deletions(-)
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index 6f0272249dc8..6d2163c0f625 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -541,19 +541,17 @@ static int lp5521_probe(struct i2c_client *client,
ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;
ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}
return 0;
-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -566,7 +564,6 @@ static int lp5521_remove(struct i2c_client *client)
lp5521_stop_all_engines(chip);
lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);
return 0;
diff --git a/drivers/leds/leds-lp5523.c b/drivers/leds/leds-lp5523.c
index d0b931a136b9..15e7051392f5 100644
--- a/drivers/leds/leds-lp5523.c
+++ b/drivers/leds/leds-lp5523.c
@@ -908,19 +908,17 @@ static int lp5523_probe(struct i2c_client *client,
ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;
ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}
return 0;
-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -933,7 +931,6 @@ static int lp5523_remove(struct i2c_client *client)
lp5523_stop_all_engines(chip);
lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);
return 0;
diff --git a/drivers/leds/leds-lp5562.c b/drivers/leds/leds-lp5562.c
index edb57c42e8b1..1c94422408b0 100644
--- a/drivers/leds/leds-lp5562.c
+++ b/drivers/leds/leds-lp5562.c
@@ -554,19 +554,17 @@ static int lp5562_probe(struct i2c_client *client,
ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;
ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}
return 0;
-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -580,7 +578,6 @@ static int lp5562_remove(struct i2c_client *client)
lp5562_stop_engine(chip);
lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);
return 0;
diff --git a/drivers/leds/leds-lp55xx-common.c b/drivers/leds/leds-lp55xx-common.c
index 44ced02b49f9..882ef39e4965 100644
--- a/drivers/leds/leds-lp55xx-common.c
+++ b/drivers/leds/leds-lp55xx-common.c
@@ -181,7 +181,7 @@ static int lp55xx_init_led(struct lp55xx_led *led,
led->cdev.name = name;
}
- ret = led_classdev_register(dev, &led->cdev);
+ ret = devm_led_classdev_register(dev, &led->cdev);
if (ret) {
dev_err(dev, "led register err: %d\n", ret);
return ret;
@@ -490,23 +490,10 @@ int lp55xx_register_leds(struct lp55xx_led *led, struct lp55xx_chip *chip)
return 0;
err_init_led:
- lp55xx_unregister_leds(led, chip);
return ret;
}
EXPORT_SYMBOL_GPL(lp55xx_register_leds);
-void lp55xx_unregister_leds(struct lp55xx_led *led, struct lp55xx_chip *chip)
-{
- int i;
- struct lp55xx_led *each;
-
- for (i = 0; i < chip->num_leds; i++) {
- each = led + i;
- led_classdev_unregister(&each->cdev);
- }
-}
-EXPORT_SYMBOL_GPL(lp55xx_unregister_leds);
-
int lp55xx_register_sysfs(struct lp55xx_chip *chip)
{
struct device *dev = &chip->cl->dev;
diff --git a/drivers/leds/leds-lp55xx-common.h b/drivers/leds/leds-lp55xx-common.h
index 783ed5103ce5..b9b1041e8143 100644
--- a/drivers/leds/leds-lp55xx-common.h
+++ b/drivers/leds/leds-lp55xx-common.h
@@ -189,8 +189,6 @@ extern void lp55xx_deinit_device(struct lp55xx_chip *chip);
/* common LED class device functions */
extern int lp55xx_register_leds(struct lp55xx_led *led,
struct lp55xx_chip *chip);
-extern void lp55xx_unregister_leds(struct lp55xx_led *led,
- struct lp55xx_chip *chip);
/* common device attributes functions */
extern int lp55xx_register_sysfs(struct lp55xx_chip *chip);
diff --git a/drivers/leds/leds-lp8501.c b/drivers/leds/leds-lp8501.c
index 2638dbf0e8ac..a58019cdb8c3 100644
--- a/drivers/leds/leds-lp8501.c
+++ b/drivers/leds/leds-lp8501.c
@@ -344,19 +344,17 @@ static int lp8501_probe(struct i2c_client *client,
ret = lp55xx_register_leds(led, chip);
if (ret)
- goto err_register_leds;
+ goto err_out;
ret = lp55xx_register_sysfs(chip);
if (ret) {
dev_err(&client->dev, "registering sysfs failed\n");
- goto err_register_sysfs;
+ goto err_out;
}
return 0;
-err_register_sysfs:
- lp55xx_unregister_leds(led, chip);
-err_register_leds:
+err_out:
lp55xx_deinit_device(chip);
err_init:
return ret;
@@ -369,7 +367,6 @@ static int lp8501_remove(struct i2c_client *client)
lp8501_stop_engine(chip);
lp55xx_unregister_sysfs(chip);
- lp55xx_unregister_leds(led, chip);
lp55xx_deinit_device(chip);
return 0;
--
2.25.0
Hello
On 1/27/20 9:00 AM, Dan Murphy wrote:
> Hello
>
> This is a re-send of the v17 multi color LED framework. I removed the last
> patch from the series. In addition I rebased this series on Pavel's for-next
> LED branch and added all ACKs from the list.
>
> Dan
>
> Dan Murphy (17):
> dt-bindings: leds: Add multicolor ID to the color ID list
> 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: lp55xx: Be consistent in the document with LED acronym
> dt: bindings: lp55xx: Update binding for Multicolor Framework
> 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
> dt: bindings: Update lp55xx binding to recommended LED naming
I have no open comments on this patchset except for a DT change
requested by Shawn Gao but this change should wait till after this
patchset is merged.
Is there something holding this up?
Dan
Hi!
> > leds: lp5521: Add multicolor framework multicolor brightness support
> > leds: lp55xx: Fix checkpatch file permissions issues
> > leds: lp5523: Fix checkpatch issues in the code
> > dt: bindings: Update lp55xx binding to recommended LED naming
>
> I have no open comments on this patchset except for a DT change requested by
> Shawn Gao but this change should wait till after this patchset is merged.
>
> Is there something holding this up?
Yes... my time; sorry about that.
The fact that it changes API makes it important to get it right, and
hard/impossible to fix it once it is merged... and I don't think this
is the right interface (sorry).
In particular, I don't think having directory per channel is a good
idea. It makes atomic updates impossible (minor), but will also
increase memory consuption (to a point where led-per-channel might
be cheaper), and will make userspace do 3x ammount of syscalls in the
common case.
And we can do better; sysfs files with arrays are okay. So I'd like to
see
channel_intensity (file containing array of u32's)
channel_names (usually containing "red green blue")
(I'm not sure if max_intensity is good idea; i believe we could simply
fix it to UINT32_MAX without bad effects).
And yes, I realize I should have spoken up sooner / more
forcefully. Sorry again.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 2/25/20 11:19 AM, Pavel Machek wrote:
> Hi!
>
>>> leds: lp5521: Add multicolor framework multicolor brightness support
>>> leds: lp55xx: Fix checkpatch file permissions issues
>>> leds: lp5523: Fix checkpatch issues in the code
>>> dt: bindings: Update lp55xx binding to recommended LED naming
>>
>> I have no open comments on this patchset except for a DT change requested by
>> Shawn Gao but this change should wait till after this patchset is merged.
>>
>> Is there something holding this up?
>
> Yes... my time; sorry about that.
>
> The fact that it changes API makes it important to get it right, and
> hard/impossible to fix it once it is merged... and I don't think this
> is the right interface (sorry).
>
> In particular, I don't think having directory per channel is a good
> idea. It makes atomic updates impossible (minor),
It is possible via brightness file, although it will need first writing
intensity files, which only will cache colors, and actual write to hw
occurs on write to brightness file. This has been discussed dozen of
times throughout last year, and you even proposed the formula for
calculating per-color-subled brightness basing on global brightness and
intensity set for each color.
> but will also
> increase memory consuption (to a point where led-per-channel might
> be cheaper), and will make userspace do 3x ammount of syscalls in the
> common case.
>
> And we can do better; sysfs files with arrays are okay. So I'd like to
> see
Let's first achieve broader consensus on this statement before we
move forward with such design. Sysfs maintainer seems to be the best
person to consult at first.
> channel_intensity (file containing array of u32's)
>
> channel_names (usually containing "red green blue")
> (I'm not sure if max_intensity is good idea; i believe we could simply
> fix it to UINT32_MAX without bad effects).
>
> And yes, I realize I should have spoken up sooner / more
> forcefully. Sorry again.
--
Best regards,
Jacek Anaszewski
Hello
On 2/25/20 4:17 PM, Jacek Anaszewski wrote:
> On 2/25/20 11:19 AM, Pavel Machek wrote:
>> Hi!
>>
>>>> leds: lp5521: Add multicolor framework multicolor brightness support
>>>> leds: lp55xx: Fix checkpatch file permissions issues
>>>> leds: lp5523: Fix checkpatch issues in the code
>>>> dt: bindings: Update lp55xx binding to recommended LED naming
>>> I have no open comments on this patchset except for a DT change requested by
>>> Shawn Gao but this change should wait till after this patchset is merged.
>>>
>>> Is there something holding this up?
>> Yes... my time; sorry about that.
>>
>> The fact that it changes API makes it important to get it right, and
>> hard/impossible to fix it once it is merged... and I don't think this
>> is the right interface (sorry).
>>
>> In particular, I don't think having directory per channel is a good
>> idea. It makes atomic updates impossible (minor),
> It is possible via brightness file, although it will need first writing
> intensity files, which only will cache colors, and actual write to hw
> occurs on write to brightness file. This has been discussed dozen of
> times throughout last year, and you even proposed the formula for
> calculating per-color-subled brightness basing on global brightness and
> intensity set for each color.
I actually just got your reply Pavel.? Unfortunately I don't have the
band width to spin any more major framework changes and as you know this
has been discussed over and over and over again with multiple iterations
and multiple designs.
I still don't agree with some nebulous unbound array being passed into
the driver via sysfs. As we have discussed at length in the past this
implementation is just as bad if not worse then what I am proposing. I
also have provided that particular array implementation and it failed to
get any ACKs as it violated sysfs rules and was wrought with corner
cases and mismatches of color to intensity values.? And calling the
sysfs node channel_intensity and channel_names is not correct this is a
LP55xx naming convention and should not be applied.
But as Jacek indicated lets have the sysfs maintainer provide the
consultation on the array implementation again.
And as I have stated above my time has run out on trying to get this
framework completed so I will just re-write the lp50xx driver against
the standard LED class implementation and abandon any hope of actually
improving the LED subsystem for multi color ICs.? As I don't have
another year or two to debate this interface again and try to implement
the code just for it to get another NACK in the end and having to
rewrite the framework again.
Dan
Hi!
> > The fact that it changes API makes it important to get it right, and
> > hard/impossible to fix it once it is merged... and I don't think this
> > is the right interface (sorry).
> >
> > In particular, I don't think having directory per channel is a good
> > idea. It makes atomic updates impossible (minor),
>
> It is possible via brightness file, although it will need first writing
> intensity files, which only will cache colors, and actual write to hw
> occurs on write to brightness file. This has been discussed dozen of
> times throughout last year, and you even proposed the formula for
> calculating per-color-subled brightness basing on global brightness and
> intensity set for each color.
You are right, it is possible to make updates atomic with right kind
of latching (which is quite confusing).
> > but will also
> > increase memory consuption (to a point where led-per-channel might
> > be cheaper), and will make userspace do 3x ammount of syscalls in the
> > common case.
> >
> > And we can do better; sysfs files with arrays are okay. So I'd like to
> > see
>
> Let's first achieve broader consensus on this statement before we
> move forward with such design. Sysfs maintainer seems to be the best
> person to consult at first.
This is actually documented:
Documentation/filesystems/sysfs.txt
<quote>
Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only one
value per file, so it is socially acceptable to express an array of
values of the same type.
Mixing types, expressing multiple lines of data, and doing fancy
formatting of data is heavily frowned upon. Doing these things may get
you publicly humiliated and your code rewritten without notice.
</quote>
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi Greg,
We have here long lasting discussion related to LED multicolor class
sysfs interface design. We went through several iterations and worked
out the solution with individual file per each color sub-LED in the
color directory as shown below:
/sys/class/leds/<led>/colors/<color>_intensity
This is in line with one-value-per-file sysfs rule, that is being
frequently highlighted, and we even had not so long ago a patch
for led cpu trigger solving the problem caused by this rule not
being adhered to.
Now we have the voice below bringing to attention another caveat
from sysfs documentation:
"it is socially acceptable to express an array of values of the same
type"
and proposing the interface in the form of two files:
channel_intensity (file containing array of u32's)
channel_names (usually containing "red green blue")
In order to have this clarified once and for all, could you please
provide us with guidance on whether the fragment from
Documentation/filesystems/sysfs.txt is still in force and we
can benefit from it for LED multicolor framework, or not and then
it should be removed from the doc then?
Best regards,
Jacek Anaszewski
On 2/26/20 1:59 PM, Pavel Machek wrote:
> Hi!
>
>>> The fact that it changes API makes it important to get it right, and
>>> hard/impossible to fix it once it is merged... and I don't think this
>>> is the right interface (sorry).
>>>
>>> In particular, I don't think having directory per channel is a good
>>> idea. It makes atomic updates impossible (minor),
>>
>> It is possible via brightness file, although it will need first writing
>> intensity files, which only will cache colors, and actual write to hw
>> occurs on write to brightness file. This has been discussed dozen of
>> times throughout last year, and you even proposed the formula for
>> calculating per-color-subled brightness basing on global brightness and
>> intensity set for each color.
>
> You are right, it is possible to make updates atomic with right kind
> of latching (which is quite confusing).
>
>>> but will also
>>> increase memory consuption (to a point where led-per-channel might
>>> be cheaper), and will make userspace do 3x ammount of syscalls in the
>>> common case.
>>>
>>> And we can do better; sysfs files with arrays are okay. So I'd like to
>>> see
>>
>> Let's first achieve broader consensus on this statement before we
>> move forward with such design. Sysfs maintainer seems to be the best
>> person to consult at first.
>
> This is actually documented:
>
> Documentation/filesystems/sysfs.txt
>
> <quote>
> Attributes should be ASCII text files, preferably with only one value
> per file. It is noted that it may not be efficient to contain only one
> value per file, so it is socially acceptable to express an array of
> values of the same type.
>
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publicly humiliated and your code rewritten without notice.
> </quote>
>
> Best regards,
> Pavel
>
Hello
On 2/26/20 2:45 PM, Jacek Anaszewski wrote:
> Hi Greg,
>
> We have here long lasting discussion related to LED multicolor class
> sysfs interface design. We went through several iterations and worked
> out the solution with individual file per each color sub-LED in the
> color directory as shown below:
>
> /sys/class/leds/<led>/colors/<color>_intensity
>
> This is in line with one-value-per-file sysfs rule, that is being
> frequently highlighted, and we even had not so long ago a patch
> for led cpu trigger solving the problem caused by this rule not
> being adhered to.
>
> Now we have the voice below bringing to attention another caveat
> from sysfs documentation:
>
> "it is socially acceptable to express an array of values of the same
> type"
>
> and proposing the interface in the form of two files:
>
> channel_intensity (file containing array of u32's)
> channel_names (usually containing "red green blue")
>
> In order to have this clarified once and for all, could you please
> provide us with guidance on whether the fragment from
> Documentation/filesystems/sysfs.txt is still in force and we
> can benefit from it for LED multicolor framework, or not and then
> it should be removed from the doc then?
I spent some time trying to find the conversation on the array
implementation for the multi color framework.
It is buried here
https://lore.kernel.org/patchwork/patch/1026515/
The response from GKH on array's was sited in the above here:
https://www.spinics.net/lists/devicetree/msg69730.html
Repeating my objections to using arrays.
Would this array of colors be fixed?? Well the answer is it would be
fixed per DT entries.? So if a user populates 10 LEDs for color then we
will have 10 entries in the array.? Another DT entry may only have 3.?
So the array size is variable but bounded for now assuming no additional
colors are added.
Another issue with this implementation is we expect channel_names and
channel_intensity arrays to be aligned.? Two different arrays need to
line up so that each element value in channel_intensity matches the
color in the channel_name.?? This can be very easily mixed up in the
HLOS if the proper array tracking is not done. Can we guarantee that the
values we are getting are for the LED they are targeted for?
Would this array be bounded?? Bounded yes by the number of supported
color IDs we have defined in the LED file.? But the size of the array is
completely variable from device to device
Specific LEDs cannot be updated without re-sending the whole array.? If
the user would like to change just 1 color and it is the nth position
(possibly 10th from above) then all color intensities need to be
passed.? There would be no way to say I want "red" at the 10th position
to be 128 without passing in all the other color values as well.? So the
caller needs to keep a cache of the current values or call the framework
to get the current values just to pass them back in. This seems more
expensive then writing 2 sysfs files as writing to the color/<color>
intensity file does not perform any I/O it merely caches the values.?
With the array the framework would need to process all the elements in
the array every time the array is passed.? And then still call the
brightness file to update the color outputs.? So we still have at
minimum two sysfs accesses.
Neither implementation is perfect.
Maybe we need to ask GKH to host this in the staging directory and
actually get some feedback from users as opposed to imposing our will on
people.
Not sure if the ABI's can change in staging.
Dan
Hi, Jacek!
(and thanks for doing this).
> We have here long lasting discussion related to LED multicolor class
> sysfs interface design. We went through several iterations and worked
> out the solution with individual file per each color sub-LED in the
> color directory as shown below:
>
> /sys/class/leds/<led>/colors/<color>_intensity
>
> This is in line with one-value-per-file sysfs rule, that is being
> frequently highlighted, and we even had not so long ago a patch
> for led cpu trigger solving the problem caused by this rule not
> being adhered to.
Yep. One of the problems is that it is nice to change all the hardware
channels at once to produce color (it is often on i2c -- and slow), so
current proposals use "interesting" kind of latching.
> Now we have the voice below bringing to attention another caveat
> from sysfs documentation:
>
> "it is socially acceptable to express an array of values of the same
> type"
>
> and proposing the interface in the form of two files:
>
> channel_intensity (file containing array of u32's)
> channel_names (usually containing "red green blue")
And thus I want to have it in one file, so it is naturaly atomic. RGB
leds with 3 channels are common; I have not user yet, but there are
RGBW with 4 channels (and some more exotic stuff). I don't expect to
have more than 5 channels.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
> Hi, Jacek!
>
> (and thanks for doing this).
>
> > We have here long lasting discussion related to LED multicolor class
> > sysfs interface design. We went through several iterations and worked
> > out the solution with individual file per each color sub-LED in the
> > color directory as shown below:
> >
> > /sys/class/leds/<led>/colors/<color>_intensity
> >
> > This is in line with one-value-per-file sysfs rule, that is being
> > frequently highlighted, and we even had not so long ago a patch
> > for led cpu trigger solving the problem caused by this rule not
> > being adhered to.
>
> Yep. One of the problems is that it is nice to change all the hardware
> channels at once to produce color (it is often on i2c -- and slow), so
> current proposals use "interesting" kind of latching.
>
> > Now we have the voice below bringing to attention another caveat
> > from sysfs documentation:
> >
> > "it is socially acceptable to express an array of values of the same
> > type"
> >
> > and proposing the interface in the form of two files:
> >
> > channel_intensity (file containing array of u32's)
> > channel_names (usually containing "red green blue")
>
> And thus I want to have it in one file, so it is naturaly atomic. RGB
> leds with 3 channels are common; I have not user yet, but there are
> RGBW with 4 channels (and some more exotic stuff). I don't expect to
> have more than 5 channels.
Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
represent a single output should be fine.
thanks,
greg k-h
Pavel
On 2/27/20 6:43 AM, Greg KH wrote:
> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
>> Hi, Jacek!
>>
>> (and thanks for doing this).
>>
>>> We have here long lasting discussion related to LED multicolor class
>>> sysfs interface design. We went through several iterations and worked
>>> out the solution with individual file per each color sub-LED in the
>>> color directory as shown below:
>>>
>>> /sys/class/leds/<led>/colors/<color>_intensity
>>>
>>> This is in line with one-value-per-file sysfs rule, that is being
>>> frequently highlighted, and we even had not so long ago a patch
>>> for led cpu trigger solving the problem caused by this rule not
>>> being adhered to.
>> Yep. One of the problems is that it is nice to change all the hardware
>> channels at once to produce color (it is often on i2c -- and slow), so
>> current proposals use "interesting" kind of latching.
>>
>>> Now we have the voice below bringing to attention another caveat
>>> from sysfs documentation:
>>>
>>> "it is socially acceptable to express an array of values of the same
>>> type"
>>>
>>> and proposing the interface in the form of two files:
>>>
>>> channel_intensity (file containing array of u32's)
>>> channel_names (usually containing "red green blue")
>> And thus I want to have it in one file, so it is naturaly atomic. RGB
>> leds with 3 channels are common; I have not user yet, but there are
>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
>> have more than 5 channels.
This is not an accurate statement. Right now a user can have up to 8
channels to cover all the LEDs defined in the LED core
And if the led_colors array expands then this array can expand.
We have no control on how many entries the user will put in their DT so
again this number is completely arbitrary.
Dan
> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> represent a single output should be fine.
> thanks,
>
> greg k-h
Removing GKH
On 2/27/20 7:07 AM, Dan Murphy wrote:
> Pavel
>
> On 2/27/20 6:43 AM, Greg KH wrote:
>> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
>>> Hi, Jacek!
>>>
>>> (and thanks for doing this).
>>>
>>>> We have here long lasting discussion related to LED multicolor class
>>>> sysfs interface design. We went through several iterations and worked
>>>> out the solution with individual file per each color sub-LED in the
>>>> color directory as shown below:
>>>>
>>>> /sys/class/leds/<led>/colors/<color>_intensity
>>>>
>>>> This is in line with one-value-per-file sysfs rule, that is being
>>>> frequently highlighted, and we even had not so long ago a patch
>>>> for led cpu trigger solving the problem caused by this rule not
>>>> being adhered to.
>>> Yep. One of the problems is that it is nice to change all the hardware
>>> channels at once to produce color (it is often on i2c -- and slow), so
>>> current proposals use "interesting" kind of latching.
>>>
>>>> Now we have the voice below bringing to attention another caveat
>>>> from sysfs documentation:
>>>>
>>>> "it is socially acceptable to express an array of values of the same
>>>> type"
>>>>
>>>> and proposing the interface in the form of two files:
>>>>
>>>> channel_intensity (file containing array of u32's)
>>>> channel_names (usually containing "red green blue")
>>> And thus I want to have it in one file, so it is naturaly atomic. RGB
>>> leds with 3 channels are common; I have not user yet, but there are
>>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
>>> have more than 5 channels.
>
> This is not an accurate statement. Right now a user can have up to 8
> channels to cover all the LEDs defined in the LED core
>
> And if the led_colors array expands then this array can expand.
>
> We have no control on how many entries the user will put in their DT
> so again this number is completely arbitrary.
>
> Dan
>
The more I think about my above statement it is actually worse to do the
arrays. What checks will we have to implement that the DT won't define
an array like this
[red green blue white red green white IR blue yellow]
This array is unbounded at this point. The sysfs framework will not
allow creating files under the directory with the same name so we can
bound this to 1 LED color to a file and there will be no duplicates.
Sure we can NACK DT's that do create unbounded color arrays but that
means we would have to review every DT file that would add a LED node.
What is expected and what is exposed as capability are two different things.
We don't expect developers to have more then 5 channels but if given the
capabilities of doing it eventually it will be done and the framework
will break.
Dan
On 2/27/20 2:07 PM, Dan Murphy wrote:
> Pavel
>
> On 2/27/20 6:43 AM, Greg KH wrote:
>> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
>>> Hi, Jacek!
>>>
>>> (and thanks for doing this).
>>>
>>>> We have here long lasting discussion related to LED multicolor class
>>>> sysfs interface design. We went through several iterations and worked
>>>> out the solution with individual file per each color sub-LED in the
>>>> color directory as shown below:
>>>>
>>>> /sys/class/leds/<led>/colors/<color>_intensity
>>>>
>>>> This is in line with one-value-per-file sysfs rule, that is being
>>>> frequently highlighted, and we even had not so long ago a patch
>>>> for led cpu trigger solving the problem caused by this rule not
>>>> being adhered to.
>>> Yep. One of the problems is that it is nice to change all the hardware
>>> channels at once to produce color (it is often on i2c -- and slow), so
>>> current proposals use "interesting" kind of latching.
>>>
>>>> Now we have the voice below bringing to attention another caveat
>>>> from sysfs documentation:
>>>>
>>>> "it is socially acceptable to express an array of values of the same
>>>> type"
>>>>
>>>> and proposing the interface in the form of two files:
>>>>
>>>> channel_intensity (file containing array of u32's)
>>>> channel_names (usually containing "red green blue")
>>> And thus I want to have it in one file, so it is naturaly atomic. RGB
>>> leds with 3 channels are common; I have not user yet, but there are
>>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
>>> have more than 5 channels.
>
> This is not an accurate statement. Right now a user can have up to 8
> channels to cover all the LEDs defined in the LED core
>
> And if the led_colors array expands then this array can expand.
>
> We have no control on how many entries the user will put in their DT so
> again this number is completely arbitrary.
I believe that some of mechanisms that were devised for the most
recent implementation proposal of LED mc class will need
to be reused for the array approach. E.g. available_colors bitmask
will make the parsing resistant to duplicates.
Of course LED multicolor DT node design should be applicable as well
to the array approach.
>> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
>> represent a single output should be fine.
>> thanks,
Thank you for making this clear.
Effectively, the way to go as I see it now is just moving from
colors directory to channel_intensity and channel_names files.
Besides that, since the issue of backwards compatibility with
LED class still remains, we need to apply the already worked out
formula for mapping brightness to color iout values.
This implies that color values written to channel_intensity file
will be written unchanged to the hw only when global brightness
is equal to max_brightness. This is because they will be multiplied
by brightness / max_brightness ratio.
Do you agree, Pavel?
--
Best regards,
Jacek Anaszewski
On Thu, Feb 27, 2020 at 10:22:43PM +0100, Jacek Anaszewski wrote:
> On 2/27/20 2:07 PM, Dan Murphy wrote:
> > Pavel
> >
> > On 2/27/20 6:43 AM, Greg KH wrote:
> >> On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
> >>> Hi, Jacek!
> >>>
> >>> (and thanks for doing this).
> >>>
> >>>> We have here long lasting discussion related to LED multicolor class
> >>>> sysfs interface design. We went through several iterations and worked
> >>>> out the solution with individual file per each color sub-LED in the
> >>>> color directory as shown below:
> >>>>
> >>>> /sys/class/leds/<led>/colors/<color>_intensity
> >>>>
> >>>> This is in line with one-value-per-file sysfs rule, that is being
> >>>> frequently highlighted, and we even had not so long ago a patch
> >>>> for led cpu trigger solving the problem caused by this rule not
> >>>> being adhered to.
> >>> Yep. One of the problems is that it is nice to change all the hardware
> >>> channels at once to produce color (it is often on i2c -- and slow), so
> >>> current proposals use "interesting" kind of latching.
> >>>
> >>>> Now we have the voice below bringing to attention another caveat
> >>>> from sysfs documentation:
> >>>>
> >>>> "it is socially acceptable to express an array of values of the same
> >>>> type"
> >>>>
> >>>> and proposing the interface in the form of two files:
> >>>>
> >>>> channel_intensity (file containing array of u32's)
> >>>> channel_names (usually containing "red green blue")
> >>> And thus I want to have it in one file, so it is naturaly atomic. RGB
> >>> leds with 3 channels are common; I have not user yet, but there are
> >>> RGBW with 4 channels (and some more exotic stuff). I don't expect to
> >>> have more than 5 channels.
> >
> > This is not an accurate statement.? Right now a user can have up to 8
> > channels to cover all the LEDs defined in the LED core
> >
> > And if the led_colors array expands then this array can expand.
> >
> > We have no control on how many entries the user will put in their DT so
> > again this number is completely arbitrary.
>
> I believe that some of mechanisms that were devised for the most
> recent implementation proposal of LED mc class will need
> to be reused for the array approach. E.g. available_colors bitmask
> will make the parsing resistant to duplicates.
>
> Of course LED multicolor DT node design should be applicable as well
> to the array approach.
>
> >> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> >> represent a single output should be fine.
> >> thanks,
>
> Thank you for making this clear.
>
> Effectively, the way to go as I see it now is just moving from
> colors directory to channel_intensity and channel_names files.
Wait, we already have an interface for this and you want to create a
competing one? Why? What's wrong with what you have now?
Do you have a pointer to the Documentation/ABI/ entries that you have
now that you feel do not work well?
thanks,
greg k-h
Hi!
> > >> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> > >> represent a single output should be fine.
> > >> thanks,
> >
> > Thank you for making this clear.
> >
> > Effectively, the way to go as I see it now is just moving from
> > colors directory to channel_intensity and channel_names files.
>
> Wait, we already have an interface for this and you want to create a
> competing one? Why? What's wrong with what you have now?
>
> Do you have a pointer to the Documentation/ABI/ entries that you have
> now that you feel do not work well?
No, we don't have ABI for RGB LEDs, but there's well-known proposal on
the list Jacek is talking about.
We currently handle RGB LED as three separate LEDs, and that does not
work well.
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Hi!
> >> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
> >> represent a single output should be fine.
> >> thanks,
>
> Thank you for making this clear.
>
> Effectively, the way to go as I see it now is just moving from
> colors directory to channel_intensity and channel_names files.
Yes.
> Besides that, since the issue of backwards compatibility with
> LED class still remains, we need to apply the already worked out
> formula for mapping brightness to color iout values.
>
> This implies that color values written to channel_intensity file
> will be written unchanged to the hw only when global brightness
> is equal to max_brightness. This is because they will be multiplied
> by brightness / max_brightness ratio.
>
> Do you agree, Pavel?
Yes. That seems like possible solution.
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Greg
On 2/28/20 1:42 AM, Greg KH wrote:
> On Thu, Feb 27, 2020 at 10:22:43PM +0100, Jacek Anaszewski wrote:
>> On 2/27/20 2:07 PM, Dan Murphy wrote:
>>> <snip>
>>> This is not an accurate statement. Right now a user can have up to 8
>>> channels to cover all the LEDs defined in the LED core
>>>
>>> And if the led_colors array expands then this array can expand.
>>>
>>> We have no control on how many entries the user will put in their DT so
>>> again this number is completely arbitrary.
>> I believe that some of mechanisms that were devised for the most
>> recent implementation proposal of LED mc class will need
>> to be reused for the array approach. E.g. available_colors bitmask
>> will make the parsing resistant to duplicates.
>>
>> Of course LED multicolor DT node design should be applicable as well
>> to the array approach.
>>
>>>> Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
>>>> represent a single output should be fine.
>>>> thanks,
>> Thank you for making this clear.
>>
>> Effectively, the way to go as I see it now is just moving from
>> colors directory to channel_intensity and channel_names files.
> Wait, we already have an interface for this and you want to create a
> competing one? Why? What's wrong with what you have now?
>
> Do you have a pointer to the Documentation/ABI/ entries that you have
> now that you feel do not work well?
Here is the proposal we have been working on for some time.
Series:
https://lore.kernel.org/patchwork/project/lkml/list/?series=427513
ABI Documentation and support code:
https://lore.kernel.org/patchwork/patch/1186194/
Dan
> thanks,
>
> greg k-h