Hi Sebastian, On 2024-09-18 11:41, Sebastian Reichel wrote: > 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 <[email protected]> > > 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.
Not sure we need to do this, was just something I noticed for one of the tests I typically perform when a board has an usb gadget port in U-Boot. > 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. My test/use-case only involve U-Boot and using one of the UMS or RockUSB features to read/write from/to storage from a host computer, e.g. write u-boot-rockchip.bin or a rootfs to eMMC or NVMe storage. The ROCK 5B only seem to use/peek around 400mA until U-Boot cli and around 750-900mA after "pci enum", so using the USB3 port on my host computer for this test/use-case is fine. When booting into and running Linux I always ensure to use a proper power supply for the board :-) Regards, Jonas > > Greetings, > > -- Sebastian
