On Fri, Aug 11, 2023 at 05:21:03PM +0530, Krishna Kurapati PSSNV wrote: > 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. > Since you have quoted my series, I'd like to get clarification on one issue I'm seeing. When resuming from runtime suspend in host mode, dwc3-qcom driver gets the wakeup event and it resumes the xhci driver. But the XHCI IRQs are received after some delay. Due to this, xhci driver doesn't resume the device, instead, all the drivers (dwc3-qcom, dwc3-core, xhci) went to runtime suspend again. But once the XHCI IRQs are received, dwc3-qcom gets the wakeup event and this time, xhci driver resumes the device. This is the reason why I added the autosuspend delay of 200ms to allow the xhci driver to wait for IRQs before going to runtime suspend. Can you clarify why there is a delay in receiving XHCI IRQs? - Mani > 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, -- மணிவண்ணன் சதாசிவம்
