drm/msm/dsi: hs_zero timing

Johansson, Werner Werner.Johansson at sonymobile.com
Fri Aug 21 13:38:44 PDT 2015

> From: Hai Li [mailto:hali at codeaurora.org]
> Sent: den 21 augusti 2015 12:56
> 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.

Not sure how these skew values can be determined from the rest of the timing? Am I correct in my understanding that these registers would compensate for differences in physical length of the dsi lanes, or are they designed for a different purpose? The documentation is very vague on this point. Adjusting the values down to the default zero still works fine on the other panels (and enabled the Panasonic panel to work properly too).

> 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.

We have the Panasonic WUXGA panel working with the downstream driver (it's shipping in our Xperia Z2 tablets). The problem with our shipping kernel is that the timing values are derived from the Qualcomm Excel sheet and then hardcoded (in DT), the timing is not calculated on the fly as is the case here. It's very easy to just modify hs_zero value up or down one notch manually when having the timing hardcoded, but such a solution is certainly not generic.


More information about the dri-devel mailing list