On Tuesday 23 November 2004 13:56, Alan Stern wrote: > 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.
So long as SOF tokens are being generated, at least that clock is needed: a frame clock to make sure the bits are transmitted correctly, and a frame counter that updates regularly. So normally a 48MHz clock. > > > > > 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). That might be an useful intermediate step ... suspend() and resume() calls would be made. The thing that would necessarily be different is handling wakeup events ... they can't be issued without a real suspend state. > > > 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. OK, I'm glad we can agree on that way of looking at things; it should help define HCD responsibilities better. (And I'm still expecting usbcore to change so the HCD can control whether it's polled by usbcore, or the HCD can just issue "status changed" calls. Simple patch.) > 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). I'm still assuming there's no can_resume flag... All USB hubs that can put ports into the USB suspend state must be able to report resume signaling from the downstream devices; I think we shouldn't worry about ports not reporting it. The root hub code could just fail requests to suspend those ports. > > > 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! By design ... :) > > 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. Right, that "bottum up autosuspend" mechanisms will take a while to percolate through the entire system. > > > 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. Nope. How could a port be suspended without the device being in USB_STATE_SUSPENDED? So if autosuspend ever kicks in, it's by definition safe: either no devices on that root hub, or only devices which have already suspended. > > > 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). Remember, DMA isn't the point ... it's issuing non-SOF transations over USB. Or so you said earlier! > 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.) Or wakeup events. The IRQs would have been handled, but the OS may not have started processing the "resume event" that was delivered by that IRQ. > > > 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... :-) We were talking about hub ports, not devices ... if you're talking about devices, then the relevant flag is "can_wakeup" (as in that original patch of mine). > What _is_ true is that we don't want to autosuspend an input device that > can't issue resume events, As reported in the "can_wakeup" flag, added to the driver model by that one patch. > 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. Exactly! > 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. Yes, that's the way I'd like to work these issues through. I suspect you underestimate how awkward it'd be to expect every driver to operate in two different modes, much less even understand how they differ ... much simpler IMO to just point all the penguins in one direction at a time! :) - 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
