ACPI / CPUFREQ.

At his ACPI talk at OLS, Len mentioned that it would be beneficial to have ACPI and CPUFREQ working together a little better.

Len, care to kick off some thoughts on what pieces you had in mind ?

The biggest problem is probably ACPI thinking the CPU should be at a certain P-state whilst the user has forced it to another with cpufreq.

Dave

I think there are 2 major issues.

1. confusion about best driver to use
this, of course, should be automatic
and should not depend on if the drivers
are built-in or modules.

2. no coordination between P-states
and T-states. ACPI currently kicks
in throttling upon high temperature conditions, but it doesn't make sense to use throttling unless we're already in the most power-conserving P-state available.

-Len

AFAICS, p4-clockmod should be considered to be removed and put into a "pending" state on some external website until a "two-cpufreq-drivers-at-a-time,one-throttling,one-scaling-driver" implementation is merged.

Other than that, only speedstep-centrino.c and acpi.c, the latter of which should be renamed IMHO to something like cpufreq-acpi-io.c, are in some sort of "conflict". A good startup-script, as well as recommending to use modules for cpufreq drivers, should solve this issue completely. Also, more extensive Documentation would help.

AFAICS, this is already done in drivers/acpi/processor.c:

in acpi_processor_set_thermal_limit():

	case ACPI_PROCESSOR_LIMIT_INCREMENT:
		/* if going up: P-states first, T-states later */

		result = acpi_thermal_cpufreq_increase(pr->id);

and acpi_thermal_cpufreq_increase() does reduce the CPU frequency up to 40% in 20%-steps [hardcoded], independent of the cpufreq driver used or whether there's even P-States data in the ACPI tables. IMO the limit of "40%" could be overriden if a cpufreq-driver is registered with the ACPI P-States library, or even decreased further. The code is there, though.

3.) No coordination between ACPI T-States and frequency scaling.

ACPI T-States should become a cpufreq-throttling-driver once the "allow-for-two-drivers" implemenation mentioned above is written, found to be sufficient and good, and merged.

Thanks,
Dominik