On Wed, 11 May 2005, David Brownell wrote:
> > > See above ... I thought the whole point of that routine was to
> > > help that resume-from-autosuspend case. At least I did when the
> > > idea originally came up ... in conjunction with the timer fixes,
> > > an autosuspended root hub could finally do a "real suspend" from
> > > the usbcore POV.
> >
> > That wasn't the point. Quite the opposite. The point was to help with
> > remote wakeup from a selective (non-auto) suspend.
>
> Which shouldn't need to be a special case; the only reason it's
> needed to be one so far is the timer mess ("soon" to be resolved).
>
> There's no fundamental difference between the wakeup scenarios.
> In both cases there's some wakeup event ... in both cases it
> might be "remote wakeup" (suspended USB device issues resume
> signaling) or another hub port change event (like plug/unplug).
> In both cases the root hub is pretty deeply suspended. The
> essential difference? In one case the root hub timer was still
> running; in the other case it wasn't.
That's not how I see it. To me the essential difference is whether or not
the resume pathway needs to go through usb_resume_device and whether or
not it needs a process context.
> > My feeling was (a) if the root hub was suspended without calling
> > usb_suspend_device then there was no need for calling usb_resume_device to
> > resume,
>
> The fact that there's any difference was primarily because of
> the timer mess.
That's a fragile way of doing things. It requires the HCD, while avoiding
actually calling usb_suspend_device, nevertheless to duplicate most of its
functionality so that usb_resume_device can reverse things properly.
It's not good programming practice.
(Ideally these calls should go through the PM core, not just through
usbcore. However the PM core is not yet up to handling such things.)
> > and (b) if autosuspend didn't need a process context then neither
> > does autoresume. From these it follow that if USB_SUSPEND isn't set then
> > resume_root_hub simply isn't needed.
>
> But (b) was a rather wrong assumption; resuming requires things
> like longish delays (I think minimum of 30 msec, plus more for
> fudge and things like working around that one Lucent bug). In
> fact OHCI autoresume has always used a process context.
I didn't know that. It does make things rather more difficult...
> OHCI autosuspends whenever the root hub is idle, whether or not any
> devices are connected. That is, connected-but-suspended is also a
> fine reason to autosuspend. And that would in fact be isomorphic
> to the the "Save 2 Watts on Centrino laptops with USB mouse and UHCI"
> configuration ... the one where UHCI changes would extend battery
> life significantly, by letting the CPU use the C3 state.
The UHCI driver could do that easily enough; only one subroutine (the one
that checks whether any active devices are attached) would need to be
changed. One key point is that I don't like the idea of autosuspending
immediately. Right now the driver insists on a minimum 1 second of
inactivity before autosuspend. Partly this is to eliminate bouncing as a
device is being plugged or unplugged, and partly it's a legacy from the
way the driver used to behave: If khubd wasn't available to clear the
port-change status bits the driver would suspend and then wake up again
right away, over and over.
Anyway, here's the problem as I understand it. OHCI (EHCI too?) needs a
process context to resume, if not to suspend. It does autosuspend without
calling usb_suspend_device (which doesn't even exist if USB_SUSPEND isn't
set). Hence it ought to autoresume without calling usb_resume_device.
And here's a suggestion for a solution. Make usb_hcd_resume_root_hub
conditional on CONFIG_PM rather than CONFIG_USB_SUSPEND (i.e., use your
patch), and make khubd call the hub_resume method directly if
root_hub->state != USB_STATE_SUSPENDED -- which will always be the case if
!CONFIG_USB_SUSPEND. This means also changing OHCI so that it leaves the
state equal to USB_STATE_CONFIGURED when autosuspending. How does that
sound?
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
