On Thu, Aug 09, 2007 at 02:56:08PM -0400, Alan Stern wrote: > On Thu, 9 Aug 2007, Zephaniah E. Hull wrote: > > > Urgh, I definitely need some sleep, yes, it's a &&. > > > Which, from the debugging statements from previous failed runs, we have > > something odder. > > > > reset_resume == 0, udev->state == USB_STATE_CONFIGURED. > > > > This is an even more bizarre state then I thought. > > 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.
>
> > > Nothing should. You might want to add a debugging printk to
> > > ohci_pci_resume() or prepare_for_handover() to see what the value is at
> > > the start of the resume. Maybe the firmware sets it incorrectly before
> > > the driver does anything.
> >
> > Perhaps, we seem to have a lot of very odd state at the time that we try
> > to resume the OHCI root hub.
>
> Agreed.
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.
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?
Zephaniah E. Hull.
--
1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
signature.asc
Description: Digital signature
------------------------------------------------------------------------- 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
