Re: [Intel-gfx] i915_init takes a full second of kernel init time

On Tue, Dec 13, 2011 at 2:21 PM, Chris Wilson wrote: > > On Tue, 13 Dec 2011 14:01:29 -0800, Jesse Barnes > wrote: > > We had some async code to take all of this out of the boot time > > critical path at least...  I thought Chris merged them long ago but I > > guess they were dropped.  Chris? >

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Adding 1080p modes to our TV Out mode list.

On Wed, 14 Dec 2011 21:10:08 -0200, Rodrigo Vivi wrote: > According to TV Out timing standards, supported 1080p modes were missing. Can you both here in the changelog and in comments a document reference so that we can easily find the right table again in future? -Chris -- Chris Wilson, Intel O

[Intel-gfx] [PATCH 3/3] drm/i915: Adding 1080p modes to our TV Out mode list.

According to TV Out timing standards, supported 1080p modes were missing. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_tv.c | 72 +++ 1 files changed, 72 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/

[Intel-gfx] [PATCH 2/3] drm/i915: Removing TV Out modes.

These modes are no longer needed or are not according to TV timing standards. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_tv.c | 122 --- 1 files changed, 0 insertions(+), 122 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers

[Intel-gfx] [PATCH 1/3] drm/i915: Fix TV Out refresh rate.

TV Out refresh rate was half of the specification for almost all modes. Due to this reason pixel clock was so low for some modes causing flickering screen. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_tv.c | 16 1 files changed, 8 insertions(+), 8 deletions(-)

[Intel-gfx] [PATCH 0/3] TV Out patches to make our mode list be according to TV timing standards

Hi all, The following patches makes the TV Out mode list be according to timing table specification from TV standards. The first one of the list fixes the https://bugs.freedesktop.org/show_bug.cgi?id=23899 When I start looking at this bug I was so focused on the pixel clock that I didn't notic

Re: [Intel-gfx] [PATCH 1/4] drm/i915: add a LLC feature flag in device description

On Wed, 14 Dec 2011 00:33:01 -0200 Eugeni Dodonov wrote: > From: Eugeni Dodonov > > LLC is not SNB-specific, so we should check for it in a more generic way. > > v2: export LLC support status via debugfs. > > Signed-off-by: Eugeni Dodonov I like it. Reviewed-by: Jesse Barnes -- Jesse Ba

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Force sync command ordering (Gen6+)

On Thu, 08 Dec 2011 18:35:24 -0800 Eric Anholt wrote: > Since MI_FLUSH_DW exists on gen6, and keithp says we still have > outstanding issues with missed blit IRQs there, I started trying it > today. Two kernel branches posted at > git://people.freedesktop.org/~anholt/linux/ > > flush-dw-notify:

Re: [Intel-gfx] [PATCH 23/43] drm/i915: multithreaded forcewake is an ivb+ feature

On Wed, 14 Dec 2011 13:57:20 +0100, Daniel Vetter wrote: > Name the function accordingly. Suggested by Chris Wilson. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Eugeni Dodonov Reviewed-by: Eric Anholt pgpcyRf969Ipb.pgp Description: PGP signature

Re: [Intel-gfx] [PATCH] [RFC] LLC and per-BO cache handling

On Wed, 14 Dec 2011 00:33:00 -0200, Eugeni Dodonov wrote: > With base on comments and feedback on LLC handling from Daniel Vetter, Chris > Wilson and Ben Widawsky, I reworked my patch into a more useful approach for > detecting presence of different cache levels from userspace. > > So, in this co

Re: [Intel-gfx] kernel BUG at drivers/gpu/drm/i915/i915_gem

On Wed, Dec 14, 2011 at 02:47:33 +0100, Daniel Vetter wrote: > On Mon, Dec 12, 2011 at 10:16, Rocko Requin wrote: > >> If you can wire up netconsole you should be able to gather the full > >> backtrace and that would be really useful. Otherwise can you please > >> confirm by reverting that commit

Re: [Intel-gfx] [PATCH 4/4] drm/i915: drpc debugfs update for gen6

On Tue, Dec 13, 2011 at 17:37, Jesse Barnes wrote: > On Mon, 12 Dec 2011 19:22:00 -0800 > Ben Widawsky wrote: > > > Many of the old fields from Ironlake have gone away. Strip all those > > fields, and try to update to fields people care about. RC information > > isn't exactly ideal anymore. All w

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Update GEN6_RP_CONTROL definitions

