Hi Sebastian,
On 2024-05-31 17:08, Sebastian Reichel wrote:
Hi,
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).
Thanks for working on this!
Some initial quick feedback is that the tcpm uclass and driver should probably take more advantage of the u-boot driver model.
Few quick thoughts: - Split out uclass/driver api parts into tcpm-uclass.c - Take advantage of uclass_driver ops such as post_probe and per_device_auto/per_device_plat_auto to e.g. handle tcpm_port_init and tcpm_port/tcpm_dev - udevice should probably be passed to tcpm_ functions instead of a tcpm_port, dev_get_uclass_plat/priv could possible be used to get the tcpm_port data for the udevice
I have not yet had time to runtime test this but will do and get back with a more in depth review later this week.
Regards, Jonas
Greetings,
-- Sebastian
Sebastian Reichel (5): usb: tcpm: add core framework usb: tcpm: fusb302: add driver board: rock5b-rk3588: add USB-C controller support board: rock5b-rk3588: enable USB-C in operating system MAINTAINERS: add TCPM section
MAINTAINERS | 8 + Makefile | 1 + arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 28 + board/radxa/rock5b-rk3588/Makefile | 6 + board/radxa/rock5b-rk3588/rock5b-rk3588.c | 33 + cmd/Kconfig | 7 + cmd/Makefile | 1 + cmd/tcpm.c | 117 + configs/rock5b-rk3588_defconfig | 5 + drivers/usb/Kconfig | 2 + drivers/usb/tcpm/Kconfig | 16 + drivers/usb/tcpm/Makefile | 4 + drivers/usb/tcpm/fusb302.c | 1427 ++++++++++++ drivers/usb/tcpm/fusb302_reg.h | 177 ++ drivers/usb/tcpm/tcpm.c | 2406 +++++++++++++++++++++ include/dm/uclass-id.h | 1 + include/usb/pd.h | 516 +++++ include/usb/tcpm.h | 116 + 18 files changed, 4871 insertions(+) create mode 100644 board/radxa/rock5b-rk3588/Makefile create mode 100644 board/radxa/rock5b-rk3588/rock5b-rk3588.c create mode 100644 cmd/tcpm.c create mode 100644 drivers/usb/tcpm/Kconfig create mode 100644 drivers/usb/tcpm/Makefile create mode 100644 drivers/usb/tcpm/fusb302.c create mode 100644 drivers/usb/tcpm/fusb302_reg.h create mode 100644 drivers/usb/tcpm/tcpm.c create mode 100644 include/usb/pd.h create mode 100644 include/usb/tcpm.h