[i2c] [patch 2.6.24-rc1-git] i2c-algo-bit, don't yield()
David Brownell
david-b at pacbell.net
Tue Nov 6 20:01:08 CET 2007
On Tuesday 06 November 2007, Jean Delvare wrote:
> On Sun, 4 Nov 2007 12:38:35 -0700, David Brownell wrote:
> > Don't use yield(). It can have nasty scheduling properties; and in any
> > case this code could be interrupted or otherwise preempted at any time.
>
> Can you please be more specific? I can't see any problem here. We're
> between two I2C transactions, how could being rescheduled be an issue?
Use (== abuse) of yield() is one of Andrew Mortons pet bugaboos.
I forget the details -- I think they related to trashing state
that kept the scheduler well-behaved -- but the short version of
the story was that it shouldn't really be used.
Turn it around: why use it at all? Or why use yield() instead
of cond_resched()?
> > This address retry mechanism should be removed from the I2C stack at some
> > point. Meanwhile, there's no point in having its primary implementation
> > misbehave.
>
> Well, I seem to remember we agreed on that and nobody objected, so
> rather than trying to fix this code, what about sending a patch that
> rips the whole thing off?
NYET. We also wanted to try a less bloodthirsty approach
than just ripping it out ... in case anyone relied on it. :)
- Dave
> > Signed-off-by: David Brownell <dbrownell at users.sourceforge.net>
> > ---
> > drivers/i2c/algos/i2c-algo-bit.c | 1 -
> > 1 files changed, 1 deletion(-)
> >
> > --- a.orig/drivers/i2c/algos/i2c-algo-bit.c 2007-09-05 09:08:53.000000000 -0700
> > +++ a/drivers/i2c/algos/i2c-algo-bit.c 2007-09-05 12:01:35.000000000 -0700
> > @@ -322,7 +322,6 @@ static int try_address(struct i2c_adapte
> > bit_dbg(3, &i2c_adap->dev, "emitting stop condition\n");
> > i2c_stop(adap);
> > udelay(adap->udelay);
> > - yield();
> > bit_dbg(3, &i2c_adap->dev, "emitting start condition\n");
> > i2c_start(adap);
> > }
>
> Thanks,
> --
> Jean Delvare
>
More information about the i2c
mailing list