On Tue, Dec 13, 2011 at 01:21, Ben Widawsky wrote: > This matches the modern specs more accurately. > > This will be used by the following patch to fix the way we display RC > status. > > Signed-off-by: Ben Widawsky > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov

Re: [Intel-gfx] [PATCH 22/43] drm/i915: prevent division by zero when asking for chipset power

On 12/14/2011 04:57 AM, Daniel Vetter wrote: > From: Eugeni Dodonov > > This prevents an in-kernel division by zero which happens when we are > asking for i915_chipset_val too quickly, or within a race condition > between the power monitoring thread and userspace accesses via debugfs. > > The is

Re: [Intel-gfx] [PATCH 40/43] drm/i915: ppgtt register definitions

On Wed, Dec 14, 2011 at 16:58, Eugeni Dodonov wrote: > On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > >> Signed-off-by: Daniel Vetter >> Reviewed-by: Ben Widawsky >> > > Reviewed-by: Eugeni Dodonov > Just clarifying - the R-b is for the ppgtt series. I think I also sent a Tested-by alr

Re: [Intel-gfx] [PATCH 15/43] drm/i915: add interface to simulate gpu hangs

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > gpu reset is a very important piece of our infrastructure. > Unfortunately we only really it test by actually hanging the gpu, > which often has bad side-effects for the entire system. And the gpu > hang handling code is one of the rather comp

Re: [Intel-gfx] [PATCH 42/43] drm/i915: per-ring fault reg

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > v2: Chris Wilson suggested to allocate the error_state with kzalloc > for better paranioa. Also kill existing spurious clears of the > error_state while at it. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Ben Widawsky > Reviewed-by: Eug

Re: [Intel-gfx] [PATCH 40/43] drm/i915: ppgtt register definitions

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > Signed-off-by: Daniel Vetter > Reviewed-by: Ben Widawsky > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 09/43] drm/i915: introduce a vtable for gpu core functions

On 12/14/2011 04:57 AM, Daniel Vetter wrote: > ... like for forcewake, which protects everything _but_ display. > Expect more things (like gtt abstractions, rings, inter-ring sync) > to come. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Eugeni Dodonov > --- > drivers/gpu/drm/i915/i915_drv.c

Re: [Intel-gfx] [PATCH 31/43] drm/i915: Use kcalloc instead of kzalloc to allocate array

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > From: Thomas Meyer > > The advantage of kcalloc is, that will prevent integer overflows which > could > result from the multiplication of number of elements and size and it is > also > a bit nicer to read. > > The semantic patch that makes th

Re: [Intel-gfx] [PATCH 28/43] drm/i915: Handle unmappable buffers during error state capture

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > From: Chris Wilson > > As the buffer is not necessarily accessible through the GTT at the time > of a GPU hang, and capturing some of its contents is far more valuable > than skipping it, provide a clflushed fallback read path. We still > pre

Re: [Intel-gfx] [PATCH 17/43] drm/i915: destroy existing error_state when simulating a gpu hang

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > This way we can simulate a bunch of gpu hangs and run the error_state > capture code every time (without the need to reload the module). > > Signed-Off-by: Daniel Vetter > Reviewed-by: Eugeni Dodonov -- Eugeni Dodonov

Re: [Intel-gfx] [PATCH 14/43] drm/i915: refactor debugfs create functions

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > All r/w debugfs files are created equal. > > v2: Add some newlines to make the code easier on the eyes as requested > by Ben Widawsky. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Ben Widawsky > Reviewed-by: Kenneth Graunke > Reviewed-b

Re: [Intel-gfx] [PATCH 05/43] drm/i915: collect more per ring error state

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > Based on a patch by Ben Widawsky, but with different colors > for the bikeshed. > > In contrast to Ben's patch this one doesn't add the fault regs. > Afaics they're for the optional page fault support which > - we're not enabling > - and which

Re: [Intel-gfx] [PATCH 04/43] drm/i915: refactor ring error state capture to use arrays

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > The code already got unwieldy and we want to dump more per-ring > registers. > > Only functional change is that we now also capture the video > ring registers on ilk. > > v2: fixup a refactor fumble spotted by Chris Wilson. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 03/43] drm/i915: switch ring->id to be a real id

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > ... and add a helpr function for the places where we want a flag. > > This way we can use ring->id to index into arrays. > > v2: Resurrect the missing beautification-space Chris Wilson noted. > I'm moving this space around because I'll reuse r

