* Re: ACPI / CPUFREQ.
2004-08-03 15:41 ` Len Brown
@ 2004-08-03 20:51 ` Dominik Brodowski
0 siblings, 0 replies; 3+ messages in thread
From: Dominik Brodowski @ 2004-08-03 20:51 UTC (permalink / raw)
To: Len Brown; +Cc: Dave Jones, cpufreq@www.linux.org.uk
On Tue, Aug 03, 2004 at 11:41:28AM -0400, Len Brown wrote:
> On Tue, 2004-08-03 at 11:10, Dave Jones wrote:
> > 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.
>
> 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.
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.
> 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.
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
^ permalink raw reply [flat|nested] 3+ messages in thread