Saturday 11 September 2010 04:06:02 Jasmine Strong wrote: > On 10 Sep 2010, at 18:21, Janusz Krzysztofik wrote: > > Both paths work stable for me, even > > under heavy load, on my OMAP1510 based Amstrad Delta videophone, that is > > the oldest, least powerfull OMAP1 implementation. > > You say that, but the ARM925 in OMAP1510 is known not to exhibit the bug Then, lucky me ;) > in > OMAP1610, which causes severe slowdown to DRAM writes when the first > address of an STM instruction is not aligned to a d-cache line boundary. > This means that at least last time I looked, the Linux ARM memcpy() > implementation is often faster on 1510 than 1610. This sounds like a problem that should be solved at a machine support level rather than a camera driver. I don't follow general OMAP development closely enough to know if this bug has ever been addressed or is going to be. Unfortunatelly, I have no access to any OMAP machine other than Amstrad Delta, so I'm not able to test the driver, including its performance, on other OMAP1 implementations. Anyways, I think there is always a room for improvement, either in my omap1_camera or maybe in the omap24xxcam driver, if someone tries to add support for a camera to an OMAP1 board other than 1510, and identifies a more optimal, 1610 or higher specific way of handling the OMAP camera interface. Do you think I should rename the driver to something like "omap1510cam" rather than "omap1_camera" then? Thanks, Janusz > > -J. > _______________________________________________ > e3-hacking mailing list > e3-hacking@xxxxxxxx > http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html