On 8/19/24 7:38 PM, Sebastian Reichel wrote:
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
- the USB-C port cannot be used at all
- 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:
- the tcpm state machine, which implements the Type C port manager state machine as described in the USB PD specification
- 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.
Could you set the DM_FLAG_PROBE_AFTER_BIND flag only for systems where this is applicable ? Maybe use some DT property to decide whether or not to set the flag ?