Missing pixels on DSI interface

Hi,

we are experiencing missing pixels on the 720p DSI video output. We have an FPGA which samples the pixels and reproduces an RGB frame. We have noticed that per a 750 line frame there are 120-130 lines which are missing a clock on the horizontal sync. That is instead of receiving a 1650 (1280+370) clocks line we receive on the notorious lines only 1649 clocks. This causes a “shorter” frame by 120 clocks which causes our external appliance connected to the output of the FPGA to reject the frames.

This is the configuration I use in the panel-r-fpga-8-0.dtsi DSI device tre file

panel-r-fpga-8-0_ch1 {
				status					= "okay";
				compatible				= "r,fpga-8-0";
				nvidia,dsi-instance			= <DSI_INSTANCE_0>;
				nvidia,dsi-n-data-lanes			= <2>;
				nvidia,dsi-pixel-format			= <TEGRA_DSI_PIXEL_FORMAT_16BIT_P>;//<TEGRA_DSI_PIXEL_FORMAT_24BIT_P>;
				nvidia,dsi-refresh-rate			= <60>;
				nvidia,dsi-video-data-type		= <TEGRA_DSI_VIDEO_TYPE_VIDEO_MODE>;
				nvidia,dsi-video-clock-mode 		= <TEGRA_DSI_VIDEO_CLOCK_CONTINUOUS>;
				nvidia,dsi-video-burst-mode 		= <TEGRA_DSI_VIDEO_NONE_BURST_MODE_WITH_SYNC_END>;
				nvidia,dsi-virtual-channel		= <TEGRA_DSI_VIRTUAL_CHANNEL_0>;
				nvidia,dsi-panel-reset			= <TEGRA_DSI_DISABLE>;
				nvidia,dsi-power-saving-suspend 	= <TEGRA_DSI_DISABLE>;
				nvidia,dsi-ulpm-not-support		= <TEGRA_DSI_ENABLE>;
				nvidia,dsi-init-cmd			= <TEGRA_DSI_DELAY_MS 160>,
					<0x0 DSI_DCS_WRITE_0_PARAM DSI_DCS_EXIT_SLEEP_MODE 0x0 0x0>,
					<TEGRA_DSI_SEND_FRAME 5>,
					<TEGRA_DSI_DELAY_MS 20>,
					<0x0 DSI_DCS_WRITE_0_PARAM DSI_DCS_SET_DISPLAY_ON 0x0 0x0>,
					<TEGRA_DSI_DELAY_MS 20>;
				nvidia,dsi-n-init-cmd			= <6>;
				nvidia,dsi-suspend-cmd			=
					<0x0 DSI_DCS_WRITE_0_PARAM DSI_DCS_SET_DISPLAY_OFF 0x0 0x0>,
					<0x0 DSI_DCS_WRITE_0_PARAM DSI_DCS_ENTER_SLEEP_MODE 0x0 0x0>,
					<TEGRA_DSI_DELAY_MS 60>;
				nvidia,dsi-n-suspend-cmd		= <3>;
				disp-default-out {
					nvidia,out-type			= <TEGRA_DC_OUT_DSI>;
					nvidia,out-width		= <130>;
					nvidia,out-height		= <74>;
					nvidia,out-flags		=
					<TEGRA_DC_OUT_CONTINUOUS_MODE TEGRA_DC_OUT_INITIALIZED_MODE>;
					nvidia,out-parent-clk		= "plld3";
					nvidia,out-xres			= <1280>;
					nvidia,out-yres			= <720>;
				};
				display-timings {
					1280x720-32 {
						clock-frequency		= <74250000>;
						hactive			= <1280>;
						vactive			= <720>;
						hfront-porch		= <140>;
						hback-porch		= <140>;
						hsync-len		= <80>;
						vfront-porch		= <10>;
						vback-porch		= <10>;
						vsync-len		= <10>;
						nvidia,h-ref-to-sync	= <1>;
						nvidia,v-ref-to-sync	= <1>;
					};
				};

BTW, small changes to the hfront-porch, hback-porch affect randomly the number of clocks received by the FPGA.
I need to emphasize that once the configuration in the DSI is set (and flashed to the NVidia Module) the number of missing clocks per frame is constant.

We thought that the problem was on the FPGA side but the frame rate is constant thus the NVidia has to be the source of the missing clocks.

Any ideas how to configure the NVidia to get the exact number of clocks per frame?
Regards.

There is a known issue that pclk may not always be precise due to some conversion inside driver and if you are using FPGA, it would be problem.

Such issue would be resolved in next release (for HDMI/DP primarily)

May I ask how do you know the display-timings? Since dsi driver won’t read EDID, it should be read through DT as what you are doing.

Does that display timing follow the spec of your panel?

The display timing are dictated by the HD-SDI protocol to which the FPGA converts. As a result of incorrect frame timing the end devices reject the video output from the FPGA - As I state above.
I hope I understood your question regarding the display-timings: We have got these valued from the HD-SDI standard. Yes these values are “mostly” similar to what we are receiving on the FPGA side, but as I said sometimes there is inconsistency with the values in random lines.
BTW we could compensate for the lack of clocks per line but we cannot compensate for an incorrect frame duration, this has to be compensated with an intermediate memory - which imposes board redesign.

Is there a way to fix these issues?