In the OFW CaFe camera driver's I2C code, there is a 1 ms delay after observing that one of bits 18,17,16 is set in the RAW IRQ Status Register (offset 0x28). Additionally, in the case of an I2C write, there is another 2 ms delay before beginning to pool those bits.
I don't know how Lilian derived those delay values. In the 1 ms case, there is a comment that says "20 usec delay". It is possible that 20 uS would be enough; the API that this code was written to only goes down to millisecond granularity. David Woodhouse wrote: > On Sun, 2007-07-08 at 06:01 -0600, Jonathan Corbet wrote: > >> Trying to make this better was already on my list. The problem is that >> the Cafe i2c has to be treated *really* gently or you start getting >> those nifty "write timed out" problems. But there is almost certainly >> room for improvement, it's just a matter of working out what the minimum >> delays are. I'll try to get to it once I'm back home. >> > > Do we have a coherent explanation of these problems in the datasheet > and/or errata? Are they planned to be fixed in a future version of the > CAFÉ? > > The majority of the problem in this case is the scheduler -- just > changing from msleep(2) to mdelay(2) reduces the time taken for ov7670 > init by an order of magnitude (~377 ticks to ~32). Going to mdelay(1) > halves it again, but that 1ms is about as low as we can go -- poll for > completion any sooner than that, and something strange happens. We need > to hook that up to an analyser and work out _what_ is happening, unless > we've already done so. > > I've committed this... > > commit 4ef53002bc09fef121bf3ec2d2faaafc2d6edb85 > Author: David Woodhouse <[EMAIL PROTECTED]> > Date: Sun Jul 8 14:39:12 2007 -0400 > > [CAFÉ CCIC] Use mdelay() instead of msleep() for smbus write > > If we msleep we lose about two timeslices for every write and the > camera init takes 4 seconds or so. It really doesn't take long; for now > just wait for it. > > Signed-off-by: David Woodhouse <[EMAIL PROTECTED]> > > diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c > index c08f650..8648785 100644 > --- a/drivers/media/video/cafe_ccic.c > +++ b/drivers/media/video/cafe_ccic.c > @@ -369,10 +369,13 @@ static int cafe_smbus_write_data(struct cafe_camera > *cam, > rval = value | ((command << TWSIC1_ADDR_SHIFT) & TWSIC1_ADDR); > cafe_reg_write(cam, REG_TWSIC1, rval); > spin_unlock_irqrestore(&cam->dev_lock, flags); > - msleep(2); /* Required or things flake */ > + mdelay(2); /* It'll probably take about 900µs anyway, and the > + CAFÉ is apparently quite sensitive to being poked > + at this point. If we can work out precisely what's > + going on and reduce this delay, it would be nice. */ > > wait_event_timeout(cam->smbus_wait, cafe_smbus_write_done(cam), > - CAFE_SMBUS_TIMEOUT); > + CAFE_SMBUS_TIMEOUT); > spin_lock_irqsave(&cam->dev_lock, flags); > rval = cafe_reg_read(cam, REG_TWSIC1); > spin_unlock_irqrestore(&cam->dev_lock, flags); > > > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
