On 12/9/25 20:07, Rob Herring wrote:
On Mon, Dec 08, 2025 at 02:56:50PM +0100, Maud Spierings wrote:
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.
If you don't have any use for anything other than driving a single
backlight, then I'd just drop the led nodes completely.
Theoretically with how the registers are laid out, it should be able to
control 4 led strings individually. But as I said when I configure led
string 1 it will also affect all the others seemingly. I am not sure if
with some other configuration you can indeed do individual control.
Before I start converting stuff back to how it was several versions ago.
Frank, do you agree with removing the led nodes in this case? I don't
want to get stuck between two different paths.
Kind regards,
Maud
