linux-rockchip.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Powers-Holmes <aholmes@omnom.net>
To: linux-rockchip@lists.infradead.org
Cc: "Ondřej Jirman" <megi@xff.cz>, "Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Frank Wunderlich" <frank-w@public-files.de>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	"Yifeng Zhao" <yifeng.zhao@rock-chips.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Nicolas Frattaroli" <frattaroli.nicolas@gmail.com>,
	"Chris Morgan" <macromorgan@hotmail.com>,
	"Ezequiel Garcia" <ezequiel@vanguardiasur.com.ar>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Mark Kettenis" <mark.kettenis@xs4all.nl>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: [PATCH 0/1] arm64: dts: rockchip: rk356x: Fix PCIe register and range mappings
Date: Sat, 12 Nov 2022 22:41:25 +1100	[thread overview]
Message-ID: <20221112114125.1637543-1-aholmes@omnom.net> (raw)

The Rockchip RK356x SoCs currently have incorrect, or at least sub-optimal,`reg`
and `ranges` values in their DTS files' PCIe nodes. Ondřej Jirman sent a patch
in [1] to resolve this, but it was not merged due to some issues discovered
during testing (it fixed his issues with devices behind a switch, but broke
directly connected NVMe drives, amongst others - see [2]).

This patch is a reworked of that patch, using the same mappings the Rockchip BSP
kernel uses. Peter sent these up during the discussion in [3] and they've been
tested on his boards as well as Ondřej's, mine, and those of a few others.

Ondřej also sent a patch in [4] with these fixed ranges, but without the fix
for RK3568 as he was not able to test on that SoC. I've included the fixes for
both SoCs as he's happy with that and the patch has not yet been merged.

I have tested these ranges against devices which only map 32-bit ranges, devices
which only map 64-bit, and devices which require both. An Intel i350-T4 NIC does
not enumerate at all with the existing or previous patch's addresses, but works
quite happily with these, as do NVMe drives and every other device I've been
able to test.

MSI/MSI-X has also been tested as working, but does not currently work upstream
due to a workaround needed in the GIC driver which Rockchip are still yet to
issue an erratum for.

Thanks,
Andrew

[1] https://lore.kernel.org/linux-rockchip/20221005085439.740992-1-megi@xff.cz/
[2] https://lore.kernel.org/linux-rockchip/CAMdYzYq3S2rR3Kb61irpV9xHYijNiJY0mkVnJwPrpXzxg_Zh9g@mail.gmail.com/
[3] https://lore.kernel.org/linux-rockchip/CAMdYzYp6ShLqKxdiAjaRFiRF5i+wzfKiQvwPMzyQLAutWZbApg@mail.gmail.com/
[4] https://lore.kernel.org/all/20221107130157.1425882-1-megi@xff.cz/

Andrew Powers-Holmes (1):
  arm64: dts: rockchip: rk356x: Fix PCIe register and range mappings

 arch/arm64/boot/dts/rockchip/rk3568.dtsi | 14 ++++++++------
 arch/arm64/boot/dts/rockchip/rk356x.dtsi |  7 ++++---
 2 files changed, 12 insertions(+), 9 deletions(-)


base-commit: f0c4d9fc9cc9462659728d168387191387e903cc
--
2.38.0


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

             reply	other threads:[~2022-11-12 11:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-12 11:41 Andrew Powers-Holmes [this message]
2022-11-12 11:41 ` [PATCH 1/1] arm64: dts: rockchip: rk356x: Fix PCIe register and range mappings Andrew Powers-Holmes
2022-12-05 16:23   ` Chukun Pan
2022-12-05 18:15     ` Ondřej Jirman

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=20221112114125.1637543-1-aholmes@omnom.net \
    --to=aholmes@omnom.net \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=frank-w@public-files.de \
    --cc=frattaroli.nicolas@gmail.com \
    --cc=heiko@sntech.de \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=macromorgan@hotmail.com \
    --cc=mark.kettenis@xs4all.nl \
    --cc=megi@xff.cz \
    --cc=michael.riesch@wolfvision.net \
    --cc=pgwipeout@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=s.hauer@pengutronix.de \
    --cc=yifeng.zhao@rock-chips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).