[PATCH v2 0/5] FUSB302 USB-C controller support

[Tim Harvey]

On Tue, Jun 4, 2024 at 9:35 AM Sebastian Reichel
<sebastian.reichel at collabora.com> 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
>
> 1. the USB-C port cannot be used at all
> 2. 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:
>
> 1. the tcpm state machine, which implements the Type C port manager state
>    machine as described in the USB PD specification
> 2. 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).
>

Hi Sebastian,

It seems here that your goal was primarily to react to the USB-PD
messages to negotiate board power. It looks like your tpmc class
implementation has the ability to handle role determination among
everything else from the tpmc but it's not clear to me how a tpmc
would hook into a USB controller to provide role feedback.

The rk3588 you're using in this series has a DWC3 controller
configured with dr_mode of otg which means it will register the
dwc3-generic-peripheral driver. When dwc3_core_init_mode is called,
what exists to set dwc->dr_mode according to the mode the TPMC is
showing? In other words what is here to provide the means for your OTG
controller to act in both host mode and device mode?

Perhaps it is beyond the scope of your series but I'm looking for a
framework where a driver monitoring a GPIO can provide the role to UDC
drivers. For example, I'm talking about a USB-B connector with the ID
pin going to a generic GPIO or a GPIO connected to a bus-less type-C
CC controller like the TPS25821 which provides a SINK# pin to specify
if you have a host cable vs a device cable attached.

Best Regards,

Tim