From: "Heiko Stübner" <heiko@sntech.de>
To: Rob Herring <robh+dt@kernel.org>, Sam Edwards <cfsworks@gmail.com>
Cc: linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Daniel Kukieła" <daniel@kukiela.pl>,
"Sven Rademakers" <sven.rademakers@gmail.com>,
"Joshua Riek" <jjriek@verizon.net>,
"Sam Edwards" <CFSworks@gmail.com>
Subject: Re: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
Date: Wed, 06 Dec 2023 10:35:48 +0100 [thread overview]
Message-ID: <2724771.ElGaqSPkdT@diego> (raw)
In-Reply-To: <20231205202900.4617-1-CFSworks@gmail.com>
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>;
> };
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Rob Herring <robh+dt@kernel.org>, Sam Edwards <cfsworks@gmail.com>
Cc: linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Daniel Kukieła" <daniel@kukiela.pl>,
"Sven Rademakers" <sven.rademakers@gmail.com>,
"Joshua Riek" <jjriek@verizon.net>,
"Sam Edwards" <CFSworks@gmail.com>
Subject: Re: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
Date: Wed, 06 Dec 2023 10:35:48 +0100 [thread overview]
Message-ID: <2724771.ElGaqSPkdT@diego> (raw)
In-Reply-To: <20231205202900.4617-1-CFSworks@gmail.com>
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>;
> };
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Rob Herring <robh+dt@kernel.org>, Sam Edwards <cfsworks@gmail.com>
Cc: linux-rockchip@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Daniel Kukieła" <daniel@kukiela.pl>,
"Sven Rademakers" <sven.rademakers@gmail.com>,
"Joshua Riek" <jjriek@verizon.net>,
"Sam Edwards" <CFSworks@gmail.com>
Subject: Re: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1
Date: Wed, 06 Dec 2023 10:35:48 +0100 [thread overview]
Message-ID: <2724771.ElGaqSPkdT@diego> (raw)
In-Reply-To: <20231205202900.4617-1-CFSworks@gmail.com>
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>;
> };
>
next prev parent reply other threads:[~2023-12-06 9:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 20:28 [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1 Sam Edwards
2023-12-05 20:28 ` Sam Edwards
2023-12-05 20:28 ` Sam Edwards
2023-12-06 9:35 ` Heiko Stübner [this message]
2023-12-06 9:35 ` Heiko Stübner
2023-12-06 9:35 ` Heiko Stübner
2023-12-06 19:42 ` Sam Edwards
2023-12-06 19:42 ` Sam Edwards
2023-12-06 19:42 ` Sam Edwards
2023-12-06 14:55 ` Heiko Stübner
2023-12-06 14:55 ` Heiko Stübner
2023-12-06 14:55 ` Heiko Stübner
2023-12-06 18:26 ` Sam Edwards
2023-12-06 18:26 ` Sam Edwards
2023-12-06 18:26 ` Sam Edwards
2023-12-07 11:41 ` Heiko Stübner
2023-12-07 11:41 ` Heiko Stübner
2023-12-07 11:41 ` Heiko Stübner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2724771.ElGaqSPkdT@diego \
--to=heiko@sntech.de \
--cc=cfsworks@gmail.com \
--cc=daniel@kukiela.pl \
--cc=devicetree@vger.kernel.org \
--cc=jjriek@verizon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=robh+dt@kernel.org \
--cc=sven.rademakers@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.