On Wednesday 24 November 2004 08:17, Alan Stern wrote:
> On Tue, 23 Nov 2004, David Brownell wrote:
>
> > > 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.
But then you also said you thought "low power" implied "frozen",
and I provided a counterexample.
> 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.
Actually no it doesn't ... there's dev->power.power_state thing,
in the current design, which is there to record power state.
But we seem agreed that it should vanish ...
> 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.
... so that the pmcore (or perhaps more specifically its sysfs glue?)
can't try to pretend that it's aware of _any_ such internal workings.
> > > > 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.
(Where "loop" is in scare-quotes because it'd actually be one
of the CPU low power idle modes, probably more aggressive than
just a "halt".)
> > > 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?
I don't quite follow all the details about timer updating, and
that VST stuff isn't fully cooked anyway. That said: "somebody"
would have to be in an IRQ handler. (Not a scheduled task, else
the scheduling timer would run normally...) Since the system
would effectively have been woken from a kind of suspend state
by that IRQ, I suspect updating "jiffies" would need to be done
before responding to that IRQ.
- Dave
> Alan Stern
>
>
