- 03 8月, 2010 5 次提交
-
-
由 Thomas Renninger 提交于
which will result in a harmless but ugly WARN message on some machines. Signed-off-by: NThomas Renninger <trenn@suse.de> CC: mjg59@srcf.ucam.org CC: platform-driver-x86@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: astarikovskiy@suse.de CC: akpm@linux-foundation.org Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Thomas Renninger 提交于
Formerly these have been exposed through /proc/.. Better register them where all IO ports should get registered and scream loud if someone else claims to use them. EC data and command port typically should show up like this then: ... 0060-0060 : keyboard 0062-0062 : EC data 0064-0064 : keyboard 0066-0066 : EC command 0070-0071 : rtc0 ... Signed-off-by: NThomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Thomas Renninger 提交于
A userspace app to easily read/write the EC can be found here: ftp://ftp.suse.com/pub/people/trenn/sources/ec/ec_access.c Multiple ECs are not supported, but shouldn't be hard to add as soon as the ec driver itself will support them. Signed-off-by: NThomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: platform-driver-x86@vger.kernel.org Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Thomas Renninger 提交于
This patch provides the same information through debugfs, which previously was provided through /proc/acpi/embedded_controller/*/info This is the gpe the EC is connected to and whether the global lock gets used. The io ports used are added to /proc/ioports in another patch. Beside the fact that /proc/acpi is deprecated for quite some time, this info is not needed for applications and thus can be moved to debugfs instead of a public interface like /sys. Signed-off-by: NThomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: Bjorn Helgaas <bjorn.helgaas@hp.com> CC: platform-driver-x86@vger.kernel.org Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
由 Thomas Renninger 提交于
Other patches in this series add the same info to /sys/... and /proc/ioports. The info removed should never have been used in an application, eventually someone read it manually. /proc/acpi is deprecated for more than a year anyway... Signed-off-by: NThomas Renninger <trenn@suse.de> CC: Alexey Starikovskiy <astarikovskiy@suse.de> CC: Len Brown <lenb@kernel.org> CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: platform-driver-x86@vger.kernel.org Signed-off-by: NMatthew Garrett <mjg@redhat.com>
-
- 25 7月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 2a6b6976 (ACPI: Store NVS state even when entering suspend to RAM) caused the ACPI suspend code save the NVS area during suspend and restore it during resume unconditionally, although it is known that some systems need to use acpi_sleep=s4_nonvs for hibernation to work. To allow the affected systems to avoid saving and restoring the NVS area during suspend to RAM and resume, introduce kernel command line option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its alias temporarily (add acpi_sleep=s4_nonvs to the feature removal file). Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16396 . Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: Ntomas m <tmezzadra@gmail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 23 7月, 2010 2 次提交
-
-
由 Len Brown 提交于
processor.bm_check_disable=1" prevents Linux from checking BM_STS before entering C3-type cpu power states. This may be useful for a system running acpi_idle where the BIOS exports FADT C-states, _CST IO C-states, or _CST FFH C-states with the BM_STS bit set; while configuring the chipset to set BM_STS more frequently than perhaps is optimal. Note that such systems may have been developed using a tickful OS that would quickly clear BM_STS, rather than a tickless OS that may go for some time between checking and clearing BM_STS. Note also that an alternative for newer systems is to use the intel_idle driver, which always ignores BM_STS, relying Linux device drivers to register constraints explicitly via PM_QOS. https://bugzilla.kernel.org/show_bug.cgi?id=15886Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
It turns out that there is a bit in the _CST for Intel FFH C3 that tells the OS if we should be checking BM_STS or not. Linux has been unconditionally checking BM_STS. If the chip-set is configured to enable BM_STS, it can retard or completely prevent entry into deep C-states -- as illustrated by turbostat: http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/ ref: Intel Processor Vendor-Specific ACPI Interface Specification table 4 "_CST FFH GAS Field Encoding" Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state https://bugzilla.kernel.org/show_bug.cgi?id=15886Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 21 7月, 2010 1 次提交
-
-
由 KOSAKI Motohiro 提交于
CONFIG_ACPI_PROCFS=n: drivers/acpi/processor_idle.c:83: warning: 'us_to_pm_timer_ticks' defined but not used. Signed-off-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 13 7月, 2010 1 次提交
-
-
由 Alex Chiang 提交于
The commit 5d554a7b (ACPI: processor: add internal processor_physically_present()) is broken on uniprocessor (UP) configurations, as acpi_get_cpuid() will always return -1. We use the value of num_possible_cpus() to tell us whether we got an invalid cpuid from acpi_get_cpuid() in the SMP case, or if instead, we are UP, in which case num_possible_cpus() is #defined as 1. We use num_possible_cpus() instead of num_online_cpus() to protect ourselves against the scenario of CPU hotplug, and we've taken down all the CPUs except one. Thanks to Jan Pogadl for initial report and analysis and Chen Gong for review. https://bugzilla.kernel.org/show_bug.cgi?id=16357 Reported-by: Jan Pogadl <pogadl.jan@googlemail.com>: Reviewed-by: NChen Gong <gong.chen@linux.intel.com> Signed-off-by: NAlex Chiang <achiang@canonical.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 07 7月, 2010 2 次提交
-
-
由 Nik A. Melchior 提交于
Fix string mismatch for Sony SR290 laptop. https://bugzilla.kernel.org/show_bug.cgi?id=12904#c45Signed-off-by: NNik A. Melchior <melchior+kernel@cmu.edu> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
When battery is hot-added, we should not invoke power_supply_changed in acpi_battery_notify, because it has been invoked in acpi_battery_update, and battery->bat.changed_work is queued in keventd already. https://bugzilla.kernel.org/show_bug.cgi?id=16244Signed-off-by: NZhang Rui <rui.zhang@intel.com> Acked-by: NAlexey Starikovskiy <astarikovskiy@sude.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 02 7月, 2010 1 次提交
-
-
由 Daniel J Blueman 提交于
When booting 2.6.35-rc3 on a x86 system without an ERST ACPI table with the 'quiet' option, we still observe an "ERST: Table is not found!" warning. Quiesce it to the same info log level as the other 'table not found' warnings. Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 29 6月, 2010 1 次提交
-
-
由 Len Brown 提交于
Folklore suggested that such systems existed in the pre-history of ACPI. However, we removed the SCI_EN polling loop from acpi_hw_set_mode() in b430acbd because it delayed resume by 3 seconds on boxes that refused to set SCI_EN. Matthew removed the call to acpi_enable() from the suspend resume path. James found a modern system that still needs to be polled upon boot. So here we restore the workaround, except that we put it in acpi_enable() rather than the low level acpi_hw_set_mode(). https://bugzilla.kernel.org/show_bug.cgi?id=16271Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 6月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
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: NTejun Heo <tj@kernel.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Len Brown <lenb@kernel.org> Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
-
- 18 6月, 2010 1 次提交
-
-
由 Rafael J. Wysocki 提交于
After commit 9630bdd9 (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=15951Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NMichal Hocko <mhocko@suse.cz> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 12 6月, 2010 8 次提交
-
-
由 Matthew Garrett 提交于
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: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bob Moore 提交于
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=854Signed-off-by: NBob Moore <robert.moore@intel.com> Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
Commit 0f849d2c (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: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 10 6月, 2010 5 次提交
-
-
由 Zhang Rui 提交于
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: NVoldemar <harestomper@gmail.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Liang Li 提交于
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: NLiang Li <liang.li@windriver.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Matthew Garrett 提交于
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: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Matthew Garrett 提交于
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: NMatthew Garrett <mjg@redhat.com> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Tested-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Thomas Renninger 提交于
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: NThomas Renninger <trenn@suse.de> CC: travis@sgi.com CC: linux-acpi@vger.kernel.org CC: lenb@kernel.org Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 05 6月, 2010 2 次提交
-
-
由 Venkatesh Pallipadi 提交于
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: NVenkatesh Pallipadi <venki@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhao Yakui 提交于
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: 2da513f5 (ACPI: Minor cleanup eliminating redundant PMTIMER_TICKS to NS conversion) Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Reported-by: NYu Zhidong <zhidong.yu@intel.com> Tested-by: NYu Zhidong <zhidong.yu@intel.com> Acked-by: NVenkatesh Pallipadi <venki@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 04 6月, 2010 1 次提交
-
-
由 Chen Gong 提交于
As suggested in Venki's suggestion in the commit 0dc698b9, add LAPIC unstable detection in the acpi_pad drvier too. Signed-off-by: NChen Gong <gong.chen@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 29 5月, 2010 7 次提交
-
-
由 Rafael J. Wysocki 提交于
The names of the functions used for blocking/unblocking EC transactions during suspend/hibernation suggest that the transactions are suspended and resumed by them, while in fact they are disabled and enabled. Rename the functions (and the flag used by them) to better reflect what they really do. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rafael J. Wysocki 提交于
There still is a race that may result in suspending the system in the middle of an EC transaction in progress, which leads to problems (like the kernel thinking that the ACPI global lock is held during resume while in fact it's not). To remove the race condition, modify the ACPI platform suspend and hibernate callbacks so that EC transactions are blocked right after executing the _PTS global control method and are allowed to happen again right after the low-level wakeup. Introduce acpi_pm_freeze() that will disable GPEs, wait until the event queues are empty and block EC transactions. Use it wherever GPEs are disabled in preparation for switching local interrupts off. Introduce acpi_pm_thaw() that will allow EC transactions to happen again and enable runtime GPEs. Use it to balance acpi_pm_freeze() wherever necessary. In addition to that use acpi_ec_resume_transactions_early() to unblock EC transactions as early as reasonably possible during resume. Also unblock EC transactions in acpi_hibernation_finish() and in the analogous suspend routine to make sure that the EC transactions are enabled in all error paths. Fixes https://bugzilla.kernel.org/show_bug.cgi?id=14668Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Reported-and-tested-by: NMaxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Venkatesh Pallipadi 提交于
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: NVenkatesh Pallipadi <venki@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Andrea Gelmini 提交于
drivers/acpi/sleep.h:3: WARNING: space prohibited between function name and open parenthesis '(' Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Venkatesh Pallipadi 提交于
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: NVenkatesh Pallipadi <venki@google.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
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: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
commit d306ebc2 (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: NLen Brown <len.brown@intel.com> Acked-by: NVenkatesh Pallipadi <venki@google.com>
-
- 28 5月, 2010 1 次提交
-
-
由 Len Brown 提交于
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: NLen Brown <len.brown@intel.com> Cc: Shaohua Li <shaohua.li@intel.com>
-