Message-ID: <20240930210652.1232951-1-CFSworks@gmail.com>
Date: Mon, 30 Sep 2024 14:06:52 -0700
From: Sam Edwards <cfsworks@...il.com>
To: Heiko Stuebner <heiko@...ech.de>
Cc: Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ondrej Jirman <megi@....cz>,
	Chris Morgan <macromorgan@...mail.com>,
	Alex Zhao <zzc@...k-chips.com>,
	Dragan Simic <dsimic@...jaro.org>,
	FUKAUMI Naoki <naoki@...xa.com>,
	Sebastian Reichel <sebastian.reichel@...labora.com>,
	Jing Luo <jing@...g.rocks>,
	Kever Yang <kever.yang@...k-chips.com>,
	devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-rockchip@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Daniel Kukieła <daniel@...iela.pl>,
	Joshua Riek <jjriek@...izon.net>,
	Sam Edwards <CFSworks@...il.com>,
	Jonas Karlman <jonas@...boo.se>
Subject: [PATCH v2] arm64: dts: rockchip: Enable all 3 USBs on Turing RK1

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@...il.com>
Suggested-by: Jonas Karlman <jonas@...boo.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

Powered by blists - more mailing lists