On Tue, 2008-09-09 at 13:36 +0400, Alexey Starikovskiy wrote:

Zhao Yakui wrote:

quoted

On Tue, 2008-09-09 at 13:12 +0400, Alexey Starikovskiy wrote:

quoted

Zhao Yakui wrote:

quoted

Hi, Alexey
    You attached the updated patch on the bug 10724/9998.
    Can the following situation be handled by your patch?(For example:
bug 10724)
       EC GPE Interrupt storm is detected and EC GPE will be disabled
when doing EC transaction.
       If EC notification event happens while doing EC transaction(EC
GPE is disabled), the SCI_EVT bit of EC status register is cleared
automatically before we can handle it.

SCI_EVT is cleared only as a response to query command sent to EC, there is no 
timeout on it.

If the SCI_EVT is cleared only after issuing query the command, in
theory the poll timer should also handle it. But on the laptop of bug
10724 it seems that the poll timer can't handle such notification event.
And on the laptops of bug 11428 and 8459 the poll timer can't handle the
notification event when the system is switched from GPE mode to polling
mode.

What we cared only is whether the EC notification event can be detected
by OS when the following case happens? (For example: On the laptop of
bug 10724)
    EC GPE Interrupt storm is detected and EC GPE will be disabled when
doing EC transaction.
    If EC notification event happens while doing EC transaction(EC GPE
is disabled), the SCI_EVT bit of EC status register is cleared before we
can handle it.
    

The problem here is with auto-repeat of function keys, thus the need to _distinguish_
one event from another (SCI bit will be set, just the event will be either different 
or next of the same kind). Poll timer does it's job every 500ms, thus auto-repeated keys are
lost. With the fastest auto-repeat being 30/s or 33ms we have plenty of time.

quoted

quoted

Transaction will take at most 2 ms (1 write/1 read or 2 writes in poll mode), 
and at the end of the transaction there is a check of the SCI bit.
With the un-patched EC SCI bit needs to stay for period while the QUERY_PENDING bit is set,
which could be quite more than 2 ms, and it seems to comply with that even on most broken
hardware.

quoted

       Can the EC notification event be handled by OS?

Maybe it will take very short time to do the EC transaction. Myabe in
most cases it is about 2ms. But in some worse situation it will take a
long time(For example: 100ms). If the EC notification happens in such
case, how to handle the event? (the SCI_EVT bit will be cleared before
we can detect it).

Where do you get this 100ms number? 

As I state in the previous email, the msleep is realized by the function
of schedule_timeout. The input parameter of msleep will be translated to
jiffies unit. In such case the time of EC transaction will be related
with the definition of HZ.(If the HZ is 100, msleep(1) will cost
10ms).At the same time when one process is waked up, maybe it won't be
scheduled immediately. If so, the time of EC transaction will be
longer.Maybe in some worse case the time will exceed 500ms.
    The detailed info log can be found in 
     http://bugzilla.kernel.org/show_bug.cgi?id=11141