Lines Matching full:gpe
1243 checking if the given GPE (as represented by a GPE device handle and a
1244 GPE number) is currently active and dispatching it (if that's the case)
1318 In the former case, if the status of a given GPE is set to start with,
1320 of the events (possibly) signaled before the GPE was enabled. In the
1321 latter case, however, the first caller of AcpiEnableGpe() for a given GPE
1324 the GPE before enabling it, to prevent stale events from triggering
1328 boolean argument indicating whether or not the GPE status needs to be
1778 Updated the GPE support to clear the status of all ACPI events when
2123 Implemented various improvements to the GPE support:
2131 4) Add parallel GPE handling to eliminate the possibility of dispatching
2132 the same GPE twice.
4399 Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix GPE storm issues.
4400 A raw gpe handling mechanism was created to allow better handling of GPE
4402 allows disabling/renabling of the GPE so that interrupt storms can be
4405 GPE. This API will leave the reference counts undisturbed, thereby
4406 preventing unintentional clearing of the GPE when the intent in only to
4408 GPE by removing GPE register locking. As such, raw handlers much provide
4409 their own locks while using GPE API's to protect access to GPE data
4413 Events: Always modify GPE registers under the GPE lock.
4414 Applies GPE lock around AcpiFinishGpe() to protect access to GPE register
4624 GPE support: During ACPICA/GPE initialization, ensure that all GPEs with
4629 Added a new return flag for the Event/GPE status interfaces --
4632 GPE currently has a handler associated with it, and can thus actually
4788 Implemented a new GPE public interface, AcpiMarkGpeForWake. Provides a
4793 handler or control method associated with the particular GPE. This will
4794 help avoid meaningless GPEs and even GPE floods. Rafael Wysocki.
4796 Updated GPE handling and dispatch by disabling the GPE before clearing
4949 support for GPE numbers > 255, where some "GPE number" fields were 8-bits
4993 Debugger: Updated the GPE command (which simulates a GPE by executing the
4994 GPE code paths in ACPICA). The GPE device is now optional, and defaults
4995 to the GPE 0/1 FADT-defined blocks.
5031 and GPE handler removal. Restructured calls to eliminate possible race
5183 2) There is not already a GPE block attached to the device.
5283 Improve exception reporting and handling for GPE block installation.
5696 Removed an arbitrary restriction of 256 GPEs per GPE block (such as the
5697 FADT-defined GPE0 and GPE1). For GPE0, GPE1, and each GPE Block Device,
5698 the maximum number of GPEs is 1016. Use of multiple GPE block devices
5774 2) Fixed a possible memory leak in GPE init error path. ACPICA BZ 1018.
5953 FADT support: Removed an extraneous warning for very large GPE register
5955 field for a GPE register set is larger than the 64-bit GAS structure can
5956 accommodate. GPE register sets can be larger than the 255-bit width
6596 GPE support: Removed an extraneous parameter from the various low-level
6597 internal GPE functions. Tang Feng.
6761 devices to be notified by a single GPE. This feature automatically
6763 runtime device notification in the absence of a BIOS-provided GPE control
6764 method (_Lxx/_Exx) or a host-installed handler for the GPE. Implicit
6844 Within ACPICA, it is only called before a notify or GPE handler is
8007 Implemented an optimization for GPE detection. This optimization will
8009 ignore GPE registers that contain no enabled GPEs -- there is no need to
8011 becomes more important on machines with a large GPE space. ACPICA
8077 iASL: Added detection of GPE method name conflicts. Detects a conflict
8079 there are two GPE methods of the form _Lxy and _Exy in the same scope.
8188 Completed the major overhaul of the GPE support code that was begun in
8191 executes _PRWs anyway), cleanup of "wake" GPE interfaces and processing,
8192 changes to existing interfaces, simplification of GPE handler operation,
8200 One new file, evxfgpe.c to consolidate all external GPE interfaces.
8203 information. See the new section 4.4 "General Purpose Event (GPE)
8211 Implemented a new GPE feature for Windows compatibility, the "Implicit
8213 GPE Notify". This feature will automatically issue a Notify(2) on a
8215 when a Wake GPE is received if there is no corresponding GPE method or
8511 Implemented several updates to the recently added GPE reference count
8522 2) Ensure that GPE enable masks stay in sync with the reference count.
8523 3) Do not inadvertently enable GPEs when writing GPE registers.
8530 Changed the behavior of the GPE install/remove handler interfaces. The
8531 GPE
8715 Implemented GPE support for dynamically loaded ACPI tables. For all GPEs,
8716 including FADT-based and GPE Block Devices, execute any _PRW methods in
8718 new table, and process any _Lxx/_Exx GPE methods in the new table. Any
8719 runtime GPE that is referenced by an _Lxx/_Exx method in the new table is
8720 immediately enabled. Handles the FADT-defined GPEs as well as GPE Block
8800 Completed a major update for the GPE support in order to improve support
8807 removed. One new external interface was added. Most of the GPE external
8808 interfaces now use the GPE spinlock instead of the events mutex (and the
8809 Flags parameter for many GPE interfaces has been removed.) See the
9992 AcpiGetGpeDevice - Get the GPE block device associated with a GPE.
10351 Fix a possible deadlock in the GPE dispatch. Remove call to
10354 to acquire the GPE lock but can deadlock since the GPE lock is already
10475 Implemented a "careful" GPE disable in AcpiEvDisableGpe, only modify one
10480 enabling of GPEs if a rogue GPE is received during initialization (before
10481 GPE
10593 Fixed a problem where the invocation of a GPE control method could hang.
10596 validation mechanism can enter an infinite loop when a GPE method is
10597 dispatched. Problem fixed by removing the obsolete code that passed GPE
10665 machines. Moved GPE enable until after _REG/_STA/_INI methods are run.
10680 the GPE, even if ACPICA thinks that that it is already disabled. It is
10681 possible that the AML or some other code has enabled the GPE unbeknownst
10764 Implemented an additional change to the GPE support in order to suppress
10769 the GPE is unknown to the system. This should prevent future interrupt
10771 from that GPE. BZ 6217 (Zhang Rui)
10860 Implemented another MS compatibility design change for GPE/Notify
11053 the underlying AML code changed the GPE enable registers. Now, any
11055 incoming GPE (no _Lxx/_Exx method and not the EC GPE) is immediately
11746 Change for GPE support: when a "wake" GPE is received, all wake GPEs are
11748 immediately disabled to prevent the waking GPE from firing again and to
12242 requested, such as global lock handler, notify handler, GPE handler, etc.
13105 Modified the subsystem initialization sequence to improve GPE support.
13107 GPE initialization has been split into two parts in order to defer
13938 Replaced "InterruptLevel" with "InterruptNumber" in all GPE interfaces
15175 Restructured the internal HW GPE interfaces to pass/track the current
15373 Fixed a problem where hardware GPE enable bits sometimes not set properly
15374 during and after GPE method execution. Result of 04/27 changes.
15424 Completed a major overhaul of the GPE handling within ACPI CA. There are
15433 enabled. Any GPE that is referenced by a _PRW method is marked for
15442 be used by device drivers to force a GPE to a particular type. It will
15453 GPE enable/disable no longer reads the GPE enable register. We now keep
15458 Always clear the wake status and fixed/GPE status bits before sleep, even
15461 Improved the AML debugger output for displaying the GPE blocks and their
15483 structure for each GPE in the system, so the size of this structure is
15498 Notes for updating drivers for the new GPE support. The following
15505 1) AcpiInstallGpeHandler no longer automatically enables the GPE, you
15509 before enabling the GPE. Also, this interface will automatically disable
15510 the GPE if it is currently enabled.
15511 3) AcpiEnableGpe no longer supports a GPE type flag.
15523 Extract GPE number and possibly GpeDevice
15527 For all other devices that have _PRWs, we automatically set the GPE type
15529 ACPI_GPE_TYPE_WAKE, but the GPE is NOT automatically (wake) enabled.
15622 _PRW methods. Every GPE that is pointed to by one or more _PRWs is
15623 identified as a WAKE GPE and by default will no longer be enabled at
15631 This new GPE behavior is can be reverted to the original behavior (enable
15761 After wake, clear GPE status register(s) before enabling GPEs.
15895 Fixed a problem where a level-triggered GPE with an associated
15937 Fixed a reported error where and incorrect GPE number was passed
15938 to the GPE dispatch handler. This value is only used for error
15940 the GPE dispatch code.
16338 The GPE Block Device support has been completed. New interfaces
16342 Events (GPEs) in order to support GPE Block Devices properly.
16371 The GPE handling and dispatch code has been completely overhauled
16372 in preparation for support of GPE Block Devices (ID ACPI0006).
16378 fields that are used to determine the GPE block lengths. The
16734 Fixed a problem with the GPE initialization that resulted from an
16736 specification states that both the address and length of the GPE
16740 the length must be non-zero to indicate a valid GPE block (i.e.,
16741 if either the address or the length is zero, the GPE block is
16919 block were not handled correctly. This resulted in a "GPE
17002 problems with ASL Mutex objects and error messages for GPE
17908 GPE, Fixed Event, and PM Timer I/O. This allows the use of memory
18038 Fixed a problem where the GPE bit masks were not initialized
18039 properly, causing erratic GPE behavior.
18191 Fixed a reported problem with the GPE number mapping mechanism
18193 Reorganized the GPE information and shrunk a large array that was
18195 to simply large enough to hold all GPEs up to the largest GPE
18203 enabling/disabling a GPE.
18215 Removed obsolete and unnecessary GPE save/restore code.
18749 modified to allow individual GPE levels to be flagged as wake-