Re: [Intel-gfx] [PATCH 02/43] drm/i915: don't bail out of intel_wait_ring_buffer too early

On Wed, Dec 14, 2011 at 10:56, Daniel Vetter wrote: > In the pre-gem days with non-existing hangcheck and gpu reset code, > this timeout of 3 seconds was pretty important to avoid stuck > processes. > > But now we have the hangcheck code in gem that goes to great length > to ensure that the gpu i

Re: [Intel-gfx] [PATCH 16/43] drm/i915: rework dev->first_error locking

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > - reduce the irq disabled section, even for a debugfs file this was > way too long. > - always disable irqs when taking the lock. > > v2: Thou shalt not mistake locking for reference counting, so: > - reference count the error_state to protec

Re: [Intel-gfx] [PATCH 13/43] drm/i915: refactor debugfs open function

On Wed, Dec 14, 2011 at 10:57, Daniel Vetter wrote: > Only forcewake has an open with special semantics, the other r/w > debugfs only assign the file private pointer. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Ben Widawsky > Reviewed-by: Kenneth Graunke > Reviewed-by: Eugeni Dodonov --

Re: [Intel-gfx] [PATCH 43/43] drm/i915: enable ppgtt

On Wed, 14 Dec 2011 13:57:40 +0100, Daniel Vetter wrote: > v2: Don't try to enable ppgtt on pre-snb. > > Signed-off-by: Daniel Vetter > Reviewed-by: Ben Widawsky > --- > +void i915_gem_init_ppgtt(struct drm_device *dev) > +{ > + drm_i915_private_t *dev_priv = dev->dev_private; > + uint

Re: [Intel-gfx] [PATCH 27/43] drm/i915: flush overlay regfile writes

On Wed, 14 Dec 2011 13:57:24 +0100, Daniel Vetter wrote: > Better be paranoid. The wmb should flush the wc writes, and > the chipset_flush hopefully flushes any mch buffers. There've been a > few overlay hangs I've never really diagnosed, unfortunately all the > reporters disappeared. At which p

Re: [Intel-gfx] [PATCH 25/43] drm/i915: properly flush the wc buffer in pwrites to phys objects

On Wed, 14 Dec 2011 13:57:22 +0100, Daniel Vetter wrote: > Usually results in (rare) cursor corruptions on platforms > requiring physically addressed cursors. I have to admit that I am still puzzled as to how this has any effect at all given that call wbinvd afterwards. But if it makes 8xx happi

Re: [Intel-gfx] [PATCH 16/43] drm/i915: rework dev->first_error locking

On Wed, 14 Dec 2011 13:57:13 +0100, Daniel Vetter wrote: > - reduce the irq disabled section, even for a debugfs file this was > way too long. > - always disable irqs when taking the lock. > > v2: Thou shalt not mistake locking for reference counting, so: > - reference count the error_state to

Re: [Intel-gfx] [PATCH 13/43] drm/i915: refactor debugfs open function

On Wed, 14 Dec 2011 13:57:10 +0100, Daniel Vetter wrote: > Only forcewake has an open with special semantics, the other r/w > debugfs only assign the file private pointer. > > Signed-Off-by: Daniel Vetter > Reviewed-by: Ben Widawsky > Reviewed-by: Kenneth Graunke Reviewed-by: Chris Wilson -C

Re: [Intel-gfx] [PATCH 12/43] drm/i915: don't trash the gtt when running out of fences

On Wed, 14 Dec 2011 13:57:09 +0100, Daniel Vetter wrote: > With the fence accounting fixed up in the previous commit not finding > enough fences is a fatal error and userspace bug. Trashing the entire > gtt is not gonna turn up that missing fence, so don't to this by > returning another error tha

Re: [Intel-gfx] [PATCH 09/43] drm/i915: introduce a vtable for gpu core functions

On Wed, 14 Dec 2011 13:57:06 +0100, Daniel Vetter wrote: > ... like for forcewake, which protects everything _but_ display. > Expect more things (like gtt abstractions, rings, inter-ring sync) > to come. The only thing that looks odd is the layout in drm_i915_private is a little haphazard. Other

