drm/msm/dsi: hs_zero timing

Hai Li hali at codeaurora.org
Mon Aug 24 07:32:34 PDT 2015


Hi Werner,

Yes, the register is to adjust hs_zero.
Could you share the panel's video timing and dphy timings (or the panel DT), used by downstream driver?

The dphy timing calculations in the phy driver are from the excel sheet as well, I can check if there is any issue inside the calculation code making the difference.


Thanks,
Hai

-----Original Message-----
From: Rob Clark [mailto:robdclark at gmail.com] 
Sent: Saturday, August 22, 2015 9:25 AM
To: Johansson, Werner
Cc: Hai Li; dri-devel at lists.freedesktop.org
Subject: Re: drm/msm/dsi: hs_zero timing

On Fri, Aug 21, 2015 at 4:38 PM, Johansson, Werner <Werner.Johansson at sonymobile.com> wrote:
>> 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) ga
>> 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).
>

fwiw, if the values are related to the physical cabling/wiring, rather than the panel timing, we should probably get them from DT..

if a combination of the timing and the wiring, that gets a bit more complicated

(I am not actually sure myself about these)

BR,
-R

>> 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.
>
> Thanks!
> /wj
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



More information about the dri-devel mailing list