Hi Jonas, On Wed, Sep 18, 2024 at 09:56:35AM GMT, Jonas Karlman wrote: > On 2024-09-05 17:08, Sebastian Reichel wrote: > > On ROCK 5B power is usually supplied via it's USB-C port. This port has the > > data lines connected to RK3588, VBUS connected to the input regulator and > > CC pins connected to FUSB302. FUSB302 is a USB-C controller, which can be > > accessed via I2C from RK3588. The USB-C controller is needed to figure out > > the USB-C cable orientation, but also to do USB PD communication. Thus it > > would be great to enable support for it in the operating system. > > > > But the USB-PD specification requires, that a device reacts to USB-PD > > messages > > send by the power-supply within around 5 seconds. If that does not happen > > the > > power-supply assumes, that the device does not support USB-PD. If a device > > later starts sending USB-PD messages it is considered an error, which is > > solved > > by doing a hard reset. A USB-PD hard reset means, that all supply voltages > > are > > removed for a short period of time. For boards, which are solely powered > > through their USB-C port, like the Radxa Rock 5B, this results in an machine > > reset. This is currently worked around by not describing the FUSB302 in the > > kernel DT, so nothing will ever speak USB-PD on the Rock 5B. This means > > > > 1. the USB-C port cannot be used at all > > 2. the board will be running via fallback supply, which provides limited > > power capabilities > > > > In order to avoid the hard reset, this adds FUSB302 support to U-Boot, so > > that we react to the power-supply's queries in time. The code, which is > > originally from the Linux kernel, consists of two parts: > > > > 1. the tcpm state machine, which implements the Type C port manager state > > machine as described in the USB PD specification > > 2. the fusb302 driver, which knows about specific registers > > > > Especially the first part has been heavily modified compared to the > > kernel, which makes use of multiple delayed works and threads. For this > > I used a priorly ported version from Rockchip, removed their hacks and > > any states not necessary in U-Boot (e.g. audio accessory support). > > > > This version has been tested on Radxa Rock 5B using the open source TF-A > > (patches recently got merged into master branch) using the following power > > supplies: > > > > * non PD capable (reports 5V 0A) > > * RavPower 90W > > * UGREEN 100W > > * Anker 45W > > * RavPower PB > > > > [snip] > > This series look good and works great on my ROCK 5B, tested using two > different PD capable power supplies, so this entire series is: > > Reviewed-by: Jonas Karlman <jo...@kwiboo.se>
Thanks. > I did notice that trying to hook up the ROCK 5B from my computer to use > UMS in U-Boot there is a slight delay at boot and following is shown: > > fusb302 usb-typec@22: TCPM: PD transmit data failed: -110 > > I suspect this work as intended, so nothing blocking. Yes. These potential delays are the reason why I only wanted to enable this for affected boards. I suppose we can try to get rid of the error message for the case of not having PD at all. Note, that a standard compliant USB port (limited to 500mA [USB2] or 900mA [USB3]) is not good enough to power the Rock 5B since cpufreq got enabled. the Rock 5Bs in Collabora's KernelCI farm were originally powered through a USB hub and the hub powered the port off during boot after applying the cpufreq patches. So the error might be useful to understand why there are boot issues. Greetings, -- Sebastian
signature.asc
Description: PGP signature
