On Mon, 22 Nov 2004, David Brownell wrote: > > For purposes of discussion, let's say that state (1) is independent of > > whether the clocks are running. A driver might subdivide (1) into various > > substates depending on which clocks are disabled, and it would naturally > > try to save as much power as possible. > > It's not independent though. If the schedule is executing, > the clocks must be running.
Yes, but when the schedule isn't executing -- state (1) -- many of the clocks can run or stop, it doesn't matter. > > > > and root_hub->state is set to USB_STATE_SUSPENDED. > > > > > > Even if the kernel doesn't support that state for any other device?? > > > > Even if. Root hubs are special, after all. > > I don't like the idea of anything being sufficiently "special" > as to redefine the semantics of a state. Let's avoid that path. I would be happy to make it not be special by allowing any device to be in USB_STATE_SUSPENDED, even when CONFIG_USB_SUSPEND is not set. The difference being that when CONFIG_USB_SUSPEND is off, the only way for a device to enter the state is for the PM core to suspend the root hub (and hence the entire bus). > > If a controller is > > unable to generate an IRQ when a port event occurs, the driver should > > indicate this by clearing the can_wakeup flag. But if the driver doesn't > > mind the power usage, it can use polling instead... > > My point is that the driver may have no choice about it. The hardware > can limit driver options ... the driver must cope with that. Exactly. If the hardware allows using IRQs for port events, then great. If not, but it allows polling, then the HCD can use polling if it wants. Otherwise, if the hardware doesn't provide any resume request capability, the HCD must clear the can_resume flag (not the can_wakeup flag; I mixed the two of them up, sorry). > > Agreed. I mentioned PME# above simply because it's the mechanism I'm > > familiar with, but others would work just as well. In states (2) and (3) > > the root hub does act just like any other suspended hub. Note also that > > in state (3), polling for port events is likely to be impossible; that's > > part of the reason for insisting that resume requests be sent via > > interrupts. > > Actually (3) acts like "any other hub" **only** in systems that > will re-activate the HC ... which for current Linux and PCI > systems, means only as part of a system-wide sleep state. > (Until ACPI and PCI get more education.) Yeah, this entire discussion is aimed at how things _should_ work, not limited by failings in how they currently _do_ work. Note however that even in situations where the HC is not re-activated, the root hub still acts like "any other hub" -- since _no_ hub can be re-activated if the HC remains suspended! > Which is why, for now, autosuspend can't do more than (2). Agreed. At some point it may be possible to add autosuspend for HC's, but for now we have to be content with autosuspend of root hubs. > > There's an implementation issue here. Last I looked, OHCI did parts of > > (2) all by itself without going through usb_suspend_device. I believe > > this is a wrong approach, as discussed below. At best it implies some > > code duplication. > > The code duplication was inherent in having CONFIG_USB_SUSPEND be > a compile time option, last I looked. And it was just a handful > of lines at best; everything else involved state that wasn't > directly visible to upper level code. But it can lead to other problems. For example, suppose we agree that usb_suspend_device should change every device on the bus to USB_STATE_SUSPENDED when the root hub suspends and CONFIG_USB_SUSPEND isn't set. Your way, it would be necessary to change the OHCI driver as well as usb_suspend_device. > > Well yes, that's why I said that FREEZE for the HC device will do nothing. > > DMA will have been shut off when FREEZE was sent to the root hub. IRQs > > and wakeups are not currently required to be off during FREEZE (the only > > IRQs a device should raise when it is frozen are resume requests). > > That's not clear to me. In what sense is it "frozen" if it's handling > that sort of request? I didn't say it was "handling" resume requests, I said it could "raise" them. It's still frozen in the sense that it's not actively doing anything important (transmitting URBs) and it's not autonomously accessing system memory (DMA). When the swsusp code disables interrupts in order to take a coherent snapshot, it won't matter if resume IRQs are pending. (But it _will_ matter later on, after the snapshot is ready when interrupts are re-enabled... I still don't know what Ben and Pavel plan to do about that.) > > can_resume means that there is a mechanism in place for receiving and > > acting on resume events. > > It's actually a proposal you've made, which I'm trying to > make sense of. If it can't issue resume events, it can't > properly suspend. That's not true at all. Lots of devices can suspend just fine without being able to issue resume events. Even lots of USB devices. I think you once said you have some USB mice like that... :-) What _is_ true is that we don't want to autosuspend an input device that can't issue resume events, because autosuspend is meant to be transparent -- devices should autoresume on demand. Of course, for devices that don't spontaneously generate input (like mass-storage devices) it doesn't matter whether resume requests are supported since the "demand" is entirely on the host side. > If the hardware doesn't support IRQ-style notification, that's > it's problem, not software's. Timer polling isn't enough to keep > the CPU out of C3; and on the OMAP processors I used in a previous > example, the hardware doesn't have that limitation (thus software > doesn't need to work around it, the system can enter "deep sleep" > opportunistically). Okay, good. So on those systems it makes sense for the HCD to use polling for port events. > > What exactly do you want USB_STATE_SUSPENDED to mean? That the device > > actually _is_ suspended? This will be true automatically whenever the > > root hub is suspended, whether or not the device was suspended beforehand. > > I want it to mean that the basic rules about the USB suspend state > have been followed. Those rules include suspending child devices > in the same way an external hub would. > > (Yes, I do consider USB PM without CONFIG_USB_SUSPEND to be borked, > which is why I'd rather not spend time trying to make that config > be any more than a temporary stopping point.) I feel the same way. Note that as things stand, without CONFIG_USB_SUSPEND we don't use USB_STATE_SUSPENDED _at all_. So there doesn't seem to be anything wrong with giving it a special-purpose meaning appropriate to those borked circumstances. > > My goal here is to have the HCD's root hub autosuspend code work the same > > as much as possible, regardless of whether CONFIG_USB_SUSPEND is set. > > This part of the discussion considers how that can best be done. Maybe > > some of the work can be moved up into the hcd "glue" layer... > > Maybe, but again: I want to achieve that "regardless ..." by > getting rid of that config option and its multiple modes for > HCDs and usbcore. Then are you saying that we should concentrate entirely on the CONFIG_USB_SUSPEND case, and make all changes to the drivers in such a way that their behavior when the option isn't set remains exactly the same as it is now? I'm okay with that, although it will make the code a little awkward temporarily. > > I disagree; we should use the core mechanism (usb_suspend_device) whenever > > possible. Remember, most of the time root-hub autosuspend will be under > > control of the hub driver and will naturally work through the core. > > Again, I don't see that. Maybe if I saw an implementation of > "normal hub autosuspend", it'd be clearer how root hubs need > to play with that logic. Good point; I'll post a patch when I get a chance to write it. It should end up being pretty simple. Alan Stern ------------------------------------------------------- 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
