Hi Tomi, On Tue, Mar 17, 2020 at 02:40:35PM +0200, Tomi Valkeinen wrote: > 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. > Yup, that's my understanding as well > 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? > In my datasheet version (2.03) page 22 reports a list of modes and the associated "scaling method". 1280x720 is reported as "cropping + subsampling" that's where I got the mode "goes through the scaler". > > > 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 It is I'm afraid. Thanks for your effort! > 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
