On Friday, January 30, 2009 9:26 am Jesse Barnes wrote:
> But maybe there's an even simpler way to handle this (the wait on disabled
> pipe/irq problem). The DRM_WAIT_ON already checks if irqs are disabled
> before waiting (or at least it's supposed to), and the vblank_get call will
> check to make sure the pipe is enabled before waiting... maybe one of those
> checks is failing in this case, or we're not waking clients up at IRQ
> disable time like we should. I'll do some more testing and see.
Since in the VT switch case at least, userspace is calling in with a stale
vblank value (one much smaller than the current count), another option would
be something like the below. Needs to be a bit smarter to deal with counter
wraparound though, but OTOH wraparound wouldn't happen as often if our
drm_update_vblank_count() wasn't so eager to add ~max_frame_count to the
counter at enable time.
--
Jesse Barnes, Intel Open Source Technology Center
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 69aa0ab..801cdc4 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -590,9 +590,8 @@ int drm_wait_vblank(struct drm_device *dev, void *data,
vblwait->request.sequence, crtc);
dev->last_vblank_wait[crtc] = vblwait->request.sequence;
DRM_WAIT_ON(ret, dev->vbl_queue[crtc], 3 * DRM_HZ,
- (((drm_vblank_count(dev, crtc) -
- vblwait->request.sequence) <= (1 << 23)) ||
- !dev->irq_enabled));
+ (drm_vblank_count(dev, crtc) >=
+ vblwait->request.sequence) || !dev->irq_enabled);
if (ret != -EINTR) {
struct timeval now;
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
