On Thu, 28 Aug 2003, David Brownell wrote: > Alan Stern wrote: > > David: > > > > The UHCI driver clearly has a problem with its > > reset/start/suspend/resume/stop functions. I'm not sure how to fix it > > because it's not clear exactly what the callbacks are supposed to > > accomplish and the contexts in which they are called (most especially > > whether they are allowed to block). The comments in core/hcd.h are very > > terse. > > Look more at where they're called: hcd.c, hcd-pci.c ... All are > allowed (even expected!) to block (schedule), like their callers.
Okay. I gather that after suspend() returns there should be no bus activity at all to the HC: DMA, PIO, regular I/O, whatever (with the possible exception of remote-wakeup IRQs). And after resume() returns the HCD should be fully operational and ready to accept URB submissions. I also gather that reset() is really more like a probe -- it should initialize the driver's data structures and generally prepare for start(). > > A couple of additional questions suggest themselves. First, what should > > happen if a wakeup/resume signal on the USB bus is detected before the > > suspend routine returns? > > We seem to have adopted the policy that going into system suspend > means going into USB suspend ... but USB suspend could happen at > other times, it's just "idle bus" (no SOF generation or other > traffic) that lets devices save power (battery etc) and lets the > host avoid accessing memory (scanning schedule etc). UHCI does this when no devices are plugged in. Maybe at some point we can add code that will detect when no URBs have been around for some period of time and initiate a suspend then too. > Since nothing turns on remote wakeup with USB, I'm suspecting > we shouldn't be expecting resume signaling. (And should be > cautious about suspending any port with a device on it.) But > I've not dived particularly into that chunk of USB. What do you mean about being cautious? > Once we do support remote wakeup, that question gets real. Maybe > we can fail the suspend operation; or maybe it'll get handled > like a normal remote wakeup would. Failing the suspend might be easier. It might not be -- obviously there's a race. > > Second, the Intel UHCI controllers have an > > erratum which causes them to present spurious resume-detect signals if a > > port's over-current input is active. (This is not just a theoretical > > problem; some manufacturers don't wire up all of the ports to connectors > > and then try to disable the unconnected ports by permanently tying the > > over-current inputs on.) When this happens the driver makes the > > conservative choice and does not allow suspends at all -- it will shutdown > > but not suspend. How should the PM callbacks behave in that situation? > > Scanning uhci docs suggest resume-detect is part of its remote wakeup > support. Yes? It is, but it's also used to detect when a new device has been plugged in to a root port while the controller is suspended. > And since Linux-USB doesn't seem to enable the remote wakeup feature > in any device, we have no reason to pay attention to such requests. > They're all errors, unless/until the host enables remote wakeup for > some device accessed through that root hub port. Not so simple. Since the driver puts the HC into suspend mode when no devices are attached, the first one to be plugged in must be able to invoke this mechanism. Alan Stern ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
