@@ -211,7 +211,7 @@ rgmii_phy: ethernet-phy@1 {
&pcie2x1l1 {
linux,pci-domain = <1>;
pinctrl-names = "default";
- pinctrl-0 = <&pcie2_reset>;
+ pinctrl-0 = <&pcie2_reset>, <&pcie30x1m1_0_clkreqn>, <&pcie30x1m1_0_waken>;
reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
status = "okay";
};
@@ -223,7 +223,7 @@ &pcie30phy {
&pcie3x4 {
linux,pci-domain = <0>;
pinctrl-names = "default";
- pinctrl-0 = <&pcie3_reset>;
+ pinctrl-0 = <&pcie3_reset>, <&pcie30x4m1_clkreqn>, <&pcie30x4m1_waken>;
reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
vpcie3v3-supply = <&vcc3v3_pcie30>;
status = "okay";
The PCIe 3 PHY in the RK3588 requires a running external reference clock for both external bus transfers and some internal PIPE operations. Without this clock, the PCIe3 controller fails to initialize and ignores DBI transactions indefinitely, which stalls the Linux boot process. On most RK3588 boards, this is evidently not an issue. But on some "SoM" designs (Turing RK1, Mixtile Core 3588E, ArmSoM AIM7, to name a few), this clock is only provided when the CLKREQ# signal is asserted. The PCIe 3 PHY generates the CLKREQ# signal when it knows it needs the reference clock for proper operation. Unfortunately, the current DT for Turing RK1 does not mux out these low-speed signals, resulting in broken boots and potentially other issues. This patch, following the previous one that split up the PCIe pinctrls, resolves this problem for Turing RK1 by explicitly muxing all of the signals needed for PCIe 2 and 3 support. Cc: Jonathan Bennett <jbennett@incomsystems.biz> Fixes: 2806a69f3f ("arm64: dts: rockchip: Add Turing RK1 SoM support") Signed-off-by: Sam Edwards <CFSworks@gmail.com> --- arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)