cafe_ccic slowness in VIDIOC_S_FMT

[David Woodhouse]

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 <dwmw2 at infradead.org>
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 <dwmw2 at infradead.org>

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);


-- 
dwmw2