Add kernel support for new ACPI "sapic" tables that contain 16-bit APICIDs.
This patch simply adds parsing of an optional SAPIC table if present.
Otherwise, the traditional local APIC table is used.

Note: the SAPIC table is not a new ACPI table - it exists on other architectures
but is not currently recognized by x86_64.
Signed-off-by: NJack Steiner <steiner@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Add functions that can be used to determine if an x86_64
system is a SGI "UV" system. UV systems come in 3 types and
are identified by the OEM ID in the MADT.
Signed-off-by: NJack Steiner <steiner@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

After the inclusion, a lot of files needs fixing for conflicts,
some of them in the headers themselves, to accomodate for both
i386 and x86_64 versions.

[ mingo@elte.hu: build fix ]
Signed-off-by: NGlauber Costa <gcosta@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

When acpi=off and pci=nomsi, don't load acpiphp.

Fixes this:

pci_hotplug: PCI Hot Plug PCI Core version: 0.5
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread
FFFF81103CC54000 could not acquire Mutex [1] [20070126]

[akpm@linux-foundation.org: export acpi_pci_disabled for acpiphp.ko]
[akpm@linux-foundation.org: fix return statement]
Signed-off-by: NYinghai Lu <yinghai.lu@sun.com>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

    This patch contains the following possible cleanups:
    - make the following needlessly global code static:
      - drivers/acpi/bay.c:dev_attr_eject
      - drivers/acpi/bay.c:dev_attr_present
      - drivers/acpi/dock.c:dev_attr_docked
      - drivers/acpi/dock.c:dev_attr_flags
      - drivers/acpi/dock.c:dev_attr_uid
      - drivers/acpi/dock.c:dev_attr_undock
      - drivers/acpi/pci_bind.c:acpi_pci_unbind()
      - drivers/acpi/pci_link.c:acpi_link_lock
      - drivers/acpi/sbs.c:acpi_sbs_callback()
      - drivers/acpi/sbshc.c:acpi_smbus_transaction()
      - drivers/acpi/sleep/main.c:acpi_sleep_prepare()
    - #if 0 the following unused global functions:
      - drivers/acpi/numa.c:acpi_unmap_pxm_to_node()
    - remove the following unused EXPORT_SYMBOL's:
      - acpi_register_gsi
      - acpi_unregister_gsi
      - acpi_strict
      - acpi_bus_receive_event
      - register_acpi_bus_type
      - unregister_acpi_bus_type
      - acpi_os_printf
      - acpi_os_sleep
      - acpi_os_stall
      - acpi_os_read_pci_configuration
      - acpi_os_create_semaphore
      - acpi_os_delete_semaphore
      - acpi_os_wait_semaphore
      - acpi_os_signal_semaphore
      - acpi_os_signal
      - acpi_pci_irq_enable
      - acpi_get_pxm
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

Fix following warning:
WARNING: o-x86_64/arch/x86/kernel/built-in.o(.text+0x13d15): Section mismatch in reference from the function acpi_map_lsapic() to the function .cpuinit.text:mp_register_lapic()

The function acpi_map_lsapic() is exported and thus not annotated.
But the sole user is acpi/processor_core.c in a __cpuinit path.
So create a small wrapper and put back the annotation thus
avoiding the warning.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

ACPI tables follow a tree structure in memory.
The root of the tree is the RSDP (Root System Description Pointer).

To find the RSDP, the OS searches for the signature "RSD PTR "
in well known physical memory locations.  Then the OS computes
a table checksum to verify that the signature is really part
of a valid table header.

Some systems have a proper signature but an invalid checksum;
followed elsewhere by a proper signature with valid checksum.

http://bugzilla.kernel.org/show_bug.cgi?id=9444

The Linux RSDP scanning code bailed out on those systems
and as a result they booted with ACPI disabled.

Fix this by deleting the Linux RSDP scanning code and
plugging in the ACPICA RSDP scanning code.
Signed-off-by: NLen Brown <len.brown@intel.com>

.. as it it used only during early boot.
Signed-off-by: NJan Beulich <jbeulich@novell.com>

 arch/ia64/kernel/acpi.c     |    2 +-
 arch/x86/kernel/acpi/boot.c |    4 ++--
 drivers/acpi/osl.c          |    3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)
Signed-off-by: NLen Brown <len.brown@intel.com>

Some BIOSes advertise HPET at 0x0. We really do no want to 
allocate a resource there. Check for it and leave early.

