All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/3] drm: Send pending vblank events before disabling vblank.
Date: Wed, 27 Apr 2011 19:17:42 +1000	[thread overview]
Message-ID: <1303895862.15750.18.camel@Ed> (raw)
In-Reply-To: <1303895309.5633.137.camel@thor.local>


[-- Attachment #1.1: Type: text/plain, Size: 1796 bytes --]

On Wed, 2011-04-27 at 11:08 +0200, Michel Dänzer wrote:
> On Mit, 2011-04-27 at 18:58 +1000, Christopher James Halse Rogers
> wrote: 
> > On Wed, 2011-04-27 at 10:32 +0200, Michel Dänzer wrote:
> > > On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers@canonical.com wrote:
> > > > From: Christopher James Halse Rogers <christopher.halse.rogers@canonical.com>
> > > > 
> > > > This is the least-bad behaviour.  It means that we signal the
> > > > vblank event before it actually happens, but since we're disabling
> > > > vblanks there's no guarantee that it will *ever* happen otherwise.
> > > 
> > > This may indeed be the best we can do for events that are pending when
> > > the CRTC is disabled[0], but I can't see anything that would prevent new
> > > events from getting scheduled (or synchronous vblank waits from timing
> > > out) while the CRTC is disabled?
> > > 
> > > [0] Though it might unnecessarily send events prematurely when the CRTC
> > > is just disabled temporarily, e.g. as part of a modeset.
> > > 
> > > 
> > > Also, this patch won't seem to help at all for other drivers which don't
> > > call drm_vblank_off() directly when disabling a CRTC.
> > 
> > This is true.  On the other hand, the other drivers don't wedge the
> > vblank code into a state where vblanks cannot be re-enabled.  So it's
> > only a problem when disabling one of 2+ monitors on those drivers,
> 
> And with DPMS?
> 

Possibly.  Since vblanks aren't wedged off in this case it's more likely
that the user turning the monitors back on will result in a vblank irq,
which will kick everything back into correct operation.

I've not managed to trigger this on my radeon system in the same way as
my intel systems, but I haven't stressed it as hard either.


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2011-04-27  9:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-27  6:10 [PATCH 1/3] drm: Send pending vblank events before disabling vblank christopher.halse.rogers
2011-04-27  6:10 ` [PATCH 2/3] drm: Warn if vblank state has become inconsistent christopher.halse.rogers
2011-04-27  8:38   ` Michel Dänzer
2011-04-27  6:10 ` [PATCH 3/3] drm: Factor-out drm_emit_vblank_event code christopher.halse.rogers
2011-04-27  8:36   ` Michel Dänzer
2011-04-27  8:48     ` Christopher James Halse Rogers
2011-04-27  9:06       ` Michel Dänzer
2011-04-28 20:36   ` Jesse Barnes
2011-04-29  3:57     ` [PATCH] drm: Factor-out drm_emit_vblank_event code. (v2) christopher.halse.rogers
2011-04-29  6:43       ` Michel Dänzer
2011-04-29 15:55       ` Marcin Slusarz
2011-05-01 23:55         ` Christopher James Halse Rogers
2011-05-02  0:09         ` [PATCH] drm: Factor-out drm_emit_vblank_event code. (v3) christopher.halse.rogers
2011-04-27  8:32 ` [PATCH 1/3] drm: Send pending vblank events before disabling vblank Michel Dänzer
2011-04-27  8:58   ` Christopher James Halse Rogers
2011-04-27  9:08     ` Michel Dänzer
2011-04-27  9:17       ` Christopher James Halse Rogers [this message]
2011-04-28  8:09       ` Christopher James Halse Rogers
2011-04-28 20:46         ` Jesse Barnes
2011-04-28 20:53           ` Jesse Barnes
2011-04-28 20:42   ` Jesse Barnes
2011-04-28 20:34 ` Jesse Barnes

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=1303895862.15750.18.camel@Ed \
    --to=christopher.halse.rogers@canonical.com \
    --cc=dri-devel@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 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.