summaryrefslogtreecommitdiff
path: root/drivers/usb/tcpm
AgeCommit message (Collapse)Author
2026-02-17treewide: Clean up DECLARE_GLOBAL_DATA_PTR usagePeng Fan
Remove DECLARE_GLOBAL_DATA_PTR from files where gd is not used, and drop the unnecessary inclusion of asm/global_data.h. Headers should be included directly by the files that need them, rather than indirectly via global_data.h. Reviewed-by: Patrice Chotard <[email protected]> #STMicroelectronics boards and STM32MP1 ram test driver Tested-by: Anshul Dalal <[email protected]> #TI boards Acked-by: Yao Zi <[email protected]> #TH1520 Signed-off-by: Peng Fan <[email protected]>
2024-10-17usb: tcpm: fusb302: add driverSebastian Reichel
Now that the TCPM framework exists we can introduce fusb302 driver using it. This chip is a very common USB-C controller chip with PD support, which can be found in the Radxa Rock 5B among many other boards. Apart from Power Delivery, it also handles detection of the cable orientation. That can be used to control a mux for connecting the right USB3 lane pair to the USB3 controller. The driver is originally from the Linux kernel, but has been adapted to the requirements of U-Boot and its TCPM framework. Co-developed-by: Wang Jie <[email protected]> Signed-off-by: Wang Jie <[email protected]> Tested-by: Soeren Moch <[email protected]> Tested-by: Anand Moon <[email protected]> Reviewed-by: Jonas Karlman <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>
2024-10-17usb: tcpm: add core frameworkSebastian Reichel
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 <[email protected]> Signed-off-by: Wang Jie <[email protected]> Tested-by: Soeren Moch <[email protected]> Tested-by: Anand Moon <[email protected]> Reviewed-by: Jonas Karlman <[email protected]> Signed-off-by: Sebastian Reichel <[email protected]>