From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 1/3] drm: Send pending vblank events before disabling vblank. Date: Thu, 28 Apr 2011 13:53:26 -0700 Message-ID: <20110428135326.00a5c886@jbarnes-desktop> References: <1303884659-739-1-git-send-email-christopher.halse.rogers@canonical.com> <1303893156.5633.126.camel@thor.local> <1303894719.15750.13.camel@Ed> <1303895309.5633.137.camel@thor.local> <1303978198.7048.28.camel@Ed> <20110428134630.6e60fe48@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy4-pub.bluehost.com (oproxy4-pub.bluehost.com [69.89.21.11]) by gabe.freedesktop.org (Postfix) with SMTP id B29A79E73D for ; Thu, 28 Apr 2011 13:53:31 -0700 (PDT) In-Reply-To: <20110428134630.6e60fe48@jbarnes-desktop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Cc: Michel =?ISO-8859-1?B?RORuemVy?= , dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Thu, 28 Apr 2011 13:46:30 -0700 Jesse Barnes wrote: > On Thu, 28 Apr 2011 18:09:58 +1000 > Christopher James Halse Rogers > wrote: > > 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. > > Yeah, unfortunately the vblank code pre-dates the KMS code by quite a > bit, so the IDs don't match. > > But with the events emitted as in your previous patch, this should be a > harder case to hit, but it sounds like we need to make sure the flip > waits are dealt with too to avoid this from triggering at all on > Intel. Or did you see other cases where the refcount was nonzero at > this point? Actually it looks like we wait for any outstanding flips before disabling so that seems correct (though I didn't check the locking, it's possible we could race a completion and a new flip if the flip ioctl and the dpms code don't exclude each other). -- Jesse Barnes, Intel Open Source Technology Center