David Woodhouse wrote: > On Sun, 2007-07-08 at 15:04 -0600, Jonathan Corbet wrote: > >> David Woodhouse <[EMAIL PROTECTED]> 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. > > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
