On 17/03/2020 12:22, Jacopo Mondi wrote:
Hi Tomi,
welcome to the ov5640 bandwagon
This driver received lot of attention and reworking, but there are
indeed several issues at the moment :(
On Fri, Mar 13, 2020 at 01:15:33PM +0200, Tomi Valkeinen wrote:
Hi all,
I've been testing and debugging OV5640 with TI's DRA76 and AM65 platforms,
which have the CAL IP for MIPI CSI2 RX.
The most clear problem is that 1280x720@30 doesn't work at all, but with all
resolutions I can see occasional PHY errors reported when starting the
streaming.
I've been testing a CSI-2 setup with 2 data lanes on an IMX6 platform,
just for the record
Two lanes here too.
The OV5640 spec lists the video timings, but I haven't been able to figure
out what exactly they mean, as e.g. the vsync time doesn't seem to match the
other times according to my calculations.
Are you referring to the ov5640_mode_info structures ?
Yes.
Looking at the git log, these values seem to have been there from the start. Initially in the raw
register sequences, then moved from there to ov5640_mode_info. But the numbers have been the same.
I wonder where they came originally, and whether they have ever been correct.
Perhaps I'll cook up a patch where I'll update the values to what the sensor sheet suggests, and
other people can try and see if the driver still works for them.
In any case, I was poking here and there, and noticed that if I use the htot
value from the spec (2844), instead of the current value (1896 for most
resolutions), 1280x720 works, and the PHY errors are gone.
Testing more, I found out that the smaller the htot, the more unreliable the
RX becomes, and going down from 2844, somewhere around 2400 I start to see
errors.
That's a good finding!
I recall I had issues as well with that mode, and fixed them by
doubling the MIPI bus clock speed You might have noticed these lines
in the CSI-2 clock tree calculation function ov5640_set_mipi_pclk()
/*
* 1280x720 is reported to use 'SUBSAMPLING' only,
* but according to the sensor manual it goes through the
* scaler before subsampling.
*/
if (mode->dn_mode == SCALING ||
(mode->id == OV5640_MODE_720P_1280_720))
mipi_div = OV5640_MIPI_DIV_SCLK; // THIS is 1
else
mipi_div = OV5640_MIPI_DIV_PCLK; // THIS is 2: halve the MIPI clock speed
I had that mode working, but after a good year or so trying to decode
the clock tree of the sensor with only partially satisfactory results,
I can't tell if that was by accident or not :)
The comment says that the above is according to the sensor manual, but I couldn't find mention of
that. Do you recall where you found that information?
I'm not that much familiar with CSI-2, and very little with OV5640. Does
anyone have a clue about what I'm observing here? Does 1280x720@30 work on
Hugues made a great effort by sampling the actual frequencies on the
bus, and he found out the actual frequencies are off compared to my
theoretical calculations. After that I've actually dropped the ball and
moved on, but maybe throwing your htot findings in the mix could help?
Here you have the thread with more information and Hugues measurement
results:
https://patchwork.kernel.org/patch/11019673/
other platforms with CSI2? Where do the current OV5640 video timings come
from?
I suggest you have a look at
dfbfb7aa832c ("media: ov5640: Compute the clock rate at runtime")
htot is used to calculate the desired pixel clock, so it could indeed
be one of the reasons why the above clock tree calculations are off.
Hope it helps a bit.
Thanks! Seems that this is all a bit of a detective work =). I have no means to measure the CSI
clock/data lanes, so debugging this is obviously rather frustrating.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
