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: Thu, 28 Apr 2011 18:09:58 +1000	[thread overview]
Message-ID: <1303978198.7048.28.camel@Ed> (raw)
In-Reply-To: <1303895309.5633.137.camel@thor.local>


[-- Attachment #1.1: Type: text/plain, Size: 2548 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?
> 
> > whereas it's easily triggerable on single monitor systems on intel. 
> 
> Anyway, this patch is probably good at least as a preliminary fix for
> the inconsistent vblank state with the intel driver.
> 
> 
> > > Maybe it would be possible to move those calls to core code, and/or only
> > > force sending out events when the CRTC isn't just getting disabled
> > > temporarily.
> > > 
> > 
> > As in: have the core modesetting code call drm_vblank_off before making
> > the driver-specific calls when disabling a crtc?  I'll look into it -
> > that would appear to be a more general solution.
> 
> Yeah, something like that, thanks.
> 

Ok.  This appears to be surprisingly difficult.  Particularly, the
vblank code indexes crtcs based on the driver-private numbering, and
there doesn't appear to be a generic interface to grab this number;
Intel uses the DRM_IOCTL_I915_GET_PIPE_FROM_CRTC_ID ioctl, radeon uses
something different.

I'll see what I can come up with, but I don't think I'm sufficiently
familiar with the kms code to quickly come up with a nice API.


[-- 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

  parent reply	other threads:[~2011-04-28  8:10 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
2011-04-28  8:09       ` Christopher James Halse Rogers [this message]
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=1303978198.7048.28.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.