On 13/10/15 12:36, Chris Wilson wrote:
On Tue, Oct 13, 2015 at 01:29:56PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 06:23:50PM +0100, Chris Wilson wrote:
On Fri, Oct 09, 2015 at 07:18:21PM +0200, Daniel Vetter wrote:
On Fri, Oct 09, 2015 at 10:45:35AM +0100, Chris Wilson wrote:
On F
On 13/10/15 16:28, Daniel Vetter wrote:
On Tue, Oct 13, 2015 at 02:20:05PM +0100, Dave Gordon wrote:
'relative_constants_mode' has always been tracked per-device, but this
is wrong in execlists (or GuC) mode, as INSTPM is saved and restored
with the logical context, and the per-con
2) Add and correct GuC related topics in kernel/Doc
Signed-off-by: Alex Dai
---
Docbook looks OK now, and the code is the same as last version I
reviewed, so ...
Reviewed-by: Dave Gordon
Documentation/DocBook/gpu.tmpl | 12 ++--
drivers/gpu/drm/i915/i915_debugfs.c| 6
spinlock functions.
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
LGTM.
Reviewed-by: Dave Gordon
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e57061a
ll 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
---
drivers/gpu/drm/i915/i915_drv.h| 2 --
drivers/gpu/drm/i915/i915_gem.c| 2 --
drive
On 23/10/15 12:02, Tomas Elf wrote:
On 23/10/2015 09:59, Daniel Vetter wrote:
On Fri, Oct 23, 2015 at 09:42:27AM +0100, Tvrtko Ursulin wrote:
On 19/10/15 16:32, Tomas Elf wrote:
Grab execlist lock when cleaning up execlist queues after GPU reset
to avoid
concurrency problems between the conte
On 23/10/15 10:14, Daniel Vetter wrote:
On Fri, Oct 23, 2015 at 10:03:50AM +0100, Chris Wilson wrote:
On Fri, Oct 23, 2015 at 10:56:12AM +0200, Daniel Vetter wrote:
We get tons of cases where the master interrupt handler apparently set
a bit, with the SDEIIR agreeing. No idea what's going on th
On 08/10/15 21:50, Wayne Boyer wrote:
From: Chris Wilson
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied
On 21/10/15 19:27, yu@intel.com wrote:
From: Alex Dai
There is a memory leak warning message from i915_gem_context_clean
when GuC submission is enabled. The reason is that gem_request (so
the LRC associated with it) is freed early than moving the vma list
to inactive.
We are not seeing thi
ation.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01b1eea..20777e4 100644
--- a/dr
;default_pointer (still) being set up; to iterate over engines
in reverse, as this is teardown code; and to reduce the nesting
level so it's easier to read.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
but multiple pointers.
From an idea by Chris Wilson.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/i915_gem.c| 5 +++--
drivers/gpu/drm/i915
ewritten to use it. This makes the logic more obvious, and usually
saves at least one memory reference.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 +++-
drivers/gpu/drm/i915/i915_gem.c | 8 ++--
drivers/gpu/drm/i915/inte
A collection of patches to simplify the creation, use, and destruction
of the driver's global default context.
The first two simplify the many places where the code treats the
global default context differently from any other context:
[1/6] drm/i915: mark the global default (intel
ister accesses from intel_cleanup_ring_buffer()
(which calls intel_stop_ring_buffer(ring) which calls stop_ring())
down into stop_ring() itself), which is already doing low-level
register accesses. Then, intel_cleanup_ring_buffer() no longer
needs 'dev_priv'.
Signed-off-
doing such request allocations and
changes all such calls to use the new function.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 36
drivers/gpu/drm/i915/intel_display.c
On 22/12/15 09:08, Chris Wilson wrote:
On Mon, Dec 21, 2015 at 04:04:40PM +, Dave Gordon wrote:
Some of the LRC-specific context-destruction code has to special-case
the global default context, bacause the HWSP is part of that context. At
present it deduces it indirectly by checking for the
On 22/12/15 09:05, Chris Wilson wrote:
On Mon, Dec 21, 2015 at 04:04:41PM +, Dave Gordon wrote:
There are quite a number of places where the driver tests whether a
given context is or is not the global default context, usually by
checking whether an engine's default_pointer points t
On 22/12/15 09:08, Chris Wilson wrote:
On Mon, Dec 21, 2015 at 04:04:42PM +, Dave Gordon wrote:
There are a number of places where the driver needs a request, but isn't
working on behalf of any specific user or in a specific context. For
such requests, we associate them with the de
er to handle the error.
v1: Move wq_reserve_space to ring_reserve_space
v2: Move wq_reserve_space to alloc_request_extras (Chris Wilson)
v3: The work queue head pointer is cached by driver now. So we can
quickly return if space is available.
s/reserve/check/g (Dave Gordon)
v4: Update cached wq
such calls to use the new function.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 39 +++-
drivers/gpu/drm/i915/intel_display.c | 6 --
drivers/gpu/drm/i915/intel_over
ntext pointer refers back to the context
being operated on. In a subsequent patch, these backpointers will go
away too :)
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem_context.c | 22 --
2 files changed, 14 inser
ts these can be rewritten to use it. This makes the
logic more obvious, and usually saves at least one memory reference.
In addition, with these uses eliminated, a future patch will be able
to get rid of engine::default_context entirely.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915
A reworking of the previous patchset, incorporating Daniel Vetter's
point that we don't need intel_context::file_priv and Chris Wilson's
wish to abolish engine::default_context.
Patch 1/4 starts the process by eliminating file_priv, which was only used
in one place. Patch 2/4 removes lots of refer
make refcounting more sensible
too, as we now have a refcount of one for the one pointer, rather than
a refcount of one but multiple pointers.
From an idea by Chris Wilson.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/i915_gem.c
Replace the for_each_ring() macro with for_each_engine() wherever
the third (index) argument is (or can be made) unused. This often
allows us to delete the associated local variable as well.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Dave Gordon
---
drivers/gpu/drm
other
source files.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 32
drivers/gpu/drm/i915/intel_uncore.c | 5 ++---
2 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/driver
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now that we have split out the seqno-barrier from the
engine->get_seqno() callback itself, we can move the users of the
seqno-barrier to the requir
On 12/12/15 15:34, Chris Wilson wrote:
dma-buf provides a generic fence class for interoperation between
drivers. Internally we use the request structure as a fence, and so with
only a little bit of interfacing we can rebase those requests on top of
dma-buf fences. This will allow us, in the futu
On 04/01/16 11:26, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now that we have split out the seqno-barrier
On 04/01/16 13:02, Dave Gordon wrote:
On 04/01/16 11:26, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now
On 29/12/15 19:18, Chris Wilson wrote:
On Tue, Dec 29, 2015 at 06:59:57PM +, Dave Gordon wrote:
In the discussions around commit 373701b1 (Jani Nikula)
drm: fix potential dangling else problems in for_each_ macros
Daniel Vetter mooted the idea of a for_each_engine(ring, dev_priv)
macro
On 16/12/15 10:19, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote:
As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the requ
On 04/01/16 14:20, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 02:09:53PM +, Dave Gordon wrote:
On 04/01/16 13:02, Dave Gordon wrote:
On 04/01/16 11:26, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14
On 23/12/15 21:02, Chris Wilson wrote:
On Wed, Dec 23, 2015 at 07:33:53PM +, Dave Gordon wrote:
There are quite a number of places where the driver tests whether
a given context is or is not the global default context, usually by
checking whether an engine's default_pointer points t
On 04/01/16 16:10, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 03:58:21PM +, Dave Gordon wrote:
On 16/12/15 10:19, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote:
@@ -1288,7 +1286,7 @@ int
On 11/12/15 11:33, Chris Wilson wrote:
By using the same address for storing the HWS on every platform, we can
remove the platform specific vfuncs and reduce the get-seqno routine to
a single read of a cached memory location.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
-
drivers/gpu/drm/i915/intel_guc_loader.c| 7 ++
drivers/gpu/drm/i915/intel_lrc.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.h | 1 +
7 files changed, 220 insertions(+), 3 deletions(-)
For the whole series,
Reviewed-by: Dave Gordon
This function was recently renamed & exposed, so now it gets documented
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8da67b3..366
On 11/12/15 11:33, Chris Wilson wrote:
In order to ensure seqno/irq coherency, we current read a ring register.
We are not sure quite how it works, only that is does. Experiments show
that e.g. doing a clflush(seqno) instead is not sufficient, but we can
remove the forcewake dance from the mmio a
On 05/01/16 10:06, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 01:38:26PM -0800, Jesse Barnes wrote:
On 01/04/2016 11:39 AM, Chris Wilson wrote:
This series is NAKed.
Why? Because you want things in a different order? Or do you object to
something in Dave's reply?
The series was intended
During startup, the driver creates a unique "intel_context" that will
provide a home for orphan requests (i.e. those generated by the driver
internally, not associated with user batchbuffers).
However, one of the infelicities of the current code is that the driver
keeps a per-engine pointer to the
his make refcounting more sensible
too, as we now have a refcount of one for the one pointer, rather than
a refcount of one but multiple pointers.
From an idea by Chris Wilson.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
drivers/gpu/drm/i915/i915_drv.h
On 07/01/16 14:36, Daniel Vetter wrote:
On Thu, Jan 07, 2016 at 03:06:13PM +0200, Jani Nikula wrote:
On Thu, 07 Jan 2016, Dave Gordon wrote:
On 06/01/16 10:20, Patchwork wrote:
== Summary ==
Built on 24b053acb16b4b3b021575e4ee30ffedd3ab2920 drm-intel-nightly:
2016y-01m-06d-08h-16m-11s UTC
On 11/01/16 09:06, Daniel Vetter wrote:
On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 08:44:29AM +, Chris Wilson wrote:
Some stress tests create both the signal helper and a lot of compet
On 07/01/16 16:56, Chris Wilson wrote:
On Thu, Jan 07, 2016 at 12:34:39PM +, Dave Gordon wrote:
On 07/01/16 11:58, Chris Wilson wrote:
On Thu, Jan 07, 2016 at 10:20:50AM +, Dave Gordon wrote:
There are a number of places where the driver needs a request, but isn't
working on beha
On 11/01/16 12:34, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 12:25:07PM +, Dave Gordon wrote:
On 11/01/16 09:06, Daniel Vetter wrote:
On Mon, Jan 11, 2016 at 08:54:59AM +, Chris Wilson wrote:
On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 08
On 11/01/16 09:16, Chris Wilson wrote:
In order to ensure seqno/irq coherency, we current read a ring register.
We are not sure quite how it works, only that is does. Experiments show
that e.g. doing a clflush(seqno) instead is not sufficient, but we can
remove the forcewake dance from the mmio a
On 11/01/16 10:44, Chris Wilson wrote:
We have a false notion of a default_context allocated per engine,
whereas actually it is a singular context reserved for kernel use.
Remove it from the engines, and rename it thus.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
| 39
drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 4 ++--
9 files changed, 53 insertions(+), 56 deletions(-)
All looks OK, so
Reviewed-by: Dave Gordon
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/g
is the right place for the magic, but
at least it's preferable to having a lazy_coherency parameter. So on the
basis that the proper review criterion is "better than before, and
creates no new problems", and not "fixes all known issues", then
Reviewed-by: Dave Gor
On 11/01/16 08:31, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 11:29:43AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
LRCA can change only when it goes from unpinned to pinned so it
makes sense to check its alignment at that point rather than at
every batch buffer submission.
Furthermo
On 08/01/16 11:29, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Purpose is to avoid calling i915_gem_obj_ggtt_offset from the
interrupt context without the big lock held.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c| 3 +--
drivers/gpu/drm/i915/intel_ringbuffer.
On 11/01/16 08:38, Daniel Vetter wrote:
On Fri, Jan 08, 2016 at 11:29:44AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We are not allowed to call i915_gem_obj_ggtt_offset from irq
context without the big kernel lock held.
LRCA lifetime is well defined so cache it so it can be looked up
On 11/01/16 09:16, Chris Wilson wrote:
By using the same address for storing the HWS on every platform, we can
remove the platform specific vfuncs and reduce the get-seqno routine to
a single read of a cached memory location.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
On 06/01/16 20:53, yu@intel.com wrote:
From: Alex Dai
During driver unloading, the guc_client created for command submission
needs to be released to avoid memory leak.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_guc_submission.c | 3 +++
1 file changed, 3 insertions(+)
diff
On 07/01/16 16:53, Chris Wilson wrote:
On Thu, Jan 07, 2016 at 08:49:38AM -0800, Jesse Barnes wrote:
On 01/07/2016 03:58 AM, Chris Wilson wrote:
On Thu, Jan 07, 2016 at 10:20:50AM +, Dave Gordon wrote:
There are a number of places where the driver needs a request, but isn't
worki
On 12/01/2016 11:43, John Harrison wrote:
On 12/01/2016 04:37, Tian, Kevin wrote:
From: john.c.harri...@intel.com
Sent: Tuesday, January 12, 2016 2:42 AM
From: John Harrison
Implemented a batch buffer submission scheduler for the i915 DRM
driver.
The general theory of operation is that whe
name.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 15 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 -
drivers/gpu/drm/i915/intel_lrc.c
indirection through parameter bad.
Reviewed-by: Dave Gordon
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 12/01/16 13:11, Chris Wilson wrote:
On Tue, Jan 12, 2016 at 12:54:25PM +, Tvrtko Ursulin wrote:
On 12/01/16 12:12, Chris Wilson wrote:
On Tue, Jan 12, 2016 at 11:56:11AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
LRC lifetime is well defined so we can cache the page pointing
t
On 11/01/16 09:17, Chris Wilson wrote:
If is simpler and leads to more readable code through the callstack if
the allocation returns the allocated struct through the return value.
The importance of this is that it no longer looks like we accidentally
allocate requests as side-effect of calling c
On 11/01/16 09:17, Chris Wilson wrote:
Both perform the same actions with more or less indirection, so just
unify the code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_gem_context.c| 8 +-
drivers/gpu/drm/i915/i915_gem
On 11/01/16 09:16, Chris Wilson wrote:
Currently there is a #define to enable extra BUG_ON for debugging
requests and associated activities. I want to expand its use to cover
all of GEM internals (so that we can saturate the code with asserts).
We can add a Kconfig option to make it easier to ena
On 11/01/16 09:16, Chris Wilson wrote:
As we add the VMA to the request early, it may be cancelled during
execbuf reservation. This will leave the context object pointing to a
dangling request; i915_wait_request() simply skips the wait and so we
may unbind the object whilst it is still active.
+-
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 +--
8 files changed, 46 insertions(+), 43 deletions(-)
LGTM.
Reviewed-by: Dave Gordon
[aside]
The conditions below seem to exclude a lot of systems. It looks like
semaphores can
On 12/01/16 13:53, Daniel Vetter wrote:
On Thu, Jan 07, 2016 at 10:20:52AM +, Dave Gordon wrote:
There are a few bits of code which the transformations implemented by
the previous patch reveal to be suboptimal, once the notion of a per-
ring default context has gone away. So this tidies up
On 12/01/16 14:27, Chris Wilson wrote:
On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote:
But we were removing the engine->default_context as it complicated the
rest of the code. I strongly prefer keeping the contexts explicit as
context separation should be first and foremost in the
On 13/01/16 12:53, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 11:44:39AM +0100, Artur Harasimiuk wrote:
Starting from Gen9 we can use IA-Coherent caches. Coherence may be not
required in certain cases and can be disabled in an easy way. To do this
we can set HDC_FORCE_NON_COHERENT bit in HDC_CH
i915_guc_submission_fini and
take struct_mutex lock before release GuC client. (Dave Gordon)
You don't seem to have implemented all the points I mentioned? I think
you want:
drivers/gpu/drm/i915/intel_guc_loader.c:
@@ -445,6 +445,7 @@ int intel_guc_ucode_load(struct drm_device
On 13/01/16 13:41, Chris Wilson wrote:
On Wed, Jan 13, 2016 at 01:27:51PM +, Dave Gordon wrote:
On 12/01/16 14:27, Chris Wilson wrote:
On Tue, Jan 12, 2016 at 01:56:48PM +, Chris Wilson wrote:
But we were removing the engine->default_context as it complicated the
rest of the code
On 13/01/16 18:17, Yu Dai wrote:
On 01/13/2016 10:15 AM, Dave Gordon wrote:
On 12/01/16 23:17, yu@intel.com wrote:
> From: Alex Dai
>
> During driver unloading, the guc_client created for command submission
> needs to be released to avoid memory leak.
>
> The struct_mute
instances of and references to the
structure rather than the abstract type. But it doesn't actually do any
harm, so with or without the redundant 'const' it gets:
Reviewed-by: Dave Gordon
___
Intel-gfx mailing list
Intel-gfx@lists.freed
i915_guc_submission_fini and
take struct_mutex lock before release GuC client. (Dave Gordon)
v2: Add the locking for failure case in guc_fw_fetch. (Dave Gordon)
Add i915_guc_submission_fini for failure case in intel_guc_ucode_load.
Signed-off-by: Alex Dai
LGTM.
Reviewed-by: Dave Gordon
diff --git
graphics device = %lluM\n",
gtt->base.total >> 20);
LGTM.
Reviewed-by: Dave Gordon
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
nce.
Now why didn't I think of that? That looks like such a good idea, we
should apply it in other CONTEXTs!
Reviewed-by: Dave Gordon
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
mp;req);
if (err) ...
NEW:
req = i915_gem_request_alloc(ring, NULL);
if (IS_ERR(req)) ...
v4: Rebased
Signed-off-by: Dave Gordon
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h| 6 ++--
drivers/gpu/drm/i915/i915_gem.c| 55 ++
During startup, the driver creates a unique "intel_context" that will
provide a home for orphan requests (i.e. those generated by the driver
internally, not associated with user batchbuffers).
However, one of the infelicities of the current code is that the driver
keeps a per-engine pointer to the
he multiple (per-ring) pointers to the default context with a single
pointer to the unique kernel context.
v4: Rebased, remove underused local (Nick Hoath)
Signed-off-by: Dave Gordon
Reviewed-by: Nick Hoath
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 4 ++--
driv
less clearly a simple transformation. In particular, any
change which alters the code block structure or indentation has been
deferred into this separate patch, because such things tend to make
diffs more difficult to read.
v4: Rebased
Signed-off-by: Dave Gordon
Reviewed-by: Nick Hoath
On 20/01/16 07:49, Patchwork wrote:
== Summary ==
Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly:
2016y-01m-19d-19h-38m-52s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-nuci7) UNSTABLE
http
_page(), making sure that they both
take the same argument (pointer to engine). They encapsulate all the details
of the relationship between the default context and the status page, so the
rest of the LRC code doesn't have to know about it.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_
Also includes Nick Hoath's patch to swap context/engine teardown.
In-Reply-To:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ation.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 799a53a..041e0e1 100644
--- a/dr
ister accesses from intel_cleanup_ring_buffer()
(which calls intel_stop_ring_buffer(ring) which calls stop_ring())
down into stop_ring() itself), which is already doing low-level
register accesses. Then, intel_cleanup_ring_buffer() no longer
needs 'dev_priv'.
Signed-off-
at it actually does
(cleanup engines, not a ringbuffer), and fix an annoying whitespace issue.
v2: Also make the fix in i915_load_modeset_init, not just in
i915_driver_unload (Chris Wilson)
v3: Had extra stuff in it.
v4: Reverted extra stuff (so we're back to v2).
Rebased and updated comme
On 21/01/16 19:37, Dave Gordon wrote:
Also includes Nick Hoath's patch to swap context/engine teardown.
In-Reply-To:
Hmm, editor/mailer seems to have dropped most of this summary :(
Probably something to do with that IRT-line above ... what it was
supposed to say was approximately
tests need to be
updated to accommodate this case.
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
On 22/01/16 10:28, Mika Kuoppala wrote:
Dave Gordon writes:
Existing code did a kunmap() on the wrong page, and didn't account for the
fact that the HWSP and the default context are different offsets within the
same GEM object.
Just to note here that usually we try to split bug fixes
On 22/01/16 07:42, Patchwork wrote:
== Summary ==
Built on 8fe9e785ae04fa7c37f7935cff12d62e38054b60 drm-intel-nightly:
2016y-01m-21d-11h-02m-42s UTC integration manifest
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-a-frame-sequence:
pass -> DMESG-WARN (ilk-hp
as first implemented.
v2:
Split from "handle teardown of HWSP when context is freed".
Signed-off-by: Dave Gordon
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/int
Various things can go wrong during initialisation and teardown, but they
usually don't, so the error-handling paths go largely untested. This
collection of patches fixes some things I recently noticed. Some might
lead to a kernel OOPS, but mostly they're leaks and other inconsistencies.
Includes
at it actually does
(cleanup engines, not a ringbuffer), and fix an annoying whitespace issue.
v2: Also make the fix in i915_load_modeset_init, not just in
i915_driver_unload (Chris Wilson)
v3: Had extra stuff in it.
v4: Reverted extra stuff (so we're back to v2).
Rebased and updated comme
ation.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 799a53a..041e0e1 100644
--- a/dr
ister accesses from intel_cleanup_ring_buffer()
(which calls intel_stop_ring_buffer(ring) which calls stop_ring())
down into stop_ring() itself), which is already doing low-level
register accesses. Then, intel_cleanup_ring_buffer() no longer
needs 'dev_priv'.
Signed-off-
ntext is freed".
Signed-off-by: Dave Gordon
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 58 +++-
1 file changed, 33 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c702fc2..8
andle teardown of HWSP when context is freed".
Signed-off-by: Dave Gordon
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 282d66a
On 25/01/16 10:52, Chris Wilson wrote:
On Fri, Jan 22, 2016 at 11:10:08PM +, Dave Gordon wrote:
1. Fix intel_cleanup_ring_buffer() to handle the error cleanup case where
the ringbuffer has been allocated but map-and-pin failed. Unpin it iff
it's previously been mapped-and-p
On 25/01/16 10:54, Chris Wilson wrote:
On Fri, Jan 22, 2016 at 11:10:09PM +, Dave Gordon wrote:
The kunmap() call here didn't match the corresponding kmap().
The kmapping was changed with the introduction of the GuC-compatible
layout of context objects and the introduction of "LRC
On 25/01/16 10:56, Chris Wilson wrote:
On Fri, Jan 22, 2016 at 11:10:10PM +, Dave Gordon wrote:
In LRC mode, the HWSP is part of the default context object, and
therefore does not exist independently. Worse, it doesn't contribute
to the refcount on the default context object e
701 - 800 of 1151 matches
Mail list logo
