Alan Stern wrote:
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?
It's enabled as part of root hub registration, for root
hubs that report they can_wakeup. I'm not completely
happy with that, but that's where it sits right now.
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.
Not without selective suspend enabled first, was my point;
so we're not disagreeing on anything except terminology
we've already agreed is confusing (This was all off-list,
but I distinctly recall you being keen on the fact that
in "global suspend" the ports weren't selectively suspended.
Hence the result that only connect/disconnect could wakeup.)
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?
All devices? They don't all support it.
All the time? Evidently some common designs misbehave then,
and anyway the USB spec says (somewhere) to do it right
before suspend (so those designs are allowed).
Or if it's supposed to be controlled by the user, why isn't
it exposed through sysfs?
That'd be a sensible option, and I think it should eventually
be supported. Default "enable wakeup". It can be added later,
ideally after we have more real-world experience with this.
Under what conditions would we want remote wakeup to be
or not to be enabled on a suspended device?
That's the "real world experience" bit. Basically, the only
reason I can think of where we do NOT want it enabled is if
the device doesn't handle remote wakeup correctly. Whether
we should expect users to know about that is a different issue.
Windows certainly gives users such options.
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?
PME# is what gets raised by devices that are in D1, D2, or D3 state;
they can't raise regular IRQs, by definition of those non-D0 states.
That is, the difference is that PCI-suspended devices can't issue
normal IRQs. Or do DMA, and only config space registers are visible
so the virtual root hub timer can't poll any more ... all of which
can be done when just the root hub suspends.
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?
You don't receive PME# as an IRQ, it's supposed to morph into a
pci resume() driver call. So it _does_ matter which path is in use.
(They can/should be independently debugged.)
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
That would only be on the pci resume() path, as I understand it.
If only the root hub was suspended, the rest of the system won't
have had any reason to even look at the device. It'll be just like
any other driver-private mode. (Visible through USB though.)
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
The hardware distinguishes between "root hub suspended" and
"device suspended", so the driver needs to do it too.
which sort has occurred? Is this a good reason for keeping both pairs of
suspend/resume callbacks in struct hc_driver?
That's an orthogonal question. There are certainly going to be
two chunks of logic (one a superset of the other), one of which
is called from the bus glue and could eventually be moved out
of hc_driver ... likely when that structure itself gets cleaned
up, which seems more like 2.7 than anything else.
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?
Read the PCI PM spec, and I think you'll agree that D3hot will be
providing suspend current to all devices (using vAux) and D3cold
won't ...
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?
I'm thinking it'd be wrong to make root hubs resume any differently
than any other kind of hub, at that level. So: resume everything.
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?
Maybe that's how it's done. But while the OHCI and EHCI specs
say how some such info is provided, UHCI doesn't (at least, the
UHCI specs that I've seen). Though I'm not entirely sure what
to make of the text in those specs ... or the behavior of any
PC hardware I've seen Linux doing power management for! :)
I suspect it's a good bet that any HC with PCI PM capabilities
actually does support such wakeup (using PME#). I suspect that
some PCI devices that don't have those capabilities can also
wake systems up, if the BIOS is allowed to perform magic.
(Which need not involve PME# actually...)
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.
That's one question, right; though see above.
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.
Right, that's basic hub behavior, and a root hub can do
pretty much what any hub can do.
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.
Yep, another "all hubs do this" behavior. So far as I've
seen, all the main PCI based HCs can act like "real hubs",
although some of the USB 1.1 features aren't always there
(power switching, overcurrent, etc).
- Dave
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
