whereas a "context-engine"
would be some sort of engine that processes contexts. Since object and
structure names are noun-like, it's more consistent to name them this way.
Originally-by: Chris Wilson
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
On 08/03/16 09:43, Tvrtko Ursulin wrote:
On 02/03/16 15:40, Dave Gordon wrote:
On 02/03/16 12:08, Chris Wilson wrote:
On Tue, Mar 01, 2016 at 04:33:58PM +, Dave Gordon wrote:
This is essentially Chris Wilson's patch of a similar name, reworked on
top of Alex Dai's recent pa
On 21/03/16 16:58, Arun Siluvery wrote:
On 21/03/2016 10:16, Dave Gordon wrote:
From: Arun Siluvery
Due to timing issues in the HW some of the status bits required for GuC
authentication doesn't get set occassionally, when that happens, GuC
cannot
be initialized and we will be left w
even
avoid some of the issues arising from unpredictable timing.
Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.
Signed-off-by: Dave Gordon
Reviewed-by: Arun Siluvery
Cc: Alex Dai
B
eload mechanism proved helpful when we indeed hit fw
load failure so it is better to include this to improve driver stability.
This change implements the following WA,
WaEnableuKernelHeaderValidFix:skl,bxt
WaEnableGuCBootHashCheckNotSet:skl,bxt
Signed-off-by: Arun Siluvery
Signed-off-by: Dave G
e loop termination,
and many redundant loop-counter variables are eliminated :)
Dave Gordon (2):
drm/i915: introduce for_each_engine_id()
drm/i915: replace for_each_engine()
drivers/gpu/drm/i915/i915_debugfs.c| 94 +++---
drivers/gpu/drm/i915/i915_drv.h
actually need the third argument are updated to use this
version, and the argument (generally 'i') is also updated to be 'id'.
Other callers (where the third argument is unused) are untouched for
now; they will be updated in the next patch.
Signed-off-by: Dave Gordon
---
x27;i').
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 50 +-
drivers/gpu/drm/i915/i915_drv.h| 17 ++
drivers/gpu/drm/i915/i915_gem.c| 50 +-
drivers/gpu/drm/i915/i915_gem_context
x27;i').
v2:
s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson]
Signed-off-by: Dave Gordon
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 50 +-
drivers/gpu/drm/i915/i915_drv.h| 17 ++
drive
On 24/03/16 09:06, Patchwork wrote:
== Series Details ==
Series: drm/i915: fix potential dangling else problems in for_each_ macros
(rev3)
URL : https://patchwork.freedesktop.org/series/1142/
State : failure
== Summary ==
Series 1142v3 drm/i915: fix potential dangling else problems in for_e
On 24/03/16 09:54, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
[ build-script, build and config logs attached ]
Hi Chris,
I am just seeing this (or noticed for the first time, here on
Ubuntu/precise AMD64)...
$ zgrep -A1 -B1 ACLOCAL_FLAGS:
build-and-instal
On 24/03/16 11:11, Sedat Dilek wrote:
From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001
From: Sedat Dilek
Date: Thu, 24 Mar 2016 12:01:37 +0100
Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs
automake problem
---
Makefile.am | 2 +-
1 file change
On 24/03/16 13:42, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 01:32:53PM +, Chris Wilson wrote:
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake sl
On 24/03/16 13:32, Chris Wilson wrote:
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake slightly later instead.
Yes, I had wondered why we armed to tim
On 24/03/16 14:31, Chris Wilson wrote:
__force_wake_get() only acquire a temporary wakeref on forcewake that is
automatically releases when a timer expires. When reading the code
again, I confused __intel_uncore_forcewake_get for __force_wake_get and
to my shame thought I found a bug in an unbala
On 24/03/16 07:40, Joonas Lahtinen wrote:
On ke, 2016-03-23 at 18:02 +0200, Ville Syrjälä wrote:
On Wed, Mar 23, 2016 at 05:54:09PM +0200, Mika Kuoppala wrote:
Ville Syrjälä writes:
[ text/plain ]
On Wed, Mar 23, 2016 at 03:00:22PM +0200, Joonas Lahtinen wrote:
Rename and document the GG
eload mechanism proved helpful when we indeed hit fw
load failure so it is better to include this to improve driver stability.
This change implements the following WA,
WaEnableuKernelHeaderValidFix:skl,bxt
WaEnableGuCBootHashCheckNotSet:skl,bxt
Signed-off-by: Arun Siluvery
Signed-off-by: Dave G
even
avoid some of the issues arising from unpredictable timing.
Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.
Signed-off-by: Dave Gordon
Reviewed-by: Arun Siluvery
Cc: Alex Dai
B
BTW, this two-item patchset was just a repost to get CI to pick it up,
without getting confused by it previously being embedded in a longer set
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/list
On 25/03/16 08:31, Patchwork wrote:
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/guc: Reset GuC and retry on
firmware load failure
URL : https://patchwork.freedesktop.org/series/4876/
State : warning
== Summary ==
Series 4876v1 Series without cover letter
http://patch
On 22/03/16 17:39, Tvrtko Ursulin wrote:
On 22/03/16 17:29, Ville Syrjälä wrote:
On Tue, Mar 22, 2016 at 05:16:52PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Since we write four times to the same register, caching
the mmio register saves a tiny amount of generated code.
The compile
On 24/03/16 12:47, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 12:29:32PM +, Dave Gordon wrote:
On 24/03/16 09:54, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
[ build-script, build and config logs attached ]
Hi Chris,
I am just seeing this (or
On 29/03/16 12:48, Daniel Vetter wrote:
On Thu, Mar 24, 2016 at 06:40:15PM +, Dave Gordon wrote:
After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already
On 01/04/16 08:46, Joonas Lahtinen wrote:
According to Chris, use of i915_vm_to_ppgtt is visible in benchmark
unless WARN_ON is removed, so lets get rid of it.
Cc: Chris Wilson
Reported-by: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_
*/
Might as well correct the grammar here too - I'd suggest "was
successful", or else "went successfully", but the latter still seems
rather clumsy.
Apart from that, they all look good, so
Reviewed-by: Dave Gordon
IIRC there's a tool ("codespell"?) tha
avoid some of the issues arising from unpredictable timing.
Also added some more fields & values to the definition of the GUC_STATUS
register, which is the key diagnostic indicator if the GuC load fails.
Signed-off-by: Dave Gordon
Reviewed-by: Arun Siluvery
Cc: Alex Dai
B
This is a resend, primarily for CI purposes. All patches to be
merged have already been reviewed. The final patch (NOT to be
merged) enables GuC loading and submission for testing purposes.
Arun Siluvery (1):
drm/i915/guc: reset GuC and retry on firmware load failure
Dave Gordon (2):
drm
are), and to fall back to execlist mode if any
required firmware cannot be found or fails to load.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 1 -
drivers/gpu/drm/i915/i915_params.c | 14 -
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i91
uvery
Signed-off-by: Dave Gordon
Reviewed-by: Alex Dai
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_guc_reg.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_guc_loader.c | 49 +++--
drivers/gpu/drm
force-wake domains exist, or with unrelated timers.
For GlBench/T-Rex this decreases the number of forcewake releases from
~480 to ~300 per second, and for a heavy combined OGL/OCL test from
~670 to ~360.
Signed-off-by: Tvrtko Ursulin
LGTM.
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/
above, plus a minor quibble about a macro
name (which you haven't actually changed, but might as well fix).
Otherwise LGTM, so
Reviewed-by: Dave Gordon
(even if you don't change the macro name)
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h
On 04/04/16 19:58, Chris Wilson wrote:
On Mon, Apr 04, 2016 at 05:51:09PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Current implementation releases the forcewake at any time between
straight away, and one jiffie from the last put, or first automatic
grab.
That isn't the problem thoug
On 05/04/16 07:56, Patchwork wrote:
== Series Details ==
Series: GuC reset-and-retry patches (resend)
URL : https://patchwork.freedesktop.org/series/5287/
State : failure
== Summary ==
Series 5287v1 GuC reset-and-retry patches (resend)
http://patchwork.freedesktop.org/api/1.0/series/5287/rev
On 06/04/16 11:05, Chris Wilson wrote:
On Wed, Apr 06, 2016 at 10:49:36AM +0100, Tvrtko Ursulin wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 985f067c1f0e..dc8e1b76c896 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.
To properly verify the driver->doorbell->GuC functionality, validation
needs to know how the driver has assigned the doorbell cache lines and
registers, so make them visible through debugfs.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
1 file chan
e doorbell management code, this function is somewhat
time-critical, so putting it near its caller may even yield a tiny
performance improvement.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 128 +++--
1 file changed, 67 insertions(+), 61
at all the doorbell hardware is left in a consistent state,
no matter how it was programmed by the previously-running kernel and/or
GuC firmware.
This patch can be removed if/when the GuC firmware is updated so that it
(re)initialises the doorbell hardware after every firmware (re)load.
Signed-of
eload fails, we don't recreate the client, so fallback
to execlists mode (if active) won't leak the client object (previously,
the now-unusable client would have been left allocated, and leaked if
the driver were unloaded).
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_s
(or in some cases workarounds)
for the various issues identified in this area.
Cc: Alex Dai
Cc: Tom O'Rourke
Cc: Arun Siluvery
Dave Gordon (5+1):
drm/i915/guc: add doorbell map to debugfs/i915_guc_info
drm/i915/guc: move guc_ring_doorbell() nearer to callsite
drm/i915/guc: ref
During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a later
one which will resolve the issue.
Signed-off-by: Dave Gordon
---
drivers/gp
are), and to fall back to execlist mode if any
required firmware cannot be found or fails to load.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 1 -
drivers/gpu/drm/i915/i915_params.c | 14 -
drivers/gpu/drm/i915/i915_params.h | 3 +-
drivers/gpu/drm/i91
te *DEV_PRIV = E;
)
<...
INTEL_INFO
(
- DEV
+ DEV_PRIV
)
...>
}
followed by manually deleting 6 now-unused "dev" locals.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 66 +++---
drivers/gpu/drm/
On 08/04/16 09:24, Jani Nikula wrote:
On Thu, 07 Apr 2016, Dave Gordon wrote:
Since Jani has given us this macro, I thought I'd make use of it by
converting all existing instances of this construct with a really
simple little Coccinelle script:
@intel_gen@
express
On 08/04/16 07:09, Joonas Lahtinen wrote:
On to, 2016-04-07 at 18:57 +0100, Dave Gordon wrote:
Where we have a suitable dev_priv pointer, we can use that rather than
'dev' for accessing INTEL_INFO(). This removes one level of memory
reference, decreasing code size a little and possi
Hi,
background to this is that one of our validation engineers has written
a test that creates a batch that loops by jumping backwards using
MI_BATCH_BUFFER_START to an address earlier in the batchbuffer, with
whatever instruction sequence is being tested inside the loop.
This works perfectly wel
On 07/04/16 22:26, Yu Dai wrote:
On 04/07/2016 10:21 AM, Dave Gordon wrote:
During a hibernate/resume cycle, the driver, the GuC, and the doorbell
hardware can end up in inconsistent states. This patch refactors the
driver's handling and tracking of doorbells, in preparation for a late
On 11/04/16 17:40, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 03:57:21PM +0100, Tvrtko Ursulin wrote:
On 11/04/16 15:44, Chris Wilson wrote:
On Mon, Apr 11, 2016 at 03:25:41PM +0100, Tvrtko Ursulin wrote:
On 08/04/16 12:11, Chris Wilson wrote:
When called because we have run out of vmap ad
should keep it local and avoid exporting a bogus pointer. Also, for
clarity and symmetry, we should clear 'virtual_start' along with 'vma'
when unmapping a ringbuffer.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h
On 12/04/16 14:51, Michał Winiarski wrote:
We started to use PIPE_CONTROL to write render ring seqno in order to
combat seqno write vs interrupt generation problems. This was introduced
by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt
generation on gen8+ execlists").
On gen8+
On 12/04/16 17:03, Patchwork wrote:
== Series Details ==
Series: series starting with drm/i915: check for ERR_PTR from
i915_gem_object_pin_map() (rev2)
URL : https://patchwork.freedesktop.org/series/5591/
State : failure
== Summary ==
Series 5591v2 Series without cover letter
http://patchwo
On 13/04/16 17:57, Ben Widawsky wrote:
For debug and development purposes only.
Cc: Mika Kuoppala
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 +
drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++
drivers/gpu/drm/i915/i915_params.c | 6 +
On 13/04/16 18:50, Yu Dai wrote:
On 04/07/2016 10:21 AM, Dave Gordon wrote:
During a hibernate/resume cycle, the whole system is reset, including
the GuC and the doorbell hardware. Then the system is booted up, drivers
are loaded, etc -- the GuC firmware may be loaded and set running at this
er (4 pages) or a
context image (currently up to 22 pages).
v5:
change name of local array [Chris Wilson]
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Alex Dai
---
drivers/gpu/drm/i915/i915_gem.c | 17 +++--
1 file changed, 11 insertions(+), 6 d
tions
from i915_gem_object_pin_map() and i915_gem_object_put_pages() into
separate functions that can then be shared by the command parser.
With this change, we have only one vmap() call in the whole driver :)
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gp
On 13/04/16 21:14, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 09:00:53PM +0100, Dave Gordon wrote:
From: Alex Dai
The recent pin-and-map unification didn't include the command parser's
own custom vmapping code, which essentially duplicates the same
algorithm but without s
On 14/04/16 12:58, Tvrtko Ursulin wrote:
On 14/04/16 12:30, Chris Wilson wrote:
On Thu, Apr 14, 2016 at 12:24:20PM +0100, Tvrtko Ursulin wrote:
On 14/04/16 12:16, Chris Wilson wrote:
On Thu, Apr 14, 2016 at 11:59:29AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We know ringbuffers a
[ 34.098911] [] entry_SYSCALL_64_fastpath+0x12/0x6a
[ 34.100208] [ cut here ]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93847
Cc:
Cc:
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 21 -
1
ai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 16
drivers/gpu/drm/i915/intel_guc.h | 2 +-
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submissi
objects, and updates the various setup/shutdown functions to use these
long-term mappings rather than doing their own kmap_atomic() calls.
Cc:
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 37 +++---
drivers/gpu/drm
On 15/04/2016 11:04, Tvrtko Ursulin wrote:
On 14/04/16 18:19, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are always pinned in memory and in the GGTT anyway)
mapped into kernel address space, rather than mapping and unmapping them
d in
i915_drm.h, and they start from the LSB and work up.
Other flags are defined in i915_gem_execbuffer, for internal use within
that file only; they start from the MSB and work down.
So here we add a compile-time check that the two sets of flags do not
overlap, which would cause all sorts of confus
ry(eb->vmas.prev, ...)"
in eb_get_batch() with the equivalent but more explicit
"list_last_entry(&eb->vmas,...)"
and of course add an explanatory comment.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++-
1 file changed, 2 inse
list is created.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 50 +-
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index bc97670
Reche
Signed-off-by: Dave Gordon
Cc: Miguel Reche
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 3a60146..c0
On 15/04/2016 12:43, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 12:32:57PM +0100, Dave Gordon wrote:
There is a problem with the relocation of batches submitted with the
I915_EXEC_SECURE flag: although the batch itself will be mapped into the
GGTT, any relocations referring to it will use its
rather than checking for NULL (Tvrtko Ursulin)
Added big comment about struct i915_guc_client & usage of the GEM
object that it describes
Cc:
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h| 12 ++
drivers/g
[ 34.098911] [] entry_SYSCALL_64_fastpath+0x12/0x6a
[ 34.100208] [ cut here ]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93847
Cc:
Cc:
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 21 -
1
w calls
by caching results in local variables.
v2:
Added local optimisations (Dave Gordon)
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 54 --
drivers/gpu/drm/i915/intel_guc.h | 2 +-
2 files c
On 18/04/16 10:18, Jani Nikula wrote:
On Fri, 15 Apr 2016, Chris Wilson wrote:
Final canvas for opinions for using a magic macro to reduce typing in
the common operation of getting our drm_i915_private from the object.
21 files changed, 333 insertions(+), 392 deletions(-)
Not to menti
On 18/04/16 11:25, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are always pinned in memory and in the GGTT anyway)
mapped into kernel address space, rather than mapping
0x3c/0x70
[] entry_SYSCALL_64_fastpath+0x12/0x6a
[ cut here ]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93847
Original-version-by: Alex Dai
Signed-off-by: Dave Gordon
Cc: Tvtrko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 40 +-
Tidying up guc_init_proc_desc() and adding commentary to the client
structure after the recent change in GuC page mapping strategy.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 38 ++
drivers/gpu/drm/i915/intel_guc.h | 23
From: Alex Dai
Now that we keep the GuC client process descriptor permanently mapped,
we don't really need to keep a local copy of the GuC's work-queue-head.
So we can simplify the code a little by not doing this.
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gp
On 18/04/16 12:37, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 12:28:43PM +0100, Dave Gordon wrote:
On 18/04/16 11:25, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote:
With the new i915_gem_obj_pin_map() interface, it makes sense to keep
GuC objects (which are
On 13/04/16 15:21, John Harrison wrote:
On 13/04/2016 10:57, Daniel Vetter wrote:
On Tue, Apr 12, 2016 at 09:03:09PM +0100, Chris Wilson wrote:
Conceptually, each request is a record of a hardware transaction - we
build up a list of pending commands and then either commit them to
hardware, or c
From: Alex Dai
Now that we keep the GuC client process descriptor permanently mapped,
we don't really need to keep a local copy of the GuC's work-queue-head.
So we can simplify the code a little by not doing this.
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gp
i
Signed-off-by: Dave Gordon
Cc: Tvtrko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 66 +-
drivers/gpu/drm/i915/intel_guc.h | 2 +
2 files changed, 30 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/dr
Tidying up guc_init_proc_desc() and adding commentary to the client
structure after the recent change in GuC page mapping strategy.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 38 ++
drivers/gpu/drm/i915/intel_guc.h | 23
On 19/04/16 15:45, tim.g...@intel.com wrote:
From: Tim Gore
WaEnableSamplerGPGPUPreemptionSupport fixes a problem
related to mid thread pre-emption.
Signed-off-by: Tim Gore
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915
On 19/04/16 16:08, Tvrtko Ursulin wrote:
On 19/04/16 12:45, Dave Gordon wrote:
Tidying up guc_init_proc_desc() and adding commentary to the client
structure after the recent change in GuC page mapping strategy.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 38
On 19/04/16 17:24, Patchwork wrote:
== Series Details ==
Series: series starting with [1/3] drm/i915/guc: keep GuC doorbell & process
descriptor mapped in kernel
URL : https://patchwork.freedesktop.org/series/5942/
State : failure
== Summary ==
Series 5942v1 Series without cover letter
http
er (4 pages) or a
context image (currently up to 22 pages).
v5:
change name of local array [Chris Wilson]
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
dif
ical
structure a bit clearer and easier to modify.
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 61 +++--
1 file changed, 40 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/
On 19/04/16 20:50, Chris Wilson wrote:
On Tue, Apr 19, 2016 at 06:40:07PM +0100, Dave Gordon wrote:
From: Alex Dai
The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code,
t clearer and easier to modify.
v2:
Restructure loop-over-pages & error check (Chris Wilson)
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 58 ++---
1 file changed, 37 insertions(+), 21 deletions(
er (4 pages) or a
context image (currently up to 22 pages).
v5:
change name of local array [Chris Wilson]
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
dif
On 20/04/16 14:30, Dave Gordon wrote:
The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code, this patch pulls out the "mapping" part of
the operation (involvi
On 20/04/16 13:57, Daniel Vetter wrote:
On Mon, Apr 18, 2016 at 12:18:23PM +0300, Jani Nikula wrote:
On Fri, 15 Apr 2016, Chris Wilson wrote:
Final canvas for opinions for using a magic macro to reduce typing in
the common operation of getting our drm_i915_private from the object.
21
On 15/04/16 18:46, Chris Wilson wrote:
To open up the future of using a generic to_i915() convenience macro,
rename the existing __I915__ superconvenience macro.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 22 +++---
1 file changed, 11 insertions(+), 11
On 15/04/16 12:26, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 10:16:25AM +0100, Peter Antoine wrote:
Thanks for tidying up and pushing.
Fwiw, I extended the test to demonstrate that !rcs engines are also
suspectible to the same pollution where one process can affect the
register settings of a
On 13/04/16 21:13, Yu Dai wrote:
On 04/13/2016 12:46 PM, Dave Gordon wrote:
On 13/04/16 18:50, Yu Dai wrote:
>
> On 04/07/2016 10:21 AM, Dave Gordon wrote:
>> During a hibernate/resume cycle, the whole system is reset, including
>> the GuC and the doorbell hardware. Then the s
On 08/04/16 08:59, Patchwork wrote:
gem_ctx_switch:
Subgroup basic-default:
skip -> PASS (bsw-nuc-2)
pass -> DMESG-WARN (skl-i7k-2)
Known bug:
https://bugs.freedesktop.org/show_bug.cgi?id=93847
"GuC is calling a sleeping function in a
On 06/10/15 09:38, Daniel Vetter wrote:
On Mon, Oct 05, 2015 at 05:59:50PM +0100, Michel Thierry wrote:
On 10/5/2015 5:36 PM, Dave Gordon wrote:
On 02/10/15 14:16, Michel Thierry wrote:
We tried to fix this in commit fdc454c1484a ("drm/i915: Prevent out of
range pt in gen6_for_eac
he
execbuffer path), but I'm all in favour of getting rid of the legacy
crud cluttering up this code, so ...
Reviewed-by: Dave Gordon
Perhaps we could get rid of relative-constants-mode next :)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i91
On 08/10/15 11:22, Tvrtko Ursulin wrote:
Hi,
On 08/10/15 07:24, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
Propagating correct error codes to userspace by using ERR_PTR and
PTR_ERR macros for stolen memory based object allocation. We generally
return -ENOMEM to the user w
On 09/10/15 18:26, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 07:14:02PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 10:03:14AM +0100, Tvrtko Ursulin wrote:
On 09/10/15 09:55, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 09:40:53AM +0100, Chris Wilson wrote:
On Fri, Oct 09, 2015 at
ers/gpu/drm/i915/intel_guc_loader.c | 93 -
6 files changed, 151 insertions(+), 38 deletions(-)
The code looks OK; the CSS header fields are adequately checked now, so:
Reviewed-by: Dave Gordon
with one note about the DocBook change below:
diff --git a/Documentation/
On 08/10/15 15:45, Animesh Manna wrote:
On 10/8/2015 5:53 PM, Mika Kuoppala wrote:
Animesh Manna writes:
On 9/21/2015 2:00 PM, Mika Kuoppala wrote:
Jani Nikula writes:
On Fri, 18 Sep 2015, Mika Kuoppala
wrote:
If csr/dmc firmware is known to be outdated, notify
user.
What would break
lt mode in the other context, submit another batch
in the first context, but this time in default mode. The driver will
fail to insert the instructions to reset INSTPM into the first context's
ringbuffer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448
Signed-off-by: Dave Gordon
-
On 17/09/15 14:20, Damien Lespiau wrote:
Not the first time! not the last time?
There is a possibility to use gcc 5's -Wbool-compare to try and compare
(reg) in those macros to a constant and gcc will warn that the
comparison between a boolean expression and a constant is always either
true or f
601 - 700 of 1151 matches
Mail list logo
