> > 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.
>
Thanks, Alan.
So you suggest the individual udc driver should keep controller status track
at all necessary places, eg, ep_flush, ep_dequeue, ep_disable etc.
And the udc decides whether it does noop or power on controller to access
register, right?
Peter
--
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
