On Thursday, 14 September 2006 22:55, Alan Stern wrote: > On Thu, 14 Sep 2006, Rafael J. Wysocki wrote: > > > Well, sorry. This test has been passed, but after a reboot it refused to > > suspend just once giving the same messages that I've got from the kernel > > with USB_SUSPEND set (the relevant dmesg output is attached). > > > > > Then for the next stage, repeat the same tests but with > > > USB_SUSPEND set. > > Okay, hang on, let's try to solve this first. > > This actually is a completely different problem from what I've been > attacking up to now, and we definitely should resolve it. It's purely a > question of the ohci-hcd driver, nothing (or very little) to do with > usbcore or ehci-hcd or uhci-hcd. > > I'm asking David to chime in, because this is his code and his driver. > > Here's an explanation of the problem. Basically it boils down to the way > ohci-hcd rolls its own root-hub autosuspend. I'm referring to the call to > ohci_bus_suspend() near the end of ohci-hub.c:ohci_hub_status_data(). > Things go wrong because that call totally bypasses usbcore. It's a > layering violation. > > The corresponding root-hub autoresume code, i.e., the call to > usb_hcd_resume_root_hub() in ohci-hcd.c:ohci_irq(), _does_ go through > usbcore. It fails for two reasons. First, resume_root_hub does its job > by queuing a call to usb_autoresume_device(), and when CONFIG_USB_SUSPEND > isn't set that routine is a no-op. Second, since usbcore was never > notified when the root hub was suspended, the root hub's device state > isn't USB_STATE_SUSPENED and the interface is still marked as active -- so > even if usb_autoresume_device() did get called it wouldn't do anything. > > As I see it, there are two ways to resolve the problem. The easiest is to > rip out the autosuspend stuff from ohci-hcd entirely. When my generic > autosuspend patches are accepted, the HCD-specific stuff won't be needed > so much. This has the disadvantage that the root hub will never get > suspended if CONFIG_USB_SUSPEND isn't set. On the other hand, this is how > ehci_hcd works already.
This isn't a big deal as far as I'm concerned, but I think that dependancy will have to be reflected by some Kconfig rules (eg. if CONFIG_USB_SUSPEND gets selected automatically if CONFIG_PM is set). > The second way is to copy what I did in uhci-hcd. There is a special > "root hub is stopped" mode which kicks in only when no ports are > connected. It isn't a full-fledged suspend, in the sense that usbcore > isn't notified -- just like what happens in ohci-hcd. The difference is, > since we know no devices are attached, the driver can go back to normal > operation while in interrupt context. It doesn't have to sleep because no > attached devices means no TRSMRCY delay is needed and the controller's > hardware can be reset directly. As a result, the corresponding > "auto-restart" code doesn't need to go through usbcore either and so > usb_autoresume_device() never enters the picture. > > I don't know if this is feasible with OHCI. For now, I'll include a patch > that takes the first approach and disables the ohci-hcd autosuspend > entirely. I think it will solve your problem above. Yes it does. Now I'm able to suspend/resume several times in a row with both ohci and ehci hcds loaded all the time. Thanks a lot! Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller ------------------------------------------------------------------------- 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