Use IPI for blacklisted CPUs, add parameter IPI vs LAPIC

Currently, Linux disables lapic timer for all machines with C2 and higher
C-state support.

According to Intel only specific Intel models (Banias/Dothan) are broken
in respect of not waking up from C2 with lapic.

However, I am not sure about the naming of the parameter and how it
could/should get integrated into the dyntick part
(CONFIG_GENERIC_CLOCKEVENTS). There, a more fine grained check (TSC
still running?, ..) is needed? Does this make sense (always use
CLOCK_EVT_NOTIFY_BROADCAST_ON, but use OFF if forced by use_ipi=0:
clockevents_notify(use_ipi ? CLOCK_EVT_NOTIFY_BROADCAST_ON :
CLOCK_EVT_NOTIFY_BROADCAST_OFF, &pr->id);
Signed-off-by: NThomas Renninger <trenn@suse.de>
Signed-off-by: NLen Brown <len.brown@intel.com>

This patch allows for ibm-acpi to coexist (with diminished functionality) with
other drivers like ACPI_BAY.  ibm-acpi will simply disable the functions it is
not able to register ACPI notifiers for.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Cc: Chris Wedgwood <cw@f00f.org>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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

This reverts 977a6226
and reverts 1ba753ac
and updates acpi_ev_queue_notify_request()
to restore the previous implementation of the
"acpi_serialize" workaround.

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

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Moving disable GPEs from enter_sleep up into sleep_prepare fixed
the disabled SCI on S4 on Acer laptops.

However, it caused an immediate S3 resume on the HP nx6125.
Apparently, on the HP, a GPE was getting re-enabled after
the prepare, but before the enter.

Close that window by restoring the GPE disable on enter.
This is redundant in most cases, but closes this window,
where S3 and S4 paths differ.
Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>
Acked-by: NRay Lee <ray-lk@madrabbit.org>

When a BIOS bug presents multiple APIC/MADTs,
Linux currently uses the 1st and ignores the 2nd.

But some machines work better if we use the 2nd.

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

Add a warning and boot parameter "acpi_apic_instance=2"
to allow parsing the 2nd.

No change to default behaviour in this patch.
Signed-off-by: NLen Brown <len.brown@intel.com>

Delay the read of the EC status register until
after the event that caused it occurs -- otherwise
it is possible to read and act on stale status that was
associated with the previous event.

Do this with a perpetually incrementing "event_count" to detect
when a new event occurs and it is safe to read status.

There is no workaround for polling mode -- it is inherently
exposed to reading and acting on stale status, since it
doesn't have an interrupt to tell it the event completed.

http://bugzilla.kernel.org/show_bug.cgi?id=8110Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NRobert P. J. Day <rpjday@mindspring.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Correct some of the most obvious spelling and grammar
mistakes in drivers/acpi/video.c (comments and printk output).
Signed-off-by: NJulius Volz <juliusrv@gmail.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

IMHO, ACPI disabled due to DMI failure or blacklisted year should be noted,
as is done with other ACPI blacklisting.

This will help people troubleshoot when ACPI isn't working.  Status quo is
a mysterious "ACPI Disabled" message without explanation on BIOS that
implements ACPI but not DMI.  This is actually fairly common on embedded
x86 boards.
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Improve the backlight code to emulate as much as possible the power
management events, as we are unable to really power on or power off the
backlight.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

This is a workaround to handle a BIOS bug where the
programmer exchanged the name and index fields of
a _PRT entry.  Apparently this BIOS error does not
confuse Windows and thus it lurks in the field
on various machines.

boot with "acpi=strict" to disable this workaround

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

(http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg05270.html):

References : http://lkml.org/lkml/2007/2/21/413
             http://lkml.org/lkml/2007/2/28/172
Submitter  : Arkadiusz Miskiewicz <arekm@maven.pl>
Caused-By  : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
             commit 0a613902

Do not disable power resources on resume even if there are no devices referencing it.
Signed-off-by: NKonstantin Karasyov <konstantin.a.karasyov@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

patch "Delete recursive feature of ACPI Global Lock"
broke re-entrancy of the Global Lock.
The common routine to acquire GL is acpi_ev_acquire_global_lock,
so check for re-entrancy _must_ be there, and not anywhere else.

http://bugzilla.kernel.org/show_bug.cgi?id=8066#c9Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Since the bay driver depends on the dock driver for proper notification,
make this driver depend on the dock driver.
Signed-off-by: NKristen Carlson Accardi <kristen.c.accardi@intel.com>
Acked-by: NLen Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make ibm-acpi bay support optional at kernel compile time.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>

The brightness class core does not update the initial status of the
device's brightness at register time.  Do it by ourselves.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: NRichard Purdie <rpurdie@rpsys.net>

http://bugzilla.kernel.org/show_bug.cgi?id=7570#c14Signed-off-by: NKonstantin Karasyov <konstantin.a.karasyov@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Per device data such as brightness belongs to the indivdual device
and should therefore be separate from the the backlight operation
function pointers. This patch splits the two types of data and
allows simplifcation of some code.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>

Remove uneeded owner field from backlight_properties structure.

Nothing uses it and it is unlikely that it will ever be used. The
backlight class uses other means to ensure that nothing references
unloaded code.

Based on a patch from Dmitry Torokhov <dtor@insightbb.com>
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>

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

register_platform_device_simple returns ERR_PTR(foo), so test it with
IS_ERR(foo).
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: NLen Brown <len.brown@intel.com>

acpi_unload_table_id() is always returning an error status.
Also, once the matching table is found, don't bother looking
for another match.
Signed-off-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add clockevent drivers for i386: lapic (local) and PIT/HPET (global).  Update
the timer IRQ to call into the PIT/HPET driver's event handler and the
lapic-timer IRQ to call into the lapic clockevent driver.  The assignement of
timer functionality is delegated to the core framework code and replaces the
compile and runtime evalution in do_timer_interrupt_hook()

Use the clockevents broadcast support and implement the lapic_broadcast
function for ACPI.

No changes to existing functionality.

[ kdump fix from Vivek Goyal <vgoyal@in.ibm.com> ]
[ fixes based on review feedback from Arjan van de Ven <arjan@infradead.org> ]
Cleanups-from: Adrian Bunk <bunk@stusta.de>
Build-fixes-from: Andrew Morton <akpm@osdl.org>
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>

This is a preperatory patch for highres/dyntick:

- replace the big #ifdef ARCH_APICTIMER_STOPS_ON_C3 hackery by functions

- remove the double switch in the power verify function (in the worst case
  we switched ipi to apic and 20usec later apic to ipi)

- keep track of the the state which stops local APIC timer
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Len Brown <len.brown@intel.com>
Cc: <linux-acpi@vger.kernel.org>
Cc: Andi Kleen <ak@suse.de>
Cc: john stultz <johnstul@us.ibm.com>
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>

apic.h does not get included on UP compiles.  That way the
APICTIMER_STOPS_ON_C3 is not there and UP boxen have no support for timer
broadcasting.  This was never noticed, because the lapic timer is only used
for profiling on UP.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

http://bugzilla.kernel.org/show_bug.cgi?id=7570Signed-off-by: NKonstantin Karasyov <konstantin.a.karasyov@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

drivers/acpi/power.c:69: warning: initialization from incompatible pointer type
Signed-off-by: NLen Brown <len.brown@intel.com>

The previous reference counting scheme to enable power resources
got confused when multiple devices were present that might
repeatedly enable or disable the resource and throw off the count.

The new code simply lists the referencing devices which
are requesting the resource to be enabled.  When there are none,
then it is off.
Signed-off-by: NKonstantin Karasyov <konstantin.a.karasyov@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

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

apic.h does not get included on UP compiles.  That way the
APICTIMER_STOPS_ON_C3 is not there and UP boxen have no support for timer
broadcasting.  This was never noticed, because the lapic timer is only used
for profiling on UP.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

It isn't needed in ACPI code anymore because
now ACPI always includes PNPACPI.

Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

We removed the ACPI motherboard driver which handled
the ACPI=y, PNP=n case, so now we need to enforce that
PNP & PNPACPI are always enabled for ACPI kernels.

Most major distros ship this way this already.

Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

...which are now unused
Signed-off-by: NLen Brown <len.brown@intel.com>

Use NULL for pointers

drivers/acpi/osl.c:208:10: warning: Using plain integer as NULL pointer
drivers/acpi/tables/tbxface.c:411:49: warning: Using plain integer as NULL pointer
drivers/acpi/processor_core.c:1008:10: warning: Using plain integer as NULL pointer
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.

The notify handler in the ACPI thermal driver is a C-routine,
which may invoke the ACPI interpreter again to get access
to some ACPI variables such as temperature.  (acpi_evaluate_xxx)
On these HP machines such an evaluation changes state of an ASL variable
and lets the loop above break.

In the current ACPI implementation, Notify requests are being deferred
to the same kacpid workqueue on which the above GPE handler with
infinite loop is executing. Thus we have a deadlock -- loop will
continue to spin, sending notify events, and at the same time
preventing these notify events from being run on a workqueue. All
notify events are deferred, thus we see explosion in memory consumption.

Also as GPE handling is blocked, machines overheat because ACPI-based
fan control is stalled.  Eventually by external poll of the same
acpi_evaluate, kacpid is released and all the queued notify events are
free to run, thus 100% CPU utilization by kacpid for several seconds
or more.

To prevent this failure,  Linux must not send notify events to the
kacpid workqueue -- either executing them immediately or putting them
on some other thread.

The first attempt to create a new thread was done by Peter Wainwright
He created a bunch of threads, which were stealing work from a kacpid
workqueue.
This patch appeared in 2.6.15-based kernel shipped with Ubuntu 6.06 LTS.

Second attempt was done by Alexey Starikovskiy, who created a new thread
for each Notify event. This worked OK on HP nx machines,
but broke Linus' Compaq n620c, by producing threads with a speed what
they stopped the machine completely.
Thus this patch was reverted from 2.6.18-rc2.

Alexey re-made the patch to create second workqueue just for notify events,
thus hopping it will not break Linus' machine. Patch was tested on the
same HP nx machines in #5534 and #7122, but this broke Linus' machine
also and was reverted from 2.6.19-rc with much fanfair.

The 4th patch inserted schedule_timeout(1) into deferred
execution of kacpid, if we had any notify requests pending, but Linus
decided that it was too complex (involved either changes to workqueue
to see if it's empty or atomic inc/dec).  Then a 5th attempt did a
yield() to every GPE execution.

Finally, this 6th generation patch simply executes the notify handler
on the stack.  Previous attempts to do this simple solution failed
because of issues in AML mutex re-entrancy which are now fixed
by the previous patch in this series.

http://bugzilla.kernel.org/show_bug.cgi?id=5534Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI AML supports "serialized" methods which are protected
by an implicit mutex.  The mutex is re-entrant for that AML thread
to allow recursion.

However, Linux implements notify() by creating a new AML thread.
So for systems where notify() re-enters a serialized method,
deadlock results.

The fix is to use the Linux thread_id as the key to allowing
re-entrancy, not the AML thread pointer.

http://bugzilla.kernel.org/show_bug.cgi?id=5534Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there.  Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.

To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm.  I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>