Russ Nelson writes:
> ebunce@lhsl.com writes:
> > A generalized hooking mechanism should probably be added to scale.c so
that
> > other drivers that need to adjust timing parameters can do so,
including
> > PCMCIA and video drivers.
>
> I'm more interested in *under*clocking the iPAQ. There's no reason I
> can see to run the processor any faster than it has to run.
The scale module does definitely support underclocking, excepting the
problem when going down to 59 MHz on the iPAQ. In fact I frequently run
mine with the speed set down to 73.7 MHz, but I experience unpleasant
behaviours if I try to use certain devices while at that speed, hence my
statement that you quoted.
For standard PIM/PDA applications there may not be the need for
*over*clocking, in fact it's very useful to drop the speed to save battery
life if that's all you doing.
But even that requires adjusting OS and driver timing parameters. Hence
why I added the recalculation of the global loops_per_sec value (a call to
delay doesn't last 3-4 times longer than it's supposed to).
As far as needing speed, some tasks actually do make you want to up the
speed. If you try to do certain types of speech recognition while playing
an MP3 (through a pair of headphones) at the same time, then you begin to
feel the urge to up the clock speed. a little... Also for graphics in
games, it can also definitely be wanted/needed (there's no graphics
accelerator in the iPAQ). But the point isn't whether {under/over}clocking
is necessary, it's that if you change the clock speed, certain timing
information calculated by various drivers will no longer be accurate, and
therefore one can experience undesirable behavior.
Erik
Received on Fri Oct 13 16:06:37 2000
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:43:44 EDT