OpenCloudOS-Kernel/drivers/acpi/acpica/evgpeinit.c

424 lines
12 KiB
C
Raw Normal View History

// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
/******************************************************************************
*
* Module Name: evgpeinit - System GPE initialization and update
*
* Copyright (C) 2000 - 2021, Intel Corp.
*
*****************************************************************************/
#include <acpi/acpi.h>
#include "accommon.h"
#include "acevents.h"
#include "acnamesp.h"
#define _COMPONENT ACPI_EVENTS
ACPI_MODULE_NAME("evgpeinit")
#if (!ACPI_REDUCED_HARDWARE) /* Entire module */
/*
* Note: History of _PRW support in ACPICA
*
* Originally (2000 - 2010), the GPE initialization code performed a walk of
* the entire namespace to execute the _PRW methods and detect all GPEs
* capable of waking the system.
*
* As of 10/2010, the _PRW method execution has been removed since it is
* actually unnecessary. The host OS must in fact execute all _PRW methods
* in order to identify the device/power-resource dependencies. We now put
* the onus on the host OS to identify the wake GPEs as part of this process
* and to inform ACPICA of these GPEs via the acpi_setup_gpe_for_wake interface. This
* not only reduces the complexity of the ACPICA initialization code, but in
* some cases (on systems with very large namespaces) it should reduce the
* kernel boot time as well.
*/
ACPICA: Add support for using logical addresses of GPE blocks The logical address of every GPE block in system memory must be known before passing it to acpi_ev_initialize_gpe_block(), because memory cannot be mapped on the fly from an interrupt handler. Accordingly, the host OS must map every GPE block in system memory upfront and it can store the logical addresses of GPE blocks for future use. If these logical addresses were known to ACPICA, it could use them instead of the corresponding physical addresses of GPE block for GPE register accesses and the memory mapping lookups carried out by acpi_os_read_memory() and acpi_os_write_memory() on every attempt to access a GPE register would not be necessary any more. To allow that to happen, introduce the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol to indicate whether or not the host OS wants ACPICA to use the logical addresses of GPE registers in system memory directly (which is the case if this symbol is defined). Moreover, conditional on whether ACPI_GPE_USE_LOGICAL_ADDRESSES is defined, introduce two new global variables for storing the logical addresses of the FADT GPE blocks 0 and 1, respectively, acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, make acpi_ev_gpe_initialize() pass their values instead of the physical addresses of the GPE blocks in question to acpi_ev_create_gpe_block() and modify acpi_hw_gpe_read() and acpi_hw_gpe_write() to access memory directly via the addresses stored in the struct acpi_gpe_address objects, which are expected to be the logical addresses of GPE registers if ACPI_GPE_USE_LOGICAL_ADDRESSES is defined. With the above changes in place, a host OS wanting ACPICA to access GPE registers directly through their logical addresses needs to define the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol and make sure that the logical addresses of the FADT GPE blocks 0 and 1 are stored in acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, respectively, prior to calling acpi_ev_gpe_initialize(). [If such a host OS also uses acpi_install_gpe_block() to add non-FADT GPE register blocks located in system memory, it must pass their logical addresses instead of their physical addresses to this function.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-11 22:44:45 +08:00
#ifdef ACPI_GPE_USE_LOGICAL_ADDRESSES
#define ACPI_FADT_GPE_BLOCK_ADDRESS(N) \
acpi_gbl_FADT.xgpe##N##_block.space_id == \
ACPI_ADR_SPACE_SYSTEM_MEMORY ? \
(u64)acpi_gbl_xgpe##N##_block_logical_address : \
acpi_gbl_FADT.xgpe##N##_block.address
#else
#define ACPI_FADT_GPE_BLOCK_ADDRESS(N) acpi_gbl_FADT.xgpe##N##_block.address
#endif /* ACPI_GPE_USE_LOGICAL_ADDRESSES */
/*******************************************************************************
*
* FUNCTION: acpi_ev_gpe_initialize
*
* PARAMETERS: None
*
* RETURN: Status
*
* DESCRIPTION: Initialize the GPE data structures and the FADT GPE 0/1 blocks
*
******************************************************************************/
acpi_status acpi_ev_gpe_initialize(void)
{
u32 register_count0 = 0;
u32 register_count1 = 0;
u32 gpe_number_max = 0;
acpi_status status;
ACPICA: Add support for using logical addresses of GPE blocks The logical address of every GPE block in system memory must be known before passing it to acpi_ev_initialize_gpe_block(), because memory cannot be mapped on the fly from an interrupt handler. Accordingly, the host OS must map every GPE block in system memory upfront and it can store the logical addresses of GPE blocks for future use. If these logical addresses were known to ACPICA, it could use them instead of the corresponding physical addresses of GPE block for GPE register accesses and the memory mapping lookups carried out by acpi_os_read_memory() and acpi_os_write_memory() on every attempt to access a GPE register would not be necessary any more. To allow that to happen, introduce the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol to indicate whether or not the host OS wants ACPICA to use the logical addresses of GPE registers in system memory directly (which is the case if this symbol is defined). Moreover, conditional on whether ACPI_GPE_USE_LOGICAL_ADDRESSES is defined, introduce two new global variables for storing the logical addresses of the FADT GPE blocks 0 and 1, respectively, acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, make acpi_ev_gpe_initialize() pass their values instead of the physical addresses of the GPE blocks in question to acpi_ev_create_gpe_block() and modify acpi_hw_gpe_read() and acpi_hw_gpe_write() to access memory directly via the addresses stored in the struct acpi_gpe_address objects, which are expected to be the logical addresses of GPE registers if ACPI_GPE_USE_LOGICAL_ADDRESSES is defined. With the above changes in place, a host OS wanting ACPICA to access GPE registers directly through their logical addresses needs to define the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol and make sure that the logical addresses of the FADT GPE blocks 0 and 1 are stored in acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, respectively, prior to calling acpi_ev_gpe_initialize(). [If such a host OS also uses acpi_install_gpe_block() to add non-FADT GPE register blocks located in system memory, it must pass their logical addresses instead of their physical addresses to this function.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-11 22:44:45 +08:00
u64 address;
ACPI_FUNCTION_TRACE(ev_gpe_initialize);
ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT,
"Initializing General Purpose Events (GPEs):\n"));
status = acpi_ut_acquire_mutex(ACPI_MTX_NAMESPACE);
if (ACPI_FAILURE(status)) {
return_ACPI_STATUS(status);
}
/*
* Initialize the GPE Block(s) defined in the FADT
*
* Why the GPE register block lengths are divided by 2: From the ACPI
* Spec, section "General-Purpose Event Registers", we have:
*
* "Each register block contains two registers of equal length
* GPEx_STS and GPEx_EN (where x is 0 or 1). The length of the
* GPE0_STS and GPE0_EN registers is equal to half the GPE0_LEN
* The length of the GPE1_STS and GPE1_EN registers is equal to
* half the GPE1_LEN. If a generic register block is not supported
* then its respective block pointer and block length values in the
* FADT table contain zeros. The GPE0_LEN and GPE1_LEN do not need
* to be the same size."
*/
/*
* Determine the maximum GPE number for this machine.
*
* Note: both GPE0 and GPE1 are optional, and either can exist without
* the other.
*
* If EITHER the register length OR the block address are zero, then that
* particular block is not supported.
*/
ACPICA: Add support for using logical addresses of GPE blocks The logical address of every GPE block in system memory must be known before passing it to acpi_ev_initialize_gpe_block(), because memory cannot be mapped on the fly from an interrupt handler. Accordingly, the host OS must map every GPE block in system memory upfront and it can store the logical addresses of GPE blocks for future use. If these logical addresses were known to ACPICA, it could use them instead of the corresponding physical addresses of GPE block for GPE register accesses and the memory mapping lookups carried out by acpi_os_read_memory() and acpi_os_write_memory() on every attempt to access a GPE register would not be necessary any more. To allow that to happen, introduce the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol to indicate whether or not the host OS wants ACPICA to use the logical addresses of GPE registers in system memory directly (which is the case if this symbol is defined). Moreover, conditional on whether ACPI_GPE_USE_LOGICAL_ADDRESSES is defined, introduce two new global variables for storing the logical addresses of the FADT GPE blocks 0 and 1, respectively, acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, make acpi_ev_gpe_initialize() pass their values instead of the physical addresses of the GPE blocks in question to acpi_ev_create_gpe_block() and modify acpi_hw_gpe_read() and acpi_hw_gpe_write() to access memory directly via the addresses stored in the struct acpi_gpe_address objects, which are expected to be the logical addresses of GPE registers if ACPI_GPE_USE_LOGICAL_ADDRESSES is defined. With the above changes in place, a host OS wanting ACPICA to access GPE registers directly through their logical addresses needs to define the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol and make sure that the logical addresses of the FADT GPE blocks 0 and 1 are stored in acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, respectively, prior to calling acpi_ev_gpe_initialize(). [If such a host OS also uses acpi_install_gpe_block() to add non-FADT GPE register blocks located in system memory, it must pass their logical addresses instead of their physical addresses to this function.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-11 22:44:45 +08:00
address = ACPI_FADT_GPE_BLOCK_ADDRESS(0);
if (acpi_gbl_FADT.gpe0_block_length && address) {
/* GPE block 0 exists (has both length and address > 0) */
register_count0 = (u16)(acpi_gbl_FADT.gpe0_block_length / 2);
gpe_number_max =
(register_count0 * ACPI_GPE_REGISTER_WIDTH) - 1;
/* Install GPE Block 0 */
status = acpi_ev_create_gpe_block(acpi_gbl_fadt_gpe_device,
address,
acpi_gbl_FADT.xgpe0_block.
space_id, register_count0, 0,
acpi_gbl_FADT.sci_interrupt,
&acpi_gbl_gpe_fadt_blocks[0]);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
"Could not create GPE Block 0"));
}
}
ACPICA: Add support for using logical addresses of GPE blocks The logical address of every GPE block in system memory must be known before passing it to acpi_ev_initialize_gpe_block(), because memory cannot be mapped on the fly from an interrupt handler. Accordingly, the host OS must map every GPE block in system memory upfront and it can store the logical addresses of GPE blocks for future use. If these logical addresses were known to ACPICA, it could use them instead of the corresponding physical addresses of GPE block for GPE register accesses and the memory mapping lookups carried out by acpi_os_read_memory() and acpi_os_write_memory() on every attempt to access a GPE register would not be necessary any more. To allow that to happen, introduce the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol to indicate whether or not the host OS wants ACPICA to use the logical addresses of GPE registers in system memory directly (which is the case if this symbol is defined). Moreover, conditional on whether ACPI_GPE_USE_LOGICAL_ADDRESSES is defined, introduce two new global variables for storing the logical addresses of the FADT GPE blocks 0 and 1, respectively, acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, make acpi_ev_gpe_initialize() pass their values instead of the physical addresses of the GPE blocks in question to acpi_ev_create_gpe_block() and modify acpi_hw_gpe_read() and acpi_hw_gpe_write() to access memory directly via the addresses stored in the struct acpi_gpe_address objects, which are expected to be the logical addresses of GPE registers if ACPI_GPE_USE_LOGICAL_ADDRESSES is defined. With the above changes in place, a host OS wanting ACPICA to access GPE registers directly through their logical addresses needs to define the ACPI_GPE_USE_LOGICAL_ADDRESSES symbol and make sure that the logical addresses of the FADT GPE blocks 0 and 1 are stored in acpi_gbl_xgpe0_block_logical_address and acpi_gbl_xgpe1_block_logical_address, respectively, prior to calling acpi_ev_gpe_initialize(). [If such a host OS also uses acpi_install_gpe_block() to add non-FADT GPE register blocks located in system memory, it must pass their logical addresses instead of their physical addresses to this function.] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-09-11 22:44:45 +08:00
address = ACPI_FADT_GPE_BLOCK_ADDRESS(1);
if (acpi_gbl_FADT.gpe1_block_length && address) {
/* GPE block 1 exists (has both length and address > 0) */
register_count1 = (u16)(acpi_gbl_FADT.gpe1_block_length / 2);
/* Check for GPE0/GPE1 overlap (if both banks exist) */
if ((register_count0) &&
(gpe_number_max >= acpi_gbl_FADT.gpe1_base)) {
ACPI_ERROR((AE_INFO,
"GPE0 block (GPE 0 to %u) overlaps the GPE1 block "
"(GPE %u to %u) - Ignoring GPE1",
gpe_number_max, acpi_gbl_FADT.gpe1_base,
acpi_gbl_FADT.gpe1_base +
((register_count1 *
ACPI_GPE_REGISTER_WIDTH) - 1)));
/* Ignore GPE1 block by setting the register count to zero */
register_count1 = 0;
} else {
/* Install GPE Block 1 */
status =
acpi_ev_create_gpe_block(acpi_gbl_fadt_gpe_device,
address,
acpi_gbl_FADT.xgpe1_block.
space_id, register_count1,
acpi_gbl_FADT.gpe1_base,
acpi_gbl_FADT.
sci_interrupt,
&acpi_gbl_gpe_fadt_blocks
[1]);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
"Could not create GPE Block 1"));
}
/*
* GPE0 and GPE1 do not have to be contiguous in the GPE number
* space. However, GPE0 always starts at GPE number zero.
*/
}
}
/* Exit if there are no GPE registers */
if ((register_count0 + register_count1) == 0) {
/* GPEs are not required by ACPI, this is OK */
ACPI_DEBUG_PRINT((ACPI_DB_INIT,
"There are no GPE blocks defined in the FADT\n"));
goto cleanup;
}
cleanup:
(void)acpi_ut_release_mutex(ACPI_MTX_NAMESPACE);
return_ACPI_STATUS(AE_OK);
}
/*******************************************************************************
*
* FUNCTION: acpi_ev_update_gpes
*
* PARAMETERS: table_owner_id - ID of the newly-loaded ACPI table
*
* RETURN: None
*
* DESCRIPTION: Check for new GPE methods (_Lxx/_Exx) made available as a
* result of a Load() or load_table() operation. If new GPE
* methods have been installed, register the new methods.
*
******************************************************************************/
void acpi_ev_update_gpes(acpi_owner_id table_owner_id)
{
struct acpi_gpe_xrupt_info *gpe_xrupt_info;
struct acpi_gpe_block_info *gpe_block;
struct acpi_gpe_walk_info walk_info;
acpi_status status = AE_OK;
/*
* Find any _Lxx/_Exx GPE methods that have just been loaded.
*
ACPI / ACPICA: Do not execute _PRW methods during initialization Currently, during initialization ACPICA walks the entire ACPI namespace in search of any device objects with assciated _PRW methods. All of the _PRW methods found are executed in the process to extract the GPE information returned by them, so that the GPEs in question can be marked as "able to wakeup" (more precisely, the ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this exercise is to avoid enabling the CAN_WAKE GPEs automatically, even if there are _Lxx/_Exx methods associated with them. However, it is both costly and unnecessary, because the host OS has to execute the _PRW methods anyway to check which devices can wake up the system from sleep states. Moreover, it then uses full information returned by _PRW, including the GPE information, so it can take care of disabling the GPEs if necessary. Remove the code that walks the namespace and executes _PRW from ACPICA and modify comments to reflect that change. Make acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices so that they don't cause spurious wakeup events to be signaled. This not only reduces the complexity of the ACPICA initialization code, but in some cases it should reduce the kernel boot time as well. Unfortunately, for this purpose we need a new ACPICA function, acpi_gpe_can_wake(), to be called by the host OS in order to disable the GPEs that can wake up the system and were previously enabled by acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE should be disabled only once, because the initialization code enables it only once, but it may be pointed to by _PRW for multiple devices and that's why the additional function is necessary). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-08 06:43:36 +08:00
* Any GPEs that correspond to new _Lxx/_Exx methods are immediately
* enabled.
*
* Examine the namespace underneath each gpe_device within the
* gpe_block lists.
*/
status = acpi_ut_acquire_mutex(ACPI_MTX_EVENTS);
if (ACPI_FAILURE(status)) {
return;
}
walk_info.count = 0;
ACPI / ACPICA: Do not execute _PRW methods during initialization Currently, during initialization ACPICA walks the entire ACPI namespace in search of any device objects with assciated _PRW methods. All of the _PRW methods found are executed in the process to extract the GPE information returned by them, so that the GPEs in question can be marked as "able to wakeup" (more precisely, the ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this exercise is to avoid enabling the CAN_WAKE GPEs automatically, even if there are _Lxx/_Exx methods associated with them. However, it is both costly and unnecessary, because the host OS has to execute the _PRW methods anyway to check which devices can wake up the system from sleep states. Moreover, it then uses full information returned by _PRW, including the GPE information, so it can take care of disabling the GPEs if necessary. Remove the code that walks the namespace and executes _PRW from ACPICA and modify comments to reflect that change. Make acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices so that they don't cause spurious wakeup events to be signaled. This not only reduces the complexity of the ACPICA initialization code, but in some cases it should reduce the kernel boot time as well. Unfortunately, for this purpose we need a new ACPICA function, acpi_gpe_can_wake(), to be called by the host OS in order to disable the GPEs that can wake up the system and were previously enabled by acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE should be disabled only once, because the initialization code enables it only once, but it may be pointed to by _PRW for multiple devices and that's why the additional function is necessary). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-08 06:43:36 +08:00
walk_info.owner_id = table_owner_id;
walk_info.execute_by_owner_id = TRUE;
/* Walk the interrupt level descriptor list */
gpe_xrupt_info = acpi_gbl_gpe_xrupt_list_head;
while (gpe_xrupt_info) {
/* Walk all Gpe Blocks attached to this interrupt level */
gpe_block = gpe_xrupt_info->gpe_block_list_head;
while (gpe_block) {
walk_info.gpe_block = gpe_block;
walk_info.gpe_device = gpe_block->node;
status = acpi_ns_walk_namespace(ACPI_TYPE_METHOD,
walk_info.gpe_device,
ACPI_UINT32_MAX,
ACPI_NS_WALK_NO_UNLOCK,
acpi_ev_match_gpe_method,
NULL, &walk_info, NULL);
if (ACPI_FAILURE(status)) {
ACPI_EXCEPTION((AE_INFO, status,
"While decoding _Lxx/_Exx methods"));
}
gpe_block = gpe_block->next;
}
gpe_xrupt_info = gpe_xrupt_info->next;
}
ACPI / ACPICA: Do not execute _PRW methods during initialization Currently, during initialization ACPICA walks the entire ACPI namespace in search of any device objects with assciated _PRW methods. All of the _PRW methods found are executed in the process to extract the GPE information returned by them, so that the GPEs in question can be marked as "able to wakeup" (more precisely, the ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this exercise is to avoid enabling the CAN_WAKE GPEs automatically, even if there are _Lxx/_Exx methods associated with them. However, it is both costly and unnecessary, because the host OS has to execute the _PRW methods anyway to check which devices can wake up the system from sleep states. Moreover, it then uses full information returned by _PRW, including the GPE information, so it can take care of disabling the GPEs if necessary. Remove the code that walks the namespace and executes _PRW from ACPICA and modify comments to reflect that change. Make acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices so that they don't cause spurious wakeup events to be signaled. This not only reduces the complexity of the ACPICA initialization code, but in some cases it should reduce the kernel boot time as well. Unfortunately, for this purpose we need a new ACPICA function, acpi_gpe_can_wake(), to be called by the host OS in order to disable the GPEs that can wake up the system and were previously enabled by acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE should be disabled only once, because the initialization code enables it only once, but it may be pointed to by _PRW for multiple devices and that's why the additional function is necessary). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Len Brown <len.brown@intel.com>
2010-07-08 06:43:36 +08:00
if (walk_info.count) {
ACPI_INFO(("Enabled %u new GPEs", walk_info.count));
}
(void)acpi_ut_release_mutex(ACPI_MTX_EVENTS);
return;
}
/*******************************************************************************
*
* FUNCTION: acpi_ev_match_gpe_method
*
* PARAMETERS: Callback from walk_namespace
*
* RETURN: Status
*
* DESCRIPTION: Called from acpi_walk_namespace. Expects each object to be a
* control method under the _GPE portion of the namespace.
* Extract the name and GPE type from the object, saving this
* information for quick lookup during GPE dispatch. Allows a
* per-owner_id evaluation if execute_by_owner_id is TRUE in the
* walk_info parameter block.
*
* The name of each GPE control method is of the form:
* "_Lxx" or "_Exx", where:
* L - means that the GPE is level triggered
* E - means that the GPE is edge triggered
* xx - is the GPE number [in HEX]
*
* If walk_info->execute_by_owner_id is TRUE, we only execute examine GPE methods
* with that owner.
*
******************************************************************************/
acpi_status
acpi_ev_match_gpe_method(acpi_handle obj_handle,
u32 level, void *context, void **return_value)
{
struct acpi_namespace_node *method_node =
ACPI_CAST_PTR(struct acpi_namespace_node, obj_handle);
struct acpi_gpe_walk_info *walk_info =
ACPI_CAST_PTR(struct acpi_gpe_walk_info, context);
struct acpi_gpe_event_info *gpe_event_info;
acpi_status status;
u32 gpe_number;
u8 temp_gpe_number;
char name[ACPI_NAMESEG_SIZE + 1];
u8 type;
ACPI_FUNCTION_TRACE(ev_match_gpe_method);
/* Check if requested owner_id matches this owner_id */
if ((walk_info->execute_by_owner_id) &&
(method_node->owner_id != walk_info->owner_id)) {
return_ACPI_STATUS(AE_OK);
}
/*
* Match and decode the _Lxx and _Exx GPE method names
*
* 1) Extract the method name and null terminate it
*/
ACPI_MOVE_32_TO_32(name, &method_node->name.integer);
name[ACPI_NAMESEG_SIZE] = 0;
/* 2) Name must begin with an underscore */
if (name[0] != '_') {
return_ACPI_STATUS(AE_OK); /* Ignore this method */
}
/*
* 3) Edge/Level determination is based on the 2nd character
* of the method name
*/
switch (name[1]) {
case 'L':
type = ACPI_GPE_LEVEL_TRIGGERED;
break;
case 'E':
type = ACPI_GPE_EDGE_TRIGGERED;
break;
default:
/* Unknown method type, just ignore it */
ACPI_DEBUG_PRINT((ACPI_DB_LOAD,
"Ignoring unknown GPE method type: %s "
"(name not of form _Lxx or _Exx)", name));
return_ACPI_STATUS(AE_OK);
}
/* 4) The last two characters of the name are the hex GPE Number */
status = acpi_ut_ascii_to_hex_byte(&name[2], &temp_gpe_number);
if (ACPI_FAILURE(status)) {
/* Conversion failed; invalid method, just ignore it */
ACPI_DEBUG_PRINT((ACPI_DB_LOAD,
"Could not extract GPE number from name: %s "
"(name is not of form _Lxx or _Exx)", name));
return_ACPI_STATUS(AE_OK);
}
/* Ensure that we have a valid GPE number for this GPE block */
gpe_number = (u32)temp_gpe_number;
gpe_event_info =
acpi_ev_low_get_gpe_info(gpe_number, walk_info->gpe_block);
if (!gpe_event_info) {
/*
* This gpe_number is not valid for this GPE block, just ignore it.
* However, it may be valid for a different GPE block, since GPE0
* and GPE1 methods both appear under \_GPE.
*/
return_ACPI_STATUS(AE_OK);
}
ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs ACPICA commit 199cad16530a45aea2bec98e528866e20c5927e1 Since whether the GPE should be disabled/enabled/cleared should only be determined by the GPE driver's state machine: 1. GPE should be disabled if the driver wants to switch to the GPE polling mode when a GPE storm condition is indicated and should be enabled if the driver wants to switch back to the GPE interrupt mode when all of the storm conditions are cleared. The conditions should be protected by the driver's specific lock. 2. GPE should be enabled if the driver has accepted more than one request and should be disabled if the driver has completed all of the requests. The request count should be protected by the driver's specific lock. 3. GPE should be cleared either when the driver is about to handle an edge triggered GPE or when the driver has completed to handle a level triggered GPE. The handling code should be protected by the driver's specific lock. Thus the GPE enabling/disabling/clearing operations are likely to be performed with the driver's specific lock held while we currently cannot do this. This is because: 1. We have the acpi_gbl_gpe_lock held before invoking the GPE driver's handler. Driver's specific lock is likely to be held inside of the handler, thus we can see some dead lock issues due to the reversed locking order or recursive locking. In order to solve such dead lock issues, we need to unlock the acpi_gbl_gpe_lock before invoking the handler. BZ 1100. 2. Since GPE disabling/enabling/clearing should be determined by the GPE driver's state machine, we shouldn't perform such operations inside of ACPICA for a GPE handler to mess up the driver's state machine. BZ 1101. Originally this patch includes a logic to flush GPE handlers, it is dropped due to the following reasons: 1. This is a different issue; 2. Linux OSL has fixed this by flushing SCI in acpi_os_wait_events_complete(). We will pick up this topic when the Linux OSL fix turns out to be not sufficient. Note that currently the internal operations and the acpi_gbl_gpe_lock are also used by ACPI_GPE_DISPATCH_METHOD and ACPI_GPE_DISPATCH_NOTIFY. In order not to introduce regressions, we add one ACPI_GPE_DISPATCH_RAW_HANDLER type to be distiguished from ACPI_GPE_DISPATCH_HANDLER. For which the acpi_gbl_gpe_lock is unlocked before invoking the GPE handler and the internal enabling/disabling operations are bypassed to allow drivers to perform them at a proper position using the GPE APIs and ACPI_GPE_DISPATCH_RAW_HANDLER users should invoke acpi_set_gpe() instead of acpi_enable_gpe()/acpi_disable_gpe() to bypass the internal GPE clearing code in acpi_enable_gpe(). Lv Zheng. Known issues: 1. Edge-triggered GPE lost for frequent enablings On some buggy silicon platforms, GPE enable line may not be directly wired to the GPE trigger line. In that case, when GPE enabling is frequently performed for edge-triggered GPEs, GPE status may stay set without being triggered. This patch may maginify this problem as it allows GPE enabling to be parallel performed during the process the GPEs are handled. This is an existing issue, because: 1. For task context: Current ACPI_GPE_DISPATCH_METHOD practices have proven that this isn't a real issue - we can re-enable edge-triggered GPE in a work queue where the GPE status bit might already be set. 2. For IRQ context: This can even happen when the GPE enabling occurs before returning from the GPE handler and after unlocking the GPE lock. Thus currently no code is included to protect this. Link: https://github.com/acpica/acpica/commit/199cad16 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05 16:27:03 +08:00
if ((ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) ==
ACPI_GPE_DISPATCH_HANDLER) ||
(ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) ==
ACPI_GPE_DISPATCH_RAW_HANDLER)) {
/* If there is already a handler, ignore this GPE method */
return_ACPI_STATUS(AE_OK);
}
ACPICA: Events: Cleanup GPE dispatcher type obtaining code ACPICA commit 7926d5ca9452c87f866938dcea8f12e1efb58f89 There is an issue in acpi_install_gpe_handler() and acpi_remove_gpe_handler(). The code to obtain the GPE dispatcher type from the Handler->original_flags is wrong: if (((Handler->original_flags & ACPI_GPE_DISPATCH_METHOD) || (Handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) && ACPI_GPE_DISPATCH_NOTIFY is 0x03 and ACPI_GPE_DISPATCH_METHOD is 0x02, thus this statement is TRUE for the following dispatcher types: 0x01 (ACPI_GPE_DISPATCH_HANDLER): not expected 0x02 (ACPI_GPE_DISPATCH_METHOD): expected 0x03 (ACPI_GPE_DISPATCH_NOTIFY): expected There is no functional issue due to this because Handler->original_flags is only set in acpi_install_gpe_handler(), and an earlier checker has excluded the ACPI_GPE_DISPATCH_HANDLER: if ((gpe_event_info->Flags & ACPI_GPE_DISPATCH_MASK) == ACPI_GPE_DISPATCH_HANDLER) { Status = AE_ALREADY_EXISTS; goto free_and_exit; } ... Handler->original_flags = (u8) (gpe_event_info->Flags & (ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK)); We need to clean this up before modifying the GPE dispatcher type values. In order to prevent such issue from happening in the future, this patch introduces ACPI_GPE_DISPATCH_TYPE() macro to be used to obtain the GPE dispatcher types. Lv Zheng. Link: https://github.com/acpica/acpica/commit/7926d5ca Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05 15:20:29 +08:00
if (ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) ==
ACPI_GPE_DISPATCH_METHOD) {
/*
* If there is already a method, ignore this method. But check
* for a type mismatch (if both the _Lxx AND _Exx exist)
*/
if (type != (gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK)) {
ACPI_ERROR((AE_INFO,
"For GPE 0x%.2X, found both _L%2.2X and _E%2.2X methods",
gpe_number, gpe_number, gpe_number));
}
return_ACPI_STATUS(AE_OK);
}
/* Disable the GPE in case it's been enabled already. */
(void)acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_DISABLE);
/*
* Add the GPE information from above to the gpe_event_info block for
* use during dispatch of this GPE.
*/
gpe_event_info->flags &= ~(ACPI_GPE_DISPATCH_MASK);
gpe_event_info->flags |= (u8)(type | ACPI_GPE_DISPATCH_METHOD);
gpe_event_info->dispatch.method_node = method_node;
ACPI_DEBUG_PRINT((ACPI_DB_LOAD,
"Registered GPE method %s as GPE number 0x%.2X\n",
name, gpe_number));
return_ACPI_STATUS(AE_OK);
}
#endif /* !ACPI_REDUCED_HARDWARE */