Hi, On Mon, Aug 19, 2024 at 07:08:37PM GMT, Marek Vasut wrote: > On 8/18/24 11:43 PM, Jonas Karlman 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). > > > > > > > > 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]. > > Can you use DM_FLAG_PROBE_AFTER_BIND instead of misc_init_r for this ? > > drivers/led/led-uclass.c: dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND); > > This will probe the driver after it got bound, and you won't have to hack > around board files or arch files for this.
Jonas suggested the same. My response still applies: Depending on the remote side (i.e. the power-supply) the TCPM state machine can take quite some time to get it into the "final" state. The worst I have seen was around 2 seconds. Boards, which are not powered via their TCPM controller can survive a USB hard reset and do not need any U-Boot support. I think we do not want to add this penality to these boards. Greetings, -- Sebastian
signature.asc
Description: PGP signature
