On 12/2/25 15:53, Frank Li wrote:
On Tue, Dec 02, 2025 at 08:46:21AM +0100, Maud Spierings wrote:
On 12/1/25 17:52, Frank Li wrote:
On Mon, Dec 01, 2025 at 12:53:20PM +0100, Maud Spierings via B4 Relay wrote:
From: Maud Spierings <[email protected]>
The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
with integrated boost controller.
Signed-off-by: Maud Spierings <[email protected]>
---
In the current implementation the control registers for channel 1,
control all channels. So only one led subnode with led-sources is
supported right now. If at some point the driver functionality is
expanded the bindings can be easily extended with it.
---
.../bindings/leds/backlight/maxim,max25014.yaml | 107
+++++++++++++++++++++
MAINTAINERS | 5 +
2 files changed, 112 insertions(+)
diff --git
a/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
new file mode 100644
index 000000000000..e83723224b07
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/maxim,max25014.yaml
@@ -0,0 +1,107 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/maxim,max25014.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim max25014 backlight controller
+
+maintainers:
+ - Maud Spierings <[email protected]>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max25014
+
+ reg:
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ enable-gpios:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-supply:
+ description: Regulator which controls the boost converter input rail.
+
+ pwms:
+ maxItems: 1
+
+ maxim,iset:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 15
+ default: 11
+ description:
+ Value of the ISET field in the ISET register. This controls the current
+ scale of the outputs, a higher number means more current.
+
+ led@0:
define whole binding, allow 0-3. binding is not related with driver's
implement.
it'd better put unders leds.
so like:
backlight: backlight@6f {
compatible = "maxim,max25014";
reg = <0x6f>;
enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_backlight>;
maxim,iset = <7>;
leds {
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0>;
led-sources = <0 1 2>;
default-brightness = <50>;
};
optional led@#....
};
};
right?
yes.
I am feeling a bit weird about these led sub nodes, because it is not
programmed as a led driver, it is programmed as a backlight. I am trying
to figure out how this would be used later when the led strings are
individually controllable.
it isn't possible to link the seperate strings to different displays
because it is only one backlight device, so I don't seen any reason why
it would ever be used in another way than what it is now, were all
strings are programmed by one register.
The only way I can make sense of it is if instead I program this device
as a led driver and then use the led_bl driver as the actual backlight.
Thats a pretty big step in a different direction, but then the led
subnodes at least can be properly used I feel.
Kind regards,
Maud
