Message-Id: <20250407-rk3576-sige5-usb-v1-0-67eec166f82f@collabora.com>
Date: Mon, 07 Apr 2025 20:09:13 +0200
From: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
To: Vinod Koul <vkoul@...nel.org>, 
 Kishon Vijay Abraham I <kishon@...nel.org>, Rob Herring <robh@...nel.org>, 
 Krzysztof Kozlowski <krzk+dt@...nel.org>, 
 Conor Dooley <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>, 
 Kever Yang <kever.yang@...k-chips.com>, 
 Frank Wang <frank.wang@...k-chips.com>
Cc: Sebastian Reichel <sebastian.reichel@...labora.com>, 
 kernel@...labora.com, linux-phy@...ts.infradead.org, 
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org, 
 Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Subject: [PATCH 0/4] RK3576 USB Enablement

This series is the result of what I thought would be a quick 10 minute
job, but turned out to be more like 3 days of pain, suffering, and
confusion. This should be expected with USB Type C though.

The first patch in the series extends the inno usb2 PHY binding in order
for us to be able to do what the second patch in the series does, which
is fiddle with some GRF flags in that driver when the PHY is connected
to a USB Type C port. Without this change, devices on USB-C simply don't
enumerate at all, as the state machine gets stuck waiting for vbus to go
low or something along those lines.

An alternate way to implement this would've been a vendor property in
the PHY binding which is then checked for in the driver and needs to be
present in all rockchip inno u2phy instances that happen to be connected
to a USB Type C connector. This is what downstream does, for example.

Patch 3 was really lovely to run into and needed a good amount of
sleuthing. I'm still certain this is "the wrong" fix, as it simply keeps
the PHY on, but it's a fix nonetheless, and one which has precedent,
namely in the RK3399. If someone is on a hunt to save milliamps in the
future, they might want to invest the time to come up with a less
sledgehammer sized solution for this problem, e.g. by disabling power
management until the controller is fully initialised.

Patch 4 adds the USB related nodes, including associated regulators and
Type C controllers, to the Sige5 tree.

As it stands, superspeed on the Sige 5's Type C port is still finnicky;
after a full day of debugging I still can't figure out why superspeed
only works in one cable orientation. I did a thorough pick through the
usbdp PHY driver, comparing it with what downstream has, etc. etc.
Because everything to do with testing Type-C ultimately comes down to
narrowing down the search space of non-compliant devices and
non-compliant cables to where you can sort of guess at the bug, it's a
huge time investment to debug this, and I'd rather submit the series
as-is right now for review and maybe some additional insight and testing
from someone with a wider variety of USB Type C cables and devices.

Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
---
Nicolas Frattaroli (4):
      dt-bindings: phy: rockchip,inno-usb2phy: add port property
      phy: rockchip: inno-usb2: add soft vbusvalid control
      arm64: dts: rockchip: add phy suspend quirk to usb on rk3576
      arm64: dts: rockchip: enable USB on Sige5

 .../bindings/phy/rockchip,inno-usb2phy.yaml        |   5 +
 .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 153 +++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3576.dtsi           |   2 +
 drivers/phy/rockchip/phy-rockchip-inno-usb2.c      |  78 ++++++++++-
 4 files changed, 234 insertions(+), 4 deletions(-)
---
base-commit: 64e9fdfc89a76fed38d8ddeed72d42ec71957ed9
change-id: 20250328-rk3576-sige5-usb-230102aeeaca

Best regards,
-- 
Nicolas Frattaroli <nicolas.frattaroli@...labora.com>

Powered by blists - more mailing lists