summaryrefslogtreecommitdiff
path: root/include/asm-ia64/acpi.h
AgeCommit message (Collapse)Author
2008-08-01[IA64] Move include/asm-ia64 to arch/ia64/include/asmTony Luck
After moving the the include files there were a few clean-ups: 1) Some files used #include <asm-ia64/xyz.h>, changed to <asm/xyz.h> 2) Some comments alerted maintainers to look at various header files to make matching updates if certain code were to be changed. Updated these comments to use the new include paths. 3) Some header files mentioned their own names in initial comments. Just deleted these self references. Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-04-08[IA64] Minimize per_cpu reservations.holt@sgi.com
This attached patch significantly shrinks boot memory allocation on ia64. It does this by not allocating per_cpu areas for cpus that can never exist. In the case where acpi does not have any numa node description of the cpus, I defaulted to assigning the first 32 round-robin on the known nodes.. For the !CONFIG_ACPI I used for_each_possible_cpu(). Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2008-01-30x86: voluntary leave_mm before entering ACPI C3Venki Pallipadi
Aviod TLB flush IPIs during C3 states by voluntary leave_mm() before entering C3. The performance impact of TLB flush on C3 should not be significant with respect to C3 wakeup latency. Also, CPUs tend to flush TLB in hardware while in C3 anyways. On a 8 logical CPU system, running make -j2, the number of tlbflush IPIs goes down from 40 per second to ~ 0. Total number of interrupts during the run of this workload was ~1200 per second, which makes it ~3% savings in wakeups. There was no measurable performance or power impact however. [ akpm@linux-foundation.org: symbol export fixes. ] Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2007-11-26ACPI: Set max_cstate to 1 for early Opterons.Alexey Starikovskiy
AMD Opteron processors before CG revision don't like C-states > 1. This solves the long standing bugzilla #5303 and probably some more on affected machines: http://bugzilla.kernel.org/show_bug.cgi?id=5303 [ tglx@linutronix.de: reworked the patch so it does not wreck ia64 ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2007-07-25ACPI: Kconfig: remove CONFIG_ACPI_SLEEP from sourceLen Brown
As it was a synonym for (CONFIG_ACPI && CONFIG_X86), the ifdefs for it were more clutter than they were worth. For ia64, just add a few stubs in anticipation of future S3 or S4 support. Signed-off-by: Len Brown <len.brown@intel.com>
2007-05-24[IA64] Cleanup acpi header to reuse the generic _PDC definesVenki Pallipadi
ia64 _PDC setup is defined similar to i386. So, cleanup the header to use generic _PDC defines than using specific defines in ia64. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2007-02-02ACPICA: Allow ACPI id to be u32 instead of u8.Alexey Starikovskiy
Allow ACPI id to be u32 instead of u8. Requires drop of conversion tables with the acpiid as index. Signed-off-by: Len Brown <len.brown@intel.com>
2007-02-02ACPICA: minimal patch to integrate new tables into LinuxAlexey Starikovskiy
Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-20[IA64] - Fix MAX_PXM_DOMAINS for systems with > 256 nodesJack Steiner
Correctly size the PXM-related arrays for systems that have more than 256 nodes. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-03-24[IA64] Increase max node count on SN platformsJack Steiner
Add support in IA64 acpi for platforms that support more than 256 nodes. Currently, ACPI is limited to 256 nodes because the proximity domain number is 8-bits. Long term, we expect to use ACPI3.0 to support >256 nodes. This patch is an interim solution that works with platforms that pass the high order bits of the proximity domain in "reserved" fields of the ACPI tables. This code is enabled ONLY on SN platforms. Signed-off-by: Jack Steiner <steiner@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-02-14[IA64] Count disabled cpus as potential hot-pluggable CPUsAshok Raj
Have a facility to account for potentially hot-pluggable CPUs. ACPI doesnt give a determinstic method to find hot-pluggable CPUs. Hence we use 2 methods to assist. - BIOS can mark potentially hot-pluggable CPUs as disabled in the MADT tables. - User can specify the number of hot-pluggable CPUs via parameter additional_cpus=X The option is enabled only if ACPI_CONFIG_HOTPLUG_CPU=y which enables the physical hotplug option. Without which user can still use logical onlining and offlining of CPUs by enabling CONFIG_HOTPLUG_CPU=y Adds more bits to cpu_possible_map for potentially hot-pluggable cpus. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-08-26[IA64] Add ACPI based P-state supportVenkatesh Pallipadi
Patch to support P-state transitions on ia64. This driver is based on ACPI, and uses the ACPI processor driver interface to find out the P-state support information for the processor. This driver plugs into generic cpufreq infrastructure. Once this driver is loaded successfully, ondemand/userspace governor can be used to change the CPU frequency dynamically based on load or on request from userspace process. Refer : ACPI specification - http://www.acpi.info P-state related PAL calls - http://developer.intel.com/design/itanium/downloads/24869909.pdf Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-07-12[ACPI] Evaluate CPEI Processor Override flagAshok Raj
ACPI 3.0 added a Correctable Platform Error Interrupt (CPEI) Processor Overide flag to MADT.Platform_Interrupt_Source. Record the processor that was provided as hint from ACPI. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
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!