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

[Marek Vasut]

On 10/16/20 6:32 PM, Patrick DELAUNAY wrote:
> Hi Marek,

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.

Can you take a look ?

I will pick this patch into next for now.