From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chaitanya Lala 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 12:00:08 -0700 Message-ID: <4AAFE438.60308@riverbed.com> References: <20090826221105.GA19712@clala-laptop> <20090912213843.59e990ad@hyperion.delvare> <4AAFD040.6040702@riverbed.com> <20090915204032.30dbfffe@hyperion.delvare> Reply-To: clala-DUeqMYwuH4dWk0Htik3J/w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20090915204032.30dbfffe-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org> Sender: linux-i2c-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jean Delvare Cc: "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: linux-i2c@vger.kernel.org Hi Jean, Jean Delvare wrote: > 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. > Thanks for the explanation. > 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. > > Will continue testing and let you know soon. Thanks, Chaitanya