From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH 1/3] drm: Send pending vblank events before disabling
	vblank.
Date: Thu, 28 Apr 2011 13:42:26 -0700
Message-ID: <20110428134226.21fe7627@jbarnes-desktop>
References: <1303884659-739-1-git-send-email-christopher.halse.rogers@canonical.com>
	<1303893156.5633.126.camel@thor.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Return-path: <dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org>
Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com
	[66.147.249.253])
	by gabe.freedesktop.org (Postfix) with SMTP id 54E709F4EC
	for <dri-devel@lists.freedesktop.org>;
	Thu, 28 Apr 2011 13:42:30 -0700 (PDT)
In-Reply-To: <1303893156.5633.126.camel@thor.local>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/dri-devel>,
	<mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org
To: Michel =?ISO-8859-1?B?RORuemVy?= <michel@daenzer.net>
Cc: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org

On Wed, 27 Apr 2011 10:32:36 +0200
Michel D=E4nzer <michel@daenzer.net> wrote:

> On Mit, 2011-04-27 at 16:10 +1000, christopher.halse.rogers@canonical.com=
 wrote:
> > From: Christopher James Halse Rogers <christopher.halse.rogers@canonica=
l.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.

We should return -EINVAL in that case from drm_wait_vblank due to
drm_vblank_get failing (i.e. the driver enable_vblank hook should fail
if the corresponding crtc is off).  At least that's how it's supposed
to work.

-- =

Jesse Barnes, Intel Open Source Technology Center