cafe_ccic slowness in VIDIOC_S_FMT

[Mitch Bradley]

David Woodhouse wrote:
> 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. 
>   

Are we sure that the Marvell chip is the source of the problem?  The 
Omnivision chip could also be affecting the timing.


> 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.
>
>