On Wed, 28 Aug 2002, Dominik Brodowski wrote:
>
> #3 Then the cpufreq driver is called to actually set the CPU frequency.
>
> #3 is absolutely ready
#3 is _not_ ready, if it doesn't include a "policy" part in addition to
the frequency. That was what I started off talking about: on some CPU's
you absolutely do _not_ want to set a hard frequency, you want to tell the
CPU how to behave (possibly together with a frequency _range_).
Until that is done, no other upper layers can use this low-level
functionality, since all upper layers would be forced to come up with a
hard frequency goal.
THAT is the problem. If you want to build infrastructure for upper layers,
then that infrastructure has to be able to pass down sufficient
information from those upper layers.
Think of this as a driver abstraction layer. Some hardware will do more
for you, some will do less. Some hardware is the equivalent of a dumb
frame buffer (where software has to change frequency and voltage by hand,
and be careful about every single step and the delays in between), while
some other hardware contains internal accelerators where you just tell
them what you want, and the hardware will do it for you asynchronously.
The current abstraction layer _thinks_ that all hardware is stupid, and is
thus not actually usable with smart hardware. See?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:24 EST