Comment 1 by Nikolaus Schaller, Jul 28, 2011

Our camera is a OV9655 module connected to I2C2.

The LInux kernel comes with a camera driver for SOC_CAMERA_OV9640
(see src/drivers/media/video). This *may* be reasonably similar to 
our camera.

There is also some OMAP3 camera driver VIDEO_OMAP3

Here is a blog about connecting camera modules to a beagleboard XM: 
http://maxgalemin.blogspot.com/2011/04/li-5m03-camera-on-beagleboard-
xm.html

Comment 2 by Nikolaus Schaller, Nov 17, 2011

We have found a OV9640 (ov96xx) driver that should fit. It has been 
added to the kernel sources and the boardfile, but not tested nor 
debugged.

Comment 3 by Nikolaus Schaller, Jan 9, 2012

Driver has been added

http://projects.goldelico.com/p/gta04-kernel/source/commit/e98c681b2d
96c9406135a9036863522216b4600f/
https://github.com/goldelico/gta04-kernel/commit/e98c681b2d96c9406135
a9036863522216b4600f

and partially works:
* gta04_cam and omap34xxcam and ov9655.ko are loaded properly
* Power and clock is switched on/off properly
* Camera emits sync and data (verified with oscilloscope)
* mplayer reports some understandable errors (not all ioctls are 
complete) but
* v4l2: select timeout 

Test command:

    mplayer tv:// -tv 
driver=v4l2:width=1280:height=1024:device=/dev/video0:fps=12 -vo x11

Ideas what can be wrong:
* clock frequency
* prescalers in OMAP and/or camera chip
* pinmux (unlikely)
* cam_xclk routing
* sync polarity
* number of bytes sent by camera vs. what interface expects (camera 
is SXGA by default, driver is VGA by default)

Generally, the register initialization of the OV9655 driver (which 
originates in a soc_camera driver by Stefan Herbrechtsmeier 
<hbmeier@hni.uni-paderborn.de>) is suspect. It writes to 
reserved registers and changes/sets some bits denoted as being 
reserved in the (preliminary!) datasheet:

http://www.surveyor.com/blackfin/OV9655-datasheet.pdf

Comment 4 by Nikolaus Schaller, Mar 22, 2012

idea for further analysis: switch the CAM interface lines to GPIO 
mode (and export to /sys) and try to read an image (at least some 
bit patterns) through the GPIOs. This could also allow to check 
hsync/vsync frequencies.
The problem is that the standard user space video commands try to 
setup and enable the camera (power, clock, I2C etc.) and then want 
to read an image. And shut down the camera again because this fails.
I.e. we can't get to the GPIOs...

Comment 5 by Nikolaus Schaller, Apr 22, 2012

Reading GPIO works and shows some bit patterns consistent with very 
slow sampling.

Here is a register programming data set for different image 
resolutions:

http://code.google.com/p/surveyor-srv1-firmware/source/browse/trunk/b
lackfin/srv/ov9655.h?r=131

We must analyse what these patterns mean and which registers they 
influence.

The code to send these patterns through I2C can be found in 
(camera_setup starting at line 1002):

http://code.google.com/p/surveyor-srv1-firmware/source/browse/trunk/b
lackfin/srv/srv.c?r=131

These reources should help to better understand how to program the 
camera chip for specific resolutions and other functions.

Comment 6 by Nikolaus Schaller, Mar 21, 2013

Driver basically works in 3.7 kernel (using subdevices and media-ctl 
tool for the ISP.

Image (camera register settings) needs a lot of improvement.