On Friday 26 November 2004 13:01, Alan Stern wrote: > > Okay, fine. My original point still stands: If wakeup_enabled isn't set > then the generic hub autosuspend code won't suspend a hub. A root hub can > do whatever the HCD likes under such circumstances, but I still think it > should do its best to mimic the behavior of a real hub when the > REMOTE_WAKEUP feature is clear.
I'd agree that if HCDs do things like autosuspending, that shouldn't be something to affect khubd ... though I'm not sure I'd expect the "hub" and HCD "root hub" driver autosuspend results to differ much. I think it's really worth thinking of HCDs as combining two distinct device drivers. One of the drivers is for the upstream bus (PCI, an SOC bus, or wire-it-yourself); the other is the root hub. Certainly that helps with OHCI, and EHCI too, though I suspect not many other standardized register APIs will appear for USB. (Plus there's the vowel shortage. [AEOU]HCI are taken, leaving only IHCI and YHCI. :) > > > > I've called what OHCI does now "autosuspend", which expects IRQs > > > > to work (and tolerates root hub timer polling) ... usbcore has > > > > no need to care about that state. > > > > > > Maybe you should call it something else, > > > > That's a generic term though; I'd call lots of things > > "autosuspend". Calling it something else wouldn't > > change the fact that OHCI calls that state "suspended", > > without reference to the Linux PM framework, and that > > the driver automatically puts the hardware into that > > state whenever it makes sense. > > > > > > ... > > > > Would you be happier to talk about different > > mechanisms like "controller autosuspend" (what > > OHCI does) versus "hub autosuspend" (does those > > other things too)? The HCD hub_suspend() method > > doesn't change anything except HC registers, so > > it's for "controller suspend". > > Well, if you can dislike the USB spec's use of "global suspend" > then I can dislike the OHCI spec's usage. :-) Sure! Thought they aren't quite comparable. "Suspend" is a very generic term, and any layer attempting to redefine it in conflict with other layers is asking for trouble. No layer has a reasonable claim to owning a generic term like "suspend" more than any other layer. (Which is part of why I dislike that usage of "global". It's also not even global in the context of USB. It's not widely used in describing host controller chips either, so I must not be alone in disliking the term.) > I also dislike using "controller autosuspend" for this; it sounds too much > like the HC has been put into a PCI reduced-power state (which if I > understand you correctly is _not_ what happens). The HC is certainly in a reduced power state. Think of it this way: there may be half a dozen things the HCD can do to save power, with a PCI-specific "enter a non-D0 state" as the very last one possible (and only with PCI). It might not even be the most important one; consider that C3 example, where stopping the periodic DMA can save 2W power ... vs an idle HC in D0 at ~1/4 W on a not-hugely-efficient chip. It _could_ be what happens even with PCI, on systems where Linux PCI has been tought better ways to use PME#. > I don't have good suggestions for better terminology. There are too many > distinct but similar concepts: Which is when I've found the only really workable solution involves carefully providing adjectives to go along with the generic terms like "suspend". > (a) USB device is physically suspended (upstream ports receives no > packets, power usage is very low). This notion does not apply > to root hubs because they don't receive packets on a regular basis > from upstream. That's what I'd call the "USB Suspend" state. Root hubs actually do have analagous states, with downstream ports suspended just like other hubs ... just say that all USB links to/from the device are disconnected or suspended, and it should be safe to ignore that root hubs don't hav USB links "to" the device, just "from" it. > (b) Usbcore thinks a device is supended (udev->state == > USB_STATE_SUSPENDED and udev->driver->suspend() has been called). > Applies to root hubs as well as real devices, and for real > devices this implies (a) -- unless usbcore is broken! Right. This is "usbcore suspend", maybe. > > (c) Root hub is not transmitting packets. It may or may not allow > polling of registers and it may or may not have reduced power use; > these could be considered sub-divisions of (c). Actually, it's the root hub analogue of (a) in most cases... especially in the "can't access registers" case. (Though that part shouldn't matter to usbcore; it's not a USB notion.) And if it's not transmitting packets, it's clearly saving power already ... HCDs can combine a few more power saving modes. > (d) Host controller is in a PCI low-power mode. Only config-space > registers are accessible. Analogous notions apply to non-PCI > controllers. This implies some form of (c). This would apply exclusively to the upstream link to the root hub, yes? Does usbcore even need to know about this? (Other than re-usable PCI glue code, which isn't exactly a "core" function.) > If you can come up with good names for the (a) - (c) we can refer to (d) > as "HC is suspended". Maybe (a) could be a "physical suspend". I was thinking "USB suspend" for (a), with "root hub suspend" for its (c) variant, and "usbcore suspend" for (b). > Obviously these definitions overlap and a device may satisfy more than one > of them at a time. Also, I don't know exactly how the OHCI autosuspend > state fits into this classification. It's clearly the (c) variant of (a) ... it can't do any of the (b) usbcore suspend actions, unfortunately, since those can't be initiated from IRQ context. - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
