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. > > 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. > As mentioned, this need has been identified a few times by now, so nothing strange in your request/proposal. But so far no one has come up with a good way to register glue code callbacks with the core; we can't pass arbitrary data (such as a function pointer to such callback), and we don't know when the core is registered, so we can't call a register operation when that happens. Regards, Bjorn > [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,
