From e38749ebe5ece08ec63dfd37aca28108ad5cc7ab Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= Date: Wed, 5 Dec 2007 14:43:22 -0500 Subject: Remove references to the sarea_priv perf_boxes field. This field isn't touched or read by any other code in the stack so it's time to retire these last few references. --- shared-core/i915_irq.c | 2 -- 1 file changed, 2 deletions(-) (limited to 'shared-core/i915_irq.c') diff --git a/shared-core/i915_irq.c b/shared-core/i915_irq.c index 2c699ecd..e7f3b083 100644 --- a/shared-core/i915_irq.c +++ b/shared-core/i915_irq.c @@ -417,8 +417,6 @@ static int i915_wait_irq(struct drm_device * dev, int irq_nr) if (READ_BREADCRUMB(dev_priv) >= irq_nr) return 0; - dev_priv->sarea_priv->perf_boxes |= I915_BOX_WAIT; - i915_user_irq_on(dev_priv); DRM_WAIT_ON(ret, dev_priv->irq_queue, 3 * DRM_HZ, READ_BREADCRUMB(dev_priv) >= irq_nr); -- cgit v1.2.3 From bfc29606e4a818897eebca46a5e23bbe7bc3ce25 Mon Sep 17 00:00:00 2001 From: Jesse Barnes Date: Fri, 7 Dec 2007 14:24:45 -0800 Subject: Fix pipe<->plane mapping vs. vblank handling (again) If drmMinor >= 6, the intel DDX driver will enable vblank events on both pipes. If drmMinor >= 10 on pre-965 chipsets, the intel DDX driver will swap the pipe<->plane mapping to allow for framebuffer compression on laptop screens. This means the secondary vblank counter (corresponding to pipe B) will be incremented when vblank interrupts occur. Now Mesa waits for vblank events on whichever plane has a greater portion of the displayed window. So it will happly ask to wait for the primary counter even though that one won't increment. So we can fix this in either the DDX driver, Mesa or the kernel (though I thought we already had several times). Since current (and previous) userspace assumes it's talking about a pipe == plane situation and now uses planes when talking to the kernel, we should probably just hide the mapping details there (indeed they already are hidden there for vblank swaps), which this patch does. So as far as userland is concerned, whether we call things planes or pipes is irrelevant, as long as kernel developers understand that userland hands them planes and they have to figure out which pipe that corresponds to (which will typically be the same on 965+ hardware and reversed on pre-965 mobile chips). --- shared-core/i915_irq.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) (limited to 'shared-core/i915_irq.c') diff --git a/shared-core/i915_irq.c b/shared-core/i915_irq.c index e7f3b083..ee7c40b5 100644 --- a/shared-core/i915_irq.c +++ b/shared-core/i915_irq.c @@ -456,12 +456,25 @@ static int i915_driver_vblank_do_wait(struct drm_device *dev, int i915_driver_vblank_wait(struct drm_device *dev, unsigned int *sequence) { - return i915_driver_vblank_do_wait(dev, sequence, &dev->vbl_received); + atomic_t *counter; + + if (i915_get_pipe(dev, 0) == 0) + counter = &dev->vbl_received; + else + counter = &dev->vbl_received2; + return i915_driver_vblank_do_wait(dev, sequence, counter); } int i915_driver_vblank_wait2(struct drm_device *dev, unsigned int *sequence) { - return i915_driver_vblank_do_wait(dev, sequence, &dev->vbl_received2); + atomic_t *counter; + + if (i915_get_pipe(dev, 1) == 0) + counter = &dev->vbl_received; + else + counter = &dev->vbl_received2; + + return i915_driver_vblank_do_wait(dev, sequence, counter); } /* Needs the lock as it touches the ring. -- cgit v1.2.3