From: John Harrison john.c.harri...@intel.com
Check whether each engine exists before trying to clean up the
corresponding logical ring.
Change-Id: I31b1ed941824db2d6bd7233360dbce05671979a8
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 12
-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cd74e5c..3c727d9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
: Id7ce9096ed100a2882c68a54206f30b6c87e92fa
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c |5 ++-
drivers/gpu/drm/i915/intel_lrc.c| 36 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 53 ---
drivers/gpu/drm/i915
On 30/10/14 19:26, Ville Syrjälä wrote:
On Thu, Oct 30, 2014 at 10:32:38AM -0700, Kenneth Graunke wrote:
On Thursday, October 30, 2014 01:01:30 PM Ville Syrjälä wrote:
On Thu, Oct 30, 2014 at 02:32:40AM -0700, Kenneth Graunke wrote:
On Thursday, October 30, 2014 11:00:51 AM Ville Syrjälä
On 31/10/14 14:52, Damien Lespiau wrote:
On Fri, Oct 31, 2014 at 12:00:26PM +, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
If a ring failed to initialise for any reason then the error path would try
to
clean up all rings including those that had not
On 03/11/14 20:59, Chris Wilson wrote:
On Mon, Nov 03, 2014 at 01:29:04PM +, Dave Gordon wrote:
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the software ring 'head' value
On 06/11/14 14:09, Daniel Vetter wrote:
On Wed, Nov 05, 2014 at 05:30:52PM +0200, Mika Kuoppala wrote:
This reverts commit 5cb13c07dae73380d8b3ddc792740487b8742938.
While the relevance for WaRsDontPollForAckOnClearingFWBits is under
investigation, revert this as regression.
Bugzilla:
of the existing interfaces will see no change from this, but
it will enable TDR to safely access the registers it needs to sample.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 61 ---
1 file changed, 49 insertions(+), 12
On 07/11/14 15:46, Ville Syrjälä wrote:
On Wed, Sep 10, 2014 at 07:34:54PM +0100, Chris Wilson wrote:
Introduce a structure to track the individual forcewake domains and use
that to eliminated duplicate logic.
---
drivers/gpu/drm/i915/i915_debugfs.c | 41 +++---
On 18/11/14 15:00, Deepak S wrote:
On Monday 03 November 2014 06:59 PM, Dave Gordon wrote:
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the software ring 'head' value
by reading
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily
contexts.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 2a1a719..1003b3a 100644
--- a/drivers/gpu/drm/i915
(and consumes) 'last_retired_head' if
(and ONLY if) it has been updated since the last call.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/i915_dma.c |5 ++-
drivers/gpu/drm/i915/intel_lrc.c| 25 +--
drivers/gpu/drm/i915/intel_ringbuffer.c
(undefined, effectively random) value into
the s/w 'head' -- A Bad Thing for the free space calculations.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915
On 19/11/14 17:05, John Harrison wrote:
On 19/11/2014 13:28, Daniel, Thomas wrote:
-Original Message-
From: Harrison, John C
Sent: Wednesday, November 19, 2014 12:26 PM
To: Daniel, Thomas; Intel-GFX@Lists.FreeDesktop.Org
Subject: Re: [Intel-gfx] [PATCH v2 11/28] drm/i915: Add IRQ
On 20/11/14 19:13, Chris Wilson wrote:
For example,
/sys/kernel/debug/dri/0/i915_hangcheck_info:
Hangcheck active, fires in 15887800ms
render ring:
seqno = -4059 [current -583]
action = 2
score = 0
ACTHD = 1ee8 [current 21f980]
max ACTHD = 0
On 20/11/14 08:45, Daniel Vetter wrote:
We need to do that every time we resume the rings, not just at load.
I've overlooked this in my untangling of the ring init code.
Hi Daniel,
another thing that needs untangling in the general maze of init code is
the initialisation of the active and
On 24/11/14 10:04, Daniel Vetter wrote:
On Tue, Nov 18, 2014 at 08:07:22PM +, Dave Gordon wrote:
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ae09258..a08ae65 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu
Essentially the same as patch 3/3 from v2 of this set, but split
into two patches; one to improve the robustness of the freespace
calculation, and then one to update all the various places that
calculate free space to call the new improved code. See individual
commit messages for more detail.
(and consumes) 'last_retired_head' if
(and ONLY if) it has been updated since the last call.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 25 ++
drivers/gpu/drm/i915/intel_ringbuffer.c | 42 ---
drivers
-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1d01b51..a5cfaae 100644
--- a/drivers/gpu/drm
On 26/11/14 18:10, Daniel Vetter wrote:
On Wed, Nov 26, 2014 at 05:07:29PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Clear the video overlay state on GPU reset. Any pending overlay request
in the ring has been nuked, and the display itself
Reviewed-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c| 14 +++---
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git
/init_render_workarounds/,
with no mention of intel_ !
Once that's corrected, then
Reviewed-by: Dave Gordon david.s.gor...@intel.com
.Dave.
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +-
3 files changed, 4
of
intel_init_ring_buffer() and logical_ring_init() so that they actually
do what their names say, but I see that's forthcoming, so
Reviewed-by: Dave Gordon david.s.gor...@intel.com
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
---
drivers/gpu/drm/i915/i915_gem.c | 13 ++---
drivers/gpu/drm/i915/intel_lrc.c| 6 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 4
3 files changed, 10 insertions(+), 13 deletions(-)
Yep, that's what I was hoping for :)
Reviewed-by: Dave Gordon david.s.gor
On 28/11/14 09:29, Daniel Vetter wrote:
We've lost the +1 required for correct timeouts in
commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9
Author: Thomas Gleixner t...@linutronix.de
Date: Wed Jul 16 21:05:06 2014 +
drm: i915: Use nsec based interfaces
Use
making deduplication
more difficult?
Anyway, this change looks OK in itself, so subject to the exercise for
the reader approach being acceptable (on which point I defer to your
and others judgement), then:
Reviewed-by: Dave Gordon david.s.gor...@intel.com
On 21/11/14 20:27, Daniel Vetter wrote:
On Fri, Nov 21, 2014 at 07:01:54PM +, Dave Gordon wrote:
On 20/11/14 08:45, Daniel Vetter wrote:
We need to do that every time we resume the rings, not just at load.
I've overlooked this in my untangling of the ring init code.
Hi Daniel,
another
On 02/12/14 15:19, Daniel Vetter wrote:
Similar to a patch from Thomas Daniel for lrc contexts. This keeps
both sides somewhat in sync and should make Dave Gordon happy.
Note that both the wa and the golden context init code suffer a bit
from an inssuficient split into driver load and hw
On 08/12/14 13:59, Damien Lespiau wrote:
On Mon, Dec 08, 2014 at 02:33:57PM +0200, Jani Nikula wrote:
#define _MASKED_BIT_ENABLE(a) (((a) 16) | (a))
#define _MASKED_BIT_DISABLE(a) ((a) 16)
+#define _MASKED_FIELD(value, mask) (((mask) 16) | (value))
Obligatory bikeshed, wouldn't you say
MI_STORE_DWORD_IMM_LEGACY /* for source
backward compatibility */
so it's clearer that (for now) the generic definition is actually the
legacy one.
The above bikeshedding notwithstanding, it gets my R-b anyway:
Reviewed-by: Dave Gordon david.s.gor...@intel.com
On 08/12/14 16:27, Daniel Vetter wrote:
On Mon, Dec 08, 2014 at 04:22:27PM +, Damien Lespiau wrote:
I was playing with clang and oh surprise! a warning trigerred by
-Wshift-overflow (gcc doesn't have this one):
[snip]
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
() and _MASKED_BIT_DISABLE() with
_MASKED_FIELD() (Jani Nikula)
Make sure we only evaluate 'a' once in _MASKED_BIT_ENABLE() (Dave Gordon)
Add check to ensure the value is within the mask boundaries (Chris Wilson)
Cc: Mika Kuoppala mika.kuopp...@linux.intel.com
Cc: Arun Siluvery arun.siluv
. In the
mean time, the traditional single-level begin/advance mechanism remains
fully supported.
This commit changes only the begin/advance checking code, to permit (but
not require) nested begin/advance pairs.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.h
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance(). Historically some (display) code
didn't use
an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|4 ++-
drivers/gpu/drm/i915/intel_lrc.h| 11
On 10/12/14 09:11, Daniel Vetter wrote:
On Wed, Dec 10, 2014 at 02:18:15AM +, Gong, Zhipeng wrote:
On Tue, 2014-12-09 at 10:46 +0100, Daniel Vetter wrote:
On Mon, Dec 08, 2014 at 01:55:56PM -0800, Rodrigo Vivi wrote:
[snip]
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|4 ++-
drivers/gpu/drm/i915/intel_lrc.h| 11
. In the
mean time, the traditional single-level begin/advance mechanism remains
fully supported.
This commit changes only the begin/advance checking code, to permit (but
not require) nested begin/advance pairs.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.h
When adding instructions to a legacy or LRC ringbuffer, the sequence of
emit() calls must be preceded by a call to intel(_logical)_ring_begin()
to reserve the required amount of space, and followed by a matching call
to intel(_logical)_ring_advance(). Historically some (display) code
didn't use
On 10/12/14 10:58, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The scheduler decouples the submission of batch buffers to the driver with
their
submission to the hardware. This basically means
On 10/12/14 10:40, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 12:59:06PM +, john.c.harri...@intel.com wrote:
From: Dave Gordon david.s.gor...@intel.com
Added various definitions that will be useful for the scheduler in general
and
pre-emptive context switching in particular.
Change
On 10/12/14 10:42, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 12:59:08PM +, john.c.harri...@intel.com wrote:
From: Dave Gordon david.s.gor...@intel.com
There is a workaround for a hardware bug when reading the seqno from the
status
page. The bug does not exist on VLV however
/8] drm/i915: Enum forcewake domains and domain identifiers
Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git
[PATCH 1/3] drm/i915: use effective_size for ringbuffer calculations
When calculating the available space in a ringbuffer, we should
use the effective_size rather than the true size of the ring.
[PATCH 2/3] drm/i915: recheck ringspace after wait+retire
When a ringbuffer is nearly
check
in the legacy ringbuffer mode too.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|9 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +++-
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
When calculating the available space in a ringbuffer, we should
use the effective_size rather than the true size of the ring.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c |5 +++--
2 files
an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|4 ++-
drivers/gpu/drm/i915/intel_lrc.h| 11
On 12/12/14 17:12, Chris Wilson wrote:
On Fri, Dec 12, 2014 at 04:13:03PM +, Dave Gordon wrote:
static inline void intel_ring_advance(struct intel_engine_cs *ring)
{
struct intel_ringbuffer *ringbuf = ring-buffer;
-ringbuf-tail = ringbuf-size - 1
an advance between
* exceeding the space reserved by begin
* leaving the ring misaligned
* ring buffer overrun (negative freespace)
v2: more deduplication (Chris)
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|3 +-
drivers/gpu/drm/i915
On 10/12/14 17:15, Daniel Vetter wrote:
On Wed, Dec 10, 2014 at 04:33:14PM +, Dave Gordon wrote:
On 10/12/14 10:58, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 12:59:11PM +, john.c.harri...@intel.com wrote:
From: John Harrison john.c.harri...@intel.com
The scheduler decouples
that both older (pre-GEN6) and newer
(GEN8+) devices don't currently include any posting read in their own
get_seqno() implementations, so this affects only GEN6 and 7 devices.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers
this new irq_barrier rather
than a POSTING_READ of ACTHD. Note that both older (pre-GEN6) and newer
(GEN8+) devices running in LRC mode do not currently include any posting
read in their own get_seqno() implementations, so this change only
makes a difference on VLV (and not CHV+).
Signed-off-by: Dave
On 17/12/14 20:09, Daniel Vetter wrote:
On Tue, Dec 16, 2014 at 02:26:55PM +, Dave Gordon wrote:
On 10/12/14 17:15, Daniel Vetter wrote:
On Wed, Dec 10, 2014 at 04:33:14PM +, Dave Gordon wrote:
On 10/12/14 10:58, Daniel Vetter wrote:
On Tue, Dec 09, 2014 at 12:59:11PM +
On 18/12/14 08:16, Daniel Vetter wrote:
On Wed, Dec 17, 2014 at 08:34:41AM -0800, Rodrigo Vivi wrote:
When we don't have any workaround to emit we should celebrate, not bother.
Well except that on the platforms where this fires we really should have
some, most likely. This is in a way
: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 5e2b11f
: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_uncore.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e9561de..d29b4d4 100644
When calculating the available space in a ringbuffer, we should
use the effective_size rather than the true size of the ring.
v2: rebase to latest drm-intel-nightly
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|2 +-
drivers/gpu/drm/i915
check
in the legacy ringbuffer mode too.
v2: rebase to latest drm-intel-nightly
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c|9 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 +++-
2 files changed, 20 insertions(+), 1 deletion
On 18/12/14 17:18, Chris Wilson wrote:
On Thu, Dec 18, 2014 at 05:03:41PM +, Dave Gordon wrote:
In {intel,logical}_ring_wait_request(), we try to find a request
whose completion will release the amount of ring space required.
If we find such a request, we wait for it, and then retire
On 18/12/14 20:44, Daniel Vetter wrote:
On Thu, Dec 18, 2014 at 09:40:51PM +0100, Daniel Vetter wrote:
On Thu, Dec 18, 2014 at 05:10:00PM +, Michel Thierry wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
In gen8, 32b PPGTT has always had one pdp (it doesn't actually have
one, but
On 21/01/15 17:45, Daniel Vetter wrote:
On Wed, Jan 21, 2015 at 04:59:08PM +, Dave Gordon wrote:
On 20/01/15 22:09, Daniel Vetter wrote:
Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since
On 15/01/15 14:00, Dave Gordon wrote:
[snip]
Finally, I think the choice of command names (especially --set vs
--custom) is confusing. I'd like to propose the following:
# Reading:
--get # get all
--get namelist # get specified
-g [namelist] # synonym for -g
On 13/01/15 22:20, Daniel Vetter wrote:
On Tue, Jan 13, 2015 at 09:48:51AM +, Gore, Tim wrote:
-Original Message-
From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
Daniel Vetter
Sent: Monday, January 12, 2015 11:26 PM
To: Gore, Tim
Cc: Gordon, David S;
On 20/01/15 22:09, Daniel Vetter wrote:
Cursor plane updates have historically been fully async and mutliple
updates batched together for the next vsync. And userspace relies upon
that. Since implementing a full queue of async atomic updates is a bit
of work lets just recover the cursor
On 21/01/15 13:13, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
On Wed, Jan 21, 2015 at 12:11:11PM +0100, Daniel Vetter wrote:
This goes back to when there was just one global context, when
restoring kinda didn't make sense.
Also with execlist we already have these
On 15/01/15 07:38, Jaeyong Yoo wrote:
Hello Daniel and other maintainers,
While I'm working on drm memory allocator with myself, I've encountered
render ring hang.
And I am noticed that I can diagnose the command streamer's status with the
following registers:
INSTPS: 0x2070
CSCMDOP:
On 15/01/15 07:38, Jaeyong Yoo wrote:
Hello Daniel and other maintainers,
While I'm working on drm memory allocator with myself, I've encountered
render ring hang.
And I am noticed that I can diagnose the command streamer's status with the
following registers:
INSTPS: 0x2070
CSCMDOP:
On 12/01/15 03:35, Ben Widawsky wrote:
WARNING: very minimally tested
In general you should not need this tool. It's primary purpose is for
benchmarking, and for debugging performance issues.
For many kernel releases now sysfs has supported reading and writing the GPU
frequency.
On 09/02/15 15:05, Wang, Zhi A wrote:
Hi Gurus:
Forgive my junior HW knowledge, I just found that in execlist
context initialization function populate_lr_context(), this line:
reg_state[CTX_CONTEXT_CONTROL+1] =
_MASKED_BIT_ENABLE((13) |
(+), 4 deletions(-)
A couple of minor points below, but not ones that require changes, so:
Reviewed-by: Dave Gordon david.s.gor...@intel.com
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8603bf4..70346b0 100644
--- a/drivers/gpu/drm/i915
On 18/02/15 16:24, Imre Deak wrote:
On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
On Tue, 17 Feb 2015, Klaus Ethgen klaus+l...@ethgen.de wrote:
After solving the conflicts, I applied the revert (see attachment) to
v3.18.7. I think it should also apply to the current head. With that
On 18/02/15 14:01, Nick Hoath wrote:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652
When converting from implicitly tracked execlist queue items to ref counted
requests, not all frees of requests were replaced with unrefs, and extraneous
refs/unrefs of contexts were added.
On 16/02/15 21:03, Chris Wilson wrote:
On Mon, Feb 16, 2015 at 06:25:10PM +, Damien Lespiau wrote:
instpm_mode != relative_constants_mode is quite unlikely to happen, so
we can test it first to use C's short-circuiting and not test on
'ring'.
I know, probably a useless
On 12/02/15 22:38, Imre Deak wrote:
On Tue, 2015-02-03 at 11:30 +0100, Daniel Vetter wrote:
UMS is no more!
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
Some machines now won't boot in recovery mode, which specifies
nomodeset and therefore results in various important bits of code not
On 19/02/15 11:08, Deak, Imre wrote:
On Thu, 2015-02-19 at 10:47 +, Dave Gordon wrote:
On 18/02/15 16:24, Imre Deak wrote:
On ke, 2015-02-18 at 17:39 +0200, Jani Nikula wrote:
On Tue, 17 Feb 2015, Klaus Ethgen klaus+l...@ethgen.de wrote:
After solving the conflicts, I applied the revert
I915_GEM_HWS_INDEX 0x30
+#define I915_GEM_HWS_SCRATCH_INDEX 0x40
#define I915_GEM_HWS_SCRATCH_ADDR (I915_GEM_HWS_SCRATCH_INDEX
MI_STORE_DWORD_INDEX_SHIFT)
void intel_unpin_ringbuffer_obj(struct intel_ringbuffer *ringbuf);
Well, nothing much can go wnorg here!
Reviewed-by: Dave
On 22/12/14 12:26, 유재용 wrote:
Hello intel-gfx,
I'm reading i915 gpu drivers and find myself quite hard to understand
about forcewake concepts.
I understand that it is something with the energy efficiency so related
to ACPI. And it looks like forcewake is working as a pair (get and put).
This gets rid of some annoying warnings and allows GNU make to parallelise more
parts of a deb-pkg build. The message is ...
make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make
rule.
... so I've added the '+' as suggested.
Signed-off-by: Dave Gordon david.s.gor
On 08/01/15 13:40, Mika Kuoppala wrote:
i915_gem_validate_context() will check the engine-state to see if it can
submit into a ringbuffer. But when we are releasing the context we leave the
engine state to a non null value. Thus after a successful hang recovery
we might mistakenly submit to a
://bugs.freedesktop.org/show_bug.cgi?id=88096
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Gordon david.s.gor...@intel.com
Signed-off-by: Thomas Daniel thomas.dan...@intel.com
---
drivers/gpu/drm/i915/intel_lrc.c |2 +-
1 file changed, 1 insertion
the '+' as suggested.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
scripts/package/Makefile |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 99ca6e7..0dbfae7 100644
--- a/scripts/package/Makefile
+++ b/scripts
On 12/01/15 18:02, Ben Widawsky wrote:
On Mon, Jan 12, 2015 at 02:02:34PM +0200, Ville Syrjälä wrote:
On Sun, Jan 11, 2015 at 07:14:57PM -0800, Ben Widawsky wrote:
On Sun, Jan 11, 2015 at 07:05:21PM -0800, Kenneth Graunke wrote:
On Sunday, January 11, 2015 05:46:09 PM Ben Widawsky wrote:
On
On 12/01/15 14:09, tim.g...@intel.com wrote:
From: Tim Gore tim.g...@intel.com
The invalid-flags test in gem_exec_params uses
(I915_EXEC_HANDLE_LUT 1) as an invalid flag, but this
is no longer invalid for recent android versions, and may
not be invalid in Linux in the future. So I have
On 07/01/15 08:13, Jaeyong Yoo wrote:
Thanks a lot. It is very helpful. Couple of follow-up questions below.
-Original Message-
From: Dave Gordon [mailto:david.s.gor...@intel.com]
Sent: Wednesday, January 07, 2015 12:19 AM
To: jaeyong@samsung.com
Cc: intel-gfx
On 05/02/15 11:01, Chris Wilson wrote:
On Thu, Feb 05, 2015 at 12:44:21PM +0200, Sakari Kapanen wrote:
On 02/04/2015 11:26 AM, Jani Nikula wrote:
On Mon, 02 Feb 2015, Sakari Kapanen sakari.m.kapa...@student.jyu.fi wrote:
Dear maintainers,
On an Asus Zenbook UX32VD laptop with an i5-3317U CPU
for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.
Signed-off-by: Dave Gordon david.s.gor...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
On 06/03/15 15:57, Daniel Vetter wrote:
On Fri, Mar 06, 2015 at 11:38:44AM +, John Harrison wrote:
On 05/03/2015 16:14, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 03:06:42PM +, John Harrison wrote:
On 05/03/2015 14:44, Daniel Vetter wrote:
Imo reserving a bit of ring space for each
not occur if such
precision
* is important.
+ *
+ * Note that some kernels have broken the inifite wait for negative values
s/inifite/infinite/, then
Reviewed-by: Dave Gordon david.s.gor...@intel.com
+ * promise, upgrade to latest stable kernels if this is the case.
*/
drm_public
On 22/02/15 19:10, François Tigeot wrote:
* This change prevents logical not is only applied to the left hand side of
comparison
gcc 5.0 warnings.
* Originally added by John Marino in DragonFly's
eecf6c3c3b6f7127edd8b8f8c2a83e2f882ed0da
commit.
Signed-off-by: François Tigeot
It can be useful to know what the driver's parameters have ended up set
to after sanitisation, so this commit adds a debugfs function to print
the current values of all the module parameters.
---
drivers/gpu/drm/i915/i915_debugfs.c | 45 +++
1 file changed, 45
On 17/04/15 22:21, yu@intel.com wrote:
From: Dave Gordon david.s.gor...@intel.com
Factor out the common code of loading firmware into a new file,
leaving only the uC-specific parts in the GuC loaders.
Issue: VIZ-4884
Signed-off-by: Alex Dai yu@intel.com
Signed-off-by: Dave Gordon
On 17/04/15 22:21, yu@intel.com wrote:
From: Alex Dai yu@intel.com
Add GuC firmware loader. It uses the unified firmware loader to
fetch firmware blob first, then load to hw in driver main thread.
Issue: VIZ-4884
Signed-off-by: Alex Dai yu@intel.com
---
On 17/04/15 22:21, yu@intel.com wrote:
From: Dave Gordon david.s.gor...@intel.com
In order to fully initialise the default contexts, we have to execute
batchbuffer commands on the GPU engines. But we can't do that until any
required firmware has been loaded, which may not be possible
On 28/04/15 10:21, Dave Gordon wrote:
On 24/04/15 06:52, Antoine, Peter wrote:
I picked up this work due to the following Jira ticket created by the
security team (on Android) and was asked to give it a second look and
found a few more issues with the hw lock code.
https://jira01
On 23/04/15 18:48, Dave Gordon wrote:
On 17/04/15 22:21, yu@intel.com wrote:
From: Alex Dai yu@intel.com
Add GuC firmware loader. It uses the unified firmware loader to
fetch firmware blob first, then load to hw in driver main thread.
Issue: VIZ-4884
Signed-off-by: Alex Dai yu
On 17/04/15 22:21, yu@intel.com wrote:
From: Sagar Kamble sagar.a.kam...@intel.com
The firmware loader will use GuC DMA engine to move data from
ggtt to WOPCM. Need to take forcewake before GuC loading.
Issue: VIZ-4884
Change-Id: Ie422fc1e122933b161ff63cab23622197e6bba54
On 30/04/15 11:47, Dan Carpenter wrote:
Hi Michel,
The patch 69876bed7e00: drm/i915/gen8: page directories rework
allocation from Apr 8, 2015, has the following issue:
drivers/gpu/drm/i915/i915_gem_gtt.c:760
warn: too many zeroes
drivers/gpu/drm/i915/i915_gem_gtt.c
746
;
- /* Preallocate the olr before touching the ring */
- ret = i915_gem_request_alloc(ring, ctx);
+ ret = logical_ring_prepare(ringbuf, ctx, num_dwords * sizeof(uint32_t));
if (ret)
return ret;
Reviewed-by: Dave Gordon david.s.gor...@intel.com
with input also
1 - 100 of 1128 matches
Mail list logo
