On Thursday 06 January 2005 6:54 am, Alan Stern wrote: > On Wed, 5 Jan 2005, David Brownell wrote: > > > > > Is EHCI being resumed before UHCI -- or afterwards? > > > > > > EHCI was resumed after UHCI. > > > > I suspect it'd work better the other way around. > > Maybe it would, maybe not.
I'd like to see Oliver try the experiment (implies a modular kernel). And besides, you asked for ideas, on the assumption that it was the port routing (to EHCI or UHCI) that was going wrong ... We saw the /proc/debug/uhci/0000:00:1d:0 output; what does the corresponding /sys/class/usb_host/.../registers information (for EHCI) show, before and after suspend? > In any case this isn't under our control. > Devices are resumed in the same order they were detected initially. I > think the only way to solve this problem is to find a workaround for EHCI > controllers that act weird when they resume. The problem could well be in UHCI instead, or BIOS. There are at least several dozen different configurations to test here, after all ... ;) Oliver, you're using some kind of BIOS suspend right? That is, /sys/power/disk says "platform" not "shutdown". Does swsusp behave correctly in the "shutdown" case? That's roughly the difference between an ACPI S4bios and an ACPI S4 suspend sequence. Both need testing. The only thing that a quick scan of the ehci resume code suggested might be a problem is the line of code in ehci-hub.c::ehci_resume() that checks for whether the PORT_SUSPEND bit is set. Maybe that should be checking for (PORT_SUSPEND|PORT_OWNER)? - Dave > > Alan Stern > > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
