On Wed, 2 Jun 2004, David Brownell wrote: > Alan Stern wrote: > > > > Right now, if I'm not mistaken, you don't enable remote wakeup on root > > hubs at all. So why should disabling it forever cause any problems? > > It's enabled as part of root hub registration, for root > hubs that report they can_wakeup. I'm not completely > happy with that, but that's where it sits right now.
You could move the root hub vs. normal device distinction from __usb_suspend_device() down into hub_port_suspend(). Then root hubs would be suspended just like other devices, so they could be resumed the same way too. > > I think this proves what I was trying to say: Your memory that in global > > suspend mode the only wakeup events are connect/disconnect is wrong, and > > if CONFIG_USB_SUSPEND is set and remote wakeup is enabled on the devices > > then we may see these other events. > > Not without selective suspend enabled first, was my point; > so we're not disagreeing on anything except terminology > we've already agreed is confusing (This was all off-list, > but I distinctly recall you being keen on the fact that > in "global suspend" the ports weren't selectively suspended. > Hence the result that only connect/disconnect could wakeup.) More accurately, during "global suspend" the ports retain their selectively-suspended status. If they were selectively suspended before the global suspend then they still are selectively suspended during it and afterward, if not then they don't become selectively suspended as a result of the global suspend. However, a root hub port in either state can receive wakeup requests during global suspend. And a suspended device (hub or otherwise) can generate remote-wakeup requests if they are enabled, regardless of whether its parent port was selectively suspended or the entire bus is in global suspend. The fact that in practice we won't enable remote-wakeup generation until the parent port is selectively suspended is kind of a side issue. (A very minor one, considering that your implementation doesn't do a global suspend _until_ all connected ports have been selectively suspended.) Are we agreeing yet? :-) > PME# is what gets raised by devices that are in D1, D2, or D3 state; > they can't raise regular IRQs, by definition of those non-D0 states. > > That is, the difference is that PCI-suspended devices can't issue > normal IRQs. Or do DMA, and only config space registers are visible > so the virtual root hub timer can't poll any more ... all of which > can be done when just the root hub suspends. Hence the driver will need to know when the whole device is suspended so that it can fail attempts to examine the controller registers via procfs or sysfs. In fact some sort of locking will be needed, probably root_hub->serialize. But the necessary information is available through root_hub->dev.power.power_state, right? > > Look, suppose the root hub is suspended. Maybe other things are too, in > > fact, maybe the whole system is asleep. It doesn't matter for my > > purposes. One way or another, the controller issues a resume-detected > > interrupt, either because a connection was made or removed on the root hub > > or because some device raised a remote wakeup signal. If the entire > > system was asleep, maybe there was PME# signal sent first. However it > > happened, my driver has now received an interrupt. What should it do? > > You don't receive PME# as an IRQ, it's supposed to morph into a > pci resume() driver call. So it _does_ matter which path is in use. > (They can/should be independently debugged.) What happens is PME# causes the power management routines to issue the PCI resume() driver call. Then the controller, now in D0, issues its resume-detected IRQ and the driver must handle that. The driver resumes the root hub. What will resume all the devices beneath? Will the PCI/bus glue code take care of it as part of the PCI resume? > > It can resume the root hub. To do that it might need to know whether > > some of the controller's registers need to be reinitialized -- buggy > > BIOSes have been known not to restore the proper values. Should the > > That would only be on the pci resume() path, as I understand it. Okay. > > which sort has occurred? Is this a good reason for keeping both pairs of > > suspend/resume callbacks in struct hc_driver? > > That's an orthogonal question. There are certainly going to be > two chunks of logic (one a superset of the other), one of which > is called from the bus glue and could eventually be moved out > of hc_driver ... likely when that structure itself gets cleaned > up, which seems more like 2.7 than anything else. You seem to be saying that there will indeed have to be two pairs of callbacks, although it's yet to be determined whether they will be in hc_driver or some other structure, right? Clearly the HCD _does_ need the PCI-level suspend/resume pair, so it can restore the device registers. PCI/bus glue can't do that for it. > > If we are resuming from a sufficiently deep sleep, do we need to reset the > > entire USB bus? For instance, in D3hot will the controller be able to > > provide power on the bus? If not, the driver would have to restart > > rather than resume. What about D3cold? > > Read the PCI PM spec, and I think you'll agree that D3hot will be > providing suspend current to all devices (using vAux) and D3cold > won't ... How will the HCD know whether it is resuming from D3hot vs. D3cold? In one case a USB global bus reset isn't needed, in the other it is. > > Once the root hub has been resumed, what about the rest of the device > > tree? Whose responsibility is it to wake that up -- whoever put it to > > sleep originally? If the user suspends the root hub via sysfs, that will > > automatically suspend everything on the bus; do we then want to arrange > > things so that when the user resumes the root hub everything else remains > > suspended? > > I'm thinking it'd be wrong to make root hubs resume any differently > than any other kind of hub, at that level. So: resume everything. If the whole system is woken up (from suspend-to-ram, for example), does the PM layer take care of resuming every device, not just the one that caused the wakeup? If yes, presumably it won't hurt that the USB code will already have resumed every USB device... Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
