[PATCH v6 0/6] FUSB302 USB-C controller support

[Jonas Karlman]

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 <jonas at 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 at 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