On Wed, Aug 26, 2015 at 1:39 PM, Werner Johansson werner.johansson@gmail.com wrote:
On Aug 26, 2015 08:34, "Hai Li" hali@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