Hi Thinh, Johan, Bjorn, Konrad,
On QC targets today, the disconnect event in device mode is generated
by controller when software writes to QSCRATCH registers in qcom glue
layer rather than the vbus line being routed to dwc3 core IP for it to
recognize and generate conndone/disconnect events.
We need to write '1' to UTMI_OTG_VBUS_VALID bit of QSCRATCH_HS_PHY_CTRL
register to generate a connection done event and "0" if we need to
generate a disconnect event during cable removal or mode switch. Exactly
what is done by "dwc3_qcom_vbus_override_enable" call in dwc3-qcom. In
case the user wants to enable runtime suspend for dwc3 and we don't
generate a disconnect event, the dwc->connected flag will be "true" and
it would block suspend entry.
Today, in dwc3-qcom, this qscratch modification is being done only for
vbus/host notifiers where I assume dwc3-qcom would be receiving these
notifications from charger driver regarding cable connect and removal
and since we are receiving a copy of the information in dwc3-qcom as
well, we would be knowing when to set/clear the VBUS_VALID bit.
But, when we have role switch in play, the role_set callback goes to DRD
and Qcom driver is agnostic of what is actually happening. While this
doesn't hinder mode switch, the role change notification never really
reaches dwc3-qcom and we would never set this bit to "0" and disconnect
event is not generated upon cable plug-out. Is there a way we can
properly provide this notification to qcom glue driver ?
I had some idea on how to get the role notification reach qcom glue
driver but wanted your opinion on whether they can be used or not:
1. Register a vendor_hook from glue driver and invoke that during
__dwc3_set_mode.
2. Let the role notification reach dwc3-qcom first and then let qcom
driver invoke role_set of drd. Something similar to what was implemented
by Wesley on [1].
But both the options require dwc3_probe to be done in sync with
of_platform_populate or we need to defer qcom probe if dwc3_probe is
deferred. Since we are leaning towards async probe, not sure if the
above two options would be proper.
Couple of more reasons to ask for the above two options:
1. We would know when we are in device/host mode and we can avoid having
any layering violations in dwc3-qcom.
2. When it comes to runtime pm implementation for dwc3-qcom, an effort
was done by Manivannan Sadhasivam previously [2], we can avoid modifying
xhci-plat.c to set autosuspend delay to any specific value. We would be
able to enable runtime/autosuspend for dwc->xhci->dev from dwc3-qcom
itself upon entering host mode.
Can you help let know your thoughts on the above two options or if there
is any way we can implement the role change / cable plug in(out) callback.
[1]:
https://patchwork.kernel.org/project/linux-usb/patch/20201009082843.28503-4-wcheng@xxxxxxxxxxxxxx/
[2]:
https://patchwork.kernel.org/project/linux-usb/cover/20230325165217.31069-1-manivannan.sadhasivam@xxxxxxxxxx/
Regards,
Krishna,
