Re: drm/msm/dsi: hs_zero timing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux