All of lore.kernel.org
 help / color / mirror / Atom feed
From: Archit Taneja <architt@codeaurora.org>
To: Werner Johansson <werner.johansson@gmail.com>,
	Rob Clark <robdclark@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: drm/msm/dsi: hs_zero timing
Date: Fri, 28 Aug 2015 11:26:07 +0530	[thread overview]
Message-ID: <55DFF7F7.3010304@codeaurora.org> (raw)
In-Reply-To: <CAKVuvfqexJnBinbkzNKD1S3UQCUDLeq9Wh3x2_Xw2X4iaBCF9g@mail.gmail.com>



On 08/27/2015 07:12 AM, Werner Johansson wrote:
> On Aug 26, 2015 11:31 AM, "Rob Clark" <robdclark@gmail.com
> <mailto:robdclark@gmail.com>> 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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2015-08-28  5:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-21 18:26 drm/msm/dsi: hs_zero timing Johansson, Werner
2015-08-21 19:55 ` Hai Li
2015-08-21 20:38   ` Johansson, Werner
2015-08-22 13:25     ` Rob Clark
2015-08-24  6:17       ` Werner Johansson
2015-08-24 14:32       ` Hai Li
2015-08-25  1:23         ` Werner Johansson
2015-08-26 15:34           ` Hai Li
2015-08-26 17:39             ` Werner Johansson
2015-08-26 17:46               ` Rob Clark
2015-08-26 18:22                 ` Werner Johansson
2015-08-26 18:31                   ` Rob Clark
2015-08-27  1:42                     ` Werner Johansson
2015-08-28  5:56                       ` Archit Taneja [this message]
2015-08-28  6:09                         ` Werner Johansson
2015-09-01 15:59                           ` Hai Li
2015-09-01 16:27                             ` Werner Johansson
2015-08-28 14:12                         ` hali
2015-08-26 17:49               ` Hai Li
2015-08-26 18:04                 ` Werner Johansson
  -- strict thread matches above, loose matches on Subject: below --
2015-08-21 18:13 Werner Johansson
2015-08-21  1:08 Johansson, Werner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55DFF7F7.3010304@codeaurora.org \
    --to=architt@codeaurora.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robdclark@gmail.com \
    --cc=werner.johansson@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.