From: Mario Kleiner <mario.kleiner.de@gmail.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Cc: Dave Airlie <airlied@redhat.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 13/14] drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
Date: Mon, 13 Jan 2014 01:22:27 +0100 [thread overview]
Message-ID: <52D331C3.5000606@gmail.com> (raw)
In-Reply-To: <1383069978-12476-14-git-send-email-ville.syrjala@linux.intel.com>
On 29/10/13 19:06, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> i915 doesn't need this kludge for most platforms. Although we do
> appear to need something similar on certain platforms, but we can
> be more accurate when we apply the adjustment since we know exactly
> why the scanline counter doesn't always quite match the vblank
> status.
>
> Also the current code doesn't handle interlaced modes correctly,
> and we already deal with interlaced modes in i915 code.
>
> So let's just move the current code to radeon_get_crtc_scanoutpos()
> since that's why it was added. For i915 we'll add a more finely
> targeted variant.
>
The logic itself looks correct and should work, although i couldn't test
it because of the dying PC.
But see below for some bugfix and some little nit-pick.
Other than that
Reviewed-by: mario.kleiner.de@gmail.com
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/drm_irq.c | 25 ++-----------------------
> drivers/gpu/drm/radeon/radeon_display.c | 22 ++++++++++++++++++++++
> 2 files changed, 24 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index b39255f..a1cc1a3 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -542,7 +542,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> {
> ktime_t stime, etime, mono_time_offset;
> struct timeval tv_etime;
> - int vbl_status, vtotal, vdisplay;
> + int vbl_status;
> int vpos, hpos, i;
> int framedur_ns, linedur_ns, pixeldur_ns, delta_ns, duration_ns;
> bool invbl;
> @@ -558,9 +558,6 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> return -EIO;
> }
>
> - vtotal = mode->crtc_vtotal;
> - vdisplay = mode->crtc_vdisplay;
> -
> /* Durations of frames, lines, pixels in nanoseconds. */
> framedur_ns = refcrtc->framedur_ns;
> linedur_ns = refcrtc->linedur_ns;
> @@ -569,7 +566,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> /* If mode timing undefined, just return as no-op:
> * Happens during initial modesetting of a crtc.
> */
> - if (vtotal <= 0 || vdisplay <= 0 || framedur_ns == 0) {
> + if (framedur_ns == 0) {
> DRM_DEBUG("crtc %d: Noop due to uninitialized mode.\n", crtc);
> return -EAGAIN;
> }
> @@ -631,24 +628,6 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev, int crtc,
> */
> delta_ns = vpos * linedur_ns + hpos * pixeldur_ns;
>
> - /* Is vpos outside nominal vblank area, but less than
> - * 1/100 of a frame height away from start of vblank?
> - * If so, assume this isn't a massively delayed vblank
> - * interrupt, but a vblank interrupt that fired a few
> - * microseconds before true start of vblank. Compensate
> - * by adding a full frame duration to the final timestamp.
> - * Happens, e.g., on ATI R500, R600.
> - *
> - * We only do this if DRM_CALLED_FROM_VBLIRQ.
> - */
> - if ((flags & DRM_CALLED_FROM_VBLIRQ) && !invbl &&
> - ((vdisplay - vpos) < vtotal / 100)) {
> - delta_ns = delta_ns - framedur_ns;
> -
> - /* Signal this correction as "applied". */
> - vbl_status |= 0x8;
> - }
> -
> if (!drm_timestamp_monotonic)
> etime = ktime_sub(etime, mono_time_offset);
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
> index 3581570..9d02fa7 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1709,5 +1709,27 @@ int radeon_get_crtc_scanoutpos(struct drm_device *dev, int crtc, unsigned int fl
> if (in_vbl)
> ret |= DRM_SCANOUTPOS_INVBL;
>
> + /* Is vpos outside nominal vblank area, but less than
> + * 1/100 of a frame height away from start of vblank?
> + * If so, assume this isn't a massively delayed vblank
> + * interrupt, but a vblank interrupt that fired a few
> + * microseconds before true start of vblank. Compensate
> + * by adding a full frame duration to the final timestamp.
> + * Happens, e.g., on ATI R500, R600.
> + *
> + * We only do this if DRM_CALLED_FROM_VBLIRQ.
> + */
> + if ((flags & DRM_CALLED_FROM_VBLIRQ) && !in_vbl) {
> + vbl_start = rdev->mode_info.crtcs[crtc]->base.hwmode.crtc_vdisplay;
vbl_start gets already initialized by the code above, so the vbl_start
assignment here shouldn't be neccessary. Only the vtotal assignment
below is really needed.
> + vtotal = rdev->mode_info.crtcs[crtc]->base.hwmode.crtc_vtotal;
> +
> + if (vbl_start - *vpos < vtotal / 100) {
> + vpos -= vtotal;
Here vpos is an int*, so the following line will corrupt kernel memory
and die. Obviously then this
> + *vpos -= vtotal;
instead.
> +
> + /* Signal this correction as "applied". */
> + ret |= 0x8;
ret |= 0x8;
This is not really defined as return flag for the
driver->get_scanout_position() hook, but would work.
The value was only used in its original function for diagnostic
DRM_DEBUG output in the DRM core at higher drm debug levels, but has
some use for debugging.
Now that it is also used in kms drivers, maybe define it properly as
#define DRM_SCANOUTPOS_NUDGED (1 << 3)
or something like that in include/drm/drmP.h to mark value 0x8 as used?
Or drop the 0x8 return code and add some DRM_DEBUG statement instead?
Same for patch 14 in the i915 driver.
thanks,
-mario
> + }
> + }
> +
> return ret;
> }
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-01-13 0:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-29 18:06 [PATCH 00/14] drm: Some more vblank timestampi changes ville.syrjala
2013-10-29 18:06 ` [PATCH 01/14] drm: Pass the display mode to drm_calc_timestamping_constants() ville.syrjala
2013-10-29 18:06 ` [PATCH 02/14] drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos() ville.syrjala
2013-10-29 18:06 ` [PATCH 03/14] drm/i915: Kill hwmode save/restore ville.syrjala
2013-10-29 18:06 ` [PATCH 04/14] drm/i915: Call drm_calc_timestamping_constants() earlier ville.syrjala
2013-10-29 18:06 ` [PATCH 05/14] drm: Improve drm_calc_timestamping_constants() documentation ville.syrjala
2013-10-29 18:06 ` [PATCH 06/14] drm: Simplify the math in drm_calc_timestamping_constants() ville.syrjala
2013-10-29 18:06 ` [PATCH 07/14] drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings() ville.syrjala
2013-10-29 18:06 ` [PATCH 08/14] drm: Use crtc_clock in drm_calc_timestamping_constants() ville.syrjala
2013-10-29 18:06 ` [PATCH 09/14] drm: Change {pixel,line,frame}dur_ns from s64 to int ville.syrjala
2013-10-29 18:06 ` [PATCH 10/14] drm/i915: Fix scanoutpos calculations for interlaced modes ville.syrjala
2013-10-29 18:06 ` [PATCH 11/14] drm: Fix vblank timestamping constants " ville.syrjala
2013-10-29 18:06 ` [PATCH 12/14] drm: Pass 'flags' from the caller to .get_scanout_position() ville.syrjala
2014-01-13 0:02 ` Mario Kleiner
2013-10-29 18:06 ` [PATCH 13/14] drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos() ville.syrjala
2014-01-13 0:22 ` Mario Kleiner [this message]
2013-10-29 18:06 ` [PATCH 14/14] drm/i915: Add a kludge for DSL incrementing too late and ISR not working ville.syrjala
2013-11-06 3:46 ` [PATCH 00/14] drm: Some more vblank timestampi changes Dave Airlie
2013-11-29 13:36 ` Ville Syrjälä
2013-11-30 12:51 ` Mario Kleiner
2014-01-12 23:58 ` Mario Kleiner
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=52D331C3.5000606@gmail.com \
--to=mario.kleiner.de@gmail.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox