.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
This patch was accidentally dropped in the first Execlists version, and
it has been very useful indeed. Put it back again, but as a standalone
debugfs file.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 52
From: Oscar Mateo oscar.ma...@intel.com
Allocate and populate the default LRC for every ring, call
gen-specific init/cleanup, init/fini the command parser and
set the status page (now inside the LRC object).
Stopping the ring before cleanup and initializing the seqnos
is left as a TODO task (we
From: Oscar Mateo oscar.ma...@intel.com
We need to attend context switch interrupts from all rings. Also, fixed writing
IMR/IER and added HWSTAM at ring init time.
Notice that, if added to irq_enable_mask, the context switch interrupts would
be incorrectly masked out when the user interrupts
From: Oscar Mateo oscar.ma...@intel.com
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests.
v2: The ring is, at this point, already being correctly re-programmed
for Execlists, and the hangcheck counters cleared.
Signed-off-by: Oscar Mateo
From: Oscar Mateo oscar.ma...@intel.com
Execlists are indeed a brave new world with respect to workload
submission to the GPU.
In previous version of these series, I have tried to impact the
legacy ringbuffer submission path as little as possible (mostly,
passing the context around and using
whitespace errors, using
lockdep to check mutex locked status in postpone_flip, removal of
__must_check
in function definition) (Chris)
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Sourab Gupta sourab.gu...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
From: Oscar Mateo oscar.ma...@intel.com
No mistery here: the seqno is still retrieved from the engine's
HW status page (the one in the default context. For the moment,
I see no reason to worry about other context's HWS page).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
I plan to reuse these for the new logical ring path.
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 31 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 3
From: Oscar Mateo oscar.ma...@intel.com
This is what i915_gem_do_execbuffer calls when it wants to execute some
worload in an Execlists world. It's a candidate for abstracting the
submission mechanism away.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Dispatch_execbuffer's evil twin.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 29 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +++
2 files changed, 32 insertions(+)
diff
From: Oscar Mateo oscar.ma...@intel.com
Well, new-ish: if all this code looks familiar, that's because it's
a clone of the existing submission mechanism (with some modifications
here and there to adapt it to LRCs and Execlists).
And why did we do this? Execlists offer several advantages, like
From: Oscar Mateo oscar.ma...@intel.com
Things are starting to get messy, and this helps a little.
And some point in time, it would be a good idea to split
intel_lrc.c/.h even further, but for the moment just shove
everything together.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
initialization.
- Damien's kmalloc review comments: check return, use sizeof(*req),
do not cast.
v5:
- Do not reuse drm_i915_gem_request. Instead, create our own.
- New namespace.
Signed-off-by: Michel Thierry michel.thie...@intel.com (v1)
Signed-off-by: Oscar Mateo oscar.ma...@intel.com (v2-v5
From: Oscar Mateo oscar.ma...@intel.com
It is generic enough to be reused.
Trivial change.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff
From: Oscar Mateo oscar.ma...@intel.com
Trivial change.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 6 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking for
contexts to squash together. Instead, share the burden by giving more
intelligence to the queue
From: Oscar Mateo oscar.ma...@intel.com
v2: Warn and return if LRCs are not enabled.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 72 +
drivers/gpu/drm/i915/intel_lrc.c| 6
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Or with a spinlock grabbed, because it might sleep, which is not
a nice thing to do. Instead, do the runtime_pm get/put together
with the create/destroy request, and handle the forcewake get/put
directly.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
From: Oscar Mateo oscar.ma...@intel.com
Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.
TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful
From: Oscar Mateo oscar.ma...@intel.com
Each logical ring context has the tail pointer in the context object,
so update it before submission.
v2: New namespace.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19
From: Oscar Mateo oscar.ma...@intel.com
Also known as __i915_add_request's evil twin.
On seqno preallocation, we set the request context information
correctly so that we can retrieve it both when we want to emit
or retire the request.
This is a candidate to be abstracted away (so
From: Oscar Mateo oscar.ma...@intel.com
Notice that the BSD invalidate bit is no longer present in GEN8, so
we can consolidate the blt and bsd ring flushes into one.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 80
From: Oscar Mateo oscar.ma...@intel.com
Add theory of operation notes to intel_lrc.c and comments to externally
visible functions.
v2: Add notes on logical ring context creation.
v3: Use kerneldoc.
Signed-off-by: Thomas Daniel thomas.dan...@intel.com (v1)
Signed-off-by: Oscar Mateo oscar.ma
From: Oscar Mateo oscar.ma...@intel.com
Very similar to the legacy add_request, only modified to account for
logical ringbuffer.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c| 61
From: Oscar Mateo oscar.ma...@intel.com
Logical rings do not need most of the initialization their
legacy ringbuffer counterparts do: we just need the pipe
control object for the render ring, enable Execlists on the
hardware and a few workarounds.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
From: Oscar Mateo oscar.ma...@intel.com
I want to reuse it from the new logical ring code (as it seems
innocent enough).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 13
From: Oscar Mateo oscar.ma...@intel.com
In the current Execlists feeding mechanism, full preemption is not
supported yet: only lite-restores are allowed (this is: the GPU
simply samples a new tail pointer for the context currently in
execution).
But we have identified an scenario in which a full
From: Oscar Mateo oscar.ma...@intel.com
So that we isolate the legacy ringbuffer submission mechanism, which becomes
a good candidate to be abstracted away.
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 298
From: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915
make
sure that it was properly aligned. Spotted by Alistair Mcaulay
alistair.mcau...@intel.com.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 112 ++-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
2 files changed, 112
From: Oscar Mateo oscar.ma...@intel.com
For the moment, just mark the place (we still need to do a lot of
preparation before execlists are ready to start submitting things).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 11 +++
drivers
From: Oscar Mateo oscar.ma...@intel.com
As suggested by Daniel.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 26
drivers/gpu/drm/i915/i915_gem.c| 48 +++---
drivers/gpu/drm/i915
namespace and multiple rebase changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 41 -
drivers/gpu/drm/i915/intel_lrc.c| 104 +++-
drivers/gpu/drm/i915/intel_lrc.h| 3 +
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Execlists need a new submission mechanism, so split the preparation
from the submission.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem_render_state.c | 27 +--
1 file changed, 21 insertions
From: Oscar Mateo oscar.ma...@intel.com
Reusing stuff, a penny at a time.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git
From: Oscar Mateo oscar.ma...@intel.com
These do not exist anymore.
Spotted while reading through intel_ringbuffer.c
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers
From: Oscar Mateo oscar.ma...@intel.com
These patches contain refactoring and preparatory work for Execlists [1].
[1http://lists.freedesktop.org/archives/intel-gfx/2014-May/044847.html]
http://lists.freedesktop.org/archives/intel-gfx/2014-May/044847.html
Oscar Mateo (6):
drm/i915: s
From: Oscar Mateo oscar.ma...@intel.com
This refactoring has been performed using the following Coccinelle
semantic script:
@@
struct intel_engine_cs r;
@@
(
- (r).obj
+ r.buffer-obj
|
- (r).virtual_start
+ r.buffer-virtual_start
|
- (r).head
From: Oscar Mateo oscar.ma...@intel.com
It's barely alive now anyway, so give it the coup de grâce.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 ---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_context.c
From: Oscar Mateo oscar.ma...@intel.com
As advanced by the previous patch, the ringbuffers and the engine
command streamers belong in different structs. This is so because,
while they used to be tightly coupled together, the new Logical
Ring Contexts (LRC for short) have a ringbuffer each
From: Oscar Mateo oscar.ma...@intel.com
Manual cleanup after the previous Coccinelle script.
Yes, I could write another Coccinelle script to do this but I
don't want labor-replacing robots making an honest programmer's
work obsolete (also, I'm lazy).
Signed-off-by: Oscar Mateo oscar.ma
From: Oscar Mateo oscar.ma...@intel.com
Up until now, contexts had one (and only one) backing object that was
used by the hardware to save/restore render ring contexts (via the
MI_SET_CONTEXT command). Other rings did not have or need this, so
our i915_hw_context struct had a 1:1 relationship
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object
From: Oscar Mateo oscar.ma...@intel.com
This is a review by igt test for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
Author: Oscar Mateo oscar.ma...@intel.com
Date: Fri May 16 11:23:12 2014 +0100
drm/i915: Gracefully
From: Oscar Mateo oscar.ma...@intel.com
Useful for testing bigger/smaller fb-wrapped buffer objects.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
lib/igt_fb.c | 45 ++---
lib/igt_fb.h | 3 +++
2
From: Oscar Mateo oscar.ma...@intel.com
This is a review by igt test for a bug located in
i915_gem_object_pin_to_display_plane and fixed by:
commit 392013bdd4b6128795e33c84bd6d6d3fd66ff0a3
Author: Oscar Mateo oscar.ma...@intel.com
Date: Fri May 16 11:23:12 2014 +0100
drm/i915: Gracefully
From: Oscar Mateo oscar.ma...@intel.com
Otherwise, we do a NULL pointer dereference.
I've seen this happen while handling an error in
i915_gem_object_pin_to_display_plane():
If i915_gem_object_set_cache_level() fails, we call is_pin_display()
to handle the error. At this point, the object
, as the BSpec suggest we do.
- Prevent warning when compiling a 32-bits kernel without HIGHMEM64.
- Add a clarifying comment to the context population code.
v5: Damien's review comments:
- The third MI_LOAD_REGISTER_IMM in the context does not set Force Posted.
- Remove dead code.
Signed-off-by: Oscar Mateo
From: Oscar Mateo oscar.ma...@intel.com
Or with a spinlock grabbed, because it might sleep, which is not
a nice thing to do. Instead, do the runtime_pm get/put together
with the create/destroy request, and handle the forcewake get/put
directly.
This can be squashed with:
[PATCH 35/50] drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Guarantees that error capture works at a very basic level.
v2: Also check that the ring object contains a reloc with MI_BB_START
for the presumed batch object's address.
v3: Chris review comments:
- Move variables to local scope.
- Do not assume
From: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
tests/.gitignore | 1 +
tests/Makefile.am | 1 +
tests/Makefile.sources | 1 +
tests/gem_execlist.c | 266 +
4 files changed, 269
From: Ben Widawsky benjamin.widaw...@intel.com
for_each_ring() iterates over all rings supported by the hardware, not
just those which have been initialized as in for_each_active_ring()
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Acked-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm
.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
v2: The Full PPGTT series have moved things around a little bit.
Also, don't forget the VEBOX.
v3: Checking ring-dev is not a good way to test if a ring is
initialized...
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
...@bwidawsk.net
v2: Several rebases.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 12 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 16
drivers/gpu/drm/i915/i915_gem_context.c
From: Oscar Mateo oscar.ma...@intel.com
The __ name is too confusing, specially given the refactoring patch
that comes soon with more new ringbuffer management functions.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 ++-
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 21 ++---
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
v3: Add a module parameter to enable execlists. Execlist are relatively
new, and so it'd be wise to be able to switch back to ring submission
to debug subtle problems that will inevitably arise.
Signed-off-by: Damien Lespiau damien.lesp
From: Oscar Mateo oscar.ma...@intel.com
We are going to use it later to allocate our own objects.
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Continue with the refactoring: do not init or clean a ringbuffer when
you actually mean a ring, because they are not the same thing anymore.
Again, no functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
This patch should have no functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
In Execlists we don't really write to the tail register to submit
a workload to the GPU, so the name is going to stop being accurate
soon.
Change and name suggested by Brad.
Cc: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Oscar Mateo oscar.ma
From: Oscar Mateo oscar.ma...@intel.com
Allocating only the RCS backing object won't be enough for LRCs, so
give callers the opportunity to skip it.
No functional changes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
The default context holds pointers to every engine's default ringbuffer,
and makes its own allocation of the corresponding backing objects. During
ringbuffer creation we might try to allocate them again, but this will
fail silently (same thing
From: Oscar Mateo oscar.ma...@intel.com
The context are going to become very important pretty soon, and
we need to be able to access them in a number of places inside
the command submission path. The idea is that, when we need to
place commands inside a ringbuffer or update the tail register,
we
From: Oscar Mateo oscar.ma...@intel.com
We need functions that are aware of the fact that the ringbuffer might be living
somewhere else than in the engine. After this commit and some of the previous,
these
new ringbuffer functions finally are:
intel_ringbuffer_get
intel_ringbuffer_begin
From: Oscar Mateo oscar.ma...@intel.com
The backing objects for user-created contexts (either via open fd or
create context ioctl) are actually empty until the user starts sending
execbuffers to them. We do this because, at create time, we really
don't know which engine is going to be used
.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
v3: Factor out a enable_execlists() function so it's clear what the
condition is. Use module parameter to enable.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem.c
From: Ben Widawsky benjamin.widaw...@intel.com
Logical ring contexts do not need most of the ring init: we just need
the pipe control object for the render ring and a few workarounds (some
more stuff to be added later).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
As we said earlier, logical ring contexts created by the user have their
own ringbuffer: not only the backing pages, but the whole management struct.
Since this is now ready, we use the context ringbuffer or the engine's
default ringbuffer depending
From: Oscar Mateo oscar.ma...@intel.com
For a description of this patchset, please check the previous cover letter [1].
Together with this patchset, I'm also submitting an IGT test: gem_execlist [2].
v2:
- Use the same context struct for all the different engines (suggested by Brad
Volkin
From: Oscar Mateo oscar.ma...@intel.com
Thanks to the previous functions and intel_ringbuffer_get(), every function
that needs to be context-aware can get the ringbuffer from the appropriate
place.
Others (either pre-GEN8 or that clearly manipulate the rings's default
ringbuffer)
get
From: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
v2: Set Replay Mode to 0 per BSpec
Michel Thierry michel.thie...@intel.com
v3: Several rebases.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 10
From: Oscar Mateo oscar.ma...@intel.com
We are going to reuse it during logical ring context creation.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
2 files changed, 3 insertions(+), 1
From: Oscar Mateo oscar.ma...@intel.com
We need it (at least) to properly update the last retired head.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b
that we don't waste memory in rings that might not get initialized).
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
Some legacy HW context and ringbuffer code assumptions don't make sense
for this new submission method, so we will place this stuff in a separate
file.
Note for reviewers: I've carefully considered the best name for this file
and this was my best option
Widawsky b...@bwidawsk.net
v2: Several rebases.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
This commit changes the ABI, so it is provided separately so that it can be
dropped by the maintainer is so he wishes.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 6 --
1 file changed, 6 deletions(-)
diff
From: Oscar Mateo oscar.ma...@intel.com
Following the logic behind the previous patch, the ringbuffers and the rings
belong in different structs. For the time being, we will keep the relationship
between the two via the default_ringbuf living inside each ring.
This commit should not introduce
, as the BSpec suggest we do.
- Prevent warning when compiling a 32-bits kernel without HIGHMEM64.
- Add a clarifying comment to the context population code.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 159
From: Oscar Mateo oscar.ma...@intel.com
When we start using Execlists, a context backing object only makes
sense for a given engine (because it will hold state data specific to
it) so multiplex the context struct to contain no-of-engines objects.
In legacy ringbuffer sumission mode, the only
From: Oscar Mateo oscar.ma...@intel.com
Even though we have one Hardware Status Page per context, we are still
managing the seqnos per engine. Therefore, the sequence number must be
written to a consistent place for all contexts: one of the global
default contexts.
Signed-off-by: Thomas Daniel
From: Oscar Mateo oscar.ma...@intel.com
This is mostly for correctness so that we know we are running the LR
context correctly (this is, the PDPs are contained inside the context
object).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4
1 file
From: Oscar Mateo oscar.ma...@intel.com
Each logical ring context has the tail pointer in the context object,
so update it before submission.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff
of the software use-only bits of the Context ID in the Context Descriptor
Format) without the hassle of the previous submission Id construction.
Also, re-add the ELSP porting read (it was dropped somewhere during the
rebases).
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915
-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 27 ++---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 36 -
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 +
4 files changed
From: Oscar Mateo oscar.ma...@intel.com
Finally, start queueing request on ring-submit. Also, remove
remaining legacy context switches.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c| 9 ++---
drivers/gpu/drm/i915/i915_gem_context.c| 10
-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_irq.c | 38 +++-
drivers/gpu/drm/i915/intel_lrc.c| 102 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 1 +
drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
The write tail function is a very special place for execlists: since
all access to the ring is mediated through requests (thanks to
Chris Wilson's Write RING_TAIL once per-request for that) and all
requests end up with a write tail, this is the place we
From: Thomas Daniel thomas.dan...@intel.com
BSPEC says: SW must set Force Wakeup bit to prevent GT from
entering C6 while ELSP writes are in progress.
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
Acked-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Oscar Mateo oscar.ma...@intel.com
v2: Warn and return if LRCs are not enabled.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 74 +
drivers/gpu/drm/i915/i915_reg.h | 7
drivers/gpu/drm/i915
the queue/lock init to the late ring initialization.
- Damien's kmalloc review comments: check return, use sizeof(*req),
do not cast.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/intel_lrc.c| 57
From: Oscar Mateo oscar.ma...@intel.com
In the current Execlists feeding mechanism, full preemption is not
supported yet: only lite-restores are allowed (this is: the GPU
simply samples a new tail pointer for the context currently in
execution).
But we have identified an scenario in which a full
.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
This patch was accidentally dropped in the first Execlists version, and
it has been very useful indeed. Put it back again, but as a standalone
debugfs file.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 52
From: Oscar Mateo oscar.ma...@intel.com
Explain intel_lrc.c with some execlists notes
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
v2: Add notes on logical ring context creation.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 67
From: Oscar Mateo oscar.ma...@intel.com
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915
From: Oscar Mateo oscar.ma...@intel.com
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests and that we re-program the ring for
execution. Also, reset the hangcheck counters.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm
From: Oscar Mateo oscar.ma...@intel.com
If we receive a storm of requests for the same context (see gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking for
contexts to squash together. Instead, share the burden by giving more
intelligence to the queue
From: Oscar Mateo oscar.ma...@intel.com
The time has come, the Walrus said, to talk of many things.
Signed-off-by: Oscar Mateo oscar.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers
From: Oscar Mateo oscar.ma...@intel.com
Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.
TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful
701 - 800 of 865 matches
Mail list logo
