kernel/linux.git/drivers/acpi/ec.c, branch v4.11.5

ACPI / EC: Use busy polling mode when GPE is not enabled

2017-01-30T11:12:52+00:00

When GPE is not enabled, it is not efficient to use the wait polling mode as it introduces an unexpected scheduler delay. So before the GPE handler is installed, this patch uses busy polling mode for all EC(s) and the logic can be applied to non boot EC(s) during the suspend/resume process. Link: https://bugzilla.kernel.org/show_bug.cgi?id=191561 Tested-by: Jakobus Schurz Tested-by: Chen Yu Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Remove old CLEAR_ON_RESUME quirk

2017-01-30T11:12:03+00:00

IRQ polling logic has been implemented to drain the post-boot/resume EC events: 1. Triggered by the following code, invoked from acpi_ec_enable_event(): if (!test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) advance_transaction(ec); 2. Drained by the following code, invoked after acpi_ec_complete_query(): if (status & ACPI_EC_FLAG_SCI) acpi_ec_submit_query(ec); This facility is safer than the old CLEAR_ON_RESUME quirk as the CLEAR_ON_RESUME quirk sends EC query commands unconditionally. The behavior is apparently not suitable for firmware that requires QUERY_HANDSHAKE quirk. Though the QUERY_HANDSHAKE quirk isn't used now because of the improvement done in the EC transaction state machine (ec_event_clearing=QUERY), it is the proof that we cannot send EC query command unconditionally. So it's time to delete the out-dated CLEAR_ON_RESUME quirk to let the users to try the newer approach. Link: https://bugzilla.kernel.org/show_bug.cgi?id=191211 Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix unused function warning when CONFIG_PM_SLEEP=n

2016-10-10T00:22:20+00:00

Signed-off-by: Eric Biggers Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix issues related to boot_ec

2016-09-10T00:33:50+00:00

There are issues related to the boot_ec: 1. If acpi_ec_remove() is invoked, boot_ec will also be freed, this is not expected as the boot_ec could be enumerated via ECDT. 2. Address space handler installation/unstallation lead to unexpected _REG evaluations. This patch adds acpi_is_boot_ec() check to be used to fix the above issues. However, since acpi_ec_remove() actually won't be invoked, this patch doesn't handle the reference counting of "struct acpi_ec", it only ensures the correctness of the boot_ec destruction during the boot. Link: https://bugzilla.kernel.org/show_bug.cgi?id=153511 Reported-and-tested-by: Jonh Henderson Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix a gap that ECDT EC cannot handle EC events

2016-09-10T00:33:50+00:00

It is possible to register _Qxx from namespace and use the ECDT EC to perform event handling. The reported bug reveals that Windows is using ECDT in this way in case the namespace EC is not present. This patch facilitates Linux to support ECDT in this way. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga Tested-by: Jonh Henderson Reviewed-by: Peter Wu Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Fix a memory leakage issue in acpi_ec_add()

2016-09-10T00:33:49+00:00

When the handler installation failed, there was no code to free the allocated EC device. This patch fixes this memory leakage issue. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga Tested-by: Jonh Henderson Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Cleanup first_ec/boot_ec code

2016-09-10T00:33:49+00:00

In order to support full ECDT (driving the ECDT EC after probing the namespace EC), we need to change our EC device alloc/free algorithm, ensure not to free old boot EC before qualifying new boot EC. This patch achieves this by cleaning up first_ec/boot_ec logic: 1. first_ec: used to perform transactions, so it is assigned in new acpi_ec_setup() function. 2. boot_ec: used to track early EC device, so it is assigned in new acpi_config_boot_ec() function which explictly tells the driver to save the EC device as early EC device. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115021 Reported-and-tested-by: Luya Tshimbalanga Tested-by: Jonh Henderson Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPI / EC: Enable event freeze mode to improve event handling for suspend process

2016-08-30T22:32:11+00:00

This patch enables the event freeze mode, flushing the EC event handling in .suspend() callback. This feature is experimental, if it is bisected out to be the cause of the real issues, please report the issues to the kernel bugzilla for further root causing and improvement. This mode eliminates useless _Qxx handling during the power saving operations, thus can help to tune the power saving operations faster. Tests show that this mode can efficiently block flooding _Qxx during the suspend process and tune the speed of the suspend faster. Signed-off-by: Lv Zheng Tested-by: Todd E Brandt Signed-off-by: Rafael J. Wysocki

