Zhao Yakui wrote:
Maybe I don't understand what you said fully. The following is my
understanding about the patches of bug 11428 and bug 10724.
a. In the patch of bug 11428 the EC GPE won't be disabled when timeout
happens, which means that it is still possible to switch EC working mode
again from polling mode to interrupt mode. i.e. EC can still be switched
to interrupt mode again. In the current upstream kernel when timeout
happens, EC will be switched to polling mode and can't be switched to
interrupt mode again(EC GPE is disabled). Right?
Wrong. EC GPE will stay enabled, driver will just not use it during wait for completion.
In fact when EC timeout happens in interrupt mode, it indicates that
EC controller can't return response in time.
Wrong. Some EC controllers are "optimized" to not send interrupts for each confirmation.
See history of EC patches for these optimization workarounds.
In the above source code maybe there exists the following phenomenon:
When the EC GPE interrupt is triggered, the waiting process will be
waked up in the GPE interrupt service routine. But as the process
can't be scheduled immediately, maybe the wait_event_timeout will
also return 0, which means that timeout happens and EC will be
switched from interrupt mode to polling mode.
We are speaking about 500msec timeout here. it needs at least 50+ ready to run tasks of same
kernel priority to not let queue thread run. Please tell me, how could this happen?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
