[Intel-gfx] [PATCH] drm/i915: enable DOP level clock gating

Rebased after new intel_pm split. This needs testing from QA to see how it impacts power consumption. Cc: "Zhang, Ouping" Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_reg.h |3 +++ drivers/gpu/drm/i915/intel_pm.c |4 2 files changed, 7 insertions(+) diff --git a/drive

Re: [Intel-gfx] [PATCH] drm/i915: re-add static qualifier to get_cxsr_latency

On Sat, Apr 21, 2012 at 18:17, Daniel Vetter wrote: > This got lost in the intel_pm.c move. > > Signed-off-by: Daniel Vetter > Yes, thanks for catching this! -- Eugeni Dodonov ___ Intel-gfx mailing list Intel-gfx@lists.

[Intel-gfx] [PATCH] drm/i915: re-add static qualifier to get_cxsr_latency

This got lost in the intel_pm.c move. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_pm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 36940a3..a2d2ce4 100644 --- a/drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH 0/9] i915 fixes for sparse warnings.

On Mon, Apr 16, 2012 at 02:07:39PM -0700, Ben Widawsky wrote: > Patch 1/2 is a mix of fairly trivial stuff. I see no reason to not take > these. > Patch 3-9 Are all __iomem related. These should run through some > regression testing. > > Most of the __iomem stuff fell into place fairly easily, but

Re: [Intel-gfx] [PATCH 09/10] drm/i915: wait render timeout ioctl

On Sat, 21 Apr 2012 09:12:17 -0700 Ben Widawsky wrote: > On Sat, 21 Apr 2012 10:41:55 +0100 > Chris Wilson wrote: > > > On Fri, 20 Apr 2012 18:23:31 -0700, Ben Widawsky > > wrote: > > > + ret = i915_seqno_wait_timed(ring, seqno, true, &timeout); > > > + if (ret == -ERESTARTSYS) > > > +

Re: [Intel-gfx] [PATCH 01/10] drm/i915: remove do_retire from i915_wait_request

On Sat, Apr 21, 2012 at 10:27:38AM -0700, Ben Widawsky wrote: > Just curious, it blows up on gen3 only? If not, how can I make it blow > up? I think you need the gpu fencing code to make it blow up, so gen2/3. Chris' refactoring might have changed some things in there and it doesn't blow up any lo

Re: [Intel-gfx] [PATCH 01/10] drm/i915: remove do_retire from i915_wait_request

On Sat, 21 Apr 2012 19:17:11 +0200 Daniel Vetter wrote: > On Fri, Apr 20, 2012 at 06:23:23PM -0700, Ben Widawsky wrote: > > This originates from a hack by me to quickly fix a bug in an earlier > > patch where we needed control over whether or not waiting on a seqno > > actually did any retire lis

Re: [Intel-gfx] [PATCH 01/10] drm/i915: remove do_retire from i915_wait_request

On Fri, Apr 20, 2012 at 06:23:23PM -0700, Ben Widawsky wrote: > This originates from a hack by me to quickly fix a bug in an earlier > patch where we needed control over whether or not waiting on a seqno > actually did any retire list processing. Since the two operations aren't > clearly related, w

Re: [Intel-gfx] [PATCH] drm/i915: Unconditionally initialise the interrupt workers

On Sat, 21 Apr 2012 19:01:11 +0200, Daniel Vetter wrote: > On Sat, Apr 21, 2012 at 07:00:24PM +0200, Daniel Vetter wrote: > > On Thu, Apr 19, 2012 at 07:41:49PM +0100, Chris Wilson wrote: > > > Rather than duplicate similar code across the IRQ installers, perform > > > the initialisation of the wo

Re: [Intel-gfx] [PATCH] drm/i915: Unconditionally initialise the interrupt workers

On Sat, Apr 21, 2012 at 07:00:24PM +0200, Daniel Vetter wrote: > On Thu, Apr 19, 2012 at 07:41:49PM +0100, Chris Wilson wrote: > > Rather than duplicate similar code across the IRQ installers, perform > > the initialisation of the workers upfront. This will lead to simpler > > teardown and quiescen

Re: [Intel-gfx] [PATCH] drm/i915: Unconditionally initialise the interrupt workers

On Thu, Apr 19, 2012 at 07:41:49PM +0100, Chris Wilson wrote: > Rather than duplicate similar code across the IRQ installers, perform > the initialisation of the workers upfront. This will lead to simpler > teardown and quiescent code as we can assume that the workers have > been initialised. > >

Re: [Intel-gfx] [PATCH] drm/i915: Remove i915_gem_ringbuffer_(data|info) from debugfs

On Thu, Apr 19, 2012 at 05:55:23PM +0100, Chris Wilson wrote: > This was originally used as an attempt to diagnose GPU hangs, but was > never very reliable and superseded by the i915_error_state capture on > hangcheck. It now lies languishing unused and unwanted. > > Signed-off-by: Chris Wilson Q

