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-a706cf60e...@kwiboo.se/ [2] https://lore.kernel.org/u-boot/56322afa-1595-4228-8259-728a92531...@kwiboo.se/ Regards, Jonas