Re: [Intel-gfx] [PATCH 08/43] drm/i915: drop register special-casing in forcewake

On Wed, 14 Dec 2011 13:57:05 +0100, Daniel Vetter wrote: > We currently have 3 register for which we must not grab forcewake for: > FORCEWAKE, FROCEWAKE_MT and ECOBUS. > - FORCEWAKE is excluded in the NEEDS_FORCE_WAKE macro and accessed > with _NOTRACE. > - FORCEWAKE_MT is just accessed with _N

[Intel-gfx] [PATCH 15/43] drm/i915: add interface to simulate gpu hangs

gpu reset is a very important piece of our infrastructure. Unfortunately we only really it test by actually hanging the gpu, which often has bad side-effects for the entire system. And the gpu hang handling code is one of the rather complicated pieces of code we have, consisting of - hang detection

[Intel-gfx] [PATCH 43/43] drm/i915: enable ppgtt

v2: Don't try to enable ppgtt on pre-snb. Signed-off-by: Daniel Vetter Reviewed-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_drv.c |2 ++ drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/i915_gem.c | 39 +++ 3 files changed, 42 insertion

[Intel-gfx] [PATCH 42/43] drm/i915: per-ring fault reg

v2: Chris Wilson suggested to allocate the error_state with kzalloc for better paranioa. Also kill existing spurious clears of the error_state while at it. Signed-Off-by: Daniel Vetter Reviewed-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_debugfs.c |8 ++-- drivers/gpu/drm/i915/i915_d

[Intel-gfx] [PATCH 41/43] drm/i915: ppgtt debugfs info

Signed-off-by: Daniel Vetter Reviewed-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_debugfs.c | 38 +++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index aa305a6..c4f

[Intel-gfx] [PATCH 40/43] drm/i915: ppgtt register definitions

Signed-off-by: Daniel Vetter Reviewed-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_reg.h | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 51ec59d..2fa7dfa 100644 --- a/drivers/gpu/

[Intel-gfx] [PATCH 39/43] drm/i915: ppgtt binding/unbinding support

This adds support to bind/unbind objects and wires it up. Objects are only put into the ppgtt when necessary, i.e. at execbuf time. Objects are still unconditionally put into the global gtt. v2: Kill the quick hack and explicitly pass cache_level to ppgtt_bind like for the global gtt function. No

[Intel-gfx] [PATCH 38/43] drm/i915: initialization/teardown for the aliasing ppgtt

This just adds the setup and teardown code for the ppgtt PDE and the last-level pagetables, which are fixed for the entire lifetime, at least for the moment. v2: Kill the stray debug printk noted by and improve the pte definitions as suggested by Chris Wilson. v3: Clean up the aperture stealing c

[Intel-gfx] [PATCH 37/43] agp/intel-gtt: export the gtt pagetable iomapping

We need this because ppgtt page directory entries need to be in the global gtt pagetable. Signed-Off-by: Daniel Vetter Reviewed-by: Ben Widawsky --- drivers/char/agp/intel-gtt.c |1 + include/drm/intel-gtt.h |2 ++ 2 files changed, 3 insertions(+), 0 deletions(-) diff --git a/driv

[Intel-gfx] [PATCH 36/43] agp/intel-gtt: export the scratch page dma address

To implement a PPGTT for drm/i915 that fully aliases the GTT, we also need to properly alias the scratch page. Signed-Off-by: Daniel Vetter Reviewed-by: Ben Widawsky --- drivers/char/agp/intel-gtt.c |9 - include/drm/intel-gtt.h |2 ++ 2 files changed, 6 insertions(+), 5 de

[Intel-gfx] [PATCH 35/43] drm/i915: rewrite shmem_pread_slow to use copy_to_user

Like for shmem_pwrite_slow. The only difference is that because we read data, we can leave the fetched cachelines in the cpu: In the case that the object isn't in the cpu read domain anymore, the clflush for the next cpu read domain invalidation will simply drop these cachelines. slow_shmem_bit17_

[Intel-gfx] [PATCH 34/43] drm/i915: rewrite shmem_pwrite_slow to use copy_from_user

... instead of get_user_pages, because that fails on non page-backed user addresses like e.g. a gtt mapping of a bo. To get there essentially copy the vfs read path into pagecache. We can't call that right away because we have to take care of bit17 swizzling. To not deadlock with our own pagefault

