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 DE9DFC433F5 for ; Wed, 5 Oct 2022 09:00:06 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vwZGRV/wvrj/wKdtuNyiOivg6rWWkMYh6ajGui1mMOw=; b=sozrhy0DexDDh1 JODwk+ws9291HOWUBpOqUOFq05jORjpyCY8wnk8Q8xUL63a4H+Hjp3Nb4+kjwc8ZVc2KKeWhseRyD K8NsLTSW24p2NsTH6J+UojbWcYHKphMVRttinGYTm/cpf/2jTtZG/kWbpWr8EMRsrw6ranQ40mFXj xW/PzUKdttLMv36kkhBDuOXlGI7K4S0doFOknBIS4zNAl11v686v260aEarQgCjYrlcPLvEdAqRp4 QErTSz7TE5JBHPyo5tfZtMH5iTXgLMp0KJWqmDRMQcQ9U2bbhptFRzHwkcjqMRw5/Ga8S6ydcUODM cbPa6dyj+hrJynIqcCjg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1og0F5-00DEA1-Ht; Wed, 05 Oct 2022 08:59:03 +0000 Received: from vps.xff.cz ([195.181.215.36]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1og0F1-00DE9I-TZ; Wed, 05 Oct 2022 08:59:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xff.cz; s=mail; t=1664960338; bh=lEwY/zjdybhUANOaEO/4dQ3U3RYpKuYPtegSEH6M8KM=; h=Date:From:To:Cc:Subject:X-My-GPG-KeyId:References:From; b=pQ6HYkXtdvvb8qsKJ4r6ENWZLKMAfB4GcE4XFdPwNkiCWvjpZj9g6ghJr+eeedXQ9 hJ5W6OgUVhM9SO3E8O/fNHAadFYWX1H3T54oN7BfNPB+GD0HGvFOiyajhAk0hj8Pd9 /P3zUtN80mmvpU/EANmT5Zvs4uMPKiHoN1OScb1w= Date: Wed, 5 Oct 2022 10:58:57 +0200 From: =?utf-8?Q?Ond=C5=99ej?= Jirman To: Peter Geis Cc: linux-rockchip@lists.infradead.org, Rob Herring , Krzysztof Kozlowski , Heiko Stuebner , Michael Riesch , Nicolas Frattaroli , Sascha Hauer , Frank Wunderlich , Ezequiel Garcia , Yifeng Zhao , Johan Jonker , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "moderated list:ARM/Rockchip SoC support" , open list Subject: Re: [PATCH] arm64: dts: rockchip: rk356x: Fix PCIe register map and ranges Message-ID: <20221005085857.psmoj7ktohsvvxic@core> Mail-Followup-To: =?utf-8?Q?Ond=C5=99ej?= Jirman , Peter Geis , linux-rockchip@lists.infradead.org, Rob Herring , Krzysztof Kozlowski , Heiko Stuebner , Michael Riesch , Nicolas Frattaroli , Sascha Hauer , Frank Wunderlich , Ezequiel Garcia , Yifeng Zhao , Johan Jonker , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , "moderated list:ARM/Rockchip SoC support" , open list X-My-GPG-KeyId: EBFBDDE11FB918D44D1F56C1F9F0A873BE9777ED References: <20221004144304.536023-1-megi@xff.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221005_015900_131482_3C5C4593 X-CRM114-Status: GOOD ( 30.60 ) 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 Hello Peter, On Tue, Oct 04, 2022 at 03:52:39PM -0400, Peter Geis wrote: > On Tue, Oct 4, 2022 at 10:43 AM Ondrej Jirman wrote: > > Good Afternoon, > > > > > > I have two Realtek PCIe wifi cards connected over the 4 port > > PCIe bridge to Quartz64-A. The cards fail to work, when nvme > > SSD is connected at the same time to the bridge. Without nvme > > connected, cards work fine. The issue seems to be related > > to mixed use of devices which make use of I/O ranges and memory > > ranges. > > > > This mapping is designed to be more straightforward, inspired by > > dt-bindings docs for sample pcie3x2 node: > > > > reg = <0x3 0xc0800000 0x0 0x390000>, > > <0x0 0xfe280000 0x0 0x10000>, > > <0x3 0x80000000 0x0 0x100000>; > > ranges = <0x81000000 0x0 0x80800000 0x3 0x80800000 0x0 0x100000>, > > <0x83000000 0x0 0x80900000 0x3 0x80900000 0x0 0x3f700000>; > > > > I noticed that this is crafted so that there doesn't need to be > > any translation other than dropping the high dword bits, and I > > modified the ranges for pcie2x1 to follow the same principle. > > > > This change to the regs/ranges makes the issue go away and both > > nvme and wifi cards work when connected at the same time to the > > bridge. > > > > Signed-off-by: Ondrej Jirman > > --- > > arch/arm64/boot/dts/rockchip/rk356x.dtsi | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > > index 319981c3e9f7..e88e8c4fe25b 100644 > > --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi > > +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi > > @@ -855,7 +855,8 @@ pcie2x1: pcie@fe260000 { > > compatible = "rockchip,rk3568-pcie"; > > reg = <0x3 0xc0000000 0x0 0x00400000>, > > <0x0 0xfe260000 0x0 0x00010000>, > > - <0x3 0x3f000000 0x0 0x01000000>; > > + <0x3 0x00000000 0x0 0x01000000>; > > + > > reg-names = "dbi", "apb", "config"; > > interrupts = , > > , > > @@ -884,8 +885,8 @@ pcie2x1: pcie@fe260000 { > > phys = <&combphy2 PHY_TYPE_PCIE>; > > phy-names = "pcie-phy"; > > power-domains = <&power RK3568_PD_PIPE>; > > - ranges = <0x01000000 0x0 0x3ef00000 0x3 0x3ef00000 0x0 0x00100000 > > - 0x02000000 0x0 0x00000000 0x3 0x00000000 0x0 0x3ef00000>; > > + ranges = <0x01000000 0x0 0x01000000 0x3 0x01000000 0x0 0x00100000 > > + 0x02000000 0x0 0x02000000 0x3 0x02000000 0x0 0x3e000000>; > > Have you verified these ranges do not regress the NVMe drive when it > is connected directly to the controller? The reason we went with the > configuration space we did was because the original space from > downstream caused errors on NVMe drives when reading large amounts > (>1GB) of data at a time. I did. Anyway... looking at the ranges more carefully, I came up with a scheme that uses whole of 0x300000000 range for MEM and the smaller 32M range at 0xf4000000 for I/O and config, and tested it again to work for both: - nvme without a switch (directly connected) - nvme+wifi cards with a switch See v2 for more details. That ranges setup is closer to what BSP does. Kind regards, o. > Very Respectfully, > Peter Geis > > > resets = <&cru SRST_PCIE20_POWERUP>; > > reset-names = "pipe"; > > #address-cells = <3>; > > -- > > 2.37.3 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel