Acpica gpe #38
Closed
Acpica gpe #38
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Updated to contain an additional patch to remove the old work queue flusher. |
|
Updated to remove the patch of AcpiEvEnableGpe removal. |
|
I added 3 more patches:
|
This patch adds support to add ACPICA upstream Commit ID/Author in the
generated linuxized patches. This format follows Linux stable material
format. The modifications include:
1. distiguish COMMITTER, AUTHOR, MAINTAINER:
1. COMMITTER is automatically extracted using "git config --get";
2. AUTHOR is automatically extracted using "git log --format=%aN <%aE>";
3. MAINTAINER is fixed in make-patches.sh, currently it is
"Bob Moore <robert.moore@intel.com>".
2. add AUTHOR and COMMIT ID information to form the ACPICA release patch
header.
3. automatically correct "Robert Moore <Robert.Moore@intel.com>" to
"Bob Moore <bob.moore@intel.com>".
4. automatically remove last empty lines in the patch description.
5. automatically append unique Signed-off-by for AUTHOR, NAINTAINER and
COMMITTER.
6. automatically add commit URL before SOBs and add "-l" option to be ready
for changing the host of the repo.
The generated patch format is ACKed by the Linux ACPI maintainer. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The OriginallyEnabled check is not paired between AcpiInstallGpeHandler() and AcpiRemoveGpeHandler(). This patch contains the code that is already in the Linux upstream. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The GPE APIs should be invoked inside of an IRQ context GPE handler or in the task context with a driver provided lock held. This driver provided lock should be safe to be held in the GPE handler by the driver. While currently we cannot do this, thus we can only use the GPE APIs for limitted cases. This patch adds reference counting for ACPI_GPE_HANDLER_INFO. Then the GPE handler can be safely invoked without holding the GPE lock, thus facilitates GPE APIs to be invoked in any atomic environment. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com>
…lers. The AcpiOsWaitEventsComplete() is used for flushing the deferred executed handlers, invoking it for GPE interrupt handlers doesn't help to protect GPE handler callback. On the contrary, it prevents GPE APIs from being invoked in the deferred notify handlers. Actually, the GPE interrupt handlers' invocation is protected by the previous implemented reference counting mechanism. This patch fixes this GPE APIs invocation issue in a seperate commit other than the reference counting one, so that if any regressions are reported, this patch can be temporarily reverted before the regressions are root caused. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch deletes a sanity check from AcpiEvEnableGpe().
This kind of check is already done in
AcpiEnableGpe()/AcpiRemoveGpeHandler()/AcpiUpdateAllGpes() before invoking
AcpiEvEnableGpe():
1. AcpiEnableGpe(): same check (skip if DISPATCH_NONE) is now implemented.
2. AcpiRemoveGpeHandler(): a more strict check (skip if !DISPATCH_HANDLER)
is implemented.
3. AcpiUpdateAllGpes(): a more strict check (skip if DISPATCH_NONE ||
DISPATCH_HANDLER || CAN_WAKE)
4. AcpiSetGpe(): since it is invoked by the OSPM driver where the IRQ
handler is known to be available, such check isn't needed.
So we can simply remove this duplicated check from AcpiEvEnableGpe().
Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The ACPI specification around the GPE handling is talking about an IRQ handling code of IRQ polling mode (which is also known as the threaded IRQ model in Linux) that is suitable for the control method execution. GPE is disabled in the IRQ context and re-enabled in the IRQ polling context (the task context of the polling thread) after the interrupt has been correctly handled. For IRQ handling code of IRQ interrupt mode (DISPATCH_HANDLER can only be implemented in this mode), disabling IRQ is useless as further IRQs with same IRQ no. are ensured to be blocked IRQ for the same CPU. There is no hardware in the real world can trigger an IRQ on the same CPU to preempt the handler of the same IRQ. There might be same IRQ handlers triggered on different CPUs but disabling it in the IRQ handler cannot prevent this from happening. And the automatic IRQ disabling is harmful to request based low power IO drivers where IRQ enabling/disabling is managed by the power references and the storm conditions. The IRQ disabling/enabling out of the drivers' control can mess up the IRQ enabling state where: 1. Enabling IRQ means there is more than 1 requests and no storms; 2. Disabling IRQ means there is no request or there is a storm. This patch adds a flag to control the ACPICA internal GPE disabling to facilitate request based low power IO drivers to work in the GPE level. Since we will have users for the new GPE flag to enable a runtime idle style GPE driver, this patch also enables AcpiInstallGpeHandler() to configure NO_AUTO_x flags. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com>
The GPE status clearing code should be invoked in the GPE handling code. There are cases that the GPE is handled in the polling mode and the IRQ mode handler is a no-op. For which, ACPICA internal clearing should be bypassed. Some silicon chips can implement special GPE status as R1C (read once clear). For those case, the internal auto GPE clearing operations should also be abandoned. In AcpiEvEnableGpe(), the clearing code can prevent this API from being request based IRQ enabling API, so also allows drivers who register GPE handlers to discard it. This flag facilitates such driver designs and implementations. Note that drivers will need to invoke AcpiClearGpe() manually in a proper position. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com>
… GPE handling model.
For AcpiSetGpe()/AcpiEnableGpe(), our target is to purify them to be APIs
can be used for request based driver handling code, so we need them to be
pure GPE enabling APIs. IRQ enabling/disabling has 2 use cases:
1. Driver may permanently enable/disable IRQs according to the usage
counts.
1. When upper layers (the users of the driver) submit requests to the
driver, it means they care about the underlying hardware. IRQ need
to be enabled for the first request submission and disabled for the
last request completion.
2. When the IRQ is shared between 2+ silicon logics. IRQ need to be
enabled for either silicon logic's driver and disabled when all of
the drivers are not started.
For these cases, AcpiEnableGpe()/AcpiDisableGpe() should be used. When
the usage count is increased from 0 to 1, the IRQ is enabled and it is
disabled when the usage count is decrased from 1 to 0.
2. Driver may temporarily disables the IRQ to enter an IRQ polling mode and
wants to re-enable it later.
1. Prevent IRQ storming: when a driver cannot fully solve the condition
that triggered the IRQ in the IRQ context, in order not to trigger
IRQ storm, driver has to disable IRQ to switch into the polling mode
and re-enables it in the non-IRQ context after the storming condition
is cleared.
2. Meet throughput requirement: some IO drivers need to poll hardware
again and again until nothing indicated instead of just handling once
for one interruption, this need to be done in the polling mode or the
IO flood may prevent the IRQ handler from returning.
3. Meet realtime requirement: in order not to block CPU to handle higher
realtime prioritized IRQs, lower priority IRQs can be handled in the
polling mode.
For these cases, AcpiSetGpe() should be used to switch to/from the
polling mode.
This patch adds unconditional GPE enabling support into AcpiSetGpe() so
that this API can be used by the drivers to switch back from the GPE
polling mode unconditionally.
Originally this function includes GPE clearing logic in it.
First, the GPE clearing is typically used in the GPE handling code to:
1. Acknowledge the GPE when we know there is an edge triggered GPE raised
and is about to handle it, otherwise the unexpected clearing may lead to
a GPE loss;
2. Issue actions after we have handled a level triggered GPE, otherwise
the unexpected clearing may trigger unwanted OSPM actions to the
hardware (for example, clocking in out-dated write FIFO data).
Thus the GPE clearing is not suitable to be used in the GPE enabling APIs.
Second, the combination of acknowledging and enabling may also not be
expected by the hardware drivers. For GPE clearing, we have a seperate API
AcpiClearGpe(). There are cases drivers do want the 2 operations to be
split. So splitting these 2 operations could facilitates drivers the
maximum possibilities to achieve success. For a combined one, we already
have AcpiFinishGpe() ready to be invoked.
Given the fact that drivers should complete all outstanding requests before
putting themselves into the sleep states, as this API is executed for
outstanding requests, it should also have nothing to do with the
"RUN"/"WAKE" distinguishing. That's why the AcpiSetGpe(ACPI_GPE_ENABLE)
should not be implemented by AcpiHwLowSetGpe(ACPI_GPE_CONDITIONAL_ENABLE).
This patch thus converts AcpiSetGpe(ACPI_GPE_ENABLE) into
AcpiHwLowSetGpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API.
Drivers then are encouraged to use this API when they need to switch
to/from the IRQ polling mode. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
…rgences. This patch is back ported from Linux kernel with modification to follow ACPICA internal coding style and structure. Linux currently is using AcpiGetEventStatus()/AcpiGetGpeStatus() to provide fixed event/GPE information to the userspace via sysfs, and Linux might be the only user for these 2 APIs. In Linux, AcpiGetEventStatus() returns ACPI_EVENT_FLAG_HANDLE (handler installed) and ACPI_EVENT_FLAG_SET (status register set) for the fixed event and AcpiGetGpeStatus() returns an additional ACPI_EVENT_FLAG_HANDLE (dispatcher set). This patch back ports these behaviors. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com>
GPEs with corresponding _Lxx/_Exx control methods need to be disabled during initialization in case they have been enabled by the BIOS, so that they don't fire up until they are enabled by AcpiUpdateAllGpes(). Rafael J. Wysocki. References: https://bugzilla.kernel.org/show_bug.cgi?id=25412 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Len Brown <len.brown@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
…nnot enable/disable GPE unconditionally. There is a facility in Linux, developers can force GPE enabling/disabling through /sys/firmware/acpi/interrupts/gpexx. This is mainly for debugging purposes because such GPE enabling/disabling operations are out of the drivers' control and hence are dangerous for the following conditions: 1. If the drivers are not IRQ polling capable and the disaling is forced, 2. If the drivers are not interrupted IRQ capable and the enabling is forced. Currently this facility invokes reference counting based GPE enabling APIs - AcpiEnableGpe()/AcpiDisableGpe(), which has confused users for so long time as: 1. Such APIs could not disable the GPE unless the GPE is not shared, not wakeup capable and not enabled by the driver more than once. This facility also breaks system wakeup code and drivers by messing up the reference count. This patch introduces AcpiForceGpe() to be used in such situation instead of AcpiEnableGpe()/AcpiDisableGpe(). It is said that the stale events clearing is required by this facility to avoid wrong _Lxx/_Exx method invocations caused by the events appeared during the forced-disabling period, and the clearing is working because most of such GPEs are used for system wakeup purposes and can be simply acknowledged by clearing the GPE status without taking any additional responses. Thus this patch keeps this logic in the new API. This patch also modifies AcpiGetGpeStatus() to return more information from ACPICA core to reflect this forced status. The old ACPI_EVENT_FLAG_SET is carefully kept to avoid regressions. It can be deleted after we can make sure all its references are removed from OSPM code. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com>
gemarcano
pushed a commit
to gemarcano/acpica
that referenced
this pull request
Sep 27, 2023
Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x0000220c98288eba in AcpiRsGetAddressCommon(ACPI_RESOURCE*, AML_RESOURCE*) ../../third_party/acpica/source/components/resources/rsaddr.c:331 <platform-bus-x86.so>+0x8f6eba acpica#1.2 0x000023625f46077f in ubsan_GetStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f acpica#1.1 0x000023625f46077f in MaybePrintStackTrace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f acpica#1 0x000023625f46077f in ~ScopedReport() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f acpica#2 0x000023625f461385 in handleTypeMismatchImpl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:137 <libclang_rt.asan.so>+0x3e385 acpica#3 0x000023625f460ead in compiler-rt/lib/ubsan/ubsan_handlers.cpp:142 <libclang_rt.asan.so>+0x3dead acpica#4 0x0000220c98288eba in AcpiRsGetAddressCommon(ACPI_RESOURCE*, AML_RESOURCE*) ../../third_party/acpica/source/components/resources/rsaddr.c:331 <platform-bus-x86.so>+0x8f6eba acpica#5 0x0000220c9828ea57 in AcpiRsConvertAmlToResource(ACPI_RESOURCE*, AML_RESOURCE*, ACPI_RSCONVERT_INFO*) ../../third_party/acpica/source/components/resources/rsmisc.c:352 <platform-bus-x86.so>+0x8fca57 acpica#6 0x0000220c9828992c in AcpiRsConvertAmlToResources(UINT8*, UINT32, UINT32, UINT8, void**) ../../third_party/acpica/source/components/resources/rslist.c:132 <platform-bus-x86.so>+0x8f792c acpica#7 0x0000220c982d1cfc in AcpiUtWalkAmlResources(ACPI_WALK_STATE*, UINT8*, ACPI_SIZE, ACPI_WALK_AML_CALLBACK, void**) ../../third_party/acpica/source/components/utilities/utresrc.c:234 <platform-bus-x86.so>+0x93fcfc acpica#8 0x0000220c98281e46 in AcpiRsCreateResourceList(ACPI_OPERAND_OBJECT*, ACPI_BUFFER*) ../../third_party/acpica/source/components/resources/rscreate.c:199 <platform-bus-x86.so>+0x8efe46 acpica#9 0x0000220c98293b51 in AcpiRsGetMethodData(ACPI_HANDLE, const char*, ACPI_BUFFER*) ../../third_party/acpica/source/components/resources/rsutils.c:770 <platform-bus-x86.so>+0x901b51 acpica#10 0x0000220c9829438d in AcpiWalkResources(ACPI_HANDLE, char*, ACPI_WALK_RESOURCE_CALLBACK, void*) ../../third_party/acpica/source/components/resources/rsxface.c:731 <platform-bus-x86.so>+0x90238d acpica#11 0x0000220c97db272b in acpi::AcpiImpl::WalkResources(acpi::AcpiImpl*, ACPI_HANDLE, const char*, acpi::Acpi::ResourcesCallable) ../../src/devices/board/lib/acpi/acpi-impl.cc:41 <platform-bus-x86.so>+0x42072b acpica#12 0x0000220c97dcec59 in acpi::DeviceBuilder::GatherResources(acpi::DeviceBuilder*, acpi::Acpi*, fidl::AnyArena&, acpi::Manager*, acpi::DeviceBuilder::GatherResourcesCallback) ../../src/devices/board/lib/acpi/device-builder.cc:52 <platform-bus-x86.so>+0x43cc59 acpica#13 0x0000220c97f94a3f in acpi::Manager::ConfigureDiscoveredDevices(acpi::Manager*) ../../src/devices/board/lib/acpi/manager.cc:75 <platform-bus-x86.so>+0x602a3f acpica#14 0x0000220c97c642c7 in publish_acpi_devices(acpi::Manager*, zx_device_t*, zx_device_t*) ../../src/devices/board/drivers/x86/acpi-nswalk.cc:102 <platform-bus-x86.so>+0x2d22c7 acpica#15 0x0000220c97caf3e6 in x86::X86::DoInit(x86::X86*) ../../src/devices/board/drivers/x86/x86.cc:65 <platform-bus-x86.so>+0x31d3e6 acpica#16 0x0000220c97cd72ae in λ(x86::X86::DdkInit::(anon class)*) ../../src/devices/board/drivers/x86/x86.cc:82 <platform-bus-x86.so>+0x3452ae acpica#17 0x0000220c97cd7223 in fit::internal::target<(lambda at../../src/devices/board/drivers/x86/x86.cc:81:19), false, false, void>::invoke(void*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:181 <platform-bus-x86.so>+0x345223 acpica#18 0x0000220c97f48eb0 in fit::internal::function_base<16UL, false, void()>::invoke(const fit::internal::function_base<16UL, false, void ()>*) ../../sdk/lib/fit/include/lib/fit/internal/function.h:505 <platform-bus-x86.so>+0x5b6eb0 acpica#19 0x0000220c97f48d2a in fit::function_impl<16UL, false, void()>::operator()(const fit::function_impl<16UL, false, void ()>*) ../../sdk/lib/fit/include/lib/fit/function.h:300 <platform-bus-x86.so>+0x5b6d2a acpica#20 0x0000220c982f9245 in async::internal::RetainedTask::Handler(async_dispatcher_t*, async_task_t*, zx_status_t) ../../zircon/system/ulib/async/task.cc:25 <platform-bus-x86.so>+0x967245 acpica#21 0x000022e2aa1cd91e in λ(const driver_runtime::Dispatcher::PostTask::(anon class)*, std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >, zx_status_t) ../../src/devices/bin/driver_runtime/dispatcher.cc:715 <libdriver_runtime.so>+0xed91e acpica#22 0x000022e2aa1cd621 in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:714:7), true, false, void, std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest>>, int>::invoke(void*, std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 <libdriver_runtime.so>+0xed621 acpica#23 0x000022e2aa1a8482 in fit::internal::function_base<24UL, true, void(std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest>>, int)>::invoke(const fit::internal::function_base<24UL, true, void (std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >, int)>*, std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >, int) ../../sdk/lib/fit/include/lib/fit/internal/function.h:505 <libdriver_runtime.so>+0xc8482 acpica#24 0x000022e2aa1a80f8 in fit::callback_impl<24UL, true, void(std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest>>, int)>::operator()(fit::callback_impl<24UL, true, void (std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >, int)>*, std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >, int) ../../sdk/lib/fit/include/lib/fit/function.h:451 <libdriver_runtime.so>+0xc80f8 acpica#25 0x000022e2aa17fc76 in driver_runtime::CallbackRequest::Call(driver_runtime::CallbackRequest*, std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >, zx_status_t) ../../src/devices/bin/driver_runtime/callback_request.h:67 <libdriver_runtime.so>+0x9fc76 acpica#26 0x000022e2aa18c7ef in driver_runtime::Dispatcher::DispatchCallback(driver_runtime::Dispatcher*, std::__2::unique_ptr<driver_runtime::CallbackRequest, std::__2::default_delete<driver_runtime::CallbackRequest> >) ../../src/devices/bin/driver_runtime/dispatcher.cc:1093 <libdriver_runtime.so>+0xac7ef acpica#27 0x000022e2aa18fd67 in driver_runtime::Dispatcher::DispatchCallbacks(driver_runtime::Dispatcher*, std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.cc:1169 <libdriver_runtime.so>+0xafd67 acpica#28 0x000022e2aa1bc9a2 in λ(const driver_runtime::Dispatcher::CreateWithAdder::(anon class)*, std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.cc:338 <libdriver_runtime.so>+0xdc9a2 acpica#29 0x000022e2aa1bc6d2 in fit::internal::target<(lambda at../../src/devices/bin/driver_runtime/dispatcher.cc:337:7), true, false, void, std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter>>, fbl::RefPtr<driver_runtime::Dispatcher>>::invoke(void*, std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/internal/function.h:128 <libdriver_runtime.so>+0xdc6d2 acpica#30 0x000022e2aa1aa1e5 in fit::internal::function_base<8UL, true, void(std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter>>, fbl::RefPtr<driver_runtime::Dispatcher>)>::invoke(const fit::internal::function_base<8UL, true, void (std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>)>*, std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/internal/function.h:505 <libdriver_runtime.so>+0xca1e5 acpica#31 0x000022e2aa1a9e32 in fit::function_impl<8UL, true, void(std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter>>, fbl::RefPtr<driver_runtime::Dispatcher>)>::operator()(const fit::function_impl<8UL, true, void (std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>)>*, std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>) ../../sdk/lib/fit/include/lib/fit/function.h:300 <libdriver_runtime.so>+0xc9e32 acpica#32 0x000022e2aa193444 in driver_runtime::Dispatcher::EventWaiter::InvokeCallback(driver_runtime::Dispatcher::EventWaiter*, std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, fbl::RefPtr<driver_runtime::Dispatcher>) ../../src/devices/bin/driver_runtime/dispatcher.h:299 <libdriver_runtime.so>+0xb3444 acpica#33 0x000022e2aa192feb in driver_runtime::Dispatcher::EventWaiter::HandleEvent(std::__2::unique_ptr<driver_runtime::Dispatcher::EventWaiter, std::__2::default_delete<driver_runtime::Dispatcher::EventWaiter> >, async_dispatcher_t*, async::WaitBase*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/dispatcher.cc:1259 <libdriver_runtime.so>+0xb2feb acpica#34 0x000022e2aa1bcf74 in AsyncLoopOwnedEventHandler<driver_runtime::Dispatcher::EventWaiter>::HandleEvent(AsyncLoopOwnedEventHandler<driver_runtime::Dispatcher::EventWaiter>*, async_dispatcher_t*, async::WaitBase*, zx_status_t, zx_packet_signal_t const*) ../../src/devices/bin/driver_runtime/async_loop_owned_event_handler.h:59 <libdriver_runtime.so>+0xdcf74 acpica#35 0x000022e2aa1bd1cb in async::WaitMethod<AsyncLoopOwnedEventHandler<driver_runtime::Dispatcher::EventWaiter>, &AsyncLoopOwnedEventHandler<driver_runtime::Dispatcher::EventWaiter>::HandleEvent>::CallHandler(async_dispatcher_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../zircon/system/ulib/async/include/lib/async/cpp/wait.h:201 <libdriver_runtime.so>+0xdd1cb acpica#36 0x000022e2aa2303a9 in async_loop_dispatch_wait(async_loop_t*, async_wait_t*, zx_status_t, zx_packet_signal_t const*) ../../zircon/system/ulib/async-loop/loop.c:381 <libdriver_runtime.so>+0x1503a9 acpica#37 0x000022e2aa229a82 in async_loop_run_once(async_loop_t*, zx_time_t) ../../zircon/system/ulib/async-loop/loop.c:330 <libdriver_runtime.so>+0x149a82 acpica#38 0x000022e2aa229102 in async_loop_run(async_loop_t*, zx_time_t, _Bool) ../../zircon/system/ulib/async-loop/loop.c:288 <libdriver_runtime.so>+0x149102 acpica#39 0x000022e2aa22aeb7 in async_loop_run_thread(void*) ../../zircon/system/ulib/async-loop/loop.c:840 <libdriver_runtime.so>+0x14aeb7 acpica#40 0x000041a874980f1c in start_c11(void*) ../../zircon/third_party/ulib/musl/pthread/pthread_create.c:55 <libc.so>+0xd7f1c acpica#41 0x000041a874aabe8d in thread_trampoline(uintptr_t, uintptr_t) ../../zircon/system/ulib/runtime/thread.cc:100 <libc.so>+0x202e8d
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some GPE divergence reduction and fixes.
This is a divergence fix.
This is a fix that is generated according to the ACPI spec. Tests showed valid.
The AcpiSetGpe() API has actually no user now. The improvement could facilitate driver writers to use this API to implement GPE handling flexibilities.
Another commit to facilitates driver writers to implement GPE handling flexibilities.