This patch breaks C-state discovery on my IBM IntelliStation Z30 because
the return value of acpi_processor_get_power_info_fadt is not assigned to
"result" in the case that acpi_processor_get_power_info_cst returns
-ENODEV. Thus, if ACPI provides C-state data via the FADT and not _CST (as
is the case on this machine), we incorrectly exit the function with -ENODEV
after reading the FADT. The attached patch sets the value of result so
that we don't exit early.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
Acked-by: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Acked-by: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
drivers/acpi/processor_idle.c:1112: warning: 'smp_callback' defined but not used
Cc: Len Brown <lenb@kernel.org>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add ->resume method to the ACPI battery handler to check
if the battery state has changed during sleep.
If yes, update the ACPI internal data structures
for benefit of /proc/acpi/battery/.
Signed-off-by: Jiri Kosina <jikos@jikos.cz>
Cc: Stefan Seyfried <seife@suse.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
I could not get correct PCI Express bus number from the structure of
acpi_object_extra. I always get zero as bus number regardless of bus
location. I found that there is incorrect comparison with _HID (PNP0A08) in
acpi/events/evrgnini.c and PCI Express _BBN method always fail.
Therefore, we always get zero as PCI Express bus number.
http://bugzilla.kernel.org/show_bug.cgi?id=7145
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This reporting is useless (we errno anyway).
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
ICC complains about a "Pointless comparsion of unsigned interger with zero"
@ line 760 & 808 of asus_acpi.c
parse_arg() mentioned below returns -E but it's copied into unsigned variable...
Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix printk format warnings in drivers/acpi:
drivers/acpi/tables/tbget.c:326: warning: format '%X' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
drivers/acpi/tables/tbrsdt.c:189: warning: format '%X' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The ACPI processor init functions should be marked as __cpuinit as they use
structures marked with __cpuinitdata.
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_pci_link_set() allocates both with interrupts on
and with interrupts off (resume-time), so check interrupts
and decide on GFP_ATOMIC or GFP_KERNEL at run-time.
Signed-off-by: Jiri Kosina <jikos@jikos.cz>
Signed-off-by: Len Brown <len.brown@intel.com>
device was set to null and used before set in a debug printk
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Len Brown <len.brown@intel.com>
On acquiring the ACPI global lock, if there were sleepers on the lock,
we used to use acpi_os_execute() to defer a thread which would signal
sleepers. Now just signal the semaphore directly.
http://bugzilla.kernel.org/show_bug.cgi?id=5534#c159
Signed-off-by: Len Brown <len.brown@intel.com>
Simplify acpi_hw_low_level_xxx() functions to inb() and outb().
Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Remove unnecessary delay (50 ms) while reading data from EC in interrupt mode.
Signed-off-by: Alexey Y. Starikovskiy <alexey.y.starikovskiy@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Unify the following functions:
acpi_ec_poll_read()
acpi_ec_poll_write()
acpi_ec_poll_query()
acpi_ec_intr_read()
acpi_ec_intr_write()
acpi_ec_intr_query()
into:
acpi_ec_poll_transaction()
acpi_ec_intr_transaction()
These new functions take as arguments an ACPI EC command, a few bytes
to write to the EC data register and a buffer for a few bytes to read
from the EC data register. The old _read(), _write(), _query() are
just special cases of these functions.
Then unified the code in acpi_ec_poll_transaction() and
acpi_ec_intr_transaction() a little more. Both functions are now just
wrappers around the new acpi_ec_transaction_unlocked() function. The
latter contains the EC access logic, the two original
function now just do their special way of locking and call the the
new function for the actual work.
This saves a lot of very similar code. The primary reason for doing
this, however, is that my driver for MSI 270 laptops needs to issue
some non-standard EC commands in a safe way. Due to this I added a new
exported function similar to ec_write()/ec_write() which is called
ec_transaction() and is essentially just a wrapper around
acpi_ec_{poll,intr}_transaction().
Signed-off-by: Lennart Poettering <mzxreary@0pointer.de>
Acked-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
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 <venkatesh.pallipadi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
The brightness and volume features from ibm-acpi are stable.
The experimental flag is no longer needed.
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Acked-by: Borislav Deianov <borislav@users.sourceforge.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Add support for W3000 (W3V) and indirectly fixes an issue with kmilo under KDE
(it was triggering excessive LCD read error messages by querying asus_acpi
module) allowing people (I am probably the only one who tested this) with
W3000 to run kmilo.
Cc: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
This is needed by at least the Mac Mini's, which (incorrectly) come back
from suspend with SCI_EN clear.
Thanks to Frédéric Riss for hunting this down.
Acked-by: Frédéric Riss <frederic.riss@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <len.brown@intel.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Maintain a per-CPU global "struct pt_regs *" variable which can be used instead
of passing regs around manually through all ~1800 interrupt handlers in the
Linux kernel.
The regs pointer is used in few places, but it potentially costs both stack
space and code to pass it around. On the FRV arch, removing the regs parameter
from all the genirq function results in a 20% speed up of the IRQ exit path
(ie: from leaving timer_interrupt() to leaving do_IRQ()).
Where appropriate, an arch may override the generic storage facility and do
something different with the variable. On FRV, for instance, the address is
maintained in GR28 at all times inside the kernel as part of general exception
handling.
Having looked over the code, it appears that the parameter may be handed down
through up to twenty or so layers of functions. Consider a USB character
device attached to a USB hub, attached to a USB controller that posts its
interrupts through a cascaded auxiliary interrupt controller. A character
device driver may want to pass regs to the sysrq handler through the input
layer which adds another few layers of parameter passing.
I've build this code with allyesconfig for x86_64 and i386. I've runtested the
main part of the code on FRV and i386, though I can't test most of the drivers.
I've also done partial conversion for powerpc and MIPS - these at least compile
with minimal configurations.
This will affect all archs. Mostly the changes should be relatively easy.
Take do_IRQ(), store the regs pointer at the beginning, saving the old one:
struct pt_regs *old_regs = set_irq_regs(regs);
And put the old one back at the end:
set_irq_regs(old_regs);
Don't pass regs through to generic_handle_irq() or __do_IRQ().
In timer_interrupt(), this sort of change will be necessary:
- update_process_times(user_mode(regs));
- profile_tick(CPU_PROFILING, regs);
+ update_process_times(user_mode(get_irq_regs()));
+ profile_tick(CPU_PROFILING);
I'd like to move update_process_times()'s use of get_irq_regs() into itself,
except that i386, alone of the archs, uses something other than user_mode().
Some notes on the interrupt handling in the drivers:
(*) input_dev() is now gone entirely. The regs pointer is no longer stored in
the input_dev struct.
(*) finish_unlinks() in drivers/usb/host/ohci-q.c needs checking. It does
something different depending on whether it's been supplied with a regs
pointer or not.
(*) Various IRQ handler function pointers have been moved to type
irq_handler_t.
Signed-Off-By: David Howells <dhowells@redhat.com>
(cherry picked from 1b16e7ac850969f38b375e511e3fa2f474a33867 commit)
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.
[akpm@osdl.org: cleanups]
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Acked-by: Jesse Barnes <jesse.barnes@intel.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In cases where the acpi memory-add event does not containe the pxm (node)
infomation allow the driver to look up node info based on the address. The
acpi_get_node call returns -1 if it can't decode the pxm info, this causes
add_memory to panic. acpi_get_node would have to decode the resource from the
handle (a lenghty proposition). This seems to be the cleanist point to
interject the hook.
[kamezawa.hiroyu@jp.fujitsu.com: build fixes]
[y-goto@jp.fujitsu.com: build fixes]
Signed-off-by: Keith Mannthey <kmannth@us.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Rougly half of callers already do it by not checking return value
* Code in drivers/acpi/osl.c does the following to be sure:
(void)kmem_cache_destroy(cache);
* Those who check it printk something, however, slab_error already printed
the name of failed cache.
* XFS BUGs on failed kmem_cache_destroy which is not the decision
low-level filesystem driver should make. Converted to ignore.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
i2c: Constify i2c_algorithm declarations, part 2
Make struct i2c_algorithm declarations const in all i2c bus drivers
where it is possible.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
While going through the code, I found out some memory leaks and potential
crashes in drivers/acpi/hotkey.c Please find the patch to fix them.
This patch does the following,
1. Fixes memory leaks in error paths of hotkey_write_config
2. Fixes freeing unallocated pointers in the error paths of hotkey_write_config
3. Uses a loop instead of linear searching for parsing the userspace
input in get_params
4. Uses array of char * instead of passing 4 pointer parameters
explicitly into the init_{poll_}hotkey_* static functions
Signed-off-by: Andrew Morton <akpm@osdl.org>
Acked-by: Luming Yu <luming.yu@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This is to remove noisy useless message at boot. The message is a ton of
"ACPI Exception (acpi_memory-0492): AE_ERROR, handle is no memory device"
In my emulation, number of memory devices are not so many (only 6), but,
this messages are displayed 114 times.
It is showed by acpi_memory_register_notify_handler() which is called by
acpi_walk_namespace().
acpi_walk_namespace() parses all of ACPI's namespace and execute
acpi_memory_register_notify_handler(). So, it is called for all of the
device which is defined in namespace. If the parsing device is not memory,
acpi_memhotplug ignores it due to "no match" and will parse next device.
This is normal route, not an exception.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Fix acpi_ac/battery boot with acpi=off
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
both of acpi_memory_enable_device() and acpi_memory_add_device() may evaluate
_CRS method.
We should avoid evaluate device's resource twice if we could get it
successfully in past.
Signed-off-by: KAMEZWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Keith Mannthey <kmannth@gmail.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
add_memory() does all necessary check to avoid collision. then, acpi layer
doesn't have to check region by itself.
(*) pfn_valid() just returns page struct is valid or not. It returns 0
if a section has been already added even is ioresource is not added.
ioresource collision check in mm/memory_hotplug.c can do more precise
collistion check.
added enabled bit check just for sanity check..
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Keith Mannthey <kmannth@gmail.com>
Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Remove uevent dock notifications. There are no consumers
of these events at present, and uevents are likely not the
correct way to send this type of event anyway.
Until I get some kind of idea if anyone in userspace cares
about dock events, I will just not send any.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The ACPI_EXCEPTION() patch enabled a bunch of messages to print
even in the non-DEBUG kernel. Need to change a couple back,
and note that ACPI_EXCEPTION takes no \n, but ACPI_DEBUG_PRINT does.
No context for object [%p]\n
Device `[%s]' is not power manageable\n
Signed-off-by: Len Brown <len.brown@intel.com>
This effectively reverts commit b8d35192c5
by reverts acpi_os_queue_for_execution() to what it was before that,
except it changes the name to acpi_os_execute() to match ACPICA
20060512.
Signed-off-by: Len Brown <len.brown@intel.com>
[ The thread execution doesn't actually solve the bug it set out to
solve (see
http://bugzilla.kernel.org/show_bug.cgi?id=5534
for more details) because the new events can get caught behind the AML
semaphore or other serialization. And when that happens, the notify
threads keep on piling up until the system dies. ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Check and handle kset_register() and kobject_register() init errors.
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: ACPI_DOCK: Initialize the atomic notifier list
ACPI: acpi_os_allocate() fixes
ACPI: SBS: fix initialization, sem2mutex
ACPI: add 'const' to several ACPI file_operations
ACPI: delete some defaults from ACPI Kconfig
ACPI: "Device `[%s]' is not power manageable" make message debug only
ACPI: ACPI_DOCK Kconfig
Revert "Revert "ACPI: dock driver""
ACPI: acpi_os_get_thread_id() returns current
ACPI: ACPICA 20060707
No need for video to be always in
No need for smart battery driver to be always in
Acked-by: Len Brown <len.brown@intel.com>
Cc: linux-acpi@vger.kernel.org
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Daniel Ritz <daniel.ritz-ml@swissonline.ch> says:
The acpi driver suspend/resume patches that went in recently caused a regression
on my box (toshiba tecra 8000 laptop): after resume from swsusp the fan turns on
keeping blowing cold air out of my notebook. before the patches, the fan was off
and would only make noise when required. it's the same thing described in
bugzilla.kernel.org #5000. the acpi suspend/resume patches or at least parts of
them originate in this bug. now the last patch in the report (attach id 8438)
actually fixes the problem - for me and the reporter. this is a trimmed down
version of that patch.
Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch>
Cc: Len Brown <len.brown@intel.com>
Cc: Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk>
Cc: Pavel Machek <pavel@suse.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Replace acpi_in_resume with a more general hack
to check irqs_disabled() on any kmalloc() from ACPI.
While setting (system_state != SYSTEM_RUNNING) on resume
seemed more general, Andrew Morton preferred this approach.
http://bugzilla.kernel.org/show_bug.cgi?id=3469
Make acpi_os_allocate() into an inline function to
allow /proc/slab_allocators to work.
Delete some memset() that could fault on allocation failure.
Signed-off-by: Len Brown <len.brown@intel.com>
cm_sbs_sem is being downed (via acpi_ac_init->acpi_lock_ac_dir) before it is
initialised, with grave results.
- Make it a mutex
- Initialise it
- Make it static
- Clean other stuff up.
Thanks to Paul Drynoff <pauldrynoff@gmail.com> for reporting and testing.
Cc: Rich Townsend <rhdt@bartol.udel.edu>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
No need for video to be always in
No need for ACPI dock driver to be always in
No need for smart battery driver to be always in
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Len Brown <len.brown@intel.com>
HOTPLUG_PCI_ACPI depends on ACPI_DOCK
ACPI_IBM_DOCK depends on ACPI_DOCK=n
ACPI_DOCK is EXPERIMENTAL, though that doesn't seem to mean much
Signed-off-by: Len Brown <len.brown@intel.com>
Linux mutexes and the debug code that that reference
acpi_os_get_thread_id() are happy with 0.
But the AML mutexes in exmutex.c expect a unique non-zero
number for each thread - as they track this thread_id
to permit the mutex re-entrancy defined by the ACPI spec.
http://bugzilla.kernel.org/show_bug.cgi?id=6687
Signed-off-by: Len Brown <len.brown@intel.com>
Added the ACPI_PACKED_POINTERS_NOT_SUPPORTED macro to
support C compilers that do not allow the initialization
of address pointers within packed structures - even though
the hardware itself may support misaligned transfers. Some
of the debug data structures are packed by default to
minimize size.
Added an error message for the case where
acpi_os_get_thread_id() returns zero. A non-zero value is
required by the core ACPICA code to ensure the proper
operation of AML mutexes and recursive control methods.
The DSDT is now the only ACPI table that determines whether
the AML interpreter is in 32-bit or 64-bit mode. Not really
a functional change, but the hooks for per-table 32/64
switching have been removed from the code. A clarification
to the ACPI specification is forthcoming in ACPI 3.0B.
Fixed a possible leak of an Owner ID in the error
path of tbinstal.c acpi_tb_init_table_descriptor() and
migrated all table OwnerID deletion to a single place in
acpi_tb_uninstall_table() to correct possible leaks when using
the acpi_tb_delete_tables_by_type() interface (with assistance
from Lance Ortiz.)
Fixed a problem with Serialized control methods where the
semaphore associated with the method could be over-signaled
after multiple method invocations.
Fixed two issues with the locking of the internal
namespace data structure. Both the Unload() operator and
acpi_unload_table() interface now lock the namespace during
the namespace deletion associated with the table unload
(with assistance from Linn Crosetto.)
Fixed problem reports (Valery Podrezov) integrated: -
Eliminate unnecessary memory allocation for CreateXxxxField
http://bugzilla.kernel.org/show_bug.cgi?id=5426
Fixed problem reports (Fiodor Suietov) integrated: -
Incomplete cleanup branches in AcpiTbGetTableRsdt (BZ 369)
- On Address Space handler deletion, needless deactivation
call (BZ 374) - AcpiRemoveAddressSpaceHandler: validate
Device handle parameter (BZ 375) - Possible memory leak,
Notify sub-objects of Processor, Power, ThermalZone (BZ
376) - AcpiRemoveAddressSpaceHandler: validate Handler
parameter (BZ 378) - Minimum Length of RSDT should be
validated (BZ 379) - AcpiRemoveNotifyHandler: return
AE_NOT_EXIST if Processor Obj has no Handler (BZ (380)
- AcpiUnloadTable: return AE_NOT_EXIST if no table of
specified type loaded (BZ 381)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
This reverts commit a5e1b94008.
Adrian Bunk points out that it has build errors, and apparently no
maintenance. Throw it out.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Most batteries today are ACPI "Control Method" batteries,
but some models ship with the older "Smart Battery"
that requires this code.
Rich Townsend and Bruno Ducrot were the original authors.
Vladimir Lebedev updated to run on latest kernel.
http://bugzilla.kernel.org/show_bug.cgi?id=3734
Signed-off-by: Len Brown <len.brown@intel.com>
This patch switches back the display nodes for M6R and M6N -- this happened
a while ago when a patch was misapplied (only the in-tree version was
affected).
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch switches back the display nodes for M6R and M6N -- this happened
a while ago when a patch was misapplied (only the in-tree version was
affected).
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This small patch adds back WLED control for S1N models, this was
accidentally removed a while ago.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch reworks laptop model detection.
This addresses the Samsung P30 issue, where the INIT method would return no
object, but the implicit return in the AML interpreter would confuse the
driver. It also accounts for a newer batch of Asus models whose INIT
returns ACPI_TYPE_BUFFER instead of STRING.
The handling is now much leaner, if we get a buffer or a string, we check
against known values, in every other case we use a different path
(currently DSDT signatures). The bulk of this patch is separating the
string matching from asus_hotk_get_info() into a separate function.
This patch properly fixes http://bugme.osdl.org/show_bug.cgi?id=5067 and
http://bugme.osdl.org/show_bug.cgi?id=5092 and makes the driver fully
functional again with acpi=strict on all machines.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds support for Asus L5D and thus fixes
http://bugme.osdl.org/show_bug.cgi?id=4695
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch creates a new file named "bluetooth" under /proc/acpi/asus/.
This file controls both the internal Bluetooth adapter's presence on the
USB bus and the associated LED.
echo 1 > /proc/acpi/asus/bluetooth to enable, 0 to disable.
Additionally, the patch add support for Asus W5A, the first model that uses
this feature.
Patch originally by Fernando A. P. Gomes.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds support for Asus A4G.
Originally by Giuseppe Rota.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch adds handling for front LED displays found on W1N and the like.
Additionally, W1N is given its own model_data instance.
Patch originally by Éric Burghard.
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
This patch updates the version string, copyright notices and does
whitespace cleanup (it looks weird, blame Lindent).
Signed-off-by: Karol Kozimor <sziwan@hell.org.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
- Use it instead of acpi_bus_get_device() in acpi_video_bus_notify()
and use the one from struct acpi_video_device in
acpi_video_device_notify().
Signed-off-by: Patrick Mochel <mochel@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
- Use it instead of acpi_bus_get_device() where we can..
Signed-off-by: Patrick Mochel <mochel@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
- Use it instead of acpi_bus_get_device() where we can..
Signed-off-by: Patrick Mochel <mochel@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
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 <andi@lisas.de>
Signed-off-by: Len Brown <len.brown@intel.com>
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 <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
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 <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
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 <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Implemented a new acpi_spinlock type for the OSL lock
interfaces. This allows the type to be customized to
the host OS for improved efficiency (since a spinlock is
usually a very small object.)
Implemented support for "ignored" bits in the ACPI
registers. According to the ACPI specification, these
bits should be preserved when writing the registers via
a read/modify/write cycle. There are 3 bits preserved
in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9],
and PM1_STATUS[11].
http://bugzilla.kernel.org/show_bug.cgi?id=3691
Implemented the initial deployment of new OSL mutex
interfaces. Since some host operating systems have
separate mutex and semaphore objects, this feature was
requested. The base code now uses mutexes (and the new
mutex interfaces) wherever a binary semaphore was used
previously. However, for the current release, the mutex
interfaces are defined as macros to map them to the
existing semaphore interfaces.
Fixed several problems with the support for the control
method SyncLevel parameter. The SyncLevel now works
according to the ACPI specification and in concert with the
Mutex SyncLevel parameter, since the current SyncLevel is
a property of the executing thread. Mutual exclusion for
control methods is now implemented with a mutex instead
of a semaphore.
Fixed three instances of the use of the C shift operator
in the bitfield support code (exfldio.c) to avoid the use
of a shift value larger than the target data width. The
behavior of C compilers is undefined in this case and can
cause unpredictable results, and therefore the case must
be detected and avoided. (Fiodor Suietov)
Added an info message whenever an SSDT or OEM table
is loaded dynamically via the Load() or LoadTable()
ASL operators. This should improve debugging capability
since it will show exactly what tables have been loaded
(beyond the tables present in the RSDT/XSDT.)
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Create a driver which lives in the acpi subsystem to handle dock events.
This driver is not an "ACPI" driver, because acpi drivers require that the
object be present when the driver is loaded.
Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Len Brown <len.brown@intel.com>
This is to find node id from acpi's handle of memory_device in DSDT. _PXM for
the new node can be found by acpi_get_pxm() by using new memory's handle. So,
node id can be found by pxm_to_nid_map[].
This patch becomes simpler than v2 of node hot-add patch.
Because old add_memory() function doesn't have node id parameter.
So, kernel must find its handle by physical address via DSDT again.
But, v3 just give node id to add_memory() now.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Change the name of old add_memory() to arch_add_memory. And use node id to
get pgdat for the node at NODE_DATA().
Note: Powerpc's old add_memory() is defined as __devinit. However,
add_memory() is usually called only after bootup.
I suppose it may be redundant. But, I'm not well known about powerpc.
So, I keep it. (But, __meminit is better at least.)
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Dave Hansen <haveblue@us.ibm.com>
Cc: "Brown, Len" <len.brown@intel.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
