Multicolor Framework v25
Subsystems (4)
v25 cover Multicolor Framework v25
Hello
This is the multi color LED framework. This framework presents clustered
colored LEDs into an array and allows the user space to adjust the brightness of the cluster using a single file write. The individual colored LEDs intensities are controlled via a single file that is an array of LEDs
Dan
Dan Murphy (16):
dt: bindings: Add multicolor class dt bindings documention
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 | 34 + .../bindings/leds/leds-class-multicolor.yaml | 71 ++ .../devicetree/bindings/leds/leds-lp50xx.yaml | 180 ++++ .../devicetree/bindings/leds/leds-lp55xx.txt | 163 +++- Documentation/leds/index.rst | 1 + Documentation/leds/leds-class-multicolor.rst | 88 ++ MAINTAINERS | 8 + arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 +- arch/arm/boot/dts/omap3-n900.dts | 29 +- arch/arm/boot/dts/ste-href.dtsi | 22 +- drivers/leds/Kconfig | 24 + drivers/leds/Makefile | 2 + drivers/leds/led-class-multicolor.c | 210 +++++ drivers/leds/led-core.c | 1 + drivers/leds/leds-lp50xx.c | 778 ++++++++++++++++++ drivers/leds/leds-lp5521.c | 43 +- drivers/leds/leds-lp5523.c | 62 +- drivers/leds/leds-lp5562.c | 22 +- drivers/leds/leds-lp55xx-common.c | 213 +++-- drivers/leds/leds-lp55xx-common.h | 16 +- drivers/leds/leds-lp8501.c | 23 +- include/dt-bindings/leds/common.h | 3 +- include/linux/led-class-multicolor.h | 121 +++ include/linux/platform_data/leds-lp55xx.h | 8 + 24 files changed, 1977 insertions(+), 159 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml 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
Signature · 1 line
2.25.1
PATCH v25 1/16 dt: bindings: Add multicolor class dt bindings documention
Add DT bindings for the LEDs multicolor class framework. Add multicolor ID to the color ID list for device tree bindings.
--- .../bindings/leds/leds-class-multicolor.yaml | 71 +++++++++++++++++++ drivers/leds/led-core.c | 1 + include/dt-bindings/leds/common.h | 3 +- 3 files changed, 74 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +71 -0
@@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for the multicolor LED class. + +maintainers: + - Dan Murphy <[email protected]> + +description: | + Bindings for multi color LEDs show how to describe current outputs of + either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV + etc.) or standalone LEDs, to achieve logically grouped multi-color LED + modules. This is achieved by adding multi-led nodes layer to the + monochrome LED bindings. + The nodes and properties defined in this document are unique to the multicolor + LED class. Common LED nodes and properties are inherited from the common.txt + within this documentation directory. + +properties: + color: + description: | + For multicolor LED support this property should be defined as + LED_COLOR_ID_MULTI and further definition can be found in + include/linux/leds/common.h. + +required: + - color + +examples: + - | + #include <dt-bindings/leds/common.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@14 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lp5009"; + reg = <0x14>; + + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_CHARGING; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + }; + +additionalProperties: false +...
drivers/leds/led-core.c +1 -0
@@ -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);
include/dt-bindings/leds/common.h +2 -1
@@ -30,7 +30,8 @@#define LED_COLOR_ID_VIOLET 5#define LED_COLOR_ID_YELLOW 6#define LED_COLOR_ID_IR 7 -#define LED_COLOR_ID_MAX 8 +#define LED_COLOR_ID_MULTI 8 +#define LED_COLOR_ID_MAX 9/* Standard LED functions */ /* Keyboard LEDs, usually it would be input4::capslock etc. */
Signature · 1 line
2.25.1
Rob Herring
maintainerRe: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Quoted 20 lines · Dan Murphy
Add DT bindings for the LEDs multicolor class framework. Add multicolor ID to the color ID list for device tree bindings.
CC Rob Herring <[email protected]>Acked-by Pavel Machek <[email protected]>Acked-by Jacek Anaszewski <[email protected]>Signed-off-by Dan Murphy <[email protected]>--- .../bindings/leds/leds-class-multicolor.yaml | 71 +++++++++++++++++++ drivers/leds/led-core.c | 1 + include/dt-bindings/leds/common.h | 3 +- 3 files changed, 74 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yamlDocumentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +0
-0
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml line 1
Quoted 1 line
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +1
-0@@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings please.
GPL-2.0-only OR BSD-2-Clause
Quoted 16 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +16
-0+%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for the multicolor LED class. + +maintainers: + - Dan Murphy <[email protected]> + +description: | + Bindings for multi color LEDs show how to describe current outputs of + either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV + etc.) or standalone LEDs, to achieve logically grouped multi-color LED + modules. This is achieved by adding multi-led nodes layer to the + monochrome LED bindings.
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml line 27
Quoted 10 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +10
-0+ The nodes and properties defined in this document are unique to the multicolor + LED class. Common LED nodes and properties are inherited from the common.txt + within this documentation directory. + +properties: + color: + description: | + For multicolor LED support this property should be defined as + LED_COLOR_ID_MULTI and further definition can be found in + include/linux/leds/common.h.
This should have:
const: X # LED_COLOR_ID_MULTI
It can't use the define, so you have to use the value.
Quoted 8 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +8
-0+ +required: + - color + +examples: + - | + #include <dt-bindings/leds/common.h> + i2c {
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml line 45
Quoted 10 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +10
-0+ #address-cells = <1>; + #size-cells = <0>; + + led-controller@14 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lp5009"; + reg = <0x14>; + + multi-led@1 {
Define $nodename must be 'multi-led(@[0-9a-f]+)?'
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml line 52
Quoted 7 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +7
-0+ #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_CHARGING; + + led@0 {
Then the schema should define child nodes named 'led'.
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml line 54
Quoted 2 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +2
-0+ reg = <0>; + color = <LED_COLOR_ID_RED>;
I assume in this case 'reg' and 'color' need to be defined as required?
drivers/leds/led-core.c
Quoted 18 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +17
-0+ }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + }; + +additionalProperties: false +...drivers/leds/led-core.c +0
-0
This isn't a binding file. Belongs in another patch.
Quoted 28 lines
index
f1f718dbe0f8..846248a0693d100644drivers/leds/led-core.c +1
-0@@ -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);include/dt-bindings/leds/common.h +2
-1@@ -30,7 +30,8 @@#define LED_COLOR_ID_VIOLET 5#define LED_COLOR_ID_YELLOW 6#define LED_COLOR_ID_IR 7 -#define LED_COLOR_ID_MAX 8 +#define LED_COLOR_ID_MULTI 8 +#define LED_COLOR_ID_MAX 9/* Standard LED functions */ /* Keyboard LEDs, usually it would be input4::capslock etc. */ Signature · 1 line
2.25.1
Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Hi!
Thanks for reviews!
Quoted 5 lines
drivers/leds/led-core.c
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +2
-0+additionalProperties: false +...drivers/leds/led-core.c +0
-0This isn't a binding file. Belongs in another patch.
These constants are directly related to the binding. It makes sense to go in one patch...
Best regards,
Pavel
Quoted 28 lines
Quoted 28 lines
index
f1f718dbe0f8..846248a0693d100644drivers/leds/led-core.c +1
-0@@ -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);include/dt-bindings/leds/common.h +2
-1@@ -30,7 +30,8 @@#define LED_COLOR_ID_VIOLET 5#define LED_COLOR_ID_YELLOW 6#define LED_COLOR_ID_IR 7 -#define LED_COLOR_ID_MAX 8 +#define LED_COLOR_ID_MULTI 8 +#define LED_COLOR_ID_MAX 9/* Standard LED functions */ /* Keyboard LEDs, usually it would be input4::capslock etc. */ Signature · 1 line
2.25.1
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rob Herring
maintainerRe: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Quoted 5 lines · Pavel Machek
Hi!
Thanks for reviews!
Quoted 8 lines
Quoted 5 lines
drivers/leds/led-core.c
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +2
-0+additionalProperties: false +...drivers/leds/led-core.c +0
-0This isn't a binding file. Belongs in another patch.
These constants are directly related to the binding. It makes sense to go in one patch...
Yes, the header does go in this patch, but kernel subsystem files do not.
Part of the reason for separating is we generate a DT only repository which filters out all the kernel code. Ideally this is just filtering out commits and the commit messages still make sense.
Rob
Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Quoted 12 lines · Rob Herring
Quoted 11 lines · Pavel Machek
Hi!
Thanks for reviews!
Quoted 5 lines
drivers/leds/led-core.c
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +2
-0+additionalProperties: false +...drivers/leds/led-core.c +0
-0This isn't a binding file. Belongs in another patch.
Quoted 8 lines
Quoted 2 lines
These constants are directly related to the binding. It makes sense to go in one patch...
Yes, the header does go in this patch, but kernel subsystem files do not.
Part of the reason for separating is we generate a DT only repository which filters out all the kernel code. Ideally this is just filtering out commits and the commit messages still make sens
Well, but the patch can't be split like that. Otherwise we risk null pointer dereferences when one part is applied but not the second one.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rob Herring
maintainerRe: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Quoted 17 lines · Pavel Machek
Quoted 15 lines · Rob Herring
Quoted 13 lines · Pavel Machek
Hi!
Thanks for reviews!
Quoted 5 lines
drivers/leds/led-core.c
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +2
-0+additionalProperties: false +...drivers/leds/led-core.c +0
-0This isn't a binding file. Belongs in another patch.
These constants are directly related to the binding. It makes sense to go in one patch...
Quoted 8 lines
Quoted 5 lines
Yes, the header does go in this patch, but kernel subsystem files do not.
Part of the reason for separating is we generate a DT only repository which filters out all the kernel code. Ideally this is just filtering out commits and the commit messages still make sens
Well, but the patch can't be split like that. Otherwise we risk null pointer dereferences when one part is applied but not the second one.
There's no risk because you are supposed to apply both patches. I don't apply binding patches that are a part of a series like this.
Rob
Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Quoted 24 lines · Rob Herring
Quoted 23 lines · Pavel Machek
Quoted 20 lines · Rob Herring
Quoted 5 lines · Pavel Machek
Hi!
Thanks for reviews!
Quoted 8 lines
Quoted 5 lines
drivers/leds/led-core.c
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml new file +2
-0+additionalProperties: false +...drivers/leds/led-core.c +0
-0This isn't a binding file. Belongs in another patch.
These constants are directly related to the binding. It makes sense to go in one patch...
Yes, the header does go in this patch, but kernel subsystem files do not.
Part of the reason for separating is we generate a DT only repository which filters out all the kernel code. Ideally this is just filtering out commits and the commit messages still make sens
Quoted 5 lines
Quoted 2 lines
Well, but the patch can't be split like that. Otherwise we risk null pointer dereferences when one part is applied but not the second one.
There's no risk because you are supposed to apply both patches. I don't apply binding patches that are a part of a series like this.
Yes, this is always guaranteed to happen, because "git bisect" understand patch series. Oh, wait.
Patches are supposed to be correct on their own. If your repository filtering can not handle that, you need to fix that...
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Rob Herring
maintainerRe: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Quoted 26 lines · Pavel Machek
Quoted 24 lines · Rob Herring
Quoted 23 lines · Pavel Machek
Quoted 20 lines · Rob Herring
Quoted 5 lines · Pavel Machek
Hi!
Thanks for reviews!
Quoted 8 lines
Quoted 5 lines
drivers/leds/led-core.c
Quoted 3 lines
(quoted diff) +2
-0+additionalProperties: false +...drivers/leds/led-core.c +0
-0This isn't a binding file. Belongs in another patch.
These constants are directly related to the binding. It makes sense to go in one patch...
Yes, the header does go in this patch, but kernel subsystem files do not.
Part of the reason for separating is we generate a DT only repository which filters out all the kernel code. Ideally this is just filtering out commits and the commit messages still make sens
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Well, but the patch can't be split like that. Otherwise we risk null pointer dereferences when one part is applied but not the second one.
There's no risk because you are supposed to apply both patches. I don't apply binding patches that are a part of a series like this.
Yes, this is always guaranteed to happen, because "git bisect" understand patch series. Oh, wait.
What!? If the binding patch with the header comes first, how would bisect build the driver change without the header?
Quoted 2 lines
Patches are supposed to be correct on their own. If your repository filtering can not handle that, you need to fix that...
I'm just asking you to follow the process that *everyone* else is following and works. It's not really about the repository filtering. That doesn't care. A binding ABI is defined by the schema and any defines it has. That is the logical unit that stands on its own.
Rob
Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
Quoted 9 lines
Quoted 6 lines
Quoted 3 lines
There's no risk because you are supposed to apply both patches. I don't apply binding patches that are a part of a series like this.
Yes, this is always guaranteed to happen, because "git bisect" understand patch series. Oh, wait.
What!? If the binding patch with the header comes first, how would bisect build the driver change without the header?
The driver is already in tree, and includes array of strings. When you change the define, you need to update the array, too, because you don't want to have invalid value in there.
Quoted 7 lines
Quoted 2 lines
Patches are supposed to be correct on their own. If your repository filtering can not handle that, you need to fix that...
I'm just asking you to follow the process that *everyone* else is following and works. It's not really about the repository filtering. That doesn't care. A binding ABI is defined by the schema and any defines it has. That is the logical unit that stands on its own.
It does not work in this case.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
PATCH v25 2/16 leds: multicolor: Introduce a multicolor class definition
In reply to Dan MurphyIntroduce a multicolor class that groups colored LEDs within a LED node.
The multi color class groups monochrome LEDs and allows controlling two aspects of the final combined color: hue and lightness. The former is controlled via the intensity file and the latter is controlled via brightness file.
--- .../ABI/testing/sysfs-class-led-multicolor | 34 +++ Documentation/leds/index.rst | 1 + Documentation/leds/leds-class-multicolor.rst | 88 ++++++++ MAINTAINERS | 8 + drivers/leds/Kconfig | 10 + drivers/leds/Makefile | 1 + drivers/leds/led-class-multicolor.c | 210 ++++++++++++++++++ include/linux/led-class-multicolor.h | 121 ++++++++++ 8 files changed, 473 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor create mode 100644 Documentation/leds/leds-class-multicolor.rst create mode 100644 drivers/leds/led-class-multicolor.c create mode 100644 include/linux/led-class-multicolor.h
Documentation/ABI/testing/sysfs-class-led-multicolor new file +34 -0
@@ -0,0 +1,34 @@ +What: /sys/class/leds/<led>/brightness +Date: March 2020 +KernelVersion: 5.8 +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 * multi_intensity/max_brightness + + For additional details please refer to + Documentation/leds/leds-class-multicolor.rst. + + The value of the color is from 0 to + /sys/class/leds/<led>/max_brightness. + +What: /sys/class/leds/<led>/multi_index +Date: March 2020 +KernelVersion: 5.8 +Contact: Dan Murphy <[email protected]> +Description: read + The multi_index array, when read, will output the LED colors + by name as they are indexed in the multi_intensity file. + +What: /sys/class/leds/<led>/multi_intensity +Date: March 2020 +KernelVersion: 5.8 +Contact: Dan Murphy <[email protected]> +Description: read/write + Intensity level for the LED color within the array. + The intensities for each color must be entered based on the + multi_index array.
Documentation/leds/index.rst +1 -0
@@ -9,6 +9,7 @@ LEDs leds-class leds-class-flash + leds-class-multicolor ledtrig-oneshot ledtrig-transient ledtrig-usbport
Documentation/leds/leds-class-multicolor.rst new file +88 -0
88 lines not on this page · raw message
MAINTAINERS +8 -0
@@ -9533,6 +9533,14 @@ F: Documentation/devicetree/bindings/leds/ F: drivers/leds/ F: include/linux/leds.h +LED MULTICOLOR FRAMEWORK +M: Dan Murphy <[email protected]> +L: [email protected] +S: Maintained +F: Documentation/leds/leds-class-multicolor.rst +F: drivers/leds/led-class-multicolor.c +F: include/linux/led-class-multicolor.h + LEGACY EEPROM DRIVER M: Jean Delvare <[email protected]> S: Maintained
drivers/leds/Kconfig +10 -0
@@ -30,6 +30,16 @@ config LEDS_CLASS_FLASH for the flash related features of a LED device. It can be built as a module. +config LEDS_CLASS_MULTI_COLOR + tristate "LED MultiColor LED Class Support" + depends on LEDS_CLASS + help + This option enables the multicolor LED sysfs class in /sys/class/leds. + It wraps LED class and adds multicolor LED specific sysfs attributes + and kernel internal API to it. You'll need this to provide support + for multicolor LEDs that are grouped together. This class is not + intended for single color LEDs. It can be built as a module. + config LEDS_BRIGHTNESS_HW_CHANGED bool "LED Class brightness_hw_changed attribute support" depends on LEDS_CLASS
drivers/leds/Makefile +1 -0
@@ -4,6 +4,7 @@ obj-$(CONFIG_NEW_LEDS) += led-core.o obj-$(CONFIG_LEDS_CLASS) += led-class.o obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o +obj-$(CONFIG_LEDS_CLASS_MULTI_COLOR) += led-class-multicolor.o obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o # LED Platform Drivers (keep this sorted, M-| sort)
drivers/leds/led-class-multicolor.c new file +210 -0
210 lines not on this page · raw message
include/linux/led-class-multicolor.h new file +121 -0
121 lines not on this page · raw message
Signature · 1 line
2.25.1
PATCH v25 3/16 dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
In reply to Dan MurphyIntroduce 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
--- .../devicetree/bindings/leds/leds-lp50xx.yaml | 180 ++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +180 -0
@@ -0,0 +1,180 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LED driver for LP50XX RGB LED from Texas Instruments. + +maintainers: + - Dan Murphy <[email protected]> + +description: | + The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into + a LED group or control them individually. + + The difference in these RGB LED drivers is the number of supported RGB + modules. + + For more product information please see the link below: + http://www.ti.com/lit/ds/symlink/lp5012.pdf + http://www.ti.com/lit/ds/symlink/lp5024.pdf + http://www.ti.com/lit/ds/symlink/lp5036.pdf + +properties: + compatible: + oneOf: + - const: ti,lp5009 + - const: ti,lp5012 + - const: ti,lp5018 + - const: ti,lp5024 + - const: ti,lp5030 + - const: ti,lp5036 + + reg: + maxItems: 1 + description: + I2C slave address + lp5009/12 - 0x14, 0x15, 0x16, 0x17 + lp5018/24 - 0x28, 0x29, 0x2a, 0x2b + lp5030/36 - 0x30, 0x31, 0x32, 0x33 + + enable-gpios: + description: GPIO pin to enable/disable the device. + + vled-supply: + description: LED supply. + + child-node: + type: object + properties: + reg: + description: This is the LED module number. + + color: + description: Must be LED_COLOR_ID_MULTI + + function: + description: see Documentation/devicetree/bindings/leds/common.txt + + ti,led-bank: + description: + This property denotes the LED module numbers that will be controlled as + a single RGB cluster. Each LED module number will be controlled by a + single LED class instance. + There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED + modules are to be backed. + $ref: /schemas/types.yaml#definitions/uint32-array + + required: + - reg + - color + - function + + grandchild-node: + type: object + properties: + reg: + description: + A single entry denoting the LED output that controls the monochrome LED. + + color: + description: + see Documentation/devicetree/bindings/leds/common.txt + + led-sources: + description: + 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 + + label: + description: | + Optional node - see Documentation/devicetree/bindings/leds/common.txt + + linux,default-trigger: + description: | + Optional node - see Documentation/devicetree/bindings/leds/common.txt + + required: + - reg + - color + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@14 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lp5009"; + reg = <0x14>; + enable-gpios = <&gpio1 16>; + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_CHARGING; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_STANDBY; + ti,led-bank = <2 3 5>; + + led@6 { + reg = <0x6>; + color = <LED_COLOR_ID_RED>; + led-sources = <6 9 15>; + }; + + led@7 { + reg = <0x7>; + color = <LED_COLOR_ID_GREEN>; + led-sources = <7 10 16>; + }; + + led@8 { + reg = <0x8>; + color = <LED_COLOR_ID_BLUE>; + led-sources = <8 11 17>; + }; + }; + }; + }; + +...
Signature · 1 line
2.25.1
Rob Herring
maintainerRe: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
Quoted 47 lines · Dan Murphy
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.pdfAcked-by Jacek Anaszewski <[email protected]>Signed-off-by Dan Murphy <[email protected]>--- .../devicetree/bindings/leds/leds-lp50xx.yaml | 180 ++++++++++++++++++ 1 file changed, 180 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yamlDocumentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +22
-0@@ -0,0 +1,180 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LED driver for LP50XX RGB LED from Texas Instruments. + +maintainers: + - Dan Murphy <[email protected]> + +description: | + The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into + a LED group or control them individually. + + The difference in these RGB LED drivers is the number of supported RGB + modules. + + For more product information please see the link below: + http://www.ti.com/lit/ds/symlink/lp5012.pdf + http://www.ti.com/lit/ds/symlink/lp5024.pdf + http://www.ti.com/lit/ds/symlink/lp5036.pdf
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 32
Quoted 10 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +10
-0+ +properties: + compatible: + oneOf: + - const: ti,lp5009 + - const: ti,lp5012 + - const: ti,lp5018 + - const: ti,lp5024 + - const: ti,lp5030 + - const: ti,lp5036
Use enum rather than oneOf+const.
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 43
Quoted 11 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +11
-0+ + reg: + maxItems: 1 + description: + I2C slave address + lp5009/12 - 0x14, 0x15, 0x16, 0x17 + lp5018/24 - 0x28, 0x29, 0x2a, 0x2b + lp5030/36 - 0x30, 0x31, 0x32, 0x33 + + enable-gpios: + description: GPIO pin to enable/disable the device.
How many? (maxItems: 1)
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 48
Quoted 5 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +5
-0+ + vled-supply: + description: LED supply. + + child-node:
This literally requires a node called 'child-node'. Not what you want.
You need a $ref to the multi-color schema in here and then only define what's specific to this chip.
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 52
Quoted 4 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +4
-0+ type: object + properties: + reg: + description: This is the LED module number.
Constraints?
Quoted 6 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +6
-0+ + color: + description: Must be LED_COLOR_ID_MULTI + + function: + description: see Documentation/devicetree/bindings/leds/common.txt
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 68
Quoted 10 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +10
-0+ + ti,led-bank: + description: + This property denotes the LED module numbers that will be controlled as + a single RGB cluster. Each LED module number will be controlled by a + single LED class instance. + There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED + modules are to be backed. + $ref: /schemas/types.yaml#definitions/uint32-array
What is reg then? Some made up index? Can't you do:
reg = <1 2 3>;
led@1 {};
led@2 {};
led@2 {};
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 75
Quoted 7 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +7
-0+ + required: + - reg + - color + - function + + grandchild-node:
Again, no.
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 80
Quoted 5 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +5
-0+ type: object + properties: + reg: + description: + A single entry denoting the LED output that controls the monochrome LED.
Constraints?
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 84
Quoted 4 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +4
-0+ + color: + description: + see Documentation/devicetree/bindings/leds/common.txt
Have you read this file recently? Don't add new references to it. (And generally freeform references to other files are wrong with schemas).
Quoted 99 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +96
-0+ + led-sources: + description: + 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 + + label: + description: | + Optional node - see Documentation/devicetree/bindings/leds/common.txt + + linux,default-trigger: + description: | + Optional node - see Documentation/devicetree/bindings/leds/common.txt + + required: + - reg + - color + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/leds/common.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + led-controller@14 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,lp5009"; + reg = <0x14>; + enable-gpios = <&gpio1 16>; + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_CHARGING; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + color = <LED_COLOR_ID_MULTI>; + function = LED_FUNCTION_STANDBY; + ti,led-bank = <2 3 5>; + + led@6 { + reg = <0x6>; + color = <LED_COLOR_ID_RED>; + led-sources = <6 9 15>; + }; + + led@7 { + reg = <0x7>; + color = <LED_COLOR_ID_GREEN>; + led-sources = <7 10 16>; + }; + + led@8 { + reg = <0x8>; + color = <LED_COLOR_ID_BLUE>; + led-sources = <8 11 17>; + }; + }; + }; + }; + +...Signature · 1 line
2.25.1
Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
Rob
Quoted 51 lines · Rob Herring
Quoted 50 lines · Dan Murphy
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.pdfAcked-by Jacek Anaszewski <[email protected]>Signed-off-by Dan Murphy <[email protected]>--- .../devicetree/bindings/leds/leds-lp50xx.yaml | 180 ++++++++++++++++++ 1 file changed, 180 insertions(+)create mode 100644
Documentation/devicetree/bindings/leds/leds-lp50xx.yamlDocumentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +25
-0@@ -0,0 +1,180 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LED driver for LP50XX RGB LED from Texas Instruments. + +maintainers: + - Dan Murphy <[email protected]> + +description: | + The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into + a LED group or control them individually. + + The difference in these RGB LED drivers is the number of supported RGB + modules. + + For more product information please see the link below: + http://www.ti.com/lit/ds/symlink/lp5012.pdf + http://www.ti.com/lit/ds/symlink/lp5024.pdf + http://www.ti.com/lit/ds/symlink/lp5036.pdf + +properties: + compatible:
Quoted 8 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 32
Quoted 7 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +7
-0+ oneOf: + - const: ti,lp5009 + - const: ti,lp5012 + - const: ti,lp5018 + - const: ti,lp5024 + - const: ti,lp5030 + - const: ti,lp5036Use enum rather than oneOf+const.
Ok
Quoted 13 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 43
Quoted 12 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +11
-0+ + reg: + maxItems: 1 + description: + I2C slave address + lp5009/12 - 0x14, 0x15, 0x16, 0x17 + lp5018/24 - 0x28, 0x29, 0x2a, 0x2b + lp5030/36 - 0x30, 0x31, 0x32, 0x33 + + enable-gpios: + description: GPIO pin to enable/disable the device.How many? (maxItems: 1)
1
Quoted 10 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 48
Quoted 6 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +5
-0+ + vled-supply: + description: LED supply. + + child-node:This literally requires a node called 'child-node'. Not what you want.
You need a $ref to the multi-color schema in here and then only define what's specific to this chip.
Ok
Quoted 6 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 52
Quoted 5 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +4
-0+ type: object + properties: + reg: + description: This is the LED module number.Constraints?
What type of constraints are needed here? They vary based on what LED device you are using.
Quoted 19 lines
Quoted 7 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +6
-0+ + color: + description: Must be LED_COLOR_ID_MULTI + + function: + description: see Documentation/devicetree/bindings/leds/common.txtDocumentation/devicetree/bindings/leds/leds-lp50xx.yaml line 68
Quoted 10 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +10
-0+ + ti,led-bank: + description: + This property denotes the LED module numbers that will be controlled as + a single RGB cluster. Each LED module number will be controlled by a + single LED class instance. + There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED + modules are to be backed. + $ref: /schemas/types.yaml#definitions/uint32-arrayWhat is reg then? Some made up index? Can't you do:
Quoted 4 lines
reg = <1 2 3>;
led@1 {};
led@2 {};
led@2 {};
reg becomes the first LED module number in the banked LED group.
This chip has the ability to group or bank and control RGB LED clusters via a single register.
Or the device can control a single RGB LED cluster. The device needs to be programmed with what LED modules are banked
together. The bank numbers and LED module numbers and output numbers are not the same. So this property indicates what modules are banked as in the
multi-led@2 example.
#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>;+ };
+ };
Quoted 8 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 75
Quoted 7 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +7
-0+ + required: + - reg + - color + - function + + grandchild-node:Again, no.
ok
Quoted 7 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 80
Quoted 6 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +5
-0+ type: object + properties: + reg: + description: + A single entry denoting the LED output that controls the monochrome LED.Constraints?
Same as above
Quoted 6 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 84
Quoted 4 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +4
-0+ + color: + description: + see Documentation/devicetree/bindings/leds/common.txtHave you read this file recently? Don't add new references to it. (And generally freeform references to other files are wrong with schemas).
These patchsets and versions have been around for a very long time.
So this and all references to the common.txt are artifacts prior to the text file being obsoleted.
I will reference the common.yaml file.
Dan
Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
In reply to Dan MurphyHi!
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 67
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +3
-0+ There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED + modules are to be backed.
I don't understand the second sentence. Pretty sure it is not valid english.
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
Pavel
Quoted 8 lines · Pavel Machek
Hi!
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 67
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +3
-0+ There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED + modules are to be backed.I don't understand the second sentence. Pretty sure it is not valid english.
If I make these changes is this still viable for 5.8 or would you then go into 5.9?
I mean v25 patchset was around for about 3+ weeks and now I have more changes.
Dan
Quoted 4 lines
Best regards,
Pavel
Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
Hi!
Quoted 9 lines
Quoted 5 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 67
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +3
-0+ There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED + modules are to be backed.I don't understand the second sentence. Pretty sure it is not valid english.
If I make these changes is this still viable for 5.8 or would you then go into 5.9?
It really depends if we get -rc8 or not, and if you'll need to do any changes to C code or not...
Best regards,
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
Hi Pavel and Dan,
Quoted 9 lines · Pavel Machek
Hi!
Quoted 7 lines
Quoted 5 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml line 67
Quoted 3 lines
Documentation/devicetree/bindings/leds/leds-lp50xx.yaml new file +3
-0+ There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED + modules are to be backed.I don't understand the second sentence. Pretty sure it is not valid english.
Quoted 5 lines
Quoted 2 lines
If I make these changes is this still viable for 5.8 or would you then go into 5.9?
It really depends if we get -rc8 or not, and if you'll need to do any changes to C code or not...
I think that we need to simmer such a big extension of the LED subsystem for a whole cycle in linux-next, especially taking into account addition of new sysfs interface, that is bit quirky.
Effectively 5.8 seems to not have been viable since few weeks.
Signature · 2 lines
Best regards, Jacek Anaszewski
Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
Jacek
Quoted 16 lines · Jacek Anaszewski
Hi Pavel and Dan,
Quoted 13 lines · Pavel Machek
Hi!
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
+ There can only be one instance of the ti,led-bank + property for each device node. This is a required node is the LED
+ modules are to be backed.I don't understand the second sentence. Pretty sure it is not valid english.
If I make these changes is this still viable for 5.8 or would you then go into 5.9?
Quoted 9 lines
Quoted 2 lines
It really depends if we get -rc8 or not, and if you'll need to do any changes to C code or not...
I think that we need to simmer such a big extension of the LED subsystem for a whole cycle in linux-next, especially taking into account addition of new sysfs interface, that is bit quirky.
Effectively 5.8 seems to not have been viable since few weeks.
After thinking about this for a while I would actually think to have this in 5.9.
Either 5.7 or 5.8 will be the 2020 LTS and such a new interface would be best suited for intermediate stable releases that get EOL'd faster.
This way we don't have to back port bug fixes for 2 years.
Dan
PATCH v25 4/16 leds: lp50xx: Add the LP50XX family of the RGB LED driver
In reply to Dan MurphyIntroduce 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.
--- drivers/leds/Kconfig | 11 + drivers/leds/Makefile | 1 + drivers/leds/leds-lp50xx.c | 778 +++++++++++++++++++++++++++++++++++++ 3 files changed, 790 insertions(+) create mode 100644 drivers/leds/leds-lp50xx.c
drivers/leds/Kconfig +11 -0
@@ -374,6 +374,17 @@ config LEDS_LP3952 To compile this driver as a module, choose M here: the module will be called leds-lp3952. +config LEDS_LP50XX + tristate "LED Support for TI LP5036/30/24/18/12/9 LED driver chip" + depends on LEDS_CLASS && REGMAP_I2C + depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR + help + If you say yes here you get support for the Texas Instruments + LP5036, LP5030, LP5024, LP5018, LP5012 and LP5009 LED driver. + + To compile this driver as a module, choose M here: the + module will be called leds-lp50xx. + config LEDS_LP55XX_COMMON tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501" depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
drivers/leds/Makefile +1 -0
@@ -48,6 +48,7 @@ obj-$(CONFIG_LEDS_LM3697) += leds-lm3697.o obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o obj-$(CONFIG_LEDS_LP3952) += leds-lp3952.o +obj-$(CONFIG_LEDS_LP50XX) += leds-lp50xx.o obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o obj-$(CONFIG_LEDS_LP5562) += leds-lp5562.o
drivers/leds/leds-lp50xx.c new file +778 -0
778 lines not on this page · raw message
Signature · 1 line
2.25.1
PATCH v25 5/16 dt: bindings: lp55xx: Be consistent in the document with LED acronym
In reply to Dan MurphyUpdate the document to be consistent in case when using "LED". This acronym should be capital throughout the document.
--- Documentation/devicetree/bindings/leds/leds-lp55xx.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Documentation/devicetree/bindings/leds/leds-lp55xx.txt +3 -3
@@ -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
Signature · 1 line
2.25.1
Re: [PATCH v25 05/16] dt: bindings: lp55xx: Be consistent in the document with LED acronym
Quoted 10 lines · Dan Murphy
Update the document to be consistent in case when using "LED". This acronym should be capital throughout the document.
Acked-by Pavel Machek <[email protected]>Acked-by Jacek Anaszewski <[email protected]>Signed-off-by Dan Murphy <[email protected]>--- Documentation/devicetree/bindings/leds/leds-lp55xx.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
PATCH v25 6/16 dt: bindings: lp55xx: Update binding for Multicolor Framework
In reply to Dan MurphyUpdate the DT binding to include the properties to use the multicolor framework for the devices that use the LP55xx framework.
--- .../devicetree/bindings/leds/leds-lp55xx.txt | 149 +++++++++++++++--- 1 file changed, 124 insertions(+), 25 deletions(-)
Documentation/devicetree/bindings/leds/leds-lp55xx.txt +124 -25
@@ -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>; + }; + }; +};
Signature · 1 line
2.25.1
Rob Herring
maintainerRe: [PATCH v25 06/16] dt: bindings: lp55xx: Update binding for Multicolor Framework
Quoted 15 lines · Dan Murphy
Update the DT binding to include the properties to use the multicolor framework for the devices that use the LP55xx framework.
Acked-by Jacek Anaszewski <[email protected]>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]>
Quoted 3 lines
--- .../devicetree/bindings/leds/leds-lp55xx.txt | 149 +++++++++++++++--- 1 file changed, 124 insertions(+), 25 deletions(-)
Convert this to schema first because it's going to need to reference the multi-color schema.
Rob
Re: [PATCH v25 06/16] dt: bindings: lp55xx: Update binding for Multicolor Framework
Rob
Quoted 19 lines · Rob Herring
Quoted 15 lines · Dan Murphy
Update the DT binding to include the properties to use the multicolor framework for the devices that use the LP55xx framework.
Acked-by Jacek Anaszewski <[email protected]>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]>Quoted 3 lines
--- .../devicetree/bindings/leds/leds-lp55xx.txt | 149 +++++++++++++++--- 1 file changed, 124 insertions(+), 25 deletions(-)
Quoted 2 lines
Convert this to schema first because it's going to need to reference the multi-color schema.
OK. This seems to be my life recently converting txt to yaml ;)
Dan
Quoted 1 line
Rob
PATCH v25 7/16 ARM: dts: n900: Add reg property to the LP5523 channel node
In reply to Dan MurphyAdd the reg property to each channel node. This update is to accomodate the multicolor framework. In addition to the accommodation this allows the LEDs to be placed on any channel and allow designs to skip channels as opposed to requiring sequential order.
--- arch/arm/boot/dts/omap3-n900.dts | 29 ++++++++++++++++++++--------- 1 file changed, 20 insertions(+), 9 deletions(-)
arch/arm/boot/dts/omap3-n900.dts +20 -9
@@ -618,63 +618,74 @@ indicator { }; lp5523: lp5523@32 { + #address-cells = <1>; + #size-cells = <0>; compatible = "national,lp5523"; reg = <0x32>; clock-mode = /bits/ 8 <0>; /* LP55XX_CLOCK_AUTO */ enable-gpio = <&gpio2 9 GPIO_ACTIVE_HIGH>; /* 41 */ - chan0 { + chan@0 { chan-name = "lp5523:kb1"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <0>; }; - chan1 { + chan@1 { chan-name = "lp5523:kb2"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <1>; }; - chan2 { + chan@2 { chan-name = "lp5523:kb3"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <2>; }; - chan3 { + chan@3 { chan-name = "lp5523:kb4"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <3>; }; - chan4 { + chan@4 { chan-name = "lp5523:b"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <4>; }; - chan5 { + chan@5 { chan-name = "lp5523:g"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <5>; }; - chan6 { + chan@6 { chan-name = "lp5523:r"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <6>; }; - chan7 { + chan@7 { chan-name = "lp5523:kb5"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <7>; }; - chan8 { + chan@8 { chan-name = "lp5523:kb6"; led-cur = /bits/ 8 <50>; max-cur = /bits/ 8 <100>; + reg = <8>; }; };
Signature · 1 line
2.25.1
PATCH v25 8/16 ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
In reply to Dan MurphyAdd the reg property to each channel node. This update is to accomodate the multicolor framework. In addition to the accommodation this allows the LEDs to be placed on any channel and allow designs to skip channels as opposed to requiring sequential order.
--- arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi +10 -4
@@ -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>; }; };
Signature · 1 line
2.25.1
PATCH v25 9/16 ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
In reply to Dan MurphyAdd the reg property to each channel node. This update is to accomodate the multicolor framework. In addition to the accommodation this allows the LEDs to be placed on any channel and allow designs to skip channels as opposed to requiring sequential order.
--- arch/arm/boot/dts/ste-href.dtsi | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-)
arch/arm/boot/dts/ste-href.dtsi +16 -6
@@ -58,16 +58,21 @@ lp5521@33 { reg = <0x33>; label = "lp5521_pri"; clock-mode = /bits/ 8 <2>; - chan0 { + #address-cells = <1>; + #size-cells = <0>; + chan@0 { + reg = <0>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; linux,default-trigger = "heartbeat"; }; - chan1 { + chan@1 { + reg = <1>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; - chan2 { + chan@2 { + reg = <2>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; };
@@ -77,15 +82,20 @@ lp5521@34 { reg = <0x34>; label = "lp5521_sec"; clock-mode = /bits/ 8 <2>; - chan0 { + #address-cells = <1>; + #size-cells = <0>; + chan@0 { + reg = <0>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; - chan1 { + chan@1 { + reg = <1>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; }; - chan2 { + chan@2 { + reg = <2>; led-cur = /bits/ 8 <0x2f>; max-cur = /bits/ 8 <0x5f>; };
Signature · 1 line
2.25.1
PATCH v25 10/16 leds: lp55xx: Convert LED class registration to devm_*
In reply to Dan MurphyConvert the LED class registration calls to the LED devm_* registration calls.
--- 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(-)
drivers/leds/leds-lp5521.c +3 -6
@@ -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 ;
drivers/leds/leds-lp5523.c +3 -6
@@ -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 ;
drivers/leds/leds-lp5562.c +3 -6
@@ -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 ;
drivers/leds/leds-lp55xx-common.c +1 -14
@@ -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;
drivers/leds/leds-lp55xx-common.h +0 -2
@@ -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);
drivers/leds/leds-lp8501.c +3 -6
@@ -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 ;
Signature · 1 line
2.25.1
PATCH v25 11/16 leds: lp55xx: Add multicolor framework support to lp55xx
In reply to Dan MurphyAdd multicolor framework support for the lp55xx family.
--- 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 | 178 +++++++++++++++++++--- drivers/leds/leds-lp55xx-common.h | 14 +- drivers/leds/leds-lp8501.c | 14 +- include/linux/platform_data/leds-lp55xx.h | 8 + 8 files changed, 209 insertions(+), 47 deletions(-)
drivers/leds/Kconfig +1 -0
@@ -388,6 +388,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
drivers/leds/leds-lp5521.c +8 -6
@@ -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);
drivers/leds/leds-lp5523.c +8 -6
@@ -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);
drivers/leds/leds-lp5562.c +8 -5
@@ -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);
drivers/leds/leds-lp55xx-common.c +156 -22
235 lines not on this page · raw message
drivers/leds/leds-lp55xx-common.h +12 -2
@@ -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,
@@ -93,6 +95,7 @@ struct lp55xx_reg {* @max_channel : Maximum number of channels * @post_init_device : Chip specific initialization code * @brightness_fn : Brightness function +* @multicolor_brightness_fn : Multicolor brightness function * @set_led_current : LED current set function * @firmware_cb : Call function when the firmware is loaded * @run_engine : Run internal engine for pattern
@@ -106,9 +109,12 @@ struct lp55xx_device_config {/* define if the device has specific initialization process */ int (*post_init_device) (struct lp55xx_chip *chip); -/* access brightness register */ +/* set LED brightness */ int (*brightness_fn)(struct lp55xx_led *led); +/* set multicolor LED brightness */ +int (*multicolor_brightness_fn)(struct lp55xx_led *led); +/* current setting function */ void (*set_led_current) (struct lp55xx_led *led,u8 led_current);
@@ -159,6 +165,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 +175,7 @@ struct lp55xx_chip {struct lp55xx_led {int chan_nr;struct led_classdev cdev; +struct led_classdev_mc mc_cdev;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 */
drivers/leds/leds-lp8501.c +8 -6
@@ -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);
include/linux/platform_data/leds-lp55xx.h +8 -0
@@ -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; +int color_id[LED_COLOR_ID_MAX ]; +int output_num[LED_COLOR_ID_MAX ]; }; struct lp55xx_predef_pattern {
Signature · 1 line
2.25.1
kernel test robot
build botRe: [PATCH v25 11/16] leds: lp55xx: Add multicolor framework support to lp55xx
I love your patch! Perhaps something to improve:
Hi Dan,
I love your patch! Perhaps something to improve:
[auto build test WARNING on pavel-linux-leds/for-next]
[also build test WARNING on robh/for-next linus/master v5.7 next-20200603] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Dan-Murphy/Multicolor-Framework-v25/20200527-011531 base: git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git for-next config: x86_64-randconfig-m001-20200603 (attached as .config) compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
If you fix the issue, kindly add following tag as appropriate
smatch warnings:drivers/leds/leds-lp55xx-common.c:215 lp55xx_init_led() warn: inconsistent indenting
vim +215 drivers/leds/leds-lp55xx-common.c
160
161 static int lp55xx_init_led(struct lp55xx_led *led,
162 struct lp55xx_chip *chip, int chan)
163 {
164 struct lp55xx_platform_data *pdata = chip->pdata;
165 struct lp55xx_device_config *cfg = chip->cfg;
166 struct device *dev = &chip->cl->dev;
167 int max_channel = cfg->max_channel;
168 struct mc_subled *mc_led_info;
169 struct led_classdev *led_cdev;
170 char name[32];
171 int i, j = 0;
172 int ret;
173
174 if (chan >= max_channel) {
175 dev_err(dev, "invalid channel: %d / %d\n", chan, max_channel);
176 return -EINVAL;
177 }
178
179 if (pdata->led_config[chan].led_current == 0)
180 return 0;
181
182 if (pdata->led_config[chan].name) {
183 led->cdev.name = pdata->led_config[chan].name;
184 } else {
185 snprintf(name, sizeof(name), "%s:channel%d",
186 pdata->label ? : chip->cl->name, chan);
187 led->cdev.name = name;
188 }
189
190 if (pdata->led_config[chan].num_colors > 1) {
191 mc_led_info = devm_kcalloc(dev,
192 pdata->led_config[chan].num_colors,
193 sizeof(*mc_led_info), GFP_KERNEL);
194 if (!mc_led_info)
195 return -ENOMEM;
196
197 led_cdev = &led->mc_cdev.led_cdev;
198 led_cdev->name = led->cdev.name;
199 led_cdev->brightness_set_blocking = lp55xx_set_mc_brightness;
200 led_cdev->groups = lp55xx_led_groups;
201 led->mc_cdev.num_colors = pdata->led_config[chan].num_colors;
202 for (i = 0; i < led->mc_cdev.num_colors; i++) {
203 mc_led_info[i].color_index =
204 pdata->led_config[chan].color_id[i];
205 mc_led_info[i].channel =
206 pdata->led_config[chan].output_num[i];
207 j++;
208 }
209
210 led->mc_cdev.subled_info = mc_led_info;
211 } else {
212 led->cdev.default_trigger =
213 pdata->led_config[chan].default_trigger;
214 led->cdev.brightness_set_blocking = lp55xx_set_brightness;
> 215 } led->cdev.groups = lp55xx_led_groups;
216
217 led->led_current = pdata->led_config[chan].led_current;
218 led->max_current = pdata->led_config[chan].max_current;
219 led->chan_nr = pdata->led_config[chan].chan_nr;
220
221 if (led->chan_nr >= max_channel) {
222 dev_err(dev, "Use channel numbers between 0 and %d\n",
223 max_channel - 1);
224 return -EINVAL;
225 }
226
227 if (pdata->led_config[chan].num_colors > 1)
228 ret = devm_led_classdev_multicolor_register(dev, &led->mc_cdev);
229 else
230 ret = devm_led_classdev_register(dev, &led->cdev);
231
232 if (ret) {
233 dev_err(dev, "led register err: %d\n", ret);
234 return ret;
235 }
236
237 return 0;
238 }
239
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
PATCH v25 12/16 leds: lp5523: Update the lp5523 code to add multicolor brightness function
In reply to Dan MurphyAdd the multicolor brightness call back to support the multicolor framework. This call back allows setting brightness on grouped channels in a single function.
--- drivers/leds/Kconfig | 1 + drivers/leds/leds-lp5523.c | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+)
drivers/leds/Kconfig +1 -0
@@ -408,6 +408,7 @@ config LEDS_LP5521 config LEDS_LP5523 tristate "LED Support for TI/National LP5523/55231 LED driver chip" depends on LEDS_CLASS && I2C + depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR select LEDS_LP55XX_COMMON help If you say yes here you get support for TI/National Semiconductor
drivers/leds/leds-lp5523.c +20 -0
@@ -791,6 +791,25 @@ static ssize_t store_master_fader_leds(struct device *dev,return ret; } +static int lp5523_multicolor_brightness (struct lp55xx_led *led) +{ +struct lp55xx_chip *chip = led->chip; +int ret; +int i; + +mutex_lock (&chip->lock); +for (i =0 ; i < led->mc_cdev.num_colors; i++) { + ret =lp55xx_write (chip, +LP5523_REG_LED_PWM_BASE + + led->mc_cdev.subled_info[i].channel, + led->mc_cdev.subled_info[i].brightness); +if (ret) +break ; + } +mutex_unlock (&chip->lock); +return ret; +} +static int lp5523_led_brightness (struct lp55xx_led *led) {struct lp55xx_chip *chip = led->chip;
@@ -857,6 +876,7 @@ static struct lp55xx_device_config lp5523_cfg = { .max_channel = LP5523_MAX_LEDS, .post_init_device = lp5523_post_init_device, .brightness_fn = lp5523_led_brightness, + .multicolor_brightness_fn = lp5523_multicolor_brightness, .set_led_current = lp5523_set_led_current, .firmware_cb = lp5523_firmware_loaded, .run_engine = lp5523_run_engine,
Signature · 1 line
2.25.1
PATCH v25 13/16 leds: lp5521: Add multicolor framework multicolor brightness support
In reply to Dan MurphyAdd the multicolor brightness call back to support the multicolor framework. This function allows setting the brightness across grouped LED channels in a single call.
--- drivers/leds/Kconfig | 1 + drivers/leds/leds-lp5521.c | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+)
drivers/leds/Kconfig +1 -0
@@ -398,6 +398,7 @@ config LEDS_LP55XX_COMMON config LEDS_LP5521 tristate "LED Support for N.S. LP5521 LED driver chip" depends on LEDS_CLASS && I2C + depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR select LEDS_LP55XX_COMMON help If you say yes here you get support for the National Semiconductor
drivers/leds/leds-lp5521.c +20 -0
@@ -349,6 +349,25 @@ static int lp5521_run_selftest(struct lp55xx_chip *chip, char *buf)return 0 ; } +static int lp5521_multicolor_brightness (struct lp55xx_led *led) +{ +struct lp55xx_chip *chip = led->chip; +int ret; +int i; + +mutex_lock (&chip->lock); +for (i =0 ; i < led->mc_cdev.num_colors; i++) { + ret =lp55xx_write (chip, +LP5521_REG_LED_PWM_BASE + + led->mc_cdev.subled_info[i].channel, + led->mc_cdev.subled_info[i].brightness); +if (ret) +break ; + } +mutex_unlock (&chip->lock); +return ret; +} +static int lp5521_led_brightness (struct lp55xx_led *led) {struct lp55xx_chip *chip = led->chip;
@@ -490,6 +509,7 @@ static struct lp55xx_device_config lp5521_cfg = { .max_channel = LP5521_MAX_LEDS, .post_init_device = lp5521_post_init_device, .brightness_fn = lp5521_led_brightness, + .multicolor_brightness_fn = lp5521_multicolor_brightness, .set_led_current = lp5521_set_led_current, .firmware_cb = lp5521_firmware_loaded, .run_engine = lp5521_run_engine,
Signature · 1 line
2.25.1
PATCH v25 14/16 leds: lp55xx: Fix checkpatch file permissions issues
In reply to Dan MurphyFix 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.
--- drivers/leds/leds-lp55xx-common.c | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-)
drivers/leds/leds-lp55xx-common.c +10 -12
@@ -83,7 +83,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) {
@@ -92,7 +92,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) {
@@ -116,7 +116,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) {
@@ -125,9 +125,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,
@@ -272,7 +271,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) {
@@ -282,7 +281,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) {
@@ -324,7 +323,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) {
@@ -349,9 +348,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,
Signature · 1 line
2.25.1
PATCH v25 15/16 leds: lp5523: Fix checkpatch issues in the code
In reply to Dan MurphyFix checkpatch errors and warnings for the LP5523.c device driver.
--- drivers/leds/leds-lp5523.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
drivers/leds/leds-lp5523.c +10 -9
@@ -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;
Signature · 1 line
2.25.1
PATCH v25 16/16 dt: bindings: Update lp55xx binding to recommended LED naming
In reply to Dan MurphyUpdate the LP55xx DT binding examples to the recommended node naming convention. There are no changes to the DT properties.
--- .../devicetree/bindings/leds/leds-lp55xx.txt | 58 +++++++++---------- 1 file changed, 29 insertions(+), 29 deletions(-)
Documentation/devicetree/bindings/leds/leds-lp55xx.txt +29 -29
@@ -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>;
Signature · 1 line
2.25.1