* [PATCH 10/18] arm64: dts: ti: k3-j722s-evm: Add overlay for fusion application daughter board
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fusion application daughter board [1] can be used to connect multiple
FPDLink-III based sensors to TI EVMs. The board has two DS90UB960
deserializers, each of which aggregates input from up to 4x FPDLink-III
sensors. Up to 8x sensors can simultaneously stream over the two CSI RX
ports on J722S EVM.
[1]: https://svtronics.com/product/fusion-application-daughter-board-evm577pfusion-v1-0/?srsltid=AfmBOooMsRAd5ibFOGJaKbjsC3j9-loTPK2wWqsqPq2Adj55g1nPluxX
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../dts/ti/k3-j722s-evm-fpdlink-fusion.dtso | 196 ++++++++++++++++++
2 files changed, 200 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-evm-fpdlink-fusion.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index b31bf2f305aa..cb16eb9039aa 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -173,6 +173,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-fpdlink-fusion.dtbo
# Boards with J784s4 SoC
dtb-$(CONFIG_ARCH_K3) += k3-am69-aquila-clover.dtb
@@ -301,6 +302,8 @@ k3-j722s-evm-csi2-quad-rpi-cam-imx219-dtbs := k3-j722s-evm.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
k3-j722s-evm-csi2-quad-tevi-ov5640-dtbs := k3-j722s-evm.dtb \
k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
+k3-j722s-evm-fpdlink-fusion-dtbs := k3-j722s-evm.dtb \
+ k3-j722s-evm-fpdlink-fusion.dtbo
k3-j742s2-evm-usb0-type-a-dtbs := k3-j742s2-evm.dtb \
k3-j784s4-j742s2-evm-usb0-type-a.dtbo
k3-j784s4-evm-fpdlink-fusion-dtbs := k3-j784s4-evm.dtb \
@@ -371,6 +374,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtb \
k3-j722s-evm-csi2-quad-tevi-ov5640.dtb \
+ k3-j722s-evm-fpdlink-fusion.dtb \
k3-j742s2-evm-usb0-type-a.dtb \
k3-j784s4-evm-fpdlink-fusion.dtb \
k3-j784s4-evm-pcie0-pcie1-ep.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm-fpdlink-fusion.dtso b/arch/arm64/boot/dts/ti/k3-j722s-evm-fpdlink-fusion.dtso
new file mode 100644
index 000000000000..cbad2409a9c1
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j722s-evm-fpdlink-fusion.dtso
@@ -0,0 +1,196 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT Overlay for Fusion (FPD-Link III) board on J721E EVM
+ * https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ clk_fusion_25M_fixed: fixed-clock-25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+
+&pca9543_0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ ds90ub960_0_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ ds90ub960_0_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ deser@36 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x36>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x5a 0x5b 0x5c 0x5d 0x5e 0x5f>;
+
+ ds90ub960_1_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_1_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy1>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ ds90ub960_1_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy0: endpoint {
+ remote-endpoint = <&ds90ub960_0_csi_out>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy1: endpoint {
+ remote-endpoint = <&ds90ub960_1_csi_out>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 11/18] arm64: dts: ti: k3-am68-sk: Add overlay for dual Arducam V3link fusion
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Arducam's V3Link mini fusion board [1] has a single DS90UB960
deserializer which can aggregate input from up to 4x V3Link (and
FPD-Link III) based cameras over a single 22-pin FFC (4-lane) CSI-2
connector. Add an overlay supporting two such boards, each connected to
one of the two CSI RX inputs on AM68-SK.
The same overlay can be reused on AM69-SK and J721E-SK.
[1] https://www.arducam.com/downloads/datasheet/Arducam_V3Link_Datasheet.pdf
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 10 +
.../boot/dts/ti/k3-am68-sk-v3link-fusion.dtso | 204 ++++++++++++++++++
2 files changed, 214 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am68-sk-v3link-fusion.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index cb16eb9039aa..b14c9a8c94b9 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -160,6 +160,7 @@ k3-am68-phyboard-izar-peb-av-15-dtbs := k3-am68-phyboard-izar.dtb \
k3-am68-phyboard-izar-peb-av-15.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am68-sk-base-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am68-sk-base-board-pcie1-ep.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am68-sk-v3link-fusion.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-fusion.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
@@ -272,12 +273,16 @@ k3-am68-sk-base-board-pcie1-ep-dtbs := k3-am68-sk-base-board.dtb \
k3-am68-sk-base-board-pcie1-ep.dtbo
k3-am68-sk-fpdlink-fusion-dtbs := k3-am68-sk-base-board.dtb \
k3-j721e-sk-fpdlink-fusion.dtbo
+k3-am68-sk-v3link-fusion-dtbs := k3-am68-sk-base-board.dtb \
+ k3-am68-sk-v3link-fusion.dtbo
k3-am69-sk-csi2-dual-imx219-dtbs := k3-am69-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
k3-am69-sk-fpdlink-fusion-dtbs := k3-am69-sk.dtb \
k3-j721e-sk-fpdlink-fusion.dtbo
k3-am69-sk-pcie0-ep-dtbs := k3-am69-sk.dtb \
k3-am69-sk-pcie0-ep.dtbo
+k3-am69-sk-v3link-fusion-dtbs := k3-am69-sk.dtb \
+ k3-am68-sk-v3link-fusion.dtbo
k3-j7200-evm-pcie1-ep-dtbs := k3-j7200-common-proc-board.dtb \
k3-j7200-evm-pcie1-ep.dtbo
k3-j721e-common-proc-board-infotainment-dtbs := k3-j721e-common-proc-board.dtb \
@@ -292,6 +297,8 @@ k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
k3-j721e-sk-fpdlink-fusion-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-fpdlink-fusion.dtbo
+k3-j721e-sk-v3link-fusion-dtbs := k3-j721e-sk.dtb \
+ k3-am68-sk-v3link-fusion.dtbo
k3-j721s2-evm-fpdlink-fusion-dtbs := k3-j721s2-evm.dtb \
k3-j721s2-evm-fusion.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -359,9 +366,11 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am68-sk-base-board-csi2-dual-imx219.dtb \
k3-am68-sk-base-board-pcie1-ep.dtb \
k3-am68-sk-fpdlink-fusion.dtb \
+ k3-am68-sk-v3link-fusion.dtb \
k3-am69-sk-csi2-dual-imx219.dtb \
k3-am69-sk-fpdlink-fusion.dtb \
k3-am69-sk-pcie0-ep.dtb \
+ k3-am69-sk-v3link-fusion.dtb \
k3-j7200-evm-pcie1-ep.dtb \
k3-j721e-common-proc-board-infotainment.dtb \
k3-j721e-evm-fpdlink-fusion.dtb \
@@ -369,6 +378,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
k3-j721e-sk-fpdlink-fusion.dtb \
+ k3-j721e-sk-v3link-fusion.dtb \
k3-j721s2-evm-fpdlink-fusion.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am68-sk-v3link-fusion.dtso b/arch/arm64/boot/dts/ti/k3-am68-sk-v3link-fusion.dtso
new file mode 100644
index 000000000000..cfbf59c45782
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am68-sk-v3link-fusion.dtso
@@ -0,0 +1,204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT Overlay for Arducam V3Link UC-A09 board
+ * https://www.arducam.com/fpd-link-3-cameras/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+ clk_fusion_25M_fixed: fixed-clock-25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+&csi_mux {
+ idle-state = <1>;
+};
+
+&cam0_i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ deser@30 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x30>;
+
+ clock-names = "refclk";
+ clocks = <&clk_fusion_25M_fixed>;
+
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ deserializer_0_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ clock-lanes = <0>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_0_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&cam1_i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ deser@30 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x30>;
+
+ clock-names = "refclk";
+ clocks = <&clk_fusion_25M_fixed>;
+
+ i2c-alias-pool = <0x5a 0x5b 0x5c 0x5d 0x5e 0x5f>;
+
+ deserializer_1_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_1_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ clock-lanes = <0>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy1>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_1_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy0: endpoint {
+ remote-endpoint = <&ds90ub960_0_csi_out>;
+ bus-type = <4>; /* CSI2 DPHY. */
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy1: endpoint {
+ remote-endpoint = <&ds90ub960_1_csi_out>;
+ bus-type = <4>; /* CSI2 DPHY. */
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 08/18] arm64: dts: ti: k3-j721s2: Add overlay for fusion application daughter board
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fusion application daughter board [1] can be used to connect multiple
FPDLink-III based sensors to TI EVMs. The board has two DS90UB960
deserializers, each of which aggregates input from up to 4x FPDLink-III
sensors. Up to 8x sensors can simultaneously stream over the two CSI RX
ports on J721S2.
CSI2RX connectivity on J784S4 and J742S2 is the same as that of J721S2,
hence the same overlay can be reused.
[1]: https://svtronics.com/product/fusion-application-daughter-board-evm577pfusion-v1-0/?srsltid=AfmBOooMsRAd5ibFOGJaKbjsC3j9-loTPK2wWqsqPq2Adj55g1nPluxX
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 7 +
.../boot/dts/ti/k3-j721s2-evm-fusion.dtso | 191 ++++++++++++++++++
2 files changed, 198 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-fusion.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 7e2ed5c94e79..79ce2ff38cc3 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -160,6 +160,7 @@ k3-am68-phyboard-izar-peb-av-15-dtbs := k3-am68-phyboard-izar.dtb \
dtb-$(CONFIG_ARCH_K3) += k3-am68-sk-base-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am68-sk-base-board-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-fusion.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
@@ -283,6 +284,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721s2-evm-fpdlink-fusion-dtbs := k3-j721s2-evm.dtb \
+ k3-j721s2-evm-fusion.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
k3-j721s2-evm-pcie1-ep.dtbo
k3-j721s2-evm-usb0-type-a-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -293,6 +296,8 @@ k3-j722s-evm-csi2-quad-tevi-ov5640-dtbs := k3-j722s-evm.dtb \
k3-j722s-evm-csi2-quad-tevi-ov5640.dtbo
k3-j742s2-evm-usb0-type-a-dtbs := k3-j742s2-evm.dtb \
k3-j784s4-j742s2-evm-usb0-type-a.dtbo
+k3-j784s4-evm-fpdlink-fusion-dtbs := k3-j784s4-evm.dtb \
+ k3-j721s2-evm-fusion.dtbo
k3-j784s4-evm-pcie0-pcie1-ep-dtbs := k3-j784s4-evm.dtb \
k3-j784s4-evm-pcie0-pcie1-ep.dtbo
k3-j784s4-evm-quad-port-eth-exp1-dtbs := k3-j784s4-evm.dtb \
@@ -351,11 +356,13 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721s2-evm-fpdlink-fusion.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtb \
k3-j722s-evm-csi2-quad-tevi-ov5640.dtb \
k3-j742s2-evm-usb0-type-a.dtb \
+ k3-j784s4-evm-fpdlink-fusion.dtb \
k3-j784s4-evm-pcie0-pcie1-ep.dtb \
k3-j784s4-evm-quad-port-eth-exp1.dtb \
k3-j784s4-evm-usb0-type-a.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-fusion.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-fusion.dtso
new file mode 100644
index 000000000000..f200cdaa1bab
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-fusion.dtso
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT Overlay for Fusion (FPD-Link III) board on J721S2 and J784S4 EVM
+ * https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ clk_fusion_25M_fixed: fixed-clock-25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+
+&main_i2c5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ deserializer_0_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_0_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ deser@36 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x36>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x5a 0x5b 0x5c 0x5d 0x5e 0x5f>;
+
+ deserializer_1_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_1_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy1>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_1_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy0: endpoint {
+ remote-endpoint = <&ds90ub960_0_csi_out>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy1: endpoint {
+ remote-endpoint = <&ds90ub960_1_csi_out>;
+ bus-type = <4>; /* CSI2 DPHY */
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 05/18] arm64: dts: ti: k3-am62p-j722s: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts,
Add additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
index f130c7cb998d..ecb537b96fca 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
@@ -1053,8 +1053,10 @@ ti_csi2rx0: ticsi2rx@30102000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x5000 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x5000 0>, <&main_bcdma_csi 0 0x5001 0>,
+ <&main_bcdma_csi 0 0x5002 0>, <&main_bcdma_csi 0 0x5003 0>,
+ <&main_bcdma_csi 0 0x5004 0>, <&main_bcdma_csi 0 0x5005 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5";
power-domains = <&k3_pds 182 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 06/18] arm64: dts: ti: k3-j722s-main: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts,
Add additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Tested-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
index d1dbf1e24fbf..98d2090c4c9c 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s-main.dtsi
@@ -173,8 +173,9 @@ ti_csi2rx1: ticsi2rx@30122000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x5100 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x5100 0>, <&main_bcdma_csi 0 0x5101 0>,
+ <&main_bcdma_csi 0 0x5102 0>, <&main_bcdma_csi 0 0x5103 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3";
power-domains = <&k3_pds 247 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -230,8 +231,9 @@ ti_csi2rx2: ticsi2rx@30142000 {
#address-cells = <2>;
#size-cells = <2>;
power-domains = <&k3_pds 248 TI_SCI_PD_EXCLUSIVE>;
- dmas = <&main_bcdma_csi 0 0x5200 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x5200 0>, <&main_bcdma_csi 0 0x5201 0>,
+ <&main_bcdma_csi 0 0x5202 0>, <&main_bcdma_csi 0 0x5203 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3";
status = "disabled";
cdns_csi2rx2: csi-bridge@30141000 {
@@ -285,8 +287,9 @@ ti_csi2rx3: ticsi2rx@30162000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x5300 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x5300 0>, <&main_bcdma_csi 0 0x5301 0>,
+ <&main_bcdma_csi 0 0x5302 0>, <&main_bcdma_csi 0 0x5303 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3";
power-domains = <&k3_pds 249 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 00/18] Add DT support for CSI2RX multi-stream
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
Driver support for CSI2RX multi-stream was merged last cycle[0]. This
series adds the corresponding device tree support.
Patch 1 is a cleanup fixing indentation in the existing CSI2RX nodes.
The next few patches i.e. (Patch 2 to Patch 6) add the additional DMA
channels required for CSI2RX multi-stream capture.
Multi-stream capture uses a SERDES pair based on the FPD-Link or
V3Link protocol. The serializer takes the input from a camera sensor
and converts it to the FPD-Link standard, while the deserializer
aggregates streams from multiple serializers and sends them over the
CSI-2 RX interface. Each CSI2RX instance therefore indirectly receives
input from multiple sensors.
The remaining patches add overlays for various deserializer boards,
and for the UB953 serializer with the IMX219 sensor. Also enabling
DS90UB960 deserializer and DS90UB953 serializer drivers in the
arm64 defconfig.
Testlogs:
J721E + Fusion application daughter board: https://gist.github.com/Yemike-Abhilash-Chandra/341cea78c93a5849a9b318a5fa1ad5b2
J721S2 + Fusion application daughter board: https://gist.github.com/Yemike-Abhilash-Chandra/e676bda929ae940f9c85e8dd3d03f644
J784s4s + Fusion application daughter board: https://gist.github.com/Yemike-Abhilash-Chandra/e69f077af78468b9e5dfc20b9bdef374
AM68 + Fusion application daughter board: https://gist.github.com/Yemike-Abhilash-Chandra/aa913e3533b227a477d6363c04692474
J721E + DS90UB954-Q1EVM: https://gist.github.com/Yemike-Abhilash-Chandra/f1bfaa7f62b185c492a81659100a9c02
J721S2 + DS90UB954-Q1EVM: https://gist.github.com/Yemike-Abhilash-Chandra/15dda67fffc542d30bcc3a83dd7d5782
J784s4s + J7EXPA01EVM Fusion2: https://gist.github.com/Yemike-Abhilash-Chandra/22a74bae79c1fc7eb92d158fc1ee81b5
AM68 + Arducam V3link: https://gist.github.com/Yemike-Abhilash-Chandra/8188ac234b21406f336032c14c9fa9d4
J722S + Arducam V3link: https://gist.github.com/Yemike-Abhilash-Chandra/24d49bd30ba3a499ff7c93fa4d5cc1ad
(grep for "ds90ub960" for the deserializer logs and "ds90ub953" for the serializer.
grep for "running tests" to see the actual test pattern genertaion capture logs from
the sensor over the SERDES)
dtbs_check: make CONFIG_OF_ALL_DTBS=y dtstree=arch/arm64/boot/dts/ti dtbs_check gives no errors
Branch: https://github.com/Yemike-Abhilash-Chandra/linux/tree/CSI_MT_DT_V3
[0]: https://lore.kernel.org/all/20260520120022.539913-1-r-donadkar@ti.com/
Jianzhong Xu (1):
arm64: dts: ti: k3-v3link: Add overlay for IMX219+UB953 serializer
Vaishnav Achath (13):
arm64: dts: ti: k3-{j721e/j721s2}-main: Fix indentation in CSI2RX node
arm64: dts: ti: k3-j721e-main: Add multiple channels for CSI2RX DMA
arm64: dts: ti: k3-j721s2-main: Add multiple channels for CSI2RX DMA
arm64: dts: ti: k3-j784s4-j742s2-main-common: Add multiple channels
for CSI2RX DMA
arm64: dts: ti: k3-am62p-j722s: Add multiple channels for CSI2RX DMA
arm64: dts: ti: k3-j722s-main: Add multiple channels for CSI2RX DMA
arm64: dts: ti: k3-j721e: Add overlay for fusion application daughter
board
arm64: dts: ti: k3-j721s2: Add overlay for fusion application daughter
board
arm64: dts: ti: k3-j721e-sk: Add overlay for fusion application
daughter board
arm64: dts: ti: k3-j722s-evm: Add overlay for fusion application
daughter board
arm64: dts: ti: k3-am68-sk: Add overlay for dual Arducam V3link fusion
arm64: dts: ti: k3-j722s-evm: Add overlay for dual Arducam V3link
fusion
arm64: dts: ti: k3-j784s4-evm: Add overlay for J7EXPA01EVM Fusion2
Yemike Abhilash Chandra (4):
arm64: dts: ti: k3-j722s-evm: Add overlay for J7EXPA01EVM Fusion2
arm64: dts: ti: k3-j721s2: Add overlay for DS90UB954-Q1EVM
arm64: dts: ti: k3-j721e: Add overlay for DS90UB954-Q1EVM
arm64: defconfig: Enable DS90UB960 deserializer and DS90UB953
serializer
arch/arm64/boot/dts/ti/Makefile | 62 ++++
.../dts/ti/k3-am62p-j722s-common-main.dtsi | 6 +-
.../boot/dts/ti/k3-am68-sk-v3link-fusion.dtso | 204 ++++++++++++
.../boot/dts/ti/k3-j721e-evm-fusion.dtso | 191 +++++++++++
.../arm64/boot/dts/ti/k3-j721e-evm-ub954.dtso | 93 ++++++
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 24 +-
.../dts/ti/k3-j721e-sk-fpdlink-fusion.dtso | 191 +++++++++++
.../boot/dts/ti/k3-j721s2-evm-fusion.dtso | 191 +++++++++++
.../boot/dts/ti/k3-j721s2-evm-ub954.dtso | 93 ++++++
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 22 +-
.../dts/ti/k3-j722s-evm-fpdlink-fusion.dtso | 196 ++++++++++++
.../ti/k3-j722s-evm-fpdlink-iv-fusion.dtso | 296 ++++++++++++++++++
.../dts/ti/k3-j722s-evm-v3link-fusion.dtso | 213 +++++++++++++
arch/arm64/boot/dts/ti/k3-j722s-main.dtsi | 15 +-
.../ti/k3-j784s4-evm-fpdlink-iv-fusion.dtso | 281 +++++++++++++++++
.../dts/ti/k3-j784s4-j742s2-main-common.dtsi | 21 +-
.../boot/dts/ti/k3-v3link-imx219-0-0.dtso | 127 ++++++++
arch/arm64/configs/defconfig | 2 +
18 files changed, 2200 insertions(+), 28 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-am68-sk-v3link-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-ub954.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-ub954.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-evm-fpdlink-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-evm-fpdlink-iv-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-evm-v3link-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm-fpdlink-iv-fusion.dtso
create mode 100644 arch/arm64/boot/dts/ti/k3-v3link-imx219-0-0.dtso
--
2.34.1
^ permalink raw reply
* [PATCH 09/18] arm64: dts: ti: k3-j721e-sk: Add overlay for fusion application daughter board
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fusion application daughter board [1] can be used to connect multiple
FPDLink-III based sensors to TI EVMs. The board has two DS90UB960
deserializers, each of which aggregates input from up to 4x FPDLink-III
sensors. Up to 8x sensors can simultaneously stream over the two CSI RX
ports on J721E SK.
CSI2RX connectivity on AM68-SK and AM69-SK is the same as that of J721E-SK,
hence the same overlay can be reused.
[1]: https://svtronics.com/product/fusion-application-daughter-board-evm577pfusion-v1-0/?srsltid=AfmBOooMsRAd5ibFOGJaKbjsC3j9-loTPK2wWqsqPq2Adj55g1nPluxX
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 10 +
.../dts/ti/k3-j721e-sk-fpdlink-fusion.dtso | 191 ++++++++++++++++++
2 files changed, 201 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 79ce2ff38cc3..b31bf2f305aa 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -148,6 +148,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk-csi2-dual-imx219.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-j721e-sk-fpdlink-fusion.dtbo
# Boards with J721s2 SoC
dtb-$(CONFIG_ARCH_K3) += k3-am68-phyboard-izar.dtb
@@ -268,8 +269,12 @@ k3-am68-sk-base-board-csi2-dual-imx219-dtbs := k3-am68-sk-base-board.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
k3-am68-sk-base-board-pcie1-ep-dtbs := k3-am68-sk-base-board.dtb \
k3-am68-sk-base-board-pcie1-ep.dtbo
+k3-am68-sk-fpdlink-fusion-dtbs := k3-am68-sk-base-board.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtbo
k3-am69-sk-csi2-dual-imx219-dtbs := k3-am69-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-am69-sk-fpdlink-fusion-dtbs := k3-am69-sk.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtbo
k3-am69-sk-pcie0-ep-dtbs := k3-am69-sk.dtb \
k3-am69-sk-pcie0-ep.dtbo
k3-j7200-evm-pcie1-ep-dtbs := k3-j7200-common-proc-board.dtb \
@@ -284,6 +289,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721e-sk-fpdlink-fusion-dtbs := k3-j721e-sk.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtbo
k3-j721s2-evm-fpdlink-fusion-dtbs := k3-j721s2-evm.dtb \
k3-j721s2-evm-fusion.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -348,7 +355,9 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am68-phyboard-izar-peb-av-15.dtb \
k3-am68-sk-base-board-csi2-dual-imx219.dtb \
k3-am68-sk-base-board-pcie1-ep.dtb \
+ k3-am68-sk-fpdlink-fusion.dtb \
k3-am69-sk-csi2-dual-imx219.dtb \
+ k3-am69-sk-fpdlink-fusion.dtb \
k3-am69-sk-pcie0-ep.dtb \
k3-j7200-evm-pcie1-ep.dtb \
k3-j721e-common-proc-board-infotainment.dtb \
@@ -356,6 +365,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721e-sk-fpdlink-fusion.dtb \
k3-j721s2-evm-fpdlink-fusion.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso b/arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso
new file mode 100644
index 000000000000..dd82ec3accfe
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721e-sk-fpdlink-fusion.dtso
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT Overlay for Fusion (FPD-Link III) board on J721E SK,
+ * AM68 SK or AM69 SK.
+ * https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/
+ *
+ * Copyright (C) 2023 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ clk_fusion_25M_fixed: fixed-clock-25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+
+&cam0_i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ deserializer_0_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX*/
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_0_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ deser@36 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x36>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x5a 0x5b 0x5c 0x5d 0x5e 0x5f>;
+
+ deserializer_1_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX*/
+ port@4 {
+ reg = <4>;
+ ds90ub960_1_csi_out: endpoint {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy1>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_1_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy0: endpoint {
+ remote-endpoint = <&ds90ub960_0_csi_out>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy1: endpoint {
+ remote-endpoint = <&ds90ub960_1_csi_out>;
+ bus-type = <4>; /* CSI2 DPHY */
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 07/18] arm64: dts: ti: k3-j721e: Add overlay for fusion application daughter board
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fusion application daughter board [1] can be used to connect multiple
FPDLink-III based sensors to TI EVMs. The board has two DS90UB960
deserializers, each of which aggregates input from up to 4x FPDLink-III
sensors. Up to 8x sensors can simultaneously stream over the two CSI RX
ports on J721E.
[1]: https://svtronics.com/product/fusion-application-daughter-board-evm577pfusion-v1-0/?srsltid=AfmBOooMsRAd5ibFOGJaKbjsC3j9-loTPK2wWqsqPq2Adj55g1nPluxX
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721e-evm-fusion.dtso | 191 ++++++++++++++++++
2 files changed, 195 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 21db60cd19de..7e2ed5c94e79 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -141,6 +141,7 @@ k3-j721e-evm-gesi-dtbs := k3-j721e-common-proc-board.dtb k3-j721e-evm-gesi-exp-b
dtb-$(CONFIG_ARCH_K3) += k3-j721e-beagleboneai64.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board-infotainment.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-fusion.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-gesi.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721e-evm-pcie0-ep.dtbo
@@ -274,6 +275,8 @@ k3-j7200-evm-pcie1-ep-dtbs := k3-j7200-common-proc-board.dtb \
k3-j7200-evm-pcie1-ep.dtbo
k3-j721e-common-proc-board-infotainment-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-common-proc-board-infotainment.dtbo
+k3-j721e-evm-fpdlink-fusion-dtbs := k3-j721e-evm.dtb \
+ k3-j721e-evm-fusion.dtbo
k3-j721e-evm-pcie0-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie0-ep.dtbo
k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
@@ -344,6 +347,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am69-sk-pcie0-ep.dtb \
k3-j7200-evm-pcie1-ep.dtb \
k3-j721e-common-proc-board-infotainment.dtb \
+ k3-j721e-evm-fpdlink-fusion.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso b/arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso
new file mode 100644
index 000000000000..0df2e48a4089
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721e-evm-fusion.dtso
@@ -0,0 +1,191 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DT Overlay for Fusion (FPD-Link III) board on J721E EVM
+ * https://svtronics.com/portfolio/evm577pfusion-v1-0-fusion/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+&{/} {
+ clk_fusion_25M_fixed: fixed-clock-25M {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+};
+
+
+&main_i2c6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ deser@3d {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x3d>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x4a 0x4b 0x4c 0x4d 0x4e 0x4f>;
+
+ deserializer_0_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_0_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ clock-lanes = <0>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy0>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_0_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ deser@36 {
+ compatible = "ti,ds90ub960-q1";
+ reg = <0x36>;
+ clocks = <&clk_fusion_25M_fixed>;
+ clock-names = "refclk";
+ i2c-alias-pool = <0x5a 0x5b 0x5c 0x5d 0x5e 0x5f>;
+
+ deserializer_1_ports: ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0{
+ reg= <0>;
+ status = "disabled";
+ };
+
+ port@1{
+ reg= <1>;
+ status = "disabled";
+ };
+
+ port@2{
+ reg= <2>;
+ status = "disabled";
+ };
+
+ port@3{
+ reg= <3>;
+ status = "disabled";
+ };
+
+ /* CSI-2 TX */
+ port@4 {
+ reg = <4>;
+ ds90ub960_1_csi_out: endpoint {
+ data-lanes = <1 2 3 4>;
+ clock-lanes = <0>;
+ link-frequencies = /bits/ 64 <800000000>;
+ remote-endpoint = <&csi2_phy1>;
+ };
+ };
+
+ port@5{
+ reg= <5>;
+ status = "disabled";
+ };
+ };
+
+ deserializer_1_links: links {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
+
+&cdns_csi2rx0 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi0_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy0: endpoint {
+ remote-endpoint = <&ds90ub960_0_csi_out>;
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+
+ };
+ };
+ };
+};
+
+&cdns_csi2rx1 {
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_port0: port@0 {
+ reg = <0>;
+ status = "okay";
+
+ csi2_phy1: endpoint {
+ remote-endpoint = <&ds90ub960_1_csi_out>;
+ bus-type = <4>; /* CSI2 DPHY */
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <800000000>;
+ };
+ };
+ };
+};
+
+&ti_csi2rx0 {
+ status = "okay";
+};
+
+&dphy0 {
+ status = "okay";
+};
+
+&ti_csi2rx1 {
+ status = "okay";
+};
+
+&dphy1 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH 04/18] arm64: dts: ti: k3-j784s4-j742s2-main-common: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts,
Add additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
.../dts/ti/k3-j784s4-j742s2-main-common.dtsi | 21 +++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
index c2636e624f18..4b4545a5af19 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
@@ -811,8 +811,11 @@ ti_csi2rx0: ticsi2rx@4500000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4940 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4940 0>, <&main_bcdma_csi 0 0x4941 0>,
+ <&main_bcdma_csi 0 0x4942 0>, <&main_bcdma_csi 0 0x4943 0>,
+ <&main_bcdma_csi 0 0x4944 0>, <&main_bcdma_csi 0 0x4945 0>,
+ <&main_bcdma_csi 0 0x4946 0>, <&main_bcdma_csi 0 0x4947 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 72 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -867,8 +870,11 @@ ti_csi2rx1: ticsi2rx@4510000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4960 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4960 0>, <&main_bcdma_csi 0 0x4961 0>,
+ <&main_bcdma_csi 0 0x4962 0>, <&main_bcdma_csi 0 0x4963 0>,
+ <&main_bcdma_csi 0 0x4964 0>, <&main_bcdma_csi 0 0x4965 0>,
+ <&main_bcdma_csi 0 0x4966 0>, <&main_bcdma_csi 0 0x4967 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 73 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -922,8 +928,11 @@ ti_csi2rx2: ticsi2rx@4520000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4980 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4980 0>, <&main_bcdma_csi 0 0x4981 0>,
+ <&main_bcdma_csi 0 0x4982 0>, <&main_bcdma_csi 0 0x4983 0>,
+ <&main_bcdma_csi 0 0x4984 0>, <&main_bcdma_csi 0 0x4985 0>,
+ <&main_bcdma_csi 0 0x4986 0>, <&main_bcdma_csi 0 0x4987 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 74 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 03/18] arm64: dts: ti: k3-j721s2-main: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts. Add
additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index 5cac119e4292..f4b8713873b1 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -1239,8 +1239,11 @@ ti_csi2rx0: ticsi2rx@4500000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4940 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4940 0>, <&main_bcdma_csi 0 0x4941 0>,
+ <&main_bcdma_csi 0 0x4942 0>, <&main_bcdma_csi 0 0x4943 0>,
+ <&main_bcdma_csi 0 0x4944 0>, <&main_bcdma_csi 0 0x4945 0>,
+ <&main_bcdma_csi 0 0x4946 0>, <&main_bcdma_csi 0 0x4947 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 38 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -1295,8 +1298,11 @@ ti_csi2rx1: ticsi2rx@4510000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_bcdma_csi 0 0x4960 0>;
- dma-names = "rx0";
+ dmas = <&main_bcdma_csi 0 0x4960 0>, <&main_bcdma_csi 0 0x4961 0>,
+ <&main_bcdma_csi 0 0x4962 0>, <&main_bcdma_csi 0 0x4963 0>,
+ <&main_bcdma_csi 0 0x4964 0>, <&main_bcdma_csi 0 0x4965 0>,
+ <&main_bcdma_csi 0 0x4966 0>, <&main_bcdma_csi 0 0x4967 0>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7";
power-domains = <&k3_pds 39 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 02/18] arm64: dts: ti: k3-j721e-main: Add multiple channels for CSI2RX DMA
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
J721E CSI2RX SHIM layer can support up to 32 DMA channel contexts. Add
additional DMA channels to enable multistream support for CSI2RX.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 5a8414fc5751..b1988437f52d 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -600,8 +600,14 @@ ti_csi2rx0: ticsi2rx@4500000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_udmap 0x4940>;
- dma-names = "rx0";
+ dmas = <&main_udmap 0x4940>, <&main_udmap 0x4941>, <&main_udmap 0x4942>,
+ <&main_udmap 0x4943>, <&main_udmap 0x4944>, <&main_udmap 0x4945>,
+ <&main_udmap 0x4946>, <&main_udmap 0x4947>, <&main_udmap 0x4948>,
+ <&main_udmap 0x4949>, <&main_udmap 0x494a>, <&main_udmap 0x494b>,
+ <&main_udmap 0x494c>, <&main_udmap 0x494d>, <&main_udmap 0x494e>,
+ <&main_udmap 0x494f>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7",
+ "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", "rx14", "rx15";
power-domains = <&k3_pds 26 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
@@ -656,8 +662,14 @@ ti_csi2rx1: ticsi2rx@4510000 {
ranges;
#address-cells = <2>;
#size-cells = <2>;
- dmas = <&main_udmap 0x4960>;
- dma-names = "rx0";
+ dmas = <&main_udmap 0x4960>, <&main_udmap 0x4961>, <&main_udmap 0x4962>,
+ <&main_udmap 0x4963>, <&main_udmap 0x4964>, <&main_udmap 0x4965>,
+ <&main_udmap 0x4966>, <&main_udmap 0x4967>, <&main_udmap 0x4968>,
+ <&main_udmap 0x4969>, <&main_udmap 0x496a>, <&main_udmap 0x496b>,
+ <&main_udmap 0x496c>, <&main_udmap 0x496d>, <&main_udmap 0x496e>,
+ <&main_udmap 0x496f>;
+ dma-names = "rx0", "rx1", "rx2", "rx3", "rx4", "rx5", "rx6", "rx7",
+ "rx8", "rx9", "rx10", "rx11", "rx12", "rx13", "rx14", "rx15";
power-domains = <&k3_pds 27 TI_SCI_PD_EXCLUSIVE>;
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH 01/18] arm64: dts: ti: k3-{j721e/j721s2}-main: Fix indentation in CSI2RX node
From: Yemike Abhilash Chandra @ 2026-07-02 9:31 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: Frank.Li, s.hauer, kernel, festevam, andersson, geert,
dmitry.baryshkov, arnd, ebiggers, luca.weiss, michal.simek, sven,
linux-arm-kernel, devicetree, linux-kernel, imx, r-donadkar,
devarsht, u-kumar1
In-Reply-To: <20260702093123.1048575-1-y-abhilashchandra@ti.com>
From: Vaishnav Achath <vaishnav.a@ti.com>
Fix a few minor indentation errors in the cdns csi2rx clocks and
clock-names properties.
Signed-off-by: Vaishnav Achath <vaishnav.a@ti.com>
Signed-off-by: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 4 ++--
arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index d5fd30a01032..5a8414fc5751 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -612,9 +612,9 @@ cdns_csi2rx0: csi-bridge@4504000 {
<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "error_irq", "irq";
clocks = <&k3_clks 26 2>, <&k3_clks 26 0>, <&k3_clks 26 2>,
- <&k3_clks 26 2>, <&k3_clks 26 3>, <&k3_clks 26 3>;
+ <&k3_clks 26 2>, <&k3_clks 26 3>, <&k3_clks 26 3>;
clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
- "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
phys = <&dphy0>;
phy-names = "dphy";
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
index 1228ac5711bf..5cac119e4292 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-main.dtsi
@@ -1251,9 +1251,9 @@ cdns_csi2rx0: csi-bridge@4504000 {
<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "error_irq", "irq";
clocks = <&k3_clks 38 3>, <&k3_clks 38 1>, <&k3_clks 38 3>,
- <&k3_clks 38 3>, <&k3_clks 38 4>, <&k3_clks 38 4>;
+ <&k3_clks 38 3>, <&k3_clks 38 4>, <&k3_clks 38 4>;
clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
- "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
phys = <&dphy0>;
phy-names = "dphy";
@@ -1307,9 +1307,9 @@ cdns_csi2rx1: csi-bridge@4514000 {
<GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "error_irq", "irq";
clocks = <&k3_clks 39 3>, <&k3_clks 39 1>, <&k3_clks 39 3>,
- <&k3_clks 39 3>, <&k3_clks 39 4>, <&k3_clks 39 4>;
+ <&k3_clks 39 3>, <&k3_clks 39 4>, <&k3_clks 39 4>;
clock-names = "sys_clk", "p_clk", "pixel_if0_clk",
- "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
+ "pixel_if1_clk", "pixel_if2_clk", "pixel_if3_clk";
phys = <&dphy1>;
phy-names = "dphy";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Wen Jiang @ 2026-07-02 9:26 UTC (permalink / raw)
To: Dev Jain
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <aecf8ea2-43e3-4aad-810a-120b036d8bc2@arm.com>
On Mon, 29 Jun 2026 at 14:47, Dev Jain <dev.jain@arm.com> wrote:
>
>
>
> On 18/06/26 2:17 pm, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > Try to align the vmap virtual address to PMD_SHIFT or a
> > larger PTE mapping size hinted by the architecture, so
> > contiguous pages can be batch-mapped when setting PMD or
> > PTE entries.
> >
> > Add __get_vm_area_node_aligned_caller() as a wrapper over
> > __get_vm_area_node() to simplify repeated calls with fixed
> > arguments.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> > mm/vmalloc.c | 37 ++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index fffb885cb2158..bc9fa93e2bdc6 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3628,6 +3628,41 @@ static int vmap_batched(unsigned long addr, unsigned long end,
> > return err;
> > }
> >
> > +static struct vm_struct *__get_vm_area_node_aligned_caller(unsigned long size,
> > + unsigned long align, unsigned long flags, const void *caller)
>
> There are 3 similar functions below __get_vm_area_node: they are __get_vm_area_caller,
> get_vm_area and get_vm_area_caller. You can put this one just below them.
>
>
> > +{
> > + return __get_vm_area_node(size, align, PAGE_SHIFT, flags,
> > + VMALLOC_START, VMALLOC_END,
> > + NUMA_NO_NODE, GFP_KERNEL, caller);
> > +}
> > +
> > +static struct vm_struct *vmap_get_aligned_vm_area(unsigned long size,
> > + unsigned long flags, const void *caller)
> > +{
> > + struct vm_struct *vm_area;
> > + unsigned int shift;
> > +
> > + /* Try PMD alignment for large sizes */
>
> This comment feels excessive. Can remove it.
>
>
> > + if (size >= PMD_SIZE) {
>
> Need an arch_vmap_pmd_supported() check here.
>
>
Will add the check here.
> > + vm_area = __get_vm_area_node_aligned_caller(size, PMD_SIZE,
> > + flags, caller);
> > + if (vm_area)
> > + return vm_area;
> > + }
> > +
> > + /* Try CONT_PTE alignment */
>
> Comment feels excessive, and again no need to mention arm64 specific stuff here.
> Just remove it.
>
> > + shift = arch_vmap_pte_supported_shift(size);
> > + if (shift > PAGE_SHIFT) {
> > + vm_area = __get_vm_area_node_aligned_caller(size, 1UL << shift,
> > + flags, caller);
> > + if (vm_area)
> > + return vm_area;
> > + }
> > +
> > + /* Fall back to page alignment */
>
> This comment can also be dropped, but I am fine either way.
>
>
Will do.
> > + return __get_vm_area_node_aligned_caller(size, PAGE_SIZE, flags, caller);
> > +}
> > +
> > /**
> > * vmap - map an array of pages into virtually contiguous space
> > * @pages: array of page pointers
> > @@ -3666,7 +3701,7 @@ void *vmap(struct page **pages, unsigned int count,
> > return NULL;
> >
> > size = (unsigned long)count << PAGE_SHIFT;
> > - area = get_vm_area_caller(size, flags, __builtin_return_address(0));
> > + area = vmap_get_aligned_vm_area(size, flags, __builtin_return_address(0));
>
> So the effect is that now we search for an aligned vm_struct unconditionally. Better
> to mention in the commit message that we do not expect any significant overhead for
> this.
>
Yes, I'll mention this in v5.
Thanks.
>
> > if (!area)
> > return NULL;
> >
>
^ permalink raw reply
* Re: [PATCH v3] drm/rockchip: Remove dependency on DRM simple helpers
From: Javier Martinez Canillas @ 2026-07-02 9:23 UTC (permalink / raw)
To: Diogo Silva, Sandy Huang, Heiko Stübner, Andy Yan
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, dri-devel, linux-arm-kernel, linux-rockchip,
linux-kernel, Diogo Silva
In-Reply-To: <20260608124018.480365-2-diogompaissilva@gmail.com>
Diogo Silva <diogompaissilva@gmail.com> writes:
Hello Diogo,
> Simple KMS helper are deprecated since they only add an intermediate
> layer between drivers and the atomic modesetting.
> This patch removes the dependency on drm simple helpers from rockchip
> DRM drivers.
>
I think that would be more informative to say something like following:
This patch removes the drm_simple_encoder_init() helper usage in the
rockchip drivers, by open coding it and using the encoder atomic helpers
directly. This is a step to eventually get rid of this simple KMS helper,
once all drivers that use it have been converted.
> Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
> ---
The changes look good to me:
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8188-geralt: Add supply for SPI NOR flash
From: AngeloGioacchino Del Regno @ 2026-07-02 9:22 UTC (permalink / raw)
To: Matthias Brugger, Chen-Yu Tsai
Cc: linux-mediatek, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260702083800.578581-1-wenst@chromium.org>
On Thu, 02 Jul 2026 16:37:58 +0800, Chen-Yu Tsai wrote:
> The SPI NOR flash is powered the "always on" 1.8V LDO regulated power
> rail.
>
> Add the supply for the SPI NOR flash.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8188-geralt: Add supply for SPI NOR flash
commit: eb3e990db356964d64f5cc258d30776c0363f9e9
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: mediatek: mt8186: change CCI OPP scaling mapping
From: AngeloGioacchino Del Regno @ 2026-07-02 9:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Matthias Brugger, devicetree,
linux-kernel, Mark Tseng
Cc: linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20260529100514.52082-2-chun-jen.tseng@mediatek.com>
On Fri, 29 May 2026 18:05:08 +0800, Mark Tseng wrote:
> The original CCI OPP table minimum frequency 500Mhz is too low to cause
> system stall, So it need update to new version, 1.4G ~ 0.8G.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8186: change CCI OPP scaling mapping
commit: c41cd028e8fb138aa6243d224d637db15354ea95
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8183-kukui: Add supply for SPI NOR flash
From: AngeloGioacchino Del Regno @ 2026-07-02 9:22 UTC (permalink / raw)
To: Matthias Brugger, Chen-Yu Tsai
Cc: linux-mediatek, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260702083746.578461-1-wenst@chromium.org>
On Thu, 02 Jul 2026 16:37:45 +0800, Chen-Yu Tsai wrote:
> The SPI NOR flash is powered from the always on 1.8V power rail through
> a load switch that is controlled by the security chip.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8183-kukui: Add supply for SPI NOR flash
commit: 1f16e99cd8361b33758205eba587dbe40a82975a
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Geert Uytterhoeven @ 2026-07-02 9:16 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Alexandre Torgue, Giuseppe Cavallaro, Chen-Yu Tsai,
Jernej Skrabec, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Shawn Guo, Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar,
Romain Gantois, Magnus Damm, Maxime Ripard, Christophe Roullier,
Radu Rendec, linux-arm-msm, devicetree, linux-kernel, netdev,
linux-stm32, linux-arm-kernel, Drew Fustini, linux-sunxi,
linux-amlogic, linux-mips, imx, linux-renesas-soc, linux-rockchip,
sophgo, linux-riscv, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <CAMRc=MfBcOhbj=ETxy2Xz9o_nyzykrEhKAc3jYi6V5_jMZEE3Q@mail.gmail.com>
Hi Bartosz,
On Thu, 2 Jul 2026 at 11:12, Bartosz Golaszewski <brgl@kernel.org> wrote:
> On Tue, 30 Jun 2026 12:23:16 +0200, Vinod Koul <vkoul@kernel.org> said:
> > On 29-06-26, 16:51, Geert Uytterhoeven wrote:
> >> > Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
> >> > driver instead of the MAC driver where it was previously. Instead of cramming
> >> > both HLOS and firmware handling into the same driver, I figured it makes more
> >> > sense to have a dedicated, cleaner driver as the two share very little code (if
> >> > any).
> >>
> >> I think you are mixing up DT bindings and driver implementation?
> >
> > Should the bindings change if we have different driver and firmware
> > implementations? Isn't binding supposed to be agnostic of
> > implementations..?
>
> I've thought about it some more and I believe this question is philosophical in
> nature.
>
> sa8775p and sa8255p are *the same* hardware. I can flash different firmware on
> the same Lemans Ride board and it becomes one or the other. Yet they are not
> described by the same DTS and the bindings differ as well. I don't see why we
> wouldn't allow the same approach for the this PHY.
>
> We treat it as different HW variant when it's managed by firmware - just like
> we do with the rest of the SoC.
DT describes hardware, not software policy.
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 v4 5/5] arm64: mpam: Add memory bandwidth usage (MBWU) documentation
From: Ben Horgan @ 2026-07-02 9:20 UTC (permalink / raw)
To: Reinette Chatre
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jic23, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, rohit.mathew, scott, sdonthineni, tan.shaopeng, xhao,
zengheng4, x86
In-Reply-To: <4b0552cc-85cc-40b6-ab65-6b7620149f74@intel.com>
Hi Reinette,
On 7/1/26 23:38, Reinette Chatre wrote:
> Hi Ben,
>
> On 5/20/26 2:24 PM, Ben Horgan wrote:
>> Memory bandwidth monitoring make uses of MBWU monitors and is now exposed
>> to the user via resctrl. Add some documentation so the user knows what to
>> expect.
>>
>> Co-developed-by: James Morse <james.morse@arm.com>
>> Signed-off-by: James Morse <james.morse@arm.com>
>> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
>> ---
>> Documentation/arch/arm64/mpam.rst | 17 +++++++++++++++++
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/Documentation/arch/arm64/mpam.rst b/Documentation/arch/arm64/mpam.rst
>> index 570f51a8d4eb..208ff17068c4 100644
>> --- a/Documentation/arch/arm64/mpam.rst
>> +++ b/Documentation/arch/arm64/mpam.rst
>> @@ -65,6 +65,23 @@ The supported features are:
>> there is at least one CSU monitor on each MSC that makes up the L3 group.
>> Exposing CSU counters from other caches or devices is not supported.
>>
>> +* Memory Bandwidth Usage (MBWU) on or after the L3 cache. resctrl uses the
>> + L3 cache-id to identify where the memory bandwidth is measured. For this
>> + reason the platform must have an L3 cache with cache-id's supplied by
>> + firmware. (It doesn't need to support MPAM.)
>> +
>> + Memory bandwidth monitoring makes use of MBWU monitors in each MSC that
>> + makes up the L3 group. If the memory bandwidth monitoring is on the memory
>> + rather than the L3 then there must be a single global L3 as otherwise it
>> + is unknown which L3 the traffic came from.
>> +
>> + To expose 'mbm_total_bytes', the topology of the group of MSC chosen must
>> + match the topology of the L3 cache so that the cache-id's can be
>> + repainted. For example: Platforms with Memory bandwidth monitors on
>> + CPU-less NUMA nodes cannot expose 'mbm_total_bytes' as these nodes do not
>> + have a corresponding L3 cache. 'mbm_local_bytes' is not exposed as MPAM
>> + cannot distinguish local traffic from global traffic.
>
> Hopefully we can get to a point where memory bandwidth monitoring data from
> CPU-less NUMA nodes can be exposed via resctrl. When considering such possible
Thank you for your interest here. I hope so too.
> future I think it may make this work easier to build on if the documentation
> focuses on what the current implementation supports and leave room for
> future enhancements by not constraining user space expectation with an absolute
> like "CPU-less NUMA nodes cannot expose 'mbm_total_bytes'".
The intention was to describe the current limitations but I do see how
this can come across as fundamental problems rather than just that we
need to do some more work to establish how this can be done and
implement it.
How about if I add this paragraph at the end?
All these restrictions based on L3 cache are due to resctrl, currently,
only supporting monitoring at the scope of the L3 scope. It is expected
that going forward more MBWU monitors can be exposed to the user after
support for more monitoring scopes is added to resctrl.
Thanks,
Ben>
> Reinette
^ permalink raw reply
* Re: [PATCH v4 5/6] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Wen Jiang @ 2026-07-02 9:18 UTC (permalink / raw)
To: Uladzislau Rezki
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <akPKkOt_GNbAbyN5@milan>
On Tue, 30 Jun 2026 at 21:54, Uladzislau Rezki <urezki@gmail.com> wrote:
>
> On Thu, Jun 18, 2026 at 04:47:25PM +0800, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > In many cases, the pages passed to vmap() may include high-order
> > pages. For example, the systemheap often allocates pages in descending
> > order: order 8, then 4, then 0. Currently, vmap() iterates over every
> > page individually—even pages inside a high-order block are handled
> > one by one.
> >
> > This patch detects physically contiguous pages (regardless of whether
> > they are compound or non-compound) by scanning with
> > num_pages_contiguous(), and maps them as a single contiguous block
> > whenever possible. The mapping order is determined by taking the
> > minimum of the contiguous page count and the pfn alignment, allowing
> > graceful degradation when pfn alignment is less than the contiguous
> > range.
> >
> > Pages with the same page_shift are coalesced and mapped via
> > vmap_pages_range_noflush_walk() to avoid page table rewalk.
> >
> > As users typically allocate memory in descending orders (e.g.
> > 8 → 4 → 0), once an order-0 page is encountered, we stop scanning
> > for contiguous pages since subsequent pages are likely order-0 as well.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Co-developed-by: Dev Jain <dev.jain@arm.com>
> > Signed-off-by: Dev Jain <dev.jain@arm.com>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > ---
> > mm/vmalloc.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 85 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 253e017130e09..fffb885cb2158 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -3545,6 +3545,89 @@ void vunmap(const void *addr)
> > }
> > EXPORT_SYMBOL(vunmap);
> >
> > +static inline unsigned int vm_shift(pgprot_t prot, unsigned long size)
> > +{
> > + if (arch_vmap_pmd_supported(prot) && size >= PMD_SIZE)
> > + return PMD_SHIFT;
> > +
> > + return arch_vmap_pte_supported_shift(size);
> > +}
> > +
> > +static inline int get_vmap_batch_order(struct page **pages,
> > + pgprot_t prot, unsigned int max_steps, unsigned int idx)
> > +{
> > + unsigned int nr_contig;
> > + int order;
> > +
> > + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMAP))
> > + return 0;
> > +
> > + nr_contig = num_pages_contiguous(&pages[idx], max_steps);
> > + if (nr_contig < 2)
> > + return 0;
> > +
> > + order = ilog2(nr_contig);
> > +
> > + /* Limit order by pfn alignment */
> > + order = min_t(int, order, __ffs(page_to_pfn(pages[idx])));
> > +
> > + if (vm_shift(prot, PAGE_SIZE << order) == PAGE_SHIFT)
> > + return 0;
> > +
> > + return order;
> > +}
> > +
> > +static int vmap_batched(unsigned long addr, unsigned long end,
> > + pgprot_t prot, struct page **pages)
> > +{
> > + unsigned int count = (end - addr) >> PAGE_SHIFT;
> > + unsigned int prev_shift = 0, idx = 0;
> > + unsigned long start = addr, map_addr = addr;
> > + int err;
> > +
> > + err = kmsan_vmap_pages_range_noflush(addr, end, prot, pages,
> > + PAGE_SHIFT, GFP_KERNEL);
> > + if (err)
> > + goto out;
> > +
> > + for (unsigned int i = 0; i < count; ) {
> > + unsigned int shift = PAGE_SHIFT +
> > + get_vmap_batch_order(pages, prot, count - i, i);
> > +
> > + if (!i)
> > + prev_shift = shift;
> > +
> > + if (shift != prev_shift) {
> > + err = vmap_pages_range_noflush_walk(map_addr, addr,
> > + prot, pages + idx, prev_shift);
> > + if (err)
> > + goto out;
> > + prev_shift = shift;
> > + map_addr = addr;
> > + idx = i;
> > + }
> > +
> > + /*
> > + * Once small pages are encountered, the remaining pages
> > + * are likely small as well.
> > + */
> > + if (shift == PAGE_SHIFT)
> > + break;
> > +
> > + addr += 1UL << shift;
> > + i += 1U << (shift - PAGE_SHIFT);
> > + }
> > +
> > + /* Remaining */
> > + if (map_addr < end)
> > + err = vmap_pages_range_noflush_walk(map_addr, end,
> > + prot, pages + idx, prev_shift);
> > +
> > +out:
> > + flush_cache_vmap(start, end);
> > + return err;
> > +}
> > +
> > /**
> > * vmap - map an array of pages into virtually contiguous space
> > * @pages: array of page pointers
> > @@ -3588,8 +3671,8 @@ void *vmap(struct page **pages, unsigned int count,
> > return NULL;
> >
> > addr = (unsigned long)area->addr;
> > - if (vmap_pages_range(addr, addr + size, pgprot_nx(prot),
> > - pages, PAGE_SHIFT) < 0) {
> > + if (vmap_batched(addr, addr + size, pgprot_nx(prot),
> > + pages) < 0) {
> >
> Better naming? vmap_pages_range_batched()?
>
Yes, I’ll adopt this naming in v5.
Thanks.
> --
> Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Bartosz Golaszewski @ 2026-07-02 9:12 UTC (permalink / raw)
To: Vinod Koul
Cc: Bartosz Golaszewski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Alexandre Torgue, Giuseppe Cavallaro, Chen-Yu Tsai,
Jernej Skrabec, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Shawn Guo, Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar,
Romain Gantois, Magnus Damm, Maxime Ripard, Christophe Roullier,
Radu Rendec, linux-arm-msm, devicetree, linux-kernel, netdev,
linux-stm32, linux-arm-kernel, Drew Fustini, linux-sunxi,
linux-amlogic, linux-mips, imx, linux-renesas-soc, linux-rockchip,
sophgo, linux-riscv, Bartosz Golaszewski, Bartosz Golaszewski,
Geert Uytterhoeven
In-Reply-To: <akOZFIowVvprnAMf@vaman>
On Tue, 30 Jun 2026 12:23:16 +0200, Vinod Koul <vkoul@kernel.org> said:
> On 29-06-26, 16:51, Geert Uytterhoeven wrote:
>> > Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
>> > driver instead of the MAC driver where it was previously. Instead of cramming
>> > both HLOS and firmware handling into the same driver, I figured it makes more
>> > sense to have a dedicated, cleaner driver as the two share very little code (if
>> > any).
>>
>> I think you are mixing up DT bindings and driver implementation?
>
> Should the bindings change if we have different driver and firmware
> implementations? Isn't binding supposed to be agnostic of
> implementations..?
>
I've thought about it some more and I believe this question is philosophical in
nature.
sa8775p and sa8255p are *the same* hardware. I can flash different firmware on
the same Lemans Ride board and it becomes one or the other. Yet they are not
described by the same DTS and the bindings differ as well. I don't see why we
wouldn't allow the same approach for the this PHY.
We treat it as different HW variant when it's managed by firmware - just like
we do with the rest of the SoC.
Bart
^ permalink raw reply
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-07-02 9:12 UTC (permalink / raw)
To: Uladzislau Rezki
Cc: Andrew Morton, linux-mm, linux-arm-kernel, catalin.marinas, will,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <akYplZcaLXIl7AsP@pc636>
On Thu, 2 Jul 2026 at 17:04, Uladzislau Rezki <urezki@gmail.com> wrote:
>
> On Thu, Jul 02, 2026 at 02:35:24PM +0800, Wen Jiang wrote:
> > On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm@linux-foundation.org> wrote:
> > >
> > > On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> > >
> > > > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > > > is physically fully or partially contiguous. Two techniques are used:
> > >
> > > Thanks.
> > >
> > > > 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> > > > segments
> > > > 2. Use batched mappings wherever possible in both vmalloc and ARM64
> > > > layers
> > > >
> > > > Besides accelerating the mapping path, this also enables large
> > > > mappings (PMD and cont-PTE) for vmap, which are currently not
> > > > supported.
> > > >
> > > > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > > > CONT-PTE regions instead of just one.
> > > >
> > > > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > > > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > > > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> > > >
> > > > Patch 4 extends the page table walk path to support page shifts other
> > > > than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> > > > mappings. The function is renamed from vmap_small_pages_range_noflush()
> > > > to vmap_pages_range_noflush_walk().
> > > >
> > > > Patches 5-6 add huge vmap support for contiguous pages, including
> > > > support for non-compound pages with pfn alignment verification.
> > > >
> > > > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > > > the performance CPUfreq policy enabled, benchmark results:
> > > >
> > > > * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> > > > * vmalloc(1 MB) mapping time (excluding allocation) with
> > > > VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
> > > > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
> > >
> > > Nice.
> > >
> > > > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
> > >
> > > Indeed.
> > >
> > > I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> > > folks) have time to go through this.
> > >
> > > Is there any effect on anything other than arm64? I'm wondering how
> > > much testing these changes will really get in mm.git and linux-next.
> > >
> > > How is our selftests coverage of these changes? Is there some existing
> > > selftest which will exercise these new features?
> > >
> >
> > Hi Andrew,
> >
> > I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
> > x86_64, comparing base (v7.0.10) against the patched kernel.
> >
> > All test_vmalloc subtests passed on both platforms. I do not see any
> > functional or performance regression. The small differences below look
> > like measurement noise.
> >
> > ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
> > 5 runs averaged):
> >
> I think there are still comments to this series. One from me about
> naming and there is one more from Jain here: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
>
> Could you please have a look?
Hi Uladzislau,
Thanks for the reminder. I’ve already gone through all the review
comments, but haven’t had time to reply yet. All the feedback will be
addressed in the v5 version.
Thanks.
>
> --
> Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH v2 2/6] mm/rmap: use huge_ptep_get() in try_to_unmap_one()
From: Dev Jain @ 2026-07-02 9:08 UTC (permalink / raw)
To: Muchun Song
Cc: riel, vbabka, harry, jannh, lance.yang, kas, linux-mm,
linux-kernel, rcampbell, apopple, ziy, matthew.brost,
joshua.hahnjy, rakie.kim, byungchul, gourry, ying.huang,
nao.horiguchi, ak, mel, pfalcato, jpoimboe, dave.hansen, tglx,
catalin.marinas, will, linux-arm-kernel, ryan.roberts,
anshuman.khandual, stable, osalvador, akpm, ljs, david, liam
In-Reply-To: <97a43d82-28c2-4f98-ad74-fe05ed9f0297@linux.dev>
On 02/07/26 2:17 pm, Muchun Song wrote:
>
>
> On 2026/7/2 13:13, Dev Jain wrote:
>> try_to_unmap_one() handles hugetlb folios when memory failure needs
>> to replace a poisoned hugetlb mapping with a hwpoison entry. In that
>> case page_vma_mapped_walk() returns the pte pointer to the hugetlb folio
>> in pvmw.pte, but the code reads it with ptep_get().
>>
>> On arches which provide their own huge_ptep_get() to dereference a huge
>> pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present()
>> etc to misbehave.
>>
>> It is not clear whether this has a trivially visible effect to userspace.
>>
>> Just use huge_ptep_get() for dereferencing a huge pte pointer.
>>
>> Fixes: c7ab0d2fdc84 ("mm: convert try_to_unmap_one() to use page_vma_mapped_walk()")
>> Cc: stable@vger.kernel.org
>> Reported-by: David Hildenbrand <david@kernel.org>
>> Signed-off-by: Dev Jain <dev.jain@arm.com>
>> ---
>> include/linux/hugetlb.h | 3 +++
>> mm/rmap.c | 16 ++++++++++------
>> 2 files changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 2abaf99321e90..fdb7bdf7645c5 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -1261,6 +1261,9 @@ static inline void hugetlb_count_sub(long l, struct mm_struct *mm)
>> {
>> }
>> +pte_t huge_ptep_get(struct mm_struct *mm, unsigned long addr,
>> + pte_t *ptep);
>> +
>
> Maybe I didn't express my thoughts clearly in the first version, let me
> explain in more detail.
>
> We should define this stub as a no-op for !CONFIG_HUGETLB_PAGE (like
> set_huge_pte_at, that is why I mentioned 5d4af6195c87c6 for your reference
> in your previous version). Currently, you've added a declaration, but the
> function itself doesn't actually exist, which seems quite strange to me.
https://lore.kernel.org/all/a4fe8ba6-2ecd-4bb9-95a9-27f9f1e87d2e@kernel.org/
David suggested this. Honestly I quite like David's suggestion, what do you
think?
>
> Muchun,
> Thanks.
>> static inline pte_t huge_ptep_clear_flush(struct vm_area_struct *vma,
>> unsigned long addr, pte_t *ptep)
>> {
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index 1c77d5dc06e9f..aa8a254efaecc 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -2095,11 +2095,16 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
>> /* Unexpected PMD-mapped THP? */
>> VM_BUG_ON_FOLIO(!pvmw.pte, folio);
>> - /*
>> - * Handle PFN swap PTEs, such as device-exclusive ones, that
>> - * actually map pages.
>> - */
>> - pteval = ptep_get(pvmw.pte);
>> + address = pvmw.address;
>> + if (folio_test_hugetlb(folio)) {
>> + pteval = huge_ptep_get(mm, address, pvmw.pte);
>> + } else {
>> + /*
>> + * Handle PFN swap PTEs, such as device-exclusive ones,
>> + * that actually map pages.
>> + */
>> + pteval = ptep_get(pvmw.pte);
>> + }
>> if (likely(pte_present(pteval))) {
>> pfn = pte_pfn(pteval);
>> } else {
>> @@ -2110,7 +2115,6 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
>> }
>> subpage = folio_page(folio, pfn - folio_pfn(folio));
>> - address = pvmw.address;
>> anon_exclusive = folio_test_anon(folio) &&
>> PageAnonExclusive(subpage);
>>
>
^ permalink raw reply
* [PATCH RFC] dt-bindings: perf: riscv,pmu: Add interrupts-extended property
From: Eric Lin @ 2026-07-02 9:04 UTC (permalink / raw)
To: Will Deacon, Mark Rutland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Atish Patra
Cc: linux-arm-kernel, linux-perf-users, devicetree, linux-riscv,
linux-kernel, Nick Hu, Eric Lin
The interrupts-extended property is used to specify the connection
between the PMU counter overflow interrupt and the corresponding CPU
local interrupt controller (riscv,cpu-intc).
This property also allows the software to associate a PMU node with a
specific CPU. To support future heterogeneous systems, where different
CPUs may support different PMU events, this property allows the driver
to identify the correct PMU capabilities for each hart.
Reviewed-by: Nick Hu <nick.hu@sifive.com>
Signed-off-by: Eric Lin <eric.lin@sifive.com>
---
Documentation/devicetree/bindings/perf/riscv,pmu.yaml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
index d01c677ad3c7..13aceb3d42b9 100644
--- a/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
+++ b/Documentation/devicetree/bindings/perf/riscv,pmu.yaml
@@ -34,6 +34,13 @@ properties:
compatible:
const: riscv,pmu
+ interrupts-extended:
+ minItems: 1
+ maxItems: 4095
+ description:
+ Specifies the interrupt-parent and local interrupt index for each CPU's
+ PMU counter overflow. Each item points to a riscv,cpu-intc node.
+
riscv,event-to-mhpmevent:
$ref: /schemas/types.yaml#/definitions/uint32-matrix
description:
@@ -101,6 +108,7 @@ examples:
- |
pmu {
compatible = "riscv,pmu";
+ interrupts-extended = <&cpu0_intc 13>;
riscv,event-to-mhpmevent = <0x0000B 0x0000 0x0001>;
riscv,event-to-mhpmcounters = <0x00001 0x00001 0x00000001>,
<0x00002 0x00002 0x00000004>,
@@ -127,6 +135,9 @@ examples:
*/
pmu {
compatible = "riscv,pmu";
+ interrupts-extended = <&cpu0_intc 13>,
+ <&cpu1_intc 13>,<&cpu2_intc 13>,
+ <&cpu3_intc 13>,<&cpu4_intc 13>;
riscv,event-to-mhpmevent =
/* SBI_PMU_HW_CACHE_REFERENCES -> Instruction or Data cache/ITIM busy */
<0x00003 0x00000000 0x1801>,
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260701-pmu-dt-property-ff12b35fe0fc
Best regards,
--
Eric Lin <eric.lin@sifive.com>
^ permalink raw reply related
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Uladzislau Rezki @ 2026-07-02 9:04 UTC (permalink / raw)
To: Wen Jiang
Cc: Andrew Morton, linux-mm, linux-arm-kernel, catalin.marinas, will,
urezki, baohua, Xueyuan.chen21, dev.jain, rppt, david,
ryan.roberts, anshuman.khandual, ajd, linux-kernel, jiangwen6,
shanghaoqiang
In-Reply-To: <CAHKocdHJ-JB5jjXG3_-syz4P8k1C=jWrGaFxwnTjcinpGyR_BA@mail.gmail.com>
On Thu, Jul 02, 2026 at 02:35:24PM +0800, Wen Jiang wrote:
> On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
> >
> > > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > > is physically fully or partially contiguous. Two techniques are used:
> >
> > Thanks.
> >
> > > 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> > > segments
> > > 2. Use batched mappings wherever possible in both vmalloc and ARM64
> > > layers
> > >
> > > Besides accelerating the mapping path, this also enables large
> > > mappings (PMD and cont-PTE) for vmap, which are currently not
> > > supported.
> > >
> > > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > > CONT-PTE regions instead of just one.
> > >
> > > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> > >
> > > Patch 4 extends the page table walk path to support page shifts other
> > > than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> > > mappings. The function is renamed from vmap_small_pages_range_noflush()
> > > to vmap_pages_range_noflush_walk().
> > >
> > > Patches 5-6 add huge vmap support for contiguous pages, including
> > > support for non-compound pages with pfn alignment verification.
> > >
> > > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > > the performance CPUfreq policy enabled, benchmark results:
> > >
> > > * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> > > * vmalloc(1 MB) mapping time (excluding allocation) with
> > > VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
> > > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
> >
> > Nice.
> >
> > > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
> >
> > Indeed.
> >
> > I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> > folks) have time to go through this.
> >
> > Is there any effect on anything other than arm64? I'm wondering how
> > much testing these changes will really get in mm.git and linux-next.
> >
> > How is our selftests coverage of these changes? Is there some existing
> > selftest which will exercise these new features?
> >
>
> Hi Andrew,
>
> I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
> x86_64, comparing base (v7.0.10) against the patched kernel.
>
> All test_vmalloc subtests passed on both platforms. I do not see any
> functional or performance regression. The small differences below look
> like measurement noise.
>
> ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
> 5 runs averaged):
>
I think there are still comments to this series. One from me about
naming and there is one more from Jain here: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
Could you please have a look?
--
Uladzislau Rezki
^ 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