ACPI P-State platform limit [Was: Re: Cpufreq for opteron]

[Dominik Brodowski <linux@brodo.de>]

[removed CC:linux-kernel]

> > I dislike this interaction between ACPI and cpufreq -- it 
> > should be done
> > more generally. Let's discuss that seperately, though. And if 
> > the code is
> > dead code at the moment.
> 
> The dead code has been removed in 1.00.07 of the driver. I am
> happy to receive suggestions as to better ways of detecting battery
> versus mains power transitions.

Currently, the ACPI P-States cpufreq driver does implement the "platform
limit". However, I'm not really excited about how it works -- and especially
that it only works with the ACPI P-States cpufreq driver and not with all
drivers.

[ A preliminary questions to the AMD people out here: Is the information in 
the _PSS of any usage for the powernow-k{7,8} driver? ]

The platform limit [ _PPC ] refers to the states defined in _PSS. This means
that this knowledge can and should be used independent of the cpufreq driver:
if the _PPC is, let's say, 2, and accoring to _PSS P2 is 1.2 GHz, a
"platform limit CPUFREQ_POLICY_NOTIFIER". If the _PPC changes, a
new cpufreq_reevaluate() function should be called:

/* cpufreq_reevaluate() - called by policy notifiers if their demands change
 * @cpu - affected CPU (nr).
 *
 * Certain cpufreq policy notifiers have demands which change over time, for
 * example a different ACPI platform limit aftern an docking/undocking event,
 * or a dangerously high temperature. When such a demand changes,
 * cpufreq_reevaluate() shall be called. This function will then try to set
 * the existing ->min, ->max and ->policy or ->governor combination, and in
 * this process all policy notifiers are called as usual.
 *
 * NOTE #1: this function might_sleep().
 */

cpufreq_reevluate(unsigned int cpu)
{
	cpufreq_policy * data = cpufreq_cpu_get(cpu);

	if (!data)
		return -EINVAL;

	cpufreq_set_policy(data);

	cpufreq_cpu_put(cpu);
}


Comments?

	Dominik