On Tue, 2008-09-09 at 13:36 +0400, Alexey Starikovskiy wrote:
> Zhao Yakui wrote:
> > On Tue, 2008-09-09 at 13:12 +0400, Alexey Starikovskiy wrote:
> >> Zhao Yakui wrote:
> >>> 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.
> >> 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.
> >>> 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
--
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
