On Tue, 1 Jun 2004, David Brownell wrote:
> > What's wrong with disabling remote wakeup on a hub, even a root hub, when
> > it is resuming? Remote wakeup is meaningful only when the hub is
> > suspended.
>
> While it's resuming, no problem. Forever ... that'd be a problem;
> and that's the effect the change you suggested would have just now.
Right now, if I'm not mistaken, you don't enable remote wakeup on root
hubs at all. So why should disabling it forever cause any problems?
> You missed something important: remote wakeup isn't going to be enabled
> outside of selective suspend. So unless CONFIG_USB_SUSPEND is enabled,
> AND it's enabled on the devices connected to that root hub (by selective
> suspend), then the only wakeup requests are connect/disconnect.
I think this proves what I was trying to say: Your memory that in global
suspend mode the only wakeup events are connect/disconnect is wrong, and
if CONFIG_USB_SUSPEND is set and remote wakeup is enabled on the devices
then we may see these other events.
> > In any case, your implementation _does_ selectively suspend all the
> > connected ports before doing a global suspend of a root hub. (In
> > principle that's not necessary but not doing it might lead to problems,
> > I'm not sure...)
>
> It's necessary since that's how remote wakeup gets enabled.
This just raises some more questions.
Why shouldn't remote wakeup be enabled on all devices, all the
time?
Or if it's supposed to be controlled by the user, why isn't
it exposed through sysfs?
Under what conditions would we want remote wakeup to be
or not to be enabled on a suspended device?
> In which path? Wakeup from PME# is different from just waking
> up the root hub itself.
I'm talking about any pathway. And how is it different? For that matter,
under what circumstances does a controller raise PME# as opposed to
raising its regular IRQ?
> > either:
> >
> > Resume the controller and then call finish_resume(), or else
>
> Khubd or hub_resume() handles all calls to finish_resume().
>
> > Call usb_resume_device() for the root hub.
>
> Right now, that'd only be done through sysfs. The bus glue
> would just call the HCD's root hub resume directly.
>
>
>
> > Neither of those can be done in an IRQ handler. Sounds like a job for
> > schedule_work() with support routines in hcd.c.
>
> OHCI has a schedule_work() call that fires in a couple places.
> One is when the wakeup IRQ fires; the other is a "selective
> resume" case that I don't think the other HCDs need to care
> about yet. Maybe hcd.c is the right place eventually.
Look, suppose the root hub is suspended. Maybe other things are too, in
fact, maybe the whole system is asleep. It doesn't matter for my
purposes. One way or another, the controller issues a resume-detected
interrupt, either because a connection was made or removed on the root hub
or because some device raised a remote wakeup signal. If the entire
system was asleep, maybe there was PME# signal sent first. However it
happened, my driver has now received an interrupt. What should it do?
It can resume the root hub. To do that it might need to know whether
some of the controller's registers need to be reinitialized -- buggy
BIOSes have been known not to restore the proper values. Should the
driver simply reinitialize the registers whenever it resumes? Should it
distinguish between a root-hub resume and a full device resume, and assume
the registers are okay during a root-hub resume? If so, how does it know
which sort has occurred? Is this a good reason for keeping both pairs of
suspend/resume callbacks in struct hc_driver?
If we are resuming from a sufficiently deep sleep, do we need to reset the
entire USB bus? For instance, in D3hot will the controller be able to
provide power on the bus? If not, the driver would have to restart
rather than resume. What about D3cold?
Once the root hub has been resumed, what about the rest of the device
tree? Whose responsibility is it to wake that up -- whoever put it to
sleep originally? If the user suspends the root hub via sysfs, that will
automatically suspend everything on the bus; do we then want to arrange
things so that when the user resumes the root hub everything else remains
suspended?
> >>But my brief reading there didn't turn up info on how UHCI does
> >>things like "wakeup from D3" (or even learn that it can_wakeup),
> >>so it might need more.
Wouldn't some of that information be available in the PCI configuration
data?
> > I'm assuming the generic hcd-pci code will suffice for that.
>
> It can't suffice to report that the root hub CAN do remote
> wakeup ... both EHCI and OHCI have special flags set by the
> BIOS code to report that.
What do you mean by "CAN do remote wakeup"?
Can issue PME# signals? I don't know about that.
Can send an IRQ when a connect/disconnect happens on a
globally-suspended root hub? UHCI controllers can always
do that (unless the manufacturer has screwed up the wiring
on the motherboard).
Can automatically send a USB resume signal when a suspended
port receives a remote wakeup signal? All UHCI controllers
do that.
Can automatically send USB resume signals on all enabled-
and-non-suspended ports when a remote wakeup signal is
received and the root hub is suspended? All UHCI controllers
do that whenever they are in global suspend mode.
Alan Stern
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
