From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Zhao Yakui <yakui.zhao@intel.com>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>,
linux-acpi@vger.kernel.org, lenb@kernel.org
Subject: Re: a problem about the two patches in bug 10724 & 11428
Date: Mon, 1 Sep 2008 23:03:02 -0300 [thread overview]
Message-ID: <20080902020302.GA12080@khazad-dum.debian.net> (raw)
In-Reply-To: <1220317387.4039.83.camel@yakui_zhao.sh.intel.com>
On Tue, 02 Sep 2008, Zhao Yakui wrote:
> On Tue, 2008-09-02 at 00:59 +0400, Alexey Starikovskiy wrote:
> > Alexey Starikovskiy wrote:
> In this patch when timeout happens, EC will try the GPE interrupt mode
> after 5 seconds.Of course EC will be in polling mode before switching to
> GPE interrupt mode. It seems reasonable.
Yeah, the patch looks good.
But we probably want to limit the number of times it will try to re-enable
interrupt mode, otherwise it will keep firing on ECs that are permanently
broken re. GPE interrupt mode. I think trying 5 times should be enough,
that gives a 25s window for the EC to get its act together.
And we should probably reset the "attempted tries to switch to GPE interrupt
mode" counter (so that the code will retry interrupt mode again) after
events that are likely to have done a lot of internal churning to the EC.
Currently, those would be when resuming from S3 or S4, I think.
> In fact there also exists the mode switch from polling mode to interrupt
> mode after EC is initialized. Is it more appropriate that ec->gpe_retry
> is initialized?
We could use the same code to do the initial switch, indeed.
The two other things that we probably want to make sure we are doing are:
1. Drain the entire EC queue at every poll cycle (this is a must, really).
2. Try to drain the entire EC queue also in interrupt mode, but be careful
about dumb ECs that will sign 10 interrupts if there are 10 bytes to read in
the queue, even when we have drained the queue when servicing the very first
interrupt. I bet there are ECs which will give you just one interrupt and
expect the queue to be drained, ECs which will give you interrupts until you
drain the queue (but no more than necessary), and ECs which will give you
interrupts for as many bytes as it stored in the queue, regardless of when
they were read... and we mustn't think there is an interrupt storm happening
because of this.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
next prev parent reply other threads:[~2008-09-02 2:03 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-01 6:40 a problem about the two patches in bug 10724 & 11428 Zhao Yakui
2008-09-01 7:49 ` Alexey Starikovskiy
2008-09-01 9:55 ` Zhao Yakui
2008-09-01 12:18 ` Alexey Starikovskiy
2008-09-02 1:59 ` Zhao Yakui
2008-09-02 8:36 ` Alexey Starikovskiy
2008-09-02 9:31 ` Zhao Yakui
2008-09-02 9:26 ` Alan Jenkins
2008-09-02 9:30 ` Alexey Starikovskiy
2008-09-02 10:00 ` Zhao Yakui
2008-09-01 12:21 ` Henrique de Moraes Holschuh
2008-09-01 12:52 ` Alexey Starikovskiy
2008-09-01 20:35 ` Alexey Starikovskiy
2008-09-01 20:59 ` Alexey Starikovskiy
2008-09-02 1:03 ` Zhao Yakui
2008-09-02 2:03 ` Henrique de Moraes Holschuh [this message]
2008-09-02 3:39 ` Zhao Yakui
2008-09-02 9:19 ` Alan Jenkins
2008-09-02 8:05 ` Zhao Yakui
2008-09-03 6:02 ` Zhao Yakui
2008-09-03 6:46 ` Alexey Starikovskiy
2008-09-03 7:28 ` Zhao Yakui
2008-09-03 8:03 ` Zhao Yakui
2008-09-03 7:53 ` Alexey Starikovskiy
2008-09-03 8:34 ` Zhao Yakui
2008-09-03 21:55 ` RFC: fast transactions in EC [was: a problem about the two patches in bug 10724 & 11428] Alexey Starikovskiy
2008-09-04 2:58 ` Zhao Yakui
2008-09-04 3:06 ` Alexey Starikovskiy
2008-09-04 3:56 ` Alexey Starikovskiy
2008-09-04 4:51 ` Alexey Starikovskiy
2008-09-05 20:07 ` Andrew Morton
2008-09-08 8:19 ` Alexey Starikovskiy
2008-09-08 8:28 ` Andrew Morton
2008-09-08 8:30 ` Alexey Starikovskiy
2008-09-08 8:41 ` Andrew Morton
2008-09-03 22:28 ` a problem about the two patches in bug 10724 & 11428 Alexey Starikovskiy
2008-09-04 3:43 ` Zhao Yakui
2008-09-04 3:47 ` Alexey Starikovskiy
2008-09-04 6:00 ` Zhao Yakui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080902020302.GA12080@khazad-dum.debian.net \
--to=hmh@hmh.eng.br \
--cc=astarikovskiy@suse.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=yakui.zhao@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox