* [PATCH v7 5/6] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
Orange Pi 5B but has had sound, USB, and leds wired up differently. The
5 and 5B boards use gmac for ethernet where the Pro has a PCIe attached
NIC.
Move the 5/5B-specific bits (analog-sound/es8388, FUSB302 Type-C,
gmac1, pwm-leds, i2s1_8ch routing, USB role-switch plumbing) out of
rk3588s-orangepi-5.dtsi into a new rk3588s-orangepi-5-5b.dtsi that is
included by both 5 and 5B.
The RK806 PLDO1 and PLDO2 outputs are wired differently between the
5/5B and the Pro (PLDO1/PLDO2 are swapped), so label the PMIC node
rk806_single in the base dtsi, drop pldo-reg1/pldo-reg2 from it, and
define them via a &rk806_single regulators augmentation in
rk3588s-orangepi-5-5b.dtsi. The Pro will supply its own mapping.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 222 +++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 225 +-----------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
4 files changed, 240 insertions(+), 215 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
new file mode 100644
index 000000000000..9e987ffa6241
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
+ * but not the Orange Pi 5 Pro.
+ */
+
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm0 0 25000 0>;
+ };
+ };
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-0 = <&gmac1_miim
+ &gmac1_tx_bus2
+ &gmac1_rx_bus2
+ &gmac1_rgmii_clk
+ &gmac1_rgmii_bus>;
+ pinctrl-names = "default";
+ tx_delay = <0x42>;
+ status = "okay";
+};
+
+&i2c6 {
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru I2S1_8CH_MCLKOUT>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
+ assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ };
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vbus_typec>;
+ status = "okay";
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ op-sink-microwatt = <1000000>;
+ power-role = "dual";
+ sink-pdos =
+ <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_hs: endpoint {
+ remote-endpoint = <&usb_host0_xhci_drd_sw>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_ss: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ usbc0_sbu: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_sbu>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&i2s1_8ch {
+ rockchip,i2s-tx-route = <3 2 1 0>;
+ rockchip,i2s-rx-route = <1 3 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclk
+ &i2s1m0_mclk
+ &i2s1m0_lrck
+ &i2s1m0_sdi1
+ &i2s1m0_sdo3>;
+ status = "okay";
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&rk806_single {
+ regulators {
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+ };
+};
+
+
+&usb_host0_xhci {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <&usbc0_hs>;
+ };
+ };
+};
+
+&usb_host2_xhci {
+ status = "okay";
+};
+
+&usbdp_phy0 {
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy0_typec_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_ss>;
+ };
+
+ usbdp_phy0_typec_sbu: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usbc0_sbu>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 83b9b6645a1e..d76bdf1b5e90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -2,12 +2,16 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5";
compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+ aliases {
+ mmc0 = &sdmmc;
+ };
+
vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
compatible = "regulator-fixed";
enable-active-high;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index fd5c6a025cd1..2b605e5fc35a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -3,19 +3,13 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
#include "rk3588s.dtsi"
/ {
- aliases {
- ethernet0 = &gmac1;
- mmc0 = &sdmmc;
- };
-
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -34,38 +28,6 @@ button-recovery {
};
};
- analog-sound {
- compatible = "simple-audio-card";
- pinctrl-names = "default";
- pinctrl-0 = <&hp_detect>;
- simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
- simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
- "LINPUT1", "Microphone Jack",
- "RINPUT1", "Microphone Jack",
- "LINPUT2", "Onboard Microphone",
- "RINPUT2", "Onboard Microphone";
- simple-audio-card,widgets =
- "Microphone", "Microphone Jack",
- "Microphone", "Onboard Microphone",
- "Headphone", "Headphones";
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
-
- masterdai: simple-audio-card,codec {
- sound-dai = <&es8388>;
- system-clock-frequency = <12288000>;
- };
- };
-
hdmi0-con {
compatible = "hdmi-connector";
type = "a";
@@ -77,18 +39,6 @@ hdmi0_con_in: endpoint {
};
};
- pwm-leds {
- compatible = "pwm-leds";
-
- led {
- color = <LED_COLOR_ID_GREEN>;
- function = LED_FUNCTION_STATUS;
- linux,default-trigger = "heartbeat";
- max-brightness = <255>;
- pwms = <&pwm0 0 25000 0>;
- };
- };
-
vbus_typec: regulator-vbus-typec {
compatible = "regulator-fixed";
enable-active-high;
@@ -101,15 +51,6 @@ vbus_typec: regulator-vbus-typec {
vin-supply = <&vcc5v0_sys>;
};
- vcc5v0_sys: regulator-vcc5v0-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
compatible = "regulator-fixed";
gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
@@ -119,6 +60,15 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_3v3_s3>;
};
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
};
&combphy0_ps {
@@ -161,20 +111,6 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
-&gmac1 {
- clock_in_out = "output";
- phy-handle = <&rgmii_phy1>;
- phy-mode = "rgmii-rxid";
- pinctrl-0 = <&gmac1_miim
- &gmac1_tx_bus2
- &gmac1_rx_bus2
- &gmac1_rgmii_clk
- &gmac1_rgmii_bus>;
- pinctrl-names = "default";
- tx_delay = <0x42>;
- status = "okay";
-};
-
&gpu {
mali-supply = <&vdd_gpu_s0>;
status = "okay";
@@ -270,69 +206,6 @@ &i2c6 {
pinctrl-0 = <&i2c6m3_xfer>;
status = "okay";
- es8388: audio-codec@10 {
- compatible = "everest,es8388", "everest,es8328";
- reg = <0x10>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcca_3v3_s0>;
- DVDD-supply = <&vcca_1v8_s0>;
- HPVDD-supply = <&vcca_3v3_s0>;
- PVDD-supply = <&vcca_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
- assigned-clock-rates = <12288000>;
- #sound-dai-cells = <0>;
- };
-
- usbc0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio0>;
- interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usbc0_int>;
- vbus-supply = <&vbus_typec>;
- status = "okay";
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- op-sink-microwatt = <1000000>;
- power-role = "dual";
- sink-pdos =
- <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
- source-pdos =
- <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- usbc0_hs: endpoint {
- remote-endpoint = <&usb_host0_xhci_drd_sw>;
- };
- };
-
- port@1 {
- reg = <1>;
- usbc0_ss: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_ss>;
- };
- };
-
- port@2 {
- reg = <2>;
- usbc0_sbu: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_sbu>;
- };
- };
- };
- };
- };
-
hym8563: rtc@51 {
compatible = "haoyu,hym8563";
reg = <0x51>;
@@ -346,18 +219,6 @@ hym8563: rtc@51 {
};
};
-&i2s1_8ch {
- rockchip,i2s-tx-route = <3 2 1 0>;
- rockchip,i2s-rx-route = <1 3 2 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2s1m0_sclk
- &i2s1m0_mclk
- &i2s1m0_lrck
- &i2s1m0_sdi1
- &i2s1m0_sdo3>;
- status = "okay";
-};
-
&i2s5_8ch {
status = "okay";
};
@@ -404,12 +265,6 @@ typec5v_pwren: typec5v-pwren {
};
};
-&pwm0 {
- pinctrl-0 = <&pwm0m2_pins>;
- pinctrl-names = "default";
- status = "okay";
-};
-
&rknn_core_0 {
npu-supply = <&vdd_npu_s0>;
sram-supply = <&vdd_npu_s0>;
@@ -491,7 +346,7 @@ &spi2 {
pinctrl-names = "default";
pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
- pmic@0 {
+ rk806_single: pmic@0 {
compatible = "rockchip,rk806";
reg = <0x0>;
interrupt-parent = <&gpio0>;
@@ -666,31 +521,6 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg1 {
- regulator-name = "vcc_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- vcca_1v8_s0: pldo-reg2 {
- regulator-name = "vcca_1v8_s0";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
-
- regulator-state-mem {
- regulator-off-in-suspend;
- regulator-suspend-microvolt = <1800000>;
- };
- };
-
vdda_1v2_s0: pldo-reg3 {
regulator-name = "vdda_1v2_s0";
regulator-always-on;
@@ -841,26 +671,7 @@ &uart2 {
};
&usbdp_phy0 {
- mode-switch;
- orientation-switch;
- sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
- sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbdp_phy0_typec_ss: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&usbc0_ss>;
- };
-
- usbdp_phy0_typec_sbu: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&usbc0_sbu>;
- };
- };
};
&usb_host0_ehci {
@@ -872,15 +683,7 @@ &usb_host0_ohci {
};
&usb_host0_xhci {
- dr_mode = "otg";
- usb-role-switch;
status = "okay";
-
- port {
- usb_host0_xhci_drd_sw: endpoint {
- remote-endpoint = <&usbc0_hs>;
- };
- };
};
&usb_host1_ehci {
@@ -891,7 +694,7 @@ &usb_host1_ohci {
status = "okay";
};
-&usb_host2_xhci {
+&vop {
status = "okay";
};
@@ -899,10 +702,6 @@ &vop_mmu {
status = "okay";
};
-&vop {
- status = "okay";
-};
-
&vp0 {
vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
index d21ec320d295..8af174777809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5B";
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v7 6/6] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
- eMMC module, you can optionally solder a SPI NOR in place and turn
off the eMMC
- PCIe-attached NIC (pcie2x1l1)
- PCIe NVMe slot (pcie2x1l2)
- AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
- BCM4345C5 Bluetooth
- es8388 audio
- USB 2.0 and USB 3.0
- Two HDMI ports, the second is connected to the SoC's DP controller
driven through a Lontium LT8711UXD bridge.
Vendors schematics are available at:
https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 442 ++++++++++++++++++
2 files changed, 443 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4d384f153c13..c99dca2ae9e7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
new file mode 100644
index 000000000000..61462c66753d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -0,0 +1,442 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5 Pro";
+ compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ mmc2 = &sdio;
+ };
+
+ hdmi1-con {
+ compatible = "hdmi-connector";
+ label = "HDMI1 OUT";
+ type = "a";
+
+ port {
+ hdmi1_con_in: endpoint {
+ remote-endpoint = <<8711uxd_out>;
+ };
+ };
+ };
+
+ lt8711uxd {
+ compatible = "lontium,lt8711uxd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lt8711uxd_in: endpoint {
+ remote-endpoint = <&dp0_out_con>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ lt8711uxd_out: endpoint {
+ remote-endpoint = <&hdmi1_con_in>;
+ };
+ };
+ };
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s2_2ch>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm15 0 1000000 0>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_ACTIVITY;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm3 0 1000000 0>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ cooling-levels = <0 50 100 150 200 255>;
+ fan-supply = <&vcc5v0_sys>;
+ pwms = <&pwm2 0 20000000 0>;
+ };
+
+ vcc3v3_dp: regulator-vcc3v3-dp {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_bridge_en>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_dp";
+ regulator-always-on;
+ regulator-boot-on;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc3v3_phy1: regulator-vcc3v3-phy1 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc3v3_phy1_en>;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_phy1";
+ startup-delay-us = <50000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc5v0_otg: regulator-vcc5v0-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_otg_en>;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "vcc5v0_otg";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+ post-power-on-delay-ms = <200>;
+ reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
+ };
+
+ typea_con: usb-a-connector {
+ compatible = "usb-a-connector";
+ data-role = "host";
+ label = "USB3 Type-A";
+ power-role = "source";
+ vbus-supply = <&vcc5v0_otg>;
+ };
+};
+
+&dp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp0m0_pins>;
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp1: endpoint {
+ remote-endpoint = <&vp1_out_dp0>;
+ };
+};
+
+&dp0_out {
+ dp0_out_con: endpoint {
+ remote-endpoint = <<8711uxd_in>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m4_xfer>;
+ status = "okay";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+ status = "okay";
+
+ es8388: audio-codec@11 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x11>;
+ #sound-dai-cells = <0>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_1v8_s0>;
+ assigned-clock-rates = <12288000>;
+ assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
+ clocks = <&cru I2S2_2CH_MCLKOUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s2m1_mclk>;
+ };
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4m3_xfer>;
+ status = "okay";
+};
+
+&i2s2_2ch {
+ pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
+ &i2s2m1_sdi &i2s2m1_sdo>;
+ status = "okay";
+};
+
+&package_thermal {
+ polling-delay = <1000>;
+
+ cooling-maps {
+ map0 {
+ trip = <&package_fan0>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map1 {
+ trip = <&package_fan1>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ package_fan0: package-fan0 {
+ hysteresis = <2000>;
+ temperature = <55000>;
+ type = "active";
+ };
+
+ package_fan1: package-fan1 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+};
+
+/* NVMe */
+&pcie2x1l1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2x1l1_rst &pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
+ reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ supports-clkreq;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+};
+
+/* NIC */
+&pcie2x1l2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie2x1l2_rst>;
+ reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_phy1>;
+ status = "okay";
+};
+
+&pinctrl {
+ bluetooth {
+ bt_wake_gpio: bt-wake-pin {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host_irq: bt-wake-host-irq {
+ rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ dp {
+ dp_bridge_en: dp-bridge-en {
+ rockchip,pins = <3 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ pcie2x1l1_rst: pcie2x1l1-rst {
+ rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ pcie2x1l2_rst: pcie2x1l2-rst {
+ rockchip,pins = <3 RK_PD1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ vcc3v3_phy1_en: vcc3v3-phy1-en {
+ rockchip,pins = <3 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ vcc5v0_otg_en: vcc5v0-otg-en {
+ rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wlan {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins = <0 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wifi_host_wake_irq: wifi-host-wake-irq {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
+
+&pwm15 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm15m2_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m1_pins>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm3m2_pins>;
+ status = "okay";
+};
+
+&rk806_single {
+ regulators {
+ vcca_1v8_s0: pldo-reg1 {
+ regulator-name = "vcca_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_1v8_s0: pldo-reg2 {
+ regulator-name = "vcc_1v8_s0";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&sdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-mmc;
+ no-sd;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ ap6256: wifi@1 {
+ compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-names = "host-wake";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_irq>;
+ };
+};
+
+&uart9 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wakeup";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1500000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
+ shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
+&usb_host0_xhci {
+ dr_mode = "host";
+};
+
+&usbdp_phy0 {
+ /*
+ * USBDP PHY0 is wired to a USB3 Type-A host connector via lanes 2/3.
+ * Additionally lanes 0/1 and the aux channel are wired to the
+ * Lontium LT8711UXD DP-to-HDMI bridge feeding the HDMI1 connector.
+ */
+ rockchip,dp-lane-mux = <0 1>;
+};
+
+&vp1 {
+ vp1_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp1>;
+ };
+};
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v7 4/6] arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels to match schematic
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Orange Pi 5, 5B and 5 Pro schematics label the RK806 PLDO outputs
using the pattern VCC_*_S0 / VCCA_*_S0 / VDDA_*_S0. Rename the base
dtsi regulator labels (and the es8388 supply references) to match:
pldo-reg1: avcc_1v8_s0 -> vcc_1v8_s0
pldo-reg2: vcc_1v8_s0 -> vcca_1v8_s0
pldo-reg3: avdd_1v2_s0 -> vdda_1v2_s0
pldo-reg4: vcc_3v3_s0 -> vcca_3v3_s0
Also update the saradc vref-supply reference to track the pldo-reg1
rename. No functional change.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 26 +++++++++----------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..fd5c6a025cd1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -274,10 +274,10 @@ es8388: audio-codec@10 {
compatible = "everest,es8388", "everest,es8328";
reg = <0x10>;
clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcc_3v3_s0>;
- DVDD-supply = <&vcc_1v8_s0>;
- HPVDD-supply = <&vcc_3v3_s0>;
- PVDD-supply = <&vcc_3v3_s0>;
+ AVDD-supply = <&vcca_3v3_s0>;
+ DVDD-supply = <&vcca_1v8_s0>;
+ HPVDD-supply = <&vcca_3v3_s0>;
+ PVDD-supply = <&vcca_3v3_s0>;
assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
assigned-clock-rates = <12288000>;
#sound-dai-cells = <0>;
@@ -441,7 +441,7 @@ &rknn_mmu_2 {
};
&saradc {
- vref-supply = <&avcc_1v8_s0>;
+ vref-supply = <&vcc_1v8_s0>;
status = "okay";
};
@@ -666,8 +666,8 @@ regulator-state-mem {
};
};
- avcc_1v8_s0: pldo-reg1 {
- regulator-name = "avcc_1v8_s0";
+ vcc_1v8_s0: pldo-reg1 {
+ regulator-name = "vcc_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -678,8 +678,8 @@ regulator-state-mem {
};
};
- vcc_1v8_s0: pldo-reg2 {
- regulator-name = "vcc_1v8_s0";
+ vcca_1v8_s0: pldo-reg2 {
+ regulator-name = "vcca_1v8_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1800000>;
@@ -691,8 +691,8 @@ regulator-state-mem {
};
};
- avdd_1v2_s0: pldo-reg3 {
- regulator-name = "avdd_1v2_s0";
+ vdda_1v2_s0: pldo-reg3 {
+ regulator-name = "vdda_1v2_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <1200000>;
@@ -703,8 +703,8 @@ regulator-state-mem {
};
};
- vcc_3v3_s0: pldo-reg4 {
- regulator-name = "vcc_3v3_s0";
+ vcca_3v3_s0: pldo-reg4 {
+ regulator-name = "vcca_3v3_s0";
regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <3300000>;
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v7 3/6] drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
drivers/gpu/drm/bridge/simple-bridge.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/bridge/simple-bridge.c b/drivers/gpu/drm/bridge/simple-bridge.c
index 8aa31ca3c72d..42c1f3d5ba0c 100644
--- a/drivers/gpu/drm/bridge/simple-bridge.c
+++ b/drivers/gpu/drm/bridge/simple-bridge.c
@@ -270,6 +270,11 @@ static const struct of_device_id simple_bridge_match[] = {
.data = &(const struct simple_bridge_info) {
.connector_type = DRM_MODE_CONNECTOR_HDMIA,
},
+ }, {
+ .compatible = "lontium,lt8711uxd",
+ .data = &(const struct simple_bridge_info) {
+ .connector_type = DRM_MODE_CONNECTOR_HDMIA,
+ },
}, {
.compatible = "parade,ps185hdm",
.data = &(const struct simple_bridge_info) {
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v7 2/6] dt-bindings: display: bridge: simple: document the Lontium LT8711UXD DP-to-HDMI bridge
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
The Lontium LT8711UXD is a high performance two lane Type-C/DP1.4
to HDMI2.0 converter, designed to connect a USB Type-C source or
a DP1.4 source to an HDMI2.0 sink.
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
index e6808419f625..752c736c8f85 100644
--- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml
@@ -30,6 +30,7 @@ properties:
- algoltek,ag6311
- asl-tek,cs5263
- dumb-vga-dac
+ - lontium,lt8711uxd
- parade,ps185hdm
- radxa,ra620
- realtek,rtd2171
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v7 1/6] dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann, Krzysztof Kozlowski
In-Reply-To: <20260414214104.1363987-1-dennis@ausil.us>
Add compatible string for the Orange Pi 5 Pro.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ae77ded9fe47..3c6b83a84463 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1320,6 +1320,7 @@ properties:
items:
- enum:
- xunlong,orangepi-5
+ - xunlong,orangepi-5-pro
- xunlong,orangepi-5b
- const: rockchip,rk3588s
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v7 0/6] Add support for Orange Pi 5 Pro
From: Dennis Gilmore @ 2026-04-14 21:40 UTC (permalink / raw)
Cc: Alexey Charkov, Andrew Lunn, Andrzej Hajda, Chaoyi Chen,
Conor Dooley, David Airlie, Dennis Gilmore, devicetree, dri-devel,
FUKAUMI Naoki, Heiko Stuebner, Hsun Lai, Jernej Skrabec,
Jimmy Hon, John Clark, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, linux-arm-kernel, linux-kernel, linux-rockchip,
Maarten Lankhorst, Maxime Ripard, Michael Opdenacker,
Michael Riesch, Mykola Kvach, Neil Armstrong, Peter Robinson,
Quentin Schulz, Robert Foss, Rob Herring, Simona Vetter,
Thomas Zimmermann
This series adds initial support for Orange Pi 5 Pro. The PCIe attached
network driver(dwmac-motorcomm) was just added.
The series was tested against Linux 7.0-rc7
Please take a look.
Thank you,
Dennis Gilmore
Changes in v7:
- Fix up whitespace issues identified by checkpatch.pl --strict in
rk3588s-orangepi-5-5b.dtsi
- checkpatch gave a warning for WARNING: phy-mode "rgmii-rxid" without
comment, as this was moved over I left it untouched
- Added lontium,lt8711uxd to the compatible enum in the simple-bridge
binding
- Added lontium,lt8711uxd match entry with DRM_MODE_CONNECTOR_HDMIA to
the simple-bridge driver
- New patch to rename the regulator labels for the es8388 supplies to
match the schematics as they all use vcca_*
- RK806 PLDO1 and PLDO2 outputs are swapped between the 5/5B and pro.
move their definition to the shared 5/5B dtsi and 5 Pro dts
- Fixed ES8388 PVDD-supply — vcca_3v3_s0 → vcca_1v8_s0, 5 Pro is
different to 5 and 5b.
- analog-sound: use CPU-as-clock-master on the Pro. The ES8388 is wired to
i2s2_2ch (the only I2S block physically routed to the codec pins on this
board), which uses the legacy rockchip_i2s driver. That driver's
slave-mode trigger path hangs for 200 µs polling I2S_CLR and bails with
-ETIMEDOUT ("lrclk update failed"). The TDM-capable i2s0/i2s1/i2s5
blocks served by rockchip_i2s_tdm don't have this issue, which is why
other mainline ES8388 boards get away with bitclock-master = masterdai.
Drop bitclock-master/frame-master and the masterdai label to let the I2S
block generate BCLK/LRCK itself
- Added pinctrl entries for all GPIO pins (dp_bridge_en, vcc3v3_phy1_en,
wifi_enable_h, pcie2x1l1_rst, pcie2x1l2_rst)
- DP bridge rework — replaced dp-connector node with proper chain:
- lt8711uxd bridge node (compatible lontium,lt8711uxd, with port@0/port@1
endpoints). Bridge power is gated by the vcc3v3_dp regulator, whose
enable GPIO (GPIO3_PC2) is driven via the dp_bridge_en pinctrl group;
no enable-gpios/vdd-supply on the bridge node itself.
- hdmi1-con connector node (compatible hdmi-connector, type a)
- dp0_out endpoint now points to bridge input instead of old connector
- drop accidentally included, unrelated changes to
drivers/gpu/drm/bridge/synopsys/dw-dp.c and
Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
- link to v6 https://lore.kernel.org/linux-devicetree/20260411024743.195385-1-dennis@ausil.us/
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5 https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4 https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3 https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purppose
- actually clean up the delete lines and comments missed in v2
- link to v2 https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- Link to v1 https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (6):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
dt-bindings: display: bridge: simple: document the Lontium LT8711UXD
DP-to-HDMI bridge
drm/bridge: simple: Add the Lontium LT8711UXD DP-to-HDMI bridge
arm64: dts: rockchip: rk3588s-orangepi-5: rename PLDO regulator labels
to match schematic
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
.../display/bridge/simple-bridge.yaml | 1 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 222 +++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 442 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 235 +---------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/simple-bridge.c | 5 +
9 files changed, 695 insertions(+), 220 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Jonathan Cameron @ 2026-04-14 18:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <ad3paMbRXtq6BrCu@ashevche-desk.local>
On Tue, 14 Apr 2026 10:14:48 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Mon, Apr 13, 2026 at 08:06:54PM +0100, Jonathan Cameron wrote:
> > On Mon, 30 Mar 2026 14:58:46 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
>
> ...
>
> > > + if (!conf->temp_en)
> > > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> >
> > Could make this
> > val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
> > !conf->temp_en);
> > Not particularly important though if you prefer the if.
>
> Isn't this becomes FIELD_MODIFY()?
>
Yes, in this particular case as the bit has never been set before
this line, they end up the same. If the compiler fails to notice it
doesn't need to zero the bit if conf->temp_en is true might make it more
efficient to do it the way I had it but given this isn't a fast
path, FIELD_MODIFY() is fine.
Jonathan
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-04-14 14:07 UTC (permalink / raw)
To: Alexey Charkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Peter Robinson, Michael Riesch, Mykola Kvach, Jimmy Hon,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <CABjd4YwZJe8fO+kJiXRTq5gZirVvKvCqWzNdYqN3-6eMAZUFxQ@mail.gmail.com>
On Sat, Apr 11, 2026 at 1:00 PM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Sat, Apr 11, 2026 at 6:47 AM <dennis@ausil.us> wrote:
> >
> > From: Dennis Gilmore <dennis@ausil.us>
> >
> > Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
> >
> > - eMMC module, you can optionally solder a SPI NOR in place and turn
> > off the eMMC
> > - PCIe-attached NIC (pcie2x1l1)
> > - PCIe NVMe slot (pcie2x1l2)
> > - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> > - BCM4345C5 Bluetooth
> > - es8388 audio
> > - USB 2.0 and USB 3.0
> > - Two HDMI ports, the second is connected to the SoC's DP controller
> > driven by a transparent LT8711UXD bridge that has firmware onboard and
> > needs no node defined.
> >
> > Vendors description and links to schematics available:
> > http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
>
> Hi Dennis,
>
> The most useful of these is the schematic, so it's best to include a
> direct link to that in a dedicated Link: tag
>
> Link: https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
Will change to that, I did not do it because a random Google Drive
link doesn't really indicate it as a source of truth
> [schematic]
>
> > Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> > ---
> > .../display/rockchip/rockchip,dw-dp.yaml | 7 +
> > arch/arm64/boot/dts/rockchip/Makefile | 1 +
> > .../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
> > drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
>
> These should be three separate patches, never lumped together. First
> the binding change, next the driver change. They go together via the
> subsystem tree (likely DRM in this case). Then the DTS addition (or
> change) separately (it goes via the SoC tree).
They were something I was doing as I worked on getting the second HDMI
port working, they ended up not being needed, and I should have
removed it there really should have only been the dts and Makefile. I
should have waited until the morning to review again and send.
> > 4 files changed, 372 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> >
> > diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> > index 6345f0132d43..079a912d97f1 100644
> > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> > @@ -57,6 +57,13 @@ properties:
> > - const: i2s
> > - const: spdif
> >
> > + hpd-gpios:
> > + maxItems: 1
> > + description:
> > + GPIO used for hot plug detection when the controller's native HPD
> > + input is not connected. If not specified, the controller uses its
> > + internal HPD detection mechanism.
>
> Do you actually need this change? According to the schematic, the
> DP_HPDIN line from the DP-HDMI bridge is routed to the native
> DP0_HPDIN_M0 pin of the DP controller, so it shouldn't require this
> GPIO trick if the pinctrl is configured properly.
No I do not, It was an approach I had experimented with but did not
use and did not mean to include here.
> > phys:
> > maxItems: 1
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> > index 4d384f153c13..c99dca2ae9e7 100644
> > --- a/arch/arm64/boot/dts/rockchip/Makefile
> > +++ b/arch/arm64/boot/dts/rockchip/Makefile
> > @@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
> > +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
> > dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> > new file mode 100644
> > index 000000000000..84c83aa69f63
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> > @@ -0,0 +1,352 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +
> > +/dts-v1/;
> > +
> > +#include "rk3588s-orangepi-5.dtsi"
> > +
> > +/ {
> > + model = "Xunlong Orange Pi 5 Pro";
> > + compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
> > +
> > + aliases {
> > + mmc0 = &sdhci;
> > + mmc1 = &sdmmc;
> > + mmc2 = &sdio;
> > + };
> > +
> > + dp-con {
> > + compatible = "dp-connector";
>
> You don't have a physical DP connector on the board, so this node
> doesn't describe actual hardware, and is thus a no-go. What you have
> instead is an HDMI type A connector routed via an onboard DP to HDMI
> bridge, so you should describe exactly that in the device tree (a node
> for the HDMI connector, a node for the bridge, a node for the DP
> controller, and endpoints connected from the controller to the bridge,
> from the bridge to the connector). Please refer to the device tree for
> Radxa Rock 5 ITX, which has a similar setup (but a different bridge
> IC).
>
> I don't think your LT8711UXD has existing binding or driver entry, so
> a one-line patch will likely be needed to
> Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml,
> and a separate one to drivers/gpu/drm/bridge/simple-bridge.c. Separate
> ones :)
Will add in v7
> > + port {
> > + dp_con_in: endpoint {
> > + remote-endpoint = <&dp0_out_con>;
> > + };
> > + };
> > + };
> > +
> > + analog-sound {
> > + compatible = "simple-audio-card";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&hp_detect>;
> > + simple-audio-card,bitclock-master = <&masterdai>;
> > + simple-audio-card,format = "i2s";
> > + simple-audio-card,frame-master = <&masterdai>;
> > + simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> > + simple-audio-card,mclk-fs = <256>;
> > + simple-audio-card,name = "rockchip,es8388";
> > + simple-audio-card,routing =
> > + "Headphones", "LOUT1",
> > + "Headphones", "ROUT1",
> > + "LINPUT1", "Microphone Jack",
> > + "RINPUT1", "Microphone Jack",
> > + "LINPUT2", "Onboard Microphone",
> > + "RINPUT2", "Onboard Microphone";
> > + simple-audio-card,widgets =
> > + "Microphone", "Microphone Jack",
> > + "Microphone", "Onboard Microphone",
> > + "Headphone", "Headphones";
> > +
> > + simple-audio-card,cpu {
> > + sound-dai = <&i2s2_2ch>;
> > + };
> > +
> > + masterdai: simple-audio-card,codec {
> > + sound-dai = <&es8388>;
> > + system-clock-frequency = <12288000>;
> > + };
> > + };
> > +
> > + pwm-leds {
> > + compatible = "pwm-leds";
> > +
> > + led-0 {
> > + color = <LED_COLOR_ID_BLUE>;
> > + function = LED_FUNCTION_STATUS;
> > + linux,default-trigger = "heartbeat";
> > + max-brightness = <255>;
> > + pwms = <&pwm15 0 1000000 0>;
> > + };
> > +
> > + led-1 {
> > + color = <LED_COLOR_ID_GREEN>;
> > + function = LED_FUNCTION_ACTIVITY;
> > + linux,default-trigger = "heartbeat";
> > + max-brightness = <255>;
> > + pwms = <&pwm3 0 1000000 0>;
> > + };
> > + };
> > +
> > + fan: pwm-fan {
> > + compatible = "pwm-fan";
> > + #cooling-cells = <2>;
> > + cooling-levels = <0 50 100 150 200 255>;
> > + fan-supply = <&vcc5v0_sys>;
> > + pwms = <&pwm2 0 20000000 0>;
> > + };
> > +
> > + vcc3v3_dp: regulator-vcc3v3-dp {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
>
> Please don't forget to add explicit pinctrl nodes for each GPIO pin
> you use (here and in other places like this). These GPIOs happen to
> work on Linux without configuring their pin control first, but that is
> pure luck and coincidence due to how the respective Linux subsystems
> are wired together, and if you ever need to use this device tree in
> e.g. U-boot (which also derives its DTS from the Linux kernel tree) it
> will break there.
Will do
> > + regulator-always-on;
> > + regulator-boot-on;
>
> Does it have to be always-on, boot-on? This looks like a hack to work
> around the fact that you didn't define the bridge node, which uses
> this as its supply. Please model the dependencies explicitly - most
> likely that will let you drop these attributes.
without these the the dp to HDMI bridge does not power up, and HPD
does not work,
> > + regulator-max-microvolt = <3300000>;
> > + regulator-min-microvolt = <3300000>;
>
> It's two separate regulators on your schematic, one DCDC at 1.25V and
> the other a load switch at 3.3V, driving six separate voltage inputs
> of the DP bridge. They are both controlled by the same GPIO pin
> though, so _maybe_ it's okay to have just one "virtual" node like this
> to model them together. Would be great for the DT maintainers to weigh
> in on this.
>
> > + regulator-name = "vcc3v3_dp";
> > + vin-supply = <&vcc_3v3_s3>;
> > + };
> > +
> > + vcc3v3_phy1: regulator-vcc3v3-phy1 {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
> > + regulator-boot-on;
>
> See above
>
> > + regulator-max-microvolt = <3300000>;
> > + regulator-min-microvolt = <3300000>;
> > + regulator-name = "vcc3v3_phy1";
> > + startup-delay-us = <50000>;
> > + vin-supply = <&vcc_3v3_s3>;
> > + };
> > +
> > + vcc5v0_otg: regulator-vcc5v0-otg {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&vcc5v0_otg_en>;
> > + regulator-max-microvolt = <5000000>;
> > + regulator-min-microvolt = <5000000>;
> > + regulator-name = "vcc5v0_otg";
> > + vin-supply = <&vcc5v0_sys>;
> > + };
> > +
> > + sdio_pwrseq: sdio-pwrseq {
> > + compatible = "mmc-pwrseq-simple";
> > + clocks = <&hym8563>;
> > + clock-names = "ext_clock";
> > + post-power-on-delay-ms = <200>;
> > + reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
>
> This GPIO also needs a pinctrl
>
> > + };
> > +
> > + typea_con: usb-a-connector {
> > + compatible = "usb-a-connector";
> > + data-role = "host";
> > + label = "USB3 Type-A";
> > + power-role = "source";
> > + vbus-supply = <&vcc5v0_otg>;
> > + };
> > +};
> > +
> > +&dp0 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&dp0m0_pins>;
>
> This switches your HPD pin to the native DP controller handling
> (DP0_HPDIN_M0), so the GPIO bits you've patched into the controller
> driver aren't even used, and it doesn't look like you tested that code
> path.
Right, I had not meant to include. It was something I had worked on in
refactoring it and went a different route.
>
> > + status = "okay";
> > +};
> > +
> > +&dp0_in {
> > + dp0_in_vp1: endpoint {
> > + remote-endpoint = <&vp1_out_dp0>;
> > + };
> > +};
> > +
> > +&dp0_out {
> > + dp0_out_con: endpoint {
> > + remote-endpoint = <&dp_con_in>;
>
> This will need to be rewritten once you add the proper bridge chain
> leading up to the HDMI type A connector.
Yep
> > + };
> > +};
> > +
> > +&i2c1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c1m4_xfer>;
> > + status = "okay";
> > +};
> > +
> > +&i2c3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c3m0_xfer>;
> > + status = "okay";
> > +
> > + es8388: audio-codec@11 {
> > + compatible = "everest,es8388", "everest,es8328";
> > + reg = <0x11>;
> > + #sound-dai-cells = <0>;
> > + AVDD-supply = <&vcc_3v3_s0>;
>
> Are you sure? Schematic says VCCA_3V3_S0, which is a different
> regulator (PLDO4 output of the PMIC)
>
> > + DVDD-supply = <&vcc_1v8_s0>;
>
> Schematic says VCCA_1V8_S0, which is a different regulator (PLDO1
> output of the PMIC)
>
> > + HPVDD-supply = <&vcc_3v3_s0>;
>
> Schematic says VCCA_3V3_S0
>
> > + PVDD-supply = <&vcc_3v3_s0>;
>
> Schematic says VCCA_1V8_S0
I will rename these. It was what was used in the original orange pi 5
boards and was carried over, but looking at their schematics, they are
labeled the same so changing makes sense. after digging in the Pi 5
Pro names two of the regulators differently to the 5 and 5b. and the
naming of the current ones does not match the schematic
>
> > + assigned-clock-rates = <12288000>;
> > + assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
> > + clocks = <&cru I2S2_2CH_MCLKOUT>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2s2m1_mclk>;
> > + };
> > +};
> > +
> > +&i2c4 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&i2c4m3_xfer>;
> > + status = "okay";
> > +};
> > +
> > +&i2s2_2ch {
> > + pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
> > + &i2s2m1_sdi &i2s2m1_sdo>;
> > + status = "okay";
> > +};
> > +
> > +&package_thermal {
> > + polling-delay = <1000>;
> > +
> > + cooling-maps {
> > + map0 {
> > + trip = <&package_fan0>;
> > + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> > + };
> > +
> > + map1 {
> > + trip = <&package_fan1>;
> > + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> > + };
> > + };
> > +
> > + trips {
> > + package_fan0: package-fan0 {
> > + hysteresis = <2000>;
> > + temperature = <55000>;
> > + type = "active";
> > + };
> > +
> > + package_fan1: package-fan1 {
> > + hysteresis = <2000>;
> > + temperature = <65000>;
> > + type = "active";
> > + };
> > + };
> > +};
> > +
> > +/* NVMe */
> > +&pcie2x1l1 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
> > + reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
>
> The GPIO also needs a pinctrl
Will fix
> > + supports-clkreq;
> > + vpcie3v3-supply = <&vcc_3v3_s3>;
> > + status = "okay";
> > +};
> > +
> > +/* NIC */
> > +&pcie2x1l2 {
> > + reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
>
> The GPIO also needs a pinctrl
Will fix
> > + vpcie3v3-supply = <&vcc3v3_phy1>;
> > + status = "okay";
> > +};
> > +
> > +&pinctrl {
> > + bluetooth {
> > + bt_wake_gpio: bt-wake-pin {
> > + rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> > + };
> > +
> > + bt_wake_host_irq: bt-wake-host-irq {
> > + rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
> > + };
> > + };
> > +
> > + usb {
> > + vcc5v0_otg_en: vcc5v0-otg-en {
> > + rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
> > + };
> > + };
> > +
> > + wlan {
> > + wifi_host_wake_irq: wifi-host-wake-irq {
> > + rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
> > + };
> > + };
> > +};
> > +
> > +&pwm15 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pwm15m2_pins>;
> > + status = "okay";
> > +};
> > +
> > +&pwm2 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pwm2m1_pins>;
> > + status = "okay";
> > +};
> > +
> > +&pwm3 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pwm3m2_pins>;
> > + status = "okay";
> > +};
> > +
> > +&sdhci {
> > + status = "okay";
> > +};
> > +
> > +&sdio {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + bus-width = <4>;
> > + cap-sd-highspeed;
> > + cap-sdio-irq;
> > + keep-power-in-suspend;
> > + max-frequency = <150000000>;
> > + mmc-pwrseq = <&sdio_pwrseq>;
> > + no-mmc;
> > + no-sd;
> > + non-removable;
> > + sd-uhs-sdr104;
> > + status = "okay";
> > +
> > + ap6256: wifi@1 {
> > + compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
> > + reg = <1>;
> > + interrupt-names = "host-wake";
> > + interrupt-parent = <&gpio0>;
> > + interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&wifi_host_wake_irq>;
> > + };
> > +};
> > +
> > +&uart9 {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
> > + uart-has-rtscts;
> > + status = "okay";
> > +
> > + bluetooth {
> > + compatible = "brcm,bcm4345c5";
> > + clocks = <&hym8563>;
> > + clock-names = "lpo";
> > + device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
> > + interrupt-names = "host-wakeup";
> > + interrupt-parent = <&gpio0>;
> > + interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
> > + max-speed = <1500000>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
> > + shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
> > + vbat-supply = <&vcc_3v3_s3>;
> > + vddio-supply = <&vcc_1v8_s3>;
> > + };
> > +};
> > +
> > +&usb_host0_xhci {
> > + dr_mode = "host";
> > +};
> > +
> > +&usbdp_phy0 {
> > + rockchip,dp-lane-mux = <0 1>;
>
> I'm wondering if the DP controller's "out" endpoint should go to the
> PHY instead of directly to the connector/bridge. That would describe
> the hardware better.
This was initially added to make sure that the type A port worked
because it uses lanes 2/3, and I needed to make sure 0/1, which route
to the dp were allocated. The DP PHY is already tied to the controller
via the phys property on &dp0 (inherited from rk3588s.dtsi), and the
lane mux is set via rockchip,dp-lane-mux on &usbdp_phy0. This matches
the convention used by rk3588-evb2-v10, rk3588s-coolpi-4b, and
rk3588s-indiedroid-nova — routing the dp0_out endpoint through the PHY
would diverge from the existing binding and all in-tree users.
> > +};
> > +
> > +&vp1 {
> > + vp1_out_dp0: endpoint@a {
> > + reg = <ROCKCHIP_VOP2_EP_DP0>;
> > + remote-endpoint = <&dp0_in_vp1>;
> > + };
> > +};
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > index fd23ca2834b0..b58f57b69b22 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> > @@ -8,6 +8,7 @@
> > */
> > #include <linux/bitfield.h>
> > #include <linux/clk.h>
> > +#include <linux/gpio/consumer.h>
> > #include <linux/iopoll.h>
> > #include <linux/irq.h>
> > #include <linux/media-bus-format.h>
> > @@ -330,6 +331,8 @@ struct dw_dp {
> > u8 pixel_mode;
> >
> > DECLARE_BITMAP(sdp_reg_bank, SDP_REG_BANK_SIZE);
> > +
> > + struct gpio_desc *hpd_gpiod;
> > };
> >
> > enum {
> > @@ -481,6 +484,9 @@ static bool dw_dp_hpd_detect(struct dw_dp *dp)
> > {
> > u32 value;
> >
> > + if (dp->hpd_gpiod)
> > + return gpiod_get_value_cansleep(dp->hpd_gpiod);
> > +
> > regmap_read(dp->regmap, DW_DP_HPD_STATUS, &value);
> >
> > return FIELD_GET(HPD_STATE, value) == DW_DP_HPD_STATE_PLUG;
> > @@ -2002,6 +2008,12 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> > return ERR_CAST(dp->regmap);
> > }
> >
> > + dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
>
> Not tested, not needed, why bother?..
this is not needed
> Best regards,
> Alexey
Thanks for the feedback
Dennis
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH v3] arm64: defconfig: Enable Rockchip video decoder
From: Detlev Casanova @ 2026-04-14 13:37 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, kernel, linux-rockchip; +Cc: Detlev Casanova
The Rockchip video decoder (rkvdec) provides hardware-accelerated video
decoding on Rockchip SoCs. Enable it as a module so that users of these
widely used platforms get video decoding support out of the box.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
---
Changes in v3:
- Update commit message
- Link to v2: https://patch.msgid.link/20260326-rkvdec-add-defconfig-v2-1-d65c296da9ba@collabora.com
Changes in v2:
- Update commit message
- Add missing CCs
- Link to v1: https://patch.msgid.link/20260325-rkvdec-add-defconfig-v1-1-89a55d3bb5c4@collabora.com
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..4b3f31cb4a94 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -931,6 +931,7 @@ CONFIG_VIDEO_RENESAS_VSP1=m
CONFIG_VIDEO_RCAR_DRIF=m
CONFIG_VIDEO_ROCKCHIP_CIF=m
CONFIG_VIDEO_ROCKCHIP_RGA=m
+CONFIG_VIDEO_ROCKCHIP_VDEC=m
CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC=m
CONFIG_VIDEO_SAMSUNG_S5P_JPEG=m
CONFIG_VIDEO_SAMSUNG_S5P_MFC=m
---
base-commit: bbeb83d3182abe0d245318e274e8531e5dd7a948
change-id: 20260325-rkvdec-add-defconfig-eaa11ab14f1f
Best regards,
--
Detlev Casanova <detlev.casanova@collabora.com>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* RE: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
From: Hongxing Zhu @ 2026-04-14 7:59 UTC (permalink / raw)
To: Manivannan Sadhasivam, Brian Norris
Cc: manivannan.sadhasivam@oss.qualcomm.com, Bjorn Helgaas,
Mahesh J Salgaonkar, Oliver O'Halloran, Will Deacon,
Lorenzo Pieralisi, Krzysztof Wilczyński, Rob Herring,
Heiko Stuebner, Philipp Zabel, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-rockchip@lists.infradead.org,
Niklas Cassel, Wilfred Mallawa, Krishna Chaitanya Chundru,
Lukas Wunner, Wilson Ding, Miles Chen
In-Reply-To: <klzq2i2ne62hdri65gz7s5pxmvely277optr2lrkvdrrahl3ca@k3hdo6o4nkjz>
> -----Original Message-----
> From: Manivannan Sadhasivam <mani@kernel.org>
> Sent: 2026年4月14日 0:35
> To: Brian Norris <briannorris@chromium.org>; Hongxing Zhu
> <hongxing.zhu@nxp.com>
> Cc: Hongxing Zhu <hongxing.zhu@nxp.com>;
> manivannan.sadhasivam@oss.qualcomm.com; Bjorn Helgaas
> <bhelgaas@google.com>; Mahesh J Salgaonkar <mahesh@linux.ibm.com>;
> Oliver O'Halloran <oohall@gmail.com>; Will Deacon <will@kernel.org>;
> Lorenzo Pieralisi <lpieralisi@kernel.org>; Krzysztof Wilczyński
> <kwilczynski@kernel.org>; Rob Herring <robh@kernel.org>; Heiko Stuebner
> <heiko@sntech.de>; Philipp Zabel <p.zabel@pengutronix.de>;
> linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org;
> linux-arm-msm@vger.kernel.org; linux-rockchip@lists.infradead.org; Niklas
> Cassel <cassel@kernel.org>; Wilfred Mallawa <wilfred.mallawa@wdc.com>;
> Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>; Lukas
> Wunner <lukas@wunner.de>; Wilson Ding <dingwei@marvell.com>; Miles
> Chen <minhuachen@google.com>
> Subject: Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a
> platform specific way
>
> Hi Brian,
>
> On Wed, Apr 08, 2026 at 06:58:34PM -0700, Brian Norris wrote:
> > Hi Richard and Mani,
> >
> > For the record, I've been using a form of an earlier version of this
> > patchset in my environment for some time now, and I've run across
> > problems that *might* relate to what Richard is reporting, but I'm not
> > quite sure at the moment. Details below.
> >
> > On Wed, Mar 25, 2026 at 07:06:49AM +0000, Hongxing Zhu wrote:
> > > Hi Mani:
> > > I've accidentally encountered a new issue based on the reset root port
> patch-set.
> > > After performing a few hot-reset operations, the PCIe link enters a
> continuous up/down cycling pattern.
> > >
> > > I found that calling pci_reset_secondary_bus() first in
> pcibios_reset_secondary_bus() appears to resolve this issue.
> > > Have you experienced a similar problem?
> > >
> > > "
> > > ...
> > > [ 141.897701] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700)
> > > link up detected [ 142.086341] imx6q-pcie 4c300000.pcie: PCIe Gen.3
> > > x1 link up [ 142.092038] imx6q-pcie 4c300000.pcie:
> > > PCIe(LNK_STS:0x00000c00) link down detected ...
> > > "
> > >
> > > Platform: i.MX95 EVK board plus local Root Ports reset supports based
> on the #1 and #2 patches of v7 patch-set.
> > > Notes of the logs:
> > > - One Gen3 NVME device is connected.
> > > - "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the
> LTSSM_EN bit to trigger the link down.
> > > - Toggle BIT6 of Bridge Control Register to trigger hot reset by
> "./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff;"
> > > - The Root Port reset patches works correctly at first.
> > > However, after several hot-reset triggers, the link enters a repeated
> down/up cycling state.
> > >
> > > Logs:
> > > [ 3.553188] imx6q-pcie 4c300000.pcie: host bridge
> /soc/pcie@4c300000 ranges:
> > > [ 3.560308] imx6q-pcie 4c300000.pcie: IO
> 0x006ff00000..0x006fffffff -> 0x0000000000
> > > [ 3.568525] imx6q-pcie 4c300000.pcie: MEM
> 0x0910000000..0x091fffffff -> 0x0010000000
> > > [ 3.577314] imx6q-pcie 4c300000.pcie: config reg[1] 0x60100000 ==
> cpu 0x60100000
> > > [ 3.796029] imx6q-pcie 4c300000.pcie: iATU: unroll T, 128 ob, 128 ib,
> align 4K, limit 1024G
> > > [ 4.003746] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> > > [ 4.009553] imx6q-pcie 4c300000.pcie: PCI host bridge to bus 0000:00
> > > root@imx95evk:~#
> > > root@imx95evk:~#
> > > root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1;
> Writing
> > > 32-bit value 0x0 to address 0x4C341058 Writing 32-bit v
> > > [ 87.265348] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d01)
> link down detected
> > > alue 0x1 to adder
> > > [ 87.273106] imx6q-pcie 4c300000.pcie: Stop root bus and handle link
> down
> > > ss 0x4C341058
> > > [ 87.281264] pcieport 0000:00:00.0: Recovering Root Port due to Link
> Down
> > > [ 87.289245] pci 0000:01:00.0: AER: can't recover (no error_detected
> callback)
> > > root@imx95evk:~# [ 87.514216] imx6q-pcie 4c300000.pcie:
> PCIe(LNK_STS:0x00000700) link up detected
> > > [ 87.702968] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> > > [ 87.834983] pcieport 0000:00:00.0: Root Port has been reset
> > > [ 87.840714] pcieport 0000:00:00.0: AER: device recovery failed
> > > [ 87.846592] imx6q-pcie 4c300000.pcie: Rescan bus after link up is
> detected
> > > [ 87.855947] pcieport 0000:00:00.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> >
> > I've seen this same line ("bridge configuration invalid") before, and
> > I believe that's because the saved state (pci_save_state(); more about
> > this below) is invalid -- it contains 0 values in places where they
> > should be non-zero. So when those values are restored
> > (pci_restore_state()), we get confused.
> >
> > I believe we've pinned down one reason this invalid state occurs --
> > it's because of an automatic (mis)feature in the DesignWare PCIe
> hardware.
> > Specifically, it's because of what the controller does during a
> > surprise link-down error.
> >
> > From the Designware docs:
> >
> > "[...] during normal operation, the link might fail and go down. After
> > this link-down event, the controller requests the DWC_pcie_clkrst.v
> > module to hot-reset the controller. There is no difference in the
> > handling of a link-down reset or a hot reset; the controller asserts
> > the link_req_rst_not output requesting the DWC_pcie_clkrst.v module
> to
> > reset the controller."
> >
> > In some of the adjacent documentation (and confirmed in local
> > testing), it suggests that this automatic reset will also reset
> > various DBI (i.e., PCIe config space) registers. It also seems as if
> > there's not really a good way to completely stop this automatic reset
> > -- the docs mention some SW methods prevent the reset, but they all
> seem racy or incomplete.
> >
> > Anyway, I think this implies that patch 1 is somewhat wrong [1]. It
> > includes some code like this:
> >
> > pci_save_state(dev);
> > ret = host->reset_root_port(host, dev);
> > if (ret)
> > pci_err(dev, "Failed to reset Root Port: %d\n", ret);
> > else
> > /* Now restore it on success */
> > pci_restore_state(dev);
> >
> > That first line (pci_save_state()) is prone to saving invalid state,
> > depending on whether the link-down event has finished flushing and
> > resetting the controller yet or not. The resulting impact is a bit
> > hard to judge, depending on what (mis)configuration you end up with.
> >
>
> Thanks a lot for your investigation. I think your observation makes sense and
> could be the culprit in saving the corrupted state. Even on non-DWC
> controllers, there is no guarantee that the Root Port config registers state will
> be preserved after LDn (before Root Port reset).
>
> > I also noticed commit a2f1e22390ac ("PCI/ERR: Ensure error
> > recoverability at all times") was merged recently. With that change, I
> > believe it is now safe to perform pci_restore_state() even without
> > pci_save_state() here.
> >
> > So ... can we remove pci_save_state() from
> > pcibios_reset_secondary_bus()? Might that help?
>
> I think so. I will also test it locally and report back soon.
>
> > It sounds like my above
> > observations *may* match Richard's reports, but I'm not sure. And
> > anyway, the documented hardware behavior is racy, so it's hard to
> > propose a foolproof solution.
> >
>
> @Richard: Can you confirm if removing 'pci_save_state(dev);' from
> pcibios_reset_secondary_bus() fixes your issue?
I have tested the hot reset trigger hundreds of times, and it works
consistently.
@Brian Norris @Manivannan Sadhasivam
Thanks a lot for your helps.
Best Regards
Richard Zhu
>
> - Mani
>
> --
> மணிவண்ணன் சதாசிவம்
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Andy Shevchenko @ 2026-04-14 7:14 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, Chris Morgan
In-Reply-To: <20260413200547.75bfd672@jic23-huawei>
On Mon, Apr 13, 2026 at 08:06:54PM +0100, Jonathan Cameron wrote:
> On Mon, 30 Mar 2026 14:58:46 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
...
> > + if (!conf->temp_en)
> > + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
>
> Could make this
> val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
> !conf->temp_en);
> Not particularly important though if you prefer the if.
Isn't this becomes FIELD_MODIFY()?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Enable the NPU on rk3588-rock-5-itx
From: Sten-Silver Ots @ 2026-04-13 21:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sten-Silver Ots, FUKAUMI Naoki, Torsten Duwe, Dmitry Baryshkov,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
This commit enables the NPU on Radxa Rock 5 ITX board.
The regulator vdd_npu_s0 was already in place and since the NPUs
power domain supply is now described remove the always-on property
from the regulator.
Signed-off-by: Sten-Silver Ots <stensilver@gmail.com>
---
.../boot/dts/rockchip/rk3588-rock-5-itx.dts | 35 ++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
index de154adb1497..d3ab6c68a60b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
@@ -421,7 +421,6 @@ vdd_npu_s0: regulator@42 {
reg = <0x42>;
fcs,suspend-voltage-selector = <1>;
regulator-name = "vdd_npu_s0";
- regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
@@ -683,6 +682,10 @@ &pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
+&pd_npu {
+ domain-supply = <&vdd_npu_s0>;
+};
+
&pinctrl {
hym8563 {
rtc_int: rtc-int {
@@ -802,6 +805,36 @@ dp1_hpd: dp1-hpd {
};
};
+&rknn_core_0 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_1 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_2 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_mmu_0 {
+ status = "okay";
+};
+
+&rknn_mmu_1 {
+ status = "okay";
+};
+
+&rknn_mmu_2 {
+ status = "okay";
+};
+
&pwm14 {
pinctrl-names = "default";
pinctrl-0 = <&pwm14m1_pins>;
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* Re: [PATCH V3 8/9] iio: imu: inv_icm42607: Add Gyroscope to icm42607
From: Jonathan Cameron @ 2026-04-13 19:39 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-9-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:52 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add gyroscope functions to the icm42607 driver.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
One very minor comment.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> new file mode 100644
> index 000000000000..80473c07c6a4
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_gyro.c
> +
> +static const struct iio_chan_spec_ext_info inv_icm42607_gyro_ext_infos[] = {
> + IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42607_get_mount_matrix),
> + {},
{ }
> +};
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 7/9] iio: imu: inv_icm42607: Add Interrupt and Wake on Movement for icm42607
From: Jonathan Cameron @ 2026-04-13 19:37 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-8-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:51 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add support for wake on movement for the icm42607 driver.
>
> At this point the driver is usable as an accelerometer/temperature
> driver, so add the necessary Makefile and Kconfig changes as well.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>l
A few comments on this one.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 56bb09e2c304..f5f1b5fea183 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
...
>
> struct iio_dev *inv_icm42607_accel_init(struct inv_icm42607_state *st)
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 62a1371b0c4a..4ac3af52c1b8 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +
> +int inv_icm42607_disable_wom(struct inv_icm42607_state *st)
> +{
> + int ret;
> +
> + /* disable WoM interrupt */
> + ret = regmap_clear_bits(st->map, INV_ICM42607_REG_INT_SOURCE1,
> + INV_ICM42607_INT_SOURCE1_WOM_INT1_EN);
> + if (ret)
> + return ret;
> +
> + /* disable WoM hardware */
> + return regmap_clear_bits(st->map, INV_ICM42607_REG_WOM_CONFIG,
> + INV_ICM42607_WOM_CONFIG_EN);
regmap_set_bits()
> +}
> +
> +
As below.
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> +
> +/**
> + * inv_icm42607_irq_init() - initialize int pin and interrupt handler
> + * @st: driver internal state
> + * @irq: irq number
> + * @irq_type: irq trigger type
> + * @open_drain: true if irq is open drain, false for push-pull
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42607_irq_init(struct inv_icm42607_state *st, int irq,
> + int irq_type, bool open_drain)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int val = 0;
> + int ret;
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_RISING:
> + case IRQF_TRIGGER_HIGH:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_HIGH;
> + break;
> + default:
> + val = INV_ICM42607_INT_CONFIG_INT1_ACTIVE_LOW;
> + break;
> + }
> +
> + switch (irq_type) {
> + case IRQF_TRIGGER_LOW:
> + case IRQF_TRIGGER_HIGH:
> + val |= INV_ICM42607_INT_CONFIG_INT1_LATCHED;
> + break;
> + default:
> + break;
> + }
> +
> + if (!open_drain)
> + val |= INV_ICM42607_INT_CONFIG_INT1_PUSH_PULL;
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_INT_CONFIG, val);
> + if (ret)
> + return ret;
> +
> + irq_type |= IRQF_ONESHOT;
> + return devm_request_threaded_irq(dev, irq, inv_icm42607_irq_timestamp,
> + inv_icm42607_irq_handler, irq_type,
> + st->name, st);
> +}
> +
> +
Trivial but single line is always enough (in IIO anyway)
> static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 6/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: Jonathan Cameron @ 2026-04-13 19:32 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-7-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:50 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add icm42607 accelerometer sensor for icm42607.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
A few more things below.
thanks
Jonathan
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> new file mode 100644
> index 000000000000..58754af31100
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_accel.c
> +
> +static const struct iio_enum inv_icm42607_accel_power_mode_enum = {
> + .items = inv_icm42607_accel_power_mode_items,
> + .num_items = ARRAY_SIZE(inv_icm42607_accel_power_mode_items),
> + .set = inv_icm42607_accel_power_mode_set,
> + .get = inv_icm42607_accel_power_mode_get,
> +};
> +
> +static const struct iio_chan_spec_ext_info inv_icm42607_accel_ext_infos[] = {
> + IIO_MOUNT_MATRIX(IIO_SHARED_BY_ALL, inv_icm42607_get_mount_matrix),
> + IIO_ENUM_AVAILABLE("power_mode", IIO_SHARED_BY_TYPE,
> + &inv_icm42607_accel_power_mode_enum),
> + IIO_ENUM("power_mode", IIO_SHARED_BY_TYPE,
> + &inv_icm42607_accel_power_mode_enum),
> + { },
No comma.
> +};
> +static int inv_icm42607_accel_read_odr(struct inv_icm42607_state *st,
> + int *val, int *val2)
> +{
> + unsigned int odr;
> + unsigned int i;
> +
> + odr = st->conf.accel.odr;
> +
> + for (i = 0; i < ARRAY_SIZE(inv_icm42607_accel_odr_conv); ++i) {
> + if (inv_icm42607_accel_odr_conv[i] == odr)
> + break;
> + }
> + if (i >= ARRAY_SIZE(inv_icm42607_accel_odr_conv))
> + return -EINVAL;
> +
> + *val = inv_icm42607_accel_odr[2 * i];
> + *val2 = inv_icm42607_accel_odr[2 * i + 1];
> +
> + return IIO_VAL_INT_PLUS_MICRO;
> +}
> +
> +static int inv_icm42607_accel_write_odr(struct iio_dev *indio_dev,
> + int val, int val2)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct inv_sensors_timestamp *ts = &accel_st->ts;
> + struct device *dev = regmap_get_device(st->map);
> + unsigned int idx;
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + int ret;
> +
> + for (idx = 0; idx < ARRAY_SIZE(inv_icm42607_accel_odr); idx += 2) {
> + if (val == inv_icm42607_accel_odr[idx] &&
> + val2 == inv_icm42607_accel_odr[idx + 1])
> + break;
> + }
> + if (idx >= ARRAY_SIZE(inv_icm42607_accel_odr))
> + return -EINVAL;
> +
> + conf.odr = inv_icm42607_accel_odr_conv[idx / 2];
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> + return -ENXIO;
> +
> + guard(mutex)(&st->lock);
> +
> + ret = inv_sensors_timestamp_update_odr(ts, inv_icm42607_odr_to_period(conf.odr),
> + iio_buffer_enabled(indio_dev));
> + if (ret)
> + return ret;
> +
> + ret = inv_icm42607_set_accel_conf(st, &conf, NULL);
> + if (ret)
> + return ret;
> +
> + inv_icm42607_buffer_update_fifo_period(st);
> + inv_icm42607_buffer_update_watermark(st);
> +
> + return ret;
> +}
> +
> +/*
> + * Calibration bias values, IIO range format int + micro.
> + * Not actually supported in the ICM-42607P registers.
> + */
> +static int inv_icm42607_accel_write_calibbias(struct inv_icm42607_state *st,
> + struct iio_chan_spec const *chan,
> + int val, int val2)
> +{
> + /* Not actually supported in the ICM-42607P registers */
> + return -EOPNOTSUPP;
> +}
> +
> +static int inv_icm42607_accel_read_calibbias(struct inv_icm42607_state *st,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2)
> +{
> + /* Not actually supported in the ICM-42607P registers */
> + return -EOPNOTSUPP;
> +}
> +
> +static int inv_icm42607_accel_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + s16 data;
> + int ret;
> +
> + switch (chan->type) {
> + case IIO_ACCEL:
> + break;
> + case IIO_TEMP:
> + return inv_icm42607_temp_read_raw(indio_dev, chan, val, val2, mask);
> + default:
> + return -EINVAL;
> + }
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> + ret = inv_icm42607_accel_read_sensor(indio_dev, chan, &data);
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> + *val = data;
> + return IIO_VAL_INT;
> + case IIO_CHAN_INFO_SCALE:
> + return inv_icm42607_accel_read_scale(indio_dev, val, val2);
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return inv_icm42607_accel_read_odr(st, val, val2);
> + case IIO_CHAN_INFO_CALIBBIAS:
> + return inv_icm42607_accel_read_calibbias(st, chan, val, val2);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +int inv_icm42607_accel_parse_fifo(struct iio_dev *indio_dev)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct inv_sensors_timestamp *ts = &accel_st->ts;
> + ssize_t i, size;
> + unsigned int no;
> + const void *accel, *gyro, *timestamp;
> + const int8_t *temp;
> + unsigned int odr;
> + int64_t ts_val;
> + struct inv_icm42607_accel_buffer buffer = { };
> +
> + /* parse all fifo packets */
> + for (i = 0, no = 0; i < st->fifo.count; i += size, ++no) {
> + size = inv_icm42607_fifo_decode_packet(&st->fifo.data[i],
> + &accel, &gyro, &temp, ×tamp, &odr);
> + /* quit if error or FIFO is empty */
> + if (size <= 0)
> + return size;
> +
> + /* skip packet if no accel data or data is invalid */
> + if (accel == NULL || !inv_icm42607_fifo_is_data_valid(accel))
> + continue;
> +
> + /* update odr */
> + if (odr & INV_ICM42607_SENSOR_ACCEL) {
> + inv_sensors_timestamp_apply_odr(ts, st->fifo.period,
> + st->fifo.nb.total, no);
> + }
> +
> + memcpy(&buffer.accel, accel, sizeof(buffer.accel));
> + /* convert 8 bits FIFO temperature in high resolution format */
> + buffer.temp = temp ? (*temp * 64) : 0;
> + ts_val = inv_sensors_timestamp_pop(ts);
> + iio_push_to_buffers_with_timestamp(indio_dev, &buffer, ts_val);
For new code, always use iio_push_to_buffers_with_ts()
This one is going away in near future.
> + }
> +
> + return 0;
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 735a262dc103..62a1371b0c4a 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +int inv_icm42607_set_accel_conf(struct inv_icm42607_state *st,
> + struct inv_icm42607_sensor_conf *conf,
> + unsigned int *sleep_ms)
> +{
> + struct inv_icm42607_sensor_conf *oldconf = &st->conf.accel;
> + unsigned int val;
> + int ret;
> +
> + if (conf->mode < 0)
> + conf->mode = oldconf->mode;
> + if (conf->fs < 0)
> + conf->fs = oldconf->fs;
> + if (conf->odr < 0)
> + conf->odr = oldconf->odr;
> + if (conf->filter < 0)
> + conf->filter = oldconf->filter;
> +
> + if (conf->fs != oldconf->fs || conf->odr != oldconf->odr) {
> + val = INV_ICM42607_ACCEL_CONFIG0_FS_SEL(conf->fs) |
> + INV_ICM42607_ACCEL_CONFIG0_ODR(conf->odr);
Another indent case that needs fixing.
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> + oldconf->fs = conf->fs;
> + oldconf->odr = conf->odr;
> + }
> +
> + if (conf->filter != oldconf->filter) {
> + if (conf->mode == INV_ICM42607_SENSOR_MODE_LOW_POWER) {
> + val = INV_ICM42607_ACCEL_CONFIG1_AVG(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_AVG_MASK, val);
> + } else {
> + val = INV_ICM42607_ACCEL_CONFIG1_FILTER(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK, val);
> + }
> + if (ret)
> + return ret;
> + oldconf->filter = conf->filter;
> + }
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode, conf->mode,
> + st->conf.temp_en, sleep_ms);
> +}
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 4/9] iio: imu: inv_icm42607: Add Buffer support functions to icm42607
From: Jonathan Cameron @ 2026-04-13 19:23 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-5-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:48 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add all FIFO parsing and reading functions to support
> inv_icm42607 hardware.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
A few minor things inline.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 4 +
> .../imu/inv_icm42607/inv_icm42607_buffer.c | 496 ++++++++++++++++++
> .../imu/inv_icm42607/inv_icm42607_buffer.h | 98 ++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 25 +
> 4 files changed, 623 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 7d13091aa8df..5530fd3bc03f 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> new file mode 100644
> index 000000000000..4f5f199586fc
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.c
> @@ -0,0 +1,496 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/minmax.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/delay.h>
> +
> +#include <linux/iio/buffer.h>
> +#include <linux/iio/common/inv_sensors_timestamp.h>
> +#include <linux/iio/iio.h>
Alphabetical order (+ a block for IIO) for headers.
> +
> +static unsigned int inv_icm42607_wm_truncate(unsigned int watermark,
> + size_t packet_size)
> +{
> + size_t wm_size;
> + unsigned int wm;
> +
> + wm_size = watermark * packet_size;
> + if (wm_size > INV_ICM42607_FIFO_WATERMARK_MAX)
> + wm_size = INV_ICM42607_FIFO_WATERMARK_MAX;
> +
> + wm = wm_size / packet_size;
> +
> + return wm;
Why not
return wm_size / packet_size;
> +}
> +int inv_icm42607_buffer_hwfifo_flush(struct inv_icm42607_state *st,
> + unsigned int count)
> +{
> + s64 gyro_ts, accel_ts;
> + int ret;
> +
> + gyro_ts = iio_get_time_ns(st->indio_gyro);
> + accel_ts = iio_get_time_ns(st->indio_accel);
> +
> + ret = inv_icm42607_buffer_fifo_read(st, count);
> +
> + return ret;
Either
return inv_...
or
ret =
if (ret)
return ret;
return 0;
2nd one only if this is going to get more complex in later patches.
> +}
> +
> +int inv_icm42607_buffer_init(struct inv_icm42607_state *st)
> +{
> + unsigned int val;
> + int ret;
> +
> + st->fifo.watermark.eff_gyro = 1;
> + st->fifo.watermark.eff_accel = 1;
> +
> + /* Configure FIFO_COUNT format in bytes and big endian */
> + val = INV_ICM42607_INTF_CONFIG0_FIFO_COUNT_ENDIAN;
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + val, val);
regmap_set_bits();
> + if (ret)
> + return ret;
> +
> + /* Initialize FIFO in bypass mode */
> + return regmap_write(st->map, INV_ICM42607_REG_FIFO_CONFIG1,
> + INV_ICM42607_FIFO_CONFIG1_BYPASS);
> +}
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
> new file mode 100644
> index 000000000000..64a66c00a861
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_buffer.h
...
> +/* FIFO data packet */
> +struct inv_icm42607_fifo_sensor_data {
> + __be16 x;
> + __be16 y;
> + __be16 z;
> +} __packed;
Why packed? It will be anyway unless I'm missing something.
> +#define INV_ICM42607_FIFO_DATA_INVALID -32768
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index da04c820dab2..344071089042 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
...
> @@ -436,6 +449,8 @@ static int inv_icm42607_suspend(struct device *dev)
> static int inv_icm42607_resume(struct device *dev)
> {
> struct inv_icm42607_state *st = dev_get_drvdata(dev);
> + struct inv_icm42607_sensor_state *gyro_st = iio_priv(st->indio_gyro);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(st->indio_accel);
> struct device *accel_dev;
> bool wakeup;
> int ret;
> @@ -462,6 +477,16 @@ static int inv_icm42607_resume(struct device *dev)
> ret = inv_icm42607_set_pwr_mgmt0(st, st->suspended.gyro,
> st->suspended.accel,
> st->suspended.temp, NULL);
> + if (ret)
> + return ret;
> +
> + if (st->fifo.on) {
I've not checked, but if this doesn't get more complex you can do
if (!st->fifo.on)
return 0;
inv_....
return regmap_write();
> + inv_sensors_timestamp_reset(&gyro_st->ts);
> + inv_sensors_timestamp_reset(&accel_st->ts);
> + ret = regmap_write(st->map, INV_ICM42607_REG_FIFO_CONFIG1,
> + INV_ICM42607_FIFO_CONFIG1_MODE);
> + }
> +
> return ret;
> }
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v13 13/27] drm/i915: Implement the "color format" DRM property
From: Ville Syrjälä @ 2026-04-13 19:21 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260413-color-format-v13-13-ab37d4dfba48@collabora.com>
On Mon, Apr 13, 2026 at 12:07:27PM +0200, Nicolas Frattaroli wrote:
> Implement the "color format" DRM property for both DP and HDMI. The
> values of the property include RGB, YCbCr420, YCbCr444 and Auto. Auto
> will pick RGB, with a fallback to YCbCr420.
>
> The mask of supported formats by the source exposed by the property is
> an optimistic scenario, as specific DFP-related caveats can't be
> established before an EDID is present.
>
> Should the explicitly requested color format not be supported by the
> sink (or by the source in combination with the sink), then an error is
> returned to userspace, so that it can make a better choice.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_connector.c | 10 +++++++
> drivers/gpu/drm/i915/display/intel_connector.h | 1 +
> drivers/gpu/drm/i915/display/intel_dp.c | 38 +++++++++++++++++++++++---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 38 +++++++++++++++++++++++---
> 4 files changed, 79 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c b/drivers/gpu/drm/i915/display/intel_connector.c
> index 7ef9338d67ab..b1a21dd77af6 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.c
> +++ b/drivers/gpu/drm/i915/display/intel_connector.c
> @@ -338,3 +338,13 @@ intel_attach_scaling_mode_property(struct drm_connector *connector)
>
> connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
> }
> +
> +void
> +intel_attach_color_format_property(struct drm_connector *connector)
> +{
> + const unsigned long fmts = BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) |
> + BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR420);
We're going to need different formats for different platforms, and
for DP vs. HDMI.
For HDMI it should be fairly simple if we have the
ycbcr420_allowed and ycbcr444_allowed things to consult.
For DP I'm not sure if we want to advertise YCbCr output support
for platforms that can't produce it without help from the PCON.
If we know there is an on board PCON that can do it, then the answer
is probably yes. But without that it might be best to not advertise
the relevant formats unless source_can_output() tells us that it can
be directly output. We could at least start with that, and revisit
it later if some situations arise where eg. having explicit 4:2:0
output on older platforms is beneficial.
I think you want to split this to separate DP vs. HDMI patches since
the two require quite different logic.
> +
> + drm_connector_attach_color_format_property(connector, fmts);
> +}
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.h b/drivers/gpu/drm/i915/display/intel_connector.h
> index 0aa86626e646..c77b7aac02cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_connector.h
> +++ b/drivers/gpu/drm/i915/display/intel_connector.h
> @@ -34,5 +34,6 @@ void intel_attach_dp_colorspace_property(struct drm_connector *connector);
> void intel_attach_scaling_mode_property(struct drm_connector *connector);
> void intel_connector_queue_modeset_retry_work(struct intel_connector *connector);
> void intel_connector_cancel_modeset_retry_work(struct intel_connector *connector);
> +void intel_attach_color_format_property(struct drm_connector *connector);
>
> #endif /* __INTEL_CONNECTOR_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 47bd3d59ea93..3b2293415b55 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -3398,10 +3398,10 @@ intel_dp_compute_output_format(struct intel_encoder *encoder,
> }
>
> static int
> -intel_dp_compute_formats(struct intel_encoder *encoder,
> - struct intel_crtc_state *crtc_state,
> - struct drm_connector_state *conn_state,
> - bool respect_downstream_limits)
> +intel_dp_compute_formats_auto(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state,
> + bool respect_downstream_limits)
> {
> struct intel_display *display = to_intel_display(encoder);
> struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> @@ -3437,6 +3437,34 @@ intel_dp_compute_formats(struct intel_encoder *encoder,
> return ret;
> }
>
> +static int
> +intel_dp_compute_formats(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> + struct drm_connector_state *conn_state,
> + bool respect_downstream_limits)
> +{
> + switch (conn_state->color_format) {
> + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> + return intel_dp_compute_output_format(encoder, crtc_state, conn_state,
> + respect_downstream_limits,
> + INTEL_OUTPUT_FORMAT_RGB);
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> + return intel_dp_compute_output_format(encoder, crtc_state, conn_state,
> + respect_downstream_limits,
> + INTEL_OUTPUT_FORMAT_YCBCR444);
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> + return intel_dp_compute_output_format(encoder, crtc_state, conn_state,
> + respect_downstream_limits,
> + INTEL_OUTPUT_FORMAT_YCBCR420);
> + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> + return intel_dp_compute_formats_auto(encoder, crtc_state, conn_state,
> + respect_downstream_limits);
> + default:
> + MISSING_CASE(conn_state->color_format);
> + return -EINVAL;
> + }
> +}
> +
> void
> intel_dp_audio_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> @@ -7025,6 +7053,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *_connec
>
> if (HAS_VRR(display))
> drm_connector_attach_vrr_capable_property(&connector->base);
> +
> + intel_attach_color_format_property(&connector->base);
> }
>
> static void
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 5ab5b5f85cde..632498e3702b 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2307,10 +2307,10 @@ static int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
> return intel_hdmi_compute_clock(encoder, crtc_state, respect_downstream_limits);
> }
>
> -static int intel_hdmi_compute_formats(struct intel_encoder *encoder,
> - struct intel_crtc_state *crtc_state,
> - const struct drm_connector_state *conn_state,
> - bool respect_downstream_limits)
> +static int intel_hdmi_compute_formats_auto(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> + const struct drm_connector_state *conn_state,
> + bool respect_downstream_limits)
> {
> struct intel_display *display = to_intel_display(encoder);
> struct intel_connector *connector = to_intel_connector(conn_state->connector);
> @@ -2345,6 +2345,35 @@ static int intel_hdmi_compute_formats(struct intel_encoder *encoder,
> return ret;
> }
>
> +static int intel_hdmi_compute_formats(struct intel_encoder *encoder,
> + struct intel_crtc_state *crtc_state,
> + const struct drm_connector_state *conn_state,
> + bool respect_downstream_limits)
> +{
> + struct intel_connector *connector = to_intel_connector(conn_state->connector);
> +
> + switch (conn_state->color_format) {
> + case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> + return intel_hdmi_compute_output_format(encoder, crtc_state, connector,
> + respect_downstream_limits,
> + INTEL_OUTPUT_FORMAT_RGB);
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> + return intel_hdmi_compute_output_format(encoder, crtc_state, connector,
> + respect_downstream_limits,
> + INTEL_OUTPUT_FORMAT_YCBCR444);
> + case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> + return intel_hdmi_compute_output_format(encoder, crtc_state, connector,
> + respect_downstream_limits,
> + INTEL_OUTPUT_FORMAT_YCBCR420);
> + case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> + return intel_hdmi_compute_formats_auto(encoder, crtc_state, conn_state,
> + respect_downstream_limits);
> + default:
> + MISSING_CASE(conn_state->color_format);
> + return -EINVAL;
> + }
> +}
> +
> static bool intel_hdmi_is_cloned(const struct intel_crtc_state *crtc_state)
> {
> return crtc_state->uapi.encoder_mask &&
> @@ -2729,6 +2758,7 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *_
>
> intel_attach_hdmi_colorspace_property(&connector->base);
> drm_connector_attach_content_type_property(&connector->base);
> + intel_attach_color_format_property(&connector->base);
>
> if (DISPLAY_VER(display) >= 10)
> drm_connector_attach_hdr_output_metadata_property(&connector->base);
>
> --
> 2.53.0
--
Ville Syrjälä
Intel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v13 12/27] drm/i915/dp: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-04-13 19:08 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260413-color-format-v13-12-ab37d4dfba48@collabora.com>
On Mon, Apr 13, 2026 at 12:07:26PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for sink support of YCBCR444 to intel_dp_sink_format_valid.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 35b8fb5740aa..47bd3d59ea93 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1364,6 +1364,11 @@ intel_dp_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
The DP situation is a lot more more fuzzy than the HDMI situation
due to the PCON stuff. So I'm not quite sure what we should do here.
At the very least I think we want the equivalent of
intel_dp_can_ycbcr420() for 444, and the same intel_dp_has_hdmi_sink()
check that we have for 420.
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.53.0
--
Ville Syrjälä
Intel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: Jonathan Cameron @ 2026-04-13 19:06 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-iio, andy, nuno.sa, dlechner, jean-baptiste.maneyrol,
linux-rockchip, devicetree, heiko, conor+dt, krzk+dt, robh,
andriy.shevchenko, Chris Morgan
In-Reply-To: <20260330195853.392877-3-macroalpha82@gmail.com>
On Mon, 30 Mar 2026 14:58:46 -0500
Chris Morgan <macroalpha82@gmail.com> wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the core component of a new inv_icm42607 driver. This includes
> a few setup functions and the full register definition in the
> header file.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Hi Chris,
I've avoided repeating a few things David raised, but there may
well be overlap on some things. I'm not particularly keen on code
that doesn't build at the end of a patch or even provide the Kconfig
and makefile stuff to do so. Maybe it's too much effort given how you have
this structured.
Thanks,
Jonathan
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 424 ++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 300 +++++++++++++
> 2 files changed, 724 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> new file mode 100644
> index 000000000000..609188c40ffc
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> @@ -0,0 +1,424 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#ifndef INV_ICM42607_H_
> +#define INV_ICM42607_H_
> +
> +#include <linux/bitops.h>
> +#include <linux/bitfield.h>
> +#include <linux/regmap.h>
> +#include <linux/mutex.h>
> +#include <linux/regulator/consumer.h>
Alphabetical order. Though fine to have an IIO specific block at the end.
> +#include <linux/iio/iio.h>
> +#include <linux/iio/common/inv_sensors_timestamp.h>
> +/* ODR values */
> +enum inv_icm42607_odr {
> + INV_ICM42607_ODR_1600HZ = 5,
> + INV_ICM42607_ODR_800HZ,
> + INV_ICM42607_ODR_400HZ,
> + INV_ICM42607_ODR_200HZ,
> + INV_ICM42607_ODR_100HZ,
> + INV_ICM42607_ODR_50HZ,
> + INV_ICM42607_ODR_25HZ,
> + INV_ICM42607_ODR_12_5HZ,
> + INV_ICM42607_ODR_6_25HZ_LP,
> + INV_ICM42607_ODR_3_125HZ_LP,
> + INV_ICM42607_ODR_1_5625HZ_LP,
> + INV_ICM42607_ODR_NB,
If just here as number, then no terminating comma as
we don't want to imply something might come after it.
Same for all the other enums.
> +};
> +
> +enum inv_icm42607_filter {
> + /* Low-Noise mode sensor data filter */
> + INV_ICM42607_FILTER_BYPASS,
> + INV_ICM42607_FILTER_BW_180HZ,
> + INV_ICM42607_FILTER_BW_121HZ,
> + INV_ICM42607_FILTER_BW_73HZ,
> + INV_ICM42607_FILTER_BW_53HZ,
> + INV_ICM42607_FILTER_BW_34HZ,
> + INV_ICM42607_FILTER_BW_25HZ,
> + INV_ICM42607_FILTER_BW_16HZ,
> +
> + /* Low-Power mode sensor data filter (averaging) */
> + INV_ICM42607_FILTER_AVG_2X = 0,
> + INV_ICM42607_FILTER_AVG_4X,
> + INV_ICM42607_FILTER_AVG_8X,
> + INV_ICM42607_FILTER_AVG_16X,
> + INV_ICM42607_FILTER_AVG_32X,
> + INV_ICM42607_FILTER_AVG_64X,
Bring these in when used. For now these to me look like they should be broken
into two separate enums. I can't see how the will be used though so hard
to tell.
> +};
>
> +#define INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK GENMASK(1, 0)
> +#define INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL \
> + FIELD_PREP(INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK, 1)
Define the value of the field to give that a name and use FIELD_PREP() inline.
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> new file mode 100644
> index 000000000000..6b7078387568
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> @@ -0,0 +1,300 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
Most likely this should be more specific headers like
dev_printk.h etc It is pretty rare it makes sense to include
device.h if following IWYU approach (which we do for IIO drivers
and is generally accepted across the kernel).
> +#include <linux/module.h>
Alphabetical order.
> +#include <linux/slab.h>
> +#include <linux/delay.h>
> +#include <linux/mutex.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/property.h>
> +#include <linux/regmap.h>
> +#include <linux/iio/iio.h>
> +u32 inv_icm42607_odr_to_period(enum inv_icm42607_odr odr)
> +{
> + static u32 odr_periods[INV_ICM42607_ODR_NB] = {
Hopefully the compiler can figure it out, but better
as explicit const.
> + /* Reserved values */
> + 0, 0, 0, 0, 0,
> + /* 1600Hz */
> + 625000,
> + /* 800Hz */
> + 1250000,
> + /* 400Hz */
> + 2500000,
> + /* 200Hz */
> + 5000000,
> + /* 100 Hz */
> + 10000000,
> + /* 50Hz */
> + 20000000,
> + /* 25Hz */
> + 40000000,
> + /* 12.5Hz */
> + 80000000,
> + /* 6.25Hz */
> + 160000000,
> + /* 3.125Hz */
> + 320000000,
> + /* 1.5625Hz */
> + 640000000,
> + };
> +
> + return odr_periods[odr];
> +}
> +
> +static int inv_icm42607_set_conf(struct inv_icm42607_state *st,
> + const struct inv_icm42607_conf *conf)
> +{
> + unsigned int val;
> + int ret;
> +
> + val = INV_ICM42607_PWR_MGMT0_GYRO(conf->gyro.mode) |
> + INV_ICM42607_PWR_MGMT0_ACCEL(conf->accel.mode);
Align as
val = INV_ICM42607_PWR_MGMT0_GYRO(conf->gyro.mode) |
INV_ICM42607_PWR_MGMT0_ACCEL(conf->accel.mode);
Though as mentioned in David's review, prefer to see the FIELD_PREP()
inline.
> + /*
> + * No temperature enable reg in datasheet, but BSP driver
> + * selected RC oscillator clock in LP mode when temperature
> + * was disabled.
> + */
> + if (!conf->temp_en)
> + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
Could make this
val |= FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL,
!conf->temp_en);
Not particularly important though if you prefer the if.
> + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_GYRO_CONFIG0_FS_SEL(conf->gyro.fs) |
> + INV_ICM42607_GYRO_CONFIG0_ODR(conf->gyro.odr);
As above. If it's the second line of a statement, it must be indented
to avoid readability issues. Fix all examples of this.
> + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_ACCEL_CONFIG0_FS_SEL(conf->accel.fs) |
> + INV_ICM42607_ACCEL_CONFIG0_ODR(conf->accel.odr);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_GYRO_CONFIG1_FILTER(conf->gyro.filter);
> + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG1, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_ACCEL_CONFIG1_FILTER(conf->accel.filter);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG1, val);
> + if (ret)
> + return ret;
> +
> + st->conf = *conf;
> +
> + return 0;
> +}
> +
> +/**
> + * inv_icm42607_setup() - check and setup chip
> + * @st: driver internal state
> + * @bus_setup: callback for setting up bus specific registers
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42607_setup(struct inv_icm42607_state *st,
> + inv_icm42607_bus_setup bus_setup)
> +{
> + const struct inv_icm42607_hw *hw = &inv_icm42607_hw[st->chip];
> + const struct device *dev = regmap_get_device(st->map);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
> + if (ret)
> + return ret;
> +
> + if (val != hw->whoami)
> + dev_warn_probe(dev, -ENODEV,
> + "invalid whoami %#02x expected %#02x (%s)\n",
> + val, hw->whoami, hw->name);
> +
> + st->name = hw->name;
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
> + INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
> + if (ret)
> + return ret;
> + msleep(INV_ICM42607_RESET_TIME_MS);
fsleep() here as sleeping longer is probably fine and that function will
apply appropriate slack on the times.
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_INT_STATUS, &val);
> + if (ret)
> + return ret;
> + if (!(val & INV_ICM42607_INT_STATUS_RESET_DONE))
> + return dev_err_probe(dev, -ENODEV,
> + "reset error, reset done bit not set\n");
> +
> + ret = bus_setup(st);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN,
> + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL);
> + if (ret)
> + return ret;
> +
> + return inv_icm42607_set_conf(st, hw->conf);
> +}
> +
> +static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
> +{
> + int ret;
> +
> + ret = regulator_enable(st->vddio_supply);
> + if (ret)
> + return ret;
> +
> + usleep_range(3000, 4000);
David covered this, fsleep() preferred.
> +
> + return 0;
> +}
> +
> +int inv_icm42607_core_probe(struct regmap *regmap, int chip,
> + inv_icm42607_bus_setup bus_setup)
> +{
> + struct device *dev = regmap_get_device(regmap);
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + struct inv_icm42607_state *st;
> + int irq, irq_type;
> + bool open_drain;
> + int ret;
> +
> + if (chip < INV_CHIP_INVALID || chip >= INV_CHIP_NB)
> + dev_warn_probe(dev, -ENODEV,
> + "Invalid chip = %d\n", chip);
Easily fits on one line shorter than 80 chars.
> +
> + /* get INT1 only supported interrupt or fallback to first interrupt */
Why the fallback? I suspect this is copied from a driver
that didn't (bug) support named interrupts from the start. Given you are
doing so here, just insist on named one to simplify things. I'd imagine
that if INT2 is ever supported, the device configuration will need to be
different.
> + irq = fwnode_irq_get_byname(fwnode, "INT1");
> + if (irq < 0 && irq != -EPROBE_DEFER) {
> + dev_info(dev, "no INT1 interrupt defined, fallback to first interrupt\n");
> + irq = fwnode_irq_get(fwnode, 0);
> + }
> + if (irq < 0)
> + return dev_err_probe(dev, irq, "error missing INT1 interrupt\n");
> +
> + irq_type = irq_get_trigger_type(irq);
> + if (!irq_type)
> + irq_type = IRQF_TRIGGER_FALLING;
Not used at this point. Bring it in when you use it so we can understand
the default setting.
> +
> + open_drain = device_property_read_bool(dev, "drive-open-drain");
> +
> + st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> + if (!st)
> + return -ENOMEM;
> +
> + dev_set_drvdata(dev, st);
> + mutex_init(&st->lock);
For new code
ret = devm_mutex_init(&st->lock);
if (ret)
return ret;
Brings a very small advantage if someone is debugging locks.
> + st->chip = chip;
> + st->map = regmap;
> + st->irq = irq;
> +
> + ret = iio_read_mount_matrix(dev, &st->orientation);
> + if (ret) {
> + dev_err(dev, "failed to retrieve mounting matrix %d\n", ret);
> + return ret;
return dev_err_probe();
> + }
> +
> + ret = devm_regulator_get_enable(dev, "vdd");
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to get vdd regulator\n");
> +
> + msleep(INV_ICM42607_POWER_UP_TIME_MS);
> +
> + st->vddio_supply = devm_regulator_get(dev, "vddio");
> + if (IS_ERR(st->vddio_supply))
> + return PTR_ERR(st->vddio_supply);
> +
> + ret = inv_icm42607_enable_vddio_reg(st);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev, inv_icm42607_disable_vddio_reg, st);
> + if (ret)
> + return ret;
> +
> + /* Setup chip registers (includes WHOAMI check, reset check, bus setup) */
> + ret = inv_icm42607_setup(st, bus_setup);
> +
> + return ret;
Looking forwards I would instead do:
if (ret)
return ret;
return 0;
I think that makes it easier to add the additional pm stuff in later patches.
> +}
> +EXPORT_SYMBOL_NS_GPL(inv_icm42607_core_probe, "IIO_ICM42607");
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v13 11/27] drm/i915/hdmi: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-04-13 19:04 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <ad08zqpKbyF--Br3@intel.com>
On Mon, Apr 13, 2026 at 09:58:22PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 13, 2026 at 12:07:25PM +0200, Nicolas Frattaroli wrote:
> > In anticipation of userspace being able to explicitly select supported
> > sink formats, add handling of the YCBCR444 sink format. The AUTO path
> > does not choose this format, but with explicit format selection added to
> > the driver, it becomes a possibility.
> >
> > Check for YCBCR444 support on the sink in both sink_bpc_possible, and
> > sink_format_valid.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > index 874076a29da4..5ab5b5f85cde 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > @@ -1966,6 +1966,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
> >
> > if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36;
> > + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> > + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36;
> > else
> > return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36;
> > case 10:
> > @@ -1974,6 +1976,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
> >
> > if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> > return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_30;
> > + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> > + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30;
> > else
> > return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30;
> > case 8:
> > @@ -2038,6 +2042,11 @@ intel_hdmi_sink_format_valid(struct intel_connector *connector,
> >
> > return MODE_OK;
> > case INTEL_OUTPUT_FORMAT_RGB:
> > + return MODE_OK;
> > + case INTEL_OUTPUT_FORMAT_YCBCR444:
>
> We'll also want the !has_hdmi_sink check here like for 4:2:0.
>
> And I think we also want something to mirror the ycbcr_420_allowed
> flag. I guess you could just make it something like:
>
> intel_hdmi_ycbcr_444_allowed(display)
> {
> return DISPLAY_VER(display) >= 5 && !HAS_GMCH(display);
Actually the display version check is redundant there.
!HAS_GMCH alone is sufficient.
> }
>
> That can also be reused when setting up the allowed property values.
>
> > + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> > + return MODE_BAD;
> > +
> > return MODE_OK;
> > default:
> > MISSING_CASE(sink_format);
> >
> > --
> > 2.53.0
>
> --
> Ville Syrjälä
> Intel
--
Ville Syrjälä
Intel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v13 11/27] drm/i915/hdmi: Add YCBCR444 handling for sink formats
From: Ville Syrjälä @ 2026-04-13 18:58 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260413-color-format-v13-11-ab37d4dfba48@collabora.com>
On Mon, Apr 13, 2026 at 12:07:25PM +0200, Nicolas Frattaroli wrote:
> In anticipation of userspace being able to explicitly select supported
> sink formats, add handling of the YCBCR444 sink format. The AUTO path
> does not choose this format, but with explicit format selection added to
> the driver, it becomes a possibility.
>
> Check for YCBCR444 support on the sink in both sink_bpc_possible, and
> sink_format_valid.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/i915/display/intel_hdmi.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 874076a29da4..5ab5b5f85cde 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1966,6 +1966,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_36;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_36;
> case 10:
> @@ -1974,6 +1976,8 @@ static bool intel_hdmi_sink_bpc_possible(struct drm_connector *_connector,
>
> if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> return hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_30;
> + else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return info->edid_hdmi_ycbcr444_dc_modes & DRM_EDID_HDMI_DC_30;
> else
> return info->edid_hdmi_rgb444_dc_modes & DRM_EDID_HDMI_DC_30;
> case 8:
> @@ -2038,6 +2042,11 @@ intel_hdmi_sink_format_valid(struct intel_connector *connector,
>
> return MODE_OK;
> case INTEL_OUTPUT_FORMAT_RGB:
> + return MODE_OK;
> + case INTEL_OUTPUT_FORMAT_YCBCR444:
We'll also want the !has_hdmi_sink check here like for 4:2:0.
And I think we also want something to mirror the ycbcr_420_allowed
flag. I guess you could just make it something like:
intel_hdmi_ycbcr_444_allowed(display)
{
return DISPLAY_VER(display) >= 5 && !HAS_GMCH(display);
}
That can also be reused when setting up the allowed property values.
> + if (!(info->color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444)))
> + return MODE_BAD;
> +
> return MODE_OK;
> default:
> MISSING_CASE(sink_format);
>
> --
> 2.53.0
--
Ville Syrjälä
Intel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v13 00/27] Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-04-13 18:45 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Heiko Stübner, linux-doc, Joonas Lahtinen, dri-devel,
linux-kernel, Andri Yngvason, Laurent Pinchart, Andrzej Hajda,
Shuah Khan, kernel, David Airlie, Marius Vlad, Simona Vetter,
Rob Herring, Robert Foss, Jonathan Corbet, Andy Yan,
Jernej Skrabec, Tvrtko Ursulin, linux-rockchip, Harry Wentland,
intel-gfx, Rodrigo Siqueira, Jonas Karlman, Leo Li, Sascha Hauer,
Maarten Lankhorst, Maxime Ripard, Jani Nikula, Rodrigo Vivi,
intel-xe, linux-arm-kernel, Dmitry Baryshkov, Neil Armstrong,
amd-gfx, Dmitry Baryshkov, Werner Sembach, Sandy Huang,
Thomas Zimmermann, Alex Deucher, Andy Yan, Christian König
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
On Mon, Apr 13, 2026 at 12:07:14PM +0200, Nicolas Frattaroli wrote:
> Hello,
>
> this is a follow-up to
> https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
> which in of itself is a follow-up to
> https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/ where
> a new DRM connector property has been added allowing users to
> force a particular color format.
Looks like we're still missing the wayland folks in the cc. But I was
told that everyone should just cc wayland-devel@lists.freedesktop.org
on all relevant uapi stuff. So please add that on the next version.
The i915 rework is now merged so you should even get a buildable
series next time.
I'll go read the i915 parts now...
--
Ville Syrjälä
Intel
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v7 0/4] PCI: Add support for resetting the Root Ports in a platform specific way
From: Manivannan Sadhasivam @ 2026-04-13 16:35 UTC (permalink / raw)
To: Brian Norris, Hongxing Zhu
Cc: Hongxing Zhu, manivannan.sadhasivam@oss.qualcomm.com,
Bjorn Helgaas, Mahesh J Salgaonkar, Oliver O'Halloran,
Will Deacon, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Heiko Stuebner, Philipp Zabel,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-arm-msm@vger.kernel.org, linux-rockchip@lists.infradead.org,
Niklas Cassel, Wilfred Mallawa, Krishna Chaitanya Chundru,
Lukas Wunner, Wilson Ding, Miles Chen
In-Reply-To: <adcHylFjFjhHT-tP@google.com>
Hi Brian,
On Wed, Apr 08, 2026 at 06:58:34PM -0700, Brian Norris wrote:
> Hi Richard and Mani,
>
> For the record, I've been using a form of an earlier version of this
> patchset in my environment for some time now, and I've run across
> problems that *might* relate to what Richard is reporting, but I'm not
> quite sure at the moment. Details below.
>
> On Wed, Mar 25, 2026 at 07:06:49AM +0000, Hongxing Zhu wrote:
> > Hi Mani:
> > I've accidentally encountered a new issue based on the reset root port patch-set.
> > After performing a few hot-reset operations, the PCIe link enters a continuous up/down cycling pattern.
> >
> > I found that calling pci_reset_secondary_bus() first in pcibios_reset_secondary_bus() appears to resolve this issue.
> > Have you experienced a similar problem?
> >
> > "
> > ...
> > [ 141.897701] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> > [ 142.086341] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> > [ 142.092038] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000c00) link down detected
> > ...
> > "
> >
> > Platform: i.MX95 EVK board plus local Root Ports reset supports based on the #1 and #2 patches of v7 patch-set.
> > Notes of the logs:
> > - One Gen3 NVME device is connected.
> > - "./memtool 4c341058=0;./memtool 4c341058=1;" is used to toggle the LTSSM_EN bit to trigger the link down.
> > - Toggle BIT6 of Bridge Control Register to trigger hot reset by "./memtool 4c30003c=004001ff; ./memtool 4c30003c=000001ff;"
> > - The Root Port reset patches works correctly at first.
> > However, after several hot-reset triggers, the link enters a repeated down/up cycling state.
> >
> > Logs:
> > [ 3.553188] imx6q-pcie 4c300000.pcie: host bridge /soc/pcie@4c300000 ranges:
> > [ 3.560308] imx6q-pcie 4c300000.pcie: IO 0x006ff00000..0x006fffffff -> 0x0000000000
> > [ 3.568525] imx6q-pcie 4c300000.pcie: MEM 0x0910000000..0x091fffffff -> 0x0010000000
> > [ 3.577314] imx6q-pcie 4c300000.pcie: config reg[1] 0x60100000 == cpu 0x60100000
> > [ 3.796029] imx6q-pcie 4c300000.pcie: iATU: unroll T, 128 ob, 128 ib, align 4K, limit 1024G
> > [ 4.003746] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> > [ 4.009553] imx6q-pcie 4c300000.pcie: PCI host bridge to bus 0000:00
> > root@imx95evk:~#
> > root@imx95evk:~#
> > root@imx95evk:~# ./memtool 4c341058=0;./memtool 4c341058=1; Writing 32-bit value 0x0 to address 0x4C341058
> > Writing 32-bit v
> > [ 87.265348] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000d01) link down detected
> > alue 0x1 to adder
> > [ 87.273106] imx6q-pcie 4c300000.pcie: Stop root bus and handle link down
> > ss 0x4C341058
> > [ 87.281264] pcieport 0000:00:00.0: Recovering Root Port due to Link Down
> > [ 87.289245] pci 0000:01:00.0: AER: can't recover (no error_detected callback)
> > root@imx95evk:~# [ 87.514216] imx6q-pcie 4c300000.pcie: PCIe(LNK_STS:0x00000700) link up detected
> > [ 87.702968] imx6q-pcie 4c300000.pcie: PCIe Gen.3 x1 link up
> > [ 87.834983] pcieport 0000:00:00.0: Root Port has been reset
> > [ 87.840714] pcieport 0000:00:00.0: AER: device recovery failed
> > [ 87.846592] imx6q-pcie 4c300000.pcie: Rescan bus after link up is detected
> > [ 87.855947] pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
>
> I've seen this same line ("bridge configuration invalid") before, and I
> believe that's because the saved state (pci_save_state(); more about
> this below) is invalid -- it contains 0 values in places where they
> should be non-zero. So when those values are restored
> (pci_restore_state()), we get confused.
>
> I believe we've pinned down one reason this invalid state occurs -- it's
> because of an automatic (mis)feature in the DesignWare PCIe hardware.
> Specifically, it's because of what the controller does during a surprise
> link-down error.
>
> From the Designware docs:
>
> "[...] during normal operation, the link might fail and go down. After
> this link-down event, the controller requests the DWC_pcie_clkrst.v
> module to hot-reset the controller. There is no difference in the
> handling of a link-down reset or a hot reset; the controller asserts
> the link_req_rst_not output requesting the DWC_pcie_clkrst.v module to
> reset the controller."
>
> In some of the adjacent documentation (and confirmed in local testing),
> it suggests that this automatic reset will also reset various DBI (i.e.,
> PCIe config space) registers. It also seems as if there's not really a
> good way to completely stop this automatic reset -- the docs mention
> some SW methods prevent the reset, but they all seem racy or incomplete.
>
> Anyway, I think this implies that patch 1 is somewhat wrong [1]. It
> includes some code like this:
>
> pci_save_state(dev);
> ret = host->reset_root_port(host, dev);
> if (ret)
> pci_err(dev, "Failed to reset Root Port: %d\n", ret);
> else
> /* Now restore it on success */
> pci_restore_state(dev);
>
> That first line (pci_save_state()) is prone to saving invalid state,
> depending on whether the link-down event has finished flushing and
> resetting the controller yet or not. The resulting impact is a bit hard
> to judge, depending on what (mis)configuration you end up with.
>
Thanks a lot for your investigation. I think your observation makes sense and
could be the culprit in saving the corrupted state. Even on non-DWC controllers,
there is no guarantee that the Root Port config registers state will be
preserved after LDn (before Root Port reset).
> I also noticed commit a2f1e22390ac ("PCI/ERR: Ensure error
> recoverability at all times") was merged recently. With that change, I
> believe it is now safe to perform pci_restore_state() even without
> pci_save_state() here.
>
> So ... can we remove pci_save_state() from
> pcibios_reset_secondary_bus()? Might that help?
I think so. I will also test it locally and report back soon.
> It sounds like my above
> observations *may* match Richard's reports, but I'm not sure. And
> anyway, the documented hardware behavior is racy, so it's hard to
> propose a foolproof solution.
>
@Richard: Can you confirm if removing 'pci_save_state(dev);' from
pcibios_reset_secondary_bus() fixes your issue?
- Mani
--
மணிவண்ணன் சதாசிவம்
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v14 3/8] drm/bridge: analogix_dp: Add new API analogix_dp_finish_probe()
From: Luca Ceresoli @ 2026-04-13 16:07 UTC (permalink / raw)
To: Damon Ding, andrzej.hajda, neil.armstrong, rfoss,
maarten.lankhorst, mripard, tzimmermann, airlied, simona,
inki.dae, sw0312.kim, kyungmin.park, krzk, jingoohan1, hjc, heiko,
andy.yan
Cc: Laurent.pinchart, jonas, jernej.skrabec, alim.akhtar,
dmitry.baryshkov, nicolas.frattaroli, dianders, m.szyprowski,
linux-kernel, dri-devel, linux-arm-kernel, linux-samsung-soc,
linux-rockchip
In-Reply-To: <20260413132551.1049307-4-damon.ding@rock-chips.com>
Hello Damon,
On Mon Apr 13, 2026 at 3:25 PM CEST, Damon Ding wrote:
> Since the panel/bridge should logically be positioned behind the
> Analogix bridge in the display pipeline, it makes sense to handle
> the panel/bridge parsing on the Analogix side. Therefore, we add
> a new API analogix_dp_finish_probe(), which combines the panel/bridge
> parsing with component addition, to do it.
>
> In order to process component binding right after the probe completes,
> the &analogix_dp_plat_data.ops is newly added to pass &component_ops,
> for which the &dp_aux_ep_device_with_data.done_probing() of DP AUX bus
> only supports passing &drm_dp_aux.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Heiko Stuebner <heiko@sntech.de> # rk3588
>
> ---
>
> Changes in v4:
> - Rename the &analogix_dp_plat_data.bridge to
> &analogix_dp_plat_data.next_bridge.
> - Remame API analogix_dp_find_panel_or_bridge() to
> analogix_dp_finish_probe().
>
> Changes in v5:
> - Select DRM_DISPLAY_DP_AUX_BUS for DRM_ANALOGIX_DP.
>
> Changes in v9:
> - Add Tested-by tag.
>
> Changes in v10:
> - Fix to use dev_err_probe() in analogix_dp_finish_probe().
> - Expand the commit message.
>
> Changes in v13:
> - Modify '(on rk3588)' to '# rk3588' for Tested-by tag.
> ---
> drivers/gpu/drm/bridge/analogix/Kconfig | 1 +
> .../drm/bridge/analogix/analogix_dp_core.c | 46 +++++++++++++++++++
> include/drm/bridge/analogix_dp.h | 2 +
> 3 files changed, 49 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig b/drivers/gpu/drm/bridge/analogix/Kconfig
> index 03dc7ffe824a..8a6136cd675f 100644
> --- a/drivers/gpu/drm/bridge/analogix/Kconfig
> +++ b/drivers/gpu/drm/bridge/analogix/Kconfig
> @@ -29,6 +29,7 @@ config DRM_ANALOGIX_ANX78XX
> config DRM_ANALOGIX_DP
> tristate
> depends on DRM
> + select DRM_DISPLAY_DP_AUX_BUS
While applying, sparse noticed an issue here: DRM_DISPLAY_DP_AUX_BUS
depends on OF, so you need to propagate the 'depends on OF' to
DRM_ANALOGIX_DP and its reverse dependencies.
I fixed it while applying the patch.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ 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