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

[Sebastian Reichel]

Hi,

On Sun, Aug 18, 2024 at 11:43:36PM GMT, Jonas Karlman wrote:
> Hi Marek and Sebastian,
> 
> On 2024-08-18 22:35, Marek Vasut wrote:
> > On 8/2/24 7:59 PM, Sebastian Reichel wrote:
> >> Hi,
> > 
> > Hello everyone,
> > 
> >> 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].
> Also the check for MISC_INIT_R symbol does not make sense and should be
> dropped, see [2].

I have a local change using PREBOOT cmd instead of misc_init_r()
and it works. I'm currently looking into the issue reported by
Sören Moch before sending a new version.

Greetings,

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20240819/8ba83f03/attachment.sig>