On Fri, 10 Aug 2007, Zephaniah E. Hull wrote: > > After you get up :-), check udev->state at the end of > > usb_suspend_device(). It should be USB_STATE_SUSPENDED, and nothing > > should change it until usb_resume_device() runs. > > > > Are you maybe seeing ohci_rh_resume() get called twice in a row? > > Got side tracked while tracking down the issue below. > > We are not calling ohci_rh_resume twice, and in usb_hcd_pci_suspend we > are in USB_STATE_CONFIGURED. > > Throwing in a few more debugging statements to figure out if we ever set > to USB_STATE_SUSPENDED, and if so, where we unset it.
udev->state is supposed to get set to USB_STATE_SUSPENDED in hcd_bus_suspend() in core/hcd.c. (This is before usb_hcd_pci_suspend() gets called.) Does something go wrong there? > I now have a better idea of what we are currently doing on resume. > > I don't have a good idea of what we should be doing on resume. > > When the OLPC comes up from suspend, a small bit of Open Firmware code > gets run, this writes 1 to HcCommandStatus, resetting the OHCI chip into > Suspend mode, then writes into HcRhDescriptorB and HcRhPortStatus*, > bringing up the power to the USB ports. > > After that the OS gets started, so by the time the Linux OHCI code sees > things, we're already in suspend mode and the power to the ports is on, > but otherwise we're fresh from chip power on. > > However since the chip isn't actually in reset, ohci_rh_resume doesn't > jump through the right hoops. This is a problem. The code in ohci-hcd isn't very sophisticated about checking for interference from the firmware. Maybe because there are so many different implementations of OHCI floating around, it's hard to know what approach will work on all of them. And maybe because there aren't many settings which can be checked. > Changing what OFW does on resume is possible, if it's flatly not doing > what it should. But a driver fix would be preferred in some ways. > > Any thoughts? I'd say OFW is flatly not doing what it should. In fact, from your description it goes out of its way to fool Linux into thinking the controller was powered on the whole time when in fact it wasn't. Because the power was off the controller has just gone through a hardware reset; there's absolutely no need to pile a software reset on top of that. Of course you can always work around this by making an OLPC-specific change to the driver. I can't think of any general way to detect this sort of thing that would be suitable for the standard kernel, however. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
