summaryrefslogtreecommitdiffstats
path: root/drivers/acpi
Commit message (Collapse)AuthorAgeFilesLines
* acpi: update gfp/slab.h includesTejun Heo2010-06-282-0/+2
| | | | | | | | | | Implicit slab.h inclusion via percpu.h is about to go away. Make sure gfp.h or slab.h is included as necessary. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
* Merge branch 'bugzilla-15951' into releaseLen Brown2010-06-172-15/+9
|\
| * ACPI / PM: Do not enable GPEs for system wakeup in advanceRafael J. Wysocki2010-06-172-15/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit 9630bdd9b15d2f489c646d8bc04b60e53eb5ec78 (ACPI: Use GPE reference counting to support shared GPEs) the wakeup enable mask bits of GPEs are set as soon as the GPEs are enabled to wake up the system. Unfortunately, this leads to a regression reported by Michal Hocko, where a system is woken up from ACPI S5 by a device that is not supposed to do that, because the wakeup enable mask bit of this device's GPE is always set when acpi_enter_sleep_state() calls acpi_hw_enable_all_wakeup_gpes(), although it should only be set if the device is supposed to wake up the system from the target state. To work around this issue, rework the ACPI power management code so that GPEs are not enabled to wake up the system upfront, but only during a system state transition when the target state of the system is known. [Of course, this means that the reference counting of "wakeup" GPEs doesn't really make sense and it is sufficient to set/unset the wakeup mask bits for them during system sleep transitions. This will allow us to simplify the GPE handling code quite a bit, but that change is too intrusive for 2.6.35.] Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15951 Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Michal Hocko <mhocko@suse.cz> Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'misc-2.6.35' into releaseLen Brown2010-06-122-1/+7
|\ \
| * | ACPI: fan: fix unbalanced code blockLiang Li2010-06-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code block braced with CONFIG_ACPI_PROCFS is unblanced. When CONFIG_ACPI_PROCFS=n, kernel trace will be produced like: Call Trace: [<c111637d>] ? remove_proc_entry+0x20d/0x290 [<c111637d>] ? remove_proc_entry+0x20d/0x290 [<c103b02c>] warn_slowpath_common+0x6c/0xc0 [<c111637d>] ? remove_proc_entry+0x20d/0x290 [<c103b0c6>] warn_slowpath_fmt+0x26/0x30 [<c111637d>] remove_proc_entry+0x20d/0x290 [<c1116bd7>] ? proc_register+0x117/0x1f0 [<c1116e83>] ? proc_mkdir_mode+0x33/0x50 [<c14f483c>] ? acpi_fan_init+0x0/0x2c [<c14f485f>] acpi_fan_init+0x23/0x2c [<c1001123>] do_one_initcall+0x23/0x180 [<c107dcf7>] ? init_irq_proc+0x67/0x80 [<c14d43bd>] kernel_init+0x13c/0x20e [<c1030e50>] ? schedule_tail+0x20/0x90 [<c1389e06>] ? syscall_exit+0x5/0x16 [<c14d4281>] ? kernel_init+0x0/0x20e [<c14d4281>] ? kernel_init+0x0/0x20e [<c10032f6>] kernel_thread_helper+0x6/0x30 ---[ end trace a7919e7f17c0a725 ]--- Then also bracket later error checking code with ACPI_PROCFS option to avoid mismatch problem. Signed-off-by: Liang Li <liang.li@windriver.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: Do not try to set up acpi processor stuff on cores exceeding maxcpus=Thomas Renninger2010-06-091-0/+5
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch is against latest Linus master branch and is expected to be safe bug fix. You get: ACPI: HARDWARE addr space,NOT supported yet for each ACPI defined CPU which status is active, but exceeds maxcpus= count. As these "not booted" CPUs do not run an idle routine and echo X >/proc/acpi/processor/*/throttling did not work I couldn't find a way to really access not onlined/booted machines. Still this should get fixed and /proc/acpi/processor/X dirs of cores exceeding maxcpus should not show up. I wonder whether this could get cleaned up by truncating possible cpu mask and nr_cpu_ids to setup_max_cpus early some day (and not exporting setup_max_cpus anymore then). But this needs touching of a lot other places... Signed-off-by: Thomas Renninger <trenn@suse.de> CC: travis@sgi.com CC: linux-acpi@vger.kernel.org CC: lenb@kernel.org Signed-off-by: Len Brown <len.brown@intel.com>
* | Merge branch 'bugzilla-13931-sleep-nvs' into releaseLen Brown2010-06-121-15/+19
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: drivers/acpi/sleep.c Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI: Store NVS state even when entering suspend to RAMMatthew Garrett2010-06-101-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugzilla.kernel.org/show_bug.cgi?id=13931 describes a bug where a system fails to successfully resume after the second suspend. Maxim Levitsky discovered that this could be rectified by forcibly saving and restoring the ACPI non-volatile state. The spec indicates that this is only required for S4, but testing the behaviour of Windows by adding an ACPI NVS region to qemu's e820 map and registering a custom memory read/write handler reveals that it's saved and restored even over suspend to RAM. We should mimic that behaviour to avoid other broken platforms. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | suspend: Move NVS save/restore code to generic suspend functionalityMatthew Garrett2010-06-101-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Saving platform non-volatile state may be required for suspend to RAM as well as hibernation. Move it to more generic code. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'bugzilla-102904-workaround' into releaseLen Brown2010-06-121-0/+8
|\ \ \
| * | | ACPI: Disable Vista compatibility for Sony VGN-NS50B_LZhang Rui2010-06-101-0/+8
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable Vista compatibility for Sony VGN-NS50B_L. https://bugzilla.kernel.org/show_bug.cgi?id=12904#c46 Note that this change is a workaround, not a permanent fix. For the permanent fix is to figure out what compatibility means and to actually be compatible... Tested-by: Voldemar <harestomper@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'acpica-cherry-pick' into releaseLen Brown2010-06-125-0/+41
|\ \ \
| * | | ACPICA: Truncate I/O addresses to 16 bits for Windows compatibilityMatthew Garrett2010-06-123-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature is optional and is enabled if the BIOS requests any Windows OSI strings. It can also be enabled by the host OS. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | ACPICA: Limit maximum time for Sleep() operatorBob Moore2010-06-122-0/+12
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To prevent accidental deep sleeps, limit the maximum time that Sleep() will sleep. Configurable, default maximum is two seconds. ACPICA bugzilla 854. http://www.acpica.org/bugzilla/show_bug.cgi?id=854 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'acpi_pad' into releaseLen Brown2010-06-121-12/+24
|\ \ \
| * | | ACPI: acpi_pad: Don't needlessly mark LAPIC unstableChen Gong2010-06-041-12/+24
| | |/ | |/| | | | | | | | | | | | | | | | | | | As suggested in Venki's suggestion in the commit 0dc698b, add LAPIC unstable detection in the acpi_pad drvier too. Signed-off-by: Chen Gong <gong.chen@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'gpe-regression-fixes' into releaseLen Brown2010-06-128-160/+145
|\ \ \ | |_|/ |/| |
| * | ACPI / ACPICA: Fix sysfs GPE interfaceRafael J. Wysocki2010-06-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The sysfs interface allowing user space to disable/enable GPEs doesn't work correctly, because a GPE disabled this way will be re-enabled shortly by acpi_ev_asynch_enable_gpe() if it was previosuly enabled by acpi_enable_gpe() (in which case the corresponding bit in its enable register's enable_for_run mask is set). To address this issue make the sysfs GPE interface use acpi_enable_gpe() and acpi_disable_gpe() instead of acpi_set_gpe() so that GPE reference counters are modified by it along with the values of GPE enable registers. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI / ACPICA: Fix GPE initializationRafael J. Wysocki2010-06-121-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While developing the GPE reference counting code we overlooked the fact that acpi_ev_update_gpes() could have enabled GPEs before acpi_ev_initialize_gpe_block() was called. As a result, some GPEs are enabled twice during the initialization. To fix this issue avoid calling acpi_enable_gpe() from acpi_ev_initialize_gpe_block() for the GPEs that have nonzero runtime reference counters. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI / ACPICA: Avoid writing full enable masks to GPE registersRafael J. Wysocki2010-06-121-13/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPICA uses acpi_hw_write_gpe_enable_reg() to re-enable a GPE after an event signaled by it has been handled. However, this function writes the entire GPE enable mask to the GPE's enable register which may not be correct. Namely, if one of the other GPEs in the same register was previously enabled by acpi_enable_gpe() and subsequently disabled using acpi_set_gpe(), acpi_hw_write_gpe_enable_reg() will re-enable it along with the target GPE. To fix this issue rework acpi_hw_write_gpe_enable_reg() so that it calls acpi_hw_low_set_gpe() with a special action value, ACPI_GPE_COND_ENABLE, that will make it only enable the GPE if the corresponding bit in its register's enable_for_run mask is set. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI / ACPICA: Fix low-level GPE manipulation codeRafael J. Wysocki2010-06-125-122/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPICA uses acpi_ev_enable_gpe() for enabling GPEs at the low level, which is incorrect, because this function only enables the GPE if the corresponding bit in its enable register's enable_for_run mask is set. This causes acpi_set_gpe() to work incorrectly if used for enabling GPEs that were not previously enabled with acpi_enable_gpe(). As a result, among other things, wakeup-only GPEs are never enabled by acpi_enable_wakeup_device(), so the devices that use them are unable to wake up the system. To fix this issue remove acpi_ev_enable_gpe() and its counterpart acpi_ev_disable_gpe() and replace acpi_hw_low_disable_gpe() with acpi_hw_low_set_gpe() that will be used instead to manipulate GPE enable bits at the low level. Make the users of acpi_ev_enable_gpe() and acpi_ev_disable_gpe() call acpi_hw_low_set_gpe() instead and make sure that GPE enable masks are only updated by acpi_enable_gpe() and acpi_disable_gpe() when GPE reference counters change from 0 to 1 and from 1 to 0, respectively. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI / ACPICA: Use helper function for computing GPE masksRafael J. Wysocki2010-06-113-16/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In quite a few places ACPICA needs to compute a GPE enable mask with only one bit, corresponding to a given GPE, set. Currently, that computation is always open coded which leads to unnecessary code duplication. Fix this by introducing a helper function for computing one-bit GPE enable masks and using it where appropriate. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| * | ACPI / ACPICA: Do not attempt to disable GPE when installing handlerRafael J. Wysocki2010-06-111-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0f849d2cc6863c7874889ea60a871fb71399dd3f (ACPICA: Minimize the differences between linux GPE code and ACPICA code base) introduced a change attempting to disable a GPE before installing a handler for it in acpi_install_gpe_handler() which was incorrect. First, the GPE disabled by it is never enabled again (except during resume) which leads to battery insert/remove events not being reported on the Maxim Levitsky's machine. Second, the disabled GPE is still reported as enabled by the sysfs interface that only checks its enable register's enable_for_run mask. Revert this change for now, because it causes more damage to happen than the bug it was supposed to fix. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branch 'acpi-idle' into releaseLen Brown2010-06-041-11/+6
|\ \ \
| * | | ACPI: Eliminate us to pm ticks conversion in common pathVenkatesh Pallipadi2010-06-041-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_enter_[simple|bm] routines does us to pm tick conversion on every idle wakeup and the value is only used in /proc/acpi display. We can store the time in us and convert it into pm ticks before printing instead and avoid the conversion in the common path. Signed-off-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Len Brown <len.brown@intel.com>
| * | | ACPI: Fix the incorrect calculation about C-state idle timeZhao Yakui2010-06-041-1/+1
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The C-state idle time is not calculated correctly, which will return the wrong residency time in C-state. It will have the following effects: 1. The system can't choose the deeper C-state when it is idle next time. Of course the system power is increased. E.g. On one server machine about 40W idle power is increased. 2. The powertop shows that it will stay in C0 running state about 95% time although the system is idle at most time. 2.6.35-rc1 regression caused-by: 2da513f582a96c053aacc2c92873978d2ea7abff (ACPI: Minor cleanup eliminating redundant PMTIMER_TICKS to NS conversion) Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Reported-by: Yu Zhidong <zhidong.yu@intel.com> Tested-by: Yu Zhidong <zhidong.yu@intel.com> Acked-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Len Brown <len.brown@intel.com>
* | | Merge branches 'bugzilla-14668' and 'misc-2.6.35' into releaseLen Brown2010-06-01100-1805/+5623
|\ \ \ | |/ /
| * | Merge branch 'idle-release' of ↵Linus Torvalds2010-05-283-26/+26
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6 * 'idle-release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-idle-2.6: intel_idle: native hardware cpuidle driver for latest Intel processors ACPI: acpi_idle: touch TS_POLLING only in the non-MWAIT case acpi_pad: uses MONITOR/MWAIT, so it doesn't need to clear TS_POLLING sched: clarify commment for TS_POLLING ACPI: allow a native cpuidle driver to displace ACPI cpuidle: make cpuidle_curr_driver static cpuidle: add cpuidle_unregister_driver() error check cpuidle: fail to register if !CONFIG_CPU_IDLE
| | * | intel_idle: native hardware cpuidle driver for latest Intel processorsLen Brown2010-05-281-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This EXPERIMENTAL driver supersedes acpi_idle on Intel Atom Processors, Intel Core i3/i5/i7 Processors and associated Intel Xeon processors. It does not support the Intel Core2 processor or earlier. For kernels configured with ACPI, CONFIG_INTEL_IDLE=y allows intel_idle to probe before the ACPI processor driver. Booting with "intel_idle.max_cstate=0" disables intel_idle and the system will fall back on ACPI's "acpi_idle". Typical Linux distributions load ACPI processor module early, making CONFIG_INTEL_IDLE=m not easily useful on ACPI platforms. intel_idle probes all processors at module_init time. Processors that are hot-added later will be limited to using C1 in idle. Signed-off-by: Len Brown <len.brown@intel.com>
| | * | ACPI: acpi_idle: touch TS_POLLING only in the non-MWAIT caseLen Brown2010-05-281-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit d306ebc28649b89877a22158fe0076f06cc46f60 (ACPI: Be in TS_POLLING state during mwait based C-state entry) fixed an important power & performance issue where ACPI c2 and c3 C-states were clearing TS_POLLING even when using MWAIT (ACPI_STATE_FFH). That bug had been causing us to receive redundant scheduling interrups when we had already been woken up by MONITOR/MWAIT. Following up on that... In the MWAIT case, we don't have to subsequently check need_resched(), as that c heck was there for the TS_POLLING-clearing case. Note that not only does the cpuidle calling function already check need_resched() before calling us, the low-level entry into monitor/mwait calls it twice -- guaranteeing that a write to the trigger address can not go un-noticed. Also, in this case, we don't have to set TS_POLLING when we wake, because we never cleared it. Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Venkatesh Pallipadi <venki@google.com>
| | * | acpi_pad: uses MONITOR/MWAIT, so it doesn't need to clear TS_POLLINGLen Brown2010-05-271-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | api_pad exclusively uses MONITOR/MWAIT to sleep in idle, so it does not need the wakeup IPI during idle sleep that is provoked by clearing TS_POLLING. Signed-off-by: Len Brown <len.brown@intel.com> Cc: Shaohua Li <shaohua.li@intel.com>
| | * | ACPI: allow a native cpuidle driver to displace ACPILen Brown2010-05-271-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI driver would fail probe when it found that another driver had previously registered with cpuidle. But this is a natural situation, as a native hardware cpuidle driver should be able to bind instead of ACPI, and the ACPI processor driver should be able to handle yielding control of C-states while still handling P-states and T-states. Add a KERN_DEBUG line showing when acpi_idle does successfully register. Signed-off-by: Len Brown <len.brown@intel.com>
| * | | Merge branch 'release' of ↵Linus Torvalds2010-05-2825-390/+3513
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits) ACPI: Don't let acpi_pad needlessly mark TSC unstable drivers/acpi/sleep.h: Checkpatch cleanup ACPI: Minor cleanup eliminating redundant PMTIMER_TICKS to NS conversion ACPI: delete unused c-state promotion/demotion data strucutures ACPI: video: fix acpi_backlight=video ACPI: EC: Use kmemdup drivers/acpi: use kasprintf ACPI, APEI, EINJ injection parameters support Add x64 support to debugfs ACPI, APEI, Use ERST for persistent storage of MCE ACPI, APEI, Error Record Serialization Table (ERST) support ACPI, APEI, Generic Hardware Error Source memory error support ACPI, APEI, UEFI Common Platform Error Record (CPER) header Unified UUID/GUID definition ACPI Hardware Error Device (PNP0C33) support ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first setup ACPI, APEI, Document for APEI ACPI, APEI, EINJ support ACPI, APEI, HEST table parsing ACPI, APEI, APEI supporting infrastructure ...
| | * \ \ Merge branch 'ht-delete-2.6.35' into releaseLen Brown2010-05-281-2/+2
| | |\ \ \
| | | * | | ACPI: delete the "acpi=ht" boot optionLen Brown2010-03-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi=ht was important in 2003 -- before ACPI was universally deployed and enabled by default in the major Linux distributions. At that time, there were a fair number of people who or chose to, or needed to, run with acpi=off, yet also wanted access to Hyper-threading. Today we find that many invocations of "acpi=ht" are accidental, and thus is it possible that it is doing more harm than good. In 2.6.34, we warn on invocation of acpi=ht. In 2.6.35, we delete the boot option. Signed-off-by: Len Brown <len.brown@intel.com>
| | * | | | Merge branch 'misc-2.6.35' into releaseLen Brown2010-05-285-26/+30
| | |\ \ \ \
| | | * | | | ACPI: Don't let acpi_pad needlessly mark TSC unstableVenkatesh Pallipadi2010-05-281-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi pad driver kind of aggressively marks TSC as unstable at init time, on mwait capable and non X86_FEATURE_NONSTOP_TSC systems. This is irrespective of whether pad driver is ever going to be used on the system or deep C-states are supported/used. This will affect every user who just happens to compile in (or get a kernel version which compiles in) acpi pad driver. Move mark_tsc_unstable() out of init to the actual idle invocation path of the pad driver. There is also another bug/missing_feature in the code that it does not support 'always running apic timer' and switches to broadcast mode unconditionally. Shaohua, can you take a look at that please. Signed-off-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * | | | drivers/acpi/sleep.h: Checkpatch cleanupAndrea Gelmini2010-05-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/acpi/sleep.h:3: WARNING: space prohibited between function name and open parenthesis '(' Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * | | | ACPI: Minor cleanup eliminating redundant PMTIMER_TICKS to NS conversionVenkatesh Pallipadi2010-05-281-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_enter_[simple,bm] does idle timing in ns, convert it to timeval, then to us, then to pmtimer_ticks and then back to ns. This patch changes things to idle timing in ns, convert it to us, and then to pmtimer_ticks. Just saves an imul along this path, but makes the code cleaner. Signed-off-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * | | | ACPI: delete unused c-state promotion/demotion data strucuturesLen Brown2010-05-211-13/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These were used before cpuidle by the native ACPI idle driver, which tracked promotion and demotion between states. The code was referenced by CONFIG_ACPI_PROCFS for /proc/acpi/processor/*/power, but as we no longer do promotion/demotion, that reference has been a NOP since the transition. Signed-off-by: Len Brown <len.brown@intel.com>
| | | * | | | ACPI: EC: Use kmemdupJulia Lawall2010-05-201-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use kmemdup when some other buffer is immediately copied into the allocated region. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S - memcpy(to, from, size); // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Acked-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * | | | drivers/acpi: use kasprintfJulia Lawall2010-05-201-4/+4
| | | | |/ / | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kasprintf combines kmalloc and sprintf, and takes care of the size calculation itself. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression a,flag; expression list args; statement S; @@ a = - \(kmalloc\|kzalloc\)(...,flag) + kasprintf(flag,args) <... when != a if (a == NULL || ...) S ...> - sprintf(a,args); // </smpl> [akpm@linux-foundation.org: don't change handling of `count'] Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | |
| | | \ \ \
| | *-. \ \ \ Merge branches 'video' and 'video-edid' into releaseLen Brown2010-05-282-9/+103
| | |\ \ \ \ \
| | | | * | | | ACPI: Export EDID blocks to the kernelMatthew Garrett2010-04-191-8/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI spec includes a provision for hardware to provide EDID via the ACPI video extension. In the KMS world it's necessary for a way to obtain this from within the kernel. Add a function that either returns the EDID for the provided ACPI display ID or the first display of the provided type. Also add support for ensuring that devices with legacy IDs are supported. Signed-off-by: Matthew Garrett <mjg@redhat.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * | | | | ACPI: video: fix acpi_backlight=videoKamal Mostafa2010-05-201-1/+1
| | | | |/ / / | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make "acpi_backlight=video" param enable ACPI_VIDEO_BACKLIGHT_FORCE_VIDEO as intended, instead of incorrectly enabling video output switching. BugLink: http://bugs.launchpad.net/bugs/573120 Signed-off-by: Kamal Mostafa <kamal@canonical.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: <stable@kernel.org> Acked-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| | * | | | | Merge branch 'acpi_enable' into releaseLen Brown2010-05-283-186/+24
| | |\ \ \ \ \
| | | * | | | | ACPI: Unconditionally set SCI_EN on resumeMatthew Garrett2010-05-121-155/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ACPI spec tells us that the firmware will reenable SCI_EN on resume. Reality disagrees in some cases. The ACPI spec tells us that the only way to set SCI_EN is via an SMM call. https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so may break machines. Tracing the ACPI calls made by Windows shows that it unconditionally sets SCI_EN on resume with a direct register write, and therefore the overwhelming probability is that everything is fine with this behaviour. Signed-off-by: Matthew Garrett <mjg@redhat.com> Tested-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
| | | * | | | | ACPICA: simplify SCI_EN workaroundLen Brown2010-05-122-31/+22
| | | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | acpi_hw_set_mode() double checks its effectiveness by calling acpi_hw_get_mode() -- polling up to 3 seconds. It would be more logical for its caller, acpi_enable() acpi_enable() to do the double-checking. (lets assume that acpi_disable() isn't interesting) The ACPI specification is unclear on this point. Some parts say that the BIOS sets SCI_EN and then returns to the OS, but one part says "OSPM polls the SCI_EN bit until it is sampled SET". The systems I have on hand do the former, SCI_EN is observed to be set upon return from the BIOS. So we move the check up out of acpi_hw_set_mode() up into acpi_enable() where it makes logical sense. Then we replace the 3-second polling loop with a single check. If this check fails, we'll see: "Hardware did not enter ACPI mode" and the system will bail out of ACPI initialization and likely fail to boot. If we see that in practice, we can restore the polling, but put it into acpi_enable. This patch is important if acpi_enable() is used in the resume from S3 path. Many systems today are seen coming back from S3 with SCI_EN off, and then failing to set SCI_EN in response to acpi_enable(). Those systems will take 3 seconds longer to resume due to this loop. However, it is possible that we will not use acpi_enable() in the S3 resume path, and bang SCI_EN directly, which would make the loop harmless, as it would be invisible to all systems except those that need it. Signed-off-by: Len Brown <len.brown@intel.com>
| | * | | | | Merge branch 'bjorn-pci-root-v4-2.6.35' into releaseLen Brown2010-05-281-27/+40
| | |\ \ \ \ \
| | | * | | | | ACPI: pci_root: pass acpi_pci_root to arch-specific scanBjorn Helgaas2010-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The acpi_pci_root structure contains all the individual items (acpi_device, domain, bus number) we pass to pci_acpi_scan_root(), so just pass the single acpi_pci_root pointer directly. This will make it easier to add _CBA support later. For _CBA, we need the entire downstream bus range, not just the base bus number. We have that in the acpi_pci_root structure, so passing the pointer makes it available to the arch-specific code. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Len Brown <len.brown@intel.com>
OpenPOWER on IntegriCloud