drm/msm/dsi: hs_zero timing

[Rob Clark]

On Wed, Aug 26, 2015 at 1:39 PM, Werner Johansson
<werner.johansson at gmail.com> wrote:
>
> On Aug 26, 2015 08:34, "Hai Li" <hali at codeaurora.org> wrote:
>>
>> Hi Werner,
>>
>> Thanks for sharing this. The DPHY timings in downstream dtsi are exactly
>> the same as the excel calculation, but slightly different from the output of
>> drm code as you posted. (e.g hs_zero is 116 vs 118)
>> I think it is caused by some precision loss during driver calculation, but
>> I need to double check.
>>
>> Could you help to try configuring the same DPHY timings as downstream, but
>> leave the values in  DSIPHY_LNx_CFG4 as is, to see if it works?
>
> 116 to hs_zero works fine without any other changes (only 118 and every
> eighth number up and down from there fails with this panel timing), so if we
> can do something to make sure we hit a working value for hs_zero without
> touching anything else that would be great!
>
> Thanks for checking the timings and let me know if you want me to test
> anything else. Is the excel formula considered public so we can discuss it
> here?

btw, w/ some of these clk rounding issues, I suspect we need 'struct
drm_display_mode' to be able to represent mode clock with greater
accuracy than Khz..

The good news is that drm_display_mode is not part of userspace ABI
(although drm_mode_modeinfo is.. and that is one path to populate
drm_display_mode)..  The bad news is that either way,
drm_display_mode::clock is referenced in *many* places.

Maybe we could add a new field to drm_display_mode to hold remainder
in Hz, and driver just take that field from panel (and ignore whatever
userspace may pass in)??

BR,
-R


> /wj