On Tue, 23 Nov 2004, David Brownell wrote:
> 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 ...)
Like I said above, this is a state not recognized by the PM core. If a
device is operational (albeit perhaps with lower performance and lower
power usage), the PM core doesn't need to know anything more. Details of
the operating state are internal to the driver. That's how the current
design works.
When you think about it, this makes sense. After all, the PM core can't
be aware of all the myriad details of the internal workings of every kind
of device. We've been saying all along that this sort of knowledge has to
be pushed out to the drivers.
> > > 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. :)
This is certainly the wrong place to ask this, but...
Doesn't that approach cause problems when timeouts of a specific length
are needed? Suppose VST is in effect and there haven't been any timer
interrupts for the last 10 ms. Jiffies still has the value it had 10 ms
ago. Now somebody asks for a 5 ms timeout. Adding the timer causes VST
to be turned off, jiffies is immediately updated to the correct value, and
bingo! -- 10 ms go by in a flash. What happens to the 5 ms timeout?
Alan Stern
