On Tuesday 09 November 2004 07:02, Alan Stern wrote:
> [Moved to linux-pm mailing list]
>
> On Mon, 8 Nov 2004, David Brownell wrote:
>
> > I've got to catch up on those linux-pm discussions (I was doing
> > some PM work instead of discussing it :) ... but last time I
> > checked in, I didn't like the way "frozen" was getting addressed.
> >
> > It was looking more and more like a swsusp-specific state that's
> > just a workaround for not having selective resume for the device
> > on which the swsusp snapshot would be written out...
>
> That's not how I see it at all. FREEZE has no relation to selectively
> resuming the swap device, and in fact Pavel was pretty much opposed to
> doing that kind of selective resume. Rather it's a way to separate out
> the two different requirements needed for power management: telling a
> driver to idle its device (FREEZE) and telling a driver to change the
> device's power level (SUSPEND).
It's somewhat like the difference between the behavior
of a USB HCD with and without CONFIG_USB_SUSPEND. For
simplicity's sake, this assumes a root hub without any
USB devices attached:
- With USB_SUSPEND, the root hub's USB suspend logic will
always (!) have been called before the PCI suspend call
gets issued.
* Suspending the hub interface's device might just
shut off the virtual root hub timer (if that
board even needs that!). This is a FROZEN state
for that function, regardless of anything else.
* After that interface suspends, so must the root hub
device itself. Though for hubs that autosuspended,
this might have nothing left to do! This hub can
probably issue wakeup events by IRQ, even though
in terms of at least DMA it's also FROZEN.
(Also HCD_STATE_SUSPENDED.)
* So when the PCI device suspend gets called, all it
needs to do is shutdown PCI access ... which, if
the controller supports PCI PM, includes setting
it to a low power PCI state like D1 or D3hot, and
maybe enabling PCI PME# wakeup (For non-PCI devices,
bus glue duties are much the same.)
- Otherwise (without USB_SUSPEND or autosuspend), we
currently only have PCI and root hub suspend logic.
* Whoops, that means root hub timers never stop
without USB_SUSPEND! That prevents some systems
from reaching lower power states ... it came up
recently with some OMAP timer patches. If timers
are constantly firing, automatic entry into deeper
sleep states (think S1) can't kick it. Kicking
those states in gave about an 8% power saving in
one simple test ... a one-day battery life going
up by almost another two hours (significant).
* Hmm, both OHCI and EHCI have hcd->hub_suspend()
calls, but UHCI doesn't -- just the PCI stuff.
That's not necessarily an issue, since there
probably aren't many non-PCI versions of UHCI,
but it's an issue we should remember.
At least for OHCI it's quite clear how to divvy up tasks
between root->suspend() and controller->suspend() ...
the root hub gets everything that's portable, the bus glue
gets the rest. EHCI can work mostly the same.
We'll be much better off when both PM and USB cores work well
enough that we just equate USB_SUSPEND with normal CONFIG_PM
logic. Otherwise we have _way_ too many code paths to test!
> > > Exactly. Drivers should stop everything whenever their interface is
> > > frozen. Only usbcore should worry about actually changing power levels
> > > during a SUSPEND call. (It may turn out, by coincidence, that a frozen
> > > device does end up getting suspended -- if the controller is UHCI for
> > > instance -- but that shouldn't affect anything.)
> >
> > Except it doesn't seem to me like it can be so neat,
> > especially given those examples where "frozen" is by
> > definition a power reduced state. (No audio out,
> > so the device disables all that circuitry...)
>
> That's just a harmless side effect. Unbinding an audio driver and setting
> the interface to altsetting 0 might do the same thing -- it's not relevant
> here. There's nothing wrong with a device using less power at certain
> times. What matters is that if the interface is frozen but the device
> isn't then the device really isn't suspended; you can send URBs to it,
> change its state, and so on.
I don't quite follow. If Apples are Red, then Oranges aren't?
Interfaces aren't devices, they don't couple that way; and I
wasn't talking about unbinding, or suggesting any kind of
new relationship between suspending devices and suspending
interfaces. (They're in the driver model tree, so interfaces
suspend before their device.)
> > The last notion that made sense to me was having
> > "frozen" just be another suspend state ... one that
> > places even fewer constraints than system-S1 does.
>
> Don't confuse driver states with device states. FREEZE is primarily a
> driver notion whereas SUSPEND is definitely a device state (although
> it implies FREEZE, of course).
But see the example I gave above, with root hubs. There
are three driver model devices: hub interface, hub device,
and controller. All have drivers. FREEZE and SUSPEND would
of necessity apply to each device, and thus to each driver!
And there don't seem to be any generally useful behavioral
distinctions between those states. That's maybe most visible
for the devices that don't directly map to hardware ... like
the interface devices in USB, or network class devices.
- Dave
