Reported by Nikolaus Schaller, Jan 29, 2011
Add driver for the (optional) Camera module.
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 <email@example.com>) 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.
Comment 7 by Nikolaus Schaller, Apr 22, 2013