Samsung D-phy driver for IMX8MM

[AlexandreFiset]

Hello,

We are configuring a screen with the imx8mm.

After struggling with the timing configuration as we need to use only one lane.

It seems that increasing the defined overhead in the drivers/gpu/drm/bridge/sec-dsim.c bridge driver fixes our problem of DE vs payload miss alignment.

But we could not explain with the theory why this solves our problem. Is it possible to have more explanation on how this overhead is calculated ?

This patch was added by Fancy Fang (chen.fang@nxp.com) and can be found here : Eric Lee / smarc-fsl-linux-kernel | Embedian Git Server

Thank you in advance for your help.

Best regards,

Alexandre Fiset

[joanxie]

I believe the owner has already explained this in the patch:

When there is no existing horizontal blanking word counts in
'dsim_hblank_par' tables, these data requires to be computed
according to the 'hfp', 'hbp' and 'hsa' timings which are in
pixel unit. So the pixel unit data requires to be converted
to word count unit data correctly to match the PLL output clk
frequency.

this patch is for calculating correct PLL PMS

 

[AlexandreFiset]

Hello Joanxie,

Thank you for your response, but that wasn't really the question. The question wasn't about why a conversion from pixel to word is needed. But rather why the word count need to be adjusted by an overhead ( MIPI_XXX_PKT_OVERHEAD ).

Thank you in advance,
Alexandre Fiset

[joanxie]

this question should related to the design team, the new formula works because your timings isn't in the 'dsim_hblank_par' tables, if you use old formula, the timing isn't accurate enough to match PLL, so fancy add the new formula to correct this, if you want to understand this, I think best way is that you can add print to print the different value and compare with the two formula result

[AlexandreFiset]

Thank you Joanxie,

I might have poorly explain the situation, I understood that when not using timing in 'dsim_hblank_par' tables, pixel world needs to be translated into word world.

But the problem is that the given overheads are not the correct ones to make our display working. ( We had to patch the driver. )

Is it possible to have some contact from Samsung or NXP to e-mail them in order to understand what the overhead value of "6" represent and why "5" for example is not suitable?

Thank you in advance,

Alexandre Fiset

[joanxie]

"But the problem is that the given overheads are not the correct ones to make our display working. ( We had to patch the driver. )"

>what given overheads do you mean? you can refer to the latest bsp, we have already use this patch as default, you don't need to confused with this, the patch owner has left already

"https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/gpu/drm/bridge/sec-dsim.c?h=imx_5...."

[AlexandreFiset]

I am talking about those overheads (lines 271-273) :

#define MIPI_HFP_PKT_OVERHEAD	6
#define MIPI_HBP_PKT_OVERHEAD	6
#define MIPI_HSA_PKT_OVERHEAD	6

 Used to translate pixel world to word world (lines 933-940 and 953-956) :

		wc = DIV_ROUND_UP(vmode->hfront_porch * (bpp >> 3),
				  dsim->lanes);
		hfp_wc = wc > MIPI_HFP_PKT_OVERHEAD ?
			 wc - MIPI_HFP_PKT_OVERHEAD : vmode->hfront_porch;
		wc = DIV_ROUND_UP(vmode->hback_porch * (bpp >> 3),
				  dsim->lanes);
		hbp_wc = wc > MIPI_HBP_PKT_OVERHEAD ?
			 wc - MIPI_HBP_PKT_OVERHEAD : vmode->hback_porch;

		wc = DIV_ROUND_UP(vmode->hsync_len * (bpp >> 3),
				  dsim->lanes);
		hsa_wc = wc > MIPI_HSA_PKT_OVERHEAD ?
			 wc - MIPI_HSA_PKT_OVERHEAD : vmode->hsync_len; 

[joanxie]

I was told that  these OVERHEAD is estimated by R&D when they calibration different display timings, since this patch is useful for your display, just use it