On Wed, Aug 26, 2015 at 2:22 PM, Werner Johansson werner.johansson@gmail.com wrote:
On Aug 26, 2015 10:46, "Rob Clark" robdclark@gmail.com wrote:
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..
Interesting point! However, in this case I had to adjust the clock hundreds of kHz to make it tick over one step of hs_zero, so it might not be absolutely necessary here. Do we need better than 10ppm accuracy for display timing (assuming 100MHz pixel clock, 1kHz step size and that I did the math correctly)? We don't even have kHz accuracy with the PLLs in the QC platforms we currently use..
I think the rounding error happens with the smaller numbers / intermediate results but maybe clock should be represented in Hz internally anyway? Not sure if it's worth changing the external-facing representation though?
I'm not completely sure.. I did observe that we calculated slightly different settings w/ the auo novatek panel on z3, compared to what downstream had hard-coded in dts (which presumably came from magic-spreadsheet), because (I think) of rounding mode->clock to integer KHz. Although in the case of the z3 panel, it didn't seem to matter. What I am unsure about is whether other panels might be more sensitive to different settings.
BR, -R