cafe_ccic slowness in VIDIOC_S_FMT

[David Woodhouse]

On Sun, 2007-07-08 at 15:04 -0600, Jonathan Corbet wrote:
> David Woodhouse <dwmw2 at infradead.org> wrote:
> 
> > 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É?
> 
> I raised the issue with Marvell early on, but didn't get too far.  They
> seem to think that it works well enough.

We need a better response from Marvell -- 'it works well enough' is just
not acceptable. We need to know exactly what's going wrong, and
precisely what the timing constraints are. And ideally, it should be in
the datasheet. 

Is your value of 2ms empirical?

> > 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). 
> 
> Interesting.  I'd made a real effort to get the hard delays out of
> there, though.  Might the real solution be to use hrtimers here?

I suspect hrtimers aren't the answer. It's not the timing system -- it's
the scheduler. We're runnable almost immediately after we go to sleep --
but we just don't get the CPU back until a few userspace processes have
had a turn. I wonder if there's a way to make the scheduler give the CPU
back immediately -- temporarily setting the process to SCHED_FIFO would
be an evil hack, but maybe there's a nicer way?

> There's a *lot* of registers to write, I hate to hog the CPU for 2ms for
> every single one of them. 

Perhaps we could have a 'bulk write' i2c API where we can submit the
whole of (for example) the ov7670_default_regs array in one go, and the
smbus code can immediately do the next write from the IRQ handler?

There's a bunch of places where that kind of thing would be useful.

-- 
dwmw2