[Intel-gfx] [PATCH 06/48] drm/i915: Handle inactivating objects for all VMAs

2013-12-06 Thread Ben Widawsky
This came from a patch called, drm/i915: Move active to vma When moving an object to the inactive list, we do it for all VMs for which the object is bound. The primary difference from that patch is this time around we don't not track 'active' per vma, but rather by object. Therefore, we only

[Intel-gfx] [PATCH 15/48] drm/i915: Simplify ring handling in execbuf

2013-12-06 Thread Ben Widawsky
Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 41 -- 1 file changed, 10 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index

[Intel-gfx] [PATCH 12/48] drm/i915: Remove vm arg from relocate entry

2013-12-06 Thread Ben Widawsky
The only place we were using it was for GEN6, which won't have PPGTT support anyway (ie. the VM is always the same). To clear things up, (it only added confusion for me since it doesn't allow us to assert vma-vm is what we always want, when just looking at the code). Signed-off-by: Ben Widawsky

[Intel-gfx] [PATCH 08/48] drm/i915: Don't use gtt mapping for !gtt error objects

2013-12-06 Thread Ben Widawsky
The existing check was insufficient to determine whether we can use the GTT mapping to read out the object during error capture. The previous condition was, if the object has a GGTT mapping, and the reloc is in the GTT range... the can happen with opjects mapped into multiple vms (one of which

[Intel-gfx] [PATCH 09/48] drm/i915: Identify active VM for batchbuffer capture

2013-12-06 Thread Ben Widawsky
Using the current state of the page directory registers, we can determine which of our address spaces was active when the hang occurred. This allows us to scan through all the address spaces to identify the active one during error capture. v2: Rebased for BDW error detection. BDW error detection

[Intel-gfx] [PATCH 11/48] drm/i915: Create bind/unbind abstraction for VMAs

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net To sum up what goes on here, we abstract the vma binding, similarly to the previous object binding. This helps for distinguishing legacy binding, versus modern binding. To keep the code churn as minimal as possible, I am leaving in insert_entries(). It serves

[Intel-gfx] [PATCH 19/48] drm/i915: Split context enabling from init

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net We **need** to do this for exactly 1 reason, because we want to embed a PPGTT into the context, but we don't want to special case the default context. To achieve that, we must be able to initialize contexts after the GTT is setup (so we can allocate and pin

[Intel-gfx] [PATCH 18/48] drm/i915: Better reset handling for contexts

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net This patch adds to changes for contexts on reset: Sets last context to default - this will prevent the context switch happening after a reset. That switch is not possible because the rings are hung during reset and context switch requires reset. This behavior

[Intel-gfx] [PATCH 16/48] drm/i915: Permit contexts on all rings

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net If we want to use contexts in more abstract terms (specifically with PPGTT in mind), we need to allow them to be specified for any ring. Since the upcoming patches will bring about the use of multiple address spaces, and each ring needs to have an address

[Intel-gfx] [PATCH 21/48] drm/i915: PPGTT vfuncs should take a ppgtt argument

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_drv.h | 3 ++- drivers/gpu/drm/i915/i915_gem.c | 4 +++- drivers/gpu/drm/i915/i915_gem_gtt.c | 8 3 files changed, 9 insertions(+), 6 deletions(-) diff --git

[Intel-gfx] [PATCH 27/48] drm/i915: Flush TLBs after !RCS PP_DIR_BASE

2013-12-06 Thread Ben Widawsky
I've found this by accident. The docs don't really come out and say you need to do this. What the docs do tell you is you need to flush the TLBs before you set the PP_DIR_BASE, and that the RCS will invalidate its TLBs upon setting the new PP_DIR_BASE. It makes no such comment about any of the

[Intel-gfx] [PATCH 22/48] drm/i915: Use drm_mm for PPGTT PDEs

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net When PPGTT support was originally enabled, it was only designed to support 1 PPGTT. It therefore made sense to simply hide the GGTT space required to enable this from the drm_mm allocator. Since we intend to support full PPGTT, which means more than 1, and

[Intel-gfx] [PATCH 26/48] drm/i915: Use LRI for switching PP_DIR_BASE

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net The docs seem to suggest this is the appropriate method (though it doesn't say so outright). In other words, we probably should have done this before. We certainly must do this for switching VMs on the fly, since synchronizing the rings to MMIO updates isn't

[Intel-gfx] [PATCH 04/48] drm/i915: Allow ggtt lookups to not WARN

2013-12-06 Thread Ben Widawsky
To be able to effectively use the GGTT object lookup function, we don't want to warn when there is no GGTT mapping. Let the caller deal with it instead. Originally, I had intended to have this behavior, and has not introduced the WARN. It was introduced during review with the addition of the

[Intel-gfx] [PATCH 17/48] drm/i915: Track which ring a context ran on

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net Previously we dropped the association of a context to a ring. It is however very important to know which ring a context ran on (we could have reused the other member, but I was nitpicky). This is very important when we switch address spaces, which unlike

[Intel-gfx] [PATCH 23/48] drm/i915: One hopeful eviction on PPGTT alloc

2013-12-06 Thread Ben Widawsky
The patch before this changed the way in which we allocate space for the PPGTT PDEs. It began carving out the PPGTT PDEs (which live in the Global GTT) from the GGTT's drm_mm. Prior to that patch, the PDEs were hidden from the drm_mm, and therefore could never fail to be allocated. In unfortunate

[Intel-gfx] [PATCH 24/48] drm/i915: Use platform specific ppgtt enable

2013-12-06 Thread Ben Widawsky
Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_gtt.c | 93 ++--- 1 file changed, 55 insertions(+), 38 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0bd0cb9..b17c65b

[Intel-gfx] [PATCH 32/48] drm/i915: Restore PDEs for all VMs

2013-12-06 Thread Ben Widawsky
In following with the old restore code, we must now restore ever PPGTT's PDEs, since they aren't proper GEM ojbects. v2: Rebased on BDW. Only do restore pdes for gen6 7 Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +++-- 1 file changed,

[Intel-gfx] [PATCH 13/48] drm/i915: Add a context open function

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net We'll be doing a bit more stuff with each file, so having our own open function should make things clean. This also allows us to easily add conditionals for stuff we don't want to do when we don't have HW contexts. Signed-off-by: Ben Widawsky

[Intel-gfx] [PATCH 38/48] drm/i915: Clean up VMAs before freeing

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net It's quite common for an object to simply be on the inactive list (and not unbound) when we want to free the context. This of course happens with lazy unbinding. Simply, this is needed when an object isn't fully unbound but we want to free one VMA of the

[Intel-gfx] [PATCH 28/48] drm/i915: Generalize PPGTT init

2013-12-06 Thread Ben Widawsky
Rearrange the initialization code to try to special case the aliasing PPGTT less, and provide usable interfaces for the general case later. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_gtt.c | 34 +++--- 1 file changed, 19

[Intel-gfx] [PATCH 20/48] drm/i915: Generalize default context setup

2013-12-06 Thread Ben Widawsky
The plan to to make every file descriptor have a default context. To accommodate this, generalize out default context setup function so it can be used at file open time. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_context.c | 25 - 1

[Intel-gfx] [PATCH 34/48] drm/i915: Create a per file_priv default context

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net Every file will get it's own context, and we use this context instead of the default context. The default context still exists for future shrinker usage as well as reset handling. v2: Updated to address Mika's recent context guilty changes Some more changes

[Intel-gfx] [PATCH 25/48] drm/i915: Extract mm switching to function

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net In order to do the full context switch with address space, it's convenient to have a way to switch the address space. We already have this in our code - just pull it out to be called by the context switch code later. v2: Rebased on BDW support. Required

[Intel-gfx] [PATCH 40/48] drm/i915: Add a tracepoint for new VMs

2013-12-06 Thread Ben Widawsky
Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem.c | 1 + drivers/gpu/drm/i915/i915_trace.h | 18 ++ 2 files changed, 19 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index a9cabff..63047da 100644

[Intel-gfx] [PATCH 36/48] drm/i915: Get context early in execbuf

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net We need to have the address space when reserving space for the objects. Since the address space and context are tied together, and reserve occurs before context switch (for good reason), we must lookup our context earlier in the process. This leaves some room

[Intel-gfx] [PATCH 45/48] drm/i915: Dump all ppgtt

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net Signed-off-by: Ben Widawsky b...@bwidawsk.net Conflicts: drivers/gpu/drm/i915/i915_debugfs.c --- drivers/gpu/drm/i915/i915_debugfs.c | 25 + 1 file changed, 25 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c

[Intel-gfx] [PATCH 42/48] drm/i915: Remove extraneous mm_switch in ppgtt enable

2013-12-06 Thread Ben Widawsky
Originally this commit message said: Now that do_switch does the mm switch, and we always enable the aliasing PPGTT, and contexts at the same time, there is no need to continue doing this during PPGTT enabling. Since originally writing the patch however, I introduced the concept of synchronous mm

[Intel-gfx] [PATCH 35/48] drm/i915: Piggy back hangstats off of contexts

2013-12-06 Thread Ben Widawsky
To simplify the codepaths somewhat, we can simply always create a context. Contexts already keep hangstat information. This prevents us from having to differentiate at other parts in the code. There is allocation overhead, but it should not be measurable. Signed-off-by: Ben Widawsky

[Intel-gfx] [PATCH 37/48] drm/i915: Defer request freeing

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net With context destruction, we always want to be able to tear down the underlying address space. This is invoked on the last unreference to the context which could happen before we've moved all objects to the inactive list. To enable a clean tear down the

[Intel-gfx] [PATCH 29/48] drm/i915: Reorganize intel_enable_ppgtt

2013-12-06 Thread Ben Widawsky
This patch consolidates the way in which we handle the various supported PPGTT by module parameter in addition to what the hardware supports. It strives to make doing the right thing in the code as simple as possible, with the USES_ macros. I've opted to add the full PPGTT argument simply so one

[Intel-gfx] [PATCH 39/48] drm/i915: Do not allow buffers at offset 0

2013-12-06 Thread Ben Widawsky
This is primarily a band aid for an unexplainable error in gem_reloc_vs_gpu/forked-faulting-reloc-thrashing. Essentially as soon as a relocated buffer (which had a non-zero presumed offset) moved to offset 0, something goes bad. Since I have been unable to solve this, and potentially this is a

[Intel-gfx] [PATCH 41/48] drm/i915: Use multiple VMs -- the point of no return

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net As with processes which run on the CPU, the goal of multiple VMs is to provide process isolation. Specific to GEN, there is also the ability to map more objects per process (2GB each instead of 2Gb-2k total). For the most part, all the pipes have been laid,

[Intel-gfx] [PATCH 48/48] page allocator: Tmp OOM deadlock w/a from Chris

2013-12-06 Thread Ben Widawsky
Deadlock with OOM lock, and struct_mutex where we invoke the OOM killer while holding struct_mutex, and unsuccessfully try to kill (because close requires struct_mutex) other processes using a lot of GEM memory. Authored-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky

[Intel-gfx] [PATCH 46/48] drm: Optionally create mm blocks from top-to-bottom

2013-12-06 Thread Ben Widawsky
From: Chris Wilson ch...@chris-wilson.co.uk Clients like i915 needs to segregate cache domains within the GTT which can lead to small amounts of fragmentation. By allocating the uncached buffers from the bottom and the cacheable buffers from the top, we can reduce the amount of wasted space and

[Intel-gfx] [PATCH 44/48] drm/i915: Add PPGTT dumper

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net Dump the aliasing PPGTT with it. The aliasing PPGTT should actually always be empty. TODO: Broadwell. Since we don't yet use full PPGTT on Broadwell, not having the dumper is okay. Signed-off-by: Ben Widawsky b...@bwidawsk.net Conflicts:

[Intel-gfx] [PATCH 31/48] drm/i915: Write PDEs at init instead of enable

2013-12-06 Thread Ben Widawsky
From: Ben Widawsky b...@bwidawsk.net We won't be calling enable() for all PPGTTs. We do need to write PDEs for all PPGTTs however. By moving the writing to init (which is called for all PPGTTs) we should accomplish this. ADD NOTE ABOUT PDE restore TODO: Eventually, we should allocate the page

[Intel-gfx] [PATCH 43/48] drm/i915: Warn on gem_pin usage

2013-12-06 Thread Ben Widawsky
The pin IOCTL is leftover from the days of yore. It allows you to take a buffer, pin it, and receive the offset of that buffer. The IOCTL does not support the newer notion of contexts and VM, and therefore is not suitable for modern usage. The unsolvable problem is, which address space do I pin

[Intel-gfx] [PATCH 47/48] drm/i915: Use topdown allocation for PPGTT

2013-12-06 Thread Ben Widawsky
In order to decrease fragmentation, and decrease the risk of using valuable mappable space for the page tables, we use the top down allocator for the page tables. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1

[Intel-gfx] [PATCH 33/48] drm/i915: Do aliasing PPGTT init with contexts

2013-12-06 Thread Ben Widawsky
We have a default context which suits the aliasing PPGTT well. Tie them together so it looks like any other context/PPGTT pair. This makes the code cleaner as it won't have to special case aliasing as often. The patch has one slightly tricky part in the default context creation function. In the

[Intel-gfx] [PATCH 30/48] drm/i915: Add VM to context

2013-12-06 Thread Ben Widawsky
Pretty straightforward so far except for the bit about the refcounting. The PPGTT will potentially be shared amongst multiple contexts. Because contexts themselves have a refcounted lifecycle, the easiest way to manage this will be to refcount the PPGTT. To acheive this, we piggy back off of the

Re: [Intel-gfx] [PATCH 09/19] drm/i915: get a runtime PM reference when the panel VDD is on

2013-12-06 Thread Paulo Zanoni
2013/11/29 Rodrigo Vivi rodrigo.v...@gmail.com: On Fri, Nov 29, 2013 at 11:59 AM, Paulo Zanoni przan...@gmail.com wrote: 2013/11/29 Rodrigo Vivi rodrigo.v...@gmail.com: On Thu, Nov 21, 2013 at 01:47:23PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com And put it when

[Intel-gfx] [PATCH] drm/i915: change CRTC assertion on LCPLL disable

2013-12-06 Thread Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com Currently, PC8 is enabled at modeset_global_resources, which is called after intel_modeset_update_state. Due to this, there's a small race condition on the case where we start enabling PC8, then do a modeset while PC8 is still being enabled. The racing

Re: [Intel-gfx] [PATCH 05/19] drm/i915: add initial Runtime PM functions

2013-12-06 Thread Paulo Zanoni
2013/11/29 Takashi Iwai ti...@suse.de: At Wed, 27 Nov 2013 18:10:30 -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com This patch adds the initial infrastructure to allow a Runtime PM implementation that sets the device to its D3 state. The patch just adds the necessary

[Intel-gfx] [PATCH 05/19] drm/i915: add initial Runtime PM functions

2013-12-06 Thread Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com This patch adds the initial infrastructure to allow a Runtime PM implementation that sets the device to its D3 state. The patch just adds the necessary callbacks and the initial infrastructure. We still don't have any platform that actually uses this

[Intel-gfx] [PATCH 06/19] drm/i915: do adapter power state notification at runtime PM

2013-12-06 Thread Paulo Zanoni
From: Paulo Zanoni paulo.r.zan...@intel.com Now that we are actually setting the device to the D3 state, we should issue the notification. The opregion spec says we should send the message before the adapter is about to be placed in a lower power state, and after the adapter is placed in a

Re: [Intel-gfx] [PATCH] drm/i915: change CRTC assertion on LCPLL disable

2013-12-06 Thread Daniel Vetter
On Fri, Dec 06, 2013 at 08:29:01PM -0200, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Currently, PC8 is enabled at modeset_global_resources, which is called after intel_modeset_update_state. Due to this, there's a small race condition on the case where we start enabling

[Intel-gfx] [PATCH v2] ACPI/i915: Fix wrong acpi/acpi.h inclusion in i915 opregion module.

2013-12-06 Thread Lv Zheng
From: Lv Zheng lv.zh...@intel.com In Linux kernel, ACPICA is wrapped and safely exported by CONFIG_ACPI. So all external modules should depend on CONFIG_ACPI rather than using ACPICA header directly for stubbing. But if we moves acpi/acpi.h inclusions into #ifdef CONFIG_ACPI, build breakge can

[Intel-gfx] [PATCH] intel-gpu-tools: Version information

2013-12-06 Thread Ben Widawsky
Provide two arguments version, and verbose, which allow printing from an arbitrary igt test. It will show system information (from build time, not runtime), as well as the git SHA being used. This will help reduce errors when people try to reproduce problems. As an example if I want to verify

<    1   2