> > #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.
So... would you take a patch that passed range down to cpufreq "core"?
Dumb cpus would set speed to upper limit while smart cpus would get all
the info...
Pavel
-- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.- 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/