On Monday 15 November 2004 09:17, Alan Stern wrote:
> On Mon, 15 Nov 2004, David Brownell wrote:
>
> > But that gets us back to FREEZE being orthogonal to power saving
> > modes: drivers could be { full power, FROZEN } during some sleep
> > state transitions, or { low power, THAWED } during routine operation
> > to save power.
>
> The current PM setup doesn't recognize "low power" as such.
Only indirectly, as a consequence of entering certain system-wide
sleep states. Drivers see PM_SUSPEND_STANDBY, or PM_SUSPEND_MEM,
and can switch to any of the device power states that's compatible
with that system sleep state. Maybe "all fans off" for example.
> There's just
> frozen and suspended (which implies frozen). I don't think anything's
> wrong with that; wouldn't a device in a low-power mode to save power
> during routine operation also be frozen?
No; as I said, "{ low power, THAWED } during routine operation".
USB root hubs should be able to autosuspend and disable clocks, for
one example, and be fully functional. If there's some non-suspended
device, they'll be in higher power mode. (OHCI does that right now
though on some systems it leaves more clocks running than might be
strictly desired. One step at a time ...)
> What we do need is a way to specify whether autoresume is enabled. This
> concept is closely tied in with remote wakeup. I'm tempted to say they
> can be treated as the same thing, but that's not necessarily so: There may
> be devices (like the Genesys host controller) that are capable of remote
> wakeup but not capable of resume signalling.
As discussed separately, the better way to look at that is
that if the root hub hardware does not generate such events,
software polling will do the trick. In both cases the hub
generates wakeup events ... and in both cases it'll be after
the device (not the root hub!) generated resume signaling
on that USB port.
The reason this can be confusing is that so many different
terms are used to address the same basic mechanism: a device
issues USB resume signaling, parent hub responds. The response
is always a "wakeup" event, and it really must not matter whether
it's generated by a timer IRQ, a root hub IRQ, a normal status
transfer from an external hub (HC data transfer IRQ), or a
system wake event like PME#. Those four event mechanisms
(and more?) are sometimes given different labels, hiding their
common nature.
> > This was in conjunction with a "Variable Scheduling Timeout" (VST)
> > patch, so the timer precision is still 1/HZ but the interrupt
> > rate is less ... if the next scheduled timeout is 1 second in
> > the future, the timer IRQ wouldn't fire until then. The S/390
> > folk contributed some infrastructure a while back that makes
> > VST trivial. The basic deal is that CPU can stay in the idle
> > "loop" a lot longer.
>
> How does jiffies get updated when VST is in effect and no timeouts are
> scheduled for a while?
Darn if I didn't just see a patch flow by on LKML to make
sure that, "jiffies" gets updated from the hardware real
time clock after resume ... "xtime" too. That's how; though
maybe that patch didn't address VST. :)
Or failing that, "hwclock --systohc", an old workaround
I remember from APM days. Always seemed like a bug to
me that userspace ever saw such stuff.
- Dave
