RE: drm/msm/dsi: hs_zero timing

["Hai Li" <hali@codeaurora.org>]

Hi Werner,

When I made DSI changes, I tried to limit the information in DT (like our downstream driver), until there is a case driver really cannot figure it out by the existing information.
I think this is the requirement of upstream kernel.

If we see a panel requires different value in PHY_LN_CFG_4(x) register and cannot derive it from any other timings, we could think about adding it into DT.

Also, I am wondering if this Panasonic WUXGA panel works with downstream driver, since I see the same hardcoded values set for all the panels.


Thanks,
Hai

-----Original Message-----
From: dri-devel [mailto:dri-devel-bounces@lists.freedesktop.org] On Behalf Of Johansson, Werner
Sent: Friday, August 21, 2015 2:27 PM
To: dri-devel@lists.freedesktop.org
Subject: drm/msm/dsi: hs_zero timing

Hi,

In drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c there are a few "magic number" writes to the PHY_LN_CFG_4(x) registers around line 108 (adjusting the hs_zero period per lane). This causes some problems with certain panel timings when timing->hs_zero plus an "unknown integer" becomes evenly divisible by 8 - this will cause the DSI output to misbehave (typically leading to black screen). On the three panels I've tested I have different "unknown integers" which I can't immediately derive from the rest of the PHY timings:

(PHY timing debug output in this order: clk_pre, clk_post, clk_zero, clk_trail, clk_prepare, hs_exit, hs_zero, hs_prepare, hs_trail, hs_rqst)

Panasonic VVX panel (WUXGA): PHY timings: 47, 2, 259, 62, 42, 112, 118, 46, 66, 51 hs_zero calculated value of 118 does not work (neither does anything <74, 78, 86, 94, 102, 110, 126, 134, 142, 150, 158, 166, 174, 182, 190, 198, 206, 214, 222, 230, 238, 246, 254)

Sharp (1080p) on Xperia Z3: PHY timings: 44, 2, 238, 56, 38, 104, 110, 42, 60, 44 hs_zero calculated value of 110 works fine here but 104, 112, 120 and the remaining multiples of 8 does not.

Sharp (qHD) on Dragonboard 800: PHY timings: 28, 4, 139, 30, 20, 68, 72, 24, 34, 25 hs_zero calculated value of 72 works fine but 62, 70, 78, 86 and the remaining multiples of 8 does not.

hs_trail looked promising at first: a bad hs_zero value + hs_trail would be evenly divisible by 8 for Panasonic and the 1080p Sharp panel but not for the Sharp qHD display, and adjusting hs_trail did not solve the issue.

However, setting all the lane adjust values for hs_zero to 0 solves the problem for the troublesome WUXGA panel timing and does not create any apparent downsides for the other two.

Does anyone know of a reason this skew is implemented? If it is indeed needed in some cases would a move to DT instead of leaving it hard-coded make sense?

Thanks for any input!

/wj

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel