We have 2 polling modes in the EC driver:
1. busy polling: originally used for the MSI quirks. udelay() is used to
perform register access guarding.
2. wait polling: normal code path uses wait_event_timeout() and it can be
woken up as soon as the transaction is completed in the interrupt mode.
It also contains the register acces guarding logic in case the interrupt
doesn't arrive and the EC driver is about to advance the transaction in
task context (the polling mode).
The wait polling is useful for interrupt mode to allow other tasks to use
the CPU during the wait.
But for the polling mode, the busy polling takes less time than the wait
polling, because if no interrupt arrives, the wait polling has to wait the
minimal HZ interval.
We have a new use case for using the busy polling mode. Some GPIO drivers
initialize PIN configuration which cause a GPIO multiplexed EC GPE to be
disabled out of the GPE register's control. Busy polling mode is useful
here as it takes less time than the wait polling. But the guarding logic
prevents it from responding even faster. We should spinning around the EC
status rather than spinning around the nop execution lasted a determined
period.
This patch introduces 2 module params for the polling mode switch and the
guard time, so that users can use the busy polling mode without the
guarding in case the guarding is not necessary. This is an example to use
the 2 module params for this purpose:
acpi.ec_busy_polling acpi.ec_polling_guard=0
We've tested the patch on a test platform. The platform suffers from such
kind of the GPIO PIN issue. The GPIO driver resets all PIN configuration
and after that, EC interrupt cannot arrive because of the multiplexing.
Then the platform suffers from a long delay carried out by the
wait_event_timeout() as all further EC transactions will run in the polling
mode. We switched the EC driver to use the busy polling mechanism instead
of the wait timeout polling mechanism and the delay is still high:
[ 44.283005] calling PNP0C0B:00+ @ 1305, parent: platform
[ 44.417548] call PNP0C0B:00+ returned 0 after 131323 usecs
And this patch can significantly reduce the delay:
[ 44.502625] calling PNP0C0B:00+ @ 1308, parent: platform
[ 44.503760] call PNP0C0B:00+ returned 0 after 1103 usecs
Tested-by: Chen Yu <yu.c.chen@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
15de603b04