Disconnect interrupt generation for QC targets when role switch is enabled

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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,



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux