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 help to detect wrong ACPICA
From: Xiang, Haihao haihao.xi...@intel.com
Otherwise it may result in GPU hang
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
lib/rendercopy_gen8.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
index
From: Xiang, Haihao haihao.xi...@intel.com
Emit PIPELINE_SELECT twice and make sure the commands in
the first batch buffer have been done.
However I don't know why this works !!!
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
lib/rendercopy_gen8.c | 19 +--
1 file
From: Xiang, Haihao haihao.xi...@intel.com
This reverts commit e41928e6c9bb3f24833a827903f1afeda83592d6.
Now the case no longer causes GPU hang on GEN
---
lib/rendercopy_i830.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/lib/rendercopy_i830.c
From: Xiang, Haihao haihao.xi...@intel.com
Otherwise the stale data in the buffer
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
lib/intel_batchbuffer.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
index 06a5437..9ce7424
Shovel a bit more of the the code into the setup function, and call
it earlier. Otherwise lockdep is unhappy since we cancel the delayed
resume work before it's initialized.
While at it also shovel the pc8 setup code into the same functions.
I wanted to also ditch the header declaration of the
Or more precisely: It already has an igt_require. So we cant ditch it
from tests.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
tests/kms_cursor_crc.c | 1 -
tests/kms_fbc_crc.c| 1 -
tests/kms_pipe_crc_basic.c | 1 -
3 files changed, 3 deletions(-)
diff --git
No need to duplicate this all over the place.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_debugfs.c | 18 ++
lib/igt_debugfs.h | 1 +
tests/kms_cursor_crc.c | 18 ++
tests/kms_fbc_crc.c| 14 +-
It's what callers expect - pipe_crc_new is the function where
we pass a potential failure back to callers.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/igt_debugfs.c | 7 ++-
lib/igt_debugfs.h | 2 +-
tests/kms_pipe_crc_basic.c | 2 +-
3 files changed, 4
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Thursday, December 05, 2013 2:43 PM
To: Intel Graphics Development
Cc: Daniel Vetter; Lister, Ian; sta...@vger.kernel.org; Widawsky, Benjamin;
Stéphane Marchesin; Bloomfield, Jon
Subject: [PATCH]
On 12/06/2013 12:54 AM, Xiang, Haihao wrote:
From: Xiang, Haihao haihao.xi...@intel.com
Otherwise the stale data in the buffer
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
lib/intel_batchbuffer.c |2 ++
1 file changed, 2 insertions(+)
diff --git
On 12/06/2013 12:54 AM, Xiang, Haihao wrote:
From: Xiang, Haihao haihao.xi...@intel.com
Otherwise it may result in GPU hang
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
lib/rendercopy_gen8.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
What's the status of this patch ? I can't find any subsequent mention of it,
but we currently use it in one of our Android development trees. I'm trying to
work out whether to retain it or replace it.
Was it killed off, or is it still in the pipeline ?
Thanks.
-Original Message-
On Wednesday 20 November 2013 07:09 AM, Shobhit Kumar wrote:
On Friday 15 November 2013 02:25 PM, Daniel Vetter wrote:
On Fri, Nov 15, 2013 at 10:27:25AM +0200, Jani Nikula wrote:
On Sat, 09 Nov 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
Basically ULPS handling during enable/disable
On Friday 15 November 2013 01:57 PM, Jani Nikula wrote:
On Sat, 09 Nov 2013, Shobhit Kumar shobhit.ku...@intel.com wrote:
Basically ULPS handling during enable/disable has been moved to
pre_enable and post_disable phases. PLL and panel power disable
also has been moved to post_disable phase.
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Don't see that it causes a problem but it looks it was intended
to use bo_count at these places.
Also using count to determine number of processes does not make
sense unless thousands of cores.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Hi,
On Fri, 2013-12-06 at 08:55 +0800, Xiang, Haihao wrote:
+++ b/tests/gem_media_fill.c
...
+#include cairo.h
It does not look like this include is needed and it is troublesome on
Android.
Regards,
Tvrtko
___
Intel-gfx mailing list
On Fri, Dec 06, 2013 at 10:44:15AM +, Bloomfield, Jon wrote:
What's the status of this patch ? I can't find any subsequent mention of
it, but we currently use it in one of our Android development trees. I'm
trying to work out whether to retain it or replace it.
Was it killed off, or is
On Fri, Dec 06, 2013 at 10:17:53AM +0100, Daniel Vetter wrote:
Shovel a bit more of the the code into the setup function, and call
it earlier. Otherwise lockdep is unhappy since we cancel the delayed
resume work before it's initialized.
While at it also shovel the pc8 setup code into the
On Fri, Dec 06, 2013 at 10:05:51AM +, Lister, Ian wrote:
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Thursday, December 05, 2013 2:43 PM
To: Intel Graphics Development
Cc: Daniel Vetter; Lister, Ian; sta...@vger.kernel.org; Widawsky,
---
drivers/gpu/drm/i915/i915_gem_evict.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index b7376533633d..8f3adc7d0dc8 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++
On Fri, Dec 06, 2013 at 11:37:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Don't see that it causes a problem but it looks it was intended
to use bo_count at these places.
Also using count to determine number of processes does not make
sense unless
Ok thanks.
To add weight to it becoming official in some form, we're using it for various
deferred operations:
drm/i915: Make plane switching asynchronous
drm/i915: Asynchronously unpin the old framebuffer after the next
vblank
They aren't my patches but I believe they
On Fri, Dec 06, 2013 at 12:11:47PM +, Chris Wilson wrote:
Ah, must have been another machine with the verbose commit msg!
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
On Fri, 2013-12-06 at 13:12 +0100, Daniel Vetter wrote:
On Fri, Dec 06, 2013 at 11:37:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Don't see that it causes a problem but it looks it was intended
to use bo_count at these places.
Also using count to
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Causes trouble for Android builds.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/gem_media_fill.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tests/gem_media_fill.c b/tests/gem_media_fill.c
index 40b391d..b458ded 100644
---
Hi Jani,
On Mon, Dec 2, 2013 at 11:26 AM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
From: Jani Nikula jani.nik...@intel.com
We don't actually do anything with the information yet, but parse and
log what's in the VBT.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Rodrigo
On Fri, Dec 06, 2013 at 10:48:44AM +0100, Daniel Vetter wrote:
It's what callers expect - pipe_crc_new is the function where
we pass a potential failure back to callers.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Oh, yes, initially ono had to specify the point at _start() time, but
On Fri, Dec 06, 2013 at 10:48:43AM +0100, Daniel Vetter wrote:
No need to duplicate this all over the place.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
(note that the use of buffered fopen/fwrite operations and the need to
flush the internal buffer could be just replaced with raw
On Fri, Dec 06, 2013 at 10:48:42AM +0100, Daniel Vetter wrote:
Or more precisely: It already has an igt_require. So we cant ditch it
from tests.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
---
tests/kms_cursor_crc.c | 1 -
On Fri, Dec 06, 2013 at 02:14:52AM -0800, Kenneth Graunke wrote:
On 12/06/2013 12:54 AM, Xiang, Haihao wrote:
From: Xiang, Haihao haihao.xi...@intel.com
Otherwise the stale data in the buffer
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
lib/intel_batchbuffer.c |2
On Fri, Dec 06, 2013 at 02:15:18AM -0800, Kenneth Graunke wrote:
On 12/06/2013 12:54 AM, Xiang, Haihao wrote:
From: Xiang, Haihao haihao.xi...@intel.com
Otherwise it may result in GPU hang
Signed-off-by: Xiang, Haihao haihao.xi...@intel.com
---
lib/rendercopy_gen8.c |2 +-
On Fri, Dec 06, 2013 at 04:54:46PM +0800, Xiang, Haihao wrote:
From: Xiang, Haihao haihao.xi...@intel.com
Emit PIPELINE_SELECT twice and make sure the commands in
the first batch buffer have been done.
However I don't know why this works !!!
Hum :) on one hand, it's great that you found
On Fri, Dec 06, 2013 at 12:12:21PM +, Bloomfield, Jon wrote:
Ok thanks.
To add weight to it becoming official in some form, we're using it for
various deferred operations:
drm/i915: Make plane switching asynchronous
drm/i915: Asynchronously unpin the old framebuffer after
On Fri, Dec 06, 2013 at 12:33:28PM +, Tvrtko Ursulin wrote:
On Fri, 2013-12-06 at 13:12 +0100, Daniel Vetter wrote:
On Fri, Dec 06, 2013 at 11:37:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Don't see that it causes a problem but it looks it was
On Fri, Dec 06, 2013 at 09:16:58AM +0800, Xiang, Haihao wrote:
From: Xiang, Haihao haihao.xi...@intel.com
write(...) is used for Render Target Write and Media Block Write.
The two message types no longer share the same cache agent on GEN8,
So a parameter is needed for cache agent. The 4th
On Fri, 2013-12-06 at 14:46 +0100, Daniel Vetter wrote:
On Fri, Dec 06, 2013 at 12:33:28PM +, Tvrtko Ursulin wrote:
On Fri, 2013-12-06 at 13:12 +0100, Daniel Vetter wrote:
On Fri, Dec 06, 2013 at 11:37:49AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
On Fri, Dec 06, 2013 at 12:38:49PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Causes trouble for Android builds.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Applied, thanks.
-Daniel
---
tests/gem_media_fill.c | 1 -
1 file changed, 1
On Fri, 6 Dec 2013 14:42:29 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Dec 06, 2013 at 12:12:21PM +, Bloomfield, Jon wrote:
Ok thanks.
To add weight to it becoming official in some form, we're using it for
various deferred operations:
drm/i915: Make plane switching
2013/12/5 Jani Nikula jani.nik...@linux.intel.com:
On Thu, 21 Nov 2013, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
When we call intel_dp_i2c_init we already get some I2C calls, which
will trigger a VDD enable, which will make use of the panel power
From: Paulo Zanoni paulo.r.zan...@intel.com
I don't see a reason to touch VDD when we're disabling the panel:
since the panel is enabled, we don't need VDD. This saves a few sleep
calls from the vdd_on and vdd_off functions at every modeset.
Bugzilla:
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
This series was already posted to the mailing list as part of the Runtime PM
series. Since the runtime PM code touches some eDP code, I originally made this
series on top of runtime PM because I was hoping runtime PM would be merged
earlier, so I
From: Paulo Zanoni paulo.r.zan...@intel.com
We just don't need this. This saves 250ms from every modeset on my
machine.
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 2 --
1 file changed, 2
From: Paulo Zanoni paulo.r.zan...@intel.com
Our driver has two different ways of waiting for panel power
sequencing delays. One of these ways is through
ironlake_wait_panel_status, which implicitly uses the values written
to our registers. The other way is through the functions that call
From: Paulo Zanoni paulo.r.zan...@intel.com
The eDP spec defines some points where after you do action A, you have
to wait some time before action B. The thing is that in our driver
action B does not happen exactly after action A, but we still use
msleep() calls directly. What this patch does is
From: Paulo Zanoni paulo.r.zan...@intel.com
If we're disabling the VDD override bit and the panel is enabled, we
don't need to wait for anything. If the panel is disabled, then we
need to actually wait for panel_power_cycle_delay, not
panel_power_down_delay, because the power down delay was
On Fri, 6 Dec 2013 17:32:42 -0200
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
If we're disabling the VDD override bit and the panel is enabled, we
don't need to wait for anything. If the panel is disabled, then we
need to actually wait for
On Fri, 6 Dec 2013 17:32:43 -0200
Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The eDP spec defines some points where after you do action A, you have
to wait some time before action B. The thing is that in our driver
action B does not happen exactly
The following changes since commit 1ce477c917c75ce398e0def49f480327c9d0bab0:
drm-intel-nightly: 2013y-12m-06d-13h-13m-07s integration manifest (2013-12-06
13:13:33 +0100)
are available in the git repository at:
git://people.freedesktop.org/~bwidawsk/drm-intel ppgtt
for you to fetch
eb_destroy currently cleans up the refcounts for all the VMAs done at
lookup. Currently eb_lookup_vmas cleans up all the *objects* we've
looked up. There exists a period of time when we under severe memory
pressure, the VMA creation will fail, and fall into our exit path.
When the above event
This was found by code inspection. If the GTT setup fails then we are
left without properly tearing down the drm_mm.
Hopefully this never happens.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Since the beginning, the functions which try to properly reference the
aliasing PPGTT have deferences a potentially null aliasing_ppgtt member.
Since the accessors are meant to be global, this will not do.
Introduced originally in:
commit a70a3148b0c61cb7c588ea650db785b261b378a3
Author: Ben
The initial implementation of this function used MMIO to write the PDPs.
Upon review it was determined (correctly) that the docs say to use LRI.
The issue is there are times where we want to do a synchronous write
(GPU reset).
I've tested this, and it works. I've verified with as many people as
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
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
From: Ben Widawsky b...@bwidawsk.net
formerly: drm/i915: Create VMAs (part 6) - finish error plumbing
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gpu_error.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git
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
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c| 14 ++---
drivers/gpu/drm/i915/i915_drv.h| 32 +++
drivers/gpu/drm/i915/i915_gem.c| 49 --
drivers/gpu/drm/i915/i915_gem_context.c
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
With the introduction of contexts per fd in the future, one can easily
envision more contexts being used. We do not have an easy remedy to
reduce the space requirements of the contexts, we can make things
slightly better by using less stringent alignments on later hardware.
Ville: Since I can
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
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
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
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,
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
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
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
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
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:
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
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
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
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
eb_destroy currently cleans up the refcounts for all the VMAs done at
lookup. Currently eb_lookup_vmas cleans up all the *objects* we've
looked up. There exists a period of time when we under severe memory
pressure, the VMA creation will fail, and fall into our exit path.
When the above event
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
From: Ben Widawsky b...@bwidawsk.net
formerly: drm/i915: Create VMAs (part 6) - finish error plumbing
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gpu_error.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git
The initial implementation of this function used MMIO to write the PDPs.
Upon review it was determined (correctly) that the docs say to use LRI.
The issue is there are times where we want to do a synchronous write
(GPU reset).
I've tested this, and it works. I've verified with as many people as
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
Since the beginning, the functions which try to properly reference the
aliasing PPGTT have deferences a potentially null aliasing_ppgtt member.
Since the accessors are meant to be global, this will not do.
Introduced originally in:
commit a70a3148b0c61cb7c588ea650db785b261b378a3
Author: Ben
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
With the introduction of contexts per fd in the future, one can easily
envision more contexts being used. We do not have an easy remedy to
reduce the space requirements of the contexts, we can make things
slightly better by using less stringent alignments on later hardware.
Ville: Since I can
This was found by code inspection. If the GTT setup fails then we are
left without properly tearing down the drm_mm.
Hopefully this never happens.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git
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
1 - 100 of 149 matches
Mail list logo