[Intel-gfx] [PATCH 33/43] drm/i915: fall through pwrite_gtt_slow to the shmem slow path

The gtt_pwrite slowpath grabs the userspace memory with get_user_pages. This will not work for non-page backed memory, like a gtt mmapped gem object. Hence fall throuh to the shmem paths if we hit -EFAULT in the gtt paths. Now the shmem paths have exactly the same problem, but this way we only nee

[Intel-gfx] [PATCH 32/43] drm/i915: Avoid using mappable space for relocation processing through the CPU

From: Chris Wilson We try to avoid writing the relocations through the uncached GTT, if the buffer is currently in the CPU write domain and so will be flushed out to main memory afterwards anyway. Also on SandyBridge we can safely write to the pages in cacheable memory, so long as the buffer is L

[Intel-gfx] [PATCH 31/43] drm/i915: Use kcalloc instead of kzalloc to allocate array

From: Thomas Meyer The advantage of kcalloc is, that will prevent integer overflows which could result from the multiplication of number of elements and size and it is also a bit nicer to read. The semantic patch that makes this change is available in https://lkml.org/lkml/2011/11/25/107 Signed

[Intel-gfx] [PATCH 30/43] drm/i915: reject GTT domain in relocations

This confuses our domain tracking and can (for gtt write domains) lead to a subsequent oops. Tested by tests/gem_exec_bad_domains from i-g-t. Signed-Off-by: Daniel Vetter Reviewed-by: Eric Anholt Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c |5 +++-- 1 files ch

[Intel-gfx] [PATCH 29/43] drm/i915: remove the i915_batchbuffer_info debugfs file

With the error_state facility in place, this has outlived it's usefulness. It also oopses with the lates llc-reloc patches because it directly access objects through the gtt without any checks. Signed-Off-by: Daniel Vetter Reviewed-by: Chris Wilson Reviewed-by: Eugeni Dodonov --- drivers/gpu/d

[Intel-gfx] [PATCH 28/43] drm/i915: Handle unmappable buffers during error state capture

From: Chris Wilson As the buffer is not necessarily accessible through the GTT at the time of a GPU hang, and capturing some of its contents is far more valuable than skipping it, provide a clflushed fallback read path. We still prefer to read through the GTT as that is more consistent with the G

[Intel-gfx] [PATCH 26/43] drm/i915: Only clear the GPU domains upon a successful finish

From: Chris Wilson By clearing the GPU read domains before waiting upon the buffer, we run the risk of the wait being interrupted and the domains prematurely cleared. The next time we attempt to wait upon the buffer (after userspace handles the signal), we believe that the buffer is idle and so s

[Intel-gfx] [PATCH 27/43] drm/i915: flush overlay regfile writes

Better be paranoid. The wmb should flush the wc writes, and the chipset_flush hopefully flushes any mch buffers. There've been a few overlay hangs I've never really diagnosed, unfortunately all the reporters disappeared. Maybe-related: https://bugs.freedesktop.org/show_bug.cgi?id=33309 Signed-Off-

[Intel-gfx] [PATCH 25/43] drm/i915: properly flush the wc buffer in pwrites to phys objects

Usually results in (rare) cursor corruptions on platforms requiring physically addressed cursors. Cc: sta...@kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35460 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=21442 Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 24/43] drm/i915: capture error_state also for stuck rings

Since quite a while we also the basic output configuration in the error_state, so it should contain enough information to diagnose these MI_WAIT hangs. Signed-Off-by: Daniel Vetter Reviewed-and-tested-by: Chris Wilson Reviewed-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_irq.c |3 +--

[Intel-gfx] [PATCH 23/43] drm/i915: multithreaded forcewake is an ivb+ feature

Name the function accordingly. Suggested by Chris Wilson. Signed-Off-by: Daniel Vetter Reviewed-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_drv.c |4 ++-- drivers/gpu/drm/i915/i915_drv.h |4 ++-- drivers/gpu/drm/i915/intel_display.c |8 3 files changed, 8 ins

[Intel-gfx] [PATCH 22/43] drm/i915: prevent division by zero when asking for chipset power

From: Eugeni Dodonov This prevents an in-kernel division by zero which happens when we are asking for i915_chipset_val too quickly, or within a race condition between the power monitoring thread and userspace accesses via debugfs. The issue can be reproduced easily via the following command: whi

