devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: Heiko Stuebner <heiko@sntech.de>
Cc: "Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Ondrej Jirman" <megi@xff.cz>,
	"Chris Morgan" <macromorgan@hotmail.com>,
	"Alex Zhao" <zzc@rock-chips.com>,
	"Dragan Simic" <dsimic@manjaro.org>,
	"FUKAUMI Naoki" <naoki@radxa.com>,
	"Sebastian Reichel" <sebastian.reichel@collabora.com>,
	"Jing Luo" <jing@jing.rocks>,
	"Kever Yang" <kever.yang@rock-chips.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
	"Daniel Kukieła" <daniel@kukiela.pl>,
	"Joshua Riek" <jjriek@verizon.net>,
	"Sam Edwards" <CFSworks@gmail.com>,
	"Jonas Karlman" <jonas@kwiboo.se>
Subject: [PATCH v2] arm64: dts: rockchip: Enable all 3 USBs on Turing RK1
Date: Mon, 30 Sep 2024 14:06:52 -0700	[thread overview]
Message-ID: <20240930210652.1232951-1-CFSworks@gmail.com> (raw)

The Turing RK1 contains 3 different USBs:
- USB0: USB 2.0, OTG
- USB1: USB 3.0, host
- USB2: USB 2.0, host

This patch activates the necessary DT nodes to enable all 3 buses.

Future work will be needed on USB0: it is not USB3-capable, so the USB0
controller needs to be told that there is no USB3 port. Per Jonas's
suggestion, the USBDP0 node is given a `rockchip,dp-lane-mux` property
that tells the USBDP driver that USBDP0 is not involved in USB so that
it can make the necessary configuration changes in hardware.
Technically, this is USB *controller* configuration, not *PHY*
configuration, so the underlying code may be moved in the future to the
USB controller driver instead, freeing up the (software) dependency on
USBDP0. A TODO comment is added to explain this.

Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Suggested-by: Jonas Karlman <jonas@kwiboo.se>

---

Happy Monday folks,

This is an updated version of one patch broken out from my previous series [1]
that enables USB on the Turing RK1 SoM.

Changes v1->v2:
- `rockchip,dp-lane-mux` added to tell USBDP0 explicitly that it is not
  involved in USB (thanks Jonas)
- Comment updated to more accurately reflect the situation, and to use one- not
  two-space-per-sentence style.

Kind regards,
Sam

[1]: https://lore.kernel.org/lkml/20240912025034.180233-1-CFSworks@gmail.com/T/
---
 .../boot/dts/rockchip/rk3588-turing-rk1.dtsi  | 65 +++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
index 0c4d809a860e..cdc525a8b157 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi
@@ -683,3 +683,68 @@ &uart9 {
 	pinctrl-0 = <&uart9m0_xfer>;
 	status = "okay";
 };
+
+/* USB 0: USB 2.0 only, OTG-capable */
+&u2phy0 {
+	status = "okay";
+};
+
+&u2phy0_otg {
+	status = "okay";
+};
+
+&usbdp_phy0 {
+	/*
+	 * TODO: On the RK1, USBDP0 drives the DisplayPort pins and is not
+	 * involved in this USB2-only bus. The bus controller (below) needs to
+	 * know that it doesn't have a USB3 port so it can ignore any
+	 * USB3-related signals. This is handled in hardware by updating the
+	 * GRFs corresponding to that bus controller. Alas, Linux currently
+	 * puts the code to do that in the USBDP driver, so USBDP0 must be
+	 * enabled for now.
+	 */
+	status = "okay";
+	rockchip,dp-lane-mux = <0 1 2 3>; /* "No USB lanes" */
+};
+
+&usb_host0_xhci {
+	extcon = <&u2phy0>;
+	maximum-speed = "high-speed";
+	status = "okay";
+};
+
+/* USB 1: USB 3.0, host only */
+&u2phy1 {
+	status = "okay";
+};
+
+&u2phy1_otg {
+	status = "okay";
+};
+
+&usbdp_phy1 {
+	status = "okay";
+};
+
+&usb_host1_xhci {
+	extcon = <&u2phy1>;
+	dr_mode = "host";
+	status = "okay";
+};
+
+/* USB 2: USB 2.0, host only */
+&u2phy2 {
+	status = "okay";
+};
+
+&u2phy2_host {
+	status = "okay";
+};
+
+&usb_host0_ehci {
+	status = "okay";
+};
+
+&usb_host0_ohci {
+	status = "okay";
+};
-- 
2.44.2


             reply	other threads:[~2024-09-30 21:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-30 21:06 Sam Edwards [this message]
2024-10-02 10:30 ` [PATCH v2] arm64: dts: rockchip: Enable all 3 USBs on Turing RK1 Heiko Stuebner

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=20240930210652.1232951-1-CFSworks@gmail.com \
    --to=cfsworks@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@kukiela.pl \
    --cc=devicetree@vger.kernel.org \
    --cc=dsimic@manjaro.org \
    --cc=heiko@sntech.de \
    --cc=jing@jing.rocks \
    --cc=jjriek@verizon.net \
    --cc=jonas@kwiboo.se \
    --cc=kever.yang@rock-chips.com \
    --cc=krzk+dt@kernel.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=megi@xff.cz \
    --cc=naoki@radxa.com \
    --cc=robh@kernel.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=zzc@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).