On Wednesday 11 May 2005 11:57 am, Alan Stern wrote:
> On Wed, 11 May 2005, David Brownell wrote:
>
> > But ... if it doesn't work without USB_SUSPEND, then what would be
> > the point of such a routine?
>
> > 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.
> 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.
> 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.
> As far as helping root hubs do a real "usbcore" suspend... I don't see
> that as necessary. Certainly not now. Eventually the hub driver (or some
> power domain container manager) will learn to do its own autosuspend; then
> it will automatically use usb_suspend_device and the HCDs won't have to
> worry about it at all.
That still doesn't seem like a given to me. I've given reasons
before, and won't repeat them here.
> > ... For now, I'm not
> > willing to have separate and subtly different suspend codepaths.
>
> In UHCI the paths aren't separate. There's a single suspend routine that
> gets called for both types of suspend. The only difference is that when
> doing an autosuspend the routine skips over a time-consuming delay. It's
> known that the delay isn't needed because no devices are attached during
> autosuspend.
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.
> In a sense it's always been my policy that autoresume isn't recursive.
And as I've said, I started to adopt that policy after a while too.
Pushing the recursion into the PM framework (to whatever extent it's
needed) has always been on the agenda. But a change like that takes
time to retest, especially when big chunks of usbcore's HCD glue and
hub driver are changing all the while!
- Dave
-------------------------------------------------------
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