[Intel-gfx] [PATCH 21/43] drm/i915: add gen6+ registers to i915_swizzle_info

Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 3eab427..5ab7784 100644 --- a/drivers/gpu/drm/i915/i915_debug

[Intel-gfx] [PATCH 20/43] drm/i915: swizzling support for snb/ivb

We have to do this manually. Somebody had a Great Idea. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_dma.c|2 +- drivers/gpu/drm/i915/i915_drv.c|4 ++- drivers/gpu/drm/i915/i915_drv.h|3 +- drivers/gpu/drm/i915/i915_gem.c| 23 ++

[Intel-gfx] [PATCH 19/43] drm/i915: add debugfs file for swizzling information

This will also come handy for the gen6+ swizzling support, where the driver is supposed to control swizzling depending upon dram configuration. v2: CxDRB3 are 16 bit regs! Noticed by Chris Wilson. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 50 ++

[Intel-gfx] [PATCH 18/43] drm/i915: fix swizzle detection for gen3

It looks like the desktop variants of i915 and i945 also have the DCC register to control dram channel interleave and cpu side bit6 swizzling. Unfortunately internal Cspec/ConfigDB documentation for these ancient chips have already been dropped and there seem to be no archives. Also somebody thoug

[Intel-gfx] [PATCH 17/43] drm/i915: destroy existing error_state when simulating a gpu hang

This way we can simulate a bunch of gpu hangs and run the error_state capture code every time (without the need to reload the module). Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i9

[Intel-gfx] [PATCH 16/43] drm/i915: rework dev->first_error locking

- reduce the irq disabled section, even for a debugfs file this was way too long. - always disable irqs when taking the lock. v2: Thou shalt not mistake locking for reference counting, so: - reference count the error_state to protect from concurent freeeing. This will be only really used in th

[Intel-gfx] [PATCH 14/43] drm/i915: refactor debugfs create functions

All r/w debugfs files are created equal. v2: Add some newlines to make the code easier on the eyes as requested by Ben Widawsky. Signed-Off-by: Daniel Vetter Reviewed-by: Ben Widawsky Reviewed-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_debugfs.c | 55 +++--

[Intel-gfx] [PATCH 13/43] drm/i915: refactor debugfs open function

Only forcewake has an open with special semantics, the other r/w debugfs only assign the file private pointer. Signed-Off-by: Daniel Vetter Reviewed-by: Ben Widawsky Reviewed-by: Kenneth Graunke --- drivers/gpu/drm/i915/i915_debugfs.c | 26 +- 1 files changed, 5 inser

[Intel-gfx] [PATCH 12/43] drm/i915: don't trash the gtt when running out of fences

With the fence accounting fixed up in the previous commit not finding enough fences is a fatal error and userspace bug. Trashing the entire gtt is not gonna turn up that missing fence, so don't to this by returning another error thatn ENOSPC. This has the added benefit that it's easier to distingu

[Intel-gfx] [PATCH 11/43] drm/i915: Separate fence pin counting from normal bind pin counting

From: Chris Wilson In order to correctly account for reserving space in the GTT and fences for a batch buffer, we need to independently track whether the fence is pinned due to a fenced GPU access in the batch or whether the buffer is pinned in the aperture. Currently we count the fenced as pinne

[Intel-gfx] [PATCH 10/43] drm/i915/ringbuffer: kill snb blt workaround

This was just to facilitate product enablement with pre-production hw. Allows us to kill quite a bit of cruft. Signed-off-by: Daniel Vetter Signed-off-by: Kenneth Graunke Reviewed-by: Eric Anholt --- drivers/gpu/drm/i915/intel_ringbuffer.c | 81 +-- 1 files change

[Intel-gfx] [PATCH 09/43] drm/i915: introduce a vtable for gpu core functions

... like for forcewake, which protects everything _but_ display. Expect more things (like gtt abstractions, rings, inter-ring sync) to come. Signed-Off-by: Daniel Vetter Reviewed-by: Eugeni Dodonov --- drivers/gpu/drm/i915/i915_drv.c |6 +++--- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH 08/43] drm/i915: drop register special-casing in forcewake

We currently have 3 register for which we must not grab forcewake for: FORCEWAKE, FROCEWAKE_MT and ECOBUS. - FORCEWAKE is excluded in the NEEDS_FORCE_WAKE macro and accessed with _NOTRACE. - FORCEWAKE_MT is just accessed with _NOTRACE. - ECOBUS is only excluded in the macro. In fear of an ever-g

