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

[Marek Vasut]

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 ?