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 inclusions
into "#ifdef CONFIG_ACPI", build breakge can help to detect wrong ACPICA
dependent modules
From: "Xiang, Haihao"
Otherwise it may result in GPU hang
Signed-off-by: Xiang, Haihao
---
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 43e962c..1a137dd 100644
--- a/lib/rendercopy_gen8.c
+++ b/
From: "Xiang, Haihao"
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
---
lib/rendercopy_gen8.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
di
From: "Xiang, Haihao"
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 b/lib/rendercopy_i830.c
index 5dd67b2..7
From: "Xiang, Haihao"
Otherwise the stale data in the buffer
Signed-off-by: Xiang, Haihao
---
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 100644
--- a/lib/intel_batchbuffer.c
+++ b/lib
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 hws
Or more precisely: It already has an igt_require. So we cant ditch it
from tests.
Signed-off-by: Daniel Vetter
---
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 a/tests/kms_cursor_crc.c b/tests/km
No need to duplicate this all over the place.
Signed-off-by: Daniel Vetter
---
lib/igt_debugfs.c | 18 ++
lib/igt_debugfs.h | 1 +
tests/kms_cursor_crc.c | 18 ++
tests/kms_fbc_crc.c| 14 +-
tests/kms_pipe_crc_basic.c | 2
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
---
lib/igt_debugfs.c | 7 ++-
lib/igt_debugfs.h | 2 +-
tests/kms_pipe_crc_basic.c | 2 +-
3 files changed, 4 insertions(+), 7 deletions(
> -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] dr
On 12/06/2013 12:54 AM, Xiang, Haihao wrote:
> From: "Xiang, Haihao"
>
> Otherwise the stale data in the buffer
>
> Signed-off-by: Xiang, Haihao
> ---
> lib/intel_batchbuffer.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
> in
On 12/06/2013 12:54 AM, Xiang, Haihao wrote:
> From: "Xiang, Haihao"
>
> Otherwise it may result in GPU hang
>
> Signed-off-by: Xiang, Haihao
> ---
> lib/rendercopy_gen8.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/rendercopy_gen8.c b/lib/rendercopy_gen8.c
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-
> Fr
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 wrote:
Basically ULPS handling during enable/disable has been moved to
pre_ena
On Friday 15 November 2013 01:57 PM, Jani Nikula wrote:
On Sat, 09 Nov 2013, Shobhit Kumar 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. The ULPS entry/exit
sequne
From: Tvrtko Ursulin
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
---
tests/gem_evict_everything.c | 12 +-
Hi,
On Fri, 2013-12-06 at 08:55 +0800, Xiang, Haihao wrote:
> +++ b/tests/gem_media_fill.c
...
> +#include
It does not look like this include is needed and it is troublesome on
Android.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.f
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
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; Wida
---
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
+++ b/dri
On Fri, Dec 06, 2013 at 11:37:49AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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.
>
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
http://
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
> >
> > 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 nu
From: Tvrtko Ursulin
Causes trouble for Android builds.
Signed-off-by: Tvrtko Ursulin
---
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
--- a/tests/gem_media_fill.c
+++ b/tests/gem_media_f
Hi Jani,
On Mon, Dec 2, 2013 at 11:26 AM, Rodrigo Vivi wrote:
> From: Jani Nikula
>
> We don't actually do anything with the information yet, but parse and
> log what's in the VBT.
>
> Signed-off-by: Jani Nikula
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 5
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
Oh, yes, initially ono had to specify the point at _start() time, but I
moved it to _new(
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
(note that the use of buffered fopen/fwrite operations and the need to
flush the internal buffer could be just replaced with raw open/write and
was a le
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
Reviewed-by: Damien Lespiau
> ---
> tests/kms_cursor_crc.c | 1 -
> tests/kms_fbc_crc.c| 1 -
> tes
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"
> >
> > Otherwise the stale data in the buffer
> >
> > Signed-off-by: Xiang, Haihao
> > ---
> > lib/intel_batchbuffer.c |2 ++
> > 1 file changed, 2 ins
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"
> >
> > Otherwise it may result in GPU hang
> >
> > Signed-off-by: Xiang, Haihao
> > ---
> > lib/rendercopy_gen8.c |2 +-
> > 1 file changed, 1 insertio
On Fri, Dec 06, 2013 at 04:54:46PM +0800, Xiang, Haihao wrote:
> From: "Xiang, Haihao"
>
> 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 this w/a, on the
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 a
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
> > >
> > > Don't see that it causes a problem but it looks it was intended
> >
On Fri, Dec 06, 2013 at 09:16:58AM +0800, Xiang, Haihao wrote:
> From: "Xiang, Haihao"
>
> 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 parameter of write
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
> > > >
> > > >
On Fri, Dec 06, 2013 at 12:38:49PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Causes trouble for Android builds.
>
> Signed-off-by: Tvrtko Ursulin
Applied, thanks.
-Daniel
> ---
> tests/gem_media_fill.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/tests/gem_media_fil
On Fri, 6 Dec 2013 14:42:29 +0100
Daniel Vetter 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 asynch
2013/12/5 Jani Nikula :
> On Thu, 21 Nov 2013, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> 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
>> sequencing registers, so we need to have them ready by this ti
From: Paulo Zanoni
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: https://bugs.freedesktop.org/show_bug.cgi?id=69693
Reviewed-by: Rodri
From: Paulo Zanoni
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 wouldn't need to rebase thi
From: Paulo Zanoni
We just don't need this. This saves 250ms from every modeset on my
machine.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i91
From: Paulo Zanoni
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
intel_wait_until_after, and on th
From: Paulo Zanoni
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 that we record the
timest
From: Paulo Zanoni
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 already
respected when we disa
On Fri, 6 Dec 2013 17:32:42 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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_d
On Fri, 6 Dec 2013 17:32:43 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
> mslee
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 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 occu
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
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
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 Widaws
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
po
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 ne
From: Ben Widawsky
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 the default context
From: Ben Widawsky
formerly: drm/i915: Create VMAs (part 6) - finish error plumbing
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gpu_error.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/
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
---
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| 14 -
From: Ben Widawsky
Signed-off-by: Ben Widawsky
---
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 a/drivers/gpu/drm/i915/i915_drv.h b/driver
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 follo
From: Ben Widawsky
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 space programmed (whi
From: Ben Widawsky
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 as the per
platfor
From: Ben Widawsky
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 they
can be created
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 bei
Signed-off-by: Ben Widawsky
---
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 bf4e2d9..29962fe 100644
--
From: Ben Widawsky
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
context objects, do ch
From: Ben Widawsky
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
---
drivers/gpu/drm/i915/i915_d
From: Ben Widawsky
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 will need to be re
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
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 adding BDW.
Signed-off
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 17 +++--
1 file changed, 15 insertions(+)
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
---
drivers
From: Ben Widawsky
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 acceptable.
v2:
Ma
Signed-off-by: Ben Widawsky
---
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 100644
--- a/drivers/gp
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 ex
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
---
drivers/gpu/drm/i915/i915_gem_context.c | 25 -
1 file changed, 12 ins
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 almo
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 othe
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 c
From: Ben Widawsky
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 tables on demand.
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 good
From: Ben Widawsky
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, and all we need to
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 t
From: Ben Widawsky
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 for optimizations
Signed-off-by: Ben Widawsky
---
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
--- a/drivers/gpu/dr
From: Ben Widawsky
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 address space, make sure
From: Ben Widawsky
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
Conflicts:
drivers/gpu/drm/i915/i915_debugfs.c
dr
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 fu
From: Ben Widawsky
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 object, for whatever re
From: Ben Widawsky
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 around this come up
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 occu
From: Chris Wilson
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 also optimize allocation o
From: Ben Widawsky
formerly: drm/i915: Create VMAs (part 6) - finish error plumbing
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gpu_error.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/
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
po
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
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 Widaws
From: Ben Widawsky
Signed-off-by: Ben Widawsky
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
b/drivers/gpu/drm/i915/i915_debugfs.
1 - 100 of 153 matches
Mail list logo
