kernel/linux.git/drivers/acpi/processor_perflib.c, branch linux-2.6.22.y

[CPUFREQ] Remove deprecated /proc/acpi/processor/performance write support

2007-04-26T18:32:02+00:00

Remove deprecated /proc/acpi/processor/performance write support Writing to /proc/acpi/processor/xy/performance interferes with sysfs cpufreq interface. Also removes buggy cpufreq_set_policy exported symbol. Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones

ACPI: delete extra #defines in /drivers/acpi/ drivers

2007-02-13T04:50:52+00:00

Cosmetic only. Except in a single case, #define ACPI_*_DRIVER_NAME were invoked 0 or 1 times. Signed-off-by: Len Brown

ACPI: clean up ACPI_MODULE_NAME() use

2007-02-13T03:42:12+00:00

cosmetic only Make "module name" actually match the file name. Invoke with ';' as leaving it off confuses Lindent and gcc doesn't care. Fix indentation where Lindent did get confused. Signed-off-by: Len Brown

ACPICA: use new ACPI headers.

2007-02-03T02:14:28+00:00

Signed-off-by: Len Brown

ACPICA: minimal patch to integrate new tables into Linux

2007-02-03T02:14:22+00:00

Signed-off-by: Len Brown

[PATCH] ACPI: fix cpufreq regression

2007-01-26T21:50:58+00:00

Recently cpufreq support on my laptop (Lenovo T60) broke completely: when it's plugged into AC it would never go higher than 1 GHz - neither 1.3 GHz nor 1.83 GHz is possible - no matter which governor (userspace, speed or ondemand) is used. After some cpufreq debugging i tracked the regression back to the following (totally correct) bug-fix commit: commit 0916bd3ebb7cefdd0f432e8491abe24f4b5a101e Author: Dave Jones Date: Wed Nov 22 20:42:01 2006 -0500 [PATCH] Correct bound checking from the value returned from _PPC method. This bugfix, which makes other laptops work, made a previously hidden (BIOS) bug visible on my laptop. The bug is the following: if the _PPC (Performance Present Capabilities) optional ACPI object is queried /after/ bootup then the BIOS reports an incorrect value of '2'. My laptop (Lenovo T60) has the following performance states supported: 0: 1833000 1: 1333000 2: 1000000 Per ACPI specification, a _PPC value of '0' means that all 3 performance states are usable. A _PPC value of '1' means states 1 .. 2 are usable, a value of '2' means only state '2' (slowest) is usable. now, the _PPC object is optional, and it also comes with notification. Furthermore, when a CPU object is initialized, the _PPC object is initialized as well. So the following evaluation of the _PPC object is superfluous: [] acpi_processor_get_platform_limit+0xa1/0xaf [] acpi_processor_register_performance+0x3b9/0x3ef [] acpi_cpufreq_cpu_init+0xb7/0x596 [] cpufreq_add_dev+0x160/0x4a8 [] sysdev_driver_register+0x5a/0xa0 [] cpufreq_register_driver+0xb4/0x176 [] acpi_cpufreq_init+0xe5/0xeb [] init+0x14f/0x3dd And this is the point where my laptop's BIOS returns the incorrect value of '2'. Note that it has not sent any notification event, so the value is probably not really intentional (possibly spurious), and Windows likely doesnt query it after bootup either. Maybe the value is kept at '2' normally, and is only set to the real value when a true asynchronous event (such as AC plug event, battery switch, etc.) occurs. So i /think/ this is a grey area of the ACPI spec: per the letter of the spec the _PPC value only changes when notified, so there's no reason to query it after the system has booted up. So in my opinion the best (and most compatible) strategy would be to do the change below, and to not evaluate the _PPC object in the acpi_processor_get_performance_info() call, but only evaluate it if _PPC is present during CPU object init, or if it's notified during an asynchronous event. This change is more permissive than the previous logic, so it definitely shouldnt break any existing system. This also happens to fix my laptop, which is merrily chugging along at 1.83 GHz now. Yay! Signed-off-by: Ingo Molnar Cc: Dave Jones Acked-by: Len Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

ACPI: delete two spurious ACPI messages

2007-01-11T04:16:36+00:00

ACPI: Getting cpuindex for acpiid 0x4 acpi_processor-0742 [00] processor_preregister_: Error while parsing _PSD domain information. Assuming no coordination http://bugzilla.kernel.org/show_bug.cgi?id=7286 Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown

Pull style into test branch

2006-12-16T06:04:27+00:00

Conflicts: drivers/acpi/button.c drivers/acpi/ec.c drivers/acpi/osl.c drivers/acpi/sbs.c

[PATCH] Correct bound checking from the value returned from _PPC method.

2006-11-23T17:18:55+00:00

processor_perflib.c::acpi_processor_ppc_notifier() check if the value returned by the processor's _PPC method is 0 and return failed if so. This is wrong since 0 indicate that the bios think the processor can go to the highest frequency. This patch for example fix the HP NX 6125 to allow its highest frequency to be available. Signed-off-by: Bruno Ducrot Cc: "Pallipadi, Venkatesh" Signed-off-by: Dave Jones Signed-off-by: Linus Torvalds

ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpi

2006-10-14T05:51:07+00:00

Signed-off-by: Jan Engelhardt Signed-off-by: Len Brown