Split ACPI_DEBUG into function trace enabled and not enabled.
Function trace is most of the ACPI_DEBUG costs, but is
not much of use for kernel ACPI debugging.
Size of kernel image increased on test compile:
+ 48k (Full ACPI_DEBUG)
+ 35k (ACPI_DEBUG with function trace compiled out)
Performance without function trace is also much better.
Also remove ACPI_LV_DEBUG_OBJECT from default debug level as
a lot vendors let Store (value, debug) in their code and this
might confuse users when it pops up in syslog.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
This is an incremental patch for the recent genetlink
multicast changes.
Now ACPI events are exported via generic netlink multicast group.
Thanks for Johannes' help on developing this patch
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
ACPI has a ton of macros which make a bunch of empty if's when configured
in non-debug mode.
[lenb: The code it complaines about is functionally correct,
so this patch is just to make -Wextra happier]
#define DBG()
if(...)
DBG();
next_c_statement
which turns into
if(...) ;
next_c_statement
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
For NUMA emulation, our SLIT should represent the true NUMA topology of the
system but our proximity domain to node ID mapping needs to reflect the
emulated state.
When NUMA emulation has successfully setup fake nodes on the system, a new
function, acpi_fake_nodes() is called. This function determines the proximity
domain (_PXM) for each true node found on the system. It then finds which
emulated nodes have been allocated on this true node as determined by its
starting address. The node ID to PXM mapping is changed so that each fake
node ID points to the PXM of the true node that it is located on.
If the machine failed to register a SLIT, then we assume there is no special
requirement for emulated node affinity so we use the default LOCAL_DISTANCE,
which is newly exported to this code, as our measurement if the emulated nodes
appear in the same PXM. Otherwise, we use REMOTE_DISTANCE.
PXM_INVAL and NID_INVAL are also exported to the ACPI header file so that we
can compare node_to_pxm() results in generic code (in this case, the SRAT
code).
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In acpi_scan_nodes(), we immediately return -1 if acpi_numa <= 0, meaning
we haven't detected any underlying ACPI topology or we have explicitly
disabled its use from the command-line with numa=noacpi.
acpi_table_print_srat_entry() and acpi_table_parse_srat() are only
referenced within drivers/acpi/numa.c, so we can mark them as static and
remove their prototypes from the header file.
Likewise, pxm_to_node_map[] and node_to_pxm_map[] are only used within
drivers/acpi/numa.c, so we mark them as static and remove their externs
from the header file.
The automatic 'result' variable is unused in acpi_numa_init(), so it's
removed.
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
[IA64] Prevent people from directly including <asm/rwsem.h>.
[IA64] remove time interpolator
[IA64] Convert to generic timekeeping/clocksource
[IA64] refresh some config files for 64K pagesize
[IA64] Delete iosapic_free_rte()
[IA64] fallocate system call
[IA64] Enable percpu vector domain for IA64_DIG
[IA64] Enable percpu vector domain for IA64_GENERIC
[IA64] Support irq migration across domain
[IA64] Add support for vector domain
[IA64] Add mapping table between irq and vector
[IA64] Check if irq is sharable
[IA64] Fix invalid irq vector assumption for iosapic
[IA64] Use dynamic irq for iosapic interrupts
[IA64] Use per iosapic lock for indirect iosapic register access
[IA64] Cleanup lock order in iosapic_register_intr
[IA64] Remove duplicated members in iosapic_rte_info
[IA64] Remove block structure for locking in iosapic.c
This is a merge of Peter Keilty's initial patch (which was
revived by Bob Picco) for this with Hidetoshi Seto's fixes
and scaling improvements.
Acked-by: Bob Picco <bob.picco@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Slab destructors were no longer supported after Christoph's
c59def9f22 change. They've been
BUGs for both slab and slub, and slob never supported them
either.
This rips out support for the dtor pointer from kmem_cache_create()
completely and fixes up every single callsite in the kernel (there were
about 224, not including the slab allocator definitions themselves,
or the documentation references).
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Introduce the pm_power_off_prepare() callback that can be registered by the
interested platforms in analogy with pm_idle() and pm_power_off(), used for
preparing the system to power off (needed by ACPI).
This allows us to drop acpi_sysclass and device_acpi that are only defined in
order to register the ACPI power off preparation callback, which is needed by
pm_power_off() registered in a much different way.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since we are now explicitly calling hibernation_ops->prepare() before
hibernation_ops->enter() in hibernation_platform_enter() (defined in
kernel/power/disk.c), ACPI should not call acpi_sleep_prepare(ACPI_STATE_S4)
from acpi_shutdown().
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At least on some machines it is necessary to prepare the ACPI firmware for the
restoration of the system memory state from the hibernation image if the
"platform" mode of hibernation has been used. Namely, in that cases we need
to disable the GPEs before replacing the "boot" kernel with the "frozen"
kernel (cf. http://bugzilla.kernel.org/show_bug.cgi?id=7887). After the
restore they will be re-enabled by hibernation_ops->finish(), but if the
restore fails, they have to be re-enabled by the restore code explicitly.
For this purpose we can introduce two additional hibernation operations,
called pre_restore() and restore_cleanup() and call them from the restore code
path. Still, they should be called if the "platform" mode of hibernation has
been used, so we need to pass the information about the hibernation mode from
the "frozen" kernel to the "boot" kernel in the image header.
Apparently, we can't drop the disabling of GPEs before the restore because of
Bug #7887 . We also can't do it unconditionally, because the GPEs wouldn't
have been enabled after a successful restore if the suspend had been done in
the 'shutdown' or 'reboot' mode.
In principle we could (and probably should) unconditionally disable the GPEs
before each snapshot creation *and* before the restore, but then we'd have to
unconditionally enable them after the snapshot creation as well as after the
restore (or restore failure) Still, for this purpose we'd need to modify
acpi_enter_sleep_state_prep() and acpi_leave_sleep_state() and we'd have to
introduce some mechanism synchronizing the disablind/enabling of the GPEs with
the device drivers' .suspend()/.resume() routines and with
disable_/enable_nonboot_cpus(). However, this would have affected the
suspend (ie. s2ram) code as well as the hibernation, which I'd like to avoid
in this patch series.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On systems that do not have pm2_control_block, we cannot really use
ARB_DISABLE before C3. We used to disable C3 totally on such systems.
To be compatible with Windows, we need to enable C3 on such systems now.
We just skip ARB_DISABLE step before entering the C3-state and assume
hardware is handling things correctly. Also, ACPI spec is not clear
about pm2_control is _needed_ for C3 or not.
We have atleast one system that need this to enable C3.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_ev_pci_config_region_setup() leaks pci_id
in the error case of "if (!pci_device_node)"
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Data returned by acpi_get_name in acpi_buffer is not acpi_object and
therefore should not be cast to it, otherwise we'll get an nice oops
trying to print error message.
Also print name of the ACPI object corresponding to the docking station
and elevate severity of the message printed when _DCK fails to KERN_ERR.
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Various pieces of code around the kernel want to be able to trigger an
orderly poweroff. This pulls them together into a single
implementation.
By default the poweroff command is /sbin/poweroff, but it can be set
via sysctl: kernel/poweroff_cmd. This is split at whitespace, so it
can include command-line arguments.
This patch replaces four other instances of invoking either "poweroff"
or "shutdown -h now": two sbus drivers, and acpi thermal
management.
sparc64 has its own "powerd"; still need to determine whether it should
be replaced by orderly_poweroff().
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Acked-by: Len Brown <lenb@kernel.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Andi Kleen <ak@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David S. Miller <davem@davemloft.net>
Convert the backlight and LCD classes from struct class_device
to struct device since class_device is scheduled for removal.
One nasty API break is the backlight power attribute has had to be
renamed to bl_power and the LCD power attribute has had to be renamed
to lcd_power since the original names clash with the core. I can't see
a way around this.
Signed-off-by: Richard Purdie <rpurdie@rpsys.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Instead of all drivers reading pci config space to get the revision
ID, they can now use the pci_device->revision member.
This exposes some issues where drivers where reading a word or a dword
for the revision number, and adding useless error-handling around the
read. Some drivers even just read it for no purpose of all.
In devices where the revision ID is being copied over and used in what
appears to be the equivalent of hotpath, I have left the copy code
and the cached copy as not to influence the driver's performance.
Compile tested with make all{yes,mod}config on x86_64 and i386.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Acked-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Upon ACPI events, send an "acpi_event" via Generic Netlink.
This is in addition to /proc/acpi/event, which remains intact for now.
Thanks to Jamal for his great help.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixed a problem with the internal FADT conversion where ACPI 1.0
FADTs that contained invalid non-zero values in reserved fields
could cause later failures because these fields have meaning in
later revisions of the FADT. For incoming ACPI 1.0 FADTs, these
fields are now always zeroed. (Preferred_PM_Profile, PSTATE_CNT,
CST_CNT, IAPC_BOOT_FLAGS.)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fixed a problem in acpi_ev_delete_gpe_xrupt where the global interrupt
list could be corrupted if the interrupt being removed was at
the head of the list. Reported by Linn Crosetto.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Latest update for the Windows strings, with comments. Removed
unused strings.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
If we have quirk "init... after standby", we should not be calling it while
resuming from hibernation. And... that quirk is only ever needed on toshiba
4030cdt... and... noone should be using standby these days, anyway.
That quirk was certainly _not_ meant to be ran after hibernation.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Use menuconfigs instead of menus, so the whole menu can be disabled at once
instead of going through all options.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Currently the acpi video module export the backlight interface to sysfs
also if acpi_video_device_lcd_query_levels() fails to read _BLC method
(e.g. because the method is not available). In this case the userspace
don't know which brightness level are supported and can't set a brightness
level (echo return with: "write error: Invalid Argument"). This happend
e.g. on a ASUS RF1 (correct supported by the asus-laptop module).
The video module should not export the backlight interface if query _BLC fail,
because you can't set anything from userspace and this make it useless.
http://bugzilla.kernel.org/show_bug.cgi?id=8375
Signed-off-by: Danny Kukawka <dkukawka@suse.de>
Acked-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
make the needlessly global osi_linux static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
make 2 needlessly global functions static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Need to check for special case "acpi_osi=!Linux" before handling the
general case "acpi_osi=!*", or it will have no effect.
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If asus_acpi_init doesn't find any device it knows about, it mistakenly
returns a "success" error code even though it cleans up after itself. Later
when trying to rmmod asus_acpi, the module_exit routine would try to clean up
one more time and we would end up calling
acpi_bus_unregister_driver(&asus_hotk_driver) twice. This patch addresses
this first problem by returning -ENODEV when no appropriate device is found.
Then there was also another bug with the code handling the return value of
backlight_device_register. If this function ever failed, the driver would
cleanup by calling the module_exit routine from module_init, but it would
still return "success". So any attempt to rmmod this module would result in
asus_acpi_exit being called twice but it's not ready to handle it (I haven't
hit this bug, just found it by code inspection). This patch fixes that by
inserting a return -ENODEV; at the end of this error handling path.
Signed-off-by: Maxime Austruy <maxime@tralhalla.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Always disable/enable interrupts in the acpi idle routine,
even in the error path.
This is required as the 2.6.20 change in git commit d331e739f5ad2aaa9...
"Fix interrupt race in idle callback" expects the idle handler
to enable interrupt before returning.
There was a case in acpi idle routine, in which interrupt was not being
enabled before return, which caused the system to hang at bootup, while
enabling C-states on an SMP system.
The signature of the hang was that "processor.nocst"
was required to enable boot.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
asus_acpi_init() has a hack to prevent the driver from loading
when asus_hotk_add() fails. However, it was returning the successful
return value of acpi_bug_registger_driver() on failure. This caused
an oops on unload. Instead it should return -ENODEV.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
In the routine acpi_ut_create_package_object(), if the
ACPI_ALLOCATE_ZEROED() fails then ACPI_FREE(package_desc) is called as
part of the cleanup. This should instead be
acpi_ut_remove_reference(package_desc) in order to remove the reference
acquired from acpi_ut_create_internal_object() [see the routine
acpi_ut_create_buffer_object() as an example of proper functionality].
Signed-off-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
if acpi_bus_get_device() returns NULL, print nothing
instead of "<NUL" in /proc/acpi/thermal_zone/*/trip_points
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix section error (allyesconfig). The exit function is called from init,
so functions that are called by the exit function cannot be marked __exit.
WARNING: drivers/built-in.o(.text+0xe5bc6): Section mismatch: reference to .exit.
text: (between 'toshiba_acpi_exit' and 'hci_raw')
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In Linux-2.6.22 we expanded the boot parameter osi=
so that it can enable and !enable an OSI string.
_OSI(Linux) is a special case because we know that there
are both systems that require it set, and systems
require that it _not_ to be set. In the long term it can't
be set, for the same reason _OS(Linux) can't be enabled --
it tends to confuse BIOS that are not properly
validated with Linux. Further, the semantics and version
information of _OSI(Linux) were never actually defined.
The kernel prints out a message if it sees _OSI(Linux)
requested, and there is a DMI workaround to invoke
"osi=Linux" automatically for existing systems that need it.
http://bugzilla.kernel.org/show_bug.cgi?id=7787
Signed-off-by: Len Brown <len.brown@intel.com>
Make the bay driver send env information on bay events.
Upon any bay event, we will send the string "BAY_EVENT=%d" along with the
KOBJ_CHANGE, and report the event number. What the event number means will
be platform specific. Event 3 is always an eject request, but an insert
may be either event 1, or it may be event 0. Event 1 may also be a
remove request. It would be best if you check the number of your event
with udevmonitor before writing any udev scripts for inserting and
removing drive bays.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Stephan Berberig <s.berberig@arcor.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Implemented support to allow Package objects to be passed as
method arguments to the acpi_evaluate_object interface. Previously,
this would return an AE_NOT_IMPLEMENTED exception.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Last of the "Section mismatch" errors from ia64 builds! acpi_map_pxm_to_node()
is defined with attribute __cpuinit, but is called by "normal" kernel functions
acpi_getnode() and acpi_map_cpu2node().
Commit f363d16fbb moved the data structures on
which this routine operates from __cpuinitdata to regular memory, so this
routine can also move out of init space.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix following section mismatch warnings in acpi
WARNING: drivers/acpi/asus_acpi.o(.init.text+0xb7): Section mismatch: reference to .exit.text: (after 'init_module')
WARNING: o-i386/drivers/acpi/toshiba_acpi.o(.init.text+0x13a): Section mismatch: reference to .exit.text: (after 'init_module')
The exit function is used in the init function during an error codition.
As __exit may be discarded during link-time / run-time this is no good.
Do not mark the exit function __exit.
Note: This warning is only seen by my local copy of modpost
but the change will soon hit upstream.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add __init to:
acpi_initialize_subsystem() (and un-export it)
acpi_os_initialize()
Add __initdata to:
acpi_osl_dmi_table[]
Signed-off-by: Len Brown <len.brown@intel.com>
_OSI("Linux") is like _OS("Linux"), it is ill-defined and
virtually no BIOS vendors test interaction with it.
As a result, it can do more damage than good because
it causes the BIOS to follow un-tested paths.
Recently, several machines have turned up that erroneously
test this string in a way which causes them to _not_ test other
compatibility strings, including the ZI9 and Toshiba.
So it appears that this bad code has made it into
a BIOS vendor's reference BIOS.
Linux has no choice but to stop advertising compatibility
with _OSI string "Linux" - as there are an unbounded
number of possible incompatibilities going forward.
But some BIOSes have already shipped which do use it
for things like conditionally re-enabling video on resume
from S3. (Too bad they didn't do that unconditionally)
Add special case code for _OSI(Linux)
Squawk to dmesg if _OSI(Linux) is requested
Add DMI list both to enable and disable _OSI(Linux)
But for now, keep the default enabled via
#define OSI_LINUX_ENABLED.
http://bugzilla.kernel.org/show_bug.cgi?id=7787
Signed-off-by: Len Brown <len.brown@intel.com>
The boot option "acpi_osi=" has always disabled Linux _OSI support,
thus disabling all OS Interface strings which are advertised
by Linux to the BIOS.
Now...
acpi_osi="string" adds the interface string, and
acpi_osi="!string" invalidates the pre-defined interface string
eg. acpi_osi="!Windows 2006"
would disable Linux's claim of Vista compatibility.
Signed-off-by: Len Brown <len.brown@intel.com>
For users with active thermal trip points, they need
the fan's name, rather than its address, to understand
where to look to observe and control fan state.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
HP and Hitachi machines have been implemented with SSDT's
that use the "OEMx" signatures. But upon Load, ACPICA is rejecting
these tables because they are not using the "SSDT" signature.
ACPI Error (tbinstal-0134): Table has invalid signature [OEMx], must be SSDT...
Signed-off-by: Len Brown <len.brown@intel.com>
Strip __cpuinit[data] from Node <-> PXM routines and supporting data
structures. Also make pxm_to_node_map and node_to_pxm_map local to the
numa acpi module.
This fixes a bug triggered by the following conditions:
- boot on a machine with a SLIT table defined
- kernel is configured w/ CONFIG_HOTPLUG_CPU=n
- cat /sys/devices/system/node/node*/distance
This will cause an oops by calling into a freed memory section.
In particular, on x86_64, __node_distance calls node_to_pxm().
Signed-off-by: Aaron Durbin <adurbin@google.com>
Cc: Len Brown <lenb@kernel.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In response to review comments from Andrew Morton
Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI EC that is used in MSI laptops knows some non-standard
commands for changing the screen brighntess and a few other things,
which are used by the msi-laptop.c driver. Unfortunately for these
commands no GPE events for IBF and OBF are triggered. Since nowadays
the EC code uses the ec_intr=1 mode by default, this causes these
operations to timeout, although they don't fail. In result, all
operations that you can do with the msi-laptop.c driver take more or
less 1s to complete, which is awfully slow.
In one of the more recent kernels (2.6.20?) the EC subsystem has been
revamped. With that change the EC timeout has been increased. before
that increase the MSI EC accesses were slow -- but not *that* slow,
hence I took notice of this limitation of the MSI EC hardware only very
recently.
The standard EC operations on the MSI EC as defined in the ACPI spec
support GPE events properly.
The following patch adds a new argument "force_poll" to the
ec_transaction() function (and friends). If set to 1, the function
will poll for IBF/OBF even if ec_intr=1 is enabled. If set to 0 the
current behaviour is used. The msi-laptop driver is modified to make
use of this new flag, so that OBF/IBF is polled for the special MSI EC
transactions -- but only for them.
Signed-off-by: Lennart Poettering <mzxreary@0pointer.de>
Acked-by: Alexey Starikovskiy <aystarik@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Since platform devices seem to get uevents suppressed by default,
manually unsuppress for the bay device since we want to be able
to send uevents.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Send an env along with our KOBJ_CHANGE uevent so that user space has
the option of checking for that to see if a dock or undock has occurred.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Platform devices may not send uevents by default - override the setting
so that we can send uevents on dock/undock.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Allow the driver to be loaded with an option that will allow userspace to
control whether the laptop is ejected immediately when the user presses the
button, or only when the syfs undock file is written.
if immediate_undock == 1, then when the user presses the undock button, the
laptop will send an event to userspace to notify userspace of the undock, but
then immediately undock without waiting for userspace. This is the current
behavior, and I set this to be the default.
if immediate_undock == 0, then when the user presses the undock button, the
laptop will send an event to userspace and do nothing. User space can query
the "flags" sysfs entry to determine if an undock request has been made by
the user (if bit 1 is set). User space will then need to write the undock
sysfs entry to complete the undocking process.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Get rid of no release function warnings by switching to dynamically
allocating the platform_device and using the platform device release
routine in the base driver.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
The driver tests the dock_station pointer for nonnull
to check whether it has initialized properly. But in
some cases dock_station will be non-null after being
freed when driver init fails. Fix by zeroing the
pointer after freeing.
Signed-off-by: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Make uid sysfs file error path free memory, and cleanup sysfs file
when removing driver. Also fix CodingStyle violations.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Illya A. Volynets-Evenbakh <ilya@total-knowledge.com>
Signed-off-by: Len Brown <len.brown@intel.com>
HP nx6125/nx6325/... machines have a _GPE handler with an infinite
loop sending Notify() events to different ACPI subsystems.
Notify handler in ACPI driver is a C-routine, which may call ACPI
interpreter again to get access to some ACPI variables
(acpi_evaluate_xxx).
On these HP machines such an evaluation changes state of some 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 increase in memory consumption
noticed by author of the thread. Also as GPE handling is bloked,
machines overheat. 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 all these horrors it's needed to not put notify events to
kacpid workqueue by either executing them immediately or putting them
on some other thread. It's dangerous to execute notify events in
place, as it will put several ACPI interpreter stacks on top of each
other (at least 4 in case of nx6125), thus causing kernel stack
overflow.
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 kernel shipped with Ubuntu 6.06 LTS.
Second attempt was done by me, I 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 18-rc2 as I remember.
I 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 I did not received reply
from Linus on a test patch sent to him.
Patch went to 19-rc and was rejected with much fanfare again.
There was 4th patch, which 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).
Now you see last variant which adds yield() to every GPE execution.
http://bugzilla.kernel.org/show_bug.cgi?id=5534http://bugzilla.kernel.org/show_bug.cgi?id=8385
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit c0d127b569.
These changes to AML locking were made to allow
Notify handlers to be called on the stack
and not deadlock. However, that scheme turns
out to be flawed and was reverted by the previous commit,
so this commit restores the locking to it previous design.
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit a8f4af6dc6.
Thus restoring ACPICA's new acpi_serialize code.
This commit by itself may cause a regression, but
it is reverted in this order so that subsequent
reverts reverts under this one can be made
without conflict.
Signed-off-by: Len Brown <len.brown@intel.com>
Requires CONFIG_VIDEO_OUTPUT_CONTROL and CONFIG_ACPI_VIDEO.
After loading output.ko and video.ko, you would have
/sys/class/video_output and several device acpi_videoNum there.
For example, I got acpi_video0, acpi_video1,acpi_video2,and acpi_video3
under /sys/class/video_output on my T40.
I can query the status of output device0 by running " cat
/sys/class/video_output/acpi_video0
" The return value is defined in ACPI SPEC B.5.5 _DCS(Return the
Status of Output Device). Also you can turn off video1 and turn on
video0 by " echo 0 > acpi_video1; echo 0x80000000 > acpi_video0".
Please reference ACPI SPEC B.5.7 _DSS for the parameter definition.
Please note that it may or may NOT works purely depending on if
your vendor providing correct ACPI video extension support in bios.
the driver output.ko and video.ko just works like a interface to
invoke BIOS.
Signed-off-by: Luming Yu <Luming.yu@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
[ With Johannes Berg <johannes@sipsolutions.net> ]
Separate the hibernation (aka suspend to disk code) from the other suspend
code. In particular:
* Remove the definitions related to hibernation from include/linux/pm.h
* Introduce struct hibernation_ops and a new hibernate() function to hibernate
the system, defined in include/linux/suspend.h
* Separate suspend code in kernel/power/main.c from hibernation-related code
in kernel/power/disk.c and kernel/power/user.c (with the help of
hibernation_ops)
* Switch ACPI (the only user of pm_ops.pm_disk_mode) to hibernation_ops
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Greg KH <greg@kroah.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Nigel Cunningham <nigel@nigel.suspend2.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is to fix unnecessary __meminit definition. These are exported for
kernel modules.
I compiled on ia64/x86-64 with memory hotplug on/off.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This works around a bug seen in some RTC-related ACPI table entries, and
tweaks related diagnostics to follow the ACPI convention.
The bug prevents misleading boot-time messages: platforms affected by this
bug wrongly report they can support alarms up to one year in the future,
when in fact the longest alarm is just 24 hours. That will surprise anyone
trying to use those extended alarms.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove /proc/acpi/alarm file when the rtc-cmos "wakealarm" file is available.
Instead, provide hooks that rtc-cmos will use.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Teach PNPACPI how to hook up its devices to their ACPI nodes, so that
pnpdev->dev.archdata points to the parallel acpi device node. Previously
this only worked for PCI, leaving a notable hole.
Export "acpi_bus_type" so this can work.
Remove some extraneous whitespace.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Adam Belay <ambx1@neo.rr.com>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove includes of <linux/smp_lock.h> where it is not used/needed.
Suggested by Al Viro.
Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
sparc64, and arm (all 59 defconfigs).
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is to fix many section mismatches of code related to memory hotplug.
I checked compile with memory hotplug on/off on ia64 and x86-64 box.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Remove software_suspend() and all its users since
pm_suspend(PM_SUSPEND_DISK) should be equivalent and there's no point in
having two interfaces for the same thing.
The patch also changes the valid_state function to return 0 (false) for
PM_SUSPEND_DISK when SOFTWARE_SUSPEND is not configured instead of
accepting it and having the whole thing fail later.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: (231 commits)
[PATCH] i386: Don't delete cpu_devs data to identify different x86 types in late_initcall
[PATCH] i386: type may be unused
[PATCH] i386: Some additional chipset register values validation.
[PATCH] i386: Add missing !X86_PAE dependincy to the 2G/2G split.
[PATCH] x86-64: Don't exclude asm-offsets.c in Documentation/dontdiff
[PATCH] i386: avoid redundant preempt_disable in __unlazy_fpu
[PATCH] i386: white space fixes in i387.h
[PATCH] i386: Drop noisy e820 debugging printks
[PATCH] x86-64: Fix allnoconfig error in genapic_flat.c
[PATCH] x86-64: Shut up warnings for vfat compat ioctls on other file systems
[PATCH] x86-64: Share identical video.S between i386 and x86-64
[PATCH] x86-64: Remove CONFIG_REORDER
[PATCH] x86-64: Print type and size correctly for unknown compat ioctls
[PATCH] i386: Remove copy_*_user BUG_ONs for (size < 0)
[PATCH] i386: Little cleanups in smpboot.c
[PATCH] x86-64: Don't enable NUMA for a single node in K8 NUMA scanning
[PATCH] x86: Use RDTSCP for synchronous get_cycles if possible
[PATCH] i386: Add X86_FEATURE_RDTSCP
[PATCH] i386: Implement X86_FEATURE_SYNC_RDTSC on i386
[PATCH] i386: Implement alternative_io for i386
...
Fix up trivial conflict in include/linux/highmem.h manually.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Change mark_tsc_unstable() so it takes a string argument, which holds the
reason the TSC was marked unstable.
This is then displayed the first time mark_tsc_unstable is called.
This should help us better debug why the TSC was marked unstable on certain
systems and allow us to make sure we're not being overly paranoid when
throwing out this troublesome clocksource.
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
The scheme where the thermal driver displayed the
cooling mode /proc/acpi/thermal_zone/*/cooling_mode
was flawed in two ways.
First, the success of _SCP doesn't actually mean
that the BIOS moved any trip points.
On many BIOS, _SCP is present, but does nothing.
So displaying what _SCP executed actually
was wrong more times than it was right.
Second, examining the relative position of the
trip points when the thermal_zone is added
is insufficient -- as the BIOS reserves the right
to change the trip points at run-time.
The only reliable way for the user to determine if
the thermal zone is in active, passive, or critical
mode is to examine the relative position of the trip points.
The user can do this without the kernel doing it
for them by looking in /proc/acpi/thermal_zone/*/trip_points
New contents for /proc/acpi/thermal_zone/*/cooling_mode:
If _SCP available:
"0 - Active; 1 - Passive\n"
If _SCP unavailable:
"<setting not supported>\n"
Signed-off-by: Len Brown <len.brown@intel.com>
/proc/acpi/thermal_zone/*/trip_points displays
what the kernel reads from the BIOS via ACPI.
If you echo a string of ':' deliminted numbers to this file
then it will change what it displays.
But it shouldn't, since the kernel has no way to communicate
these changes to ACPI thermal zones. ACPI thermal zone
trip points are read-only.
The kernel does have the opportunity to ask the BIOS to change
the trip points with _SCP - Set Cooling Policy.
Request Active Cooling Mode:
# echo 0 > /proc/acpi/thermal_zone/*/cooling_policy
Request Passive Cooling Mode:
# echo 1 > /proc/acpi/thermal_zone/*/cooling_policy
However, in practice it is quite rare for the BIOS
to support the optional _SCP, and it is even more rare
for the BIOS to export an _SCP that actually changes
the trip points.
Signed-off-by: Len Brown <len.brown@intel.com>
Almost all users of pm_ops only support mem sleep, don't check in .valid and
don't reject any others in .prepare so users can be confused if they check
/sys/power/state, especially when new states are added (these would then
result in s-t-r although they're supposed to be something different).
This patch implements a generic pm_valid_only_mem function that is then
exported for users and puts it to use in almost all existing pm_ops.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: David Brownell <david-b@pacbell.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Cc: linux-pm@lists.linux-foundation.org
Cc: Len Brown <lenb@kernel.org>
Acked-by: Russell King <rmk@arm.linux.org.uk>
Cc: Greg KH <greg@kroah.com>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linux-2.6.21 stopped booting on a P4/HT because Linux
wrote the FADT.CST_CNT value to the SMI_CMD.
Apparently this stumbled over some SMM instability,
such as confusing SMM when invoking it from cpu1.
Linux did this because even though the r2 FADT reserves
the CST_CNT field, this BIOS set that field and Linux
used it.
Turns out that up through 2.6.20 we explicitly cleared
cst_control for r2 FADTs. So here we go back to doing that,
plus also clear some additional fields that are reserved
until FADT r3.
http://bugzilla.kernel.org/show_bug.cgi?id=8346
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Remove deprecated /proc/acpi/processor/performance write support
Writing to /proc/acpi/processor/xy/performance interferes with sysfs
cpufreq interface. Also removes buggy cpufreq_set_policy exported symbol.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device. Example:
Device S-state Status Sysfs node
PCI0 S4 disabled no-bus:pci0000:00
PS2M S4 disabled pnp:00:05
PS2K S4 disabled pnp:00:06
UAR1 S4 disabled pnp:00:08
USB1 S3 disabled pci:0000:00:03.0
USB2 S3 disabled pci:0000:00:03.1
USB3 S3 disabled
USB4 S3 disabled pci:0000:00:03.3
S139 S4 disabled
LAN S4 disabled pci:0000:00:04.0
MDM S4 disabled
AUD S4 disabled pci:0000:00:02.7
SLPB S4 *enabled
Eventually this file should be removed, but until then it's almost the only
way we have to tell how the relevant ACPI tables are broken (and cope). In
that example, two devices don't actually exist (USB3, S139), one can't issue
wakeup events (PCI0), and two seem harmlessly (?) confused (MDM and AUD are
the same PCI device, but it's the _modem_ that does wake-on-ring).
In particular, we need to be sure driver model nodes are properly hooked
up before we can get rid of this ACPI-only interface for wakeup events.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Be explicit about what "device->status = 0x0F" really means.
syntax only.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
No need to duplicate the existing definitions in include/acpi/actypes.h.
syntax only -- no functional change.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Thomas's patch for including <asm/apic.h> for x86 UP builds came into
Linus's tree from two different directions, both of which were merged.
This reverts the latter, yanking out the duplicate #include and comment.
Signed-off-by: Ray Lee <ray-lk@madrabbit.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Use relative time, not absolute. Discovered by Jung-Ik (John) Lee
<jilee@google.com>.
Cc: Jung-Ik (John) Lee <jilee@google.com>
Acked-by: Len Brown <lenb@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use NULL instead of 0 for pointers:
drivers/acpi/dock.c:677:75: warning: Using plain integer as NULL pointer
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Len Brown <len.brown@intel.com>
ibm-acpi is not an ACPICA driver, so move it to drivers/misc as per Len
Brown's request.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Update copyright and license info on the source code comments. No
functional changes.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Shuffle code around to better organize the driver code inside the
ibm-acpi.c file.
This patch adds no functional changes. It is pure fluff that will make me
a bit more productive.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Add a (private) header file for ibm-acpi, and move type definitions and
ThinkPad driver constants to the new header file.
This patch has no functional changes.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
Rename some identifiers so that they are more in tune with the rest of the
driver code, or less generic.
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
I shall protect the ibm-acpi city against the invasion of the barbarian
blanks! To the unforgiving jaws of sed s/[[:blank:]]\+$// they go!
Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Signed-off-by: Len Brown <len.brown@intel.com>
It turned out that it is almost impossible to trust ACPI, BIOS & Co.
regarding the C states. This was the reason to switch the local apic
timer off in C2 state already. OTOH there are sane and well behaving
systems, which get punished by that decision.
Allow the user to confirm that the local apic timer is trustworthy in C2
state. This keeps the default behaviour on the safe side.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 25496caec1, which
broke bootup on at least Ingo's ThinkPad T60. Need to figure out
exactly what is wrong before we can re-do the logic.
Requested-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Renninger <trenn@suse.de>
Cc: Len Brown <len.brown@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The SBS driver has tne features as CM battery:
SBS update_time variable has tne same definition as CM battery 'update_time' variable.
Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Debug messages correction/improvement:
Use ACPI_EXCEPTION instead of ACPI_DEBUG_PRINT.
Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
SBS does not depend on I2C.
i2c_ec.h and i2c_ec.c are not needed
Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
SBS is based on EC function(ec_read/ec_write).
Not needed using of I2C structures/functions ... is removed.
SBS does not depend on I2C now.
Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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: Thomas Renninger <trenn@suse.de>
Signed-off-by: Len 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: Henrique 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: Len Brown <len.brown@intel.com>
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: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Acked-by: Ray 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: Len Brown <len.brown@intel.com>
