On Wednesday 02 August 2006 2:02 pm, Alan Stern wrote: > On Wed, 2 Aug 2006, David Brownell wrote: > > > ... now that I have a machine that can partially resume from STR, > > I can maybe spend some time chasing some of those issues; the box > > that can resume partially from "standby" is tied up with other stuff, > > not available for testing. I still have zero faith in how the Linux > > ACPI code does its wakeup event processing, since the number of times > > I've seen it behave sanely can be counted on the fingers of a hand > > that's been through industrial accidents that cost fingers. > > Before worrying about STR, standby, or STD, you should just try some > simple tests using runtime suspend. They should be doable on any machine > with an EHCI controller.
All that stuff used to work just fine, and I don't recall changing any of it. You're right, if that stuff has broken, it needs investigation. Time allowing. > > > Second, the call to > > > usb_hcd_resume_root_hub() is in the wrong place -- it is invoked when a > > > wakeup request arrives on a suspended port rather than when the root hub > > > itself generates a wakeup request. > > > > All hcd_resume_root() does is kick khubd, and it doesn't matter how > > often that happens since it merges events, and can't even talk to the > > root hub until that routine finishes. > > More accurately, it doesn't matter if that happens too often. It _does_ > matter if that doesn't happen often enough, which is the problem I was > trying to fix. Well, I guess I'll see that when I go look again. What I saw in your patch was adding an event in a path that wasn't supposed to need it, and in which there was no guarantee the event could be handled correctly. > > Your change makes it so the > > controller isn't necessarily going to be running when khubd comes in, > > and kicks hubd even when there's nothing for it to do. > > All right, one thing at a time: > > > Your change makes it so the > > controller isn't necessarily going to be running when khubd comes in, > > I.e., the controller might be suspended (as in PCI D3)? No, running -- there's a bit that turns the controller on enough to make it do USB work. Controller != hub; the hub can be suspended while the controller is still running. > I don't see how > that could happen. The routine I changed is ehci_irq(), and when the > controller is suspended we are very careful to make sure that it can't > generate IRQs. HCD_FLAG_HW_ACCESSIBLE and all that. So how could my > changes cause khubd to kick in when the controller is suspended? That "running" bit wouldn't have been properly set. > But perhaps you meant to say that my patch might kick khubd at a time when > the root hub isn't running? Well of course it does -- that's the whole > point. The root hub is suspended and it needs to be resumed; that's > exactly what usb_hcd_resume_root_hub() is intended to accomplish. But "suspended" doesn't mean the RUN bit isn't set. It does mean that none of the downstream ports are both enabled and not-suspended. > > and kicks hubd even when there's nothing for it to do. > > There _is_ something for it do to: It can resume the root hub! > > By contrasting, the existing code calls usb_hcd_resume_root_hub() at times > when there really is nothing for it to do (because the root hub is already > resumed when a remote-wakeup request is received on one of the ports). > > Are we miscommunicating somehow? It would seem so. That RUN bit is important ... some implementations of EHCI don't hook root hub operations up to it, so that it's possible to more or less treat their root hubs as a bitbang/gpio problem. That's nice, but unfortunately the EHCI 1.0 spec was revised to insist that the controller also have that RUN bit set. - Dave ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
