Hi, On Sun, Aug 18, 2024 at 11:43:36PM GMT, Jonas Karlman wrote: > 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].
I have a local change using PREBOOT cmd instead of misc_init_r() and it works. I'm currently looking into the issue reported by Sören Moch before sending a new version. Greetings, -- Sebastian
signature.asc
Description: PGP signature
