Re: Disconnect interrupt generation for QC targets when role switch is enabled

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

 



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,



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux