drm/msm/dsi: hs_zero timing
robdclark at gmail.com
Wed Aug 26 10:46:28 PDT 2015
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
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)??
More information about the dri-devel