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@earth.li http://www.earth.li/cgi-bin/mailman/listinfo/e3-hacking