cafe_ccic slowness in VIDIOC_S_FMT

[Mitch Bradley]

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