[PATCH] usb: dwc2: add "u-boot,force-vbus-detection" for stm32

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut <marex at denx.de>
> Sent: jeudi 15 octobre 2020 19:39
> 
> On 10/15/20 6:52 PM, Patrick DELAUNAY wrote:
> 
> Hi,
> 
> [...]
> 
> >> On 10/15/20 2:49 PM, Patrick Delaunay wrote:
> >>> On some board, the ID pin is not connected so the B session must be
> >>> overridden with "u-boot,force_b_session_valid" but the VBus sensing
> >>> must continue to be handle.
> >>>
> >>> To managed it, this patch adds a new DT field
> >>> "u-boot,force-vbus-detection" to use with "u-boot,force_b_session_valid"
> >>
> >> How is this solved in Linux ?
> >
> > It is managed by Linux DWC2 driver: it is a real OTG driver, with dual
> > mode support and by usb framework
> >
> > Throught the properties
> > &usbotg_hs {
> > 	usb-role-switch;
> > };
> >
> > a glue treat the session and the sensing management see
> > linux/drivers/usb/dwc2/drd.c in linux-next
> >
> > PS: activate_stm_id_vb_detection is also used in driver = hsotg->params.
> >
> > As ID pin / vbus is completly managed by the USB TYPE driver C
> > (STUSB1600 for STMicroelectronics board) and DWC2 driver with dual
> > role stack (host/gadget).
> >
> > I don't found a better solution than device tree property for this
> > task in U-Boot as DWC2 driver don't support dual role and U-Boot don't have
> framework for USB type C controller.
> >
> >>
> >> btw can you do something about that huge change in indent ? Is it necessary ?
> >
> > I move all this code under activate_stm_id_vb_detection (linked to
> > compatible "st,stm32mp1-hsotg") to avoid impact on other platform as
> > this "sensing" properties are only support for STM32MP15X (it is
> > linked to USB block detection integrated in SOC)
> >
> > And after I need to check the
> > 1/ The usb33d-supply is required of vbus or IDPIN sensing 2/ manage
> > Vbus sensing or override (according dt) 3/ manage IDPIN or override
> > (according dt)
> >
> > I add a new property to be backward compatible (even it the
> > combinaison is less clear) I protect regulator function call to avoid compilation
> issue for other platform.
> >
> > PS: after reading the refmanual, I also split VALOEN and VALOVAL bit update
> as it is required.
> >
> > So yes I think it is needed but I can split the patch to simplify the review.
> 
> I presume you don't feel like implementing proper OTG support, right ?

Yes, I am afraid of this task.

Patrick