Hi Marek,

On 12/9/20 5:22 PM, Patrick DELAUNAY wrote:

-----Original Message----- From: Marek Vasut marex@denx.de Sent: mardi 20 octobre 2020 12:21

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.

I check this topic, I think I don't need to support OTG in dwc2

but I need to support USB port and connector as it is done in linux kernel.

and I think that I can propose a plan (6 month-1 year)

- Add a new u-class for USB connector based on linux/drivers/usb/typec/class.c

=> Allow to detect cable connection and USB mode (device / host)

- Add a new driver for USB type C connector (compatible "usb-c-connector")

- Migrate stusb1600 driver to use this new driver

- Update driver (dwc2 or usbphyc or directly in uclass ?) to use connector when present in device tree (devicetree/bindings/connector/usb-connector.yaml)

With these modifcations, I hope to have the same hooks than Linux.

And for future

- Add a USB typeC connector driver based on UCSI (linux/drivers/usb/typec/ucsi)

https://www.intel.com/content/dam/www/public/us/en/documents/technical-speci...

- Adapt other driver to use USB connector..... (as DWC3 for example to manage dual role with type-c)

Patrick