umeric value that is already used.
This should produce identical code to the previous version!
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_guc_fwif.h | 1 +
drivers/gpu/drm/i915/intel_guc_loader.c| 2 +-
es for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
options that the user can select (-1, 0, 1, 2 respectively).
This should produce identical code to the previous version!
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_guc.h
On 22/07/16 13:51, Tvrtko Ursulin wrote:
On 22/07/16 13:42, Dave Gordon wrote:
On 21/07/16 14:46, Tvrtko Ursulin wrote:
On 21/07/16 14:31, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote:
On 21/07/16 13:59, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 01
As we're tweaking the GuC-related code in debugfs, we can
drop the no-longer-used 'q_fail' and repack the structure.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
drivers/gpu/drm/i915/intel_guc.h| 6 ++
2 f
e that
the client is associated with.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++-
drivers/gpu/drm/i915/intel_guc.h | 3 ++-
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gp
ore than once or twice, hopefully eliminating memory
references.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 17 +
drivers/gpu/drm/i915/i915_guc_submission.c | 22 +-
2 files changed, 22 insertion
workqueue slots.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 25 -
drivers/gpu/drm/i915/i915_guc_submission.c | 35 +++---
drivers/gpu/drm/i915/intel_guc.h | 2 +-
3 files changed
We have essentially the same code in each of two different
loops, so we can refactor it into a little helper function.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 54 +-
1 file changed, 30 insertions(+), 24
On 22/07/16 11:06, Tvrtko Ursulin wrote:
On 22/07/16 07:02, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: use one GuC client per GPU engine
URL : https://patchwork.freedesktop.org/series/10149/
State : success
== Summary ==
Series 10149v1 drm/i915/guc: use one GuC client per
workqueue slots.
Dave Gordon (6):
drm/i915/guc: doorbell reset should avoid used doorbells
drm/i915/guc: refactor guc_init_doorbell_hw()
drm/i915/guc: use a separate GuC client for each engine
drm/i915/guc: add engine mask to GuC client & pass to GuC
drm/i915/guc: use for_each_engin
abled, avoiding those that are marked as in use by any client.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gp
Re-enables GuC loading and submission by default on suitable
platforms, since it's Intel's Plan of Record that GuC submission
shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
also been executed at least once.
To avoid the annoying warning, though, this patch reorganises the code a
little and adds an explicit initialisation of the suspect variable.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 19 ---
drivers/gpu/drm/i915/i915
On 25/07/16 09:49, Chris Wilson wrote:
On Mon, Jul 25, 2016 at 11:45:42AM +0300, Joonas Lahtinen wrote:
On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote:
A few places we use ring when referring to the struct intel_engine_cs. An
anachronism we are pruning out.
Signed-off-by: Chris Wilson
-
On 25/07/16 08:44, Chris Wilson wrote:
Space for flushing the GPU cache prior to completing the request is
preallocated and so cannot fail.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +---
drivers/gpu/drm/
On 25/07/16 10:18, Joonas Lahtinen wrote:
On ma, 2016-07-25 at 08:44 +0100, 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
On 27/07/16 11:00, Chris Wilson wrote:
On Wed, Jul 27, 2016 at 10:49:46AM +0100, Dave Gordon wrote:
On 25/07/16 08:44, Chris Wilson wrote:
Space for flushing the GPU cache prior to completing the request is
preallocated and so cannot fail.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915
On 25/07/16 08:44, Chris Wilson wrote:
If we rewrite the I915_WRITE_TAIL specialisation for the legacy
ringbuffer as submitting the request onto the ringbuffer, we can unify
the vfunc with both execlists and GuC in the next patch.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
d
have a local engine variable and so
finding a good name was trickier.
Signed-off-by: Chris Wilson
Cc: Dave Gordon
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h| 15 +-
drivers/gpu/drm/i915/i915_gem.c| 26 +--
On 27/07/16 09:07, Chris Wilson wrote:
Inside the error capture itself, we refer to not only the hardware
engine, its ringbuffer but also the capture state. Finding clear names
for each whilst avoiding mixing ring/intel_engine_cs is tricky. As a
compromise we keep using ering for the error captur
On 21/07/16 15:14, Chris Wilson wrote:
On Thu, Jul 21, 2016 at 04:39:58PM +0300, Joonas Lahtinen wrote:
On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
if (so.aux_batch_size > 8) {
- ret = req->engine->dispatch_execbuffer(req,
-
On 22/07/16 09:03, Joonas Lahtinen wrote:
On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote:
Move request submission from emit_request into its own common vfunc
from i915_add_request().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_request.c| 7 +++
drivers/gpu/drm
On 27/07/16 19:09, Chris Wilson wrote:
On Wed, Jul 27, 2016 at 06:51:35PM +0100, Dave Gordon wrote:
@@ -1006,6 +1005,10 @@ int i915_guc_submission_enable(struct drm_i915_private
*dev_priv)
host2guc_sample_forcewake(guc, client);
guc_init_doorbell_hw(guc);
+ /* Take over
On 28/07/16 11:12, Joonas Lahtinen wrote:
On ke, 2016-07-27 at 19:11 +0100, Chris Wilson wrote:
From gen6, the hardware tracks address lookup failures and so that we do
not trigger false positives from errors before we are initialised we
clear those upon startup (intel_uncore_early_sanitize()).
On 27/07/16 16:28, Chris Wilson wrote:
On Wed, Jul 27, 2016 at 12:08:35PM +0100, Dave Gordon wrote:
On 25/07/16 10:18, Joonas Lahtinen wrote:
On ma, 2016-07-25 at 08:44 +0100, Chris Wilson wrote:
If is simpler and leads to more readable code through the callstack if
the allocation returns the
thout the overhead of flushing.
Signed-off-by: Chris Wilson
Cc: Dave Gordon
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 10 ++
drivers/gpu/drm/i915/i915_gem_request.c
On 27/07/16 13:29, Chris Wilson wrote:
On Wed, Jul 27, 2016 at 12:53:25PM +0100, Dave Gordon wrote:
On 25/07/16 08:44, Chris Wilson wrote:
If we rewrite the I915_WRITE_TAIL specialisation for the legacy
ringbuffer as submitting the request onto the ringbuffer, we can unify
the vfunc with both
number of dwords emitted must match the reserved space).
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
3 file
On 28/07/16 16:10, Chris Wilson wrote:
On Thu, Jul 28, 2016 at 01:48:32PM +0100, Dave Gordon wrote:
On 27/07/16 16:28, Chris Wilson wrote:
On Wed, Jul 27, 2016 at 12:08:35PM +0100, Dave Gordon wrote:
On 25/07/16 10:18, Joonas Lahtinen wrote:
On ma, 2016-07-25 at 08:44 +0100, Chris Wilson
On 25/07/16 08:44, Chris Wilson wrote:
As GEN6+ is now a simple variant on the basic breadcrumbs + tail write,
reuse the common code.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 74 +
1 file changed, 30
On 28/07/16 16:29, Chris Wilson wrote:
On Thu, Jul 28, 2016 at 04:23:42PM +0100, Dave Gordon wrote:
On 25/07/16 08:44, Chris Wilson wrote:
As GEN6+ is now a simple variant on the basic breadcrumbs + tail write,
reuse the common code.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.
v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed
On 06/07/16 15:24, Peter Antoine wrote:
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_guc_submission.c | 65 ++
drivers/gpu/drm/i915/intel_guc_fwif.h | 1 +
drivers/gpu/drm/i915/intel_guc_loader.c| 2 +
3 files changed, 68 insertions(+)
No obvious problems here.
Reviewed-by: Dave
On 06/07/16 15:24, Peter Antoine wrote:
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if
On 29/07/16 12:33, Dave Gordon wrote:
On 06/07/16 15:24, Peter Antoine wrote:
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm
On 01/08/16 14:54, Jani Nikula wrote:
On Fri, 22 Jul 2016, Dave Gordon wrote:
The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on boolean 0/1
mapping to specific values (w
igned-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
drivers/gpu/drm/i915/intel_ringbuffer.h | 17 +
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git
On 01/08/16 19:57, Dave Gordon wrote:
On 01/08/16 14:54, Jani Nikula wrote:
On Fri, 22 Jul 2016, Dave Gordon wrote:
The existing code that accesses the "enable_guc_submission"
parameter uses explicit numerical values for the various
possibilities, including in one case relying on b
On 21/07/16 18:10, Dave Gordon wrote:
On 21/07/16 11:38, Tvrtko Ursulin wrote:
On 20/07/16 22:07, Rodrigo Vivi wrote:
please kill this _ucode variation that is just a alias to guc
instead
Not sure, it was added with a particular goal. Cc Dave in case he wants
to comment.
Regards
with workstreams.
The second patch simply changes the output of this same test to make
it more obvious what measurements are made and what results can be
calculated from them.
Dave Gordon (2):
igt/gem_exec_nop: add burst submission to parallel execution test
igt/gem_exec_nop: clarify & ex
) workloads.
Signed-off-by: Dave Gordon
---
tests/gem_exec_nop.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index 9b89260..c2bd472 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -166,14 +166,17 @@ static
% may also be possible, although less likely.
Signed-off-by: Dave Gordon
---
tests/gem_exec_nop.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index c2bd472..05aa383 100644
--- a/tests/gem_exec_nop.c
+++ b/tests
On 03/08/16 16:45, Chris Wilson wrote:
On Wed, Aug 03, 2016 at 04:36:46PM +0100, Dave Gordon wrote:
The parallel execution test in gem_exec_nop chooses a pessimal
distribution of work to multiple engines; specifically, it
round-robins one batch to each engine in turn. As the workloads
are
On 02/08/16 15:16, Daniel Vetter wrote:
On Tue, Aug 02, 2016 at 11:10:46AM +0100, Dave Gordon wrote:
On 21/07/16 18:10, Dave Gordon wrote:
On 21/07/16 11:38, Tvrtko Ursulin wrote:
On 20/07/16 22:07, Rodrigo Vivi wrote:
please kill this _ucode variation that is just a alias to guc
instead
On 06/08/16 09:29, Chris Wilson wrote:
On Sat, Aug 06, 2016 at 10:09:16AM +0200, Lukas Wunner wrote:
On Wed, Aug 03, 2016 at 04:36:18PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Dell UP2414Q doesn't like it when we're driving it in MST mode, and then
reboot the machine.
names for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
submission options that the user can select (-1, 0, 1, 2
respectively).
This should produce identical code to the previous version!
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Jani Nikula
---
drivers/gp
added (3/4
Re-enable GuC loading & submission (4/4)
Added cover letter
v4:
Additional final patch (5/5) to change treatment of unrecognised
option values (ignore them rather than force them into range).
Dave Gordon (5):
drm/i915/guc: symbolic names for GuC submission preferences
es for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
options that the user can select (-1, 0, 1, 2 respectively).
This should produce identical code to the previous version!
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i
Of course, this also re-enables GuC loading and submission
by default on suitable platforms, since it's Intel's Plan
of Record that GuC submission shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 10 +-
1 file changed, 5 insert
we also have to report that we've ignored unknown values so
that the administrator or developer knows the kernel command line wasn't
sensible!
Signed-off-by: Dave Gordon
Cc: Jani Nikula
---
drivers/gpu/drm/i915/intel_guc.h| 8
drivers/gpu/drm/i915/intel_guc_loa
umeric value that is already used.
This should produce identical code to the previous version!
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_guc_fwif.h | 1 +
drivers/gpu/drm/i915/intel_guc_loader.
per engine is left for a subsequent
patch after the next release of GuC firmware is available.
Dave Gordon (6):
drm/i915/guc: doorbell reset should avoid used doorbells
drm/i915/guc: refactor guc_init_doorbell_hw()
drm/i915/guc: add engine mask to GuC client & pass to GuC
drm/i915/guc:
doorbell registers to the state they're already in.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 54 +-
1 file changed, 30 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission
abled, avoiding those that are marked as in use by any client.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gp
ore than once or twice, hopefully eliminating memory
references.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c| 18 ++
drivers/gpu/drm/i915/i915_guc_submission.c | 13 +++--
2 files changed, 17 insertions(+), 14 d
As we're tweaking the GuC-related code in debugfs, we can
drop the no-longer-used 'q_fail' and repack the structure.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 1 -
drivers/gpu/drm/i915/intel_guc.h| 6 ++
2 f
Re-enables GuC loading and submission by default on suitable
platforms, since it's Intel's Plan of Record that GuC submission
shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
e
that the client was associated with. So this patch enables this usage,
in preparation for having multiple clients, though at this point there
is still only a single client used for all supported engines.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submiss
On 09/08/16 12:25, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: use symbolic names for module parameter values (rev2)
URL : https://patchwork.freedesktop.org/series/10188/
State : warning
== Summary ==
Series 10188v2 drm/i915/guc: use symbolic names for module parameter values
On 09/08/16 15:55, Patchwork wrote:
== Series Details ==
Series: Accommodate multiple GuC submission clients
URL : https://patchwork.freedesktop.org/series/10847/
State : failure
== Summary ==
Series 10847v1 Accommodate multiple GuC submission clients
http://patchwork.freedesktop.org/api/1.0
On 09/08/16 03:59, Dave Airlie wrote:
On 8 August 2016 at 19:40, Daniel Vetter wrote:
On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
Hello there,
Recent versions of gcc say this:
include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, b
Recent versions of gcc say this:
include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshift-overflow=]
Reported-by: David Binderman
Signed-off-by: Dave Gordon
Cc: Dave Airlie
---
include/drm/i915_drm.h | 2 +-
On 10/08/16 06:57, Rodrigo Vivi wrote:
With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
links") we started loading the firmware version directly
instead of symbolic links.
However the pathnames in the patch context below are still the symlink
names -- is this correct? Or did some m
mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG
v4:
Resend with added cover letter :)
Dave Gordon (4):
drm: extra printk() wrapper macros
drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
drm/i915/guc: revisit GuC loader messa
Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.
v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()
Signed-off-by: Dave G
Re-enables GuC loading and submission by default on suitable
platforms, since it's Intel's Plan of Record that GuC submission
shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 inser
underlying macro that does all the token-pasting.
DRM_ERROR is unchanged, as it's not just a printk wrapper.
v2:
Fix whitespace, missing ## (Eric Engestrom)
Signed-off-by: Dave Gordon
Reviewed-by: Eric Engestrom
Cc: dri-de...@lists.freedesktop.org
---
include/drm/drmP.h
estore the file names instead keeping the
symbolic links (Dave).
Cc: sta...@vger.kernel.org
Cc: Dave Gordon
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Patrik Jakobsson
Cc: Matthew Atwood
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97182
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i
platform.
v2: Rebased for KBL.
Signed-off-by: Tvrtko Ursulin
Cc: Dave Gordon
Cc: Rodrigo Vivi
Cc: Peter Antoine
Cc: Michel Thierry
Reviewed-by: Dave Gordon (v1)
You can carry the R-b over to v2 too :)
But wouldn't it be even nicer to unify with the HuC and DMC loaders too?
-by: Dave Gordon
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 83f40e869955..c461072da142 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3226,7 +3226,7 @@ static int i915_semaphore_status(struct seq_file
On 10/08/16 11:26, Daniel Vetter wrote:
On Tue, Aug 09, 2016 at 10:57:13PM -0700, Rodrigo Vivi wrote:
On Tue, Aug 9, 2016 at 1:48 AM, Jani Nikula wrote:
On Tue, 09 Aug 2016, Daniel Klaffenbach wrote:
Hi,
which one is the correct DMC version to load for Linux 4.8-rc1? The
binary blob in linu
as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.
v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Revie
On 11/08/16 11:49, Dave Gordon wrote:
On 06/07/16 15:24, Peter Antoine wrote:
Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to
ff-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
R-b can carry over again, but this will need (ANOTHER!) rebase as Chris
has nuked one of the functions called below.
---
drivers/gpu/drm/i915/i915_debugfs.c| 12 +--
drivers/gpu/drm/i915/i915_guc_submission.c
l;
+ }
if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {
No other problems found, so
Reviewed-by: Dave Gordon
even without the extra blank lines.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 inser
underlying macro that does all the token-pasting.
DRM_ERROR is unchanged, as it's not just a printk wrapper.
v2:
Fix whitespace, missing ## (Eric Engestrom)
Signed-off-by: Dave Gordon
Reviewed-by: Eric Engestrom
Cc: dri-de...@lists.freedesktop.org
---
include/drm/drmP.h
mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG
v4:
Resend with added cover letter
Dave Gordon (4):
drm: extra printk() wrapper macros
drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
drm/i915/guc: revisit GuC loader message le
Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
drive
Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.
v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()
Signed-off-by: Dave G
On 07/08/16 15:45, Chris Wilson wrote:
Since the guc allocates and pins and object into the GGTT for its usage,
it is more natural to use that pinned VMA as our resource cookie.
Well it isn't really any more natural, as we hardly ever care about the
mapping, whereas we more frequently work wit
next version, when the naming gets
unified across all the uC devices :) So
Reviewed-by: Dave Gordon
/**
* intel_huc_load_ucode() - DMA's the firmware
* @dev: the drm device
@@ -157,6 +160,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_SK
r points (numbered below) to be addressed, but once
those are fixed, then:
Reviewed-by: Dave Gordon
1: Several typos in the commit message above (e.g. 'dev_provate',
'automic'),
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c |
bout failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG
v4:
Resend with added cover letter
Dave Gordon (4):
drm: extra printk() wrapper macros
drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()
drm/i915/guc: revisit GuC
Update GuC firmware version to 8.11, and re-enable GuC loading and
submission by default on suitable platforms, since it's Intel's
Plan of Record that GuC submission shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
drive
Some downgraded from DRM_ERROR() to DRM_WARN() or DRM_NOTE(),
a few upgraded from DRM_INFO() to DRM_NOTE() or DRM_WARN(),
and one eliminated completely.
v2: different permutation of levels :)
v3: convert a couple of "this shouldn't happen" messages to WARN()
Signed-off-by: Dave G
underlying macro that does all the token-pasting.
DRM_ERROR is unchanged, as it's not just a printk wrapper.
v2:
Fix whitespace, missing ## (Eric Engestrom)
Signed-off-by: Dave Gordon
Reviewed-by: Eric Engestrom
Cc: dri-de...@lists.freedesktop.org
---
include/drm/drmP.h
Where we're going to continue regardless of the problem, rather than
fail, then the message should be a WARNing rather than an ERROR.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++---
1 file changed, 7 inser
On 11/08/16 18:35, Patchwork wrote:
== Series Details ==
Series: Reclassify messages from GuC loader/submission (rev3)
URL : https://patchwork.freedesktop.org/series/10918/
State : failure
== Summary ==
Series 10918v3 Reclassify messages from GuC loader/submission
http://patchwork.freedeskto
On 12/08/16 12:20, David Weinehall wrote:
drm/i915: debugfs spring cleaning
Just like with sysfs, we do some major overhaul.
Pass dev_priv instead of dev to all feature macros (IS_, HAS_,
INTEL_, etc.). This has the side effect that a bunch of functions
now get dev_priv passed instead of dev.
On 18/08/16 13:01, John Harrison wrote:
On 03/08/2016 17:05, Dave Gordon wrote:
On 03/08/16 16:45, Chris Wilson wrote:
On Wed, Aug 03, 2016 at 04:36:46PM +0100, Dave Gordon wrote:
The parallel execution test in gem_exec_nop chooses a pessimal
distribution of work to multiple engines
On 18/08/16 16:27, Dave Gordon wrote:
[snip]
Note that SKL GuC firmware 6.1 didn't support dual submission or lite
restore, whereas the next version (8.11) does. Therefore, with that
firmware we don't see the same slowdown when going to 1-at-a-time
round-robin. I have a different
On 18/08/16 16:36, Dave Gordon wrote:
On 18/08/16 16:27, Dave Gordon wrote:
[snip]
Note that SKL GuC firmware 6.1 didn't support dual submission or lite
restore, whereas the next version (8.11) does. Therefore, with that
firmware we don't see the same slowdown when going to 1-at-a-
On 18/08/16 16:27, Dave Gordon wrote:
On 18/08/16 13:01, John Harrison wrote:
[snip]
Can you post the numbers that you get?
I seem to get massive variability on my BDW. The render ring always
gives me around 2.9us/batch but the other rings sometimes give me region
of 1.2us and sometimes 7
On 11/08/16 17:43, Chris Wilson wrote:
On Thu, Aug 11, 2016 at 05:09:01PM +0100, Arun Siluvery wrote:
From: Dave Gordon
Context capture hasn't worked for a while now, since the introduction of
execlists because the function that records active context is using CCID
register but this reg
es for the values
representing the DEFAULT, DISABLED, PREFERRED, and MANDATORY
options that the user can select (-1, 0, 1, 2 respectively).
This should produce identical code to the previous version!
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
Cc: Jani Nikula
---
drivers/gpu/drm/i915/i
Of course, this also re-enables GuC loading and submission
by default on suitable platforms, since it's Intel's Plan
of Record that GuC submission shall be used where available.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 10 +-
1 file changed, 5 insert
added (3/4
Re-enable GuC loading & submission (4/4)
Added cover letter
v4:
Additional final patch (5/5) to change treatment of unrecognised
option values (ignore them rather than force them into range).
[Jani Nikula]
Dave Gordon (5):
drm/i915/guc: symbolic names for GuC submis
101 - 200 of 1151 matches
Mail list logo
