aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi/processor_perflib.c
Commit message (Collapse)AuthorAgeFilesLines
* ACPI: clean up ACPI_MODULE_NAME() useLen Brown2007-02-121-1/+1
| | | | | | | | | | 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 <len.brown@intel.com>
* ACPICA: use new ACPI headers.Alexey Starikovskiy2007-02-021-6/+6
| | | | Signed-off-by: Len Brown <len.brown@intel.com>
* ACPICA: minimal patch to integrate new tables into LinuxAlexey Starikovskiy2007-02-021-17/+10
| | | | Signed-off-by: Len Brown <len.brown@intel.com>
* [PATCH] ACPI: fix cpufreq regressionIngo Molnar2007-01-261-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <davej@redhat.com> 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: [<c028ba5f>] acpi_processor_get_platform_limit+0xa1/0xaf [<c028c040>] acpi_processor_register_performance+0x3b9/0x3ef [<c0111a85>] acpi_cpufreq_cpu_init+0xb7/0x596 [<c03dab74>] cpufreq_add_dev+0x160/0x4a8 [<c02bed90>] sysdev_driver_register+0x5a/0xa0 [<c03d9c4c>] cpufreq_register_driver+0xb4/0x176 [<c068ac08>] acpi_cpufreq_init+0xe5/0xeb [<c010056e>] 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 <mingo@elte.hu> Cc: Dave Jones <davej@redhat.com> Acked-by: Len Brown <lenb@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ACPI: delete two spurious ACPI messagesVenkatesh Pallipadi2007-01-101-4/+0
| | | | | | | | | | | 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 <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Pull style into test branchLen Brown2006-12-161-5/+5
|\ | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/button.c drivers/acpi/ec.c drivers/acpi/osl.c drivers/acpi/sbs.c
| * ACPI: Remove unnecessary from/to-void* and to-void casts in drivers/acpiJan Engelhardt2006-10-141-5/+5
| | | | | | | | | | Signed-off-by: Jan Engelhardt <jengelh@gmx.de> Signed-off-by: Len Brown <len.brown@intel.com>
* | [PATCH] Correct bound checking from the value returned from _PPC method.Dave Jones2006-11-231-3/+1
|/ | | | | | | | | | | | | 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 <ducrot@poupinou.org> Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* ACPI: delete acpi_os_free(), use kfree() directlyLen Brown2006-06-301-3/+3
| | | | Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: delete tracing macros from drivers/acpi/*.cPatrick Mochel2006-06-271-49/+38
| | | | Signed-off-by: Len Brown <len.brown@intel.com>
* Pull bugzilla-5737 into release branchThomas Renninger2006-06-271-4/+4
|\
| * ACPI: HW P-state coordination supportVenkatesh Pallipadi2006-06-261-4/+4
| | | | | | | | | | | | | | | | | | | | Treat HW coordination as independent CPUs. This enables per-cpu monintoring of P-states http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)Len Brown2006-06-271-6/+6
| | | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
* | ACPI: Enable ACPI error messages w/o CONFIG_ACPI_DEBUGThomas Renninger2006-06-261-22/+15
|/ | | | | Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
* ACPI: resolve merge conflict between sem2mutex and processor_perflib.cLen Brown2006-06-151-2/+2
| | | | Signed-off-by: Len Brown <len.brown@intel.com>
* Pull bugzilla-5737 into release branchLen Brown2006-06-151-0/+224
|\ | | | | | | | | | | Conflicts: arch/x86_64/kernel/acpi/processor.c
| * ACPI: use for_each_possible_cpu() instead of for_each_cpu()KAMEZAWA Hiroyuki2006-05-131-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | for_each_cpu() actually iterates across all possible CPUs. We've had mistakes in the past where people were using for_each_cpu() where they should have been iterating across only online or present CPUs. This is inefficient and possibly buggy. We're renaming for_each_cpu() to for_each_possible_cpu() to avoid this in the future. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: delete newly added debugging macros in processor_perflib.cLen Brown2006-05-111-7/+3
| | | | | | | | Signed-off-by: Len Brown <len.brown@intel.com>
| * P-state software coordination for ACPI coreVenkatesh Pallipadi2006-02-091-0/+228
| | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Pull sem2mutex into release branchLen Brown2006-06-151-11/+12
|\ \
| * | sem2mutex: drivers/acpi/processor_perflib.cArjan van de Ven2006-05-131-11/+12
| |/ | | | | | | | | | | | | | | | | | | | | | | Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com>
* | [PATCH] powernow-k8 crash workaroundAndrew Morton2006-06-101-1/+4
|/ | | | | | | | | | | | | | | From: Andrew Morton <akpm@osdl.org> Work around the oops reported in http://bugzilla.kernel.org/show_bug.cgi?id=6478. Thanks to Ralf Hildebrandt <ralf.hildebrandt@charite.de> for testing and reporting. Acked-by: Dave Jones <davej@codemonkey.org.uk> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
*-. [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi ↵Len Brown2006-01-241-3/+1
|\ \ | | | | | | | | | | | | | | | branches into release Signed-off-by: Len Brown <len.brown@intel.com>
| | * [ACPI] move some run-time structure inits to compile timeArjan van de Ven2006-01-071-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | acpi_processor_limit_fops.write was written at run time, but can be initiailized at compile-time instead. Similar for acpi_video_bus_POST_fops.write and friends, but keep doing those at runtime to avoid prototype-hell. Signed-off-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * [ACPI] Avoid BIOS inflicted crashes by evaluating _PDC only onceVenkatesh Pallipadi2005-12-011-2/+0
|/ | | | | | | | | | | | | | | Linux invokes the AML _PDC method (Processor Driver Capabilities) to tell the BIOS what features it can handle. While the ACPI spec says nothing about the OS invoking _PDC multiple times, doing so with changing bits seems to hopelessly confuse the BIOS on multiple platforms up to and including crashing the system. Factor out the _PDC invocation so Linux invokes it only once. http://bugzilla.kernel.org/show_bug.cgi?id=5483 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* [ACPI] Lindent all ACPI filesLen Brown2005-08-051-154/+143
| | | | Signed-off-by: Len Brown <len.brown@intel.com>
* [ACPI] enable C2 and C3 idle power states on SMPVenkatesh Pallipadi2005-07-121-32/+1
| | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=4401 Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+666
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
generated by cgit v1.1 at 2024-09-18 08:02:31 +0000