Thread (18 messages) 18 messages, 6 authors, 2026-01-14

Re: [PATCH v6 1/4] dt-bindings: backlight: Add max25014 support

From: Maud Spierings <maudspierings@gocontroll.com>
Date: 2025-12-08 13:57:00
Also in: dri-devel, imx, linux-devicetree, linux-fbdev, linux-leds, lkml

On 12/2/25 15:53, Frank Li wrote:
On Tue, Dec 02, 2025 at 08:46:21AM +0100, Maud Spierings wrote:
quoted
On 12/1/25 17:52, Frank Li wrote:
quoted
On Mon, Dec 01, 2025 at 12:53:20PM +0100, Maud Spierings via B4 Relay wrote:
quoted
From: Maud Spierings <maudspierings@gocontroll.com>

The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
with integrated boost controller.

Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>

---

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 <maudspierings@gocontroll.com>
+
+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

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help