[PATCH v3 0/7] FUSB302 USB-C controller support

[Jonas Karlman]

Hi Marek and Sebastian,

On 2024-08-18 22:35, Marek Vasut wrote:
> On 8/2/24 7:59 PM, Sebastian Reichel wrote:
>> Hi,
> 
> Hello everyone,
> 
>> 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).
>>
>> Sorry for the delay in getting PATCHv3 ready.
> 
> I am the one who should be sorry here, really, sorry for the abysmal 
> delay in my replies.
> 
> So ... this series looks good to me. Thank you for working on this !
> 
> Jonas, are your concerns resolved ?

No, for ROCK 5B the full overwrite of the Rockchip common misc_init_r()
in mach-rockchip/board.c should be fixed, rockchip_early_misc_init_r()
could probably be used instead (or possible a PREBOOT cmd), see [1].

Also the check for MISC_INIT_R symbol does not make sense and should be
dropped, see [2].

[1] https://lore.kernel.org/u-boot/34c55a9f-0e49-4439-9360-a706cf60ea2b@kwiboo.se/
[2] https://lore.kernel.org/u-boot/56322afa-1595-4228-8259-728a92531025@kwiboo.se/

Regards,
Jonas