Re: [Intel-gfx] [PATCH] drm/i915/sprite: Avoid incurring extra vblank stall when updating plane on IVB

On Wed, Apr 18, 2012 at 09:23:46AM -0700, Jesse Barnes wrote: > On Wed, 18 Apr 2012 17:12:26 +0100 > Chris Wilson wrote: > > > IvyBridge requires an extra frame between disabling the low power > > watermarks and enabling scaling on the sprite plane. If the scaling > > is already enabled, then we

Re: [Intel-gfx] [PATCH] drm/i915: print computed bpp in dp link configuration

On Fri, Apr 20, 2012 at 08:23:49PM +0200, Daniel Vetter wrote: > Pretty useful to debug our DP bandwidth woes. > > v2: Also print out the required and available link bandwidth, > suggested by Chris Wilson. > > v3: Also print out the input parameters so that diagnosing failures to > find a valid d

[Intel-gfx] Updated -next

Hi all, Highlights: - More gmbus patches from Daniel Kurtz, I think gmbus is now ready, all known issues fixed. - Fencing cleanup and pipelined fencing removal from Chris. - rc6 residency interface from Ben, useful for powertop. - Cleanups and code reorg around the ringbuffer code (Ben&me). - Us

[Intel-gfx] [PATCH 01/17] drm/i915: Remove the list of pinned inactive objects

Simplify object tracking by removing the inactive but pinned list. The only place where this was used is for counting the available memory, which is just as easy performed by checking all objects on the rare occasions it is required (application startup). For ease of debugging, we keep the reportin

[Intel-gfx] [PATCH 02/17] drm/i915: Remove the deferred-free list

The use of the mm_list by deferred-free breaks the following patches to extend the range of objects tracked. We can simplify things if we just make the unbind during free uninterrible. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 11 --- drivers/gpu/drm/i915/i915_d

[Intel-gfx] [PATCH 03/17] drm/i915: Track unbound pages

When dealing with a working set larger than the GATT, or even the mappable aperture when touching through the GTT, we end up with evicting objects only to rebind them at a new offset again later. Moving an object into and out of the GTT requires clflushing the pages, thus causing a double-clflush p

[Intel-gfx] [PATCH 04/17] drm/i915: Only pwrite through the GTT if there is space in the aperture

Avoid stalling and waiting for the GPU by checking to see if there is sufficient inactive space in the aperture for us to bind the buffer prior to writing through the GTT. If there is inadequate space we will have to stall waiting for the GPU, and incur overheads moving objects about. Instead, only

[Intel-gfx] [PATCH 05/17] drm/i915: Try harder to allocate an mmap_offset

Given the persistence of an offset for the lifetime of an object, itis easy to contemplate how the mmap space becomes badly fragmented to the point that further allocations fail with ENOSPC. Our only recourse at this point is to try to purge the objects to release some space and reattempt the alloc

[Intel-gfx] [PATCH 06/17] drm/i915/debugfs: Show (count, size) of purgeable objects in i915_gem_objects

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 452e5c7..84bd7e7 100644 --- a/drivers/gpu/drm/i915/i915_d

[Intel-gfx] [PATCH 08/17] drm: Introduce drm_mm_create_block()

To be used later to preallocate exact blocks of space from the range manager. Signed-off-by: Chris Wilson --- drivers/gpu/drm/drm_mm.c | 49 ++ include/drm/drm_mm.h |4 2 files changed, 53 insertions(+) diff --git a/drivers/gpu/drm/drm_

[Intel-gfx] [PATCH 09/17] drm/i915: Split the stolen handling for GEM out of i915_dma.c

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile |1 + drivers/gpu/drm/i915/i915_dma.c| 161 ++--- drivers/gpu/drm/i915/i915_drv.h|4 + drivers/gpu/drm/i915/i915_gem_stolen.c | 201 4 files change

[Intel-gfx] [PATCH 10/17] drm/i915: Move GEM initialisation from i915_dma.c to i915_gem.c

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_dma.c | 66 +-- drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/i915_gem.c | 64 + 3 files changed, 66 insertions(+), 65 deletions(-) diff --git a/

[Intel-gfx] [PATCH 11/17] drm/i915: Avoid clearing preallocated regions from the GTT

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h |2 ++ drivers/gpu/drm/i915/i915_gem_gtt.c | 32 +--- 2 files changed, 31 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 22736

[Intel-gfx] [PATCH 07/17] drm/i915/tv: fix open-coded ARRAY_SIZE.

From: Dave Airlie Signed-off-by: Dave Airlie Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_tv.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c index ca12c70..67f44

[Intel-gfx] [PATCH 12/17] drm/i915: Always use the scatterlists if available for GTT insertion

