On Tue, 26 Nov 2013, Peter Chen wrote:
> > > 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?
Right. For most of these operations, you probably will not need to
power-on the controller.
In fact, for most of these operations you probably will not need to do
anything whenever Vbus is off or the D+ pullup is off, even if the
controller is still at full power.
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
