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
