The LP5812 is a 4×3 RGB LED driver with an autonomous animation engine
and time-cross-multiplexing (TCM) support for up to 12 LEDs.
It supports both analog (256 levels) and PWM (8-bit) dimming,
including exponential PWM for smooth brightness control.
Signed-off-by: Nam Tran <trannamatk@gmail.com>
---
.../devicetree/bindings/leds/ti,lp5812.yaml | 119 ++++++++++++++++++
MAINTAINERS | 6 +
2 files changed, 125 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/ti,lp5812.yaml
diff --git a/Documentation/devicetree/bindings/leds/ti,lp5812.yaml b/Documentation/devicetree/bindings/leds/ti,lp5812.yaml
new file mode 100644
index 000000000000..448d6f87b586
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti,lp5812.yaml
@@ -0,0 +1,119 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti,lp5812.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI/National Semiconductor LP5812 LED Driver
+
+maintainers:
+ - Nam Tran <trannamatk@gmail.com>
+
+description: |
+ The LP5812 is an I2C LED Driver that can support LED matrix 4x3.
+ For more product information please see the link below:
+ https://www.ti.com/product/LP5812#tech-docs
+
+properties:
+ compatible:
+ const: ti,lp5812
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^led@[0-9a-b]$":
+ type: object
+ $ref: common.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ minimum: 0
+ maximum: 0xb
+
+ chan-name:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: LED channel name
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1b {
+ compatible = "ti,lp5812";
+ reg = <0x1b>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0x0>;
+ chan-name = "a0";
+ };
+ led@1 {
+ reg = <0x1>;
+ chan-name = "a1";
+ };
+ led@2 {
+ reg = <0x2>;
+ chan-name = "a2";
+ };
+ led@3 {
+ reg = <0x3>;
+ chan-name = "b0";
+ };
+ led@4 {
+ reg = <0x4>;
+ chan-name = "b1";
+ };
+ led@5 {
+ reg = <0x5>;
+ chan-name = "b2";
+ };
+ led@6 {
+ reg = <0x6>;
+ chan-name = "c0";
+ };
+ led@7 {
+ reg = <0x7>;
+ chan-name = "c1";
+ };
+ led@8 {
+ reg = <0x8>;
+ chan-name = "c2";
+ };
+ led@9 {
+ reg = <0x9>;
+ chan-name = "d0";
+ };
+ led@a {
+ reg = <0xa>;
+ chan-name = "d1";
+ };
+ led@b {
+ reg = <0xb>;
+ chan-name = "d2";
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index c59316109e3f..3901c04b9734 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23934,6 +23934,12 @@ S: Supported
F: Documentation/devicetree/bindings/iio/dac/ti,dac7612.yaml
F: drivers/iio/dac/ti-dac7612.c
+TEXAS INSTRUMENTS' LP5812 LED DRIVER
+M: Nam Tran <trannamatk@gmail.com>
+L: linux-leds@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/leds/ti,lp5812.yaml
+
TEXAS INSTRUMENTS' LB8864 LED BACKLIGHT DRIVER
M: Alexander Sverdlin <alexander.sverdlin@siemens.com>
L: linux-leds@vger.kernel.org
--
2.25.1
On 14/04/2025 16:57, Nam Tran wrote: > + > +description: | > + The LP5812 is an I2C LED Driver that can support LED matrix 4x3. > + For more product information please see the link below: > + https://www.ti.com/product/LP5812#tech-docs > + > +properties: > + compatible: > + const: ti,lp5812 > + > + reg: > + maxItems: 1 > + > + "#address-cells": > + const: 1 > + > + "#size-cells": > + const: 0 No need for supply? > + > +patternProperties: > + "^led@[0-9a-b]$": > + type: object > + $ref: common.yaml# > + unevaluatedProperties: false > + > + properties: > + reg: > + minimum: 0 > + maximum: 0xb > + > + chan-name: > + $ref: /schemas/types.yaml#/definitions/string > + description: LED channel name My comment stay valid. I don't think LEDs have channels, datasheet also has nothing about channels, so again - use existing properties. Or better drop it - I don't see any point in the name. The reg already defines it. However after dropping this, your example has nodes with only reg - what's the point of them? Why no properties from common.yaml are applicable? If they are not applicable, then the entire subnode should be dropped - you don't need them to describe the hardware. Best regards, Krzysztof
On Mon, 14 Apr 2025, Krzysztof Kozlowski wrote: > On 14/04/2025 16:57, Nam Tran wrote: > > + > > +description: | > > + The LP5812 is an I2C LED Driver that can support LED matrix 4x3. > > + For more product information please see the link below: > > + https://www.ti.com/product/LP5812#tech-docs > > + > > +properties: > > + compatible: > > + const: ti,lp5812 > > + > > + reg: > > + maxItems: 1 > > + > > + "#address-cells": > > + const: 1 > > + > > + "#size-cells": > > + const: 0 > > No need for supply? Since the hardware uses an external power supply, we decide not to include the supply property in the binding. > > + > > +patternProperties: > > + "^led@[0-9a-b]$": > > + type: object > > + $ref: common.yaml# > > + unevaluatedProperties: false > > + > > + properties: > > + reg: > > + minimum: 0 > > + maximum: 0xb > > + > > + chan-name: > > + $ref: /schemas/types.yaml#/definitions/string > > + description: LED channel name > > My comment stay valid. I don't think LEDs have channels, datasheet also > has nothing about channels, so again - use existing properties. Or > better drop it - I don't see any point in the name. The reg already > defines it. The channel was named for the output channel to each LED, not the LED channels. They are not required properties because we can control entirely the LEDs of LP5812 through the indexes (regs property), but the person who wants to develop LP5812's matrix-related features can use the "channels" for easy mapping. > > However after dropping this, your example has nodes with only reg - > what's the point of them? Why no properties from common.yaml are > applicable? If they are not applicable, then the entire subnode should > be dropped - you don't need them to describe the hardware. Actually, the "color" property can be applied, but the LP5812 is a matrix LED, so specifying a particular LED color is not necessary when developing LP5812 features. Best regards, Nam Tran
On 15/04/2025 11:53, Nam Tran wrote: > On Mon, 14 Apr 2025, Krzysztof Kozlowski wrote: > >> On 14/04/2025 16:57, Nam Tran wrote: >>> + >>> +description: | >>> + The LP5812 is an I2C LED Driver that can support LED matrix 4x3. >>> + For more product information please see the link below: >>> + https://www.ti.com/product/LP5812#tech-docs >>> + >>> +properties: >>> + compatible: >>> + const: ti,lp5812 >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + "#address-cells": >>> + const: 1 >>> + >>> + "#size-cells": >>> + const: 0 >> >> No need for supply? > > Since the hardware uses an external power supply, > we decide not to include the supply property in the binding. So there is power supply? If so, must be in the binding. Bindings describe given hardware (LP5812), not your particular board/setup. > >>> + >>> +patternProperties: >>> + "^led@[0-9a-b]$": >>> + type: object >>> + $ref: common.yaml# >>> + unevaluatedProperties: false >>> + >>> + properties: >>> + reg: >>> + minimum: 0 >>> + maximum: 0xb >>> + >>> + chan-name: >>> + $ref: /schemas/types.yaml#/definitions/string >>> + description: LED channel name >> >> My comment stay valid. I don't think LEDs have channels, datasheet also >> has nothing about channels, so again - use existing properties. Or >> better drop it - I don't see any point in the name. The reg already >> defines it. > > The channel was named for the output channel to each LED, not the LED channels. I don't understand what you want to say. Please explain why existing label property is not correct here. > They are not required properties because we can control entirely the LEDs of LP5812 through the indexes (regs property), I did not ask about this. > but the person who wants to develop LP5812's matrix-related features can use the "channels" for easy mapping. easy mapping of what? Please show me the usage. > >> >> However after dropping this, your example has nodes with only reg - >> what's the point of them? Why no properties from common.yaml are >> applicable? If they are not applicable, then the entire subnode should >> be dropped - you don't need them to describe the hardware. > > Actually, the "color" property can be applied, but the LP5812 is a matrix LED, > so specifying a particular LED color is not necessary when developing LP5812 features. This does not help me much and based on this I see no points in describing individual LEDs, because the only missing information is number of them but even that is fixed for given device, isn't it? Best regards, Krzysztof
On Tue, 15 Apr 2025, Krzysztof Kozlowski wrote: >On 15/04/2025 11:53, Nam Tran wrote: >> On Mon, 14 Apr 2025, Krzysztof Kozlowski wrote: >> >>> On 14/04/2025 16:57, Nam Tran wrote: >>>> + >>>> +description: | >>>> + The LP5812 is an I2C LED Driver that can support LED matrix 4x3. >>>> + For more product information please see the link below: >>>> + https://www.ti.com/product/LP5812#tech-docs >>>> + >>>> +properties: >>>> + compatible: >>>> + const: ti,lp5812 >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + "#address-cells": >>>> + const: 1 >>>> + >>>> + "#size-cells": >>>> + const: 0 >>> >>> No need for supply? >> >> Since the hardware uses an external power supply, >> we decide not to include the supply property in the binding. > >So there is power supply? If so, must be in the binding. Bindings >describe given hardware (LP5812), not your particular board/setup. Thank you for the clarification. The LP5812 is externally powered and has a dedicated VCC pin. I'll update the binding to include a `vcc-supply` property. >> >>>> + >>>> +patternProperties: >>>> + "^led@[0-9a-b]$": >>>> + type: object >>>> + $ref: common.yaml# >>>> + unevaluatedProperties: false >>>> + >>>> + properties: >>>> + reg: >>>> + minimum: 0 >>>> + maximum: 0xb >>>> + >>>> + chan-name: >>>> + $ref: /schemas/types.yaml#/definitions/string >>>> + description: LED channel name >>> >>> My comment stay valid. I don't think LEDs have channels, datasheet also >>> has nothing about channels, so again - use existing properties. Or >>> better drop it - I don't see any point in the name. The reg already >>> defines it. >> >> The channel was named for the output channel to each LED, not the LED channels. > >I don't understand what you want to say. Please explain why existing >label property is not correct here. I understand that the label property is deprecated and that the preferred approach now is to use function and color instead. However, in the case of the LP5812, which is a matrix LED driver, these properties are not a good fit. The LP5812 does not associate each output with a specific function (like "status", "activity"), and the LEDs driven by LP5812 are not fixed to a particular color. >> but the person who wants to develop LP5812's matrix-related features can use the "channels" for easy mapping. > >easy mapping of what? Please show me the usage. You're right — I cannot provide a meaningful usage example for chan-name. The chan-name property was intended to give a more descriptive name for each LED channel, mainly for convenience in user space. But since this isn’t standard and you advised against introducing such a property, we’ve decided to drop it. >> >>> >>> However after dropping this, your example has nodes with only reg - >>> what's the point of them? Why no properties from common.yaml are >>> applicable? If they are not applicable, then the entire subnode should >>> be dropped - you don't need them to describe the hardware. >> >> Actually, the "color" property can be applied, but the LP5812 is a matrix LED, >> so specifying a particular LED color is not necessary when developing LP5812 features. > >This does not help me much and based on this I see no points in >describing individual LEDs, because the only missing information is >number of them but even that is fixed for given device, isn't it? Actually, the number of LED outputs on the LP5812 is not strictly fixed — it depends on the selected operating mode. This mode is configurable by the end user at runtime through sysfs interfaces provided by the driver. I understand your point — if no additional properties from common.yaml are applicable, these subnodes may not be necessary. Therefore, we’ve decided to drop them. Best regards, Nam Tran
On 17/04/2025 04:06, Nam Tran wrote: > >>> >>>>> + >>>>> +patternProperties: >>>>> + "^led@[0-9a-b]$": >>>>> + type: object >>>>> + $ref: common.yaml# >>>>> + unevaluatedProperties: false >>>>> + >>>>> + properties: >>>>> + reg: >>>>> + minimum: 0 >>>>> + maximum: 0xb >>>>> + >>>>> + chan-name: >>>>> + $ref: /schemas/types.yaml#/definitions/string >>>>> + description: LED channel name >>>> >>>> My comment stay valid. I don't think LEDs have channels, datasheet also >>>> has nothing about channels, so again - use existing properties. Or >>>> better drop it - I don't see any point in the name. The reg already >>>> defines it. >>> >>> The channel was named for the output channel to each LED, not the LED channels. >> >> I don't understand what you want to say. Please explain why existing >> label property is not correct here. > > I understand that the label property is deprecated and that the preferred approach now is to use function and color instead. > However, in the case of the LP5812, which is a matrix LED driver, these properties are not a good fit. > The LP5812 does not associate each output with a specific function (like "status", "activity"), > and the LEDs driven by LP5812 are not fixed to a particular color. Then use label instead of creating another property. If label is deprecated, how creating another property which duplicates the label solves anything? Best regards, Krzysztof
On Thu, 17 Apr 2025, Krzysztof Kozlowski wrote: >On 17/04/2025 04:06, Nam Tran wrote: >> >>>> >>>>>> + >>>>>> +patternProperties: >>>>>> + "^led@[0-9a-b]$": >>>>>> + type: object >>>>>> + $ref: common.yaml# >>>>>> + unevaluatedProperties: false >>>>>> + >>>>>> + properties: >>>>>> + reg: >>>>>> + minimum: 0 >>>>>> + maximum: 0xb >>>>>> + >>>>>> + chan-name: >>>>>> + $ref: /schemas/types.yaml#/definitions/string >>>>>> + description: LED channel name >>>>> >>>>> My comment stay valid. I don't think LEDs have channels, datasheet also >>>>> has nothing about channels, so again - use existing properties. Or >>>>> better drop it - I don't see any point in the name. The reg already >>>>> defines it. >>>> >>>> The channel was named for the output channel to each LED, not the LED channels. >>> >>> I don't understand what you want to say. Please explain why existing >>> label property is not correct here. >> >> I understand that the label property is deprecated and that the preferred approach now is to use function and color instead. >> However, in the case of the LP5812, which is a matrix LED driver, these properties are not a good fit. >> The LP5812 does not associate each output with a specific function (like "status", "activity"), >> and the LEDs driven by LP5812 are not fixed to a particular color. > >Then use label instead of creating another property. If label is >deprecated, how creating another property which duplicates the label >solves anything? You're right — creating a new property like chan-name does not help if it duplicates the purpose of the deprecated label property. I initially created the chan-name property after referring to the existing leds-lp55xx.yaml binding. However, based on your recommendation, I’ve decided to drop chan-name and the entire subnode as well. Additionally, I will add the vcc-supply property as mentioned in the last email. Would this be sufficient for me to submit a new patch? Best regards, Nam Tran
© 2016 - 2025 Red Hat, Inc.