Other BIOSes tell us the HPET is at 0xfed0000000000000 
instead of 0xfed00000. Add a check and fix it up with a warning
on user request.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Spelling fixes in arch/i386/.
Signed-off-by: NSimon Arlott <simon@fire.lp0.eu>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>

This patch converts the x86_cpu_to_apicid array to be a per cpu
variable. This saves sizeof(apicid) * NR unused cpus.  Access is mostly
from startup and CPU HOTPLUG functions.

MP_processor_info() is one of the functions that require access to the
x86_cpu_to_apicid array before the per_cpu data area is setup.  For this
case, a pointer to the __initdata array is initialized in setup_arch()
and removed in smp_prepare_cpus() after the per_cpu data area is
initialized.

A second change is included to change the initial array value of ARCH
i386 from 0xff to BAD_APICID to be consistent with ARCH x86_64.
Signed-off-by: NMike Travis <travis@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Three main sets of changes:

1) dmi_get_system_info() return value should have been marked const,
   since callers should not be changing that data.

2) const-ify DMI internals, since DMI firmware tables should,
   whenever possible, be marked const to ensure we never ever write to
   that data area.

3) const-ify DMI API, to enable marking tables const where possible
   in low-level drivers.

And if we're really lucky, this might enable some additional
optimizations on the part of the compiler.

The bulk of the changes are #2 and #3, which are interrelated.  #1 could
have been a separate patch, but it was so small compared to the others,
it was easier to roll it into this changeset.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Insert HPET resources after pci probing has been completed in order to
avoid resource conflicts with PCI resource reservation.  With this change
the HPET firmware resources will be identified, but it should also not
cause issues when the HPET address falls on a BAR in a PCI device, and the
PCI enumeration cannot reserve the resources.
Signed-off-by: NAaron Durbin <adurbin@google.com>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When Andi reverted the HPET resource reservation (in commit
0f8dc2f0), he didn't remove the now
unused variables, which just causes gcc to be noisy.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Matthias Lenk reports that the PCI subsystem would move the HPET on
SB400/SB600-based systems, where the HPET is in BAR1 of the SMbus
controller.

The reason? The ACPI layer registered the PCI MMIO range as being busy
too early, before PCI enumeration had happened, causing the PCI layer to
decide that it should relocate the resources somewhere else.

Firmware resources should be marked busy _after_ the PCI enumeration and
probing has happened, not before.

Remove the too-early reservation, we'll fix it up to do it properly
later.  In the meantime, this solves the regression.
Tested-by: NMatthias Lenk <matthias.lenk@amd.com>
Cc: Aaron Durbin <adurbin@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I have a Dell Optiplex GX240 and when I boot Linux, ACPI gets set up by only
acpi=ht.  dmesg shows the following line:

   DELL GX240 detected: force use of acpi=ht

Everything seemed to be fine.  However, I discovered that everything is not
fine.  The USB controller works so slowly that copying a few (uncached) 1
megabyte large photos from a USB-enabled digital camera takes many minutes
instead of a couple of seconds.

I am using Linux 2.6.21.1 on a Debian 4.0 ("Etch") system.

I thought that this might be related to ACPI.  So I tried to boot with _only_
"acpi=force" appended to the kernel command line.  Voila, the USB controller
started to work at full speed and copying photos from my digital camera took
only seconds.

I tested the system with "acpi=force" and could not find anything which did
not work.

I thought that this might be related to interrupts and APIC as well.  (Note
that this is APIC, not ACPI.) I tried booting with _only_ "noapic" and
"nolapic" appended to the command line.  Again, the USB controller started to
work at full speed.
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Default to physical mode on hotplug CPU kernels.  Furher simplify and clean up
the APIC initialization code.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Andi Kleen <ak@suse.de>
Cc: "Li, Shaohua" <shaohua.li@intel.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>

The root cause of this bug shows that this machine
could not possibly run an ACPI-aware OS without a
model specific workaround.

http://bugzilla.kernel.org/show_bug.cgi?id=5966Signed-off-by: NLen Brown <len.brown@intel.com>

In preparation for supporting generic timekeeping, this patch cleans up
x86-64's use of vxtime.hpet_address, changing it to just hpet_address as is
also used in i386.  This is necessary since the vxtime structure will be going
away.
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@muc.de>
Cc: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Allow early access to the power management timer by exposing the verified read
function and providing a helper function which checks the pmtmr_ioport
variable and returns either the pm timer readout or 0 in case the pm timer is
not available.

