On 08/27/2015 07:12 AM, Werner Johansson wrote:
On Aug 26, 2015 11:31 AM, "Rob Clark" <robdclark@xxxxxxxxx <mailto:robdclark@xxxxxxxxx>> wrote: > > 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. 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. 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)?
There are certain modes (generally for HDMI/DVI) where the refresh rate isn't an integer. It can be something like 59.94 Hz, or 60.04Hz. The above calculation may not work well with such modes. For example, a 720p@59.94Hz mode requires 74.175 Mhz. This value can be expressed relatively accurately in KHz if stored beforehand in mode->clock. If we try to calculate the pixel clock here ourselves, we'll need to round off the vrefresh to 60Hz, which gives us a less accurate 74.25 Mhz. We have platforms where the DSI output is connected to HDMI bridge chips. So the issue I mentioned holds true for msm/dsi too. Thanks, Archit -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel