linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: clala-DUeqMYwuH4dWk0Htik3J/w@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [linux-2.6 PATCH 1/1] i2c-i801: Re-read busy bit and wait for transaction to complete
Date: Tue, 15 Sep 2009 20:40:32 +0200	[thread overview]
Message-ID: <20090915204032.30dbfffe@hyperion.delvare> (raw)
In-Reply-To: <4AAFD040.6040702-DUeqMYwuH4dWk0Htik3J/w@public.gmane.org>

Hi Chaitanya,

On Tue, 15 Sep 2009 10:34:56 -0700, Chaitanya Lala wrote:
> I tried your patch and preliminary results look encouraging.
> Will let you know about the final results in a few days.

OK, thanks.

> One question - Are we sure that msleep(2) would fix the glitch for good ?
> I am not very clear about the timings constraints of the i2c bus, hence 
> the query.

It doesn't have anything to do with I2C bus timings. The msleep() is
between the beginning of the transaction and the polling for result.
This is between the OS and the SMBus controller. The bus timings
themselves are solely handled by the SMBus controller in hardware and
we don't have to deal with it at all.

The msleep(1) has been there for a long time, back when HZ was
hard-coded to 100. This means we used to wait for at least 10 ms. With
HZ values increasing, the same code results in shorter sleeps (down to
1 ms). So maybe 1 ms wasn't sufficient and 2 ms will be. That being
said, if you didn't use HZ=1000... At HZ=250 and HZ=100, msleep(1) and
msleep(2) are the same, so I would be surprised if my patch really
helps for these values of HZ. I expected your problems to happen at
HZ=1000.

But please keep testing, and report what you find. If my patch doesn't
help, you could try with msleep(3) or msleep(4) and see if that helps.

-- 
Jean Delvare

  parent reply	other threads:[~2009-09-15 18:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-26 22:11 [linux-2.6 PATCH 1/1] i2c-i801: Re-read busy bit and wait for transaction to complete Chaitanya Lala
2009-09-12 19:38 ` Jean Delvare
     [not found]   ` <20090912213843.59e990ad-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-09-15 17:34     ` Chaitanya Lala
     [not found]       ` <4AAFD040.6040702-DUeqMYwuH4dWk0Htik3J/w@public.gmane.org>
2009-09-15 18:40         ` Jean Delvare [this message]
     [not found]           ` <20090915204032.30dbfffe-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2009-09-15 19:00             ` Chaitanya Lala
     [not found]               ` <4AAFE438.60308-DUeqMYwuH4dWk0Htik3J/w@public.gmane.org>
2009-12-17 13:21                 ` 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=20090915204032.30dbfffe@hyperion.delvare \
    --to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
    --cc=clala-DUeqMYwuH4dWk0Htik3J/w@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@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).