[PATCH v2 1/5] usb: tcpm: add core framework

[Soeren Moch]

On 13.07.24 17:13, Simon Glass wrote:
> 00000000000000000000000000000000000000000000000000000000000000000000Hi
> Sebastian,
>
> On Tue, 4 Jun 2024 at 17:35, Sebastian Reichel
> <sebastian.reichel at 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.wang at rock-chips.com>
>> Signed-off-by: Wang Jie <dave.wang at rock-chips.com>
>> Signed-off-by: Sebastian Reichel <sebastian.reichel at 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