* [PATCH v2 2/5] arm64: dts: renesas: r9a09g077: Add DU node
From: Prabhakar @ 2026-06-15 11:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-renesas-soc, devicetree, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add Display Unit (DU) node to SoC DTSI.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- No change
---
arch/arm64/boot/dts/renesas/r9a09g077.dtsi | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
index dda7008acdd9..93e792d0c4a0 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
@@ -1377,6 +1377,30 @@ sdhi1_vqmmc: vqmmc-regulator {
};
};
+ du: display@920c0000 {
+ compatible = "renesas,r9a09g077-du";
+ reg = <0 0x920c0000 0 0x10000>;
+ interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
+ <&cpg CPG_MOD 1204>,
+ <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ renesas,vsps = <&vspd 0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+ };
+ };
+
fcpvd: fcp@920d0000 {
compatible = "renesas,r9a09g077-fcpvd", "renesas,fcpv";
reg = <0 0x920d0000 0 0x10000>;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 3/5] arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes
From: Prabhakar @ 2026-06-15 11:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-renesas-soc, devicetree, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add VSPD and FCPVD nodes to RZ/N2H SoC DTSI.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- Dropped internal RB tag
---
arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
index e8d4f76949cc..174f683fa68d 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
@@ -1379,6 +1379,28 @@ sdhi1_vqmmc: vqmmc-regulator {
status = "disabled";
};
};
+
+ fcpvd: fcp@920d0000 {
+ compatible = "renesas,r9a09g087-fcpvd", "renesas,fcpv";
+ reg = <0 0x920d0000 0 0x10000>;
+ clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
+ <&cpg CPG_MOD 1204>,
+ <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ };
+
+ vspd: vsp@920e0000 {
+ compatible = "renesas,r9a09g087-vsp2", "renesas,r9a07g044-vsp2";
+ reg = <0 0x920e0000 0 0x8000>;
+ interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
+ <&cpg CPG_MOD 1204>,
+ <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ renesas,fcp = <&fcpvd>;
+ };
};
stmmac_axi_setup: stmmac-axi-config {
--
2.54.0
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: renesas: r9a09g087: Add DU node
From: Prabhakar @ 2026-06-15 11:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-renesas-soc, devicetree, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add Display Unit (DU) node to SoC DTSI.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- No change
---
arch/arm64/boot/dts/renesas/r9a09g087.dtsi | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
index 174f683fa68d..308d3ccc21d1 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
@@ -1380,6 +1380,30 @@ sdhi1_vqmmc: vqmmc-regulator {
};
};
+ du: display@920c0000 {
+ compatible = "renesas,r9a09g087-du", "renesas,r9a09g077-du";
+ reg = <0 0x920c0000 0 0x10000>;
+ interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
+ <&cpg CPG_MOD 1204>,
+ <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
+ clock-names = "aclk", "pclk", "vclk";
+ power-domains = <&cpg>;
+ renesas,vsps = <&vspd 0>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ du_out_rgb: endpoint {
+ };
+ };
+ };
+ };
+
fcpvd: fcp@920d0000 {
compatible = "renesas,r9a09g087-fcpvd", "renesas,fcpv";
reg = <0 0x920d0000 0 0x10000>;
--
2.54.0
^ permalink raw reply related
* [PATCH v2 5/5] arm64: dts: renesas: Add LCDC overlays for RZ/T2H and RZ/N2H EVKs with ADV7513
From: Prabhakar @ 2026-06-15 11:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-renesas-soc, devicetree, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Add DT overlay support enabling the DU/LCDC pipeline on the RZ/T2H
(r9a09g077) and RZ/N2H (r9a09g087) evaluation kits when fitted with a
CN15/CN20 ADV7513 HDMI transmitter.
Move the LED8 and LED9 preprocessor conditionals inside the node
definitions so that the nodes remain present in the base DTS. This
allows the LCDC overlay to reference and disable them when their pins
are reassigned to display functions.
According to the hardware manual, the LCDC pins should use slew-rate
setting 1 (fast). However, testing on the RZ/T2H and RZ/N2H EVKs with
the ADV7513 HDMI transmitter showed unstable display output with visible
screen flicker when configured for fast slew-rate operation. Configure
the LCDC pins with slew-rate setting 0 (slow) instead, which provides
stable display output on the evaluation platforms.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
v1->v2:
- Fixed typo in makefile for CONFIG_ARCH_R9A09G087
- Explicitly disabled the led7 and key-1 in the overlay
- Dropped comment about DSW5[3]
- Updated commit message
---
arch/arm64/boot/dts/renesas/Makefile | 6 +++
.../renesas/r9a09g077m44-evk-cn15-lcdc.dtso | 40 +++++++++++++++
.../renesas/r9a09g087m44-evk-cn20-lcdc.dtso | 50 +++++++++++++++++++
.../dts/renesas/r9a09g087m44-rzn2h-evk.dts | 12 +++--
.../dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi | 50 +++++++++++++++++++
5 files changed, 154 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso
create mode 100644 arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
create mode 100644 arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi
diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index 8bf155badd11..e4a7d7ab5b0e 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -216,8 +216,14 @@ r9a09g057h48-kakip-pixpaper-dtbs := r9a09g057h48-kakip.dtb r9a09g057h48-kakip-pi
dtb-$(CONFIG_ARCH_R9A09G057) += r9a09g057h48-kakip-pixpaper.dtb
dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-rzt2h-evk.dtb
+dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-evk-cn15-lcdc.dtbo
+r9a09g077m44-rzt2h-evk-cn15-lcdc-dtbs := r9a09g077m44-rzt2h-evk.dtb r9a09g077m44-evk-cn15-lcdc.dtbo
+dtb-$(CONFIG_ARCH_R9A09G077) += r9a09g077m44-rzt2h-evk-cn15-lcdc.dtb
dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-rzn2h-evk.dtb
+dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-evk-cn20-lcdc.dtbo
+r9a09g087m44-rzn2h-evk-cn20-lcdc-dtbs := r9a09g087m44-rzn2h-evk.dtb r9a09g087m44-evk-cn20-lcdc.dtbo
+dtb-$(CONFIG_ARCH_R9A09G087) += r9a09g087m44-rzn2h-evk-cn20-lcdc.dtb
dtb-$(CONFIG_ARCH_RCAR_GEN3) += draak-ebisu-panel-aa104xd12.dtbo
dtb-$(CONFIG_ARCH_RCAR_GEN3) += salvator-panel-aa104xd12.dtbo
diff --git a/arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso b/arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso
new file mode 100644
index 000000000000..41c695325729
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r9a09g077m44-evk-cn15-lcdc.dtso
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT overlay for the RZ/T2H EVK with ADV7513 transmitter
+ * connected to DU enabled.
+ *
+ * Copyright (C) 2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * RZ/T2H LCDC configuration:
+ * ----------------------------------------------------------
+ * Function Pin SW Setting
+ * ----------------------------------------------------------
+ * LCDC_DATG0 P11_0, SW6[3]: OFF, SW6[4]: ON, SW6[5]: OFF
+ * LCDC_DATB1 P18_0, SW8[3]: OFF, SW8[4]: ON
+ * LCDC_DATB2 P18_1, SW8[1]: OFF, SW8[2]: ON
+ * HEADER_IRQ8 P22_6, SW2[1]: ON, SW2[2]: OFF
+ */
+#include "rzt2h-n2h-evk-du-adv7513.dtsi"
+
+&{/leds/led-4} {
+ /* P18_0 is used for DU function LCDC_DATB1. */
+ status = "disabled";
+};
+
+&{/leds/led-5} {
+ /* P18_1 is used for DU function LCDC_DATB2. */
+ status = "disabled";
+};
+
+/*
+ * Disable SDHI0 as SW2 settings for eMMC/SD card conflict with DU pin
+ * settings.
+ */
+&sdhi0 {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
new file mode 100644
index 000000000000..17bc71380860
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT overlay for the RZ/N2H EVK with ADV7513 transmitter
+ * connected to DU enabled.
+ *
+ * Copyright (C) 2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * RZ/N2H LCDC configuration:
+ * ----------------------------------------------------------
+ * Function Pin SW Setting
+ * ----------------------------------------------------------
+ * LCDC_DATG0 P11_0, DSW12[3]: ON, DSW12[4]: OFF
+ * LCDC_DATG3 P14_3, DSW18[5]: OFF, DSW18[6]: ON
+ * LCDC_DATG6 P14_6, DSW15[8]: ON, DSW15[9]: OFF, DSW15[10]: OFF
+ * LCDC_DATB2 P18_1, DSW18[9]: OFF, DSW18[10]: ON
+ * I2C_SDA1 P03_3, DSW7[1]: ON, DSW7[2]: OFF
+ * I2C_SCL1 P03_4, DSW7[3]: ON, DSW7[4]: OFF
+ * ------------------------------------------------
+ */
+
+#include "rzt2h-n2h-evk-du-adv7513.dtsi"
+
+&{/keys/key-1} {
+ /* P18_2 is used for DU function LCDC_DATB3. */
+ status = "disabled";
+};
+
+&{/leds/led-4} {
+ /* P18_1 is used for DU function LCDC_DATB2. */
+ status = "disabled";
+};
+
+&{/leds/led-7} {
+ /* P14_3 is used for DU function LCDC_DATG3. */
+ status = "disabled";
+};
+
+&{/leds/led-8} {
+ /* P14_6 is used for DU function LCDC_DATG6. */
+ status = "disabled";
+};
+
+&i2c0 {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
index 4e57d4fe195c..5176e620685a 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
+++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
@@ -162,8 +162,8 @@ led-7 {
function-enumerator = <8>;
};
-#if LED8
led-8 {
+#if LED8
/*
* USER_LED0
* DSW15-8: OFF, DSW15-9: OFF, DSW15-10: ON
@@ -172,11 +172,13 @@ led-8 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DEBUG;
function-enumerator = <0>;
- };
+#else
+ status = "disabled";
#endif
+ };
-#if LED9
led-9 {
+#if LED9
/*
* USER_LED1
* DSW15-5: OFF, DSW15-6: ON
@@ -185,8 +187,10 @@ led-9 {
color = <LED_COLOR_ID_GREEN>;
function = LED_FUNCTION_DEBUG;
function-enumerator = <1>;
- };
+#else
+ status = "disabled";
#endif
+ };
led-10 {
/*
diff --git a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi
new file mode 100644
index 000000000000..c537b2221fdc
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-du-adv7513.dtsi
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT overlay common parts for the RZ/{T2H/N2H} EVKs with ADV7513
+ * transmitter connected to DU enabled.
+ *
+ * Copyright (C) 2026 Renesas Electronics Corp.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/pinctrl/renesas,r9a09g077-pinctrl.h>
+
+#define ADV7513_PARENT_I2C i2c1
+#include "rz-smarc-du-adv7513.dtsi"
+
+&pinctrl {
+ du_pins: du-pins {
+ pinmux = <RZT2H_PORT_PINMUX(9, 4, 0x28)>, /* LCDC_CLK */
+ <RZT2H_PORT_PINMUX(9, 5, 0x28)>, /* LCDC_HSYNC */
+ <RZT2H_PORT_PINMUX(9, 6, 0x28)>, /* LCDC_VSYNC */
+ <RZT2H_PORT_PINMUX(9, 7, 0x28)>, /* LCDC_DE */
+ <RZT2H_PORT_PINMUX(10, 0, 0x28)>, /* LCDC_DATR0 */
+ <RZT2H_PORT_PINMUX(10, 1, 0x28)>, /* LCDC_DATR1 */
+ <RZT2H_PORT_PINMUX(10, 2, 0x28)>, /* LCDC_DATR2 */
+ <RZT2H_PORT_PINMUX(10, 3, 0x28)>, /* LCDC_DATR3 */
+ <RZT2H_PORT_PINMUX(10, 4, 0x28)>, /* LCDC_DATR4 */
+ <RZT2H_PORT_PINMUX(10, 5, 0x28)>, /* LCDC_DATR5 */
+ <RZT2H_PORT_PINMUX(10, 6, 0x28)>, /* LCDC_DATR6 */
+ <RZT2H_PORT_PINMUX(10, 7, 0x28)>, /* LCDC_DATR7 */
+ <RZT2H_PORT_PINMUX(11, 0, 0x28)>, /* LCDC_DATG0 */
+ <RZT2H_PORT_PINMUX(14, 1, 0x28)>, /* LCDC_DATG1 */
+ <RZT2H_PORT_PINMUX(14, 2, 0x28)>, /* LCDC_DATG2 */
+ <RZT2H_PORT_PINMUX(14, 3, 0x28)>, /* LCDC_DATG3 */
+ <RZT2H_PORT_PINMUX(14, 4, 0x28)>, /* LCDC_DATG4 */
+ <RZT2H_PORT_PINMUX(14, 5, 0x28)>, /* LCDC_DATG5 */
+ <RZT2H_PORT_PINMUX(14, 6, 0x28)>, /* LCDC_DATG6 */
+ <RZT2H_PORT_PINMUX(17, 6, 0x28)>, /* LCDC_DATG7 */
+ <RZT2H_PORT_PINMUX(17, 7, 0x28)>, /* LCDC_DATB0 */
+ <RZT2H_PORT_PINMUX(18, 0, 0x28)>, /* LCDC_DATB1 */
+ <RZT2H_PORT_PINMUX(18, 1, 0x28)>, /* LCDC_DATB2 */
+ <RZT2H_PORT_PINMUX(18, 2, 0x28)>, /* LCDC_DATB3 */
+ <RZT2H_PORT_PINMUX(18, 3, 0x28)>, /* LCDC_DATB4 */
+ <RZT2H_PORT_PINMUX(18, 4, 0x28)>, /* LCDC_DATB5 */
+ <RZT2H_PORT_PINMUX(18, 5, 0x28)>, /* LCDC_DATB6 */
+ <RZT2H_PORT_PINMUX(18, 6, 0x28)>; /* LCDC_DATB7 */
+ drive-strength-microamp = <11800>;
+ slew-rate = <0>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: dts: renesas: r9a06g032-rzn1d400-eb: Enable SPI-FRAM
From: Geert Uytterhoeven @ 2026-06-15 11:55 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree
In-Reply-To: <aixTJEh-A4WeL4fJ@ninjato>
Hi Wolfram,
On Fri, 12 Jun 2026 at 20:42, Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
> > > +&spi1 {
> > > + pinctrl-0 = <&pins_spi1>;
> > > + pinctrl-names = "default";
> >
> > Please document that this depends on SW2-4 being OFF.
>
> Hmmm, this is a bit weird. SW2-4 does only do the routing to the SPI5
> (target) controller connector. SPI1 is totally independent of that. I
> can read out the FRAM with 2-4 being ON. Dunno how well that behaves in
> parallel with RMII2 ;) Shall I still do the comment?
You are right.
Once again I've been bitten by the confusing naming in RZ/N1 DB/EB
schematics. So no comment is needed.
>
> > > + cs-gpios = <&gpio2a 31 GPIO_ACTIVE_LOW>;
> >
> > It doesn't work with hardware chip-select?
>
> I couldn't get it to work and I know other people also use cs-gpios on
> their custom boards.
OK.
> > > + fram: fram@0 {
> > > + compatible = "cypress,fm25", "atmel,at25";
> > > + reg = <0>;
> > > + spi-max-frequency = <12500000>;
> >
> > The actual FRAM part seems to support 40 MHz, but that may
> > be limited by the board wiring.
>
> So, what do we do? In my tests, 40MHz did not work. Up to 30MHz it seems
> to work. However, all of the BSP DTS snippets say RZ/N1 can only do up
> to 12.5MHz. I don't have an errata documenting this nor could I find
> another source. I would still rather play safe here. I could add a
> comment, though.
In that case it is fine as-is.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 5/5] arm64: dts: renesas: Add LCDC overlays for RZ/T2H and RZ/N2H EVKs with ADV7513
From: sashiko-bot @ 2026-06-15 12:02 UTC (permalink / raw)
To: Prabhakar; +Cc: devicetree, robh, wsa+renesas, conor+dt
In-Reply-To: <20260615115455.1412098-6-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Mismatch between commit message and implementation regarding LED9.
- [Low] Typo in the overlay header comment swapping I2C1 SDA and SCL pin mappings.
--
commit ab4b9f4219de83b53cbe289e906c4c7c0bf82541
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
arm64: dts: renesas: Add LCDC overlays for RZ/T2H and RZ/N2H EVKs with ADV7513
Add DT overlay support enabling the DU/LCDC pipeline on the RZ/T2H and RZ/N2H
evaluation kits.
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
> new file mode 100644
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-evk-cn20-lcdc.dtso
> @@ -0,0 +1,50 @@
[ ... ]
> +/*
> + * RZ/N2H LCDC configuration:
> + * ----------------------------------------------------------
> + * Function Pin SW Setting
> + * ----------------------------------------------------------
> + * LCDC_DATG0 P11_0, DSW12[3]: ON, DSW12[4]: OFF
> + * LCDC_DATG3 P14_3, DSW18[5]: OFF, DSW18[6]: ON
> + * LCDC_DATG6 P14_6, DSW15[8]: ON, DSW15[9]: OFF, DSW15[10]: OFF
> + * LCDC_DATB2 P18_1, DSW18[9]: OFF, DSW18[10]: ON
> + * I2C_SDA1 P03_3, DSW7[1]: ON, DSW7[2]: OFF
> + * I2C_SCL1 P03_4, DSW7[3]: ON, DSW7[4]: OFF
> + * ------------------------------------------------
> + */
[Severity: Low]
This isn't a bug, but is there a typo in the I2C1 pin mappings documented
here? The base hardware pinmux assigns SCL to P03_3 and SDA to P03_4, which
suggests these comments have SDA and SCL swapped.
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
> --- a/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087m44-rzn2h-evk.dts
[ ... ]
> -#if LED9
> led-9 {
> +#if LED9
> /*
> * USER_LED1
> * DSW15-5: OFF, DSW15-6: ON
> @@ -185,8 +187,10 @@ led-9 {
> color = <LED_COLOR_ID_GREEN>;
> function = LED_FUNCTION_DEBUG;
> function-enumerator = <1>;
> - };
> +#else
> + status = "disabled";
> #endif
> + };
[Severity: Medium]
Is this base DTS conditional for led-9 actually utilized by the overlay?
The commit message states that moving this conditional allows the LCDC
overlay to reference and disable LED9 when its pin is reassigned to display
functions. However, the overlay (r9a09g087m44-evk-cn20-lcdc.dtso) does not
reference or disable led-9. Additionally, the display functions do not
reassign LED9's pin (P14_7) since LCDC_DATG7 uses P17_6.
Does the commit message need updating to match the implementation, or should
led-9 be disabled in the overlay?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=5
^ permalink raw reply
* [PATCH v6 0/3] Add initial Milk-V Duo S board support
From: Joshua Milas @ 2026-06-15 12:03 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, pjw, chen.wang, inochiama, palmer, aou,
alex, liujingqi, alexander.sverdlin, rabenda.cn, hanguidong02
Cc: josh.milas, linux-kernel, devicetree, linux-riscv, sophgo,
michael.opdenacker
This adds an initial device tree for the Milk-V Duo S board
with support for reading from the SD card and network over
Ethernet. This is continued work from Michael Opdenacker's
v6 series [1] on the ARM64 and RISCV side. It has been tested
with ARM64 and RISCV64 to boot from an SD card, have networking
from ethernet, enumerate the wifi chip, have bluetooth, and can
read a I2C slave device over i2c4.
---
v6
- Patches 1,3 from v5 were applied
- Rebased to latest sophgo/for-next
- Added mmc1, mmc2, serial4 aliases
- Removed spi3 alias and node as it was conflicting with sdhci1/wifi
- Added wifi_pwrseq node for wifi chip
- Added pinctrl configs for enabled devices
- Reordered &sdhci0 properties
- Updated &sdhci1 node properties for wifi chip
- Added uart4 for bluetooth
- Changed memory from 256 MB to 512 MB on riscv side
v5: https://lore.kernel.org/sophgo/20260403111516.379795-1-josh.milas@gmail.com/
- Fixes spaces at beginning of line in &usb node of DTS
v4: https://lore.kernel.org/sophgo/20260328173450.219664-2-josh.milas@gmail.com/
- Rebased to latest sophogo/for-next
- Added usb node to arm64 and riscv DTS
- Removed sg200x link in commit messages
- Added missing change to v3 and removed link from v2
v3: https://lore.kernel.org/sophgo/20251029001052.36774-1-josh.milas@gmail.com/
- Added sg2000 interrupt controller and timer to documentation
- Added sg2000.dtsi for RISCV and moved DTS over to use it
- remove devices from DTS's to match what is available in the
default pinmux config. spi0-2, i2c0-3, uart1-4
- Added i2c4 and spi3 aliases
- Removed milkv,duo-s from sophgo,cv1812h in documentation
v2: https://lore.kernel.org/sophgo/20251011014811.28521-1-josh.milas@gmail.com/
- Made new entry in docs to avoid DTC error
- "Milk-V DuoS" -> "Milk-V Duo S"
- Sorting of aliases
- Added uart*, emmc, mdio, gmac0, i2c*, spi*, dmac, saradc
to device tree matching what is available on the pinout
- Removal of 'no-mmc' and 'no-sdio' for sdhci0 as it works without
- Added riscv device tree
v1: https://lore.kernel.org/sophgo/20250927173619.89768-1-josh.milas@gmail.com/
Link: https://lore.kernel.org/linux-riscv/20240421055710.143617-1-michael.opdenacker@bootlin.com/ [1]
Joshua Milas (3):
arm64: dts: sophgo: add initial Milk-V Duo S board support
riscv64: dts: sophgo: add SG2000 dtsi
riscv64: dts: sophgo: add initial Milk-V Duo S board support
arch/arm64/boot/dts/sophgo/Makefile | 1 +
.../boot/dts/sophgo/sg2000-milkv-duo-s.dts | 245 ++++++++++++++++++
arch/riscv/boot/dts/sophgo/Makefile | 1 +
.../boot/dts/sophgo/sg2000-milkv-duo-s.dts | 245 ++++++++++++++++++
arch/riscv/boot/dts/sophgo/sg2000.dtsi | 53 ++++
5 files changed, 545 insertions(+)
create mode 100644 arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts
create mode 100644 arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts
create mode 100644 arch/riscv/boot/dts/sophgo/sg2000.dtsi
base-commit: f7337210bede62fc7c6230ef58013dddf7e0a921
--
2.54.0
^ permalink raw reply
* [PATCH v6 1/3] arm64: dts: sophgo: add initial Milk-V Duo S board support
From: Joshua Milas @ 2026-06-15 12:03 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, pjw, chen.wang, inochiama, palmer, aou,
alex, liujingqi, alexander.sverdlin, rabenda.cn, hanguidong02
Cc: josh.milas, linux-kernel, devicetree, linux-riscv, sophgo,
michael.opdenacker
In-Reply-To: <20260615120324.1527881-1-josh.milas@gmail.com>
Adds initial arm64 support for the Milk-V Duo S board
[1] making it possible to boot Linux to the command line.
Link: https://milkv.io/duo-s [1]
Signed-off-by: Joshua Milas <josh.milas@gmail.com>
---
arch/arm64/boot/dts/sophgo/Makefile | 1 +
.../boot/dts/sophgo/sg2000-milkv-duo-s.dts | 245 ++++++++++++++++++
2 files changed, 246 insertions(+)
create mode 100644 arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts
diff --git a/arch/arm64/boot/dts/sophgo/Makefile b/arch/arm64/boot/dts/sophgo/Makefile
index 94f52cd7d994..68aace728223 100644
--- a/arch/arm64/boot/dts/sophgo/Makefile
+++ b/arch/arm64/boot/dts/sophgo/Makefile
@@ -1,2 +1,3 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_SOPHGO) += sg2000-milkv-duo-module-01-evb.dtb
+dtb-$(CONFIG_ARCH_SOPHGO) += sg2000-milkv-duo-s.dtb
diff --git a/arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts b/arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts
new file mode 100644
index 000000000000..f56bfddeacc4
--- /dev/null
+++ b/arch/arm64/boot/dts/sophgo/sg2000-milkv-duo-s.dts
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/pinctrl/pinctrl-sg2000.h>
+#include "sg2000.dtsi"
+
+/ {
+ model = "Milk-V Duo S";
+ compatible = "milkv,duo-s", "sophgo,sg2000";
+
+ aliases {
+ i2c4 = &i2c4;
+ mmc0 = &sdhci0;
+ mmc1 = &emmc;
+ mmc2 = &sdhci1;
+ serial0 = &uart0;
+ serial4 = &uart4;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&porta 15 GPIO_ACTIVE_LOW>;
+ power-off-delay-us = <50000>;
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+&osc {
+ clock-frequency = <25000000>;
+};
+
+&pinctrl {
+ emmc_cfg: emmc-cfg {
+ emmc-rstn-pins {
+ pinmux = <PINMUX(PIN_EMMC_RSTN, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ emmc-clk-pins {
+ pinmux = <PINMUX(PIN_EMMC_CLK, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ emmc-cmd-pins {
+ pinmux = <PINMUX(PIN_EMMC_CMD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ emmc-data-pins {
+ pinmux = <PINMUX(PIN_EMMC_DAT0, 0)>,
+ <PINMUX(PIN_EMMC_DAT1, 0)>,
+ <PINMUX(PIN_EMMC_DAT2, 0)>,
+ <PINMUX(PIN_EMMC_DAT3, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+ };
+
+ i2c4_cfg: i2c4-cfg {
+ i2c4-pins {
+ pinmux = <PINMUX(PIN_VIVO_D1, 7)>,
+ <PINMUX(PIN_VIVO_D0, 7)>;
+ bias-pull-up;
+ drive-strength-microamp = <4000>;
+ power-source = <1800>;
+ };
+ };
+
+ sdhci0_cfg: sdhci0-cfg {
+ sdhci0-cd-pins {
+ pinmux = <PINMUX(PIN_SD0_CD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ sdhci0-clk-pins {
+ pinmux = <PINMUX(PIN_SD0_CLK, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <16100>;
+ power-source = <3300>;
+ };
+
+ sdhci0-cmd-pins {
+ pinmux = <PINMUX(PIN_SD0_CMD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ sdhci0-data-pins {
+ pinmux = <PINMUX(PIN_SD0_D0, 0)>,
+ <PINMUX(PIN_SD0_D1, 0)>,
+ <PINMUX(PIN_SD0_D2, 0)>,
+ <PINMUX(PIN_SD0_D3, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+
+ sdhci1_cfg: sdhci1-cfg {
+ sdhci1-clk-pins {
+ pinmux = <PINMUX(PIN_MIPI_TXM4, 1)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ sdhci1-cmd-pins {
+ pinmux = <PINMUX(PIN_MIPI_TXP4, 1)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ sdhci1-data-pins {
+ pinmux = <PINMUX(PIN_MIPI_TXM3, 1)>,
+ <PINMUX(PIN_MIPI_TXP3, 1)>,
+ <PINMUX(PIN_MIPI_TXM2, 7)>,
+ <PINMUX(PIN_MIPI_TXP2, 7)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+ };
+
+ uart0_cfg: uart0-cfg {
+ uart0-pins {
+ pinmux = <PINMUX(PIN_UART0_TX, 0)>,
+ <PINMUX(PIN_UART0_RX, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+
+ uart4_cfg: uart4-cfg {
+ uart4-data-pins {
+ pinmux = <PINMUX(PIN_UART2_TX, 5)>,
+ <PINMUX(PIN_UART2_RX, 5)>;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ uart4-control-pins {
+ pinmux = <PINMUX(PIN_UART2_CTS, 5)>,
+ <PINMUX(PIN_UART2_RTS, 5)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+};
+
+&dmac {
+ status = "okay";
+};
+
+&emmc {
+ bus-width = <4>;
+ no-1-8-v;
+ cap-mmc-hw-reset;
+ no-sd;
+ no-sdio;
+ non-removable;
+ pinctrl-0 = <&emmc_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&gmac0 {
+ status = "okay";
+};
+
+&i2c4 {
+ pinctrl-0 = <&i2c4_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&mdio {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+};
+
+&sdhci0 {
+ bus-width = <4>;
+ disable-wp;
+ no-1-8-v;
+ pinctrl-0 = <&sdhci0_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&sdhci1 {
+ bus-width = <4>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ no-mmc;
+ no-sd;
+ non-removable;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ pinctrl-0 = <&sdhci1_cfg>;
+ pinctrl-names = "default";
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-0 = <&uart0_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-0 = <&uart4_cfg>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&usb {
+ dr_mode = "host";
+ status = "okay";
+};
+
--
2.54.0
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: backlight: ti,lp8864: Add backlight class properties
From: A. Sverdlin @ 2026-06-15 12:03 UTC (permalink / raw)
To: linux-leds
Cc: Alexander Sverdlin, Lee Jones, Daniel Thompson, Jingoo Han,
Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Helge Deller, Andrew Davis, dri-devel, devicetree, linux-kernel,
linux-fbdev
In-Reply-To: <20260615120353.3409035-1-alexander.sverdlin@siemens.com>
From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Extend the TI LP8864/LP8866 device-tree binding to support backlight
class properties alongside the existing LED class child node.
This is a preparatory change for converting the LP8864 driver from a
pure LED class driver to additionally register a backlight class device,
motivated by a use case on a hot-pluggable segment of an I2C bus. The
generic led-backlight driver (led_bl.c) is a platform driver and thus
inherently non-hotpluggable, which makes it unsuitable for hardware
topologies where the backlight controller resides on a hot-pluggable I2C
bus segment. By making the LP8864 driver itself register a backlight
class device, it becomes a native I2C driver that properly supports
hot-plug/unplug events.
The binding is updated to:
- Reference backlight common.yaml at the top level, making
default-brightness and max-brightness valid optional properties
- Make the "led" child node optional rather than required, since the
backlight class device is now the primary interface
- Use unevaluatedProperties instead of additionalProperties to properly
allow properties inherited from the referenced common schema
The LED child node is preserved for backward compatibility with existing
device-trees. No in-tree device-trees reference this binding, so this
change has no impact on existing mainline users.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
.../bindings/leds/backlight/ti,lp8864.yaml | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml
index d44232d462bde..11d7e3840c6fb 100644
--- a/Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/leds/backlight/ti,lp8864.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments - LP8864/LP8866 4/6-Channel LED Driver family
+title: Texas Instruments - LP8864/LP8866 4/6-Channel LED Backlight Driver family
maintainers:
- Andrew Davis <afd@ti.com>
@@ -21,6 +21,9 @@ description: |
https://www.ti.com/product/LP8866-Q1
https://www.ti.com/product/LP8866S-Q1
+allOf:
+ - $ref: common.yaml#
+
properties:
compatible:
const: ti,lp8864
@@ -36,9 +39,15 @@ properties:
vled-supply:
description: LED supply
+ default-brightness:
+ maximum: 65535
+
+ max-brightness:
+ maximum: 65535
+
led:
type: object
- $ref: common.yaml#
+ $ref: /schemas/leds/common.yaml#
properties:
function: true
color: true
@@ -50,9 +59,8 @@ properties:
required:
- compatible
- reg
- - led
-additionalProperties: false
+unevaluatedProperties: false
examples:
- |
--
2.54.0
^ permalink raw reply related
* [PATCH 0/3] Convert LP8864 LED driver to backlight class
From: A. Sverdlin @ 2026-06-15 12:03 UTC (permalink / raw)
To: linux-leds
Cc: Alexander Sverdlin, Lee Jones, Daniel Thompson, Jingoo Han,
Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Helge Deller, Andrew Davis, dri-devel, devicetree, linux-kernel,
linux-fbdev
From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
This series converts the TI LP8864/LP8866 driver from a pure LED class
driver to a backlight class driver, while preserving backward-compatible
LED class device registration.
The motivation is a use case on a hot-pluggable segment of an I2C bus.
The generic led-backlight driver (drivers/video/backlight/led_bl.c) is
a platform driver and thus inherently non-hotpluggable -- it cannot react
to dynamic appearance/disappearance of the underlying I2C device. By
making the LP8864 driver directly register a backlight class device, it
becomes a self-contained I2C driver that properly supports hot-plug/unplug
events without depending on a separate platform device for backlight
functionality.
The LED class device registration is retained for backward compatibility:
if the "led" child node is present in the device-tree, an LED class device
is registered in addition to the backlight device.
No in-tree device-trees reference this driver, so there is no mainline
impact. Out-of-tree users who previously relied on the LP8864 as a backend
for the generic led-backlight platform driver will notice a backlight class
device appearing directly.
Alexander Sverdlin (3):
dt-bindings: backlight: ti,lp8864: Add backlight class properties
leds: lp8864: Rename struct lp8864_led and local variables
backlight: lp8864: Convert from LED to backlight class driver
.../bindings/leds/backlight/ti,lp8864.yaml | 16 +-
MAINTAINERS | 2 +-
drivers/leds/Kconfig | 12 --
drivers/leds/Makefile | 1 -
drivers/video/backlight/Kconfig | 15 ++
drivers/video/backlight/Makefile | 1 +
.../backlight/lp8864_bl.c} | 169 ++++++++++++------
7 files changed, 147 insertions(+), 69 deletions(-)
rename drivers/{leds/leds-lp8864.c => video/backlight/lp8864_bl.c} (55%)
--
2.54.0
^ permalink raw reply
* [PATCH v6 2/3] riscv64: dts: sophgo: add SG2000 dtsi
From: Joshua Milas @ 2026-06-15 12:03 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, pjw, chen.wang, inochiama, palmer, aou,
alex, liujingqi, alexander.sverdlin, rabenda.cn, hanguidong02
Cc: josh.milas, linux-kernel, devicetree, linux-riscv, sophgo,
michael.opdenacker
In-Reply-To: <20260615120324.1527881-1-josh.milas@gmail.com>
Adds sg2000.dtsi on the RISCV side.
Signed-off-by: Joshua Milas <josh.milas@gmail.com>
Tested-by: Gui-Dong Han <hanguidong02@gmail.com>
Reviewed-by: Gui-Dong Han <hanguidong02@gmail.com>
---
arch/riscv/boot/dts/sophgo/sg2000.dtsi | 53 ++++++++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 arch/riscv/boot/dts/sophgo/sg2000.dtsi
diff --git a/arch/riscv/boot/dts/sophgo/sg2000.dtsi b/arch/riscv/boot/dts/sophgo/sg2000.dtsi
new file mode 100644
index 000000000000..38462769574f
--- /dev/null
+++ b/arch/riscv/boot/dts/sophgo/sg2000.dtsi
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+#define SOC_PERIPHERAL_IRQ(nr) ((nr) + 16)
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pinctrl/pinctrl-sg2000.h>
+#include "cv180x-cpus.dtsi"
+#include "cv180x.dtsi"
+#include "cv181x.dtsi"
+
+/ {
+ compatible = "sophgo,sg2000";
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>;
+ };
+
+ soc {
+ interrupt-parent = <&plic>;
+ dma-noncoherent;
+
+ pinctrl: pinctrl@3001000 {
+ compatible = "sophgo,sg2000-pinctrl";
+ reg = <0x03001000 0x1000>,
+ <0x05027000 0x1000>;
+ reg-names = "sys", "rtc";
+ };
+
+ clk: clock-controller@3002000 {
+ compatible = "sophgo,sg2000-clk";
+ reg = <0x03002000 0x1000>;
+ clocks = <&osc>;
+ #clock-cells = <1>;
+ };
+
+ plic: interrupt-controller@70000000 {
+ compatible = "sophgo,sg2000-plic", "thead,c900-plic";
+ reg = <0x70000000 0x4000000>;
+ interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ riscv,ndev = <101>;
+ };
+
+ clint: timer@74000000 {
+ compatible = "sophgo,sg2000-clint", "thead,c900-clint";
+ reg = <0x74000000 0x10000>;
+ interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>;
+ };
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH 2/3] leds: lp8864: Rename struct lp8864_led and local variables
From: A. Sverdlin @ 2026-06-15 12:03 UTC (permalink / raw)
To: linux-leds
Cc: Alexander Sverdlin, Lee Jones, Daniel Thompson, Jingoo Han,
Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Helge Deller, Andrew Davis, dri-devel, devicetree, linux-kernel,
linux-fbdev
In-Reply-To: <20260615120353.3409035-1-alexander.sverdlin@siemens.com>
From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Rename struct lp8864_led to struct lp8864 and the local variable 'led'
to 'priv' throughout the driver. The LED functionality will become
optional in a subsequent patch that adds backlight class support, so
having the driver's private data structure and variables named after
LED-specifics is misleading.
No functional change.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
drivers/leds/leds-lp8864.c | 70 +++++++++++++++++++-------------------
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/leds/leds-lp8864.c b/drivers/leds/leds-lp8864.c
index 3afd729d2f8a6..d05211b970c94 100644
--- a/drivers/leds/leds-lp8864.c
+++ b/drivers/leds/leds-lp8864.c
@@ -69,32 +69,32 @@ static const char *const lp8864_led_status_msg[] = {
};
/**
- * struct lp8864_led
+ * struct lp8864
* @client: Pointer to the I2C client
* @led_dev: led class device pointer
* @regmap: Devices register map
* @led_status_mask: Helps to report LED fault only once
*/
-struct lp8864_led {
+struct lp8864 {
struct i2c_client *client;
struct led_classdev led_dev;
struct regmap *regmap;
u16 led_status_mask;
};
-static int lp8864_fault_check(struct lp8864_led *led)
+static int lp8864_fault_check(struct lp8864 *priv)
{
int ret, i;
unsigned int val;
- ret = regmap_read(led->regmap, LP8864_SUPPLY_STATUS, &val);
+ ret = regmap_read(priv->regmap, LP8864_SUPPLY_STATUS, &val);
if (ret)
goto err;
/* Odd bits are status bits, even bits are clear bits */
for (i = 0; i < ARRAY_SIZE(lp8864_supply_status_msg); i++)
if (val & BIT(i * 2 + 1))
- dev_warn(&led->client->dev, "%s\n", lp8864_supply_status_msg[i]);
+ dev_warn(&priv->client->dev, "%s\n", lp8864_supply_status_msg[i]);
/*
* Clear bits have an index preceding the corresponding Status bits;
@@ -102,25 +102,25 @@ static int lp8864_fault_check(struct lp8864_led *led)
* Status bit.
*/
if (val)
- ret = regmap_write(led->regmap, LP8864_SUPPLY_STATUS, val >> 1 | val);
+ ret = regmap_write(priv->regmap, LP8864_SUPPLY_STATUS, val >> 1 | val);
if (ret)
goto err;
- ret = regmap_read(led->regmap, LP8864_BOOST_STATUS, &val);
+ ret = regmap_read(priv->regmap, LP8864_BOOST_STATUS, &val);
if (ret)
goto err;
/* Odd bits are status bits, even bits are clear bits */
for (i = 0; i < ARRAY_SIZE(lp8864_boost_status_msg); i++)
if (val & BIT(i * 2 + 1))
- dev_warn(&led->client->dev, "%s\n", lp8864_boost_status_msg[i]);
+ dev_warn(&priv->client->dev, "%s\n", lp8864_boost_status_msg[i]);
if (val)
- ret = regmap_write(led->regmap, LP8864_BOOST_STATUS, val >> 1 | val);
+ ret = regmap_write(priv->regmap, LP8864_BOOST_STATUS, val >> 1 | val);
if (ret)
goto err;
- ret = regmap_read(led->regmap, LP8864_LED_STATUS, &val);
+ ret = regmap_read(priv->regmap, LP8864_LED_STATUS, &val);
if (ret)
goto err;
@@ -128,31 +128,31 @@ static int lp8864_fault_check(struct lp8864_led *led)
* Clear already reported faults that maintain their value until device
* power-down
*/
- val &= ~led->led_status_mask;
+ val &= ~priv->led_status_mask;
for (i = 0; i < ARRAY_SIZE(lp8864_led_status_msg); i++)
if (lp8864_led_status_msg[i] && val & BIT(i))
- dev_warn(&led->client->dev, "%s\n", lp8864_led_status_msg[i]);
+ dev_warn(&priv->client->dev, "%s\n", lp8864_led_status_msg[i]);
/*
* Mark those which maintain their value until device power-down as
* "already reported"
*/
- led->led_status_mask |= val & ~LP8864_LED_STATUS_WR_MASK;
+ priv->led_status_mask |= val & ~LP8864_LED_STATUS_WR_MASK;
/*
* Only bits 14, 12, 10 have to be cleared here, but others are RO,
* we don't care what we write to them.
*/
if (val & LP8864_LED_STATUS_WR_MASK)
- ret = regmap_write(led->regmap, LP8864_LED_STATUS, val >> 1 | val);
+ ret = regmap_write(priv->regmap, LP8864_LED_STATUS, val >> 1 | val);
if (ret)
goto err;
return 0;
err:
- dev_err(&led->client->dev, "Failed to read/clear faults (%pe)\n", ERR_PTR(ret));
+ dev_err(&priv->client->dev, "Failed to read/clear faults (%pe)\n", ERR_PTR(ret));
return ret;
}
@@ -160,31 +160,31 @@ static int lp8864_fault_check(struct lp8864_led *led)
static int lp8864_brightness_set(struct led_classdev *led_cdev,
enum led_brightness brt_val)
{
- struct lp8864_led *led = container_of(led_cdev, struct lp8864_led, led_dev);
+ struct lp8864 *priv = container_of(led_cdev, struct lp8864, led_dev);
/* Scale 0..LED_FULL into 16-bit HW brightness */
unsigned int val = brt_val * 0xffff / LED_FULL;
int ret;
- ret = lp8864_fault_check(led);
+ ret = lp8864_fault_check(priv);
if (ret)
return ret;
- ret = regmap_write(led->regmap, LP8864_BRT_CONTROL, val);
+ ret = regmap_write(priv->regmap, LP8864_BRT_CONTROL, val);
if (ret)
- dev_err(&led->client->dev, "Failed to write brightness value\n");
+ dev_err(&priv->client->dev, "Failed to write brightness value\n");
return ret;
}
static enum led_brightness lp8864_brightness_get(struct led_classdev *led_cdev)
{
- struct lp8864_led *led = container_of(led_cdev, struct lp8864_led, led_dev);
+ struct lp8864 *priv = container_of(led_cdev, struct lp8864, led_dev);
unsigned int val;
int ret;
- ret = regmap_read(led->regmap, LP8864_BRT_CONTROL, &val);
+ ret = regmap_read(priv->regmap, LP8864_BRT_CONTROL, &val);
if (ret) {
- dev_err(&led->client->dev, "Failed to read brightness value\n");
+ dev_err(&priv->client->dev, "Failed to read brightness value\n");
return ret;
}
@@ -208,14 +208,14 @@ static void lp8864_disable_gpio(void *data)
static int lp8864_probe(struct i2c_client *client)
{
int ret;
- struct lp8864_led *led;
+ struct lp8864 *priv;
struct device_node *np = dev_of_node(&client->dev);
struct device_node *child_node;
struct led_init_data init_data = {};
struct gpio_desc *enable_gpio;
- led = devm_kzalloc(&client->dev, sizeof(*led), GFP_KERNEL);
- if (!led)
+ priv = devm_kzalloc(&client->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
return -ENOMEM;
child_node = of_get_next_available_child(np, NULL);
@@ -237,24 +237,24 @@ static int lp8864_probe(struct i2c_client *client)
if (ret)
return ret;
- led->client = client;
- led->led_dev.brightness_set_blocking = lp8864_brightness_set;
- led->led_dev.brightness_get = lp8864_brightness_get;
+ priv->client = client;
+ priv->led_dev.brightness_set_blocking = lp8864_brightness_set;
+ priv->led_dev.brightness_get = lp8864_brightness_get;
- led->regmap = devm_regmap_init_i2c(client, &lp8864_regmap_config);
- if (IS_ERR(led->regmap))
- return dev_err_probe(&client->dev, PTR_ERR(led->regmap),
+ priv->regmap = devm_regmap_init_i2c(client, &lp8864_regmap_config);
+ if (IS_ERR(priv->regmap))
+ return dev_err_probe(&client->dev, PTR_ERR(priv->regmap),
"Failed to allocate regmap\n");
/* Control brightness by DISPLAY_BRT register */
- ret = regmap_update_bits(led->regmap, LP8864_USER_CONFIG1, LP8864_BRT_MODE_MASK,
+ ret = regmap_update_bits(priv->regmap, LP8864_USER_CONFIG1, LP8864_BRT_MODE_MASK,
LP8864_BRT_MODE_REG);
if (ret) {
- dev_err(&led->client->dev, "Failed to set brightness control mode\n");
+ dev_err(&priv->client->dev, "Failed to set brightness control mode\n");
return ret;
}
- ret = lp8864_fault_check(led);
+ ret = lp8864_fault_check(priv);
if (ret)
return ret;
@@ -262,7 +262,7 @@ static int lp8864_probe(struct i2c_client *client)
init_data.devicename = "lp8864";
init_data.default_label = ":display_cluster";
- ret = devm_led_classdev_register_ext(&client->dev, &led->led_dev, &init_data);
+ ret = devm_led_classdev_register_ext(&client->dev, &priv->led_dev, &init_data);
if (ret)
dev_err(&client->dev, "Failed to register LED device (%pe)\n", ERR_PTR(ret));
--
2.54.0
^ permalink raw reply related
* [PATCH 3/3] backlight: lp8864: Convert from LED to backlight class driver
From: A. Sverdlin @ 2026-06-15 12:03 UTC (permalink / raw)
To: linux-leds
Cc: Alexander Sverdlin, Lee Jones, Daniel Thompson, Jingoo Han,
Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Helge Deller, Andrew Davis, dri-devel, devicetree, linux-kernel,
linux-fbdev
In-Reply-To: <20260615120353.3409035-1-alexander.sverdlin@siemens.com>
From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Move the TI LP8864/LP8866 driver from drivers/leds/ to
drivers/video/backlight/ and convert it to register a backlight class
device as its primary interface.
The motivation is a use case on a hot-pluggable segment of an I2C bus.
The generic led-backlight driver (drivers/video/backlight/led_bl.c) is a
platform driver and as such inherently non-hotpluggable. It cannot react
to dynamic appearance/disappearance of the underlying I2C device. By
making the LP8864 driver directly register a backlight class device, it
becomes a native I2C driver that properly supports hot-plug/unplug
events on the I2C bus.
Key changes:
- Register a backlight class device using
devm_backlight_device_register() as the primary interface
- Implement backlight_ops (update_status, get_brightness)
- The hardware 16-bit brightness register (0x0000-0xFFFF) is directly
exposed as the backlight brightness range
- Support DT properties "default-brightness" and "max-brightness"
from the backlight common binding
- Include BL_CORE_SUSPENDRESUME for proper power management integration
- Preserve backward-compatible LED class device registration: if the
"led" child node is present in the DT, an LED class device is also
registered (same as the original driver behavior)
- Preserve the CONFIG_LEDS_LP8864 Kconfig symbol name so that existing
kernel configurations are not affected
- Update MAINTAINERS to reflect the new file location
This will be noticeable for applications which already used the LP8864
as a backend for the generic led-backlight platform driver, as a
backlight device will now appear directly in addition to the LED class
device. However, no in-tree device-trees reference this driver, so
there is no mainline impact.
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
---
MAINTAINERS | 2 +-
drivers/leds/Kconfig | 12 --
drivers/leds/Makefile | 1 -
drivers/video/backlight/Kconfig | 15 +++
drivers/video/backlight/Makefile | 1 +
.../backlight/lp8864_bl.c} | 111 ++++++++++++++----
6 files changed, 106 insertions(+), 36 deletions(-)
rename drivers/{leds/leds-lp8864.c => video/backlight/lp8864_bl.c} (70%)
diff --git a/MAINTAINERS b/MAINTAINERS
index dbd4552236e64..250e8b1ed4bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -26481,7 +26481,7 @@ M: Alexander Sverdlin <alexander.sverdlin@siemens.com>
L: linux-leds@vger.kernel.org
S: Maintained
F: Documentation/devicetree/bindings/leds/backlight/ti,lp8864.yaml
-F: drivers/leds/leds-lp8864.c
+F: drivers/video/backlight/lp8864_bl.c
TEXAS INSTRUMENTS' SYSTEM CONTROL INTERFACE (TISCI) PROTOCOL DRIVER
M: Nishanth Menon <nm@ti.com>
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index f4a0a3c8c8705..990cb9ef18c1e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -529,18 +529,6 @@ config LEDS_LP8860
on the LP8860 4 channel LED driver using the I2C communication
bus.
-config LEDS_LP8864
- tristate "LED support for the TI LP8864/LP8866 4/6 channel LED drivers"
- depends on LEDS_CLASS && I2C && OF
- select REGMAP_I2C
- help
- If you say yes here you get support for the TI LP8864-Q1,
- LP8864S-Q1, LP8866-Q1, LP8866S-Q1 4/6 channel LED backlight
- drivers with I2C interface.
-
- To compile this driver as a module, choose M here: the
- module will be called leds-lp8864.
-
config LEDS_CLEVO_MAIL
tristate "Mail LED on Clevo notebook"
depends on LEDS_CLASS && BROKEN
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8fdb45d5b4393..5e624a48aa2a5 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -59,7 +59,6 @@ obj-$(CONFIG_LEDS_LP55XX_COMMON) += leds-lp55xx-common.o
obj-$(CONFIG_LEDS_LP8501) += leds-lp8501.o
obj-$(CONFIG_LEDS_LP8788) += leds-lp8788.o
obj-$(CONFIG_LEDS_LP8860) += leds-lp8860.o
-obj-$(CONFIG_LEDS_LP8864) += leds-lp8864.o
obj-$(CONFIG_LEDS_LT3593) += leds-lt3593.o
obj-$(CONFIG_LEDS_MAX5970) += leds-max5970.o
obj-$(CONFIG_LEDS_MAX77650) += leds-max77650.o
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index a7a3fbaf7c29e..82ecd7e46236d 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -514,6 +514,21 @@ config BACKLIGHT_LED
If you have a LCD backlight adjustable by LED class driver, say Y
to enable this driver.
+config LEDS_LP8864
+ tristate "Backlight driver for TI LP8864/LP8866 4/6 channel LED drivers"
+ depends on I2C && OF
+ select REGMAP_I2C
+ select NEW_LEDS
+ select LEDS_CLASS
+ help
+ If you say yes here you get support for the TI LP8864-Q1,
+ LP8864S-Q1, LP8866-Q1, LP8866S-Q1 4/6 channel LED backlight
+ drivers with I2C interface. The driver registers a backlight
+ class device and optionally an LED class device.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lp8864_bl.
+
endif # BACKLIGHT_CLASS_DEVICE
endmenu
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 794820a98ed49..6a7287d01d81b 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -62,3 +62,4 @@ obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
obj-$(CONFIG_BACKLIGHT_ARCXCNN) += arcxcnn_bl.o
obj-$(CONFIG_BACKLIGHT_RAVE_SP) += rave-sp-backlight.o
obj-$(CONFIG_BACKLIGHT_LED) += led_bl.o
+obj-$(CONFIG_LEDS_LP8864) += lp8864_bl.o
diff --git a/drivers/leds/leds-lp8864.c b/drivers/video/backlight/lp8864_bl.c
similarity index 70%
rename from drivers/leds/leds-lp8864.c
rename to drivers/video/backlight/lp8864_bl.c
index d05211b970c94..67b28f7daedd2 100644
--- a/drivers/leds/leds-lp8864.c
+++ b/drivers/video/backlight/lp8864_bl.c
@@ -1,12 +1,13 @@
// SPDX-License-Identifier: GPL-2.0-only
/*
- * TI LP8864/LP8866 4/6 Channel LED Driver
+ * TI LP8864/LP8866 4/6 Channel LED Backlight Driver
*
- * Copyright (C) 2024 Siemens AG
+ * Copyright (C) 2024-2026 Siemens AG
*
* Based on LP8860 driver by Dan Murphy <dmurphy@ti.com>
*/
+#include <linux/backlight.h>
#include <linux/gpio/consumer.h>
#include <linux/i2c.h>
#include <linux/init.h>
@@ -27,6 +28,8 @@
#define LP8864_LED_STATUS 0x12
#define LP8864_LED_STATUS_WR_MASK GENMASK(14, 9) /* Writeable bits in the LED_STATUS reg */
+#define LP8864_MAX_BRIGHTNESS 0xffff
+
/* Textual meaning for status bits, starting from bit 1 */
static const char *const lp8864_supply_status_msg[] = {
"Vin under-voltage fault",
@@ -71,13 +74,15 @@ static const char *const lp8864_led_status_msg[] = {
/**
* struct lp8864
* @client: Pointer to the I2C client
- * @led_dev: led class device pointer
+ * @led_dev: optional led class device pointer
+ * @bl: backlight device pointer
* @regmap: Devices register map
* @led_status_mask: Helps to report LED fault only once
*/
struct lp8864 {
struct i2c_client *client;
- struct led_classdev led_dev;
+ struct led_classdev *led_dev;
+ struct backlight_device *bl;
struct regmap *regmap;
u16 led_status_mask;
};
@@ -157,28 +162,59 @@ static int lp8864_fault_check(struct lp8864 *priv)
return ret;
}
-static int lp8864_brightness_set(struct led_classdev *led_cdev,
- enum led_brightness brt_val)
+static int lp8864_brightness_set(struct lp8864 *priv, unsigned int brightness)
{
- struct lp8864 *priv = container_of(led_cdev, struct lp8864, led_dev);
- /* Scale 0..LED_FULL into 16-bit HW brightness */
- unsigned int val = brt_val * 0xffff / LED_FULL;
int ret;
ret = lp8864_fault_check(priv);
if (ret)
return ret;
- ret = regmap_write(priv->regmap, LP8864_BRT_CONTROL, val);
+ ret = regmap_write(priv->regmap, LP8864_BRT_CONTROL, brightness);
if (ret)
dev_err(&priv->client->dev, "Failed to write brightness value\n");
return ret;
}
-static enum led_brightness lp8864_brightness_get(struct led_classdev *led_cdev)
+static int lp8864_backlight_update_status(struct backlight_device *bl)
+{
+ return lp8864_brightness_set(bl_get_data(bl), backlight_get_brightness(bl));
+}
+
+static int lp8864_backlight_get_brightness(struct backlight_device *bl)
{
- struct lp8864 *priv = container_of(led_cdev, struct lp8864, led_dev);
+ struct lp8864 *priv = bl_get_data(bl);
+ unsigned int val;
+ int ret;
+
+ ret = regmap_read(priv->regmap, LP8864_BRT_CONTROL, &val);
+ if (ret) {
+ dev_err(&priv->client->dev, "Failed to read brightness value\n");
+ return ret;
+ }
+
+ return val;
+}
+
+static const struct backlight_ops lp8864_backlight_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = lp8864_backlight_update_status,
+ .get_brightness = lp8864_backlight_get_brightness,
+};
+
+static int lp8864_led_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brt_val)
+{
+ struct lp8864 *priv = dev_get_drvdata(led_cdev->dev->parent);
+
+ /* Scale 0..LED_FULL into 16-bit HW brightness */
+ return lp8864_brightness_set(priv, brt_val * 0xffff / LED_FULL);
+}
+
+static enum led_brightness lp8864_led_brightness_get(struct led_classdev *led_cdev)
+{
+ struct lp8864 *priv = dev_get_drvdata(led_cdev->dev->parent);
unsigned int val;
int ret;
@@ -212,18 +248,15 @@ static int lp8864_probe(struct i2c_client *client)
struct device_node *np = dev_of_node(&client->dev);
struct device_node *child_node;
struct led_init_data init_data = {};
+ struct backlight_device *bl;
+ struct backlight_properties props;
struct gpio_desc *enable_gpio;
+ u32 val;
priv = devm_kzalloc(&client->dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
- child_node = of_get_next_available_child(np, NULL);
- if (!child_node) {
- dev_err(&client->dev, "No LED function defined\n");
- return -EINVAL;
- }
-
ret = devm_regulator_get_enable_optional(&client->dev, "vled");
if (ret && ret != -ENODEV)
return dev_err_probe(&client->dev, ret, "Failed to enable vled regulator\n");
@@ -238,8 +271,7 @@ static int lp8864_probe(struct i2c_client *client)
return ret;
priv->client = client;
- priv->led_dev.brightness_set_blocking = lp8864_brightness_set;
- priv->led_dev.brightness_get = lp8864_brightness_get;
+ i2c_set_clientdata(client, priv);
priv->regmap = devm_regmap_init_i2c(client, &lp8864_regmap_config);
if (IS_ERR(priv->regmap))
@@ -258,11 +290,46 @@ static int lp8864_probe(struct i2c_client *client)
if (ret)
return ret;
+ /* Register backlight class device */
+ memset(&props, 0, sizeof(props));
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = LP8864_MAX_BRIGHTNESS;
+ props.brightness = LP8864_MAX_BRIGHTNESS;
+ props.scale = BACKLIGHT_SCALE_LINEAR;
+
+ if (!device_property_read_u32(&client->dev, "max-brightness", &val))
+ props.max_brightness = val;
+
+ if (!device_property_read_u32(&client->dev, "default-brightness", &val))
+ props.brightness = val;
+
+ bl = devm_backlight_device_register(&client->dev, "lp8864-backlight",
+ &client->dev, priv,
+ &lp8864_backlight_ops, &props);
+ if (IS_ERR(bl))
+ return dev_err_probe(&client->dev, PTR_ERR(bl),
+ "Failed to register backlight device\n");
+
+ priv->bl = bl;
+ backlight_update_status(bl);
+
+ /* Register LED class device if "led" child node is present */
+ child_node = of_get_available_child_by_name(np, "led");
+ if (!child_node)
+ return 0;
+
+ priv->led_dev = devm_kzalloc(&client->dev, sizeof(*priv->led_dev), GFP_KERNEL);
+ if (!priv->led_dev)
+ return -ENOMEM;
+
+ priv->led_dev->brightness_set_blocking = lp8864_led_brightness_set;
+ priv->led_dev->brightness_get = lp8864_led_brightness_get;
+
init_data.fwnode = of_fwnode_handle(child_node);
init_data.devicename = "lp8864";
init_data.default_label = ":display_cluster";
- ret = devm_led_classdev_register_ext(&client->dev, &priv->led_dev, &init_data);
+ ret = devm_led_classdev_register_ext(&client->dev, priv->led_dev, &init_data);
if (ret)
dev_err(&client->dev, "Failed to register LED device (%pe)\n", ERR_PTR(ret));
@@ -291,6 +358,6 @@ static struct i2c_driver lp8864_driver = {
};
module_i2c_driver(lp8864_driver);
-MODULE_DESCRIPTION("Texas Instruments LP8864/LP8866 LED driver");
+MODULE_DESCRIPTION("Texas Instruments LP8864/LP8866 LED Backlight driver");
MODULE_AUTHOR("Alexander Sverdlin <alexander.sverdlin@siemens.com>");
MODULE_LICENSE("GPL");
--
2.54.0
^ permalink raw reply related
* [PATCH v6 3/3] riscv64: dts: sophgo: add initial Milk-V Duo S board support
From: Joshua Milas @ 2026-06-15 12:03 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, pjw, chen.wang, inochiama, palmer, aou,
alex, liujingqi, alexander.sverdlin, rabenda.cn, hanguidong02
Cc: josh.milas, linux-kernel, devicetree, linux-riscv, sophgo,
michael.opdenacker
In-Reply-To: <20260615120324.1527881-1-josh.milas@gmail.com>
This adds initial riscv support for the Milk-V Duo S board
[1] making it possible to boot Linux to the command line.
Link: https://milkv.io/duo-s [1]
Signed-off-by: Joshua Milas <josh.milas@gmail.com>
---
arch/riscv/boot/dts/sophgo/Makefile | 1 +
.../boot/dts/sophgo/sg2000-milkv-duo-s.dts | 245 ++++++++++++++++++
2 files changed, 246 insertions(+)
create mode 100644 arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts
diff --git a/arch/riscv/boot/dts/sophgo/Makefile b/arch/riscv/boot/dts/sophgo/Makefile
index 6f65526d4193..58cc6b70d8de 100644
--- a/arch/riscv/boot/dts/sophgo/Makefile
+++ b/arch/riscv/boot/dts/sophgo/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_SOPHGO) += cv1800b-milkv-duo.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += cv1812h-huashan-pi.dtb
+dtb-$(CONFIG_ARCH_SOPHGO) += sg2000-milkv-duo-s.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2002-licheerv-nano-b.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2042-milkv-pioneer.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2042-evb-v1.dtb
diff --git a/arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts
new file mode 100644
index 000000000000..f56bfddeacc4
--- /dev/null
+++ b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts
@@ -0,0 +1,245 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/pinctrl/pinctrl-sg2000.h>
+#include "sg2000.dtsi"
+
+/ {
+ model = "Milk-V Duo S";
+ compatible = "milkv,duo-s", "sophgo,sg2000";
+
+ aliases {
+ i2c4 = &i2c4;
+ mmc0 = &sdhci0;
+ mmc1 = &emmc;
+ mmc2 = &sdhci1;
+ serial0 = &uart0;
+ serial4 = &uart4;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&porta 15 GPIO_ACTIVE_LOW>;
+ power-off-delay-us = <50000>;
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+&osc {
+ clock-frequency = <25000000>;
+};
+
+&pinctrl {
+ emmc_cfg: emmc-cfg {
+ emmc-rstn-pins {
+ pinmux = <PINMUX(PIN_EMMC_RSTN, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ emmc-clk-pins {
+ pinmux = <PINMUX(PIN_EMMC_CLK, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ emmc-cmd-pins {
+ pinmux = <PINMUX(PIN_EMMC_CMD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ emmc-data-pins {
+ pinmux = <PINMUX(PIN_EMMC_DAT0, 0)>,
+ <PINMUX(PIN_EMMC_DAT1, 0)>,
+ <PINMUX(PIN_EMMC_DAT2, 0)>,
+ <PINMUX(PIN_EMMC_DAT3, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+ };
+
+ i2c4_cfg: i2c4-cfg {
+ i2c4-pins {
+ pinmux = <PINMUX(PIN_VIVO_D1, 7)>,
+ <PINMUX(PIN_VIVO_D0, 7)>;
+ bias-pull-up;
+ drive-strength-microamp = <4000>;
+ power-source = <1800>;
+ };
+ };
+
+ sdhci0_cfg: sdhci0-cfg {
+ sdhci0-cd-pins {
+ pinmux = <PINMUX(PIN_SD0_CD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ sdhci0-clk-pins {
+ pinmux = <PINMUX(PIN_SD0_CLK, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <16100>;
+ power-source = <3300>;
+ };
+
+ sdhci0-cmd-pins {
+ pinmux = <PINMUX(PIN_SD0_CMD, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ sdhci0-data-pins {
+ pinmux = <PINMUX(PIN_SD0_D0, 0)>,
+ <PINMUX(PIN_SD0_D1, 0)>,
+ <PINMUX(PIN_SD0_D2, 0)>,
+ <PINMUX(PIN_SD0_D3, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+
+ sdhci1_cfg: sdhci1-cfg {
+ sdhci1-clk-pins {
+ pinmux = <PINMUX(PIN_MIPI_TXM4, 1)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ sdhci1-cmd-pins {
+ pinmux = <PINMUX(PIN_MIPI_TXP4, 1)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+
+ sdhci1-data-pins {
+ pinmux = <PINMUX(PIN_MIPI_TXM3, 1)>,
+ <PINMUX(PIN_MIPI_TXP3, 1)>,
+ <PINMUX(PIN_MIPI_TXM2, 7)>,
+ <PINMUX(PIN_MIPI_TXP2, 7)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <1800>;
+ };
+ };
+
+ uart0_cfg: uart0-cfg {
+ uart0-pins {
+ pinmux = <PINMUX(PIN_UART0_TX, 0)>,
+ <PINMUX(PIN_UART0_RX, 0)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+
+ uart4_cfg: uart4-cfg {
+ uart4-data-pins {
+ pinmux = <PINMUX(PIN_UART2_TX, 5)>,
+ <PINMUX(PIN_UART2_RX, 5)>;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+
+ uart4-control-pins {
+ pinmux = <PINMUX(PIN_UART2_CTS, 5)>,
+ <PINMUX(PIN_UART2_RTS, 5)>;
+ bias-pull-up;
+ drive-strength-microamp = <10800>;
+ power-source = <3300>;
+ };
+ };
+};
+
+&dmac {
+ status = "okay";
+};
+
+&emmc {
+ bus-width = <4>;
+ no-1-8-v;
+ cap-mmc-hw-reset;
+ no-sd;
+ no-sdio;
+ non-removable;
+ pinctrl-0 = <&emmc_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&gmac0 {
+ status = "okay";
+};
+
+&i2c4 {
+ pinctrl-0 = <&i2c4_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&mdio {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+};
+
+&sdhci0 {
+ bus-width = <4>;
+ disable-wp;
+ no-1-8-v;
+ pinctrl-0 = <&sdhci0_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&sdhci1 {
+ bus-width = <4>;
+ cap-sdio-irq;
+ cap-sd-highspeed;
+ keep-power-in-suspend;
+ no-mmc;
+ no-sd;
+ non-removable;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ pinctrl-0 = <&sdhci1_cfg>;
+ pinctrl-names = "default";
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-0 = <&uart0_cfg>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-0 = <&uart4_cfg>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&usb {
+ dr_mode = "host";
+ status = "okay";
+};
+
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: sashiko-bot @ 2026-06-15 12:06 UTC (permalink / raw)
To: Udaya Kiran Challa; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260615115311.515404-1-challauday369@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `cs-gpios` property was omitted from the `required` list during the DT schema conversion.
--
commit 418415dcdca7e4f555bde32db4703c62c250ee78
Author: Udaya Kiran Challa <challauday369@gmail.com>
spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
Convert Microchip PIC32 SPI controller devicetree binding
from legacy text format to DT schema.
> diff --git a/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
> new file mode 100644
> index 0000000000000..a0a182cdccbd9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-spi.yaml
[ ... ]
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - interrupt-names
> + - clocks
> + - clock-names
> +
> +unevaluatedProperties: false
[Severity: Medium]
Did this conversion intentionally drop cs-gpios from the required properties
list?
Looking at the legacy text binding being removed, cs-gpios was explicitly
listed under the required properties section. Since the PIC32 SPI driver
returns -EINVAL if the GPIO chip select is missing during setup, omitting
it here might allow incomplete device trees to pass schema validation but
fail later at probe time.
Could we add cs-gpios back to the required list to maintain parity with the
old binding constraints?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615115311.515404-1-challauday369@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/3] powercap: qcom: Add SPEL powercap driver
From: Daniel Lezcano @ 2026-06-15 12:07 UTC (permalink / raw)
To: Konrad Dybcio, Manaf Meethalavalappu Pallikunhi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm, Gaurav Kohli
In-Reply-To: <fe5ff2e6-4c54-4b21-be5c-0f06bf0e6696@oss.qualcomm.com>
Hi Konrad,
Le 09/06/2026 à 15:31, Konrad Dybcio a écrit :
> On 6/9/26 3:23 PM, Manaf Meethalavalappu Pallikunhi wrote:
>> Hi Konrad,
>>
>>
>> On 5/21/2026 4:46 PM, Konrad Dybcio wrote:
>>> On 5/19/26 12:49 PM, Manaf Meethalavalappu Pallikunhi wrote:
>>>> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
>>>> based power monitoring and limiting capabilities for various power
>>>> domains including System, SoC, CPU clusters, GPU, and various other
>>>> subsystems.
>>>>
>>>> The driver integrates with the Linux powercap framework, exposing SPEL
>>>> capabilities through powercap sysfs interfaces.
>>>>
>>>> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
>>>> ---
>
> [...]
>
>>>> +static void spel_remove(struct platform_device *pdev)
>>>> +{
>>>> + struct spel_system *sp = platform_get_drvdata(pdev);
>>>> + int i;
>>>> +
>>>> + if (!sp)
>>>> + return;
>>>> +
>>>> + /* Unregister in reverse order: children first, then SOC, then SYS */
>>>> + for (i = SPEL_DOMAIN_MAX - 1; i >= 0; i--)
>>>> + powercap_unregister_zone(sp->control_type, &sp->domains[i].power_zone);
>>>
>>> Could you try adding a devm_ variant of these register functions?
>>
>> Powercap framework doesn't support any devm_* API, you meant add this support in framework in this series ?
>
> Yes, this should be fairly trivial - look at e.g.
>
> drivers/regulator/devres.c : devm_of_regulator_get
Given how structured is the powercap framework, I'm not sure it is so
trivial. May be it is, but I doubt.
I don't think it is worth to investigate adding devm_ variant now (for a
few lines saved) and diverge from the objective of this series
-- Daniel
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: qcom: kodiak: Sort pinctrl subnodes by pins
From: Konrad Dybcio @ 2026-06-15 12:09 UTC (permalink / raw)
To: Luca Weiss, Vladimir Zapolskiy, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <DJ747VLQEHIN.Q3SS1FFC9I3L@fairphone.com>
On 6/12/26 3:46 PM, Luca Weiss wrote:
> On Fri Jun 12, 2026 at 2:59 PM CEST, Vladimir Zapolskiy wrote:
>> As documented in the "Devicetree Sources (DTS) Coding Style" document,
>> pinctrl subnodes should be sorted by the pins property. Do this once for
>> kodiak.dtsi so that future additions can be added at the right places.
>>
>> No functional change intended, verified with dtx_diff.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> arch/arm64/boot/dts/qcom/kodiak.dtsi | 1382 +++++++++++++++++-----------------
>> 1 file changed, 691 insertions(+), 691 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>> index fa540d8c2615..62daef726d32 100644
>> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
>
> <snip>
>
>> + qup_uart12_cts: qup-uart12-cts-state {
>> + pins = "gpio48";
>> + function = "qup14";
>> + };
>> +
>> + qup_uart12_rts: qup-uart12-rts-state {
>> + pins = "gpio49";
>> + function = "qup14";
>> + };
>> +
>> + qup_uart12_tx: qup-uart12-tx-state {
>> + pins = "gpio50";
>> + function = "qup14";
>> + };
>>
>> I understand and support the intention to keep this change non-functional,
>> but this pad "gpio50" is for qup16 also, right?
>
> According to my QCM6490 data sheet, GPIO_50 has these functions:
> * UART for qup14 (OK)
> * SPI for qup14 (OK)
> * SPI for qup16 (no pinctrl)
"no pinctrl" meaning "not defined in the upstream dt as of today"?
>
>>
>> Similarly pads "gpio54"/"gpio55" for qup14 function, "gpio62"/"gpio63"
>> for qup16 function, I find all of these are missing on the original list.
>
> GPIO_54:
> * UART qup15 (OK)
> * SPI qup15 (OK)
> * SPI qup14 (no pinctrl)
>
> GPIO_55:
> * UART qup15 (OK)
> * SPI qup15 (OK)
> * SPI qup14 (no pinctrl)
>
> GPIO_62:
> * UART qup17 (OK)
> * SPI qup17 (OK)
> * SPI qup16 (no pinctrl)
>
> GPIO_63:
> * UART qup16 (?)
> * SPI qup16 (lane 3) (?)
> * SPI qup16 (lane 5) (?)
>
> But the GPIO_63 looks weird, is the data sheet wrong?! Where would
> UART_RX of QUP1 SE7 go? Maybe it should be UART qup17 and SPI qup17 and
> then SPI qup16 ??
GPIO63:
QUP1_SE6 SPI_CS2
QUP1_SE7 UART_RX/SPI_CS0
Konrad
^ permalink raw reply
* Re: [PATCH v2 4/5] arm64: dts: renesas: r9a09g087: Add DU node
From: sashiko-bot @ 2026-06-15 12:10 UTC (permalink / raw)
To: Prabhakar; +Cc: robh, conor+dt, devicetree, wsa+renesas
In-Reply-To: <20260615115455.1412098-5-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing the required `resets` property in the `du` node, leading to a driver probe failure.
- [Medium] Missing a fallback compatible string for the `du` node.
- [Low] The device tree compilation fails due to the use of an undeclared macro `R9A09G087_LCDC_CLKD`.
--
commit 60fe4c07204f3af15bb869a850f5f3764a505646
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
arm64: dts: renesas: r9a09g087: Add DU node
This commit adds the Display Unit node to the r9a09g087 device tree.
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> index cb2eabe3242e0..21250caf31493 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> @@ -1272,6 +1272,30 @@ sdhi1_vqmmc: vqmmc-regulator {
> };
> };
>
> + du: display@920c0000 {
> + compatible = "renesas,r9a09g087-du", "renesas,r9a09g077-du";
[Severity: Medium]
Does this node need a recognized fallback compatible string?
Neither "renesas,r9a09g087-du" nor "renesas,r9a09g077-du" are present in
the display driver's match table, and no existing fallback string
is provided. Without a recognized fallback, the device will fail to match
with the driver entirely, preventing the display unit from probing.
> + reg = <0 0x920c0000 0 0x10000>;
> + interrupts = <GIC_SPI 781 IRQ_TYPE_LEVEL_HIGH>;
[Severity: High]
Does this node need a resets property?
The renesas,rzg2l-du.yaml schema strictly requires the resets property.
Furthermore, the display driver in drivers/gpu/drm/renesas/rz-du/
unconditionally attempts to acquire the reset control via:
devm_reset_control_get_shared(rcdu->dev, NULL)
Because the resets property is absent, this returns -ENOENT, which aborts
the driver probe and renders the display subsystem unusable.
> + clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> + <&cpg CPG_MOD 1204>,
> + <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
[Severity: Low]
Is the R9A09G087_LCDC_CLKD macro defined in the dt-bindings headers?
This macro is used as a clock specifier but does not appear to be defined
in the repository, causing the preprocessor to output the macro name as a
literal string. This results in a syntax error from dtc which expects a
phandle or integer.
> + clock-names = "aclk", "pclk", "vclk";
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=4
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: kodiak: Add camera mclk pinctrl definitions
From: Konrad Dybcio @ 2026-06-15 12:10 UTC (permalink / raw)
To: Luca Weiss, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260612-kodiak-cam-mclk-v1-2-fd294ff003a2@fairphone.com>
On 6/12/26 12:55 PM, Luca Weiss wrote:
> On different boards the cameras are connected to different pins with the
> cam_mclk function. Add the definitions so that mclk0-5 are covered.
>
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Could you tack on a patch qcs6490-rb3gen2-vision-mezzanine.dtso
to use this common define?
Konrad
^ permalink raw reply
* Re: [PATCH v3 1/2] cpufreq: spacemit: Add K1 cpufreq driver
From: Shuwei Wu @ 2026-06-15 12:11 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Yixun Lan, linux-pm, linux-kernel, linux-riscv, spacemit,
devicetree
In-Reply-To: <wjwkykv555gkeqxabsqcdfn4lomcopawsv7bgm4bydc5likhjs@p3ca3p7wbri5>
Hi Viresh,
Thanks for pointing it out.
On Mon Jun 15, 2026 at 2:34 PM CST, Viresh Kumar wrote:
> Hi Shuwei,
>
> On 15-06-26, 14:12, Shuwei Wu wrote:
>> The clusters have separate clocks, but they share the same voltage supply.[1]
>> So two independent policies would be unsafe: one policy could lower the shared
>> voltage while the other cluster is still running at a higher frequency.
>
> No, both will vote for the regulator contraints using CPU device and the
> regulator core will make sure it doesn't break any of them. This is what all
> frameworks do, regulator, clk, etc.
>
>> This means they can't use different policies.
>
> This is incorrect.
>
>> From a hardware perspective, the eight cores of the K1 are homogeneous,
>> so using the same policy for them is relatively reasonable.
>
> Right, but this is inefficient. One cluster can be idle, or in low freq mode
> while other can be in higher. They MUST be two policies.
Yes, you're right. Two policies are not inherently unsafe.
The regulator framework handles multi-consumer voting correctly.
The actual problem was using single value opp-microvolt. With one cluster at
a low frequency holding a precise [950000, 950000] on the shared rail, and the
other requesting [1050000, 1050000] for 1.6 GHz, the regulator finds no
intersection:
~ # echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 544.744195] buck1: Restricting voltage, 1050000-950000uV
[ 544.757073] cpu cpu0: _set_opp_voltage: failed to set
voltage (1050000 1050000 1050000 mV): -22
[ 544.771304] cpufreq: __target_index: Failed to change
cpu frequency: -22
The fix is to use the <target min max> triplet for the lower OPPs so the
regulator always has a valid intersection:
- cpu_opp_table: opp-table-cpu {
+ cluster0_opp_table: opp-table-cluster0 {
compatible = "operating-points-v2";
opp-shared;
opp-614400000 {
- opp-microvolt = <950000>;
+ opp-microvolt = <950000 950000 1050000>;
};
opp-819000000 {
- opp-microvolt = <950000>;
+ opp-microvolt = <950000 950000 1050000>;
};
...
opp-1600000000 {
opp-microvolt = <1050000>;
};
};
+ cluster1_opp_table: opp-table-cluster1 {
+ // same OPP entries and voltage ranges as above
+ };
- &cpu_0 { operating-points-v2 = <&cpu_opp_table>; };
+ &cpu_0 { operating-points-v2 = <&cluster0_opp_table>; };
...
- &cpu_7 { operating-points-v2 = <&cpu_opp_table>; };
+ &cpu_3 { operating-points-v2 = <&cluster0_opp_table>; };
+ &cpu_4 { operating-points-v2 = <&cluster1_opp_table>; };
...
+ &cpu_7 { operating-points-v2 = <&cluster1_opp_table>; };
This way the low frequency cluster accepts up to 1.05 V on the rail.
That is safe: high voltage at low frequency costs power but does not cause
instability.
With two cpufreq-dt policies (one per cluster) and these ranges, neither cluster
blocks the other. Tested on BPI-F3 and OrangePi Rv2 boards, works as expected.
Does this look good to you, or would you prefer a different approach?
>
>> I used a K1-specific driver because cpufreq-dt only manages one CPU clock
>> through the CPU device used for the OPP transition.
>> On K1, the policy needs to control two independent cluster clocks and one shared
>> regulator, so the driver has to update the second cluster clock explicitly and
>> keep the ordering safe: raise voltage before raising either cluster, and lower
>> both cluster clocks before lowering the shared voltage.
>>
>> [1] https://lore.kernel.org/spacemit/aeaXszeaE62rM6BJ@aurel32.net/
--
Best regards,
Shuwei Wu
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: remoteproc: qcom,pas: add thermal mitigation properties
From: Gaurav Kohli @ 2026-06-15 12:12 UTC (permalink / raw)
To: Daniel Lezcano, Krzysztof Kozlowski
Cc: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Amit Kucheria,
Manivannan Sadhasivam, Konrad Dybcio, Kees Cook,
Gustavo A. R. Silva, cros-qcom-dts-watchers, linux-arm-msm,
linux-remoteproc, devicetree, linux-kernel, linux-pm,
linux-hardening, Manaf Meethalavalappu Pallikunhi
In-Reply-To: <3cbcaf8c-357e-42d2-91c1-9d1a32c55ed0@oss.qualcomm.com>
On 6/15/2026 4:04 PM, Daniel Lezcano wrote:
> On 6/13/26 13:05, Gaurav Kohli wrote:
>>
>>
>> On 6/13/2026 1:11 PM, Krzysztof Kozlowski wrote:
>>> On 12/06/2026 15:52, Gaurav Kohli wrote:
>>>>
>>>>
>>>> On 6/11/2026 5:53 PM, Krzysztof Kozlowski wrote:
>>>>> On 11/06/2026 13:12, Gaurav Kohli wrote:
>>>>>>> Why? And where is this generic property defined? You cannot just
>>>>>>> sprinkle generic properties in random bindings.
>>>>>>>
>>>>>>
>>>>>> Ack, will add why part.
>>>>>> These names are matched with the thermal mitigation device
>>>>>> identifiers
>>>>>> populated by remote firmware over QMI and define mitigation
>>>>>> devices are
>>>>>> exposed as cooling devices.
>>>>>
>>>>> No, -names correspond to values passed via DT, not some remote
>>>>> firmware.
>>>>> The remote firmware should give you interface which is explicit and
>>>>> does
>>>>> not need such properties.
>>>>
>>>> thanks Krzysztof for review, We need tmd-names because of following
>>>> reasons:
>>>>
>>>> Following Daniel's series [1], the thermal framework supports
>>>> mapping multiple cooling devices per remoteproc/device via indexed
>>>> cooling-cells.
>>>>
>>>> 1) The thermal framework's cooling-maps reference
>>>> cooling devices by index (for #cooling-cells = <3>). Without tmd-names,
>>>> there's no way to know which index corresponds to which TMD, as
>>>> firmware
>>>> may return tmd-names in any order.
>>>>
>>>> below are the changes post new thermal mapping changes:
>>>> DT: tmd-names = "cdsp_sw", "xyz";
>>>> Firmware: ["cdsp_sw", "xyz1", "xyz2",]
>>>> Driver registers: Only "cdsp_sw" (index 0) and "xyz" (index 1)
>>>
>>> names property are not to instruct drivers to register or not to
>>> register something.
>>>
>>> I don't understand the problem and explanation in the binding is
>>> basically non-existing.
>>>
>>> Remember that all lists and indices ARE FIXED, so driver knows exactly
>>> which index means what.
>>>
>>
>> thanks for review, shall i use driver data, which is basically pas
>> data structure like below:
>>
>> static const struct qcom_pas_data {
>> .crash_reason_smem = 601,
>> .firmware_name = "cdsp.mdt",
>> .tmd_names = (const char *[]){"xyz", NULL},
>> .num_tmds = 1,
>>
>> Is something like above acceptable? and this will also help to filter
>> tmd names as well?
>
>
> How the thermal framework will bind the thermal zone with the TMD ?
> (node pointer, id) ?
>
Hi Daniel,
thanks for review.
With id only, in this case instead of taking tmd names from device tree,
qmi_tmd will take tmd name from pas_data(driver) and register with the
cooling framework with id only. Please let us know if this looks fine.
thanks
Gaurav
^ permalink raw reply
* Re: [PATCH v8 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Can Guo @ 2026-06-15 12:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, bvanassche, beanhuo, peter.wang,
martin.petersen, mani
Cc: linux-scsi, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ram Kumar Dwivedi,
Zhaoming Luo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <8ee6bfe0-71aa-4d3a-a583-f7495a86fc58@kernel.org>
On 6/15/2026 7:26 PM, Krzysztof Kozlowski wrote:
> On 15/06/2026 10:50, Can Guo wrote:
>> UFS v5.0/UFSHCI v5.0 adds HS-G6 support (46.6 Gbps/lane) via UniPro
>> v3.0 and M-PHY v6.0. These specs define TX Equalization for all
>> High-Speed Gears (not only HS-G6) to compensate channel loss and
>> improve signal integrity at high speed.
>>
>> For HS-G6, M-PHY uses PAM4 1b1b line coding. Pre-Coding may also be
>> required depending on channel characteristics.
>>
>> Document vendor-neutral properties in ufs-common.yaml:
>> - txeq-preshoot-g[1-6]
>> - txeq-deemphasis-g[1-6]
>> - tx-precode-enable-g6
>>
>> Values are per-lane Host/Device tuples (2 values for x1, 4 values for
>> x2). PreShoot/DeEmphasis range from 0..7, and Precode is 0/1.
>>
>> These are board-specific signal-integrity tuning values. They depend on
>> channel SI/PHY characterization and validation (host PHY, device PHY,
>> package, and board routing), and are determined by HW/PHY designers.
>>
>> Although UFSHCI v5.0 supports TX Equalization Training via UniPro v3.0,
>> which allows host software to determine optimal TX Equalization at
>> runtime, static board-specific TX Equalization settings in the Device
>> Tree are still necessary because:
>> - TX Equalization Training is not supported for HS-G3 and below
>> - TX Equalization Training is disabled on some platforms
>>
>> Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
>> ---
>> .../devicetree/bindings/ufs/ufs-common.yaml | 55 +++++++++++++++++++
>> 1 file changed, 55 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
>> index ed97f5682509..145a6416e1df 100644
>> --- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
>> +++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
>> @@ -105,6 +105,61 @@ properties:
>> Restricts the UFS controller to rate-a or rate-b for both TX and
>> RX directions.
>>
>> + tx-precode-enable-g6:
>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
>> + oneOf:
>> + - items:
>> + - description: Host_Lane0 precode
>> + - description: Device_Lane0 precode
>> + - items:
>> + - description: Host_Lane0 precode
>> + - description: Device_Lane0 precode
>> + - description: Host_Lane1 precode
>> + - description: Device_Lane1 precode
>> + items:
>> + enum: [0, 1]
>> + description:
>> + Static TX Precode enable values for HS-G6 only.
> My bad here, that was my mistake. I wanted matrix, but gave you array
> syntax. Proper code would be:
>
> tx-precode-enable-g6:
> $ref: /schemas/types.yaml#/definitions/uint32-matrix
> minItems: 1
> items:
> - items:
> - description: Host_Lane0 precode
> enum: [0, 1]
> - description: Device_Lane0 precode
> enum: [0, 1]
> - items:
> - description: Host_Lane1 precode
> enum: [0, 1]
> - description: Device_Lane1 precode
> enum: [0, 1]
> description:
> Static TX Precode enable values for HS-G6 only.
>
>
> I tested it with DTS and seems to work fine. Please use the same for
> other properties, but enum will be 0-7.
Sure, I will correct it and validate the same for the next version.
Thank you for helping me out.
Best Regards,
Can Guo.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH RFC 4/9] net: stmmac: qcom-ethqos: add per-platform NOC clock voting
From: Konrad Dybcio @ 2026-06-15 12:13 UTC (permalink / raw)
To: Mohd Ayaan Anwar, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, Bjorn Andersson, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue, Russell King
Cc: linux-arm-msm, netdev, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260612-shikra_ethernet-v1-4-f0f4a1d19929@oss.qualcomm.com>
On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
> Some SoCs gate the EMAC's path to the System NOC behind dedicated clocks
> that must be enabled before the DMA can reach memory. Add
> ethqos_noc_clk_cfg and the corresponding fields in the driver-data and
> runtime structs so each compatible can declare its own set with per-clock
> rates. The clocks are acquired during probe and enabled/disabled
> alongside the existing link clock in ethqos_clks_config().
Sounds like we should use an OPP table instead, we can't just do
set_rate() on qcom, as that will not propagate the required perf
state to the clock controller's supplier power domain (i.e. VDDCX)
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/5] arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes
From: sashiko-bot @ 2026-06-15 12:14 UTC (permalink / raw)
To: Prabhakar; +Cc: wsa+renesas, devicetree, conor+dt, robh
In-Reply-To: <20260615115455.1412098-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Missing required 'resets' property in VSP and FCP nodes causes DT binding violations and unconditional driver probe failure.
- [High] The device tree references an unregistered module clock `<&cpg CPG_MOD 1204>`.
- [Low] Undefined macro `R9A09G077_LCDC_CLKD` causes a fatal dtc compilation failure.
- [Low] Undocumented compatible strings used without updating the YAML bindings.
--
commit 8127cbbf46c0b360f49e2126e2ac9941c9ebfa22
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
arm64: dts: renesas: r9a09g077: Add VSPD and FCPVD nodes
Add VSPD and FCPVD nodes to RZ/T2H SoC DTSI.
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> index 3761551c96472..29ecd0189ce72 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g077.dtsi
> @@ -1268,6 +1268,28 @@ sdhi1_vqmmc: vqmmc-regulator {
> status = "disabled";
> };
> };
> +
> + fcpvd: fcp@920d0000 {
> + compatible = "renesas,r9a09g077-fcpvd", "renesas,fcpv";
[Severity: Low]
Are these compatible strings documented in the YAML bindings?
It seems renesas,r9a09g077-fcpvd is not added to renesas,fcp.yaml. This could
cause dtbs_check to report unrecognized compatibles. Since it falls back
to generic renesas,fcpv constraints, it might enforce maxItems: 1 for clocks
and trigger further validation errors.
> + reg = <0 0x920d0000 0 0x10000>;
> + clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> + <&cpg CPG_MOD 1204>,
[Severity: High]
Is module clock 1204 registered in the clock driver?
Looking at drivers/clk/renesas/r9a09g077-cpg.c, 1204 doesn't appear to be
defined in the module clock array. This would cause the clock framework's
of_xlate function to return -ENOENT, preventing the PM domain from enabling
the clock and resulting in a fatal probe failure.
> + <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;
[Severity: Low]
Is R9A09G077_LCDC_CLKD defined in the kernel tree?
It appears this macro isn't defined, which would leave the token unchanged by
the C preprocessor and cause a syntax error during device tree compilation.
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
[Severity: High]
Does this node need a resets property?
The device tree bindings for FCP require a resets property. Without it,
device initialization might be incomplete.
> + };
> +
> + vspd: vsp@920e0000 {
> + compatible = "renesas,r9a09g077-vsp2", "renesas,r9a07g044-vsp2";
[Severity: Low]
Is the renesas,r9a09g077-vsp2 compatible string added to the bindings?
Without an update to renesas,vsp1.yaml, dtbs_check will report this as an
unrecognized compatible.
> + reg = <0 0x920e0000 0 0x8000>;
> + interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_CORE R9A09G077_CLK_PCLKAH>,
> + <&cpg CPG_MOD 1204>,
[Severity: High]
Would the unregistered CPG_MOD 1204 clock also cause probe failure for the
VSPD device here?
Similar to the fcpvd node, failing to acquire the clock will abort the probe.
> + <&cpg CPG_CORE R9A09G077_LCDC_CLKD>;
[Severity: Low]
Could this undefined macro break dtc compilation here as well?
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
[Severity: High]
Does the vsp1 driver require a resets property to successfully probe?
Looking at drivers/media/platform/renesas/vsp1/vsp1_drv.c, vsp1_probe() calls
devm_reset_control_get_shared() without the optional flag. Because the resets
property is omitted here, this might return -ENOENT and immediately abort the
probe via dev_err_probe().
> + renesas,fcp = <&fcpvd>;
> + };
> };
>
> stmmac_axi_setup: stmmac-axi-config {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=1
^ permalink raw reply
* Re: [PATCH v6 3/3] riscv64: dts: sophgo: add initial Milk-V Duo S board support
From: sashiko-bot @ 2026-06-15 12:14 UTC (permalink / raw)
To: Joshua Milas; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260615120324.1527881-4-josh.milas@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Contradictory eMMC voltage configuration artificially restricts eMMC speed capabilities
--
commit 9d652e59c7623b46a5dd7a0a5954061467e5aea7
Author: Joshua Milas <josh.milas@gmail.com>
riscv64: dts: sophgo: add initial Milk-V Duo S board support
This adds initial riscv support for the Milk-V Duo S board
making it possible to boot Linux to the command line.
Link: https://milkv.io/duo-s [1]
> diff --git a/arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts
> new file mode 100644
> index 0000000000000..f56bfddeacc40
> --- /dev/null
> +++ b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duo-s.dts
[ ... ]
> +&pinctrl {
> + emmc_cfg: emmc-cfg {
> + emmc-rstn-pins {
> + pinmux = <PINMUX(PIN_EMMC_RSTN, 0)>;
> + bias-pull-up;
> + drive-strength-microamp = <10800>;
> + power-source = <1800>;
> + };
[ ... ]
> +&emmc {
> + bus-width = <4>;
> + no-1-8-v;
[Severity: Medium]
Is this contradictory eMMC voltage configuration intentional?
The pinctrl node emmc_cfg explicitly configures the eMMC pins to
operate at 1.8V (power-source = <1800>), but the &emmc node here
specifies the no-1-8-v property.
Since the hardware pads are physically configured for 1.8V, the interface
actually does support 1.8V signaling. Specifying no-1-8-v here artificially
restricts the eMMC to legacy, slower modes instead of negotiating
faster modes like HS200.
> + cap-mmc-hw-reset;
> + no-sd;
> + no-sdio;
> + non-removable;
> + pinctrl-0 = <&emmc_cfg>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615120324.1527881-1-josh.milas@gmail.com?part=3
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox