Dave Jones wrote: > I'm glad I'm not the only one who feels he's too dumb to see > the advantages of this. The added complexity to expose something > that in all cases, we actually don't want to expose seems a little > pointless to me. > > For example, most of the x86 drivers, if you set a speed, and then > start fiddling with the voltage, you can pretty much guarantee > you'll crash within the next few seconds. They have to match, > or at the least, be within a very small margin. I've attempted to extoll the benefits of adding these interfaces in previous emails, and if after that it still seems mystifying why anybody would want to do this then I'll take the heat for doing a lousy job of extolling. I've also admitted that it is primarily of use in embedded-specific hardware, and of less use in x86 and in desktop/server usage for various reasons (unless it turns out there's some fantastic savings to be had in modifying common x86 bus speeds independently of cpu speed, which seems unlikely). In the case of x86, undervolting is in practice by some folks, but yes it is risky and support for it in the basic interfaces probably shouldn't be a high priority. > Given how long its taken us to get sane userspace parts for cpufreq, > I'm loathe to changing the interfaces yet again unless there's > a clear advantage to doing so, as it'll take at least another 12 months > for userspace to catch up. Just to be clear, there are no cpufreq userspace interface changes required by this, it simply occupies the bottom layer of code that modifies platform power registers etc. The same speed/policy/governor etc. interfaces are used to specify the cpu speed. Interfaces to the power parameters can optionally be used for diagnostic purposes, and in the near future I'll propose alternative interfaces for setting entire operating points, but the existing cpufreq interfaces will work just fine regardless. -- Todd
