* [PATCH v3 06/11] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 7" DSI
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260522161105.277519-13-ivitro@gmail.com>
From: Vitor Soares <vitor.soares@toradex.com>
Add a device tree overlay for the Toradex Capacitive Touch Display 7"
DSI on the Verdin DSI_1 interface. The display features an internal
Texas Instruments SN65DSI83 DSI-to-LVDS bridge driving a Riverdi
RVT70HSLNWCA0 7" WSVGA IPS TFT LCD panel. The touch input is provided
by an Ilitek ILI2132 capacitive touch controller.
Link: https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-7inch-dsi
Link: https://developer.toradex.com/hardware/accessories/add-ons/dsi-display-adapter/
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
Changes in v3:
- Rename touch@ nodes to touchscreen@
arch/arm64/boot/dts/ti/Makefile | 5 +
...m625-verdin-panel-cap-touch-7inch-dsi.dtso | 132 ++++++++++++++++++
2 files changed, 137 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index dc397bc693ac..14898f8ab0e2 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -42,6 +42,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-yavia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-zinnia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-dsi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-lvds.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-7inch-dsi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia-dsi-to-hdmi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia-panel-cap-touch-10inch-dsi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia.dtb
@@ -223,6 +224,9 @@ k3-am625-sk-hdmi-audio-dtbs := k3-am625-sk.dtb k3-am62x-sk-hdmi-audio.dtbo
k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch-dtbs := \
k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
+k3-am625-verdin-wifi-dev-panel-cap-touch-7inch-dsi-dtbs := \
+ k3-am625-verdin-wifi-dev.dtb \
+ k3-am625-verdin-panel-cap-touch-7inch-dsi.dtbo
k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds-dtbs := \
k3-am625-verdin-wifi-mallow.dtb \
k3-am625-verdin-panel-cap-touch-10inch-lvds.dtbo
@@ -328,6 +332,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-sk-csi2-tevi-ov5640.dtb \
k3-am625-sk-hdmi-audio.dtb \
k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch.dtb \
+ k3-am625-verdin-wifi-dev-panel-cap-touch-7inch-dsi.dtb \
k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds.dtb \
k3-am62-lp-sk-hdmi-audio.dtb \
k3-am62-lp-sk-nand.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso
new file mode 100644
index 000000000000..1f44133f9ca6
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Toradex Capacitive Touch Display 7" on Verdin DSI_1.
+ * On Dahlia (X17) and Development Board (X48), DSI_1 is exposed via a
+ * Samtec LSS-130 connector and requires the Toradex DSI Display Adapter
+ * to convert to FFC/FPC connector.
+ *
+ * https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-7inch-dsi
+ * https://www.toradex.com/accessories/capacitive-touch-display-7-inch-dsi
+ * https://developer.toradex.com/hardware/accessories/add-ons/dsi-display-adapter
+ * https://www.toradex.com/accessories/verdin-dsi-display-adapter
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+&{/} {
+ backlight_pwm3: backlight-pwm3 {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 45 63 88 119 158 203 255>;
+ default-brightness-level = <4>;
+ power-supply = <®_3v3>;
+ /* Verdin PWM_3_DSI (SODIMM 19) - PWM_3_DSI_LVDS */
+ pwms = <&epwm1 0 6666667 0>;
+ };
+
+ panel-lvds-bridge {
+ compatible = "riverdi,rvt70hslnwca0", "panel-lvds";
+ backlight = <&backlight_pwm3>;
+ data-mapping = "vesa-24";
+ height-mm = <86>;
+ width-mm = <154>;
+
+ panel-timing {
+ clock-frequency = <51200000>;
+ de-active = <1>;
+ hactive = <1024>;
+ hback-porch = <160 160 160>;
+ hfront-porch = <16 160 216>;
+ hsync-active = <0>;
+ hsync-len = <1 5 140>;
+ pixelclk-active = <1>;
+ vactive = <600>;
+ vback-porch = <23 23 23>;
+ vfront-porch = <1 12 126>;
+ vsync-active = <0>;
+ vsync-len = <1 10 20>;
+ };
+
+ port {
+ panel_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_out>;
+ };
+ };
+ };
+};
+
+&dsi_bridge {
+ status = "okay";
+};
+
+&dsi_bridge_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ dsi_bridge_out: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_in>;
+ };
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+/* Verdin I2C_2_DSI */
+&main_i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2c {
+ compatible = "ti,sn65dsi83";
+ reg = <0x2c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_bkl_en>;
+ /* Verdin GPIO_10_DSI (SODIMM 21) - DSI_1_BKL_EN */
+ enable-gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_bridge_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dsi_lvds_bridge_out: endpoint {
+ remote-endpoint = <&panel_lvds_bridge_in>;
+ };
+ };
+ };
+ };
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2132";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_int>, <&pinctrl_i2s_2_bclk_gpio>;
+ /* Verdin GPIO_9_DSI (SODIMM 17) - TOUCH_INT# */
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <49 IRQ_TYPE_EDGE_RISING>;
+ /* Verdin I2S_2_BCLK (SODIMM 42) - TOUCH_RESET# */
+ reset-gpios = <&main_gpio0 35 GPIO_ACTIVE_LOW>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 05/11] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" DSI
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260522161105.277519-13-ivitro@gmail.com>
From: Vitor Soares <vitor.soares@toradex.com>
Add a device tree overlay for the Toradex Capacitive Touch Display 10.1"
on the Verdin DSI_1 interface. The display features an internal
Texas Instruments SN65DSI83 DSI-to-LVDS bridge driving a Riverdi
RVT101HVLNWC00 10.1" WXGA (1280x800) IPS TFT LCD panel. The touch input
is provided by an Ilitek ILI2132 capacitive touch controller.
The overlay is also combined with the Verdin AM62 Dahlia carrier board
device trees to provide ready-to-use DTBs in both WiFi and non-Wifi SoM
variants.
Link: https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-dsi
Link: https://developer.toradex.com/hardware/accessories/add-ons/dsi-display-adapter/
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
Changes in v3:
- Rename touch@ nodes to touchscreen@
arch/arm64/boot/dts/ti/Makefile | 9 ++
...625-verdin-panel-cap-touch-10inch-dsi.dtso | 132 ++++++++++++++++++
2 files changed, 141 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 867c05b675d1..dc397bc693ac 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -11,10 +11,16 @@
# Boards with AM62x SoC
k3-am625-verdin-nonwifi-dahlia-dsi-to-hdmi-dtbs := k3-am625-verdin-nonwifi-dahlia.dtb \
k3-am625-verdin-dsi-to-hdmi.dtbo
+k3-am625-verdin-nonwifi-dahlia-panel-cap-touch-10inch-dsi-dtbs := \
+ k3-am625-verdin-nonwifi-dahlia.dtb \
+ k3-am625-verdin-panel-cap-touch-10inch-dsi.dtbo
k3-am625-verdin-nonwifi-dev-dsi-to-hdmi-dtbs := k3-am625-verdin-nonwifi-dev.dtb \
k3-am625-verdin-dsi-to-hdmi.dtbo
k3-am625-verdin-wifi-dahlia-dsi-to-hdmi-dtbs := k3-am625-verdin-wifi-dahlia.dtb \
k3-am625-verdin-dsi-to-hdmi.dtbo
+k3-am625-verdin-wifi-dahlia-panel-cap-touch-10inch-dsi-dtbs := \
+ k3-am625-verdin-wifi-dahlia.dtb \
+ k3-am625-verdin-panel-cap-touch-10inch-dsi.dtbo
k3-am625-verdin-wifi-dev-dsi-to-hdmi-dtbs := k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-dsi-to-hdmi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-beagleplay.dtb
@@ -26,6 +32,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-tqma62xx-mba62xx.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-hdmi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia-dsi-to-hdmi.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia-panel-cap-touch-10inch-dsi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dev-dsi-to-hdmi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dev.dtb
@@ -33,8 +40,10 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-ivy.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-mallow.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-yavia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-zinnia.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-dsi.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-lvds.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia-dsi-to-hdmi.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia-panel-cap-touch-10inch-dsi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dev-dsi-to-hdmi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dev.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso
new file mode 100644
index 000000000000..ed66feec9462
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Toradex Capacitive Touch Display 10.1" on Verdin DSI_1.
+ * On Dahlia (X17) and Development Board (X48), DSI_1 is exposed via a
+ * Samtec LSS-130 connector and requires the Toradex DSI Display Adapter
+ * to convert to FFC/FPC connector.
+ *
+ * https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-dsi
+ * https://www.toradex.com/accessories/capacitive-touch-display-10.1-inch-dsi
+ * https://developer.toradex.com/hardware/accessories/add-ons/dsi-display-adapter
+ * https://www.toradex.com/accessories/verdin-dsi-display-adapter
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+&{/} {
+ backlight_pwm3: backlight-pwm3 {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 45 63 88 119 158 203 255>;
+ default-brightness-level = <4>;
+ power-supply = <®_3v3>;
+ /* Verdin PWM_3_DSI (SODIMM 19) - PWM_3_DSI_LVDS */
+ pwms = <&epwm1 0 6666667 0>;
+ };
+
+ panel-lvds-bridge {
+ compatible = "riverdi,rvt101hvlnwc00", "panel-lvds";
+ backlight = <&backlight_pwm3>;
+ data-mapping = "vesa-24";
+ height-mm = <136>;
+ width-mm = <217>;
+
+ panel-timing {
+ clock-frequency = <72400000>;
+ de-active = <1>;
+ hactive = <1280>;
+ hback-porch = <88 88 88>;
+ hfront-porch = <12 72 132>;
+ hsync-active = <0>;
+ hsync-len = <1 5 40>;
+ pixelclk-active = <1>;
+ vactive = <800>;
+ vback-porch = <23 23 23>;
+ vfront-porch = <1 15 49>;
+ vsync-active = <0>;
+ vsync-len = <1 10 20>;
+ };
+
+ port {
+ panel_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_out>;
+ };
+ };
+ };
+};
+
+&dsi_bridge {
+ status = "okay";
+};
+
+&dsi_bridge_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ dsi_bridge_out: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_in>;
+ };
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+/* Verdin I2C_2_DSI */
+&main_i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2c {
+ compatible = "ti,sn65dsi83";
+ reg = <0x2c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_bkl_en>;
+ /* Verdin GPIO_10_DSI (SODIMM 21) - DSI_1_BKL_EN */
+ enable-gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_bridge_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dsi_lvds_bridge_out: endpoint {
+ remote-endpoint = <&panel_lvds_bridge_in>;
+ };
+ };
+ };
+ };
+
+ touchscreen@41 {
+ compatible = "ilitek,ili2132";
+ reg = <0x41>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_int>, <&pinctrl_i2s_2_bclk_gpio>;
+ /* Verdin GPIO_9_DSI (SODIMM 17) - TOUCH_INT# */
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <49 IRQ_TYPE_EDGE_RISING>;
+ /* Verdin I2S_2_BCLK (SODIMM 42) - TOUCH_RESET# */
+ reset-gpios = <&main_gpio0 35 GPIO_ACTIVE_LOW>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 04/11] dt-bindings: display: panel-lvds: Add Riverdi RVT70HSLNWCA0 and RVT101HVLNWC00
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, Conor Dooley
In-Reply-To: <20260522161105.277519-13-ivitro@gmail.com>
From: Vitor Soares <vitor.soares@toradex.com>
The Riverdi RVT70HSLNWCA0 is a 7.0" WSVGA (1024x600) IPS TFT LCD LVDS
panel used in the Riverdi RVT70HSDNWCA0 display module.
The Riverdi RVT101HVLNWC00 is a 10.1" WXGA (1280x800) IPS TFT LCD LVDS
panel used in the Riverdi RVT101HVDNWC00 display module.
Link: https://download.riverdi.com/RVT70HSLNWCA0/DS_RVT70HSLNWCA0_Rev.1.4.pdf
Link: https://download.riverdi.com/RVT101HVLNWC00/DS_RVT101HVLNWC00_Rev.1.4.pdf
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
.../devicetree/bindings/display/panel/panel-lvds.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
index b31c67babaa8..b89f86bc0683 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml
@@ -58,6 +58,10 @@ properties:
- hydis,hv070wx2-1e0
# Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel
- jenson,bl-jt60050-01a
+ # Riverdi RVT101HVLNWC00 10.1" WXGA (1280x800) TFT LCD LVDS panel
+ - riverdi,rvt101hvlnwc00
+ # Riverdi RVT70HSLNWCA0 7.0" WSVGA (1024x600) TFT LCD LVDS panel
+ - riverdi,rvt70hslnwca0
# Samsung LTN070NL01 7.0" WSVGA (1024x600) TFT LCD LVDS panel
- samsung,ltn070nl01
# Samsung LTN101AL03 10.1" WXGA (800x1280) TFT LCD LVDS panel
--
2.54.0
^ permalink raw reply related
* [PATCH v3 03/11] dt-bindings: vendor-prefixes: Add Riverdi
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel, Conor Dooley
In-Reply-To: <20260522161105.277519-13-ivitro@gmail.com>
From: Vitor Soares <vitor.soares@toradex.com>
Add vendor prefix for Riverdi Sp. z o.o, a design and manufacturer
of TFT display solutions.
Link: https://riverdi.com
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..bac056d486e7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1403,6 +1403,8 @@ patternProperties:
description: Embest RIoT
"^riscv,.*":
description: RISC-V Foundation
+ "^riverdi,.*":
+ description: Riverdi Sp. z o.o
"^rockchip,.*":
description: Rockchip Electronics Co., Ltd.
"^rocktech,.*":
--
2.54.0
^ permalink raw reply related
* [PATCH v3 02/11] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260522161105.277519-13-ivitro@gmail.com>
From: Vitor Soares <vitor.soares@toradex.com>
Add a device tree overlay for the Toradex Capacitive Touch Display 10.1"
LVDS connected via Verdin AM62 OLDI on carrier boards exposing LVDS
interface (e.g., Mallow). The panel is a LogicTechno LT170410-2WHC 10.1"
WXGA IPS LCD and the touch input is provided by an Atmel MaxTouch
capacitive touch controller.
Link: https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
Changes in v3:
- Add missing regulator-name property on fixed regulators
- Simplify regulator labels
- Rename touch@ nodes to touchscreen@
Changes in v2:
- Use panel-simple compatible form
arch/arm64/boot/dts/ti/Makefile | 5 +
...25-verdin-panel-cap-touch-10inch-lvds.dtso | 120 ++++++++++++++++++
2 files changed, 125 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index b2408f62c139..867c05b675d1 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -33,6 +33,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-ivy.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-mallow.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-yavia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-zinnia.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-panel-cap-touch-10inch-lvds.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia-dsi-to-hdmi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dev-dsi-to-hdmi.dtb
@@ -213,6 +214,9 @@ k3-am625-sk-hdmi-audio-dtbs := k3-am625-sk.dtb k3-am62x-sk-hdmi-audio.dtbo
k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch-dtbs := \
k3-am625-verdin-wifi-dev.dtb \
k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
+k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds-dtbs := \
+ k3-am625-verdin-wifi-mallow.dtb \
+ k3-am625-verdin-panel-cap-touch-10inch-lvds.dtbo
k3-am62-lp-sk-hdmi-audio-dtbs := k3-am62-lp-sk.dtb k3-am62x-sk-hdmi-audio.dtbo
k3-am62-lp-sk-nand-dtbs := k3-am62-lp-sk.dtb k3-am62-lp-sk-nand.dtbo
k3-am62a7-phyboard-lyra-disable-eth-phy-dtbs := k3-am62a7-phyboard-lyra-rdk.dtb \
@@ -315,6 +319,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-sk-csi2-tevi-ov5640.dtb \
k3-am625-sk-hdmi-audio.dtb \
k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch.dtb \
+ k3-am625-verdin-wifi-mallow-panel-cap-touch-10inch-lvds.dtb \
k3-am62-lp-sk-hdmi-audio.dtb \
k3-am62-lp-sk-nand.dtb \
k3-am62a7-phyboard-lyra-disable-eth-phy.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds.dtso
new file mode 100644
index 000000000000..f83366b11bdb
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds.dtso
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Toradex Capacitive Touch Display 10.1" connected via Verdin AM62 OLDI
+ * on carrier boards with a Toradex standard LVDS display connector
+ * (e.g., Mallow).
+ *
+ * https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
+ * https://www.toradex.com/accessories/capacitive-touch-display-10.1-inch-lvds
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+ backlight_pwm2: backlight-pwm2 {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_2_d_out_gpio>;
+ brightness-levels = <0 45 63 88 119 158 203 255>;
+ default-brightness-level = <4>;
+ /* Verdin I2S_2_D_OUT as GPIO (SODIMM 46) */
+ enable-gpios = <&main_gpio0 34 GPIO_ACTIVE_HIGH>;
+ /* Verdin PWM_2 (SODIMM 16) */
+ pwms = <&epwm0 1 6666667 PWM_POLARITY_INVERTED>;
+ };
+
+ panel-lvds-native {
+ compatible = "logictechno,lt170410-2whc";
+ backlight = <&backlight_pwm2>;
+ power-supply = <®_3v3_lvds>;
+
+ port {
+ panel_lvds_native_in: endpoint {
+ remote-endpoint = <&oldi0_out>;
+ };
+ };
+ };
+
+ reg_3v3_lvds: regulator-3v3-lvds {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "+V3.3_LVDS";
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+&dss_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* DSS VP1: internal DPI output to OLDIx */
+ port@0 {
+ reg = <0>;
+
+ dss0_out: endpoint {
+ remote-endpoint = <&oldi0_in>;
+ };
+ };
+};
+
+/* Verdin I2C_2_DSI */
+&main_i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ reg = <0x4a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_2_d_in_gpio>, <&pinctrl_i2s_2_sync_gpio>;
+ /* Verdin I2S_2_SYNC as GPIO (SODIMM 44) */
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <37 IRQ_TYPE_EDGE_FALLING>;
+ /* Verdin I2S_2_D_IN as GPIO (SODIMM 48) */
+ reset-gpios = <&main_gpio0 33 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&main_pmx0 {
+ /* Mallow Touch RST */
+ pinctrl_i2s_2_d_in_gpio: main-gpio0-33-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0088, PIN_INPUT, 7) /* (L24) GPMC0_OEn_REn.GPIO0_33 */ /* SODIMM 48 */
+ >;
+ };
+
+ /* Mallow Touch INT# */
+ pinctrl_i2s_2_sync_gpio: main-gpio0-37-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0098, PIN_INPUT, 7) /* (U23) GPMC0_WAIT0.GPIO0_37 */ /* SODIMM 44 */
+ >;
+ };
+};
+
+&oldi0 {
+ status = "okay";
+};
+
+&oldi0_port0 {
+ oldi0_in: endpoint {
+ remote-endpoint = <&dss0_out>;
+ };
+};
+
+&oldi0_port1 {
+ oldi0_out: endpoint {
+ remote-endpoint = <&panel_lvds_native_in>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 01/11] arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with 10.1" display
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260522161105.277519-13-ivitro@gmail.com>
From: Vitor Soares <vitor.soares@toradex.com>
Add a device tree overlay for the Toradex DSI to LVDS Adapter with the
Toradex Capacitive Touch Display 10.1" LVDS. The adapter connects to the
Verdin DSI_1 interface. It is based on the Texas Instruments SN65DSI84
DSI-to-LVDS bridge and drives a LogicTechno LT170410-2WHC 10.1" WXGA LVDS
panel. Touch input is provided by an Atmel MaxTouch capacitive touch
controller.
Link: https://developer.toradex.com/hardware/accessories/add-ons/dsi-lvds-adapter
Link: https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
Assisted-by: Claude:claude-sonnet-4.6
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
---
Changes in v3:
- Add missing regulator-name property on fixed regulators
- Simplify regulator labels
- Rename touch@ nodes to touchscreen@
Changes in v2:
- Use panel-simple compatible form
arch/arm64/boot/dts/ti/Makefile | 5 +
...in-dsi-to-lvds-panel-cap-touch-10inch.dtso | 124 ++++++++++++++++++
2 files changed, 129 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 21db60cd19de..b2408f62c139 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -24,6 +24,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-phyboard-lyra-rdk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-tqma62xx-mba62xx.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-hdmi.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia-dsi-to-hdmi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dahlia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dev-dsi-to-hdmi.dtb
@@ -209,6 +210,9 @@ k3-am625-sk-csi2-ov5640-dtbs := k3-am625-sk.dtb \
k3-am625-sk-csi2-tevi-ov5640-dtbs := k3-am625-sk.dtb \
k3-am62x-sk-csi2-tevi-ov5640.dtbo
k3-am625-sk-hdmi-audio-dtbs := k3-am625-sk.dtb k3-am62x-sk-hdmi-audio.dtbo
+k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch-dtbs := \
+ k3-am625-verdin-wifi-dev.dtb \
+ k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtbo
k3-am62-lp-sk-hdmi-audio-dtbs := k3-am62-lp-sk.dtb k3-am62x-sk-hdmi-audio.dtbo
k3-am62-lp-sk-nand-dtbs := k3-am62-lp-sk.dtb k3-am62-lp-sk-nand.dtbo
k3-am62a7-phyboard-lyra-disable-eth-phy-dtbs := k3-am62a7-phyboard-lyra-rdk.dtb \
@@ -310,6 +314,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-sk-csi2-ov5640.dtb \
k3-am625-sk-csi2-tevi-ov5640.dtb \
k3-am625-sk-hdmi-audio.dtb \
+ k3-am625-verdin-wifi-dev-dsi-to-lvds-panel-cap-touch-10inch.dtb \
k3-am62-lp-sk-hdmi-audio.dtb \
k3-am62-lp-sk-nand.dtb \
k3-am62a7-phyboard-lyra-disable-eth-phy.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso
new file mode 100644
index 000000000000..deb74ecc5eb4
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Toradex DSI to LVDS Adapter on Verdin DSI_1 with Capacitive Touch Display 10.1"
+ * Used on Dahlia (X17) and Development Board (X48) that expose DSI_1 via an
+ * Samtec LSS-130 connector.
+ *
+ * https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
+ * https://www.toradex.com/accessories/capacitive-touch-display-10.1-inch-lvds
+ * https://developer.toradex.com/hardware/accessories/add-ons/dsi-lvds-adapter
+ * https://www.toradex.com/accessories/verdin-dsi-to-lvds-adapter
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/pwm/pwm.h>
+
+&{/} {
+ backlight_pwm3: backlight-pwm3 {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2s_2_d_out_gpio>;
+ brightness-levels = <0 45 63 88 119 158 203 255>;
+ default-brightness-level = <4>;
+ /* Verdin I2S_2_D_OUT as GPIO (SODIMM 46) */
+ enable-gpios = <&main_gpio0 34 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_3v3>;
+ /* Verdin PWM_3_DSI (SODIMM 19) */
+ pwms = <&epwm1 0 6666667 PWM_POLARITY_INVERTED>;
+ };
+
+ panel-lvds-bridge {
+ compatible = "logictechno,lt170410-2whc";
+ backlight = <&backlight_pwm3>;
+ power-supply = <®_3v3_dsi>;
+
+ port {
+ panel_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_out>;
+ };
+ };
+ };
+
+ reg_3v3_dsi: regulator-3v3-dsi {
+ compatible = "regulator-fixed";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "+V3.3_DSI";
+ };
+};
+
+&dsi_bridge {
+ status = "okay";
+};
+
+&dsi_bridge_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ dsi_bridge_out: endpoint {
+ remote-endpoint = <&dsi_lvds_bridge_in>;
+ };
+ };
+};
+
+&dss {
+ status = "okay";
+};
+
+/* Verdin I2C_1 */
+&main_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bridge@2c {
+ compatible = "ti,sn65dsi84";
+ reg = <0x2c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_bkl_en>;
+ /* Verdin GPIO_10_DSI (SODIMM 21) - DSI_1_BKL_EN */
+ enable-gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_lvds_bridge_in: endpoint {
+ remote-endpoint = <&dsi_bridge_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ dsi_lvds_bridge_out: endpoint {
+ remote-endpoint = <&panel_lvds_bridge_in>;
+ };
+ };
+ };
+ };
+
+ touchscreen@4a {
+ compatible = "atmel,maxtouch";
+ reg = <0x4a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_dsi1_int>, <&pinctrl_i2s_2_bclk_gpio>;
+ /* Verdin GPIO_9_DSI (SODIMM 17) - TOUCH_INT# */
+ interrupt-parent = <&main_gpio1>;
+ interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
+ /* Verdin I2S_2_BCLK (SODIMM 42) - TOUCH_RESET# */
+ reset-gpios = <&main_gpio0 35 GPIO_ACTIVE_LOW>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v3 00/11] arm64: dts: ti: k3-am62-verdin: Add display and peripheral overlays
From: Vitor Soares @ 2026-05-22 16:11 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
From: Vitor Soares <vitor.soares@toradex.com>
This series adds device tree overlays, expanding the hardware support for
the Toradex Verdin AM62 SoM. The overlays target displays, cameras, audio,
and peripherals available through Toradex carrier boards and the accessory
ecosystem.
Display additions cover three interface types:
- native OLDI (LVDS) with Toradex Capacitive Touch Display 10.1" LVDS
- DSI-to-LVDS adapter based on the SN65DSI84 with Toradex Capacitive Touch
Display 10.1" LVDS
- DSI driving Toradex Capacitive Touch Display 7" and 10.1" DSI.
The Riverdi vendor prefix and panel bindings required by the DSI overlay
patches are also added.
Non-display additions include OV5640 CSI camera support in 24 MHz and
27 MHz oscillator variants, NAU8822 Bridge Tied Load mode on the
Development Board, MCU_MCAN1 on the Mezzanine board low-speed header,
and MCU_UART0 reservation for the Cortex-M4F debug UART.
TI maintainers: patches adding the Riverdi vendor prefix and panel-lvds
bindings are required by the DTS patches.
Are you fine picking up the full series once those patches are acked by
the DT/display maintainers?
---
Changes in v3:
- Add missing regulator-name property on fixed regulators
- Simplify regulator labels (reg_3v3_lvds_native -> reg_3v3_lvds,
reg_3v3_lvds_bridge -> reg_3v3_dsi)
- Rename touch@ nodes to touchscreen@
- Link v2: https://lore.kernel.org/all/20260522132014.226721-13-ivitro@gmail.com/
Changes in v2:
- Add Ab tags
- Drop introduction of the LG LP156WF1 15.6" FHD dual-channel LVDS panel
- Drop migration of "logictechno,lt170410-2whc" to panel-lvds.yaml
- Link v1: https://lore.kernel.org/all/20260521150038.103538-17-ivitro@gmail.com/
---
Vitor Soares (11):
arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with
10.1" display
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display
10.1" LVDS
dt-bindings: vendor-prefixes: Add Riverdi
dt-bindings: display: panel-lvds: Add Riverdi RVT70HSLNWCA0 and
RVT101HVLNWC00
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display
10.1" DSI
arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display
7" DSI
arm64: dts: ti: k3-am62-verdin: Add NAU8822 Bridge Tied Load
arm64: dts: ti: k3-am62-verdin: Reserve UART_4 for Cortex-M4F
arm64: dts: ti: k3-am62-verdin: Add Toradex OV5640 CSI Cameras
arm64: dts: ti: k3-am62-verdin: Add Toradex Verdin Mezzanine CAN
arm64: dts: ti: k3-am62-verdin: Add Mezzanine with Toradex Display
10.1" LVDS
.../bindings/display/panel/panel-lvds.yaml | 4 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/ti/Makefile | 49 +++++++
.../ti/k3-am625-verdin-dev-mezzanine-can.dtso | 28 ++++
...mezzanine-panel-cap-touch-10inch-lvds.dtso | 98 +++++++++++++
.../ti/k3-am625-verdin-dev-nau8822-btl.dtso | 14 ++
...in-dsi-to-lvds-panel-cap-touch-10inch.dtso | 124 ++++++++++++++++
.../dts/ti/k3-am625-verdin-ov5640-24mhz.dtso | 17 +++
.../boot/dts/ti/k3-am625-verdin-ov5640.dtsi | 71 ++++++++++
.../boot/dts/ti/k3-am625-verdin-ov5640.dtso | 18 +++
...625-verdin-panel-cap-touch-10inch-dsi.dtso | 132 ++++++++++++++++++
...25-verdin-panel-cap-touch-10inch-lvds.dtso | 120 ++++++++++++++++
...m625-verdin-panel-cap-touch-7inch-dsi.dtso | 132 ++++++++++++++++++
.../dts/ti/k3-am625-verdin-uart4-mcu.dtso | 13 ++
14 files changed, 822 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-can.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-mezzanine-panel-cap-touch-10inch-lvds.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dev-nau8822-btl.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-10inch.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640-24mhz.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-ov5640.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-dsi.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-10inch-lvds.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-panel-cap-touch-7inch-dsi.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-uart4-mcu.dtso
--
2.54.0
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: pinctrl: renesas,rzg2l-pinctrl: Document the missing I3C power source option
From: Conor Dooley @ 2026-05-22 16:11 UTC (permalink / raw)
To: Claudiu Beznea
Cc: geert+renesas, linusw, robh, krzk+dt, conor+dt, magnus.damm,
wsa+renesas, claudiu.beznea, linux-renesas-soc, linux-gpio,
devicetree, linux-kernel, Claudiu Beznea
In-Reply-To: <20260522102251.1723392-6-claudiu.beznea@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] Bluetooth: hci_qca: Support QCA2066 on M.2 connector via pwrseq
From: Loic Poulain @ 2026-05-22 16:11 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-pci,
linux-pm, linux-kernel, linux-arm-msm, linux-bluetooth,
devicetree
In-Reply-To: <cx3pbr47tsy5mnag73oopkodnx4jgoiipz5pzrp4uze7mk4fgg@zogzww23ueni>
On Wed, May 20, 2026 at 2:33 PM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
>
> On Wed, May 20, 2026 at 01:01:43PM +0200, Loic Poulain wrote:
> > For QCA2066 (and other QCA chips) on M.2 connectors, the UART enable
> > is controlled by the W_DISABLE2# signal managed by the pcie-m2 power
> > sequencer rather than a dedicated BT enable GPIO.
> >
> > When the serdev controller has an OF graph (indicating it is connected
> > to an M.2 connector), acquire the 'uart' pwrseq target from the
> > connector's power sequencer and use it to control BT power instead of
> > the bt-enable GPIO.
> >
> > Also allocate bt_power unconditionally for all SOC types since the
> > pwrseq path is independent of the SOC type switch.
> >
> > Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> > ---
> > drivers/bluetooth/hci_qca.c | 33 +++++++++++++--------------------
> > 1 file changed, 13 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index b5439b9956cfb0497e6ba6ccd9ed61224d23a9dd..de5cba7b7f44e280a48dad5d670fa2758d3268d0 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -1873,6 +1873,9 @@ static int qca_power_on(struct hci_dev *hdev)
> > /* Controller needs time to bootup. */
> > msleep(150);
> > }
> > +
> > + if (qcadev->bt_power && qcadev->bt_power->pwrseq)
> > + pwrseq_power_on(qcadev->bt_power->pwrseq);
> > }
> >
> > clear_bit(QCA_BT_OFF, &qca->flags);
> > @@ -2415,25 +2418,9 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> > else
> > qcadev->btsoc_type = QCA_ROME;
> >
> > - switch (qcadev->btsoc_type) {
> > - case QCA_QCA6390:
> > - case QCA_WCN3950:
> > - case QCA_WCN3988:
> > - case QCA_WCN3990:
> > - case QCA_WCN3991:
> > - case QCA_WCN3998:
> > - case QCA_WCN6750:
> > - case QCA_WCN6855:
> > - case QCA_WCN7850:
> > - qcadev->bt_power = devm_kzalloc(&serdev->dev,
> > - sizeof(struct qca_power),
> > - GFP_KERNEL);
> > - if (!qcadev->bt_power)
> > - return -ENOMEM;
> > - break;
> > - default:
> > - break;
> > - }
> > + qcadev->bt_power = devm_kzalloc(&serdev->dev, sizeof(struct qca_power), GFP_KERNEL);
> > + if (!qcadev->bt_power)
> > + return -ENOMEM;
>
> This builds bt_power for all devices even though it wasn't the case
> beforehand. As such, you can drop all further `if (qcadev->bt_power)`
> checks in the driver. But, you also need to check that this won't break
> support for other (older) chips.
Ok, I will do, and double check.
>
> >
> > switch (qcadev->btsoc_type) {
> > case QCA_WCN3950:
> > @@ -2543,7 +2530,13 @@ static int qca_serdev_probe(struct serdev_device *serdev)
> > return PTR_ERR(qcadev->bt_en);
> > }
> >
> > - if (!qcadev->bt_en)
> > + if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
>
> And this breaks support for pwrseq for non-M.2 BT devices. There is no
> OF graph in such a case.
Not sure why, here we handle OF graph as an optional pwrseq provider,
but still support legacy enablement.
>
> > + qcadev->bt_power->pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, "uart");
> > + if (IS_ERR(qcadev->bt_power->pwrseq))
> > + return PTR_ERR(qcadev->bt_power->pwrseq);
> > + }
> > +
> > + if (!qcadev->bt_en && !qcadev->bt_power->pwrseq)
> > bt_en_available = false;
> >
> > qcadev->susclk = devm_clk_get_optional_enabled_with_rate(
> >
> > --
> > 2.34.1
> >
>
> --
> With best wishes
> Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: ad4080: add AD4884 support
From: Conor Dooley @ 2026-05-22 16:10 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Antoniu Miclaus, Nuno Sá, Michael Hennerich, David Lechner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260522133228.06521c5d@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
On Fri, May 22, 2026 at 01:32:28PM +0100, Jonathan Cameron wrote:
> On Fri, 22 May 2026 14:53:36 +0300
> Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
>
> > Add AD4884 compatible string to the AD4080 devicetree binding.
> >
> > The AD4884 is a dual-channel, 16-bit, 40 MSPS SAR ADC, sharing the same
> > register map and interface as the AD4080 family. Like the AD4880, it
> > requires two SPI chip selects and two io-backends for its independent
> > ADC channels.
>
> I don't see anything in here to say how it is different in a fashion
> that doesn't allow a fall back compatible to the ad4880. Probably just
> needs a statement about the resolution being different.
With one,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> >
> > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
> > ---
> > Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
> > index 9c6a56c7c8ef..4a3f7d3e05c3 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
> > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4080.yaml
> > @@ -39,6 +39,7 @@ properties:
> > - adi,ad4087
> > - adi,ad4088
> > - adi,ad4880
> > + - adi,ad4884
> >
> > reg:
> > minItems: 1
> > @@ -99,7 +100,9 @@ allOf:
> > properties:
> > compatible:
> > contains:
> > - const: adi,ad4880
> > + enum:
> > + - adi,ad4880
> > + - adi,ad4884
> > then:
> > properties:
> > reg:
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/2] cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC
From: sashiko-bot @ 2026-05-22 16:06 UTC (permalink / raw)
To: Imran Shaik; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260522-shikra-cpufreq-scaling-v4-2-f042a25896c5@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Calling kfree() on an interior pointer of a devm-managed array causes severe memory corruption.
- [High] The turbo/boost frequency is improperly ignored and left invalid when the hardware LUT is fully populated.
- [High] The LMh throttle delayed work can outlive the `qcom_cpufreq_data` structure, causing a Use-After-Free when the policy is destroyed.
--
commit 04a4ff128bbeeee8119bf80c19ea931913c35395
Author: Taniya Das <taniya.das@oss.qualcomm.com>
cpufreq: qcom: Add cpufreq scaling support for Qualcomm Shikra SoC
This commit adds cpufreq scaling support for the Qualcomm Shikra SoC. It
introduces the shikra_epss_soc_data structure which reuses the EPSS
configuration but limits the maximum lookup table entries to 12.
> diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c b/drivers/cpufreq/qcom-cpufreq-hw.c
> index ea9a20d27b8fd..3d5a865fb8a35 100644
> --- a/drivers/cpufreq/qcom-cpufreq-hw.c
> +++ b/drivers/cpufreq/qcom-cpufreq-hw.c
[ ... ]
> @@ -236,7 +238,7 @@ static int qcom_cpufreq_hw_read_lut(struct device *cpu_dev,
> icc_scaling_enabled = false;
> }
>
> - for (i = 0; i < LUT_MAX_ENTRIES; i++) {
> + for (i = 0; i < soc_data->lut_max_entries; i++) {
> data = readl_relaxed(drv_data->base + soc_data->reg_freq_lut +
> i * soc_data->lut_row_size);
> src = FIELD_GET(LUT_SRC, data);
[Severity: High]
This is a pre-existing issue, but does this loop handle a fully populated LUT
where the last entry is a turbo frequency?
When a frequency has a core_count of LUT_TURBO_IND, it is initially marked as
CPUFREQ_ENTRY_INVALID. The code relies on encountering a duplicate frequency
on the next iteration to convert that invalid entry into CPUFREQ_BOOST_FREQ.
If the hardware LUT is completely filled with unique entries up to its
capacity limit, the loop terminates naturally. Does this leave the final
turbo entry ignored and invalid since the duplicate check is never reached?
[ ... ]
[Severity: Critical]
This is a pre-existing issue, but could the teardown path free a devm-managed
interior pointer?
During policy initialization, the driver assigns policy->driver_data to point
to an interior element within a collectively allocated devm-managed array:
qcom_cpufreq_hw_cpu_init()
policy->driver_data = &qcom_cpufreq.data[index];
During teardown, the driver appears to manually free this pointer:
qcom_cpufreq_hw_cpu_exit()
kfree(data);
Can this manual kfree() on an interior pointer bypass devres management and
cause memory issues during device unbind or CPU hotplug?
[Severity: High]
This is a pre-existing issue, but is there a race between the LMh throttle
delayed work and the CPU offline sequence?
In qcom_cpufreq_hw_cpu_offline(), the driver cancels the work before
disabling the interrupt:
qcom_cpufreq_hw_cpu_offline()
cancel_delayed_work_sync(&data->throttle_work);
disable_irq_nosync();
If the hardware interrupt fires during this window, the interrupt handler
qcom_lmh_dcvs_handle_irq() unconditionally re-arms the delayed work.
Later, when qcom_cpufreq_hw_cpu_exit() frees the data structure, the re-armed
work could still execute and attempt to access the freed memory:
qcom_lmh_dcvs_poll()
mutex_lock(&data->throttle_lock);
Could the driver disable the IRQ before canceling the work to ensure the
work is not re-armed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-shikra-cpufreq-scaling-v4-0-f042a25896c5@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH v7 9/9] clk: eyeq: Add EyeQ7H compatibles
From: sashiko-bot @ 2026-05-22 16:06 UTC (permalink / raw)
To: Benoît Monin; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260522-clk-eyeq7-v7-9-14ad6c2c5213@bootlin.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Calculations for PLL multipliers, dividers, and accuracy in `eqc_pll_parse_jfracr` suffer from severe truncation and overflows on 32-bit platforms.
- [High] The PLL parsing functions for AINTP and JFRACR completely ignore the defined post-divider configurations when calculating the clock frequency.
Pre-existing issues:
- [High] Using `readq()` to read two distinct 32-bit configuration registers simultaneously risks bus faults on 32-bit peripheral buses.
--
commit 2a35962c5575980a3ba602361782cb07def54c96
Author: Benoît Monin <benoit.monin@bootlin.com>
clk: eyeq: Add EyeQ7H compatibles
Add the entries for the 14 Other Logic Blocks found in the EyeQ7H SoC. The
clock tree is more complex than the previous generation of SoC, as some
OLB depend on the clock output of other OLB instead of all referring to
the main oscillator.
> diff --git a/drivers/clk/clk-eyeq.c b/drivers/clk/clk-eyeq.c
> index 5200d5f0ff060..d55be678c597f 100644
> --- a/drivers/clk/clk-eyeq.c
> +++ b/drivers/clk/clk-eyeq.c
[ ... ]
> @@ -160,6 +196,29 @@ static void eqc_pll_downshift_factors(unsigned long *mult, unsigned long *div)
> *div >>= shift;
> }
>
> +static int eqc_pll_parse_aintp(void __iomem *base, unsigned long *mult, unsigned long *div)
> +{
> + u32 r0;
> +
> + r0 = readl(base);
> + if (r0 & AINTP_PCSR_BYPASS) {
> + *mult = 1;
> + *div = 1;
> + return 0;
> + }
> +
> + if (!(r0 & AINTP_PCSR_PLL_LOCKED))
> + return -EINVAL;
> +
> + *mult = FIELD_GET(AINTP_PCSR_FB_DIV, r0);
> + *div = FIELD_GET(AINTP_PCSR_REF_DIV, r0);
[Severity: High]
Does this calculation ignore post-dividers? The macros AINTP_PCSR_POST_DIV1
and AINTP_PCSR_POST_DIV2 are explicitly defined, but aren't used here. If the
hardware is configured to output the post-divided clock, will the driver
report an erroneously high frequency to the clock framework?
> +
> + if (!*mult || !*div)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static int eqc_pll_parse_fracg(void __iomem *base, unsigned long *mult,
> unsigned long *div, unsigned long *acc)
> {
[ ... ]
> @@ -229,6 +288,60 @@ static int eqc_pll_parse_fracg(void __iomem *base, unsigned long *mult,
> return 0;
> }
>
> +static int eqc_pll_parse_jfracr(void __iomem *base, unsigned long *mult,
> + unsigned long *div, unsigned long *acc)
> +{
> + unsigned long spread;
> + u32 r0, r1, r2;
> + u64 val;
> +
> + val = readq(base);
[Severity: High]
This is a pre-existing issue, but does using readq() to read two distinct
32-bit configuration registers risk bus faults on 32-bit peripheral buses?
Without explicit hardware support for 64-bit wide reads, should these
registers be read strictly using distinct readl() calls?
> + r0 = val;
> + r1 = val >> 32;
> + r2 = readl(base + 8);
> +
> + if (r0 & JFRACR_PCSR0_BYPASS) {
> + *mult = 1;
> + *div = 1;
> + *acc = 0;
> + return 0;
> + }
> +
> + /* Consider the PLL locked if either the phase or the frequency is locked */
> + if (!(r0 & JFRACR_PCSR0_PLL_LOCKED))
> + return -EINVAL;
> +
> + *mult = FIELD_GET(JFRACR_PCSR0_FB_DIV, r0);
> + *div = FIELD_GET(JFRACR_PCSR0_REF_DIV, r0);
[Severity: High]
Similar to the AINTP parser above, does this miss the post-dividers
JFRACR_PCSR0_POST_DIV1 and JFRACR_PCSR0_POST_DIV2 when calculating the
clock frequency?
> +
> + /* fractional part on 24 bits */
> + if (r1 & JFRACR_PCSR1_DSM_EN) {
> + *div *= (1ULL << 24);
> + *mult = *mult * (1ULL << 24) + FIELD_GET(JFRACR_PCSR1_FRAC_IN, r1);
[Severity: High]
On 32-bit platforms, mult is a pointer to a 32-bit unsigned long. Will
assigning the 64-bit result of this calculation back into *mult silently
truncate it before eqc_pll_downshift_factors() executes?
Should intermediate calculations use u64 variables instead?
> + }
> +
> + if (!*mult || !*div)
> + return -EINVAL;
> +
> + if (r2 & (JFRACR_PCSR2_RESET | JFRACR_PCSR2_DIS_SSCG)) {
> + *acc = 0;
> + } else {
> + /* spread spectrum is identical to FRACG PLL */
> + spread = FIELD_GET(JFRACR_PCSR2_SPREAD, r2);
> + *acc = DIV_ROUND_CLOSEST(spread * 1000000000, 1024 * 2);
[Severity: High]
If spread is larger than 4, will spread * 1000000000 overflow a 32-bit
unsigned integer native calculation?
Should this use 1000000000ULL and DIV_ROUND_CLOSEST_ULL to prevent
truncation and incorrect clock rates?
> +
> + if (r2 & JFRACR_PCSR2_DOWN_SPREAD) {
> + *mult *= 2048 - spread;
> + *div *= 2048;
> + }
> + }
> +
> + /* make sure mult and div fit in 32 bits */
> + eqc_pll_downshift_factors(mult, div);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-clk-eyeq7-v7-0-14ad6c2c5213@bootlin.com?part=9
^ permalink raw reply
* Re: Re: Re: [PATCH net v2 1/5] dt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets
From: Conor Dooley @ 2026-05-22 16:02 UTC (permalink / raw)
To: 李志; +Cc: sashiko-reviews, robh, devicetree, conor+dt
In-Reply-To: <1dd4d673.86ff.19e4d99369e.Coremail.lizhi2@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 4046 bytes --]
On Fri, May 22, 2026 at 10:52:27AM +0800, 李志 wrote:
>
>
>
> > -----Original Messages-----
> > From: "Conor Dooley" <conor@kernel.org>
> > Send time:Tuesday, 19/05/2026 17:55:27
> > To: 李志 <lizhi2@eswincomputing.com>
> > Cc: sashiko-reviews@lists.linux.dev, robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
> > Subject: Re: Re: [PATCH net v2 1/5] dt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets
> >
> > On Tue, May 19, 2026 at 05:51:05PM +0800, 李志 wrote:
> > >
> > >
> > >
> > > > -----Original Messages-----
> > > > From: "Conor Dooley" <conor@kernel.org>
> > > > Send time:Tuesday, 19/05/2026 17:11:59
> > > > To: sashiko-reviews@lists.linux.dev
> > > > Cc: lizhi2@eswincomputing.com, robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
> > > > Subject: Re: [PATCH net v2 1/5] dt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets
> > > >
> > > > On Tue, May 19, 2026 at 02:23:33AM +0000, sashiko-bot@kernel.org wrote:
> > > > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > > > > - [Medium] Missing `minItems: 4` constraint makes the newly added optional cells mandatory, breaking schema backward compatibility.
> > > > > --
> > > > >
> > > > > commit 2992483df88af2823c275fc86187f7e38acbee5c
> > > > > Author: Zhi Li <lizhi2@eswincomputing.com>
> > > > >
> > > > > dt-bindings: ethernet: eswin: add optional TXD and RXD delay register offsets
> > > > >
> > > > > This commit documents two optional cells in the eswin,hsp-sp-csr property
> > > > > for the TXD and RXD delay control register offsets.
> > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> > > > > > --- a/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/net/eswin,eic7700-eth.yaml
> > > > >
> > > > > [ ... ]
> > > > >
> > > > > > @@ -82,6 +91,8 @@ properties:
> > > > > > - description: Offset of AXI clock controller Low-Power request
> > > > > > register
> > > > > > - description: Offset of register controlling TX/RX clock delay
> > > > > > + - description: Optional offset of register controlling TXD delay
> > > > > > + - description: Optional offset of register controlling RXD delay
> > > > >
> > > > > Will this make the two new offsets strictly required instead of optional?
> > > > >
> > > > > In dt-schema, when an items list defines a tuple, minItems implicitly
> > > > > defaults to the total number of items in that list. By increasing the list
> > > > > from 4 to 6 items without adding a minItems: 4 constraint to the inner items
> > > > > list, won't validation now strictly require exactly 6 items?
> > > > >
> > > > > Could this cause dt_binding_check to fail for existing device trees that
> > > > > correctly specify only the original 4 elements?
> > > >
> > > > Looks like a valid complaint to me.
> > > > pw-bot: changes-requested
> > > >
> > > You're right, this is a valid issue.
> > >
> > > I'll fix it in v3 by adding only minItems: 4 to preserve backward
> > > compatibility with existing 4-cell device trees.
> > >
> > > Should I drop your Acked-by in v3 due to the schema change, or should
> > > it be retained?
> >
> > Just fix it, and you can retain.
>
> Hi Conor,
>
> I noticed that the v2 series has already been applied to net.git:
> https://lore.kernel.org/lkml/177935821264.4013498.4647676520552839707.git-patchwork-notify@kernel.org/
>
> Since the missing minItems: 4 breaks backward compatibility for
> existing 4-cell device trees, I plan to send a new single-patch series
> targeting net to add the missing constraint.
>
> Just wanted to confirm that this is the preferred approach.
That sounds like the right approach to me.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 01/10] soc: bcm2835: Use IS_REACHABLE for function declaration
From: sashiko-bot @ 2026-05-22 16:00 UTC (permalink / raw)
To: Gregor Herburger; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260522-rpi-otp-driver-v6-1-b0eac97d1428@linutronix.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Replacing IS_ENABLED() with IS_REACHABLE() introduces silent runtime failures (such as infinite probe-deferral loops or silently failing operations) by hiding unresolved module dependencies behind inline stubs.
--
commit 4df320b82133df67fcde1204534b53b54b092612
Author: Gregor Herburger <gregor.herburger@linutronix.de>
soc: bcm2835: Use IS_REACHABLE for function declaration
This commit modifies the raspberrypi-firmware header to use IS_REACHABLE
instead of IS_ENABLED for function declarations. It aims to simplify
Kconfig dependencies for dependent drivers while avoiding linker errors
during COMPILE_TEST builds where the firmware is modular.
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index e1f87fbfe5542..eb33838e0cd10 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -174,7 +174,7 @@ struct rpi_firmware_clk_rate_request {
> .id = cpu_to_le32(_id), \
> }
>
> -#if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
> +#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
[Severity: High]
Could this change introduce silent runtime failures for dependent drivers?
When a dependent driver is compiled as built-in (=y) via COMPILE_TEST while
the firmware is compiled as a module (=m), IS_REACHABLE evaluates to false.
This causes the compiler to silently substitute hardcoded inline stubs
instead of linking against the real firmware functions.
Consequently, the build succeeds but the drivers might fundamentally fail at
runtime. For example, devm_rpi_firmware_get() returning NULL could cause a
permanent -EPROBE_DEFER loop, or rpi_firmware_property() returning -ENOSYS
might break all NVMEM reads and writes.
The previous Kconfig dependency forced dependent drivers to =m in this
scenario, guaranteeing functional runtime behavior and using linker errors
to enforce correct configurations. Does using IS_REACHABLE here mask these
module dependencies in a way that breaks the drivers at runtime?
> int rpi_firmware_property(struct rpi_firmware *fw,
> u32 tag, void *data, size_t len);
> int rpi_firmware_property_list(struct rpi_firmware *fw,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de?part=1
^ permalink raw reply
* Re: [PATCH v2 1/4] phy: qcom: qmp-combo: skip USB power_off/exit after device teardown
From: Michael Scott @ 2026-05-22 15:59 UTC (permalink / raw)
To: Bryan O'Donoghue, linux-arm-msm
Cc: vkoul, neil.armstrong, dmitry.baryshkov, wesley.cheng, abelvesa,
faisal.hassan, linux-phy, andersson, konradybcio, robh, krzk+dt,
conor+dt, devicetree, val, laurentiu.tudor1, alex.vinarskis,
linux-kernel
In-Reply-To: <d543fe6c-88a3-40b8-a83a-ccc6fa80eee3@linaro.org>
On 5/21/26 4:58 AM, Bryan O'Donoghue wrote:
> On 21/05/2026 02:09, Michael Scott wrote:
>> qmp_combo_usb_power_off() is reachable from an external consumer
>> (notably dwc3 via phy_exit() during driver unbind) after this device's
>> backing resources have already been released along a separate teardown
>> chain. The dereference of qmp->pcs (whose ioremap mapping has been
>> freed by devm cleanup) then takes a level-3 translation fault and
>> oopses.
>>
>> Easily reproducible during testing of USB-C role-switch enablement on
>> Dell Latitude 7455 (X1E80100), by writing "none" to a USB-C DWC3's
>> usb_role_switch role attribute, e.g.
>>
>> echo none > /sys/class/usb_role/a800000.usb-role-switch/role
>>
>> which triggers the chain:
>>
>> Unable to handle kernel paging request at virtual address
>> ffff8000876c5400
>> pc : qmp_combo_usb_power_off.isra.0+0x58/0x470 [phy_qcom_qmp_combo]
>> Call trace:
>> qmp_combo_usb_power_off+0x58/0x470 [phy_qcom_qmp_combo]
>> qmp_combo_usb_exit+0x38/0x90 [phy_qcom_qmp_combo]
>> phy_exit
>> dwc3_phy_exit [dwc3]
>> dwc3_core_remove [dwc3]
>> dwc3_remove [dwc3]
>> platform_remove
>> device_release_driver_internal
>> device_driver_detach
>> unbind_store
>> sysfs_kf_write
>> vfs_write
>> ksys_write
>> __arm64_sys_write
>> el0_svc
>>
>> Two WARNs precede the oops from the same teardown chain, confirming
>> the resource ordering:
>>
>> WARNING: drivers/clk/clk.c:4494 at
>> clk_nodrv_disable_unprepare+0x8/0x18
>> WARNING: drivers/regulator/core.c:2657 at _regulator_put+0x84/0x98
>>
>> i.e. the pipe clock provider has been unregistered and the regulators
>> released before qmp_combo_usb_power_off() runs.
>>
>> The proper long-term fix is a teardown-ordering rework so the QMP
>> PHY's backing resources outlive any consumer that may still call its
>> phy_ops. Pending that, guard the power_off/exit paths with the
>> existing usb_init_count balance so re-entry after teardown does not
>> oops. usb_init_count tracks the balance of usb_power_on/off; if it
>> is zero we have either never powered on or have already powered off,
>> and there is nothing to do.
>>
>> The same guard is added to qmp_combo_usb_exit() since it is the entry
>> point used by external consumers via phy_exit().
>>
>> Signed-off-by: Michael Scott <mike.scott@oss.qualcomm.com>
>
> Something like this requires a Fixes: tag
Thanks! Noted.
>
>> ---
>> drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> index cdcfad2e86b1..0db200292642 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
>> @@ -3926,6 +3926,17 @@ static int qmp_combo_usb_power_off(struct phy
>> *phy)
>> struct qmp_combo *qmp = phy_get_drvdata(phy);
>> const struct qmp_phy_cfg *cfg = qmp->cfg;
>> + /*
>> + * Reachable as ->exit from external consumers (notably dwc3) after
>> + * this device's backing resources have already been released along
>> + * a teardown chain. Refuse to touch registers in that case.
>> + */
>> + if (!qmp->usb_init_count) {
>> + dev_dbg(qmp->dev, "%s: PHY not powered on, skipping\n",
>> + __func__);
>> + return 0;
>> + }
>> +
>> /* PHY reset */
>> qphy_setbits(qmp->pcs, cfg->regs[QPHY_SW_RESET], SW_RESET);
>> @@ -3968,6 +3979,17 @@ static int qmp_combo_usb_exit(struct phy *phy)
>> struct qmp_combo *qmp = phy_get_drvdata(phy);
>> int ret;
>> + /*
>> + * See qmp_combo_usb_power_off(): an external consumer may call
>> + * phy_exit() after the QMP device's resources have been torn
>> + * down. usb_init_count tracks usb_init/usb_exit balance.
>> + */
>> + if (!qmp->usb_init_count) {
>> + dev_dbg(qmp->dev, "%s: PHY not initialised, skipping\n",
>> + __func__);
>> + return 0;
>> + }
>> +
>> mutex_lock(&qmp->phy_mutex);
>> ret = qmp_combo_usb_power_off(phy);
>
> This can't be right - you check usb_init_count before the mutex and
> then again inside the mutex @ qmp_combo_usb_power_off();
>
> It seems like an error to even get to this function with
> !usb_init_count also check if that is a signed or an unsigned value as
> usb_init_count = -1 will evaluate true.
Yep, there are a few issues with this patch (and this looks like an
extra check I accidentally left in). I'm dropping this from the
patchset and I'll revisit at a later date.
Apologies for the noise.
>
>> if (ret)
>> --
>> 2.53.0
>>
>
^ permalink raw reply
* Re: [PATCH v2 3/4] firmware: qcom: scm: Add minidump SRAM support
From: Mukesh Ojha @ 2026-05-22 15:58 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <1f8f46c7-8332-44ee-992e-0b9ca1c0ffef@oss.qualcomm.com>
On Thu, May 21, 2026 at 12:21:03PM +0200, Konrad Dybcio wrote:
> On 5/19/26 7:14 PM, Mukesh Ojha wrote:
> > On most Qualcomm SoCs where minidump is supported, a word in always-on
> > SRAM is shared between the kernel and boot firmware. Before DDR is
> > initialised on the warm reset following a crash, firmware reads this
> > word to decide if minidump is enabled and collect a minidump and where
> > to deliver it (USB upload to a host, or save to local storage).
> >
> > The SRAM region is described by a 'sram' phandle on the SCM DT node.
> > If the property is absent the feature is silently disabled, keeping
> > existing SoCs unaffected.
> >
> > Expose a 'minidump_dest' module parameter (default: usb) so the user can
> > select the destination. Only the string names "usb" or "storage" are
> > accepted; an invalid value is rejected with -EINVAL. Changing the
> > destination while minidump mode is already active updates SRAM immediately.
> >
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
>
> [...]
>
> > +static int qcom_scm_map_minidump_sram(struct device *dev, void __iomem **out)
> > +{
> > + struct device_node *np = dev->of_node;
> > + struct device_node *sram_np;
> > + struct resource res;
> > + int ret;
> > +
> > + if (!of_property_present(np, "sram"))
> > + return 0;
>
> I think of_parse_phandle() calls this indirectly already
>
Right, will remove and turn below return statement to return 0.
> > +
> > + sram_np = of_parse_phandle(np, "sram", 0);
> > + if (!sram_np)
> > + return -EINVAL;
> > +
> > + ret = of_address_to_resource(sram_np, 0, &res);
> > + of_node_put(sram_np);
> > + if (ret)
> > + return ret;
> > +
> > + if (resource_size(&res) < sizeof(u32)) {
> > + dev_err(dev, "minidump SRAM region too small\n");
> > + return -EINVAL;
>
> I don't know if this is possible in practice
>
Right, will remove it.
> Konrad
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v2 3/4] firmware: qcom: scm: Add minidump SRAM support
From: Mukesh Ojha @ 2026-05-22 15:56 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <19de35c4-8ddc-4824-b8c6-083eb53a5e8d@oss.qualcomm.com>
On Thu, May 21, 2026 at 12:21:34PM +0200, Konrad Dybcio wrote:
> On 5/19/26 7:14 PM, Mukesh Ojha wrote:
> > On most Qualcomm SoCs where minidump is supported, a word in always-on
> > SRAM is shared between the kernel and boot firmware. Before DDR is
> > initialised on the warm reset following a crash, firmware reads this
> > word to decide if minidump is enabled and collect a minidump and where
> > to deliver it (USB upload to a host, or save to local storage).
> >
> > The SRAM region is described by a 'sram' phandle on the SCM DT node.
> > If the property is absent the feature is silently disabled, keeping
> > existing SoCs unaffected.
> >
> > Expose a 'minidump_dest' module parameter (default: usb) so the user can
> > select the destination. Only the string names "usb" or "storage" are
> > accepted; an invalid value is rejected with -EINVAL. Changing the
> > destination while minidump mode is already active updates SRAM immediately.
> >
> > Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> > ---
>
> [...]
>
> > +
> > +static u32 minidump_dest = QCOM_MINIDUMP_DEST_USB;
> > +
> > +static const char * const minidump_dest_name[] = { "usb", "storage" };
> > +static const u32 minidump_dest_val[] = {
> > + QCOM_MINIDUMP_DEST_USB,
> > + QCOM_MINIDUMP_DEST_STORAGE,
> > +};
>
> Since these two are supposed to live together, could you turn this into
> a struct?
Sure.
>
> Konrad
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v2 01/11] arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with 10.1" display
From: Vitor Soares @ 2026-05-22 15:51 UTC (permalink / raw)
To: Laurent Pinchart, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Lad Prabhakar,
Thierry Reding
Cc: Vitor Soares, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260522132014.226721-14-ivitro@gmail.com>
Hi,
On Fri, 2026-05-22 at 14:20 +0100, Vitor Soares wrote:
> From: Vitor Soares <vitor.soares@toradex.com>
>
> Add a device tree overlay for the Toradex DSI to LVDS Adapter with the
> Toradex Capacitive Touch Display 10.1" LVDS. The adapter connects to the
> Verdin DSI_1 interface. It is based on the Texas Instruments SN65DSI84
> DSI-to-LVDS bridge and drives a LogicTechno LT170410-2WHC 10.1" WXGA LVDS
> panel. Touch input is provided by an Atmel MaxTouch capacitive touch
> controller.
>
> Link:
> https://developer.toradex.com/hardware/accessories/add-ons/dsi-lvds-adapter
> Link:
> https://developer.toradex.com/hardware/accessories/displays/capacitive-touch-display-101inch-lvds
> Assisted-by: Claude:claude-sonnet-4.6
> Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
>
[...]
> diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-
> touch-10inch.dtso b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-
> cap-touch-10inch.dtso
> new file mode 100644
> index 000000000000..0e873f2ccf65
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-dsi-to-lvds-panel-cap-touch-
> 10inch.dtso
>
[...]
> +
> + reg_3v3_lvds_bridge: regulator-3v3-lvds-bridge {
> + compatible = "regulator-fixed";
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
Sashiko flagged the missing 'regulator-name' property here,
> + };
> +};
> +
>
[...]
> +
> + touch@4a {
and to use the generic node name 'touchscreen@4a' here instead of
'touch@4a'.
> + compatible = "atmel,maxtouch";
> + reg = <0x4a>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_dsi1_int>, <&pinctrl_i2s_2_bclk_gpio>;
> + /* Verdin GPIO_9_DSI (SODIMM 17) - TOUCH_INT# */
> + interrupt-parent = <&main_gpio1>;
> + interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
> + /* Verdin I2S_2_BCLK (SODIMM 42) - TOUCH_RESET# */
> + reset-gpios = <&main_gpio0 35 GPIO_ACTIVE_LOW>;
> + };
> +};
I will send a v3 addressing these issues here and where it applies.
Thanks,
Vitor Soares
^ permalink raw reply
* Re: [PATCH v2 7/7] arm64: dts: renesas: r8a779md: Add support for R-Car M3Le R8A779MD Geist
From: Geert Uytterhoeven @ 2026-05-22 15:47 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Nguyen Tran, Brian Masney, Conor Dooley,
Geert Uytterhoeven, Krzysztof Kozlowski, Kuninori Morimoto,
Magnus Damm, Michael Turquette, Rob Herring, Stephen Boyd,
Ulf Hansson, Wolfram Sang, devicetree, linux-clk, linux-kernel,
linux-mmc, linux-renesas-soc
In-Reply-To: <20260504144534.43745-8-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Mon, 4 May 2026 at 16:46, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> From: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
>
> Add support for the Geist board based on the Renesas R-Car R8A779MD (M3Le)
> SoC, a register-compatible variant of the R8A77965 (M3-N) with reduced set
> of peripherals.
>
> Signed-off-by: Nguyen Tran <nguyen.tran.pz@bp.renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> V2: - Drop CS2500 variant suffix
> - Drop cells from rcar_sound ports {}
> - Drop ehci1, ohci1, usb2_phy1
> - Drop Salvator-X reference from commit message
> - Split panel DTO into separate patch
> - Drop FCNL node
> - Add another memory node for the second 2 GiB of DRAM,
> although the DRAM layout is patched in by U-Boot
> - Drop FIXME from audio-clkout {}
> - Sort nodes without unit address
> - Rename regulators, use npmv suffix for n.m V regulators
> - Rename x12 node to x12-clock node
> - Add PHY compatible string
> - Use interrupts-extended in PHY node
> - Rename clk_multiplier/clock-generator to clock-controller
> - Use interrupts-extended
> - Reinstate port@0 to rsound
> - Drop iommus from SDHI2
> - Drop DU until it can be tested
Thanks for the update!
--- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a779md-geist.dts
> +&avb {
> + pinctrl-0 = <&avb_pins>;
> + pinctrl-names = "default";
> + phy-handle = <&phy0>;
> + tx-internal-delay-ps = <2000>;
> + status = "okay";
> +
> + phy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-id0022.1622";
> + rxc-skew-ps = <1500>;
> + reg = <0>;
> + interrupts-extended = <&gpio2 11 IRQ_TYPE_LEVEL_LOW>;
> + reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <100>;
10000?
> + reset-deassert-us = <100>;
300?
> + };
> +};
> +&pfc {
> + pwm2_pins: pwm2 {
> + groups = "pwm2_a";
> + function = "pwm2";
> + };
Shall I drop this while applying?
> +&pwm2 {
> + pinctrl-0 = <&pwm2_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
Shall I drop this while applying?
With the above fixed:
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 2/2] remoteproc: xlnx: enable auto boot feature
From: Mathieu Poirier @ 2026-05-22 15:46 UTC (permalink / raw)
To: tanmay.shah
Cc: andersson, robh, krzk+dt, conor+dt, michal.simek, ben.levinsky,
linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <cbd418a3-1585-4592-8e86-b0750e19ec0f@amd.com>
On Thu, May 21, 2026 at 01:38:57PM -0500, Shah, Tanmay wrote:
> Hello,
>
> Thank you for the reviews, please find my comments below:
>
> On 5/21/2026 12:48 PM, Mathieu Poirier wrote:
> > Good morning,
> >
> > I don't recal reviewing the first revision of this set. Can you provide a link
> > to it so that I can read the comments that were provided?
> >
>
> Here it is:
> https://lore.kernel.org/linux-remoteproc/20260422202558.2362971-1-tanmay.shah@amd.com/
>
> The device-tree bindings needed rework in v1, so I sent v2, before we
> ever reviewed the driver part.
>
>
> > On Fri, May 01, 2026 at 07:37:07AM -0700, Tanmay Shah wrote:
> >> remoteproc framework has capability to start (or attach to) the remote
> >
> > The remoteproc framework...
> >
>
> Ack.
>
> >> processor automatically if auto boot flag is set by the driver during
> >> probe. If remote core is not started before the Linux boot, and linux is
> >> expected to start the remote core then it uses "firmware-name" property
> >> to load default firmware during auto boot.
> >>
> >> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> >> ---
> >> drivers/remoteproc/xlnx_r5_remoteproc.c | 48 +++++++++++++++++--------
> >> 1 file changed, 34 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> index 45a62cb98072..652030f9cea2 100644
> >> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> >> @@ -899,17 +899,18 @@ static const struct rproc_ops zynqmp_r5_rproc_ops = {
> >> };
> >>
> >> /**
> >> - * zynqmp_r5_add_rproc_core() - Add core data to framework.
> >> - * Allocate and add struct rproc object for each r5f core
> >> + * zynqmp_r5_alloc_rproc_core() - alloc rproc core data structure
> >> + * Allocate struct rproc object for each r5f core
> >> * This is called for each individual r5f core
> >> *
> >> * @cdev: Device node of each r5 core
> >> *
> >> * Return: zynqmp_r5_core object for success else error code pointer
> >> */
> >> -static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> +static struct zynqmp_r5_core *zynqmp_r5_alloc_rproc_core(struct device *cdev)
> >
> > Why is there a need to change the function's name?
> >
>
> Before, the function was actually adding the rproc core by calling
> rproc_add() function, but now it only allocates the memory by calling
> rproc_alloc(). For auto boot to work it's important to add rproc core
> after all the other hw is initialized (such as mbox, tcm, sram,
> power-domains etc). More details below [1].
>
Ok
> >> {
> >> struct zynqmp_r5_core *r5_core;
> >> + const char *fw_name = NULL;
> >> struct rproc *r5_rproc;
> >> int ret;
> >>
> >> @@ -918,10 +919,15 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> if (ret)
> >> return ERR_PTR(ret);
> >>
> >> + ret = rproc_of_parse_firmware(cdev, 0, &fw_name);
> >> + if (ret < 0 && ret != -EINVAL)
> >> + return ERR_PTR(dev_err_probe(cdev, ret,
> >> + "failed to parse firmware-name\n"));
> >> +
> >> /* Allocate remoteproc instance */
> >> r5_rproc = rproc_alloc(cdev, dev_name(cdev),
> >> &zynqmp_r5_rproc_ops,
> >> - NULL, sizeof(struct zynqmp_r5_core));
> >> + fw_name, sizeof(struct zynqmp_r5_core));
> >> if (!r5_rproc) {
> >> dev_err(cdev, "failed to allocate memory for rproc instance\n");
> >> return ERR_PTR(-ENOMEM);
> >> @@ -932,6 +938,11 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> r5_rproc->recovery_disabled = true;
> >> r5_rproc->has_iommu = false;
> >> r5_rproc->auto_boot = false;
> >> +
> >> + /* attempt to boot automatically if the firmware-name is provided */
> >> + if (fw_name)
> >> + r5_rproc->auto_boot = true;
> >> +
> >
> > What happens when a firmware name needs to be provided in the DT but you don't
> > want to automatically boot the remote processor?
> >
>
> I think that use case is not needed. If the user/system-designer doesn't
> want auto-boot, then having firmware-name in the device-tree serves no
> purpose. User can always load the firmware via sysfs once kernel boots.
>
Ok
> >> r5_core = r5_rproc->priv;
> >> r5_core->dev = cdev;
> >> r5_core->np = dev_of_node(cdev);
> >> @@ -941,13 +952,6 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> >> goto free_rproc;
> >> }
> >>
> >> - /* Add R5 remoteproc core */
> >> - ret = rproc_add(r5_rproc);
> >> - if (ret) {
> >> - dev_err(cdev, "failed to add r5 remoteproc\n");
> >> - goto free_rproc;
> >> - }
> >> -
> >
> > I'm not sure why there is a need to move this to zynqmp_r5_cluster_init()? Is
> > it simply to make the error path easier to handle? If so, please do that in a
> > separate patch.
> >
>
> [1] This was moved to make auto-boot work. The remote core can auto-boot
> only after other hardware is initialized. The zynqmp_r5_core_init()
> initializes sram, TCM and power-domains of the core. Also, mailbox is
> requested before zynqmp_r5_core_init() as well. We can't auto-boot core
> directly without all this. So, I had to move rproc_add() at the end of
> the cluster init, and rename above function from
> zynqmp_r5_add_rproc_core to zynqmp_r5_alloc_rproc_core.
>
> If you prefer, I will add above explanation in the commit text, or as
> comment right before rproc_add().
>
Yes, please add that to the commit log.
>
>
> >> r5_core->rproc = r5_rproc;
> >> return r5_core;
> >>
> >> @@ -1280,6 +1284,7 @@ static int zynqmp_r5_core_init(struct zynqmp_r5_cluster *cluster,
> >> if (zynqmp_r5_get_rsc_table_va(r5_core))
> >> dev_dbg(r5_core->dev, "rsc tbl not found\n");
> >> r5_core->rproc->state = RPROC_DETACHED;
> >> + r5_core->rproc->auto_boot = true;
> >
> > I thought this was done in zynqmp_r5_add_rproc_core() - what am I missing?
> >
>
> That function is now zynqmp_r5_alloc_core() as mentioned above. Also,
> until now, auto_boot was set to 'false' only to show that it is
> disabled. It is actually used and enabled now.
>
Ok
> > Thanks,
> > Mathieu
> >
> >> }
> >> }
> >>
> >> @@ -1304,7 +1309,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> >> enum rpu_oper_mode fw_reg_val;
> >> struct device **child_devs;
> >> enum rpu_tcm_comb tcm_mode;
> >> - int core_count, ret, i;
> >> + int core_count, ret, i, j;
> >> struct mbox_info *ipi;
> >>
> >> ret = of_property_read_u32(dev_node, "xlnx,cluster-mode", &cluster_mode);
> >> @@ -1390,7 +1395,7 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> >> child_devs[i] = &child_pdev->dev;
> >>
> >> /* create and add remoteproc instance of type struct rproc */
> >> - r5_cores[i] = zynqmp_r5_add_rproc_core(&child_pdev->dev);
> >> + r5_cores[i] = zynqmp_r5_alloc_rproc_core(&child_pdev->dev);
> >> if (IS_ERR(r5_cores[i])) {
> >> ret = PTR_ERR(r5_cores[i]);
> >> r5_cores[i] = NULL;
> >> @@ -1435,16 +1440,31 @@ static int zynqmp_r5_cluster_init(struct zynqmp_r5_cluster *cluster)
> >> goto release_r5_cores;
> >> }
> >>
> >> + for (j = 0; j < cluster->core_count; j++) {
> >> + /* Add R5 remoteproc core */
> >> + ret = rproc_add(r5_cores[j]->rproc);
> >> + if (ret) {
> >> + dev_err_probe(r5_cores[j]->dev, ret,
> >> + "failed to add remoteproc\n");
> >> + goto delete_r5_cores;
> >> + }
> >> + }
> >> +
> >> kfree(child_devs);
> >> return 0;
> >>
> >> +delete_r5_cores:
> >> + i = core_count - 1;
> >> + /* delete previous added rproc */
> >> + while (--j >= 0)
> >> + rproc_del(r5_cores[j]->rproc);
> >> +
> >> release_r5_cores:
> >> while (i >= 0) {
> >> put_device(child_devs[i]);
> >> if (r5_cores[i]) {
> >> zynqmp_r5_free_mbox(r5_cores[i]->ipi);
> >> of_reserved_mem_device_release(r5_cores[i]->dev);
> >> - rproc_del(r5_cores[i]->rproc);
> >> rproc_free(r5_cores[i]->rproc);
> >> }
> >> i--;
> >> --
> >> 2.34.1
> >>
>
^ permalink raw reply
* Re: [PATCH 4/4] clk: add support for siflower sf21-topcrm
From: Yao Zi @ 2026-05-22 15:44 UTC (permalink / raw)
To: Chuanhong Guo
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, linux-riscv,
linux-kernel, linux-clk, devicetree
In-Reply-To: <CAJsYDVJZW2VYFaxzJRg2+CJZbvqq_iRXaf7+zYvidQn0AiviKQ@mail.gmail.com>
On Mon, May 18, 2026 at 09:34:17PM +0800, Chuanhong Guo wrote:
> Hi!
>
> On Mon, May 18, 2026 at 8:22 PM Yao Zi <me@ziyao.cc> wrote:
> >
> > On Sun, May 17, 2026 at 10:12:58PM +0800, Chuanhong Guo wrote:
...
> >
> > [...]
> >
> > Besides field/register offsets, the only difference I could tell between
> > cmnpll_postdiv and pciepll_fout is that pciepll_fout clocks could be
> > gated.
> >
> > Would it be a good idea to describe the gating function separately as a
> > clock, and merge the common part of pciepll_fout and cmnpll_postdiv? In
> > which way you could save a lot of mostly duplicated code.
>
> I don't think so. Since the majority of the existing code are register
> operations, and the register bit layout are completely different,
> there isn't much to share between these two PLLs.
> Writing a struct to describe both register layouts together seems
> unnecessarily complicated and harder to read.
I'm not suggesting merging the implementation of the two PLLs
themselves, but only the two types of clocks derived from them,
i.e. cmnpll_postdiv and pciepll_fout.
> BTW the CMNPLL and PCIEPLL are actually different hardware.
> The former is an integer PLL while the latter actually supports
> fractional operations. I didn't add support for the fractional part
> due to the lack of use cases and documentation. PCIE and GMAC
> clocks are fed by this PLL and require exact clock frequencies
> which can be achieved using only the integer mode.
>
> >
> > > + .recalc_rate = sf21_pciepll_fout_recalc_rate,
> > > + .determine_rate = sf21_pciepll_fout_determine_rate,
> > > + .set_rate = sf21_pciepll_fout_set_rate,
> > > +};
> > [...]
> > > +
> > > + spin_lock_irqsave(cmn_priv->lock, flags);
> > > + if (index)
> > > + sf_rmw(cmn_priv, mux_reg, 0, BIT(mux_offs));
> > > + else
> > > + sf_rmw(cmn_priv, mux_reg, BIT(mux_offs), 0);
> > > +
> > > + spin_unlock_irqrestore(cmn_priv->lock, flags);
> > > + return 0;
> > > +}
> >
> > I believe besides the divider reloading part, clk_mux_ops,
> > clk_divider_ops, and clk_gate_ops have already provided the logic
> > you implemented here. So it might be a better option to composite them
> > together to implement your clocks instead of building from scratch.
>
> The divider reloading is the exact reason I chose to not compose them
> with the function you mentioned. The reloading bit need to be set on
> both clock divider change and clock enabling, because the clock divider
> loading only happens when the clock is running. Since I already have
> to write two of the three parts you mentioned, trying to reuse
> clk_mux_ops doesn't seem to reduce the code complexity here.
You don't have to write divider/gate operations from scratch, but only
wrappers that first call clk_{divider,gate}_ops.* then trigger frequency
reloading.
> It's just trading get_parent and set_parent call with one more level
> in the clock tree for every clock and more code to wire them together
> in the probe function.
>
> >
> > > +static const struct clk_ops sf21_clk_muxdiv_ops = {
> > > + .enable = sf21_muxdiv_enable,
> > > + .disable = sf21_muxdiv_disable,
> > > + .is_enabled = sf21_muxdiv_is_enabled,
> > > + .recalc_rate = sf21_muxdiv_recalc_rate,
> > > + .determine_rate = sf21_muxdiv_determine_rate,
> > > + .set_rate = sf21_muxdiv_set_rate,
> > > + .get_parent = sf21_muxdiv_get_parent,
> > > + .set_parent = sf21_muxdiv_set_parent,
> > > +};
Regards,
Yao Zi
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: firmware: qcom,scm: Add minidump SRAM property
From: Mukesh Ojha @ 2026-05-22 15:43 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <04465873-17bd-4c84-ad51-29e648a88b4c@kernel.org>
On Fri, May 22, 2026 at 11:15:22AM +0200, Krzysztof Kozlowski wrote:
> On 22/05/2026 09:52, Mukesh Ojha wrote:
> > On Wed, May 20, 2026 at 12:17:21PM +0200, Krzysztof Kozlowski wrote:
> >> On Tue, May 19, 2026 at 10:44:39PM +0530, Mukesh Ojha wrote:
> >>> On most Qualcomm SoCs where minidump is supported, a word in always-on
> >>> SRAM is shared between the kernel and boot firmware. Before DDR is
> >>> initialised on the warm reset following a crash, firmware reads this
> >>> word to decide if minidump is enabled and collect a minidump and where
> >>> to deliver it (USB upload to a host, or save to local storage).
> >>>
> >>> Add a 'sram' property to the SCM binding to describe a region in
> >>> always-on SRAM where the minidump download destination value could be
> >>> written. Boot firmware reads it before DDR is initialised on a warm
> >>> reset to decide where to store the minidump either to host PC or to
> >>> on device storage.
> >>>
> >>> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> >>> ---
> >>> .../devicetree/bindings/firmware/qcom,scm.yaml | 16 ++++++++++++++++
> >>> 1 file changed, 16 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>> index 25f62bacbc91..27422d00b8fc 100644
> >>> --- a/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>> +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.yaml
> >>> @@ -129,6 +129,13 @@ properties:
> >>> - description: offset of the download mode control register
> >>> description: TCSR hardware block
> >>>
> >>> + sram:
> >>> + description:
> >>> + Phandle to a region in always-on SRAM used to store the download
> >>> + mode value for boot firmware to read before DDR is initialised on
> >>> + the next warm reset.
> >>> + maxItems: 1
> >>> +
> >>> allOf:
> >>> # Clocks
> >>> - if:
> >>> @@ -250,3 +257,12 @@ examples:
> >>> clock-names = "core", "bus", "iface";
> >>> };
> >>> };
> >>> +
> >>> + - |
> >>> + firmware {
> >>> + scm {
> >>> + compatible = "qcom,scm-kaanapali", "qcom,scm";
> >>
> >> Incomplete, missing interrupts.
> >
> > Interrupt number comes from firmware and has not even been described
> > statically for SCM for any SoC and so I am not sure to include it in
> > the example. Perhaps I took the wrong example here and should have taken
> > some pre-Gunyah Qualcomm SoC.
>
> Then you do not need a new example. Difference in one property (reset
> cells) does not justify new example.
Sure, will drop it.
>
> Best regards,
> Krzysztof
--
-Mukesh Ojha
^ permalink raw reply
* [PATCH v6 10/10] ARM: multi_v7_defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards.
Enabling this in the multi_v7_defconfg allows standard upstream kernels
to use these registers out of the box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc12028..4b61ad5f46ce7 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1281,6 +1281,7 @@ CONFIG_NVMEM_ROCKCHIP_EFUSE=m
CONFIG_NVMEM_STM32_ROMEM=m
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_VF610_OCOTP=y
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_FSI=m
CONFIG_FSI_MASTER_GPIO=m
CONFIG_FSI_MASTER_HUB=m
--
2.47.3
^ permalink raw reply related
* [PATCH v6 09/10] ARM: bcm2835_defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
Enable the newly added Raspberry Pi OTP driver as module to allow access
to the otp registers. This driver provides access to the OTP registers
present on all Raspberry Pi boards.
Enabling this in the bcm2835 defconfig allows standard upstream kernels
to use these registers out of the box.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm/configs/bcm2835_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/bcm2835_defconfig b/arch/arm/configs/bcm2835_defconfig
index 4a8ac09843d73..fd83bda9cfaaf 100644
--- a/arch/arm/configs/bcm2835_defconfig
+++ b/arch/arm/configs/bcm2835_defconfig
@@ -151,6 +151,8 @@ CONFIG_BCM2835_MBOX=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_PWM=y
CONFIG_PWM_BCM2835=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
--
2.47.3
^ permalink raw reply related
* [PATCH v6 07/10] dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
From: Gregor Herburger @ 2026-05-22 15:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh, Russell King
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley, Gregor Herburger
In-Reply-To: <20260522-rpi-otp-driver-v6-0-b0eac97d1428@linutronix.de>
The "select" in schema is not necessary anymore since dtschema drops
simple-mfd when constructing the select/filter query for schemas with
compatibles.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a3a5243b91706..7cf9a6fa1e5be 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -10,15 +10,6 @@ maintainers:
- Eric Anholt <eric@anholt.net>
- Stefan Wahren <wahrenst@gmx.net>
-select:
- properties:
- compatible:
- contains:
- const: raspberrypi,bcm2835-firmware
-
- required:
- - compatible
-
properties:
compatible:
oneOf:
--
2.47.3
^ permalink raw reply related
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