Re: PowerOp Design and working patch

Vitaly Wool
2006-08-01T12:23:38Z

On 8/1/06, david singleton <dsingleton@mvista.com> wrote:
> Actually in practice there aren't that many supported operating
> points, even on the hardware you and I are familiar with. I've yet
> to construct a case where there are more than 16 to 20
> operating points.

If there's no way for runtime OP creation, you'll have to specify ALL
the _valid_ OPs otherwise you'll be artificially narrowing the
applicability down. I hope that's clear.
And the number of theoretically possible (ie valid) OPs might well be
more than 100 - at least on some PXA boards, on PNX4008, on some
high-end ARMv6 ones etc.

> And the Linux device model allows the system to be set at
> a particular operating point and then suspending the LCD
> or unused USB if so desired. So the combination flexibility
> is still available.

I wasn't talking about that; I've constructed a (weird yet possible)
example that concerned only frequency/voltage changing, not turning
on/off the devices.

> If there were 600 supported operating points that would be a
> very good reason to use PowerOp. I'm not sure I'd want
> the user passing all the frequencies, voltages, clock
> divisor and clock multiplier for all those operating points.

Within the given use case for a particular board, given the
possibility of runtime OP creation, there shouldn't be any need to
specify ALL the OPs.

> > It looks to me that the concept that the kernel can implement
> > rules/restrictions for operating points but shouldn't define them with
> > possible exception for the most essential ones far better suits both
> > embedded and non-embedded use cases.
> CPUFREQ shows that it can, and I believe should, define the operating
> points the system supports. CPUFREQ does NOT let the user pass
> frequency or voltage values into the kernel. It shows the hardware
> vendor certified and validated frequencies and voltages.

Again, IMO you should specify what OPs are valid to be able to
validate runtime-created OPs, but you shouldn't limit OP creation
kernel-wise.

Vitaly