aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/acpi
Commit message (Collapse)AuthorAge
* acpi-thermal: fix mod_timer() intervalAndrew Morton2007-04-24
| | | | | | | | | | 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>
* Revert "ACPI: parse 2nd MADT by default"Len Brown2007-03-30
| | | | | | | This reverts commit 09fe58356d148ff66901ddf639e725ca1a48a0af. http://bugzilla.kernel.org/show_bug.cgi?id=8283 Signed-off-by: Len Brown <len.brown@intel.com>
* [PATCH] i386: add command line option "local_apic_timer_c2_ok"Thomas Gleixner2007-03-23
| | | | | | | | | | | | | | 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>
* Revert "ACPI: Only use IPI on known broken machines (AMD, ↵Linus Torvalds2007-03-23
| | | | | | | | | | | | | | Dothan/BaniasPentium M)" This reverts commit 25496caec111481161e7f06bbfa12a533c43cc6f, 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>
* Pull c2 into release branchLen Brown2007-03-20
|\
| * ACPI: Only use IPI on known broken machines (AMD, Dothan/BaniasPentium M)Thomas Renninger2007-03-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Pull bugzilla-7465 into release branchLen Brown2007-03-20
|\ \
| * | ACPI: parse 2nd MADT by defaultLen Brown2007-03-15
| | | | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=7465 Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: Add support to parse 2nd MADTLen Brown2007-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Pull bugzilla-8171 into release branchLen Brown2007-03-20
|\ \ \
| * | | ACPICA: revert "acpi_serialize" changesLen Brown2007-03-15
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts 977a6226feae3e2c10a4d8227625ff0f04b49239 and reverts 1ba753acb372c2955a4843302e92e49ce82e2fea 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=8171 Signed-off-by: Len Brown <len.brown@intel.com>
* | | Pull misc-for-upstream into release branchLen Brown2007-03-20
|\ \ \ | |/ / |/| |
| * | ACPI: ibm-acpi: allow module to load when acpi notifiers can't be set (v2)Henrique de Moraes Holschuh2007-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | ACPI: resolve HP nx6125 S3 immediate wakeup regressionAlexey Starikovskiy2007-03-12
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* / [PATCH] misc NULL noiseAl Viro2007-03-14
|/ | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Pull misc-for-upstream into release branchLen Brown2007-03-09
|\
| * ACPI: Kconfig: hide ACPI menu when CONFIG_PM=nRobert P. J. Day2007-03-09
| | | | | | | | | | Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: video: Fix spelling and grammar mistakesJulius Volz2007-03-09
| | | | | | | | | | | | | | | | Correct some of the most obvious spelling and grammar mistakes in drivers/acpi/video.c (comments and printk output). Signed-off-by: Julius Volz <juliusrv@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: make blacklist more verboseAnthony Godshall, Ampro Computers, Inc2007-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | 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: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| * ACPI: ThinkPad Z60m: usb mouse stops working after suspend to RAMKonstantin Karasyov2007-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (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 0a6139027f3986162233adc17285151e78b39cac Do not disable power resources on resume even if there are no devices referencing it. Signed-off-by: Konstantin Karasyov <konstantin.a.karasyov@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Pull bugzilla-8110 into release branchLen Brown2007-03-09
|\ \
| * | ACPI: ec: fix race in status register accessAlexey Starikovskiy2007-03-09
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=8110 Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Pull bugzilla-8066 into release branchLen Brown2007-03-09
|\ \
| * | ACPICA: Fix ACPI Global Lock re-entrancyAlexey Starikovskiy2007-03-07
| |/ | | | | | | | | | | | | | | | | | | | | | | 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#c9 Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Pull bugzilla-7570 into release branchLen Brown2007-03-09
|\ \
| * | ACPI: fix S3 fan resume issueKonstantin Karasyov2007-02-21
| | | | | | | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=7570#c14 Signed-off-by: Konstantin Karasyov <konstantin.a.karasyov@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Pull bugzilla-6859 into release branchLen Brown2007-03-09
|\ \ \
| * | | ACPI: fix boot hang w/o "noapic" on MSI MS-6390-LShaohua Li2007-03-08
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=6859 Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Pull ibm into release branchLen Brown2007-03-09
|\ \ \ | |/ / |/| |
| * | ACPI: ibm-acpi: improve backlight power handlingHenrique de Moraes Holschuh2007-03-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: ibm-acpi: make ibm-acpi bay support optionalHenrique de Moraes Holschuh2007-02-22
| | | | | | | | | | | | | | | | | | Make ibm-acpi bay support optional at kernel compile time. Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
| * | ACPI: ibm-acpi: fix initial status of backlight deviceHenrique de Moraes Holschuh2007-02-22
| | | | | | | | | | | | | | | | | | | | | | | | 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: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Acked-by: Richard Purdie <rpurdie@rpsys.net>
* | | [PATCH] ACPI: make bay depend on dockKristen Carlson Accardi2007-03-01
|/ / | | | | | | | | | | | | | | | | | | Since the bay driver depends on the dock driver for proper notification, make this driver depend on the dock driver. Signed-off-by: Kristen Carlson Accardi <kristen.c.accardi@intel.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>
* | backlight: Separate backlight properties from backlight ops pointersRichard Purdie2007-02-20
| | | | | | | | | | | | | | | | | | 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: Richard Purdie <rpurdie@rpsys.net>
* | backlight: Remove unneeded owner fieldRichard Purdie2007-02-20
|/ | | | | | | | | | | | 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: Richard Purdie <rpurdie@rpsys.net>
* Pull bugzilla-7897 into release branchLen Brown2007-02-16
|\
| * ACPI: sbs: fix present rateVladimir Lebedev2007-02-10
| | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=7897 Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Pull bugzilla-7887 into release branchLen Brown2007-02-16
|\ \
| * | ACPI: invoke acpi_sleep_init() earlierAlexey Starikovskiy2007-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | late_initcall() is too late for acpi_sleep_init(). Call it directly from acpi_init code. http://bugzilla.kernel.org/show_bug.cgi?id=7887 Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: Disable GPEs in preparation for sleep.Alexey Starikovskiy2007-02-10
| |/ | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=7887 Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | Pull bugzilla-7570 into release branchLen Brown2007-02-16
|\ \
| * | ACPI: fix fan after resume from S3Konstantin Karasyov2007-02-16
| | | | | | | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=7570 Signed-off-by: Konstantin Karasyov <konstantin.a.karasyov@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Pull bugzilla-7200 into release branchLen Brown2007-02-16
|\ \ \
| * | | ACPI: battery: check for battery present on /proc/battery accessVladimir Lebedev2007-02-10
| | |/ | |/| | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=7200 Signed-off-by: Vladimir Lebedev <vladimir.p.lebedev@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Pull bugzilla-7122 into release branchLen Brown2007-02-16
|\ \ \
| * | | ACPI: update acpi_power_resume() per new acpi_op_resumeLen Brown2007-02-16
| | | | | | | | | | | | | | | | | | | | | | | | drivers/acpi/power.c:69: warning: initialization from incompatible pointer type Signed-off-by: Len Brown <len.brown@intel.com>
| * | | ACPI: Thermal issues on HP nx6325Konstantin Karasyov2007-02-16
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Konstantin Karasyov <konstantin.a.karasyov@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Pull bugzilla-5534 into release branchLen Brown2007-02-16
|\ \ \
| * | | Execute AML Notify() requests on stack.Alexey Starikovskiy2007-02-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=5534 Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | ACPICA: fix AML mutex re-entrancyAlexey Starikovskiy2007-02-15
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=5534 Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-27 01:52:29 -0500