[PATCH v3 0/7] FUSB302 USB-C controller support

[Marek Vasut]

On 8/19/24 7:38 PM, Sebastian Reichel wrote:
> Hi,
> 
> On Mon, Aug 19, 2024 at 07:08:37PM GMT, Marek Vasut wrote:
>> On 8/18/24 11:43 PM, Jonas Karlman wrote:
>>>>> 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).
>>>>>
>>>>> Sorry for the delay in getting PATCHv3 ready.
>>>>
>>>> I am the one who should be sorry here, really, sorry for the abysmal
>>>> delay in my replies.
>>>>
>>>> So ... this series looks good to me. Thank you for working on this !
>>>>
>>>> Jonas, are your concerns resolved ?
>>>
>>> No, for ROCK 5B the full overwrite of the Rockchip common misc_init_r()
>>> in mach-rockchip/board.c should be fixed, rockchip_early_misc_init_r()
>>> could probably be used instead (or possible a PREBOOT cmd), see [1].
>>
>> Can you use DM_FLAG_PROBE_AFTER_BIND instead of misc_init_r for this ?
>>
>> drivers/led/led-uclass.c: dev_or_flags(dev, DM_FLAG_PROBE_AFTER_BIND);
>>
>> This will probe the driver after it got bound, and you won't have to hack
>> around board files or arch files for this.
> 
> Jonas suggested the same. My response still applies:
> 
> Depending on the remote side (i.e. the power-supply) the TCPM state
> machine can take quite some time to get it into the "final" state.
> The worst I have seen was around 2 seconds.
> 
> Boards, which are not powered via their TCPM controller can survive
> a USB hard reset and do not need any U-Boot support. I think we do
> not want to add this penality to these boards.

Could you set the DM_FLAG_PROBE_AFTER_BIND flag only for systems where 
this is applicable ? Maybe use some DT property to decide whether or not 
to set the flag ?