Message ID | 20231205202900.4617-1-CFSworks@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp3689576vqy; Tue, 5 Dec 2023 12:29:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IF8PJ4NogDkFF4Jw73oPBZOF7we2+XqFu/2FHDtHqVt+1E3g3QvbZpF/3zvkhjmxCeExILw X-Received: by 2002:a17:90a:4007:b0:286:c37f:d1b1 with SMTP id u7-20020a17090a400700b00286c37fd1b1mr1720498pjc.41.1701808159124; Tue, 05 Dec 2023 12:29:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701808159; cv=none; d=google.com; s=arc-20160816; b=Qz+ybHcGdVuhjLImOSMODWNBSmQhOf7GmthfyanXMyZXQ3OIY+cuWno6VmVx6+X4P3 1ijMWK3eVpo4SCHKcC1K9J8LnO5tm9Ex1VP1khb3+alghfxbR1xptbzMUThdHiRm4qmz OXhXztJaeDXCesEO3A61LkQLkrV9uPZTMtqOA6fi1984rcug/LGgKX2deaUDNKUJWAGI Usl4RCFnk18+YDsxb55vr96aDt2e9qjYz4EIBbdpQmbBtvLUTHW6SF/msFkbUF1TqmfV pClYXjsWwmiCzcB/DMDCwIaZYv/H1sINnnm74lLJUV/J7prfdwcfWj1ioHUGp9p+IPPU LQLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=7MBM4ZA5oNd9/yj6ChXURBgLtdL7sP8s8g23+U8L60Y=; fh=WsPG8bmoeVdJ+mTvc3JfGT690EmTY9Rsmm35P0eF47I=; b=mW5N2emeer6FYd2CqmpvTTCVBu2VsW4Y5AZP9HyPfG0FUG7ZaczcG/rhzCxn+KVq+H L5HwuAo1ixWtpDusadQ5fg47Mk1LarOmI1QRqlxY6HFUOGNNmC2ftKX5+R2NIriiFs9w 4f/+vC8MnAVKWVp6HPZtQqwhIBThBjOe2H8dUf2QDNL7+hy3jj3Q+6XhNNtGNv/25jmP fm0a6bAslxsfqfyh2N7UjIN2lxot+WAZSO7U6KMANZAJDhNnzoBaioHEnMFvfUyd1pOC N+4Be9r8VP+oMMTDLHj2hS8CPT7R0nIY/L140G0UGxzZKuAVGoRFXW0+Z/vDyyYjCf/z /apQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fSKty53H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id 19-20020a170902c11300b001bdcd2e1706si8747854pli.196.2023.12.05.12.29.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 12:29:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=fSKty53H; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 06D1880309BB; Tue, 5 Dec 2023 12:29:18 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232305AbjLEU3I (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Tue, 5 Dec 2023 15:29:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229569AbjLEU3H (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 5 Dec 2023 15:29:07 -0500 Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ADF6B181; Tue, 5 Dec 2023 12:29:13 -0800 (PST) Received: by mail-il1-x130.google.com with SMTP id e9e14a558f8ab-35d55c8ab0cso18679355ab.2; Tue, 05 Dec 2023 12:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701808153; x=1702412953; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=7MBM4ZA5oNd9/yj6ChXURBgLtdL7sP8s8g23+U8L60Y=; b=fSKty53HK1LnDPHwi91klboedE4IsFeoF+lq+GIpAse/K6v0kax0ViXIuM+ysKGZTm oDNxzc2aLK5vQi2jPQXLl9XOsIvR9Zd1ba/1BvyJeDRCuP+52NkP9nUbP/f8aRuX0Cj/ 6OHZ+hQTmyddYaWdQ5zh3e0mBi18LjcXoocu4O+EatfR+EGxNv3EV6QHKXuFLemjIPXo /i9iL0cbY/2nbPza6M0ya20Vi8BN2NFbab8GU2dPT39+bjHoF88E6X2syg40GRoiT9eS pHj89wEplgpaCZQalo5uCV5ePsLXkabEyKOnixvA2uuR9fjL/tOriZSXdvaQPCpc3p8K JF9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701808153; x=1702412953; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7MBM4ZA5oNd9/yj6ChXURBgLtdL7sP8s8g23+U8L60Y=; b=rC5Qd1UI8ez9nGH3p6ce2G0+q5bfdmYw2DEkNBMoXMq7R84D5oiPZMOepoNZ1eiV+h Yn6FVDC/HBtP4Dma4qtMy6PISus5ufhHgyRE3KDAC/yXzwfN6j1F0LxSvHUXlCqLqLiQ XGjWHdTIOJ0Vt1lvQ4Kp+j2GMxF+Z1gxTyduanrR7K79uSjWxkc7Il6eNzjTLHnQab3r o+JsLX+nZSRlyQ1Gsnbkfuy7Xevzwwa80UdMJLUIWe8Yg9JOzw/totcDLWC1BHLReMZ/ 2rewCTnflhPJd6O/Wecv24Wsf50DdAjhIVDtRBjMevI6Nhu3UIJnuc4AKHcFdUdPAu2a Tn0g== X-Gm-Message-State: AOJu0YyIIPYZbt4SLCSYsvXVwX1MuxZ8N822zRkVh1gDZjqUTB4Xtc5M PppJ9MJAlrhVNsf2wViIuiA= X-Received: by 2002:a05:6e02:1d12:b0:35c:f2f6:7b1b with SMTP id i18-20020a056e021d1200b0035cf2f67b1bmr7324672ila.26.1701808152987; Tue, 05 Dec 2023 12:29:12 -0800 (PST) Received: from celestia.nettie.lan ([2001:470:42c4:101:3fb7:1e39:b284:286f]) by smtp.gmail.com with ESMTPSA id cw2-20020a05663849c200b004302370a169sm3296320jab.157.2023.12.05.12.29.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 12:29:12 -0800 (PST) From: Sam Edwards <cfsworks@gmail.com> X-Google-Original-From: Sam Edwards <CFSworks@gmail.com> To: Heiko Stuebner <heiko@sntech.de>, Rob Herring <robh+dt@kernel.org> Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, =?utf-8?q?Daniel_?= =?utf-8?q?Kukie=C5=82a?= <daniel@kukiela.pl>, Sven Rademakers <sven.rademakers@gmail.com>, Joshua Riek <jjriek@verizon.net>, Sam Edwards <CFSworks@gmail.com> Subject: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1 Date: Tue, 5 Dec 2023 12:28:59 -0800 Message-ID: <20231205202900.4617-1-CFSworks@gmail.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 05 Dec 2023 12:29:18 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784475191849655414 X-GMAIL-MSGID: 1784475191849655414 |
Series |
[RESEND] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
|
|
Commit Message
Sam Edwards
Dec. 5, 2023, 8:28 p.m. UTC
The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when
no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it
will sometimes (varying between specific RK3588 chips, not over time) shut
off the DBI block, and reads to this range will instead stall
indefinitely.
When this happens, it will prevent Linux from booting altogether. The
PCIe driver will stall the CPU core once it attempts to read the version
information from the DBI range.
Fix this boot hang by adding the correct pinctrl configuration to the
PCIe 3.0 device node, which is the proper thing to do anyway. While
we're at it, also add the necessary configuration to the PCIe 2.0 node,
which may or may not fix the equivalent problem over there -- but is the
proper thing to do anyway. :)
Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
---
.../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------
1 file changed, 2 insertions(+), 12 deletions(-)
Comments
Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards: > The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when > no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it > will sometimes (varying between specific RK3588 chips, not over time) shut > off the DBI block, and reads to this range will instead stall > indefinitely. > > When this happens, it will prevent Linux from booting altogether. The > PCIe driver will stall the CPU core once it attempts to read the version > information from the DBI range. > > Fix this boot hang by adding the correct pinctrl configuration to the > PCIe 3.0 device node, which is the proper thing to do anyway. While > we're at it, also add the necessary configuration to the PCIe 2.0 node, > which may or may not fix the equivalent problem over there -- but is the > proper thing to do anyway. :) > > Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support") > Signed-off-by: Sam Edwards <CFSworks@gmail.com> > --- > .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > index 9570b34aca2e..129f14dbd42f 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy@1 { > &pcie2x1l1 { > linux,pci-domain = <1>; > pinctrl-names = "default"; > - pinctrl-0 = <&pcie2_reset>; > + pinctrl-0 = <&pcie30x1m1_pins>; This really throws me for a loop here - in the original submission too already. Because somehow those pins are named pcie30x1... for the pcie2 controller ;-) . > reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>; > status = "okay"; > }; > @@ -226,7 +226,7 @@ &pcie30phy { > &pcie3x4 { > linux,pci-domain = <0>; > pinctrl-names = "default"; > - pinctrl-0 = <&pcie3_reset>; > + pinctrl-0 = <&pcie30x4m1_pins>; > reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; > vpcie3v3-supply = <&vcc3v3_pcie30>; > status = "okay"; > @@ -245,17 +245,7 @@ hym8563_int: hym8563-int { > }; > }; > > - pcie2 { > - pcie2_reset: pcie2-reset { > - rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; > - }; > - }; > - > pcie3 { > - pcie3_reset: pcie3-reset { > - rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; > - }; > - > vcc3v3_pcie30_en: pcie3-reg { > rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>; > }; >
Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards: > The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when > no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it > will sometimes (varying between specific RK3588 chips, not over time) shut > off the DBI block, and reads to this range will instead stall > indefinitely. > > When this happens, it will prevent Linux from booting altogether. The > PCIe driver will stall the CPU core once it attempts to read the version > information from the DBI range. > > Fix this boot hang by adding the correct pinctrl configuration to the > PCIe 3.0 device node, which is the proper thing to do anyway. While > we're at it, also add the necessary configuration to the PCIe 2.0 node, > which may or may not fix the equivalent problem over there -- but is the > proper thing to do anyway. :) > > Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support") > Signed-off-by: Sam Edwards <CFSworks@gmail.com> > --- > .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > index 9570b34aca2e..129f14dbd42f 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy@1 { > &pcie2x1l1 { > linux,pci-domain = <1>; > pinctrl-names = "default"; > - pinctrl-0 = <&pcie2_reset>; > + pinctrl-0 = <&pcie30x1m1_pins>; > reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>; > status = "okay"; > }; > @@ -226,7 +226,7 @@ &pcie30phy { > &pcie3x4 { > linux,pci-domain = <0>; > pinctrl-names = "default"; > - pinctrl-0 = <&pcie3_reset>; > + pinctrl-0 = <&pcie30x4m1_pins>; also, why are you throwing out the pinctrl for the reset pin. That seems not related to the regular pins and you could instead just do + pinctrl-0 = <&pcie30x4m1_pins>, <&pcie3_reset>; Thanks Heiko > reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; > vpcie3v3-supply = <&vcc3v3_pcie30>; > status = "okay"; > @@ -245,17 +245,7 @@ hym8563_int: hym8563-int { > }; > }; > > - pcie2 { > - pcie2_reset: pcie2-reset { > - rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; > - }; > - }; > - > pcie3 { > - pcie3_reset: pcie3-reset { > - rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; > - }; > - > vcc3v3_pcie30_en: pcie3-reg { > rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>; > }; >
On 12/6/23 07:55, Heiko Stübner wrote: > Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards: >> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when >> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it >> will sometimes (varying between specific RK3588 chips, not over time) shut >> off the DBI block, and reads to this range will instead stall >> indefinitely. >> >> When this happens, it will prevent Linux from booting altogether. The >> PCIe driver will stall the CPU core once it attempts to read the version >> information from the DBI range. >> >> Fix this boot hang by adding the correct pinctrl configuration to the >> PCIe 3.0 device node, which is the proper thing to do anyway. While >> we're at it, also add the necessary configuration to the PCIe 2.0 node, >> which may or may not fix the equivalent problem over there -- but is the >> proper thing to do anyway. :) >> >> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support") >> Signed-off-by: Sam Edwards <CFSworks@gmail.com> >> --- >> .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------ >> 1 file changed, 2 insertions(+), 12 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi >> index 9570b34aca2e..129f14dbd42f 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi >> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi >> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy@1 { >> &pcie2x1l1 { >> linux,pci-domain = <1>; >> pinctrl-names = "default"; >> - pinctrl-0 = <&pcie2_reset>; >> + pinctrl-0 = <&pcie30x1m1_pins>; >> reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>; >> status = "okay"; >> }; >> @@ -226,7 +226,7 @@ &pcie30phy { >> &pcie3x4 { >> linux,pci-domain = <0>; >> pinctrl-names = "default"; >> - pinctrl-0 = <&pcie3_reset>; >> + pinctrl-0 = <&pcie30x4m1_pins>; Hi Heiko, > > also, why are you throwing out the pinctrl for the reset pin. > That seems not related to the regular pins and you could instead just do > > + pinctrl-0 = <&pcie30x4m1_pins>, <&pcie3_reset>; The pcie30x4m1_pins def does include pinmuxing `4 RK_PB6` to the DW controller already. The v2 patch should probably instead remove the reset-gpios property, since an out-of-band GPIO reset is not needed when the controller can do it. I'm still looking into the story with the PCIe 2.0 pins, since 2.0x1's PERST# is definitely 4A2. I'll ask around and try to find out where the corresponding CLKREQ# is going. > > Thanks > Heiko Likewise, Sam > >> reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; >> vpcie3v3-supply = <&vcc3v3_pcie30>; >> status = "okay"; >> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int { >> }; >> }; >> >> - pcie2 { >> - pcie2_reset: pcie2-reset { >> - rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; >> - }; >> - }; >> - >> pcie3 { >> - pcie3_reset: pcie3-reset { >> - rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; >> - }; >> - >> vcc3v3_pcie30_en: pcie3-reg { >> rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>; >> }; >> > > > >
On 12/6/23 02:35, Heiko Stübner wrote: > Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards: >> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when >> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it >> will sometimes (varying between specific RK3588 chips, not over time) shut >> off the DBI block, and reads to this range will instead stall >> indefinitely. >> >> When this happens, it will prevent Linux from booting altogether. The >> PCIe driver will stall the CPU core once it attempts to read the version >> information from the DBI range. >> >> Fix this boot hang by adding the correct pinctrl configuration to the >> PCIe 3.0 device node, which is the proper thing to do anyway. While >> we're at it, also add the necessary configuration to the PCIe 2.0 node, >> which may or may not fix the equivalent problem over there -- but is the >> proper thing to do anyway. :) >> >> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support") >> Signed-off-by: Sam Edwards <CFSworks@gmail.com> >> --- >> .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------ >> 1 file changed, 2 insertions(+), 12 deletions(-) >> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi >> index 9570b34aca2e..129f14dbd42f 100644 >> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi >> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi >> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy@1 { >> &pcie2x1l1 { >> linux,pci-domain = <1>; >> pinctrl-names = "default"; >> - pinctrl-0 = <&pcie2_reset>; >> + pinctrl-0 = <&pcie30x1m1_pins>; > > This really throws me for a loop here - in the original submission too > already. Because somehow those pins are named pcie30x1... for the > pcie2 controller ;-) . Hi Heiko, I just double-checked. The RK1's PCIe 2.0 x1 has the following pin assignments: PCIE1_CLKREQ_N -> AK30 (4 RK_PA0) PCIE_WAKE (shared with PCIE0 wake signal) -> AL30 (4 RK_PA1) PCIE1_RST_N -> AM29 (4 RK_PA2) ...so the patch's pinmux setting is indeed correct. (But we may still want to drop the `reset-gpios` property; see my reply to your other email.) The confusion seems to be that the PCIe 2.0 path used here is: PCIe30X1_1(1L1) -> Combo PIPE PHY2 (So, a PCIe3 controller, but a PCIe2 PHY.) The WAKE/CLKREQ/PERST signals are very low-speed, and thus bypass the PHY: the RK3588's IOMUX subsystem connects them directly to the PCIe3 controller. So they are "pcie30" pins in that sense. The (potential) misnomer here is `pcie2x1l1`. The controller at 0xFE180000 is unequivocally a PCIe 3.0 core, and it *could* be muxed to a (bifurcated) PCIe 3.0 x2 PHY for true PCIe 3.0 operation. But since it appears that mainline doesn't support this bifurcation (yet), this PCIe 3.0 core can only be used for PCIe 2.0 through combphy2, which is probably why the DT node is labeled `pcie2x1l1` (for now). In any case, thank you for calling attention to this! I enjoyed researching the "why" and hope that it clarifies things for you as well. :) Cheers, Sam > > >> reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>; >> status = "okay"; >> }; >> @@ -226,7 +226,7 @@ &pcie30phy { >> &pcie3x4 { >> linux,pci-domain = <0>; >> pinctrl-names = "default"; >> - pinctrl-0 = <&pcie3_reset>; >> + pinctrl-0 = <&pcie30x4m1_pins>; >> reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; >> vpcie3v3-supply = <&vcc3v3_pcie30>; >> status = "okay"; >> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int { >> }; >> }; >> >> - pcie2 { >> - pcie2_reset: pcie2-reset { >> - rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; >> - }; >> - }; >> - >> pcie3 { >> - pcie3_reset: pcie3-reset { >> - rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; >> - }; >> - >> vcc3v3_pcie30_en: pcie3-reg { >> rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>; >> }; >> > > > >
Am Mittwoch, 6. Dezember 2023, 19:26:40 CET schrieb Sam Edwards: > > On 12/6/23 07:55, Heiko Stübner wrote: > > Am Dienstag, 5. Dezember 2023, 21:28:59 CET schrieb Sam Edwards: > >> The RK3588 PCIe 3.0 controller seems to have unpredictable behavior when > >> no CLKREQ/PERST/WAKE pins are configured in the pinmux. In particular, it > >> will sometimes (varying between specific RK3588 chips, not over time) shut > >> off the DBI block, and reads to this range will instead stall > >> indefinitely. > >> > >> When this happens, it will prevent Linux from booting altogether. The > >> PCIe driver will stall the CPU core once it attempts to read the version > >> information from the DBI range. > >> > >> Fix this boot hang by adding the correct pinctrl configuration to the > >> PCIe 3.0 device node, which is the proper thing to do anyway. While > >> we're at it, also add the necessary configuration to the PCIe 2.0 node, > >> which may or may not fix the equivalent problem over there -- but is the > >> proper thing to do anyway. :) > >> > >> Fixes: 2806a69f3fef6 ("arm64: dts: rockchip: Add Turing RK1 SoM support") > >> Signed-off-by: Sam Edwards <CFSworks@gmail.com> > >> --- > >> .../arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 14 ++------------ > >> 1 file changed, 2 insertions(+), 12 deletions(-) > >> > >> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > >> index 9570b34aca2e..129f14dbd42f 100644 > >> --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > >> +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi > >> @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy@1 { > >> &pcie2x1l1 { > >> linux,pci-domain = <1>; > >> pinctrl-names = "default"; > >> - pinctrl-0 = <&pcie2_reset>; > >> + pinctrl-0 = <&pcie30x1m1_pins>; > >> reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>; > >> status = "okay"; > >> }; > >> @@ -226,7 +226,7 @@ &pcie30phy { > >> &pcie3x4 { > >> linux,pci-domain = <0>; > >> pinctrl-names = "default"; > >> - pinctrl-0 = <&pcie3_reset>; > >> + pinctrl-0 = <&pcie30x4m1_pins>; > > Hi Heiko, > > > > > also, why are you throwing out the pinctrl for the reset pin. > > That seems not related to the regular pins and you could instead just do > > > > + pinctrl-0 = <&pcie30x4m1_pins>, <&pcie3_reset>; > > The pcie30x4m1_pins def does include pinmuxing `4 RK_PB6` to the DW > controller already. The v2 patch should probably instead remove the > reset-gpios property, since an out-of-band GPIO reset is not needed when > the controller can do it. yep, also because of the reset-gpios the pinctrl/gpio driver will mux the pin to gpio function even though the pinctrl would've set if the pcie- function before that. So I'm really in favor of not mixing the two concepts :-) When setting the pins, the reset-gpio should be gone and vice-versa. > I'm still looking into the story with the PCIe 2.0 pins, since 2.0x1's > PERST# is definitely 4A2. I'll ask around and try to find out where the > corresponding CLKREQ# is going. Yeah, I tried reading up in the TRM but it was really hard following which pin-group actually goes to which controller and the naming definitly does not help :-) . Heiko > >> reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; > >> vpcie3v3-supply = <&vcc3v3_pcie30>; > >> status = "okay"; > >> @@ -245,17 +245,7 @@ hym8563_int: hym8563-int { > >> }; > >> }; > >> > >> - pcie2 { > >> - pcie2_reset: pcie2-reset { > >> - rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; > >> - }; > >> - }; > >> - > >> pcie3 { > >> - pcie3_reset: pcie3-reset { > >> - rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; > >> - }; > >> - > >> vcc3v3_pcie30_en: pcie3-reg { > >> rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>; > >> }; > >> > > > > > > > > >
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi index 9570b34aca2e..129f14dbd42f 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi @@ -214,7 +214,7 @@ rgmii_phy: ethernet-phy@1 { &pcie2x1l1 { linux,pci-domain = <1>; pinctrl-names = "default"; - pinctrl-0 = <&pcie2_reset>; + pinctrl-0 = <&pcie30x1m1_pins>; reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>; status = "okay"; }; @@ -226,7 +226,7 @@ &pcie30phy { &pcie3x4 { linux,pci-domain = <0>; pinctrl-names = "default"; - pinctrl-0 = <&pcie3_reset>; + pinctrl-0 = <&pcie30x4m1_pins>; reset-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>; vpcie3v3-supply = <&vcc3v3_pcie30>; status = "okay"; @@ -245,17 +245,7 @@ hym8563_int: hym8563-int { }; }; - pcie2 { - pcie2_reset: pcie2-reset { - rockchip,pins = <4 RK_PA2 RK_FUNC_GPIO &pcfg_pull_none>; - }; - }; - pcie3 { - pcie3_reset: pcie3-reset { - rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>; - }; - vcc3v3_pcie30_en: pcie3-reg { rockchip,pins = <2 RK_PC5 RK_FUNC_GPIO &pcfg_pull_none>; };