On 13.07.24 17:13, Simon Glass wrote:
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?
Asks the developer who caused the most u-boot regressions for me within
the last decade.
Did you notice this is a 5 part series?
It was tested on the board this was developed for. You received a t-b
~5 weeks ago.
Regards,
Soeren
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
