Re: Re: PowerOP 2/3: Intel Centrino support

Todd Poynor
2005-08-10T23:37:36Z

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