From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Seth Heasley
<seth.heasley-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>,
Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 3/8 v3] i2c: i801: check INTR after every transaction
Date: Sun, 1 Jul 2012 23:20:51 +0200 [thread overview]
Message-ID: <20120701232051.308c03d1@endymion.delvare> (raw)
In-Reply-To: <20120627180724.762f854a-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
Hi again Daniel,
On Wed, 27 Jun 2012 18:07:24 +0200, Jean Delvare wrote:
> On Wed, 27 Jun 2012 21:54:10 +0800, Daniel Kurtz wrote:
> > Per ICH10 datasheet [1] pg. 711, after completing a block transaction,
> > INTR should be checked & cleared separately, only after BYTE_DONE is
> > first cleared:
> >
> > When the last byte of a block message is received, the host controller
> > sets DS. However, it does not set the INTR bit (and generate another
> > interrupt) until DS is cleared. Thus, for a block message of n bytes,
> > the ICH10 will generate n+1 interrupts.
> >
> > [1] http://www.intel.com/content/dam/doc/datasheet/io-controller-hub-10-family-datasheet.pdf
> >
> > Currently, the INTR bit was only checked & cleared separately if the PEC
> > was used.
> > This patch checks and clears INTR at the very end of every successful
> > transaction, regardless of whether the PEC is used.
> >
> > Signed-off-by: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > ---
> > drivers/i2c/busses/i2c-i801.c | 46 ++++++++++++++++++++--------------------
> > 1 files changed, 23 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> > index 8b74e1e..6a53338 100644
> > --- a/drivers/i2c/busses/i2c-i801.c
> > +++ b/drivers/i2c/busses/i2c-i801.c
> > @@ -257,6 +257,24 @@ static int i801_check_post(struct i801_priv *priv, int status, int timeout)
> > return result;
> > }
> >
> > +/* wait for INTR bit as advised by Intel */
> > +static void i801_wait_intr(struct i801_priv *priv)
> > +{
> > + int timeout = 0;
> > + int status;
> > +
> > + status = inb_p(SMBHSTSTS(priv));
> > + while ((!(status & SMBHSTSTS_INTR)) && (timeout++ < MAX_RETRIES)) {
> > + usleep_range(250, 500);
> > + status = inb_p(SMBHSTSTS(priv));
> > + }
>
> Per my comment on previous patch, I've swapped the logic here to be in
> line with what we had before. I have no objection to trying this change
> again, but later, and only if you have actual numbers to back it up.
I've done some performance measurements, and it turns out that, with the
version of this patch modified by me, all short transactions are twice
as slow as before. This is because i801_transaction waits twice now:
once for BUSY to be clear, and then again once for INTR to be set.
I don't think this makes much sense, as both events normally happen at
the same time. As a matter of fact, the original code did clear INTR at
the end of i801_transaction without checking that it was set. Also, we
call i801_check_post() _before_ i801_wait_intr(), which makes no sense
IMHO. If INTR was really not set yet, then checking for errors was
wrong, it was too early.
I'm not even sure why we rely on the BUSY bit in the first place. It
would seem easier to just wait for INTR.
Thinking about it some more, the idea of function i801_wait_intr() is a
little strange. Normally, you'd wait for INTR, then do what you have
to, and lastly clear the INTR bit. Having a function which waits for
INTR and clears it immediately seems wrong.
--
Jean Delvare
next prev parent reply other threads:[~2012-07-01 21:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-27 13:54 [PATCH 0/8 v3] i2c: i801: enable irq Daniel Kurtz
2012-06-27 13:54 ` [PATCH 1/8 v3] i2c: i801: refactor use of LAST_BYTE i801_block_transaction_byte_by_byte Daniel Kurtz
2012-06-27 14:39 ` Jean Delvare
2012-06-27 13:54 ` [PATCH 2/8 v3] i2c: i801: optimize waiting for HWPEC to finish Daniel Kurtz
2012-06-27 14:58 ` Jean Delvare
2012-06-27 13:54 ` [PATCH 3/8 v3] i2c: i801: check INTR after every transaction Daniel Kurtz
[not found] ` <1340805255-8041-4-git-send-email-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-06-27 16:07 ` Jean Delvare
2012-06-28 7:51 ` Daniel Kurtz
[not found] ` <CAGS+omCoto4djKuZUooeD2A-szjrH4e9=YJCptR_raOdQ8g3-A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-06-28 11:36 ` Jean Delvare
[not found] ` <20120627180724.762f854a-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-07-01 21:20 ` Jean Delvare [this message]
[not found] ` <20120701232051.308c03d1-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-07-02 1:19 ` Daniel Kurtz
[not found] ` <CAGS+omDV_ynBL-PN0qmLmDRiHGbQFf+TwqC2-+KJY8zy9FDhrA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-02 10:08 ` Jean Delvare
[not found] ` <20120702120814.47d71bc5-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-07-02 15:16 ` Jean Delvare
2012-06-27 13:54 ` [PATCH 4/8 v3] i2c: i801: check and return errors during byte-by-byte transfers Daniel Kurtz
[not found] ` <1340805255-8041-5-git-send-email-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-06-27 16:51 ` Jean Delvare
2012-06-28 3:46 ` Daniel Kurtz
[not found] ` <CAGS+omDkhA=dP0JP=4huQEwJ4j6YqZWJ+mFsJv+eeGMBRpu5fQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-06-28 7:08 ` Jean Delvare
[not found] ` <1340805255-8041-1-git-send-email-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-06-27 13:54 ` [PATCH 5/8 v3] i2c: i801: rename some SMBHSTCNT bit constants Daniel Kurtz
[not found] ` <1340805255-8041-6-git-send-email-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-06-27 17:01 ` Jean Delvare
2012-06-27 13:54 ` [PATCH 6/8 v3] i2c: i801: drop ENABLE_INT9 Daniel Kurtz
[not found] ` <1340805255-8041-7-git-send-email-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-06-28 7:04 ` Jean Delvare
2012-06-27 13:54 ` [PATCH 7/8 v3] i2c: i801: enable irq for i801 smbus transactions Daniel Kurtz
[not found] ` <1340805255-8041-8-git-send-email-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-07-04 15:48 ` Jean Delvare
2012-07-04 20:16 ` Jean Delvare
[not found] ` <20120704221600.416d4475-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-07-05 4:31 ` Daniel Kurtz
2012-07-05 8:10 ` Jean Delvare
2012-07-05 10:29 ` Jean Delvare
2012-07-06 10:28 ` Daniel Kurtz
[not found] ` <CAGS+omAgVLumYvOssHfdjELXixMdfRSxSj003xPzQ5v4h_D-mA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-07-06 11:55 ` Jean Delvare
2012-06-27 13:54 ` [PATCH 8/8 v3] i2c: i801: enable irq for byte_by_byte transactions Daniel Kurtz
2012-07-05 14:46 ` Jean Delvare
[not found] ` <1340805255-8041-9-git-send-email-djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
2012-07-08 11:53 ` Jean Delvare
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=20120701232051.308c03d1@endymion.delvare \
--to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org \
--cc=seth.heasley-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
/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;
as well as URLs for NNTP newsgroup(s).