Re: [linux-2.6 PATCH 1/1] i2c-i801: Re-read busy bit and wait for transaction to complete

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

On Tue, 15 Sep 2009 12:00:08 -0700, Chaitanya Lala wrote:
> 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.

This was quite some times ago. Any news?

-- 
Jean Delvare