ACPI / EC: Add PM operations to improve event handling for suspend process

2016-08-30T22:32:11+00:00

In the original EC driver, though the event handling is not explicitly stopped, the EC driver is actually not able to handle events during the noirq stage as the EC driver is not prepared to handle the EC events in the polling mode. So if there is no advance_transaction() triggered, the EC driver couldn't notice the EC events. However, do we actually need to handle EC events during suspend/resume stage? EC events are mostly useless for the suspend/resume period (key strokes and battery/thermal updates, etc.,), and the useful ones (lid close, power/sleep button press) should have already been delivered to the OSPM to trigger the power saving operations. Thus this patch implements acpi_ec_disable_event() to be a reverse call of acpi_ec_enable_event(), with which, the EC driver is able to stop handling the EC events in a position before entering the noirq stage. Since there are actually 2 choices for us: 1. implement event handling in polling mode; 2. stop event handling before entering noirq stage. And this patch only implements the second choice using .suspend() callback. Thus this is experimental (first choice is better? or different hook position is better?). This patch finally keeps the old behavior by default and prepares a boot parameter to enable this feature. The differences of the event handling availability between the old behavior (this patch is not applied) and the new behavior (this patch is applied) are as follows: !FreezeEvents FreezeEvents before suspend Y Y suspend before EC Y Y suspend after EC Y N suspend_late Y N suspend_noirq Y (actually N) N resume_noirq Y (actually N) N resume_late Y (actually N) N resume before EC Y (actually N) N resume after EC Y Y after resume Y Y Where "actually N" means if there is no EC transactions, the EC driver is actually not able to notice the pending events. We can see that FreezeEvents is the only approach now can actually flush the EC event handling with both query commands and _Qxx evaluations flushed, other modes can only flush the EC event handling with only query commands flushed, _Qxx evaluations occurred after stopping the EC driver may end up failure due to the failure of the EC transaction carried out in the _Qxx control methods. We also can see that this feature should be able to trigger some platform notifications later than resuming other drivers. Signed-off-by: Lv Zheng Tested-by: Todd E Brandt Signed-off-by: Rafael J. Wysocki

ACPI / EC: Add PM operations to improve event handling for resume process

2016-08-30T22:32:10+00:00

This patch makes 2 changes: 1. Restore old behavior Originally, EC driver stops handling both events and transactions in acpi_ec_block_transactions(), and restarts to handle transactions in acpi_ec_unblock_transactions_early(), restarts to handle both events and transactions in acpi_ec_unblock_transactions(). While currently, EC driver still stops handling both events and transactions in acpi_ec_block_transactions(), but restarts to handle both events and transactions in acpi_ec_unblock_transactions_early(). This patch tries to restore the old behavior by dropping __acpi_ec_enable_event() from acpi_unblock_transactions_early(). 2. Improve old behavior However this still cannot fix the real issue as both of the acpi_ec_unblock_xxx() functions are invoked in the noirq stage. Since the EC driver actually doesn't implement the event handling in the polling mode, re-enabling the event handling too early in the noirq stage could result in the problem that if there is no triggering source causing advance_transaction() to be invoked, pending SCI_EVT cannot be detected by the EC driver and _Qxx cannot be triggered. It actually makes sense to restart the event handling in any point during resuming after the noirq stage. Just like the boot stage where the event handling is enabled in .add(), this patch further moves acpi_ec_enable_event() to .resume(). After doing that, the following 2 functions can be combined: acpi_ec_unblock_transactions_early()/acpi_ec_unblock_transactions(). The differences of the event handling availability between the old behavior (this patch isn't applied) and the new behavior (this patch is applied) are as follows: !Applied Applied before suspend Y Y suspend before EC Y Y suspend after EC Y Y suspend_late Y Y suspend_noirq Y (actually N) Y (actually N) resume_noirq Y (actually N) Y (actually N) resume_late Y (actually N) Y (actually N) resume before EC Y (actually N) Y (actually N) resume after EC Y (actually N) Y after resume Y (actually N) Y Where "actually N" means if there is no triggering source, the EC driver is actually not able to notice the pending SCI_EVT occurred in the noirq stage. So we can clearly see that this patch has improved the situation. Signed-off-by: Lv Zheng Tested-by: Todd E Brandt Signed-off-by: Rafael J. Wysocki