public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races
Date: Wed, 26 Feb 2014 11:48:46 -0800	[thread overview]
Message-ID: <20140226114846.64304e77@jbarnes-desktop> (raw)
In-Reply-To: <1393297106.27769.48.camel@thor.local>

On Tue, 25 Feb 2014 11:58:26 +0900
Michel Dänzer <michel@daenzer.net> wrote:

> On Mon, 2014-02-24 at 14:11 +0200, Ville Syrjälä wrote:
> > On Mon, Feb 24, 2014 at 12:48:55PM +0900, Michel Dänzer wrote:
> > > On Fre, 2014-02-21 at 21:03 +0200, ville.syrjala@linux.intel.com wrote:
> > > > 
> > > > We can kill of the drm_vblank_{pre,post}_modeset() calls since those are
> > > > there simply to make drm_vblank_get() fail during a modeset.
> > > 
> > > Actually, their original purpose was to keep the DRM vblank counter
> > > consistent across modesets, assuming the modeset resets the hardware
> > > vblank counter.
> > 
> > I see. Well, actually I really don't. The code is too funky for me to
> > tell what it actually ends up doing. The obvious way would be to
> > resample the hardware counter at drm_vblank_post_modeset(), which the
> > code certainly doesn't do. But maybe it did something sensible in the
> > past.
> 
> When the pre/post-modeset hooks were originally added, it worked like
> this: the pre-modeset hook enabled the vblank interrupt, which updated
> the DRM vblank counter from the driver/HW counter. The post-modeset hook
> disabled the vblank interrupt again, which recorded the post-modeset
> driver/HW counter value.
> 
> But the vblank code has changed a lot since then, not sure it still
> works like that.

Yeah it's changed a bit.  I think Rob added the latest bits there.
They were originally in place to support both UMS and KMS drivers,
which is as ugly as it sounds.

As long as nothing breaks (vblank vs dpms, vblank vs modeset, vblank vs
high precision timestamps, vblank vs refcount) I think your code is ok.

Cc'ing Mario for another opinion too.  This makes me nervous but it
seems ok.

I think you should update the docbook (with examples) as well so other
driver writers will know how to use this stuff.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

-- 
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-02-26 19:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-21 19:03 [PATCH 0/5] drm: Allow vblank interrupts during modeset and make the code less racy ville.syrjala
2014-02-21 19:03 ` [PATCH 1/5] drm: Use correct spinlock flavor in drm_vblank_get() ville.syrjala
2014-02-26 19:24   ` [Intel-gfx] " Jesse Barnes
2014-02-21 19:03 ` [PATCH 2/5] drm: Make the vblank disable timer per-crtc ville.syrjala
2014-02-26 19:32   ` Jesse Barnes
2014-02-21 19:03 ` [PATCH 3/5] drm: Allow the driver to reject vblank requests only when it really has the vblank interrupts disabled ville.syrjala
2014-02-26 19:41   ` Jesse Barnes
2014-03-04  9:24   ` Daniel Vetter
2014-03-05 12:38     ` Ville Syrjälä
2014-03-05 13:55       ` Daniel Vetter
2014-02-21 19:03 ` [PATCH 4/5] drm: Allow reenabling of vblank interrupts even if refcount>0 ville.syrjala
2014-02-26 19:44   ` Jesse Barnes
2014-03-04  9:16   ` Daniel Vetter
2014-03-05 12:33     ` Ville Syrjälä
2014-02-21 19:03 ` [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races ville.syrjala
2014-02-24  3:48   ` Michel Dänzer
2014-02-24 12:11     ` Ville Syrjälä
2014-02-25  2:58       ` Michel Dänzer
2014-02-26 19:48         ` Jesse Barnes [this message]
2014-03-04  9:13         ` Daniel Vetter
2014-05-28  9:12           ` Michel Dänzer
2014-05-28 11:19             ` [Intel-gfx] " Ville Syrjälä
2014-05-29  4:11               ` Michel Dänzer
2014-05-29 10:56                 ` Daniel Vetter
2014-05-30  3:13                   ` Michel Dänzer
2014-02-28  8:56   ` Ville Syrjälä
2014-03-04  9:15     ` Daniel Vetter

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=20140226114846.64304e77@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=michel@daenzer.net \
    /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