From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F0F77C4167B for ; Wed, 6 Dec 2023 09:36:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=l6Xv+Eu3+PuYowToAvvcvATyuGxZIp29k1/hNeisPKM=; b=3CrsGmhN4nr3hD sHgn8GvmzfINsfprqU7D8QMDIoJbCL6pRRzOGo7W+5j2E3AxvBnlK/THyAx4WESjTcUfEJgXTWVJR SIOSelxpO4V4KE8GrxwGCXylnsOctzFfnyjhuXTgxb9TNQZAofMnF+a3UBQfHUPEL6GdBWboyvFBX il4w2mq1jNdL7DPmBAWoehTaoRcAvn5iOhDjaFpp4ukinu1LwCDvpC59tkVmu6hmf4hoRbctq2q5k MxpVQ9jJoqtnCnj6Vuaz1cUiOsNU1dIGDwiQg/kwIP+imjiIUhe2XgC2NVls70JfP0IIcUr4gLjXQ wanJeRcKoDlDeo4mlb7A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rAoJv-009Zg3-0H; Wed, 06 Dec 2023 09:35:55 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rAoJr-009Zf9-22; Wed, 06 Dec 2023 09:35:52 +0000 Received: from i53875b61.versanet.de ([83.135.91.97] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rAoJp-0008S0-Tl; Wed, 06 Dec 2023 10:35:49 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Rob Herring , Sam Edwards Cc: linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, Daniel =?utf-8?B?S3VraWXFgmE=?= , Sven Rademakers , Joshua Riek , Sam Edwards Subject: Re: [RESEND PATCH] arm64: dts: rockchip: Add PCIe pinctrls to Turing RK1 Date: Wed, 06 Dec 2023 10:35:48 +0100 Message-ID: <2724771.ElGaqSPkdT@diego> In-Reply-To: <20231205202900.4617-1-CFSworks@gmail.com> References: <20231205202900.4617-1-CFSworks@gmail.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231206_013551_669831_90054821 X-CRM114-Status: GOOD ( 22.54 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > --- > .../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