If we have created a scatterlist for the physical mapping of the object, simply use it. This facilitates the later insertion of stolen objects into the GATT which are not backed by struct page. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_gtt.c | 19 --- 1 file

[Intel-gfx] [PATCH 13/17] drm/i915: Tidy handling of the scatterlist by ppgtt

Check to see if we've reached the end before dereferencing to get the next scatterlist. This helps when creating scatterlists by hand. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_gtt.c |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/dr

[Intel-gfx] [PATCH 14/17] drm/i915: Delay allocation of stolen space for FBC

As we may wish to wrap regions preallocated by the BIOS, we need to do that before carving out contiguous chunks of stolen space for FBC. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h|1 + drivers/gpu/drm/i915/i915_gem_stolen.c | 65 ---

[Intel-gfx] [PATCH 17/17] drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_dma.c |4 ++ drivers/gpu/drm/i915/intel_display.c |3 - drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_fb.c | 121 -- 4 files changed, 122 insertions(+), 7 delet

[Intel-gfx] [PATCH 15/17] drm/i915: Introduce i915_gem_object_create_for_stolen()

Wrap a preallocated region of stolen memory within an ordinary GEM object. (For example for preserving the BIOS framebuffer.) In order to hide that the object has no backing struct pages, we create a fake dma mapping for the contiguous physical allocation. Signed-off-by: Chris Wilson --- driver

[Intel-gfx] [PATCH 16/17] drm/i915: Split the framebuffer_info creation into a separate routine

This will be shared with wrapping the BIOS framebuffer into the fbdev later. In the meantime, we can tidy the code slightly and improve the error path handling. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_fb.c | 125 +-- 1 file changed, 69 inse

[Intel-gfx] [RFC] Preserve stolen objects across initialisation

The goal of this series is to introduce a GEM object that is backend by stolen memory and able to wrap preallocated objects before we have fully initialised GEM. And then to keep those objects around as we do intialise GEM for continued use afterwards. This patchset is slightly larger than strictl

Re: [Intel-gfx] [PATCH 04/10] drm/i915: drop polled waits from i915_wait_request

On Sat, 21 Apr 2012 10:29:35 +0100 Chris Wilson wrote: > On Fri, 20 Apr 2012 18:23:26 -0700, Ben Widawsky > wrote: > > The only time irq_get should fail is during unload or suspend. Both > > of these points should try to quiesce the GPU before disabling > > interrupts and so the atomic polling s

Re: [Intel-gfx] [PATCH 09/10] drm/i915: wait render timeout ioctl

On Sat, 21 Apr 2012 10:41:55 +0100 Chris Wilson wrote: > On Fri, 20 Apr 2012 18:23:31 -0700, Ben Widawsky > wrote: > > + ret = i915_seqno_wait_timed(ring, seqno, true, &timeout); > > + if (ret == -ERESTARTSYS) > > + ret = -EINTR; > Don't convert it here, pass ERESTARTSYS to the sys

[Intel-gfx] [PATCH 2/2] drm/i915: Only the zap the VMA after updating the tiling parameters

If we fail to unbind and so abort the change in tiling, we will have removed the VMA for the object for no reason. The likelihood of unbind failing is slim (other than ERESTARTSYS which will cause userspace to try again), so the change is mostly for the principle. Also improve the slightly stale c

[Intel-gfx] [PATCH 1/2] drm/i915: Clarify the semantics of tiling-changed by renaming it

Rename obj->tiling_changed to obj->fence_dirty so that it is clear that it flags when the parameters for an active fence (including the no-fence) register are changed. v2: Use fence_dirty to better express what the flag tracks and add a few more details to the comments to serve as a reminder of ho

Re: [Intel-gfx] [PATCH 09/10] drm/i915: wait render timeout ioctl

On Fri, 20 Apr 2012 18:23:31 -0700, Ben Widawsky wrote: > + ret = i915_seqno_wait_timed(ring, seqno, true, &timeout); > + if (ret == -ERESTARTSYS) > + ret = -EINTR; Don't convert it here, pass ERESTARTSYS to the system call handler which decides how to handle it. > + else

Re: [Intel-gfx] [PATCH 04/10] drm/i915: drop polled waits from i915_wait_request

On Fri, 20 Apr 2012 18:23:26 -0700, Ben Widawsky wrote: > The only time irq_get should fail is during unload or suspend. Both of > these points should try to quiesce the GPU before disabling interrupts > and so the atomic polling should never occur. > > This was recommended by Chris Wilson as a w

Re: [Intel-gfx] [PATCH 02/10] drm/i915: move vbetool invoked ier stuff

On Fri, 20 Apr 2012 18:23:24 -0700, Ben Widawsky wrote: > This extra bit of interrupt enabling code doesn't belong in the wait > seqno function. If anything we should pull it out to a helper so the > throttle code can also use it. The history is a bit vague, but I am > going to attempt to just dum