> > You mean ohci->regs->control doesn't contain OHCI_USB_RESET in the > > appropriate bits? What does it contain? And why? > > ohci->hc_control & OHCI_CTRL_HCFS == OHCI_USB_SUSPEND, and I honestly > don't have the foggiest clue how or why it has that after coming back > from the chip being powered off. > > My best guess is that somewhere else in the resume path we're resetting > it, but that's only a guess and I have no idea why anything would do > that. > > Infact, grepping through the source tree, the only thing setting > OHCI_USB_SUSPEND is ohci_rh_suspend, which would have happened prior to > turning off the device. > > My guess is that something is blindly restoring from ohci->hc_control > without first reading in the value.
And with more digging and grepping, there are only a small handful of
functions that could even vaguely potentially be doing this.
All on ohci-q.c, and a bit above my head as to figuring out if they
could be called before resume, but here they are:
finish_urb will do it at the end if there are no other requests pending.
ed_schedule will do it in the PIPE_CONTROL and PIPE_BULK cases, some of
the time anyhow.
ed_deschedule will also do it in the PIPE_CONTROL and PIPE_BULK cases,
some of the time.
td_submit_urb will do it if periodic DMA is needed.
finish_unlinks will do it in some cases.
Someone who knows the code better then me, or at least someone who
hasn't been up 18 hours with the past 10+ spent on this bug should try
to figure out if one of these is being called (a hand full of debugging
statements would do the job), and then figure out how it's being called
prior to the resume being finished.
It may well be worth while, if the spec and driver design will allow, to
go through the few cases that set hc_control without updating the
register contents to update the register contents immediately, and to
kill all cases of setting straight from hc_control without first reading
back the proper contents from the hardware.
If that's actually the right approach for the driver, and I need more
sleep before being able to make a guess at that, then it's a fairly
straight forward job.
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.
Has anyone got a reference cynic? I think I need to recalibrate myself.
-- James Riden in the SDM.
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
