aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi/processor_idle.c
Commit message (Collapse)AuthorAgeFilesLines
...
* | [PATCH] acpi_processor_latency_notifier(): UP warning fixAndrew Morton2006-10-171-0/+6
| | | | | | | | | | | | | | | | | | drivers/acpi/processor_idle.c:1112: warning: 'smp_callback' defined but not used Cc: Len Brown <[email protected]> Cc: Arjan van de Ven <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* | Pull trivial into test branchLen Brown2006-10-141-1/+1
|\ \
| * | ACPI: fix section for CPU init functionsPierre Ossman2006-10-141-1/+1
| |/ | | | | | | | | | | | | | | | | The ACPI processor init functions should be marked as __cpuinit as they use structures marked with __cpuinitdata. Signed-off-by: Pierre Ossman <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
* / ACPI: Processor native C-states using MWAITVenkatesh Pallipadi2006-10-141-36/+61
|/ | | | | | | | | | | | | | | | | | | | | | | | | Intel processors starting with the Core Duo support support processor native C-state using the MWAIT instruction. Refer: Intel Architecture Software Developer's Manual http://www.intel.com/design/Pentium4/manuals/253668.htm Platform firmware exports the support for Native C-state to OS using ACPI _PDC and _CST methods. Refer: Intel Processor Vendor-Specific ACPI: Interface Specification http://www.intel.com/technology/iapc/acpi/downloads/302223.htm With Processor Native C-state, we use 'MWAIT' instruction on the processor to enter different C-states (C1, C2, C3). We won't use the special IO ports to enter C-state and no SMM mode etc required to enter C-state. Overall this will mean better C-state support. One major advantage of using MWAIT for all C-states is, with this and "treat interrupt as break event" feature of MWAIT, we can now get accurate timing for the time spent in C1, C2, .. states. Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
* [PATCH] maximum latency tracking infrastructureArjan van de Ven2006-10-011-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add infrastructure to track "maximum allowable latency" for power saving policies. The reason for adding this infrastructure is that power management in the idle loop needs to make a tradeoff between latency and power savings (deeper power save modes have a longer latency to running code again). The code that today makes this tradeoff just does a rather simple algorithm; however this is not good enough: There are devices and use cases where a lower latency is required than that the higher power saving states provide. An example would be audio playback, but another example is the ipw2100 wireless driver that right now has a very direct and ugly acpi hook to disable some higher power states randomly when it gets certain types of error. The proposed solution is to have an interface where drivers can * announce the maximum latency (in microseconds) that they can deal with * modify this latency * give up their constraint and a function where the code that decides on power saving strategy can query the current global desired maximum. This patch has a user of each side: on the consumer side, ACPI is patched to use this, on the producer side the ipw2100 driver is patched. A generic maximum latency is also registered of 2 timer ticks (more and you lose accurate time tracking after all). While the existing users of the patch are x86 specific, the infrastructure is not. I'd like to ask the arch maintainers of other architectures if the infrastructure is generic enough for their use (assuming the architecture has such a tradeoff as concept at all), and the sound/multimedia driver owners to look at the driver facing API to see if this is something they can use. [[email protected]: cleanups] Signed-off-by: Arjan van de Ven <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Acked-by: Jesse Barnes <[email protected]> Cc: "Brown, Len" <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* ACPI: add 'const' to several ACPI file_operationsArjan van de Ven2006-07-101-1/+1
| | | | | Signed-off-by: Arjan van de Ven <[email protected]> Signed-off-by: Len Brown <[email protected]>
* ACPI: delete acpi_os_free(), use kfree() directlyLen Brown2006-06-301-1/+1
| | | | Signed-off-by: Len Brown <[email protected]>
* Pull c-states into release branchLen Brown2006-06-291-19/+16
|\
| * ACPI: C-States: only demote on current bus mastering activityDominik Brodowski2006-06-281-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | Only if bus master activity is going on at the present, we should avoid entering C3-type sleep, as it might be a faulty transition. As long as the bm_activity bitmask was based on the number of calls to the ACPI idle function, looking at previous moments made sense. Now, with it being based on what happened this jiffy, looking at this jiffy should be sufficient. Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
| * ACPI: C-States: bm_activity improvementsDominik Brodowski2006-06-281-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do not assume there was bus mastering activity if the idle handler didn't get called, as there's only reason to not enter C3-type sleep if there is bus master activity going on. Only for the "promotion" into C3-type sleep bus mastering activity is taken into account, and there only current bus mastering activity, and not pure guessing should lead to the decision on whether to enter C3-type sleep or not. Also, as bm_activity is a jiffy-based bitmask (bit 0: bus mastering activity during this juffy, bit 31: bus mastering activity 31 jiffies ago), fix the setting of bit 0, as it might be called multiple times within one jiffy. Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
| * ACPI: C-States: accounting of sleep statesDominik Brodowski2006-06-281-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Track the actual time spent in C-States (C2 upwards, we can't determine this for C1), not only the number of invocations. This is especially useful for dynamic ticks / "tickless systems", but is also of interest on normal systems, as any interrupt activity leads to C-States being exited, not only the timer interrupt. The time is being measured in PM timer ticks, so an increase by one equals 279 nanoseconds. Signed-off-by: Dominik Brodowski <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
* | ACPI: additional blacklist entry for ThinkPad R40eBartlomiej Swiercz2006-06-281-0/+3
| | | | | | | | Signed-off-by: Len Brown <[email protected]>
* | ACPI: restore comment justifying 'extra' P_LVLx accessAndreas Mohr2006-06-281-2/+4
|/ | | | | | | | | | | | | | While trying to look for superfluous I/O accesses that can be optimized away, I stumbled upon this ACPI sleep I/O access and couldn't figure out why the hell this dummy op was necessary. After more than one hour of internet research, I had collected a sufficient number of documents (among those very old kernel versions) that finally told me what this dummy read was about: STPCLK# doesn't get asserted in time on (some) chipsets, which is why we need to have a dummy I/O read to delay further instruction processing until the CPU is fully stopped. Signed-off-by: Andreas Mohr <[email protected]> Signed-off-by: Len Brown <[email protected]>
* ACPI: delete tracing macros from drivers/acpi/*.cPatrick Mochel2006-06-271-41/+30
| | | | Signed-off-by: Len Brown <[email protected]>
* ACPI: un-export ACPI_ERROR() -- use printk(KERN_ERR...)Len Brown2006-06-271-2/+2
| | | | Signed-off-by: Len Brown <[email protected]>
* ACPI: Enable ACPI error messages w/o CONFIG_ACPI_DEBUGThomas Renninger2006-06-271-9/+5
| | | | | Signed-off-by: Thomas Renninger <[email protected]> Signed-off-by: Len Brown <[email protected]>
* Merge branch 'x86-64'Linus Torvalds2006-06-261-6/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * x86-64: (83 commits) [PATCH] x86_64: x86_64 stack usage debugging [PATCH] x86_64: (resend) x86_64 stack overflow debugging [PATCH] x86_64: msi_apic.c build fix [PATCH] x86_64: i386/x86-64 Add nmi watchdog support for new Intel CPUs [PATCH] x86_64: Avoid broadcasting NMI IPIs [PATCH] x86_64: fix apic error on bootup [PATCH] x86_64: enlarge window for stack growth [PATCH] x86_64: Minor string functions optimizations [PATCH] x86_64: Move export symbols to their C functions [PATCH] x86_64: Standardize i386/x86_64 handling of NMI_VECTOR [PATCH] x86_64: Fix modular pc speaker [PATCH] x86_64: remove sys32_ni_syscall() [PATCH] x86_64: Do not use -ffunction-sections for modules [PATCH] x86_64: Add cpu_relax to apic_wait_icr_idle [PATCH] x86_64: adjust kstack_depth_to_print default [PATCH] i386/x86-64: adjust /proc/interrupts column headings [PATCH] x86_64: Fix race in cpu_local_* on preemptible kernels [PATCH] x86_64: Fix fast check in safe_smp_processor_id [PATCH] x86_64: x86_64 setup.c - printing cmp related boottime information [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_status ... Manual resolve of trivial conflict in arch/i386/kernel/Makefile
| * [PATCH] i386/x86-64/ia64: Move polling flag into thread_info_statusAndi Kleen2006-06-261-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During some profiling I noticed that default_idle causes a lot of memory traffic. I think that is caused by the atomic operations to clear/set the polling flag in thread_info. There is actually no reason to make this atomic - only the idle thread does it to itself, other CPUs only read it. So I moved it into ti->status. Converted i386/x86-64/ia64 for now because that was the easiest way to fix ACPI which also manipulates these flags in its idle function. Cc: Nick Piggin <[email protected]> Cc: Tony Luck <[email protected]> Cc: Len Brown <[email protected]> Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* | [PATCH] Time: i386 Conversion - part 2: Rework TSC Supportjohn stultz2006-06-261-0/+9
|/ | | | | | | | | | | | | | | | | | | | | | | As part of the i386 conversion to the generic timekeeping infrastructure, this introduces a new tsc.c file. The code in this file replaces the TSC initialization, management and access code currently in timer_tsc.c (which will be removed) that we want to preserve. The code also introduces the following functionality: o tsc_khz: like cpu_khz but stores the TSC frequency on systems that do not change TSC frequency w/ CPU frequency o check/mark_tsc_unstable: accessor/modifier flag for TSC timekeeping usability o minor cleanups to calibration math. This patch also includes a one line __cpuinitdata fix from Zwane Mwaikambo. Signed-off-by: John Stultz <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* ACPI: apply "__read_mostly" to processor_idle.c loop module parameters and ↵Andreas Mohr2006-05-141-4/+4
| | | | | | | | | | | friends make pm_idle_save, nocst and bm_history __read_mostly remove initializer from static 'first_run'. Signed-off-by: Andreas Mohr <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
* [PATCH] Fix compilation of processor_idle.c on IA64Andi Kleen2006-03-261-2/+4
| | | | | | | | | | Broken earlier by me by a x86-64 patch. The code was optimized away, but the compiler still complained about an undeclared function. Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* [PATCH] x86_64: Force broadcast timer on AMD systems with C3 too.Andi Kleen2006-03-251-10/+15
| | | | | Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* [PATCH] x86_64: data/functions wrongly marked as __init with cpu hotplug.Ashok Raj2006-02-051-1/+3
| | | | | | | | | | | attached patch is 2 more cases i found via running the reference_init.pl script. These were easy to spot just knowing the file names. There is one another about init/main.c that i cant exactly zero in. (partly because i dont know how to interpret the data thats spewed out of the tool). Signed-off-by: Ashok Raj <[email protected]> Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* [PATCH] x86_64: Only switch to IPI broadcast timer on Intel when C3 is supportedVenkatesh Pallipadi2006-02-051-1/+1
| | | | | | | | | Bug in apic timer removal on C3 patch. We should switch to IPI from APIC timer only when C3 state is valid. Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
*---------. [ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica asus fops pnpacpi ↵Len Brown2006-01-241-51/+82
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | branches into release Signed-off-by: Len Brown <[email protected]>
| | | | | | * [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 <[email protected]> Signed-off-by: Len Brown <[email protected]>
| | | * | | [ACPI] handle BIOS with implicit C1 in _CSTJanosch Machowinski2005-12-021-33/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ASUS M6Ne specifies C2, implying C1 but not explicitly specifying it. http://bugzilla.kernel.org/show_bug.cgi?id=4485 Signed-off-by: Janosch Machowinski <[email protected]> Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Len Brown <[email protected]>
| * | | | | [ACPI] Disable C2/C3 for _all_ IBM R40e LaptopsThomas Rosner2006-01-071-16/+51
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds all known BIOS versions of IBM R40e Laptops to the C2/C3 processor state blacklist and thus prevents them from crashing. workaround for http://bugzilla.kernel.org/show_bug.cgi?id=3549 Signed-off-by: Thomas Rosner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Len Brown <[email protected]>
* / | | | [PATCH] i386: Handle missing local APIC timer interrupts on C3 stateVenkatesh Pallipadi2006-01-121-0/+15
|/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whenever we see that a CPU is capable of C3 (during ACPI cstate init), we disable local APIC timer and switch to using a broadcast from external timer interrupt (IRQ 0). This is needed because Intel CPUs stop the local APIC timer in C3. This is currently only enabled for Intel CPUs. Patch below adds the code for i386 and also the ACPI hunk. Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Andi Kleen <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* | | | Pull 5165 into release branchLen Brown2005-12-051-5/+15
|\ \ \ \ | |/ / / |/| | |
| * | | [ACPI] correct earlier SMP deep C-states on HT patchDavid Shaohua Li2005-12-051-5/+15
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=5165 Change polarity of test for PLVL2_UP flag. Skip promotion/demotion code when not needed. Signed-off-by: Shaohua Li <[email protected]> Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Len Brown <[email protected]>
* | | Add missing "local_irq_enable()" to C2/C3 exit logicLinus Torvalds2005-12-031-0/+1
| | | | | | | | | | | | | | | | | | Silly bug crept in with the C2/C3 TIF_POLLING_NRFLAG fixes. Signed-off-by: Linus Torvalds <[email protected]>
* | | [PATCH] Fix TIF_POLLING_NRFLAG in ACPI idle routinesNick Piggin2005-12-021-7/+14
|/ / | | | | | | | | | | | | | | | | | | Commit 64c7c8f88559624abdbe12b5da6502e8879f8d28 broke the ACPI C2 and C3 sleep states, because it left TIF_POLLING_NRFLAG active even though those states do not actually poll the reschedule flag at all. As a result, the CPU wouldn't get sent an IPI when it was to be woken up, and would only notice that it had runnable processes on the next timer tick. Signed-off-by: Linus Torvalds <[email protected]>
* | [ACPI] Add support for FADT P_LVL2_UP flagVenkatesh Pallipadi2005-11-301-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | which tells us if C2 is valid for UP-only, or SMP. As there is no separate bit for C3, use P_LVL2_UP bit to cover both C2 and C3. http://bugzilla.kernel.org/show_bug.cgi?id=5165 Signed-off-by: Venkatesh Pallipadi<[email protected]> Signed-off-by: Len Brown <[email protected]> (cherry picked from 28b86b368af3944eb383078fc5797caf2dc8ce44 commit)
* | [ACPI] Prefer _CST over FADT for C-state capabilitiesVenkatesh Pallipadi2005-11-301-5/+5
|/ | | | | | | | | | | | | Note: This ACPI standard compliance may cause regression on some system, if they have _CST present, but _CST value is bogus. "nocst" module parameter should workaround that regression. http://bugzilla.kernel.org/show_bug.cgi?id=5165 Signed-off-by: Venkatesh Pallipadi<[email protected]> Signed-off-by: Len Brown <[email protected]> (cherry picked from 883baf7f7e81cca26f4683ae0d25ba48f094cc08 commit)
* Fix ACPI processor power block initializationLinus Torvalds2005-11-181-10/+4
| | | | | | | | | | | | Properly clear the memory, and set "pr->flags.power" only if a C2 or deeper state is valid (to make the code match both the comment and previous behaviour). This fixes a boot-time lockup reported by Maneesh Soni when using "maxcpus=1". Acked-by: Maneesh Soni <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* [PATCH] sched: resched and cpu_idle reworkNick Piggin2005-11-091-14/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make some changes to the NEED_RESCHED and POLLING_NRFLAG to reduce confusion, and make their semantics rigid. Improves efficiency of resched_task and some cpu_idle routines. * In resched_task: - TIF_NEED_RESCHED is only cleared with the task's runqueue lock held, and as we hold it during resched_task, then there is no need for an atomic test and set there. The only other time this should be set is when the task's quantum expires, in the timer interrupt - this is protected against because the rq lock is irq-safe. - If TIF_NEED_RESCHED is set, then we don't need to do anything. It won't get unset until the task get's schedule()d off. - If we are running on the same CPU as the task we resched, then set TIF_NEED_RESCHED and no further action is required. - If we are running on another CPU, and TIF_POLLING_NRFLAG is *not* set after TIF_NEED_RESCHED has been set, then we need to send an IPI. Using these rules, we are able to remove the test and set operation in resched_task, and make clear the previously vague semantics of POLLING_NRFLAG. * In idle routines: - Enter cpu_idle with preempt disabled. When the need_resched() condition becomes true, explicitly call schedule(). This makes things a bit clearer (IMO), but haven't updated all architectures yet. - Many do a test and clear of TIF_NEED_RESCHED for some reason. According to the resched_task rules, this isn't needed (and actually breaks the assumption that TIF_NEED_RESCHED is only cleared with the runqueue lock held). So remove that. Generally one less locked memory op when switching to the idle thread. - Many idle routines clear TIF_POLLING_NRFLAG, and only set it in the inner most polling idle loops. The above resched_task semantics allow it to be set until before the last time need_resched() is checked before going into a halt requiring interrupt wakeup. Many idle routines simply never enter such a halt, and so POLLING_NRFLAG can be always left set, completely eliminating resched IPIs when rescheduling the idle task. POLLING_NRFLAG width can be increased, to reduce the chance of resched IPIs. Signed-off-by: Nick Piggin <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Con Kolivas <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* [PATCH] fix missing includesTim Schmielau2005-10-311-0/+1
| | | | | | | | | | | | | | | | | | | | | I recently picked up my older work to remove unnecessary #includes of sched.h, starting from a patch by Dave Jones to not include sched.h from module.h. This reduces the number of indirect includes of sched.h by ~300. Another ~400 pointless direct includes can be removed after this disentangling (patch to follow later). However, quite a few indirect includes need to be fixed up for this. In order to feed the patches through -mm with as little disturbance as possible, I've split out the fixes I accumulated up to now (complete for i386 and x86_64, more archs to follow later) and post them before the real patch. This way this large part of the patch is kept simple with only adding #includes, and all hunks are independent of each other. So if any hunk rejects or gets in the way of other patches, just drop it. My scripts will pick it up again in the next round. Signed-off-by: Tim Schmielau <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
* [ACPI] Lindent all ACPI filesLen Brown2005-08-051-156/+159
| | | | Signed-off-by: Len Brown <[email protected]>
* /home/lenb/src/to-linus branch 'acpi-2.6.12'Len Brown2005-08-031-4/+3
|\
| * [ACPI] fix 64-bit build warning in processor_idle.cLen Brown2005-08-031-4/+3
| | | | | | | | Signed-off-by: Len Brown <[email protected]>
* | /home/lenb/src/to-linus branch 'acpi-2.6.12'Len Brown2005-07-301-14/+17
|\|
| * [ACPI] delete boot-time printk()s from processor_idle.cVenkatesh Pallipadi2005-07-301-2/+0
| | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=4401 Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Len Brown <[email protected]>
| * [ACPI] address boot-freeze with updated DMI blacklist for c-statesDavid Shaohua Li2005-07-291-9/+12
| | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=4763 Signed-off-by: David Shaohua Li <[email protected]> Signed-off-by: Len Brown <[email protected]>
| * [ACPI] Fix memset arguments in acpi processor_idle.cVenkatesh Pallipadi2005-07-291-2/+4
| | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=4954 Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Len Brown <[email protected]>
| * [ACPI] Fix the regression with c1_default_handler on some systemsVenkatesh Pallipadi2005-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | where C-states come from FADT. Thanks to Kevin Radloff for identifying the issue and isolating it to exact line of code that is causing the issue. Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Len Brown <[email protected]>
* | [ACPI] merge acpi-2.6.12 branch into latest Linux 2.6.13-rc...Len Brown2005-07-121-41/+97
|\| | | | | | | Signed-off-by: Len Brown <[email protected]>
| * [ACPI] enable C2 and C3 idle power states on SMPVenkatesh Pallipadi2005-07-121-34/+71
| | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=4401 Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Len Brown <[email protected]>
| * [ACPI] update /proc/acpi/processor/*/power even if only C1 supportVenkatesh Pallipadi2005-07-121-7/+26
| | | | | | | | | | Signed-off-by: Venkatesh Pallipadi <[email protected]> Signed-off-by: Len Brown <[email protected]>
* | [PATCH] smp_processor_id() cleanupIngo Molnar2005-06-221-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a number of smp_processor_id() cleanup ideas that Arjan van de Ven and I came up with. The previous __smp_processor_id/_smp_processor_id/smp_processor_id API spaghetti was hard to follow both on the implementational and on the usage side. Some of the complexity arose from picking wrong names, some of the complexity comes from the fact that not all architectures defined __smp_processor_id. In the new code, there are two externally visible symbols: - smp_processor_id(): debug variant. - raw_smp_processor_id(): nondebug variant. Replaces all existing uses of _smp_processor_id() and __smp_processor_id(). Defined by every SMP architecture in include/asm-*/smp.h. There is one new internal symbol, dependent on DEBUG_PREEMPT: - debug_smp_processor_id(): internal debug variant, mapped to smp_processor_id(). Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new lib/smp_processor_id.c file. All related comments got updated and/or clarified. I have build/boot tested the following 8 .config combinations on x86: {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT} I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT. (Other architectures are untested, but should work just fine.) Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Arjan van de Ven <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
generated by cgit (git 2.51.2) at 2025-12-04 03:59:11 +0000