* [PATCH 14/15] arm64: dts: ti: k3-am62p-j722s-common-main: Add support for DSS
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen, Jayesh Choudhary, Aradhya Bhatia
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
From: Jayesh Choudhary <j-choudhary@ti.com>
TI's AM62P and J722S SoCs support 2 display subsystems (DSS), DSS0 and
DSS1, each with two video ports (VP) and two video planes. The outputs
from the DSS VPs can be routed to two OLDI TXes (OLDI0, OLDI1), a DSI
TX, or parallel DPI output.
DSS0 supports:
- VP0: OLDI0 in single-link mode or OLDI0 and OLDI1 in dual-link or
clone mode.
- VP1: DPI
DSS1 supports:
- VP0: OLDI1 in single-link mode, or DPI
- VP1: DPI or DSI
The DSI is only connected to VP1 of DSS1, but OLDI and DPI are shared
between the DSS instances. Thus only a single VP can output to DPI, and
a single VP can use an OLDI block. Note that in single-link
configuration OLDI0 can be used by DSS0, and at the same time OLDI1 can
be used by DSS1.
Add the necessary nodes to k3-am62p-j722s-common-main.dtsi, including
DSS0, DSS1, OLDI0, OLDI1, DPHY and DSI.
An important note about OLDIs:
We have two OLDI hardware blocks. Each OLDI has certain configuration
that has to be done before it can be used. The OLDI blocks get this
configuration directly from the DSS block, via DSS registers. However,
as a single OLDI block can be used either with DSS0 or DSS1, the
source for the configuration changes according to (probably, this is
unclear) a DSS related clock mux.
So, afaics, when thinking about Linux device hierarchy wrt. control
busses, OLDI blocks are children of DSS blocks, and they reside in a
special DSS bus. And the OLDI parent changes according to the mux. As
far as I know, there is no way we can represent this in the DT.
Thus the solution used here (and in the driver) is that each DSS node
contains the OLDI nodes that can be used with that DSS. Thus the DSS0
node has two child nodes, OLDI0 and OLDI1, and the DSS1 node has one
child node, OLDI1. The OLDI1 nodes thus refer to the same piece of
hardware, and they cannot be used at the same time. The selection which
OLDI nodes to use are chosen in the board dts files, so assuming the dts
files are correct, no resource conflict can happen.
This is not a very nice solution, but the hardware doesn't make it easy
to have a clean solution, and, most importantly, this works.
A note about DPI0_CLK_CTRL:
The SoCs also have a separate quirk/fix register for DPI data/sync edge.
See commit "dt-bindings: display: ti,am65x-dss: Add dpi-io-ctrl property
for data/sync edge synchronization" for details.
Here we add that quirk register, with the dss_dpi0_clk_ctrl node, and
refer to it from the DSS nodes.
Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com>
[j-choudhary@ti.com: Refactor changes for k3-am62p-j722s-common-main.dtsi
and add changes for new OLDI driver support]
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
[tomi.valkeinen: various fixes and improvements]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
.../boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 112 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am62p.dtsi | 16 +++
arch/arm64/boot/dts/ti/k3-j722s.dtsi | 16 +++
3 files changed, 144 insertions(+)
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 0e1af2a69ca2..263bab009021 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
@@ -64,6 +64,16 @@ audio_refclk1: clock-controller@82e4 {
#clock-cells = <0>;
};
+ dss_dpi0_clk_ctrl: dss-dpi0-clk-ctrl@8300 {
+ compatible = "ti,am625-dss-dpi0-clk-ctrl", "syscon";
+ reg = <0x8300 0x4>;
+ };
+
+ dss_oldi_io_ctrl: dss-oldi-io-ctrl@8600 {
+ compatible = "ti,am625-dss-oldi-io-ctrl", "syscon";
+ reg = <0x8600 0x200>;
+ };
+
phy_gmii_sel: phy@4044 {
compatible = "ti,am654-phy-gmii-sel";
reg = <0x4044 0x8>;
@@ -1110,6 +1120,108 @@ dphy0: phy@30110000 {
status = "disabled";
};
+ dss0: dss@30200000 {
+ compatible = "ti,am62p-dss";
+ reg = <0x00 0x30200000 0x00 0x1000>, /* common */
+ <0x00 0x30202000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30206000 0x00 0x1000>, /* vid */
+ <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
+ <0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */
+ <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI */
+ <0x00 0x30201000 0x00 0x1000>; /* common1 */
+ reg-names = "common", "vidl1", "vid",
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
+ power-domains = <&k3_pds 186 TI_SCI_PD_EXCLUSIVE>; /* DSS0 */
+ clocks = <&k3_clks 186 6>,
+ <&dss0_vp1_clk>,
+ <&k3_clks 186 2>;
+ clock-names = "fck", "vp1", "vp2";
+ interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ oldi-transmitters {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dss0_oldi0: oldi@0 {
+ reg = <0>;
+ clocks = <&k3_clks 186 0>;
+ clock-names = "serial";
+ ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+ status = "disabled";
+ power-domains = <&k3_pds 243 TI_SCI_PD_EXCLUSIVE>; /* OLDI0_VD */
+ };
+
+ dss0_oldi1: oldi@1 {
+ reg = <1>;
+ status = "disabled";
+ power-domains = <&k3_pds 244 TI_SCI_PD_EXCLUSIVE>; /* OLDI1_VD */
+ };
+ };
+ };
+
+ dss1: dss@30220000 {
+ compatible = "ti,am62p-dss";
+ reg = <0x00 0x30220000 0x00 0x1000>, /* common */
+ <0x00 0x30222000 0x00 0x1000>, /* vidl1 */
+ <0x00 0x30226000 0x00 0x1000>, /* vid */
+ <0x00 0x30227000 0x00 0x1000>, /* ovr1 */
+ <0x00 0x30228000 0x00 0x1000>, /* ovr2 */
+ <0x00 0x3022a000 0x00 0x1000>, /* vp1: Used for DPI/OLDI */
+ <0x00 0x3022b000 0x00 0x1000>, /* vp2: Used DPI/DSI */
+ <0x00 0x30221000 0x00 0x1000>; /* common1 */
+ reg-names = "common", "vidl1", "vid",
+ "ovr1", "ovr2", "vp1", "vp2", "common1";
+ power-domains = <&k3_pds 232 TI_SCI_PD_EXCLUSIVE>; /* DSS1 */
+ clocks = <&k3_clks 232 8>,
+ <&dss1_vp1_clk>,
+ <&k3_clks 232 4>;
+ clock-names = "fck", "vp1", "vp2";
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ oldi-transmitters {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dss1_oldi1: oldi@1 {
+ reg = <1>;
+ clocks = <&k3_clks 232 0>;
+ clock-names = "serial";
+ ti,oldi-io-ctrl = <&dss_oldi_io_ctrl>;
+ status = "disabled";
+ power-domains = <&k3_pds 244 TI_SCI_PD_EXCLUSIVE>; /* OLDI1_VD */
+ };
+ };
+ };
+
+ dphy_tx0: phy@301c0000 {
+ compatible = "ti,j721e-dphy";
+ reg = <0x0 0x301c0000 0x0 0x1000>;
+ clocks = <&k3_clks 238 16>, <&k3_clks 238 1>;
+ clock-names = "psm", "pll_ref";
+ #phy-cells = <0>;
+ power-domains = <&k3_pds 238 TI_SCI_PD_EXCLUSIVE>;
+ assigned-clocks = <&k3_clks 238 1>;
+ assigned-clock-parents = <&k3_clks 238 2>;
+ assigned-clock-rates = <25000000>;
+ status = "disabled";
+ };
+
+ dsi0: dsi@30500000 {
+ compatible = "ti,j721e-dsi";
+ reg = <0x0 0x30500000 0x0 0x100000>, <0x0 0x30270000 0x0 0x100>;
+ clocks = <&k3_clks 231 2>, <&k3_clks 231 5>;
+ clock-names = "dsi_p_clk", "dsi_sys_clk";
+ power-domains = <&k3_pds 231 TI_SCI_PD_EXCLUSIVE>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ phys = <&dphy_tx0>;
+ phy-names = "dphy";
+ status = "disabled";
+ };
+
vpu: video-codec@30210000 {
compatible = "ti,j721s2-wave521c", "cnm,wave521c";
reg = <0x00 0x30210000 0x00 0x10000>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
index 9d6266d6ddb8..074dc44ec049 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi
@@ -144,6 +144,22 @@ cbass_wakeup: bus@b00000 {
};
};
+ dss0_vp1_clk: clock-divider-oldi-dss0 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 186 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
+ dss1_vp1_clk: clock-divider-oldi-dss1 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 232 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
#include "k3-am62p-j722s-common-thermal.dtsi"
};
diff --git a/arch/arm64/boot/dts/ti/k3-j722s.dtsi b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
index 059c65ece183..f5b74281ab3d 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j722s.dtsi
@@ -227,6 +227,22 @@ cbass_wakeup: bus@b00000 {
};
};
+ dss0_vp1_clk: clock-divider-oldi-dss0 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 186 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
+ dss1_vp1_clk: clock-divider-oldi-dss1 {
+ compatible = "fixed-factor-clock";
+ clocks = <&k3_clks 232 0>;
+ #clock-cells = <0>;
+ clock-div = <7>;
+ clock-mult = <1>;
+ };
+
#include "k3-am62p-j722s-common-thermal.dtsi"
};
--
2.43.0
^ permalink raw reply related
* [PATCH 15/15] arm64: dts: ti: beagley-ai: Enable HDMI display and audio
From: Tomi Valkeinen @ 2026-04-20 12:54 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lee Jones, Aradhya Bhatia, Nishanth Menon, Vignesh Raghavendra,
Swamil Jain, Devarsh Thakkar, Louis Chauvet
Cc: devicetree, dri-devel, linux-kernel, linux-arm-kernel,
Tomi Valkeinen, Andrew Davis
In-Reply-To: <20260420-beagley-ai-display-v1-0-f628543dfd14@ideasonboard.com>
From: Andrew Davis <afd@ti.com>
Enable HDMI support for BeagleY-AI platform. The display controller used is
TIDSS and the HDMI bridge used is IT66122.
Based on DT by: Robert Nelson <robertcnelson@gmail.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Signed-off-by: Swamil Jain <s-jain1@ti.com>
[tomi.valkeinen: cosmetic fixes]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts | 197 +++++++++++++++++++++++++
1 file changed, 197 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
index 5255e04b9ac7..b7bcc90005d7 100644
--- a/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
+++ b/arch/arm64/boot/dts/ti/k3-am67a-beagley-ai.dts
@@ -146,6 +146,34 @@ led-1 {
default-state = "on";
};
};
+
+ hdmi0: connector-hdmi {
+ compatible = "hdmi-connector";
+ label = "hdmi";
+ type = "d";
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&it66122_out>;
+ };
+ };
+ };
+
+ sound0: sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "it66122 HDMI";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&hdmi_dailink_master>;
+ simple-audio-card,frame-master = <&hdmi_dailink_master>;
+
+ hdmi_dailink_master: simple-audio-card,cpu {
+ sound-dai = <&mcasp1>;
+ system-clock-direction-out;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&it66122>;
+ };
+ };
};
&main_pmx0 {
@@ -185,6 +213,20 @@ J722S_IOPAD(0x0240, PIN_INPUT, 7) /* (B24) MMC1_SDCD.GPIO1_48 */
bootph-all;
};
+ main_i2c1_pins_default: main-i2c1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
+ J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_gpio0_ioexp_intr_pins_default: main-gpio0-ioexp-intr-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0110, PIN_INPUT, 7) /* (G27) MMC2_DAT1.GPIO0_67 */
+ >;
+ };
+
mdio_pins_default: mdio-default-pins {
pinctrl-single,pins = <
J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
@@ -227,6 +269,47 @@ vdd_3v3_sd_pins_default: vdd-3v3-sd-default-pins {
J722S_IOPAD(0x0254, PIN_OUTPUT, 7) /* (E25) USB0_DRVVBUS.GPIO1_50 */
>;
};
+
+ dss1_pins_default: dss1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0100, PIN_OUTPUT, 0) /* (AB23) VOUT0_VSYNC */
+ J722S_IOPAD(0x00f8, PIN_OUTPUT, 0) /* (AB24) VOUT0_HSYNC */
+ J722S_IOPAD(0x0104, PIN_OUTPUT, 0) /* (AC26) VOUT0_PCLK */
+ J722S_IOPAD(0x00fc, PIN_OUTPUT, 0) /* (AC27) VOUT0_DE */
+ J722S_IOPAD(0x00b8, PIN_OUTPUT, 0) /* (W27) VOUT0_DATA0 */
+ J722S_IOPAD(0x00bc, PIN_OUTPUT, 0) /* (W25) VOUT0_DATA1 */
+ J722S_IOPAD(0x00c0, PIN_OUTPUT, 0) /* (W24) VOUT0_DATA2 */
+ J722S_IOPAD(0x00c4, PIN_OUTPUT, 0) /* (W23) VOUT0_DATA3 */
+ J722S_IOPAD(0x00c8, PIN_OUTPUT, 0) /* (W22) VOUT0_DATA4 */
+ J722S_IOPAD(0x00cc, PIN_OUTPUT, 0) /* (W21) VOUT0_DATA5 */
+ J722S_IOPAD(0x00d0, PIN_OUTPUT, 0) /* (Y26) VOUT0_DATA6 */
+ J722S_IOPAD(0x00d4, PIN_OUTPUT, 0) /* (Y27) VOUT0_DATA7 */
+ J722S_IOPAD(0x00d8, PIN_OUTPUT, 0) /* (AA24) VOUT0_DATA8 */
+ J722S_IOPAD(0x00dc, PIN_OUTPUT, 0) /* (AA27) VOUT0_DATA9 */
+ J722S_IOPAD(0x00e0, PIN_OUTPUT, 0) /* (AA25) VOUT0_DATA10 */
+ J722S_IOPAD(0x00e4, PIN_OUTPUT, 0) /* (AB25) VOUT0_DATA11 */
+ J722S_IOPAD(0x00e8, PIN_OUTPUT, 0) /* (AA23) VOUT0_DATA12 */
+ J722S_IOPAD(0x00ec, PIN_OUTPUT, 0) /* (AA22) VOUT0_DATA13 */
+ J722S_IOPAD(0x00f0, PIN_OUTPUT, 0) /* (AB26) VOUT0_DATA14 */
+ J722S_IOPAD(0x00f4, PIN_OUTPUT, 0) /* (AB27) VOUT0_DATA15 */
+ J722S_IOPAD(0x005c, PIN_OUTPUT, 1) /* (AC25) GPMC0_AD8.VOUT0_DATA16 */
+ J722S_IOPAD(0x0060, PIN_OUTPUT, 1) /* (U26) GPMC0_AD9.VOUT0_DATA17 */
+ J722S_IOPAD(0x0064, PIN_OUTPUT, 1) /* (V27) GPMC0_AD10.VOUT0_DATA18 */
+ J722S_IOPAD(0x0068, PIN_OUTPUT, 1) /* (V25) GPMC0_AD11.VOUT0_DATA19 */
+ J722S_IOPAD(0x006c, PIN_OUTPUT, 1) /* (V26) GPMC0_AD12.VOUT0_DATA20 */
+ J722S_IOPAD(0x0070, PIN_OUTPUT, 1) /* (V24) GPMC0_AD13.VOUT0_DATA21 */
+ J722S_IOPAD(0x0074, PIN_OUTPUT, 1) /* (V22) GPMC0_AD14.VOUT0_DATA22 */
+ J722S_IOPAD(0x0078, PIN_OUTPUT, 1) /* (V23) GPMC0_AD15.VOUT0_DATA23 */
+ >;
+ };
+
+ main_mcasp1_pins_default: main-mcasp1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0090, PIN_INPUT, 2) /* (P27) GPMC0_BE0n_CLE.MCASP1_ACLKX */
+ J722S_IOPAD(0x0098, PIN_INPUT, 2) /* (V21) GPMC0_WAIT0.MCASP1_AFSX */
+ J722S_IOPAD(0x008c, PIN_INPUT, 2) /* (N23) GPMC0_WEn.MCASP1_AXR0 */
+ >;
+ };
};
&cpsw3g {
@@ -284,6 +367,13 @@ J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (C6) WKUP_I2C1_SDA */
>;
bootph-all;
};
+
+ hdmi_gpio_pins_default: hdmi-gpio-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x0038, PIN_INPUT_PULLUP | PIN_DEBOUNCE_CONF6, 7) /* (D8) MCU_MCAN0_RX.MCU_GPIO0_14 HDMI_INTn */
+ J722S_MCU_IOPAD(0x0034, PIN_OUTPUT_PULLUP, 7) /* (B2) MCU_MCAN0_TX.MCU_GPIO0_13 HDMI_RSTn */
+ >;
+ };
};
&wkup_uart0 {
@@ -385,6 +475,63 @@ rtc: rtc@68 {
};
};
+&main_i2c1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>;
+ clock-frequency = <400000>;
+ bootph-all;
+
+ it66122: bridge-hdmi@4c {
+ compatible = "ite,it66122";
+ reg = <0x4c>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdmi_gpio_pins_default>;
+ vcn33-supply = <&vdd_3v3>;
+ vcn18-supply = <&buck2_reg>;
+ vrf12-supply = <&ldo2_reg>;
+ reset-gpios = <&mcu_gpio0 13 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&mcu_gpio0>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
+ #sound-dai-cells = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * HDMI can be serviced with 3 potential VPs -
+ * (DSS0 VP1 / DSS1 VP0 / DSS1 VP1).
+ * For now, we will service it with DSS1 VP1.
+ */
+ port@0 {
+ reg = <0>;
+
+ it66122_in: endpoint {
+ bus-width = <24>;
+ remote-endpoint = <&dss1_dpi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ it66122_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+};
+
+&main_gpio0 {
+ status = "okay";
+};
+
+&mcu_gpio0 {
+ status = "okay";
+};
+
&sdhci1 {
/* SD/MMC */
vmmc-supply = <&vdd_mmc1>;
@@ -399,4 +546,54 @@ &sdhci1 {
status = "okay";
};
+&dss1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss1_pins_default>;
+
+ clocks = <&k3_clks 232 8>,
+ <&k3_clks 232 0>,
+ <&k3_clks 232 4>;
+
+ assigned-clocks = <&k3_clks 241 0>, /* DSS1-VP0 */
+ <&k3_clks 240 0>, /* DSS1-VP1 */
+ <&k3_clks 245 0>; /* DPI Output */
+
+ assigned-clock-parents = <&k3_clks 241 2>, /* PLL 17 HDMI */
+ <&k3_clks 240 1>, /* PLL 18 DSI */
+ <&k3_clks 245 2>; /* DSS1-DPI0 */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* DSS1-VP1: DPI/HDMI Output */
+ port@0 {
+ reg = <0>;
+
+ dss1_dpi0_out: endpoint {
+ remote-endpoint = <&it66122_in>;
+ };
+ };
+ };
+};
+
+&mcasp1 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp1_pins_default>;
+ auxclk-fs-ratio = <2177>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 1 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ tx-num-evt = <32>;
+ rx-num-evt = <32>;
+};
+
#include "k3-j722s-ti-ipc-firmware.dtsi"
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: crypto: qcom,inline-crypto-engine: Document Nord ICE
From: Shawn Guo @ 2026-04-20 12:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herbert Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov,
Bartosz Golaszewski, Deepti Jaggi, linux-crypto, devicetree,
linux-arm-msm, linux-kernel
In-Reply-To: <4b074757-ac44-4077-8ab4-5a983d1be50b@kernel.org>
On Mon, Apr 20, 2026 at 01:56:46PM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2026 10:39, Shawn Guo wrote:
> > On Mon, Apr 20, 2026 at 10:27:56AM +0200, Krzysztof Kozlowski wrote:
> >> On 20/04/2026 09:33, Shawn Guo wrote:
> >>> Add compatible for Inline Crypto Engine (ICE) on Qualcomm Nord SoC
> >>> witha fallback on qcom,inline-crypto-engine.
> >>
> >> Don't explain what the diff is doing. Explain why. Why do you use fallback?
> >>
> >> What is Nord? It's nowhere explained. First posting was 1.5 months ago
> >> and it did not provide any explanation. I don't see any information
> >> being posted in the series sent now.
> >
> > I'm still checking internally to see how we can get the best socinfo
> > patch describing Nord which is a SoC family covering both SA8997P and
> > IQ10 variant. Hopefully I will get it soon.
>
> I found the DTS on:
> https://github.com/qualcomm-linux/kernel-topics/commits/early/hwe/nord/
> so it should be mentioned somewhere, which I kind of asked when we
> discussed about adding compatibles used by that DTS. You would solve
> yourself all my questions from three threads.
Ah, I see. I thought only patches posted to list count.
Thanks!
Shawn
^ permalink raw reply
* Re: [regression] of: mis-parsing Depthcharge's /firmware
From: Rob Herring @ 2026-04-20 12:57 UTC (permalink / raw)
To: Brian Norris
Cc: Chen-Yu Tsai, Sasha Levin, Krzysztof Kozlowski,
AngeloGioacchino Del Regno, Linus Torvalds, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, devicetree, Matthias Brugger,
Doug Anderson, Julius Werner, chrome-platform
In-Reply-To: <aeKlYzTiL0OB1y3g@google.com>
On Fri, Apr 17, 2026 at 4:26 PM Brian Norris <briannorris@chromium.org> wrote:
>
> Hi all,
>
> (New subject; was "Re: [GIT PULL] Devicetree updates for v6.13")
>
> On Mon, Dec 09, 2024 at 05:28:09PM +0800, Chen-Yu Tsai wrote:
> > steelix.dtb is the same, plus the firmware now inserts #address-cells
> > and #size-cells under /firmware. This fix has landed for all future
> > ChromeOS devices via our main firmware branch [1].
> >
> > AFAIK they also have a bad FDT END symbol. This was only recently
> > discovered and fixed for future devices [2].
> >
> >
> > ChenYu
> >
> > [1] Gerrit: https://crrev.com/c/6051580
> > [2] Gerrit: https://review.coreboot.org/c/coreboot/+/85462
>
> This all comes back to bite us, since nobody went back to patch the
> existing Chromebook device trees, and now we've added a true regression
> on top:
>
> In commit 6e5773d52f4a ("of/address: Fix WARN when attempting
> translating non-translatable addresses") we now reject devices without
> '#address-cells', and this breaks the DTs generated by bootloaders
> without Chen-Yu's https://crrev.com/c/6051580 fix (this is ... pretty
> much all Chromebooks). Specifically, Linux now refuses to add 'reg'
> resources to the /firmware/coreboot device, and we fail with:
>
> [ 11.886271] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
>
> This is almost certainly a DTB ABI regression.
>
> This was noticed here (OpenWrt supports some Chromium-based WiFi routers
> that use Depthcharge-based bootloaders from many years ago):
>
> https://github.com/openwrt/openwrt/issues/21243
>
> For now, I just patched up the OpenWrt DTS files like so:
> https://github.com/openwrt/openwrt/pull/22951
>
> But what should we do going forward? I note that Rob says "We may
> revisit this later and address with a fixup to the DT itself" in commit
> 8600058ba28a ("of: Add coreboot firmware to excluded default cells
> list").
>
> That never happened, and a ton of Chromium devices are still broken.
The above just silenced the warning. If they are broken, then
something else broke them.
> (They don't have WARNINGs, but /sys/firmware/vpd, etc., is still
> missing.)
>
> Can we patch of_bus_default_match() to accept an empty 'ranges' [1]? Or
> should I go patch every Chromium-device DTS file I can find? So far, I
> think I can get that done in 17 files in the upstream tree...
Both.
Though I'd rather the kernel fixup the DT rather than relax the
parsing code for everyone. Then we know what platforms need this and
don't let new ones in.
>
> Brian
>
> [1] From ePAPR:
>
> "If the [ranges] property is defined with an <empty> value, it
> specifies that the parent and child address 28 space is identical, and
> no address translation is required."
>
> And:
>
> "An ePAPR-compliant boot program shall supply #address-cells and
> #size-cells on all nodes 16 that have children.
>
> If missing, a client program should assume a default value of 2 for
> #address-cells, and a value of 1 for #size-cells."
ePAPR may say that, but that's not what the kernel implements,
defaulting to 1 address cell (on !SPARC). dtc however does default to
2 cells. Relying on defaults has been a warning in dtc essentially
forever. I'd like to get rid of defaults in the kernel
Rob
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Krzysztof Kozlowski @ 2026-04-20 13:00 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Rob Herring (Arm), linux-kernel, Conor Dooley, Jonathan Corbet,
Alexandre Belloni, Greg Kroah-Hartman, linux-doc, devicetree,
Drew Fustini, Linus Walleij, Jiri Slaby, Russell King, soc,
Arnd Bergmann, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <6264667.lOV4Wx5bFT@strix>
On Sun, Apr 19, 2026 at 11:30:04AM +0300, Stefan Dösinger wrote:
> Hi Rob,
>
> Am Samstag, 18. April 2026, 00:08:44 Ostafrikanische Zeit schrieben Sie:
>
> > If you already ran 'make dt_binding_check' and didn't see the above
> > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > date:
>
> Here is a new PEBKAC issue for your mail template: I ran dt_binding_check, it
> wrote the warning you pointed out, but I only checked the return value - which
> indicated success. Which I guess makes sense for a warning, since there seem
> to be a few preexisting ones. The warning itself was somewhere in the
> scrollback because I let dt_binding_check check all the files.
>
> So I learned I have to actually look at the output to see if there are any
> warnings.
Same with every other tool warnings, like compiler warnings...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: eliza-mtp: Enable USB and ADSP support
From: Abel Vesa @ 2026-04-20 13:03 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <adyfWzVHsg3qo9cH@prism>
On 26-04-13 07:52:27, Alexander Koskovich wrote:
> On Tue, Mar 31, 2026 at 01:37:24PM +0300, Abel Vesa wrote:
> > The Eliza MTP features a single USB Type-C port. Its USB 2.0 lines are
> > routed through an eUSB2 repeater provided by the PM7750BA PMIC.
> >
> > Describe the port and repeater, and enable the USB controller and PHYs.
> >
> > Also specify the ADSP firmware and enable the remoteproc.
> >
> > Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> > ---
> > arch/arm64/boot/dts/qcom/eliza-mtp.dts | 83 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 83 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/eliza-mtp.dts b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
> > index 90f629800cb0..c31f00e36eee 100644
> > --- a/arch/arm64/boot/dts/qcom/eliza-mtp.dts
> > +++ b/arch/arm64/boot/dts/qcom/eliza-mtp.dts
> > @@ -6,9 +6,12 @@
> > /dts-v1/;
> ...
> >
> > +&usb_hsphy {
> > + vdd-supply = <&vreg_l2b>;
>
> Shouldn't this be l7k? Looking at kera-usb.dtsi I see the vdd-supply for
> eusb2_phy0 as l7k. I don't see this being overriden by anything else
> downstream either.
>
> Just bringing it up since I copied this part for another Eliza platform
> (USB 2 only) and USB failed until I fixed this supply.
Yep. That seems to be the case. Thanks for pointing this out.
Will fix when respinning.
^ permalink raw reply
* [PATCH 0/2] drm/panel: Add Raspberry Pi 7" panel
From: Tomi Valkeinen @ 2026-04-20 13:13 UTC (permalink / raw)
To: Dave Stevenson, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Tomi Valkeinen
This series adds Raspberry Pi 7" display module's panel to panel-simple.
Tested with BeagleY-AI and v1.1 of the display module.
This series, with
https://lore.kernel.org/all/20260327-tc358762-fixes-v2-0-3589d3c45f4a%40ideasonboard.com/
gives me a perfectly centered display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Tomi Valkeinen (2):
dt-bindings: display: simple: Add Raspberry Pi 7" DSI Display module panel
drm/panel: simple: Add timings for Raspberry Pi 7" panel
.../bindings/display/panel/panel-simple.yaml | 2 ++
drivers/gpu/drm/panel/panel-simple.c | 32 ++++++++++++++++++++++
2 files changed, 34 insertions(+)
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260420-rpi-7inch-c1d83fe13b17
Best regards,
--
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: display: simple: Add Raspberry Pi 7" DSI Display module panel
From: Tomi Valkeinen @ 2026-04-20 13:13 UTC (permalink / raw)
To: Dave Stevenson, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Tomi Valkeinen
In-Reply-To: <20260420-rpi-7inch-v1-0-e68d5c9c44bc@ideasonboard.com>
Add compatible string for panel used in Raspberry Pi 7" DSI Display
module. The different display module versions have panels from multiple
undisclosed vendors.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 868edb04989a..a71578a99ccc 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -274,6 +274,8 @@ properties:
- qiaodian,qd43003c0-40
# Shenzhen QiShenglong Industrialist Co., Ltd. Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel
- qishenglong,gopher2b-lcd
+ # Raspberry Pi 7" DSI Display module panel (multiple undisclosed vendors)
+ - raspberrypi,7inch-dsi
# Raystar Optronics, Inc. RFF500F-AWH-DNN 5.0" TFT 840x480
- raystar,rff500f-awh-dnn
# Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] drm/panel: simple: Add timings for Raspberry Pi 7" panel
From: Tomi Valkeinen @ 2026-04-20 13:13 UTC (permalink / raw)
To: Dave Stevenson, Neil Armstrong, Jessica Zhang, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Sam Ravnborg
Cc: dri-devel, devicetree, linux-kernel, Tomi Valkeinen
In-Reply-To: <20260420-rpi-7inch-v1-0-e68d5c9c44bc@ideasonboard.com>
Add timings for the panel used in Raspberry Pi 7" DSI Display module:
https://www.raspberrypi.com/products/raspberry-pi-touch-display/
This has been tested with version v1.1 of the display module.
The panel is very strict about the back-porch values, they must be
exactly 46 for hbp and 23 for vbp. Other timings can be defined quite
freely.
The panel is exclusive to Raspberry Pi, and different versions of the
display module can have panels from different vendors which are fully
compatible. Also, as the panel vendors are not public, the compatible
string used is "raspberrypi,7inch-dsi".
Note that while the display module has a DSI connector, and the
compatible has "dsi" in it, we use DRM_MODE_CONNECTOR_DPI as the panel
itself is a parallel video panel. The display module (as of v1.1) uses
TC358762 DSI-to-DPI bridge to do the conversion.
We could use DRM_MODE_CONNECTOR_DSI here, which would have the benefit
of showing a "DSI-1" connector to the userspace. However, the panel IS a
DPI panel, and gets its input from a DSI-to-DPI bridge, and the
panel-simple.c behaves differently depending on the connector type used,
so, DRM_MODE_CONNECTOR_DPI it is.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
drivers/gpu/drm/panel/panel-simple.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 91ab280869ba..e75eb20301f2 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4208,6 +4208,35 @@ static const struct panel_desc rocktech_rk043fn48h = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct display_timing raspberrypi_7inch_timing = {
+ .pixelclock = { 10000000, 30000000, 50000000 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 16, 72, 354 },
+ .hsync_len = { 1, 32, 40 },
+ .hback_porch = { 46, 46, 46 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 7, 21, 147 },
+ .vsync_len = { 1, 2, 20 },
+ .vback_porch = { 23, 23, 23 },
+ .flags = DISPLAY_FLAGS_VSYNC_HIGH | DISPLAY_FLAGS_HSYNC_HIGH,
+ /* Note: the rest of the flags are defined below in bus_flags */
+};
+
+static const struct panel_desc raspberrypi_7inch = {
+ .timings = &raspberrypi_7inch_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH |
+ DRM_BUS_FLAG_SYNC_DRIVE_POSEDGE |
+ DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
+};
+
static const struct display_timing rocktech_rk070er9427_timing = {
.pixelclock = { 26400000, 33300000, 46800000 },
.hactive = { 800, 800, 800 },
@@ -5490,6 +5519,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "qishenglong,gopher2b-lcd",
.data = &qishenglong_gopher2b_lcd,
+ }, {
+ .compatible = "raspberrypi,7inch-dsi",
+ .data = &raspberrypi_7inch,
}, {
.compatible = "raystar,rff500f-awh-dnn",
.data = &raystar_rff500f_awh_dnn,
--
2.43.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: imx91-tqma9131: improve eMMC pad configuration
From: Sasha Levin @ 2026-04-20 13:07 UTC (permalink / raw)
To: patches, stable
Cc: Markus Niebel, Alexander Stein, Frank Li, Sasha Levin, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, linux, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
[ Upstream commit 44db7bc66eb38e85bb32777c5fd3a4e7baa84147 ]
Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve
stability and detection at low temperatures under -25°C.
Fixes: e71db39f0c7c ("arm64: dts: freescale: add initial device tree for TQMa91xx/MBa91xxCA")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
.../boot/dts/freescale/imx91-tqma9131.dtsi | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi b/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
index 5792952b7a8e1..c99d7bc168483 100644
--- a/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx91-tqma9131.dtsi
@@ -272,20 +272,20 @@ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
/* enable SION for data and cmd pad due to ERR052021 */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = /* PD | FSEL 3 | DSE X5 */
- <MX91_PAD_SD1_CLK__USDHC1_CLK 0x5be>,
+ <MX91_PAD_SD1_CLK__USDHC1_CLK 0x59e>,
/* HYS | FSEL 0 | no drive */
<MX91_PAD_SD1_STROBE__USDHC1_STROBE 0x1000>,
/* HYS | FSEL 3 | X5 */
- <MX91_PAD_SD1_CMD__USDHC1_CMD 0x400011be>,
+ <MX91_PAD_SD1_CMD__USDHC1_CMD 0x4000139e>,
/* HYS | FSEL 3 | X4 */
- <MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x4000119e>,
- <MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x4000119e>,
- <MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x4000119e>,
- <MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x4000119e>,
- <MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x4000119e>,
- <MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x4000119e>,
- <MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x4000119e>,
- <MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x4000119e>;
+ <MX91_PAD_SD1_DATA0__USDHC1_DATA0 0x4000139e>,
+ <MX91_PAD_SD1_DATA1__USDHC1_DATA1 0x4000139e>,
+ <MX91_PAD_SD1_DATA2__USDHC1_DATA2 0x4000139e>,
+ <MX91_PAD_SD1_DATA3__USDHC1_DATA3 0x4000139e>,
+ <MX91_PAD_SD1_DATA4__USDHC1_DATA4 0x4000139e>,
+ <MX91_PAD_SD1_DATA5__USDHC1_DATA5 0x4000139e>,
+ <MX91_PAD_SD1_DATA6__USDHC1_DATA6 0x4000139e>,
+ <MX91_PAD_SD1_DATA7__USDHC1_DATA7 0x4000139e>;
};
pinctrl_wdog: wdoggrp {
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: imx93-tqma9352: improve eMMC pad configuration
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Markus Niebel, Alexander Stein, Frank Li, Sasha Levin, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shawnguo, linux, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Markus Niebel <Markus.Niebel@ew.tq-group.com>
[ Upstream commit b6c94c71f349479b76fcc0ef0dc7147f3f326dff ]
Use DSE x4 an PullUp for CMD an DAT, DSE x4 and PullDown for CLK to improve
stability and detection at low temperatures under -25°C.
Fixes: 0b5fdfaa8e45 ("arm64: dts: freescale: imx93-tqma9352: set SION for cmd and data pad of USDHC")
Signed-off-by: Markus Niebel <Markus.Niebel@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
.../boot/dts/freescale/imx93-tqma9352.dtsi | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
index 82914ca148d3a..c095d7f115c21 100644
--- a/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx93-tqma9352.dtsi
@@ -270,21 +270,21 @@ MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x106
/* enable SION for data and cmd pad due to ERR052021 */
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
- /* PD | FSEL 3 | DSE X5 */
- MX93_PAD_SD1_CLK__USDHC1_CLK 0x5be
+ /* PD | FSEL 3 | DSE X4 */
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x59e
/* HYS | FSEL 0 | no drive */
MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1000
- /* HYS | FSEL 3 | X5 */
- MX93_PAD_SD1_CMD__USDHC1_CMD 0x400011be
- /* HYS | FSEL 3 | X4 */
- MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000119e
- MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000119e
- MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000119e
- MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000119e
- MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000119e
- MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000119e
- MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000119e
- MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000119e
+ /* HYS | PU | FSEL 3 | DSE X4 */
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000139e
+ /* HYS | PU | FSEL 3 | DSE X4 */
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000139e
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000139e
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000139e
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000139e
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000139e
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000139e
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000139e
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000139e
>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH] arm64: dts: ti: k3-j722s: use ti,j7200-padconf compatible
From: Richard Genoud (TI) @ 2026-04-20 13:17 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Thomas Petazzoni, Gregory CLEMENT, Thomas Richard, Udit Kumar,
Abhash Kumar, linux-arm-kernel, devicetree, linux-kernel,
Richard Genoud (TI)
From: Abhash Kumar Jha <a-kumar2@ti.com>
The pinctrl contexts for j722s should be saved and restored during
suspend-to-ram, just like it is done for j7200 and j784s4 SoCs.
Use ti,j7200-padconf compatible to save and restore pinctrl contexts during
suspend-to-ram.
Signed-off-by: Abhash Kumar Jha <a-kumar2@ti.com>
Signed-off-by: Richard Genoud (TI) <richard.genoud@bootlin.com>
---
arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
index e66330c71593..757eb6abcd72 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
@@ -242,6 +242,7 @@ &phy_gmii_sel {
};
&main_pmx0 {
+ compatible = "ti,j7200-padconf", "pinctrl-single";
main_mcan0_pins_default: main-mcan0-default-pins {
pinctrl-single,pins = <
@@ -418,6 +419,7 @@ &main_uart5 {
};
&mcu_pmx0 {
+ compatible = "ti,j7200-padconf", "pinctrl-single";
mcu_i2c0_pins_default: mcu-i2c0-default-pins {
pinctrl-single,pins = <
--
2.47.3
^ permalink raw reply related
* [PATCH] riscv: dts: starfive: jh7110: Drop CAMSS node
From: Jai Luthra @ 2026-04-20 13:18 UTC (permalink / raw)
To: Emil Renner Berthing, Conor Dooley, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Changhuang Liang, Mauro Carvalho Chehab,
Sakari Ailus, Laurent Pinchart
Cc: Krzysztof Kozlowski, linux-riscv, devicetree, linux-kernel,
Jai Luthra
The starfive-camss driver and bindings were dropped, as they were no
longer being worked upon for destaging.
Drop the relevant node as well to avoid the following build warning:
"failed to match any schema with compatible: ['starfive,jh7110-camss']"
Fixes: 644673fc8fb04 ("media: dt-bindings: Drop starfive,jh7110-camss from staging")
Reported-by: Conor Dooley <conor@kernel.org>
Closes: https://lore.kernel.org/all/20260420-very-cartel-645595ffd1c7@spud/
Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
---
Ideally this patch should have gone in the original series, before the
one that dropped the bindings which is now merged in mainline.
I've added a Fixes tag so it gets picked in the RC cycles for 7.1.
---
arch/riscv/boot/dts/starfive/jh7110-common.dtsi | 27 +-----------------------
arch/riscv/boot/dts/starfive/jh7110.dtsi | 28 -------------------------
2 files changed, 1 insertion(+), 54 deletions(-)
diff --git a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
index 8cfe8033305d80cbe6179ed26601ca057ee00f16..a7a1c09a2c9075711f3a214a49618911fdc7b421 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-common.dtsi
@@ -135,29 +135,6 @@ &tdm_ext {
clock-frequency = <49152000>;
};
-&camss {
- assigned-clocks = <&ispcrg JH7110_ISPCLK_DOM4_APB_FUNC>,
- <&ispcrg JH7110_ISPCLK_MIPI_RX0_PXL>;
- assigned-clock-rates = <49500000>, <198000000>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- };
-
- port@1 {
- reg = <1>;
-
- camss_from_csi2rx: endpoint {
- remote-endpoint = <&csi2rx_to_camss>;
- };
- };
- };
-};
-
&csi2rx {
assigned-clocks = <&ispcrg JH7110_ISPCLK_VIN_SYS>;
assigned-clock-rates = <297000000>;
@@ -175,9 +152,7 @@ port@0 {
port@1 {
reg = <1>;
- csi2rx_to_camss: endpoint {
- remote-endpoint = <&camss_from_csi2rx>;
- };
+ /* remote CAMSS endpoint */
};
};
};
diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi b/arch/riscv/boot/dts/starfive/jh7110.dtsi
index 6e56e9d20bb064e86b57a92d4cb05be330cca01a..9c3e4598747eb5541effe697044484715569a285 100644
--- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
@@ -1199,34 +1199,6 @@ csi_phy: phy@19820000 {
#phy-cells = <0>;
};
- camss: isp@19840000 {
- compatible = "starfive,jh7110-camss";
- reg = <0x0 0x19840000 0x0 0x10000>,
- <0x0 0x19870000 0x0 0x30000>;
- reg-names = "syscon", "isp";
- clocks = <&ispcrg JH7110_ISPCLK_DOM4_APB_FUNC>,
- <&ispcrg JH7110_ISPCLK_ISPV2_TOP_WRAPPER_C>,
- <&ispcrg JH7110_ISPCLK_DVP_INV>,
- <&ispcrg JH7110_ISPCLK_VIN_P_AXI_WR>,
- <&ispcrg JH7110_ISPCLK_MIPI_RX0_PXL>,
- <&syscrg JH7110_SYSCLK_ISP_TOP_CORE>,
- <&syscrg JH7110_SYSCLK_ISP_TOP_AXI>;
- clock-names = "apb_func", "wrapper_clk_c", "dvp_inv",
- "axiwr", "mipi_rx0_pxl", "ispcore_2x",
- "isp_axi";
- resets = <&ispcrg JH7110_ISPRST_ISPV2_TOP_WRAPPER_P>,
- <&ispcrg JH7110_ISPRST_ISPV2_TOP_WRAPPER_C>,
- <&ispcrg JH7110_ISPRST_VIN_P_AXI_RD>,
- <&ispcrg JH7110_ISPRST_VIN_P_AXI_WR>,
- <&syscrg JH7110_SYSRST_ISP_TOP>,
- <&syscrg JH7110_SYSRST_ISP_TOP_AXI>;
- reset-names = "wrapper_p", "wrapper_c", "axird",
- "axiwr", "isp_top_n", "isp_top_axi";
- power-domains = <&pwrc JH7110_PD_ISP>;
- interrupts = <92>, <87>, <90>, <88>;
- status = "disabled";
- };
-
voutcrg: clock-controller@295c0000 {
compatible = "starfive,jh7110-voutcrg";
reg = <0x0 0x295c0000 0x0 0x10000>;
---
base-commit: c1f49dea2b8f335813d3b348fd39117fb8efb428
change-id: 20260420-starfive_camss_use-7a229c330e71
Best regards,
--
Jai Luthra <jai.luthra@ideasonboard.com>
^ permalink raw reply related
* [PATCH] arm64: dts: renesas: rz-smarc-du-adv7513: Simplify DU port configuration
From: Prabhakar @ 2026-04-20 13:22 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-renesas-soc, devicetree, linux-kernel, Prabhakar, Biju Das,
Fabrizio Castro, Lad Prabhakar
From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
The SoC dtsi already defines the du node with its ports hierarchy,
including the du_out_rgb endpoint node under port@0. There is no need
to redefine the entire ports/port@0 structure in the board-level dtsi.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
---
.../boot/dts/renesas/rz-smarc-du-adv7513.dtsi | 15 +++------------
1 file changed, 3 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
index f5412578ee65..dbe16908b260 100644
--- a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
+++ b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
@@ -24,19 +24,10 @@ &du {
pinctrl-names = "default";
status = "okay";
+};
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
-
- du_out_rgb: endpoint {
- remote-endpoint = <&adv7513_in>;
- };
- };
- };
+&du_out_rgb {
+ remote-endpoint = <&adv7513_in>;
};
&ADV7513_PARENT_I2C {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Krzysztof Kozlowski @ 2026-04-20 13:23 UTC (permalink / raw)
To: Qiang Yu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aeXUZ1uSEJ9InUtw@hu-qianyu-lv.qualcomm.com>
On Mon, Apr 20, 2026 at 12:23:19AM -0700, Qiang Yu wrote:
> On Fri, Apr 17, 2026 at 11:18:08AM +0200, Krzysztof Kozlowski wrote:
> > On Wed, Apr 15, 2026 at 07:58:13PM -0700, Qiang Yu wrote:
> > > On Wed, Apr 15, 2026 at 09:50:28AM +0200, Krzysztof Kozlowski wrote:
> > > > On Sun, Apr 12, 2026 at 11:25:56PM -0700, Qiang Yu wrote:
> > > > > The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
> > > > >
> > > > > 1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
> > > > > 4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
> > > > > 2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
> > > > > follower to form a single 8-lane PCIe Gen5 interface
> > > > >
> > > > > In bifurcation mode, the hardware design requires controlling additional
> > > > > resources beyond the standard pcie3a PHY configuration:
> > > > >
> > > > > - pcie3b's aux_clk (phy_b_aux)
> > > > > - pcie3b's phy_gdsc power domain
> > > > > - pcie3b's bcr/nocsr reset
> > > > >
> > > > > Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
> > > > > 8-lane bifurcation configuration.
> > > >
> > > > Do you describe PCI3A or PCI3B or something combined PCI3?
> > >
> > > I describe a single x8 PHY with resources from both the pcie3a and pcie3b
> > > PHY blocks for x8 operation.
> > >
> > > >
> > > > >
> > > > > The phy_b_aux clock is used as the 6th clock instead of pipediv2,
> > > > > requiring the clock-names enum to be extended to support both
> > > > > [phy_b_aux, pipediv2] options at index 5. This follows the existing
> > > > > pattern used for [rchng, refgen] clocks at index 3.
> > > > >
> > > > > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > > > > ---
> > > > > .../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 ++++++++++++++++++----
> > > > > 1 file changed, 45 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..14eba5d705b1956c1bb00cc8c95171ed6488299b 100644
> > > > > --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
> > > > > @@ -18,6 +18,7 @@ properties:
> > > > > enum:
> > > > > - qcom,glymur-qmp-gen4x2-pcie-phy
> > > > > - qcom,glymur-qmp-gen5x4-pcie-phy
> > > > > + - qcom,glymur-qmp-gen5x8-pcie-phy
> > > >
> > > > That's the same device as 5x4, no? One device, one compatible and this
> > > > suggests you will have three PCI phys in the DT - two 5x4 and one 5x8?
> > > >
> > >
> > > It is not the same as the 5x4 PHY. In DT, we model three PHY nodes:
> > > phy_3a (1x4), phy_3b (1x4), and a separate phy_1x8 node for x8 mode.
> >
> > OK, that's what I wanted to hear. And that's what should not be done,
> >
> > You should not have a separate node for the same hardware. First, DTC
> > will give you a W=1 warning, although warning itself should be moved to
> > W=2.
> >
> > Second, the warning tells important story - same hardware is described
> > twice.
> >
> > You only need phy_3a and phy_3b, so only two in total.
>
> We can keep only phy_3a and phy_3b, but still add new compatible
> qcom,glymur-qmp-gen5x8-pcie-phy in binding, right?
>
> For boards that support pcie3a(1x4) + pcie3b(1x4), DTS would be:
>
> pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
> pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
>
> For boards that support 1x8, we would override pcie3a_phy with:
>
> pcie3a_phy { compatible = "qcom,glymur-qmp-gen5x8-pcie-phy"; /* additional resources */ };
> pcie3b_phy { compatible = "qcom,glymur-qmp-gen5x4-pcie-phy"; };
>
> This still uses only two PHY nodes and DTC will not report warning.
IMO, you do not need another compatible. Device is exactly the same. If
wiring on the board differs, e.g. you have 8x instead of 4x, you:
1. disable unused 3B phy.
2. Add to 3A missing resources or the phandle to companion node.
At least that is what I tought till now, when I opened the HPG/manual
for Glymur phy. Someone skipped important information when PCIe PHY was
upstreamed first and glymur.dtsi already got PHY 3B described.
Reminder: writing bindings asks you explicitly to post COMPLETE
bindings.
If you posted COMPLETE bindings we would question all this and you would
have to check in user manual that this is actually ONE device.
There is no 5x4 phy 3A and 3B, at least HPG is pretty clear here.
And you should start with that.
But you posted first incomplete binding, hiding the rest and now you
have 5x4 merged into DTSI.
So let's rephrase based on manual:
You have only one PCIE phy3. Not 3A + 3B. That one phy3 can be
configured by consumers (board) differently, e.g. by requesting 8-lane
or twice 4-lane phys.
Let me send correction note for glymur.dtsi.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH AUTOSEL 7.0-6.12] arm64: tegra: Fix snps,blen properties
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Thierry Reding, Sasha Levin, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Thierry Reding <treding@nvidia.com>
[ Upstream commit 51f10c527a63dc4a71bce4b40fc53eee78bbbd52 ]
The snps,blen property of stmmac-axi-config nodes needs to have 7
entries in total, with unsupported burst lengths listed as 0.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for my analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: `arm64: tegra` (ARM64 device tree, Tegra SoC)
- Action verb: "Fix" — direct bug fix language
- Summary: Fix the `snps,blen` DT properties for MGBE Ethernet
controllers
- Record: [arm64: tegra] [fix] [correcting snps,blen DT property to have
required 7 entries]
**Step 1.2: Tags**
- `Signed-off-by: Thierry Reding <treding@nvidia.com>` — Author is the
Tegra platform maintainer at NVIDIA.
- No Fixes: tag, no Cc: stable, no Reported-by (expected for auto-
selection candidates).
- Record: No notable tags beyond authorship. Author is the subsystem
maintainer.
**Step 1.3: Commit Body**
- States: "The snps,blen property of stmmac-axi-config nodes needs to
have 7 entries in total, with unsupported burst lengths listed as 0."
- This describes a DT schema violation — the property had 4 entries but
the driver requires 7.
- Record: Bug is a malformed DT property that doesn't match the driver's
expectation.
**Step 1.4: Hidden Bug Fix Detection**
- This is NOT a hidden fix — it's explicitly labeled "Fix." The
underlying bug is that `of_property_read_u32_array(np, "snps,blen",
axi_blen, 7)` fails silently when the property only has 4 entries,
leaving the stack buffer uninitialized.
- Record: Direct bug fix, not disguised.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- 1 file changed: `arch/arm64/boot/dts/nvidia/tegra234.dtsi`
- 3 lines changed (each identical):
- `snps,blen = <256 128 64 32>;` → `snps,blen = <256 128 64 32 0 0
0>;`
- Affects MGBE0, MGBE1, MGBE2 stmmac-axi-config nodes.
- Record: Single DT file, 3 identical one-line changes. Scope:
minimal/surgical.
**Step 2.2: Code Flow**
- Before: DT property has 4 u32 entries.
- After: DT property has 7 u32 entries (3 trailing zeros for unsupported
burst lengths).
- The stmmac driver calls `of_property_read_u32_array(np, "snps,blen",
axi_blen, AXI_BLEN)` where `AXI_BLEN = 7`. With only 4 entries,
`of_find_property_value_of_size()` checks `prop->length (16) < min
(28)` and returns `-EOVERFLOW`. The stack array `axi_blen[7]` is never
written. Then `stmmac_axi_blen_to_mask()` processes uninitialized
stack data.
**Step 2.3: Bug Mechanism**
- Category: **Uninitialized data** / **incorrect DT specification**
- Mechanism: The DT property is too short, causing
`of_property_read_u32_array()` to fail, leaving a stack buffer
uninitialized. The uninitialized data is then used to configure the
AXI DMA burst length register for network hardware.
- Record: Uninitialized stack data used for hardware DMA configuration.
The fix ensures the property has the correct count.
**Step 2.4: Fix Quality**
- Obviously correct: all other DT files using `snps,blen` have exactly 7
entries (verified by grep across all arm64 DT files).
- Minimal/surgical: 3 identical one-line changes.
- Zero regression risk: adding trailing zeros only enables the driver to
read the property successfully, and zero entries are explicitly
skipped by `stmmac_axi_blen_to_mask()`.
- Record: Fix is obviously correct, minimal, zero regression risk.
## PHASE 3: GIT HISTORY
**Step 3.1: Blame**
- The buggy `snps,blen = <256 128 64 32>` was introduced by commit
`81695da63b977` ("arm64: tegra: Add AXI configuration for Tegra234
MGBE") by Thierry Reding, dated 2024-02-21, merged in v6.9.
- Record: Bug introduced in v6.9 by the same author who is now fixing
it.
**Step 3.2: Fixes tag**
- No Fixes: tag present. The implicit fix target is `81695da63b977`.
**Step 3.3: File History**
- Recent changes to `tegra234.dtsi` are mostly DT cleanup/additions. No
related fixes.
- Record: Standalone fix, no prerequisites.
**Step 3.4: Author**
- Thierry Reding is the Tegra platform maintainer at NVIDIA. He wrote
the original buggy commit and is now fixing it.
- Record: Subsystem maintainer self-fix.
**Step 3.5: Dependencies**
- None. The fix is a pure DT property value change that applies
independently.
- Record: No dependencies, applies cleanly standalone.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1: Original Submission**
- Found via web search: patch is `[PATCH 09/10]` in a series "dt-
bindings: Various cleanups for Tegra-related bindings" posted
2026-02-23.
- Part of a v3 cleanup series. While most patches in the series are DT
binding cleanups, this specific patch (09/10) is a genuine bug fix.
- Record: Part of a larger DT cleanup series, but this patch is an
independent bug fix.
**Step 4.2: Reviewers**
- b4 dig found the original commit (81695da63b977) was reviewed and
tested by Jon Hunter (NVIDIA Tegra co-maintainer). The fix itself is
straightforward enough that formal review was likely implicit.
- Record: Original buggy code was reviewed by Jon Hunter.
**Step 4.3-4.5: Bug Reports / Stable History**
- No specific bug report found. Likely discovered by the author during
code review / DT validation.
- No prior stable discussion found.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1-5.4: Key Functions**
- `stmmac_axi_setup()` in `stmmac_platform.c` parses the DT property.
- Called during stmmac platform driver probe for any device using
`snps,axi-config` DT phandle.
- `stmmac_axi_blen_to_mask()` converts the burst length array to
register value.
- The register value is written to hardware in `dwxgmac2_dma_init()` /
`dwmac4_dma_init()` / `dwmac1000_dma_init()`.
- Impact: Affects AXI DMA configuration for MGBE Ethernet on Tegra234.
**Step 5.5: Similar Patterns**
- All other arm64 DT files consistently use 7 entries for `snps,blen`.
Tegra234 was the ONLY outlier with 4 entries.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable**
- Commit `81695da63b977` was introduced in v6.9. It exists in stable
trees v6.12.y and any newer LTS branches.
- It does NOT exist in v6.6.y (confirmed via `git merge-base --is-
ancestor`).
- Record: Bug affects v6.9+ stable trees (v6.12.y at minimum).
**Step 6.2: Backport Complications**
- Pure DT change with no code dependencies. Should apply cleanly.
- Record: Clean apply expected.
**Step 6.3: Related Fixes**
- No prior fix for this issue found in any tree.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem**
- ARM64 Device Tree for Tegra234 MGBE (Multi-Gigabit Ethernet).
- Criticality: IMPORTANT — affects Tegra234 network hardware users
(NVIDIA Jetson AGX Orin, etc.).
- Record: [arm64/tegra DT] [IMPORTANT — Jetson platform network
hardware]
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected Users**
- Users of NVIDIA Tegra234 platforms (Jetson AGX Orin) using MGBE
Ethernet controllers.
- Platform-specific but widely deployed in industrial/embedded
applications.
**Step 8.2: Trigger Conditions**
- Triggered on every boot when the MGBE driver probes. No special
configuration needed.
- The AXI burst length read fails silently, so uninitialized data
configures DMA hardware.
**Step 8.3: Failure Mode**
- Uninitialized stack data used for DMA hardware configuration.
- Could result in suboptimal network performance, potential DMA errors,
or undefined hardware behavior depending on what stack values happen
to be.
- Severity: **HIGH** (hardware misconfiguration from uninitialized data,
affecting network DMA)
**Step 8.4: Risk-Benefit**
- BENEFIT: High — fixes broken AXI DMA configuration for 3 MGBE Ethernet
controllers on Tegra234.
- RISK: Very low — 3 identical one-line DT property changes, adding
trailing zeros, no code change.
- Record: Very favorable risk-benefit ratio.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence Summary**
FOR backporting:
- Fixes real bug: `of_property_read_u32_array()` fails with only 4/7
entries, leading to uninitialized stack data being used for hardware
DMA configuration
- Minimal, surgical fix: 3 identical one-line DT changes
- Obviously correct: all other DT files use 7 entries
- Written by subsystem maintainer (Thierry Reding, NVIDIA Tegra
maintainer)
- Zero regression risk: trailing zeros are explicitly handled ("Burst
values of zero must be skipped")
- Applies to v6.12.y+ stable trees
AGAINST backporting:
- No explicit user report of symptoms (could mean it works by luck with
stack data)
- Part of a larger series (but this patch is independent)
**Step 9.2: Stable Rules Checklist**
1. Obviously correct? **YES** — all other DT files have 7 entries
2. Fixes a real bug? **YES** — uninitialized data used for HW
configuration
3. Important issue? **YES** — hardware DMA misconfiguration
4. Small and contained? **YES** — 3 one-line changes in 1 DT file
5. No new features? **YES** — pure DT fix
6. Can apply to stable? **YES** — clean DT-only change
**Step 9.3: Exception Category**
- DT update fixing existing hardware description — automatic YES
category
## Verification
- [Phase 1] Parsed subject: "Fix" verb, arm64 tegra subsystem, snps,blen
property
- [Phase 2] Diff: 3 lines changed in tegra234.dtsi, each adds `0 0 0` to
snps,blen property
- [Phase 2] Verified AXI_BLEN=7 in `include/linux/stmmac.h` line 109
- [Phase 2] Verified `of_property_read_u32_array()` calls
`of_find_property_value_of_size()` with min=28 bytes; property has 16
bytes (4 entries), so it returns -EOVERFLOW
- [Phase 2] Verified `stmmac_axi_blen_to_mask()` skips zero entries
("Burst values of zero must be skipped")
- [Phase 3] git blame: buggy code from 81695da63b977 (v6.9), author:
Thierry Reding
- [Phase 3] git merge-base: confirmed 81695da63b977 is in v6.12 but not
v6.6
- [Phase 4] b4 dig: found original commit submission at lore (patch-id
match)
- [Phase 4] Web search: fix is PATCH 09/10 of "dt-bindings: Various
cleanups for Tegra-related bindings"
- [Phase 5] Verified all other arm64 DT snps,blen entries have exactly 7
values (grep across arch/arm64/boot/dts)
- [Phase 5] Traced call chain: stmmac_axi_setup →
of_property_read_u32_array → of_find_property_value_of_size
- [Phase 6] Bug exists in v6.9+ stable trees
- [Phase 8] Failure mode: uninitialized stack data used for AXI DMA
register, severity HIGH
**YES**
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 850c473235e36..04a95b6658caa 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -3621,7 +3621,7 @@ ethernet@6800000 {
snps,axi-config = <&mgbe0_axi_setup>;
mgbe0_axi_setup: stmmac-axi-config {
- snps,blen = <256 128 64 32>;
+ snps,blen = <256 128 64 32 0 0 0>;
snps,rd_osr_lmt = <63>;
snps,wr_osr_lmt = <63>;
};
@@ -3663,7 +3663,7 @@ ethernet@6900000 {
snps,axi-config = <&mgbe1_axi_setup>;
mgbe1_axi_setup: stmmac-axi-config {
- snps,blen = <256 128 64 32>;
+ snps,blen = <256 128 64 32 0 0 0>;
snps,rd_osr_lmt = <63>;
snps,wr_osr_lmt = <63>;
};
@@ -3705,7 +3705,7 @@ ethernet@6a00000 {
snps,axi-config = <&mgbe2_axi_setup>;
mgbe2_axi_setup: stmmac-axi-config {
- snps,blen = <256 128 64 32>;
+ snps,blen = <256 128 64 32 0 0 0>;
snps,rd_osr_lmt = <63>;
snps,wr_osr_lmt = <63>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Reserve full Gunyah metadata region
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Loic Poulain, Konrad Dybcio, Dmitry Baryshkov, Bjorn Andersson,
Sasha Levin, konradybcio, robh, krzk+dt, conor+dt, quic_jingyw,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Loic Poulain <loic.poulain@oss.qualcomm.com>
[ Upstream commit 85d98669fa7f1d3041d962515e45ee6e392db6f8 ]
We observe spurious "Synchronous External Abort" exceptions
(ESR=0x96000010) and kernel crashes on Monaco-based platforms.
These faults are caused by the kernel inadvertently accessing
hypervisor-owned memory that is not properly marked as reserved.
>From boot log, The Qualcomm hypervisor reports the memory range
at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned:
qhee_hyp_assign_remove_memory: 0x91a80000/0x80000 -> ret 0
However, the EFI memory map provided by firmware only reserves the
subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion
(0x91a88000–0x91afffff) is incorrectly reported as conventional
memory (from efi debug):
efi: 0x000091a40000-0x000091a87fff [Reserved...]
efi: 0x000091a88000-0x0000938fffff [Conventional...]
As a result, the allocator may hand out PFNs inside the hypervisor
owned region, causing fatal aborts when the kernel accesses those
addresses.
Add a reserved-memory carveout for the Gunyah hypervisor metadata
at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not
map or allocate from this area.
For the record:
Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC)
UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1
Fixes: 7be190e4bdd2 ("arm64: dts: qcom: add QCS8300 platform")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260302142603.1113355-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
arch/arm64/boot/dts/qcom/qcs8300.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
index b8d4a75baee22..7a4c3e872d8ee 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
@@ -756,6 +756,11 @@ smem_mem: smem@90900000 {
hwlocks = <&tcsr_mutex 3>;
};
+ gunyah_md_mem: gunyah-md-region@91a80000 {
+ reg = <0x0 0x91a80000 0x0 0x80000>;
+ no-map;
+ };
+
lpass_machine_learning_mem: lpass-machine-learning-region@93b00000 {
reg = <0x0 0x93b00000 0x0 0xf00000>;
no-map;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB
From: Sasha Levin @ 2026-04-20 13:18 UTC (permalink / raw)
To: patches, stable
Cc: Mihai Sain, Claudiu Beznea, Sasha Levin, nicolas.ferre,
alexandre.belloni, robh, krzk+dt, conor+dt, varshini.rajendran,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Mihai Sain <mihai.sain@microchip.com>
[ Upstream commit 907150bbe566e23714a25d7bcb910f236c3c44c0 ]
The pioB controller on the SAM9X7 SoC actually supports 27 GPIO lines.
The previous value of 26 was incorrect, leading to the last pin being
unavailable for use by the GPIO subsystem.
Update the #gpio-lines property to reflect
the correct hardware specification.
Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC")
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Link: https://lore.kernel.org/r/20260209090735.2016-1-mihai.sain@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
arch/arm/boot/dts/microchip/sam9x7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/microchip/sam9x7.dtsi b/arch/arm/boot/dts/microchip/sam9x7.dtsi
index 46dacbbd201dd..d242d7a934d0f 100644
--- a/arch/arm/boot/dts/microchip/sam9x7.dtsi
+++ b/arch/arm/boot/dts/microchip/sam9x7.dtsi
@@ -1226,7 +1226,7 @@ pioB: gpio@fffff600 {
interrupt-controller;
#gpio-cells = <2>;
gpio-controller;
- #gpio-lines = <26>;
+ #gpio-lines = <27>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 3>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: qcom: hamoa/x1: fix idle exit latency
From: Sasha Levin @ 2026-04-20 13:19 UTC (permalink / raw)
To: patches, stable
Cc: Daniel J Blueman, Konrad Dybcio, Bjorn Andersson, Sasha Levin,
konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Daniel J Blueman <daniel@quora.org>
[ Upstream commit 3ecea84d2b90bbf934d5ca75514fa902fd71e03f ]
Designs based on the Qualcomm X1 Hamoa reference platform report:
driver: Idle state 1 target residency too low
This is because the declared X1 idle entry plus exit latency of 680us
exceeds the declared minimum 600us residency time:
entry-latency-us = <180>;
exit-latency-us = <500>;
min-residency-us = <600>;
Fix this to be 320us so the sum of the entry and exit latencies matches
the downstream 500us exit latency, as directed by Maulik.
Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100.
Fixes: 2e65616ef07f ("arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers")
Signed-off-by: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260220124626.8611-1-daniel@quora.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 6d97329995fe7..efe8d5e7079fe 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -281,7 +281,7 @@ cluster_c4: cpu-sleep-0 {
idle-state-name = "ret";
arm,psci-suspend-param = <0x00000004>;
entry-latency-us = <180>;
- exit-latency-us = <500>;
+ exit-latency-us = <320>;
min-residency-us = <600>;
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v14 2/7] qcom-tgu: Add TGU driver
From: Jie Gan @ 2026-04-20 13:28 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260417073336.2712426-3-songwei.chai@oss.qualcomm.com>
On 4/17/2026 3:33 PM, Songwei Chai wrote:
> Add driver to support device TGU (Trigger Generation Unit).
> TGU is a Data Engine which can be utilized to sense a plurality of
> signals and create a trigger into the CTI or generate interrupts to
> processors. Add probe/enable/disable functions for tgu.
>
LGTM.
Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
> drivers/Makefile | 1 +
> drivers/hwtracing/Kconfig | 2 +
> drivers/hwtracing/qcom/Kconfig | 20 ++
> drivers/hwtracing/qcom/Makefile | 3 +
> drivers/hwtracing/qcom/tgu.c | 193 ++++++++++++++++++
> drivers/hwtracing/qcom/tgu.h | 51 +++++
> 7 files changed, 279 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> create mode 100644 drivers/hwtracing/qcom/Kconfig
> create mode 100644 drivers/hwtracing/qcom/Makefile
> create mode 100644 drivers/hwtracing/qcom/tgu.c
> create mode 100644 drivers/hwtracing/qcom/tgu.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> new file mode 100644
> index 000000000000..f877a00fcaa5
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -0,0 +1,9 @@
> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
> +Date: April 2026
> +KernelVersion: 7.1
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (RW) Set/Get the enable/disable status of TGU
> + Accepts only one of the 2 values - 0 or 1.
> + 0 : disable TGU.
> + 1 : enable TGU.
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 53fbd2e0acdd..82b712a12a26 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
> obj-$(CONFIG_USB4) += thunderbolt/
> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
> obj-y += hwtracing/intel_th/
> +obj-y += hwtracing/qcom/
> obj-$(CONFIG_STM) += hwtracing/stm/
> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
> obj-y += android/
> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
> index 911ee977103c..8a640218eed8 100644
> --- a/drivers/hwtracing/Kconfig
> +++ b/drivers/hwtracing/Kconfig
> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
> source "drivers/hwtracing/ptt/Kconfig"
>
> +source "drivers/hwtracing/qcom/Kconfig"
> +
> endmenu
> diff --git a/drivers/hwtracing/qcom/Kconfig b/drivers/hwtracing/qcom/Kconfig
> new file mode 100644
> index 000000000000..5c94c75ffa39
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Kconfig
> @@ -0,0 +1,20 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# QCOM specific hwtracing drivers
> +#
> +menu "Qualcomm specific hwtracing drivers"
> +
> +config QCOM_TGU
> + tristate "QCOM Trigger Generation Unit driver"
> + depends on ARCH_QCOM || COMPILE_TEST
> + depends on ARM_AMBA
> + help
> + This driver provides support for Trigger Generation Unit that is
> + used to detect patterns or sequences on a given set of signals.
> + TGU is used to monitor a particular bus within a given region to
> + detect illegal transaction sequences or slave responses. It is also
> + used to monitor a data stream to detect protocol violations and to
> + provide a trigger point for centering data around a specific event
> + within the trace data buffer.
> +
> +endmenu
> diff --git a/drivers/hwtracing/qcom/Makefile b/drivers/hwtracing/qcom/Makefile
> new file mode 100644
> index 000000000000..5a0a868c1ea0
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_QCOM_TGU) += tgu.o
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> new file mode 100644
> index 000000000000..49c8f710b931
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -0,0 +1,193 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/amba/bus.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_runtime.h>
> +
> +#include "tgu.h"
> +
> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + /* Enable TGU to program the triggers */
> + writel(1, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +}
> +
> +static int tgu_enable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + drvdata->enabled = true;
> +
> + tgu_write_all_hw_regs(drvdata);
> +
> + return 0;
> +}
> +
> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + writel(0, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +
> + drvdata->enabled = false;
> +}
> +
> +static void tgu_disable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (!drvdata->enabled)
> + return;
> +
> + tgu_do_disable(drvdata);
> +}
> +
> +static ssize_t enable_tgu_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + bool enabled;
> +
> + guard(spinlock)(&drvdata->lock);
> + enabled = drvdata->enabled;
> +
> + return sysfs_emit(buf, "%d\n", !!enabled);
> +}
> +
> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU) triggers. */
> +static ssize_t enable_tgu_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + unsigned long val;
> + int ret;
> +
> + ret = kstrtoul(buf, 0, &val);
> + if (ret || val > 1)
> + return -EINVAL;
> +
> + if (val) {
> + scoped_guard(spinlock, &drvdata->lock) {
> + if (drvdata->enabled)
> + return -EBUSY;
> + }
> +
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> +
> + ret = tgu_enable(dev);
> + if (ret) {
> + pm_runtime_put(dev);
> + return ret;
> + }
> + } else {
> + scoped_guard(spinlock, &drvdata->lock) {
> + if (!drvdata->enabled)
> + return -EINVAL;
> + }
> +
> + tgu_disable(dev);
> + pm_runtime_put(dev);
> + }
> +
> + return size;
> +}
> +static DEVICE_ATTR_RW(enable_tgu);
> +
> +static struct attribute *tgu_common_attrs[] = {
> + &dev_attr_enable_tgu.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group tgu_common_grp = {
> + .attrs = tgu_common_attrs,
> + NULL,
> +};
> +
> +static const struct attribute_group *tgu_attr_groups[] = {
> + &tgu_common_grp,
> + NULL,
> +};
> +
> +static int tgu_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + struct device *dev = &adev->dev;
> + struct tgu_drvdata *drvdata;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->dev = &adev->dev;
> + dev_set_drvdata(dev, drvdata);
> +
> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
> + if (IS_ERR(drvdata->base))
> + return PTR_ERR(drvdata->base);
> +
> + spin_lock_init(&drvdata->lock);
> +
> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
> + if (ret) {
> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
> + return ret;
> + }
> +
> + drvdata->enabled = false;
> +
> + pm_runtime_put(&adev->dev);
> +
> + return 0;
> +}
> +
> +static void tgu_remove(struct amba_device *adev)
> +{
> + struct device *dev = &adev->dev;
> +
> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
> +
> + tgu_disable(dev);
> +}
> +
> +static const struct amba_id tgu_ids[] = {
> + {
> + .id = 0x000f0e00,
> + .mask = 0x000fffff,
> + },
> + { 0, 0, NULL },
> +};
> +
> +MODULE_DEVICE_TABLE(amba, tgu_ids);
> +
> +static struct amba_driver tgu_driver = {
> + .drv = {
> + .name = "qcom-tgu",
> + .suppress_bind_attrs = true,
> + },
> + .probe = tgu_probe,
> + .remove = tgu_remove,
> + .id_table = tgu_ids,
> +};
> +
> +module_amba_driver(tgu_driver);
> +
> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
> new file mode 100644
> index 000000000000..dd7533b9d735
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _QCOM_TGU_H
> +#define _QCOM_TGU_H
> +
> +/* Register addresses */
> +#define TGU_CONTROL 0x0000
> +#define TGU_LAR 0xfb0
> +#define TGU_UNLOCK_OFFSET 0xc5acce55
> +
> +static inline void TGU_LOCK(void __iomem *addr)
> +{
> + do {
> + /* Wait for things to settle */
> + mb();
> + writel_relaxed(0x0, addr + TGU_LAR);
> + } while (0);
> +}
> +
> +static inline void TGU_UNLOCK(void __iomem *addr)
> +{
> + do {
> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
> + /* Make sure everyone has seen this */
> + mb();
> + } while (0);
> +}
> +
> +/**
> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator Unit)
> + * @base: Memory-mapped base address of the TGU device
> + * @dev: Pointer to the associated device structure
> + * @lock: Spinlock for handling concurrent access to private data
> + * @enabled: Flag indicating whether the TGU device is enabled
> + *
> + * This structure defines the data associated with a TGU device,
> + * including its base address, device pointers, clock, spinlock for
> + * synchronization, trigger data pointers, maximum limits for various
> + * trigger-related parameters, and enable status.
> + */
> +struct tgu_drvdata {
> + void __iomem *base;
> + struct device *dev;
> + spinlock_t lock;
> + bool enabled;
> +};
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v14 7/7] qcom-tgu: Add reset node to initialize
From: Jie Gan @ 2026-04-20 13:29 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260417073336.2712426-8-songwei.chai@oss.qualcomm.com>
On 4/17/2026 3:33 PM, Songwei Chai wrote:
> Add reset node to initialize the value of
> priority/condition_decode/condition_select/timer/counter nodes.
>
LGTM.
Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 7 ++
> drivers/hwtracing/qcom/tgu.c | 74 +++++++++++++++++++
> 2 files changed, 81 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> index 7a3573e03e27..a6b6019c8ef1 100644
> --- a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -42,3 +42,10 @@ KernelVersion: 7.1
> Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> Description:
> (RW) Set/Get the counter value with specific step for TGU.
> +
> +What: /sys/bus/amba/devices/<tgu-name>/reset_tgu
> +Date: April 2026
> +KernelVersion: 7.1
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (Write) Write 1 to reset the dataset for TGU.
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> index 6d5bf2621cb0..9fb51f2a912f 100644
> --- a/drivers/hwtracing/qcom/tgu.c
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -420,8 +420,82 @@ static ssize_t enable_tgu_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(enable_tgu);
>
> +/* reset_tgu_store - Reset Trace and Gating Unit (TGU) configuration. */
> +static ssize_t reset_tgu_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t size)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + struct value_table *vt = drvdata->value_table;
> + u32 *cond_decode = drvdata->value_table->condition_decode;
> + unsigned long value;
> + int i, j, ret;
> +
> + if (kstrtoul(buf, 0, &value) || value != 1)
> + return -EINVAL;
> +
> + spin_lock(&drvdata->lock);
> + if (!drvdata->enabled) {
> + spin_unlock(&drvdata->lock);
> + ret = pm_runtime_resume_and_get(drvdata->dev);
> + if (ret)
> + return ret;
> + spin_lock(&drvdata->lock);
> + }
> +
> + tgu_do_disable(drvdata);
> +
> + if (vt->priority) {
> + size_t size = MAX_PRIORITY * drvdata->num_step *
> + drvdata->num_reg * sizeof(unsigned int);
> + memset(vt->priority, 0, size);
> + }
> +
> + if (vt->condition_decode) {
> + size_t size = drvdata->num_condition_decode *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_decode, 0, size);
> + }
> +
> + /* Initialize all condition registers to NOT(value=0x1000000) */
> + for (i = 0; i < drvdata->num_step; i++) {
> + for (j = 0; j < drvdata->num_condition_decode; j++) {
> + cond_decode[calculate_array_location(drvdata, i,
> + TGU_CONDITION_DECODE, j)] = 0x1000000;
> + }
> + }
> +
> + if (vt->condition_select) {
> + size_t size = drvdata->num_condition_select *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_select, 0, size);
> + }
> +
> + if (vt->timer) {
> + size_t size = (drvdata->num_step) * (drvdata->num_timer) *
> + sizeof(unsigned int);
> + memset(vt->timer, 0, size);
> + }
> +
> + if (vt->counter) {
> + size_t size = (drvdata->num_step) * (drvdata->num_counter) *
> + sizeof(unsigned int);
> + memset(vt->counter, 0, size);
> + }
> +
> + spin_unlock(&drvdata->lock);
> +
> + dev_dbg(dev, "Qualcomm-TGU reset complete\n");
> +
> + pm_runtime_put(drvdata->dev);
> +
> + return size;
> +}
> +static DEVICE_ATTR_WO(reset_tgu);
> +
> static struct attribute *tgu_common_attrs[] = {
> &dev_attr_enable_tgu.attr,
> + &dev_attr_reset_tgu.attr,
> NULL,
> };
>
^ permalink raw reply
* [PATCH AUTOSEL 6.18] arm64: dts: imx93-9x9-qsb: change usdhc tuning step for eMMC and SD
From: Sasha Levin @ 2026-04-20 13:20 UTC (permalink / raw)
To: patches, stable
Cc: Luke Wang, Frank Li, Sasha Levin, robh, krzk+dt, conor+dt,
shawnguo, peng.fan, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Luke Wang <ziniu.wang_1@nxp.com>
[ Upstream commit 08903184553def7ba1ad6ba4fa8afe1ba2ee0a21 ]
During system resume, the following errors occurred:
[ 430.638625] mmc1: error -84 writing Cache Enable bit
[ 430.643618] mmc1: error -84 doing runtime resume
For eMMC and SD, there are two tuning pass windows and the gap between
those two windows may only have one cell. If tuning step > 1, the gap may
just be skipped and host assumes those two windows as a continuous
windows. This will cause a wrong delay cell near the gap to be selected.
Set the tuning step to 1 to avoid selecting the wrong delay cell.
For SDIO, the gap is sufficiently large, so the default tuning step does
not cause this issue.
Fixes: 0565d20cd8c2 ("arm64: dts: freescale: Support i.MX93 9x9 Quick Start Board")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
index 0852067eab2cb..197c8f8b7f669 100644
--- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
@@ -507,6 +507,7 @@ &usdhc1 {
pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
bus-width = <8>;
non-removable;
+ fsl,tuning-step = <1>;
status = "okay";
};
@@ -519,6 +520,7 @@ &usdhc2 {
vmmc-supply = <®_usdhc2_vmmc>;
bus-width = <4>;
no-mmc;
+ fsl,tuning-step = <1>;
status = "okay";
};
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity
From: Sasha Levin @ 2026-04-20 13:20 UTC (permalink / raw)
To: patches, stable
Cc: Ravi Hothi, Krzysztof Kozlowski, Konrad Dybcio, Bjorn Andersson,
Sasha Levin, konradybcio, robh, krzk+dt, conor+dt,
mohammad.rafi.shaik, quic_pkumpatl, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
[ Upstream commit b7df21c59739cceb7b866c6c5e8a6ba03875ab71 ]
The WCD9370 audio codec reset line on QCM6490 IDP should be active-low, but
the device tree described it as active-high. As a result, the codec is
kept in reset and fails to reset the SoundWire, leading to timeouts
and ASoC card probe failure (-ETIMEDOUT).
Fix the reset GPIO polarity to GPIO_ACTIVE_LOW so the codec can properly
initialize.
Fixes: aa04c298619f ("arm64: dts: qcom: qcm6490-idp: Add WSA8830 speakers and WCD9370 headset codec")
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260220090220.2992193-1-ravi.hothi@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
index 73fce639370cd..214671b462770 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
@@ -177,7 +177,7 @@ wcd9370: audio-codec-0 {
pinctrl-0 = <&wcd_default>;
pinctrl-names = "default";
- reset-gpios = <&tlmm 83 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&tlmm 83 GPIO_ACTIVE_LOW>;
vdd-buck-supply = <&vreg_l17b_1p7>;
vdd-rxtx-supply = <&vreg_l18b_1p8>;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Fix UART10 pinconf
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: patches, stable
Cc: Loic Poulain, Konrad Dybcio, Dmitry Baryshkov, Bjorn Andersson,
Sasha Levin, konradybcio, robh, krzk+dt, conor+dt, quic_msavaliy,
quic_vdadhani, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Loic Poulain <loic.poulain@oss.qualcomm.com>
[ Upstream commit 5b2a16ab0dbd090dc545c05ee79a077cc7a9c1e0 ]
UART10 RTS and TX pins were incorrectly mapped to gpio84 and gpio85.
Correct them to gpio85 (RTS) and gpio86 (TX) to match the hardware
I/O mapping.
Fixes: 467284a3097f ("arm64: dts: qcom: qcs8300: Add QUPv3 configuration")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260202155611.1568-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
arch/arm64/boot/dts/qcom/qcs8300.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
index 8d78ccac411e4..b8d4a75baee22 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
@@ -5430,12 +5430,12 @@ qup_uart10_cts: qup-uart10-cts-state {
};
qup_uart10_rts: qup-uart10-rts-state {
- pins = "gpio84";
+ pins = "gpio85";
function = "qup1_se2";
};
qup_uart10_tx: qup-uart10-tx-state {
- pins = "gpio85";
+ pins = "gpio86";
function = "qup1_se2";
};
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] dt-bindings: net: Fix Tegra234 MGBE PTP clock
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: patches, stable
Cc: Jon Hunter, Krzysztof Kozlowski, Jakub Kicinski, Sasha Levin,
andrew+netdev, davem, edumazet, pabeni, robh, krzk+dt, conor+dt,
thierry.reding, treding, vbhadram, netdev, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Jon Hunter <jonathanh@nvidia.com>
[ Upstream commit fb22b1fc5bca3c0aad95388933497ceb30f1fb26 ]
The PTP clock for the Tegra234 MGBE device is incorrectly named
'ptp-ref' and should be 'ptp_ref'. This is causing the following
warning to be observed on Tegra234 platforms that use this device:
ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
Although this constitutes an ABI breakage in the binding for this
device, PTP support has clearly never worked and so fix this now
so we can correct the device-tree for this device. Note that the
MGBE driver still supports the legacy 'ptp-ref' clock name and so
older/existing device-trees will still work, but given that this
is not the correct name, there is no point to advertise this in the
binding.
Fixes: 189c2e5c7669 ("dt-bindings: net: Add Tegra234 MGBE")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260401102941.17466-3-jonathanh@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
.../devicetree/bindings/net/nvidia,tegra234-mgbe.yaml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
index 2bd3efff2485e..215f14d1897d2 100644
--- a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
+++ b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
@@ -42,7 +42,7 @@ properties:
- const: mgbe
- const: mac
- const: mac-divider
- - const: ptp-ref
+ - const: ptp_ref
- const: rx-input-m
- const: rx-input
- const: tx
@@ -133,7 +133,7 @@ examples:
<&bpmp TEGRA234_CLK_MGBE0_RX_PCS_M>,
<&bpmp TEGRA234_CLK_MGBE0_RX_PCS>,
<&bpmp TEGRA234_CLK_MGBE0_TX_PCS>;
- clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m",
+ clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m",
"rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m",
"rx-pcs", "tx-pcs";
resets = <&bpmp TEGRA234_RESET_MGBE0_MAC>,
--
2.53.0
^ 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