Create a new header file and replace also the ifdef'ed extern definition in
arch/i386/kernel/acpi/boot.c

This is a preperatory patch for the rework of the local apic timer
calibration.

No functional changes.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Returning count for tables that are supposed to be unique
was useless and confusing.
Signed-off-by: NLen Brown <len.brown@intel.com>

Allow ACPI id to be u32 instead of u8.
Requires drop of conversion tables with the acpiid as index.
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NLen Brown <len.brown@intel.com>

Dunno why this pops out in only in the allmodconfig build.
Though the warning is accurate, all the callers of the flagged
non __init function are __init, this is not a functional change.

WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_sci_flags from .text between 'acpi_sci_ioapic_setup' (at offset 0xc010f0a
6) and 'acpi_gsi_to_irq'                                                                                                                   WARNING: vmlinux - Section mismatch: reference to .init.text:mp_override_legacy_irq from .text between 'acpi_sci_ioapic_setup' (at offset 0
xc010f0de) and 'acpi_gsi_to_irq'                                                                                                           WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_sci_override_gsi from .text between 'acpi_sci_ioapic_setup' (at offset 0x
c010f0e4) and 'acpi_gsi_to_irq'
Signed-off-by: NLen Brown <len.brown@intel.com>

This reverts commit 281ea49b,
which broke ACPI Interrupt source overrides that move
the SCI from one IRQ in PIC mode to another in IOAPIC mode.

If the SCI shared an interrupt line with another device,
this would result in a "irq 18: nobody cared" type failure.

http://bugzilla.kernel.org/show_bug.cgi?id=7601Signed-off-by: NLen Brown <len.brown@intel.com>

Timer overrides are normally disabled on Nvidia board because
they are commonly wrong, except on new ones with HPET support.
Unfortunately there are quite some Asus boards around that
don't have HPET, but need a timer override.

We don't know yet how to handle this transparently,
but at least add a command line option to force the timer override
and let them boot.

Cc: len.brown@intel.com
Signed-off-by: NAndi Kleen <ak@suse.de>

WARNING: vmlinux - Section mismatch: reference to .init.data:acpi_noirq from .text between 'pcibios_penalize_isa_irq' (at offset 0xc026ffa1) and 'pirq_serverworks_get'
Acked-by: N"Brown, Len" <len.brown@intel.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- Fixes a build problem with CONFIG_M386=y (include file dependencies get
  messy).

- Share the implementation between x86 and x86_64

- These are too big to inline anyway.
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

The Linux group at Stratus Technologies has come across an issue with SCI
routing under ACPI.  We were bitten by this when we made an x86_64 platform
whose BIOS provides an Interrupt Source Override for the SCI itself.
Apparently the override has no effect for the System Control Interrupt, and
this appears to be because of the way the SCI is setup in the ACPI code.
It does not handle the case where busirq != gsi.

The code that sets up the SCI routing assumes that bus irq == global irq.
So there is simply no provision for telling it otherwise.  The attached
patch provides this mechanism.

This patch provided by David Bulkow, was tested on an i386 platform, which
does not use the SCI override, and also on an x86_64 platform which does
use an override.
Signed-off-by: NDavid Bulkow <david.bulkow@stratus.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

After raising the number of irqs the system supports this function is no
longer necessary.
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch removes the change in behavior of the irq allocation code when
CONFIG_PCI_MSI is defined.  Removing all instances of the assumption that irq
== vector.

create_irq is rewritten to first allocate a free irq and then to assign that
irq a vector.

assign_irq_vector is made static and the AUTO_ASSIGN case which allocates an
vector not bound to an irq is removed.

The ioapic vector methods are removed, and everything now works with irqs.

The definition of NR_IRQS no longer depends on CONFIG_PCI_MSI

[akpm@osdl.org: cleanup]
Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rajesh Shah <rajesh.shah@intel.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add HPET(s) into resource map. This will allow for the HPET(s) to be
visibile within /proc/iomem.
Signed-off-by: NAaron Durbin <adurbin@google.com>
Signed-off-by: NAndi Kleen <ak@suse.de>

This patch enables ACPI based physical CPU hotplug support for x86_64.
Implements acpi_map_lsapic() and acpi_unmap_lsapic() to support physical cpu
hotplug.
Signed-off-by: NAshok Raj <ashok.raj@intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Cc: Andi Kleen <ak@muc.de>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>