Re: OV5640 CSI2 problemsg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

>
> 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 ?

> 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 :)

> 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
   j

>  Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux