On Wed, Aug 26, 2015 at 1:39 PM, Werner Johansson <werner.johansson@xxxxxxxxx> wrote: > > On Aug 26, 2015 08:34, "Hai Li" <hali@xxxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
