00000000000000000000000000000000000000000000000000000000000000000000Hi Sebastian,
On Tue, 4 Jun 2024 at 17:35, Sebastian Reichel <sebastian.reic...@collabora.com> wrote: > > This adds TCPM framework in preparation for fusb302 support, which can > handle USB power delivery messages. This is needed to solve issues with > devices, that are running from a USB-C port supporting USB-PD, but not > having a battery. > > Such a device currently boots to the kernel without interacting with > the power-supply at all. If there are no USB-PD message replies within > 5 seconds, the power-supply assumes the peripheral is not capable of > USB-PD. It usually takes more than 5 seconds for the system to reach > the kernel and probe the I2C based fusb302 chip driver. Thus the > system always runs into this state. The power-supply's solution to > fix this error state is a hard reset, which involves removing the > power from VBUS. Boards without a battery (or huge capacitors) will > reset at this point resulting in a boot loop. > > This imports the TCPM framework from the kernel. The porting has > originally been done by Rockchip using hardware timers and the Linux > kernel's TCPM code from some years ago. > > I had a look at upgrading to the latest TCPM kernel code, but that > beast became a lot more complex due to adding more USB-C features. > I believe these features are not needed in U-Boot and with multiple > kthreads and hrtimers being involved it is non-trivial to port them. > Instead I worked on stripping down features from the Rockchip port > to an even more basic level. Also the TCPM code has been reworked > to avoid complete use of any timers (Rockchip used SoC specific > hardware timers + IRQ to implement delayed work mechanism). Instead > the delayed state changes are handled directly from the poll loop. > > Note, that (in contrast to the original Rockchip port) the state > machine has the same hard reset quirk, that the kernel has - i.e. > it avoids disabling the CC pin resistors for devices that are not > self-powered. Without that quirk, the Radxa Rock 5B will not just > end up doing a machine reset when a hard reset is triggered, but will > not even recover, because the CPU will loose power and the FUSB302 > will keep this state because of leak voltage arriving through the RX > serial pin (assuming a serial adapter is connected). > > This also includes a 'tcpm' command, which can be used to get > information about the current state and the negotiated voltage > and current. > > Co-developed-by: Wang Jie <dave.w...@rock-chips.com> > Signed-off-by: Wang Jie <dave.w...@rock-chips.com> > Signed-off-by: Sebastian Reichel <sebastian.reic...@collabora.com> > --- > Makefile | 1 + > cmd/Kconfig | 7 + > cmd/Makefile | 1 + > cmd/tcpm.c | 142 ++ > drivers/usb/Kconfig | 2 + > drivers/usb/tcpm/Kconfig | 8 + > drivers/usb/tcpm/Makefile | 3 + > drivers/usb/tcpm/tcpm-internal.h | 174 +++ > drivers/usb/tcpm/tcpm-uclass.c | 102 ++ > drivers/usb/tcpm/tcpm.c | 2251 ++++++++++++++++++++++++++++++ > include/dm/uclass-id.h | 1 + > include/usb/pd.h | 516 +++++++ > include/usb/tcpm.h | 99 ++ > 13 files changed, 3307 insertions(+) > 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/tcpm-internal.h > create mode 100644 drivers/usb/tcpm/tcpm-uclass.c > create mode 100644 drivers/usb/tcpm/tcpm.c > create mode 100644 include/usb/pd.h > create mode 100644 include/usb/tcpm.h Can you please add docs for the command (and perhaps the whole feature)? How is this tested? It should be possible to write a simple i2c emulator for the chip as a way to cover this in CI (search for UCLASS_I2C_EMUL to see examples). Regards, Simon
