Alan Stern wrote:
On Sun, 30 May 2004, David Brownell wrote:
Is it otherwise safe to unbind hubs from the hub driver? That
issue is worth looking at on its own. For now I'm assuming the
answer is no.
Right now it isn't safe. In the future it could be made safe, if we want
to. The simpler course might be to change the USBDEVFS_DISCONNECT ioctl
so that it will refuse to unbind the hub driver.
That makes sense to me.
That change would interact with the policy for using remote
wakeup too ... in this case badly, since finish_resume() would
disable it. It should probably be renamed ... finish_port_resume()
is more like how I'd been thinking of its role, and that's the
kind of context it's always called from.
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.
There's no apparent mechanism for an HCD to indicate that the root
hub has received a remote wakeup request while in global suspend mode.
How is this meant to be handled?
In global suspend mode, I seem to recall the only wakeup request is
port connect/disconnect ... device remote wakeup is only turned
on when a port is placed into selective suspend, and I recall you
being keen that one distinction of global suspend is that individual
ports were NOT selectively suspended.
Your second memory is correct, but your first memory is wrong. Remote
wakeup requests _are_ serviced for non-suspended ports when the entire hub
is suspended. There's two different states called Restart_S and
Restart_E; see 11.5.1.12 and 11.5.1.13.
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.
There's a nuance there with USB OTG support though: OTG devices
can wake up hosts at any time, remote wakeup (or SRP) are always
enabled. I was trying to keep that in the background for now, since
the basic answer to the question is that either the PME# handler
does the work (when both device and root hub are suspended) or
else the HCD's IRQ handler does (if just the root hub is)
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.
(For non-OTG devices, which will be the norm for the next
several years.)
I think all the HCDs can just get a port change detect IRQ somehow.
Which, even in the case that it's a "non-enabled" remote
wakeup, is enough of a hook to solve the problem. Since
the HC could issue an IRQ, it's in D0 state; and since it
received the IRQ, it can resume the root hub if needed.
That's what OHCI and EHCI should be doing now anyway. For things
like keyboards waking hosts from sleep, there's also PME# on PCI.
Non-PCI systems have their own solutions for restarting clocks and
otherwise bringing the relevant system components back to life.
Yes, that part is clear. But what happens next? Somehow the HCD has to
In which path? Wakeup from PME# is different from just waking
up the root hub itself.
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.
There's also the vexsome question of how this is supposed to interact with
PM. After the PME# signal is received and the CPU woken up, will the PM
code automatically resume every device? If not, how can the HCD hope to
resume the controller if its PCI interface is still in D3?
The code handling PME# is responsible for resuming the device(s)
issuing that wakeup request ... by calling PCI resume() entries,
which among other things put the device back into D0 state.
I don't know why you're assuming it should resume "every device".
While that could be a rule in the PC architecture that I don't
happen to know about, I didn't see anything in the PCI PM specs
that says anything other than selective resume is needed.
Your patch leaves two suspend/resume entries in struct hc_driver:
one for suspending the entire controller and one for suspending just the
root hub. It's not clear under what more the first has to do besides
calling usb_suspend_device() for the root hub, which will then call the
second. Maybe for a simple PCI controller like UHCI it doesn't have to do
anything else?
Given that hcd-pci does the rest, that's likely true for UHCI.
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.
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.
- Dave
I suspect that the hc_driver should only have the root hub
entry. The rest of suspend/resume is more like bus glue, or
even cpu-specific glue. Consider OMAP: PCI isn't normally
a factor, and different chip versions may turn off the clocks
using different registers. For now, this will affect OHCI
the most ... all the OHCI bus glue will be able to use the
same root hub suspend/resume logic.
Yes, that's about what I thought.
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
