On Saturday 23 October 2004 09:51, Alan Stern wrote: > On Fri, 22 Oct 2004, David Brownell wrote: > > > So long as it doesn't get in the way of me finishing basic integration > > of USB_SUSPEND and system suspend, I'm all for it! > > It shouldn't interfere. Although it will need to be updated when your > wakeup_supported/enabled stuff gets added to the driver model structures.
Call me paranoid ... the hub driver is in usbcore, right between the HCDs (which don't all handle the necessary suspend transitions right yet) and the PM core (which doesn't do so either). So while I agree with "should", it seems far from "will" (not intefere)... We should deploy autosuspend in some other drivers first. Storage would be a good trial ... all the control goes from CPU to device, there are no status or wakeup events going the other direction. I'd be pleasantly surprised if autosuspend there turned up no problems... > > Thing is, I think EHCI will be able to do that as easily as OHCI can. > > So no _need_ for usbcore to be involved ... except for external hubs. > > It isn't as simple as that. There's a real benefit from having all the > autosuspend logic funnel through a single place (the hub driver). If the > HCDs do their own independent autosuspending in addition, the potential > for confusion increases greatly. Remember, the standard suspend pathway > will be present whenever CONFIG_USB_SUSPEND is set. I was describing a suspend mechanism that's orthogonal to USB_SUSPEND, so it kicks in with just CONFIG_PM. > Furthermore, we may be talking about two slightly different things. The > new autosuspend I'm proposing would work through usb_suspend_device(), > which means changing the hub's state to USB_STATE_SUSPENDED plus doing all > the stuff that goes with it. You can't do this in interrupt context. I certainly see the state as SUSPENDED ... also, it's not "interrupt context" unless by that you include irqs blocked and the HC's spinlock held; because that's the only place an HCD can really establish that it's "free" to turn things off. (As in, it boils down to one register write.) As soon as the HCD drops the spinlock, events can arrive which make it stop being "free". One advantage of doing this in the HCDs is elimination of failure modes ... and failure modes are bad, because it handling them always involves rarely-executed and hard-to-maintain code. > What you're doing in OHCI is probably a lot like what UHCI does. It > doesn't interact cleanly with the standard USB device suspend code and > it's complicated by the need to maintain a state machine so that the > necessary actions (and their multi-millisecond delays) can be handled > in_interrupt. OHCI won't autosuspend if any delay is needed. From what little I know of UHCI, it could do about the same thing. See the CONFIG_PM bit at the end of ohci_hub_status_data() ... it's really simple. > When a suspended external hub gets a port status change, it has to send a > wakeup signal from its upstream port. (I think if the status change was a > wakeup request then it also has to echo a resume signal out the downstream > ports but I forget the details.) All external hubs are required to have > this capability. > > When a suspended root hub gets a port status change, it has to send a > wakeup message upstream to the CPU. This message will take the form of a > normal IRQ if the host controller isn't also suspended, otherwise it will > take some alternate form (like asserting PME#). Yes, some controllers > aren't wired to send an alternate signal. > > But on a few systems the UHCI controller can't send either sort of signal, > IRQ or PME#. That is, it can issue an interrupt request but not in > response to a port status change if the root hub is suspended (there's no > problem if the root hub is active or "half-suspended"). For these broken > systems it makes sense to say the root hub doesn't support wakeup. Another way to say this is that it's possible to look at suspending any hub (root or external) in two parts: downstream links, and upstream ones. And that while most hubs use standard mechanisms, like IN-interrupt transfers or IRQs, to pass resume (and wakeup) events upstream, on some boards UHCI root hubs need an alternate implementation ... all the USB events behave, but the PCI ones are less functional than may be desired. I'm thinking that's another argument in favor of usbcore ensuring that HCDs can implement root hub suspend directly ... whatever we decide that means, and with some way we can (regresssion) test them so we know they all act compatibly. > > > ... > > > > I describe that differently: the root hub itself is fully suspended. > > The frame clock might not even be running. Nothing goes on > > downstream of that hub, nothing. > > My use of terms isn't the same as yours, although I agree in substance. > I say that the root hub isn't suspended because it can receive and reply > to URBs and because root_hub->state is USB_STATE_CONFIGURED, not > USB_STATE_SUSPENDED. In other words, as far as usbcore is concerned the > root hub isn't suspended. (And as far as the hardware is concerned the > root hub isn't running.) That is, you're agreeing with me ... OHCI root hub state *is* SUSPENDED. We probably look at the upstream link a bit differently though, since you're thinking of UHCI hubs where the root hub timer needs to poll the registers, so that port change events get reported ... so it can't be SUSPENDED. > > Erm, it won't involve _any_ kind of "wakeup" from a system sleep > > state: the CPU is getting scheduled, so there's no sleep state! > > "Wakeup" can refer to waking the CPU from a system sleep state, but it can > also refer to resuming a suspended device. I'm trying to use "wakeup" mainly to refer to system events, and "resume" for the USB events. So "resume" doesn't imply "wakeup", and we can say "root hub resumes" without any assumptions about the previous system state. > Of course, with a > "half-suspended" root hub neither kind of wakeup is needed! For now, it looks like that "half suspended" state will be mostly UHCI-specific. Most OHCI boards don't seem to need it, though I certainly expect some of the external transceiver arrangements (mostly on embeded boards) will add up to the same thing. > > Hmm ... other than not working for external hubs, or through a > > settable timer, how does the current OHCI behavior differ from > > what you're describing? > > I'm not familiar with all the details of the OHCI behavior, but here > goes... > > The transitions are transparent to the hub driver rather than > controlled by it; That shouldn't matter; the hub driver should handles all suspended hubs in the same way, regardless of whether they were suspended by HCD, syfs, hub driver, or gremlin intervention. > The transitions take place in interrupt context rather than in > process context; This state transition requires mutual exclusion for the root hub, which basically means spin_lock_irqsave() regardless. > The transitions take place independently of any other autosuspend > code in the hub driver (which would naturally apply to root hubs > as well as to external hubs); So far as root hubs go, I don't buy this. It sounds like it ought to be right, but the facts that I see don't back it up. > The transitions take place independently of the driver model's > conception of the root hub's state; Actually I think I'm going to end up proposing that the driver model have no notion of any device's power state. That's the root cause of much bogosity. > If an OHCI controller is autosuspended with a suspended child, > does the driver wake the controller up when a someone wants > to resume the child? That's something the resume logic should handle, not the HCD. - Dave > Alan Stern > > ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
