<div dir="ltr"><p dir="ltr">On Aug 26, 2015 11:31 AM, "Rob Clark" <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br>><br>
> I'm not completely sure.. I did observe that we calculated slightly<br>
> different settings w/ the auo novatek panel on z3, compared to what<br>
> downstream had hard-coded in dts (which presumably came from<br>
> magic-spreadsheet), because (I think) of rounding mode->clock to<br>
> integer KHz.  Although in the case of the z3 panel, it didn't seem to<br>
> matter.  What I am unsure about is whether other panels might be more<br>
> sensitive to different settings.<br>
</p><p>Yes, the code definitely calculates different timing (as can be seen with the calculations for this particular Panasonic panel as well). We need more of the spreadsheet magic in the code it seems. This hs_zero issue seems to be a bug of sorts inside the MSM SoC itself though, not an issue with the panel (as exactly the same issue occurred with all three panels I tried. The "every-eighth value fails" failure mode does not seem to be timing related as I was able to fuzz the timing way outside of the specified ranges and still have perfectly good display, as long as I stayed out of the "every-eighth" value for hs_zero. The panels are typically not crystal controlled so their frequency tolerances are wide.</p><p>The display mode seems a bit over-specified, can we derive clock from htotal * vtotal * refreshrate instead and get the resolution needed (for DSI that should always result in the correct clock, right)?</p><p>/wj</p>
</div>