On Mon, 25 Nov 2013, Peter Chen wrote:
> Hi all,
>
> With runtime pm enabled udc driver, we may put controller to low
> power mode when vbus is off or with SRP request. But gadget driver
> may not know the udc status when it calls usb_ep_ops and usb_gadget_ops.
>
> I meet this problem when I plug out usb cable from PC (using g_mass_storage),
> my callstack like: vbus interrupt->.vbus_session->composite_disconnect
> ->pm_runtime_put_sync(&_gadget->dev), the composite_disconnect will
> call fsg_disable, but fsg_disable calls usb_ep_disable using async way,
> there are register accesses for usb_ep_disable. So sometimes, I get system
> hang due to visit register without clock, sometimes not.
>
> Another use case is uvc, it enables dp pullup (call .pullup) by application,
> but at that time, the udc may be in low power mode.
>
> The ways I can think for dealing with above cases:
>
> - Add pm_runtime_get{_sync} and pm_runtime_put{_sync} during usb_ep_ops
> and usb_gadget_ops APIs, it needs to change every runtime pm enabled udc
> driver's related APIs, I don't think it is a good way.
> - Like hcd driver, we maintain some controller status, such as HCD_HW_ACCESSIBLE(hcd),
> etc, and udc dirver (or udc-core) update the status, and composite.c
> decides whether it needs to call pm_runtime_get{_sync} and pm_runtime_put{_sync}
> according to hardware status, for example, it needs to wait gadget to
> finish its hardware operation if it is async (like g_mass_storage).
>
> Any other good suggestions?
The UDC driver knows what the power state is at all times. Therefore,
when usb_ep_disable is called while the hardware is at low power, the
routine can avoid accessing the hardware. Since there's no connection
to host at such times, the usb_ep_disable really shouldn't need to do
anything.
The same sort of thing is true of pullup. The driver should keep track
of whether the pullup will need to be turned on when the hardware goes
back to full power, but as long as you are at low power, the routine
should not need to access the hardware at all.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
