On 8/1/06, david singleton <dsingleton at 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
