Hi Marek,
On 12/9/20 5:22 PM, Patrick DELAUNAY wrote:
-----Original Message-----
From: Marek Vasut <ma...@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-specifications/usb-type-c-ucsi-spec.pdf
- Adapt other driver to use USB connector..... (as DWC3 for example to
manage dual role with type-c)
Patrick
