On Sun, 30 May 2004, David Brownell wrote:
> > In usb_resume_device(), when resuming a root hub, I think you
> > shouldn't call hub_resume() but instead call finish_resume(). After all,
> > the hub driver may have been unbound from the root hub!
>
> 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 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.
> > 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.
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...)
> I think all the HCDs can just get a port change detect IRQ somehow.
> 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
either:
Resume the controller and then call finish_resume(), or else
Call usb_resume_device() for the root hub.
Neither of those can be done in an IRQ handler. Sounds like a job for
schedule_work() with support routines in hcd.c.
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?
> > 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.
> 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: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
