On Wed, Aug 26, 2015 at 2:22 PM, Werner Johansson <werner.johansson@xxxxxxxxx> wrote: > > On Aug 26, 2015 10:46, "Rob Clark" <robdclark@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
