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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.