[PATCH] [drm/i915] Eliminate WARN calls from irq_handler on unexpected pipestat

pipestat can be set when iir is unset due to our ordering of pipestat and iir writes. Remove a WARN left when the code to always read pipestat was added. Signed-off-by: Keith Packard [EMAIL PROTECTED] --- drivers/gpu/drm/i915/i915_irq.c |8 1 files changed, 0 insertions(+), 8

Patch sequence to clear GTT and retry on -ENOMEM

This patch sequence adds the ability to retry pinning in execbuffer when one of the pin operations returns -ENOMEM. We unpin all of the buffers and then clear the GTT before trying again, with the hope that we'll eliminate any fragmentation this way. Along the way, there are patches which finish

[PATCH] [drm/i915] Rename object_set_domain to object_set_to_gpu_domain

Now that the CPU and GTT domain operations are isolated to their own functions, the previously general-purpose set_domain function is now used only to set GPU domains. It also has no failure cases, which is important as this eliminates any possible interruption of the computation of new object

[PATCH] [drm/i915] Retry execbuffer pinning after clearing the GTT

If we fail to pin all of the buffers in an execbuffer request, go through and clear the GTT and try again to see if its just a matter of fragmentation Signed-off-by: Keith Packard [EMAIL PROTECTED] --- drivers/gpu/drm/i915/i915_gem.c | 51 --- 1 files

[PATCH] [drm/i915] Move the execbuffer domain computations together

This eliminates the dev_set_domain function and just in-lines it where its used, with the goal of moving the manipulation and use of invalidate_domains and flush_domains closer together. This also avoids calling add_request unless some domain has been flushed. Signed-off-by: Keith Packard [EMAIL

[PATCH] [drm/i915] execbuffer pins objects, no need to ensure they're still in the GTT

Before we had the notion of pinning objects, we had a kludge around to make sure all of the objects were still resident in the GTT before we committed to executing a batch buffer. We don't need this any longer, and it sticks an error return in the middle of object domain computations that must be

[PATCH] [drm/i915] In execbuffer, split handle lookup and relocation

Splitting these will make re-trying the relocation cleaner Signed-off-by: Keith Packard [EMAIL PROTECTED] --- drivers/gpu/drm/i915/i915_gem.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index

[Bug 18631] [mi] EQ overflowing. The server is probably stuck in an infinite loop.

http://bugs.freedesktop.org/show_bug.cgi?id=18631 Renato Caldas [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED

Re: [Intel-gfx] [PATCH] [drm] Move drm vblank initialization/cleanup to driver load/unload

Hi I applied this patch on top of kernel 2.6.28-rc5 and I found that VT switch works under KDE4 with composite enabled. However, suspend to disk does not work. After resuming, I can only see a black screen and the cursor, which I can move. At that point, I can only ssh into the machine and

Re: Waiting for vblank vs VT switching

On Fri, 2008-11-21 at 23:14 +0200, Michel Dänzer wrote: No, radeon doesn't (un)install the IRQ handler on VT switch. It's not a matter of uninstalling the IRQ handler; the question is whether the hardware frame count gets reset at VT switch time. The i915 driver uses the hardware frame counter

Re: Waiting for vblank vs VT switching

On Tue, 2008-11-18 at 16:23 -0800, Keith Packard wrote: On Wed, 2008-11-19 at 00:44 +0200, Michel Dänzer wrote: On Wed, 2008-11-19 at 00:07 +0200, Michel Dänzer wrote: This is precisely what DRM_PRE/POST_MODESET are for. Assuming xf86-video-intel is calling them appropriately before

[Bug 12028] i915 DRM is broken in 2.6.28-rc4

http://bugzilla.kernel.org/show_bug.cgi?id=12028 --- Comment #4 from [EMAIL PROTECTED] 2008-11-21 19:26 --- I have an i915 mobo, specs and backtraces and other info found in the bugs I posted on freedesktop If I have more than 4 gigs of ram, X may display corrupted graphics and