[Intel-gfx] [PATCH 07/43] drm/i915: convert force_wake_get to func pointer in the gpu reset code

This was forgotten in the original multi-threaded forcewake conversion: commit 8d715f0024f64ad1b1be85d8c081cf577944c847 Author: Keith Packard Date: Fri Nov 18 20:39:01 2011 -0800 drm/i915: add multi-threaded forcewake support Signed-Off-by: Daniel Vetter Reviewed-by: Eugeni Dodonov ---

[Intel-gfx] [PATCH 06/43] drm/i915: protect force_wake_(get|put) with the gt_lock

The problem this patch solves is that the forcewake accounting necessary for register reads is protected by dev->struct_mutex. But the hangcheck and error_capture code need to access registers without grabbing this mutex because we hold it while waiting for the gpu. So a new lock is required. Becau

[Intel-gfx] [PATCH 05/43] drm/i915: collect more per ring error state

Based on a patch by Ben Widawsky, but with different colors for the bikeshed. In contrast to Ben's patch this one doesn't add the fault regs. Afaics they're for the optional page fault support which - we're not enabling - and which seems to be unsupported by the hw team. Recent bspec lacks tons

[Intel-gfx] [PATCH 04/43] drm/i915: refactor ring error state capture to use arrays

The code already got unwieldy and we want to dump more per-ring registers. Only functional change is that we now also capture the video ring registers on ilk. v2: fixup a refactor fumble spotted by Chris Wilson. Signed-off-by: Daniel Vetter Reviewed-by: Chris Wilson Signed-off-by: Ben Widawsky

[Intel-gfx] [PATCH 03/43] drm/i915: switch ring->id to be a real id

... and add a helpr function for the places where we want a flag. This way we can use ring->id to index into arrays. v2: Resurrect the missing beautification-space Chris Wilson noted. I'm moving this space around because I'll reuse ring_str in the next patch. Signed-off-by: Daniel Vetter Review

[Intel-gfx] [PATCH 02/43] drm/i915: don't bail out of intel_wait_ring_buffer too early

In the pre-gem days with non-existing hangcheck and gpu reset code, this timeout of 3 seconds was pretty important to avoid stuck processes. But now we have the hangcheck code in gem that goes to great length to ensure that the gpu is really dead before declaring it wedged. So there's no need for

[Intel-gfx] [PATCH 01/43] drm/i915: kicking rings stuck on semaphores considered harmful

If our semaphore logic gets confused and we have a ring stuck waiting for one, there's a decent chance it'll just execute garbage when being kicked. Also, kicking the ring obscures the place where the error first occured, making error_state decoding much harder. So drop this an let gpu reset handl

Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.

On Wed, 14 Dec 2011 19:44:34 +0800, "Zhigang Gong" wrote: > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Wednesday, December 14, 2011 7:12 PM > > To: Zhigang Gong > > Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com > > Subject: RE: [P

Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.

On Tue, 13 Dec 2011 22:31:41 +0800, zhigang.g...@linux.intel.com wrote: > From: Zhigang Gong > > This commit enable all the rest glamor rendering functions. > Tested with latest glamor master branch, can pass rendercheck. Sure enough, it passes rendercheck. Well done! However, glyph rendering i

Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, December 14, 2011 7:12 PM > To: Zhigang Gong > Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com > Subject: RE: [PATCH] uxa/glamor: Enable the rest glamor rendering > functions. > > On

Re: [Intel-gfx] [PATCH] uxa/glamor: Enable the rest glamor rendering functions.

On Wed, 14 Dec 2011 12:08:30 +0800, "Zhigang Gong" wrote: > > -Original Message- > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > > Sent: Wednesday, December 14, 2011 2:45 AM > > To: zhigang.g...@linux.intel.com > > Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@gmail.com; >

Re: [Intel-gfx] More crashes with intel driver 1.10.4 and corrupted stack traces for GM45

On Tue, 13 Dec 2011 19:05:34 -0800, Marc MERLIN wrote: > Since I'm a newbie at thie, there isn't a 'head' per se, and I see that > not all patches are production ready. > Could you point me on what I could sync from and that would be > reasonably likely to work? :) If you checkout the master bran