- 10 9月, 2009 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The wakeup.prepared flag is used for marking devices that have the wake-up power already enabled, so that the wake-up power is not enabled twice in a row for the same device. This assumes, however, that device wake-up power will only be enabled once, while the device is being prepared for a system-wide sleep transition, and the second attempt is made by acpi_enable_wakeup_device_prep(). With the upcoming PCI wake-up rework this assumption will not hold any more for PCI bridges and the root bridge whose wake-up power may be enabled as a result of wake-up enable propagation from other devices (eg. add-on devices that are not associated with any GPEs). Thus, there may be many attempts to enable wake-up power on a PCI bridge or the root bridge during a system power state transition and it's better to replace wakeup.prepared with a reference counter. Reviewed-by: NMatthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 07 4月, 2009 1 次提交
-
-
由 Shaohua Li 提交于
Convert acpi_device_lock to a mutex to avoid a potential race upon access to /proc/acpi/wakeup Delete the lock entirely in wakeup.c since it is not necessary (and can not sleep) Found-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NShaohua Li <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 3月, 2009 1 次提交
-
-
由 Bjorn Helgaas 提交于
This patch makes acpi_init() call acpi_wakeup_device_init() directly. Previously, acpi_wakeup_device_init() was a late_initcall (sequence 7). acpi_wakeup_device_init() depends on acpi_wakeup_device_list, which is populated when ACPI devices are enumerated by acpi_init() -> acpi_scan_init(). Using late_initcall is certainly enough to make sure acpi_wakeup_device_list is populated, but it is more than necessary. We can just as easily call acpi_wakeup_device_init() directly from acpi_init(), which avoids the initcall magic. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> CC: Li Shaohua <shaohua.li@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 3月, 2009 1 次提交
-
-
由 Bjorn Helgaas 提交于
A number of things that shouldn't be exposed outside the ACPI core were declared in include/acpi/acpi_drivers.h, where anybody can see them. This patch moves those declarations to a new "internal.h" inside drivers/acpi. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 09 1月, 2009 1 次提交
-
-
由 Len Brown 提交于
also, delete sleep/ and delete ACPI_CFLAGS from Makefile Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 31 12月, 2008 2 次提交
-
-
由 Lin Ming 提交于
External driver files should not include any private acpica headers. Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Lin Ming 提交于
ACPI_FUNCTION_TRACE is an internal acpica function. remove ACPI_FUNCTION_TRACE Signed-off-by: NLin Ming <ming.m.lin@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 12 11月, 2008 1 次提交
-
-
由 Alexey Starikovskiy 提交于
Disabling gpe might interfere with gpe detection/handling, thus producing "interrupt not handled" errors. Ironically, disabling of GPE from interrupt context is already under spinlock, so only userspace needs to start using it. Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 08 7月, 2008 2 次提交
-
-
由 Rafael J. Wysocki 提交于
* Introduce function acpi_pm_device_sleep_wake() for enabling and disabling the system wake-up capability of devices that are power manageable by ACPI. * Introduce function acpi_bus_can_wakeup() allowing other (dependent) subsystems to check if ACPI is able to enable the system wake-up capability of given device. * Introduce callback .sleep_wake() in struct pci_platform_pm_ops and for the ACPI PCI 'driver' make it use acpi_pm_device_sleep_wake(). * Introduce callback .can_wakeup() in struct pci_platform_pm_ops and for the ACPI 'driver' make it use acpi_bus_can_wakeup(). * Move the PME# handlig code out of pci_enable_wake() and split it into two functions, pci_pme_capable() and pci_pme_active(), allowing the caller to check if given device is capable of generating PME# from given power state and to enable/disable the device's PME# functionality, respectively. * Modify pci_enable_wake() to use the new ACPI callbacks and the new PME#-related functions. * Drop the generic .platform_enable_wakeup() callback that is not used any more. * Introduce device_set_wakeup_capable() that will set the power.can_wakeup flag of given device. * Rework PCI device PM initialization so that, if given device is capable of generating wake-up events, either natively through the PME# mechanism, or with the help of the platform, its power.can_wakeup flag is set and its power.should_wakeup flag is unset as appropriate. * Make ACPI set the power.can_wakeup flag for devices found to be wake-up capable by it. * Make the ACPI wake-up code enable/disable GPEs for devices that have the wakeup.flags.prepared flag set (which means that their wake-up power has been enabled). Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Rafael J. Wysocki 提交于
The currect ACPI code attempts to execute _PSW at three different places and in one of them only it tries to execute _DSW before _PSW, which is inconsistent with the other two cases. Move the execution of _DSW and _PSW into a separate function called acpi_device_sleep_wake() and call it wherever appropriate instead of executing _DSW and/or _PSW directly. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 28 9月, 2007 1 次提交
-
-
由 Alexey Starikovskiy 提交于
S4 suspend to disk will disable GPE's permanently because acpi_gpe_sleep_prepare() does not have a counterpart at resume time. Thus, those devices became unavailable for wakeup from subsequent S3 suspend-to-ram. Here acpi_gpe_sleep_prepare() is removed, and upon suspend acpi_enable_wakeup_device() gets its functionality. Upon resume, acpi_disable_wakeup_device() restores the state. https://bugzilla.novell.com/show_bug.cgi?id=292300Signed-off-by: NAlexey Starikovskiy <astarikovskiy@suse.de> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 25 7月, 2007 1 次提交
-
-
由 Len Brown 提交于
As it was a synonym for (CONFIG_ACPI && CONFIG_X86), the ifdefs for it were more clutter than they were worth. For ia64, just add a few stubs in anticipation of future S3 or S4 support. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 07 11月, 2006 1 次提交
-
-
由 Satoru Takeuchi 提交于
Fixing wrong description for acpi_gpe_sleep_prepare(). acpi_gpe_sleep_prepare() had only used on power off and was changed to also used on entering some sleep state. However its description isn't changed yet. Signed-off-by: NSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 04 4月, 2006 1 次提交
-
-
由 Bjorn Helgaas 提交于
Internal BIOS names like these should be exposed to the user as little as possible: ACPI wakeup devices: C069 C0CE C1D1 C0DE C1D4 Eventually, the "wakeup" property of a device should be exported via the device tree, not by a printk of an internal BIOS name. For the hard-core, these are still available in /proc/acpi/wakeup_devices, just not printed to dmesg. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 16 12月, 2005 1 次提交
-
-
由 Alexey Starikovskiy 提交于
http://bugzilla.kernel.org/show_bug.cgi?id=4320Signed-off-by: NAlexey Starikovskiy <alexey.y.starikovskiy@intel.com> Acked-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 05 8月, 2005 1 次提交
-
-
由 Len Brown 提交于
Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-