OV5647 unicam and V4L2 driver usage

[anuj.k]

Hello! I'm trying to get the OV5647 working using the open source unicam + V4L2 drivers, but struggling a bit. After enabling the appropriate device tree overlay (otherwise using the driver out of the box), this is the image I get:

testing.png (208.13 KiB) Viewed 399 times

This is using the 640x480, 8-bit Bayer output. Clearly something is misconfigured, but I would have expected this to work out of the box:

Code: Select all

v4l2-ctl --stream-mmap --stream-to=testing.raw --stream-count=1 

(Trying to get the mainline ov5647 unicam subdevice driver working as a baseline before modifying for another camera module that we're trying to bring up.)

Does anyone have pointers on what to look into with getting the default ov5647 driver working as expected?

Thanks in advance!

[6by9]

The ov5647 driver was originally a mainline driver that only supported raw 8 VGA readout cropped from the top left of the frame, and it had near zero controls. We extended it to add the other readout modes, raw10 support, and a bundle of controls to actually make it useful.
The original driver was a little unreliable as it wasn't explicit about whether it used continuous clocks or dropped the clock lane to LP mode, but did work after a fashion.
Note also that the first frame produced from an image sensor is often incorrectly exposed or otherwise "incorrect", so it's generally goood policy to drop it.

If you use the modified version of yavta from https://github.com/6by9/yavta, then running with the -m flag sends it through the MMAL ISP component to the display, so quicker and easier than messing with v4l2-ctl and then looking at the raw files. Doing so with ov5647 I will agree that there appears to be an issue with the 8bit mode. The 10bit modes all appear to be OK.

Depending on what your new sensor is, it's probably easier to use imx219 as a basis as that was merged to mainline more recently, and therefore has been reviewed against the more recent ways of doing things. It too supports both 8 and 10 bit readout (and in a nicer way as all modes are supported at both bitdepths).
Likewise imx290 was reviewed and merged this year (although I've extended that on our branches compared to mainline). imx327 is compatible with the imx290 driver, and modules are available from a couple of manufacturers.

Do check whether anyone else has started on a driver first - a search of the linux-media mailing list and a general Google (other search engines are available) for the sensor name and "linux" often provide links to Rockchip, NVidia's, or other similar companies vendor kernels which provide some support.

[anuj.k]

Hi, I wanted to circle back and thank you for your help! We took your suggestion to start over with the IMX219 driver, and that helped clarify some of the issues we were facing. We've got our new sensor working now!