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
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.
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
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
WA_TAIL_DWORDS so we could accommodate GPUs
that required different amounts of padding, generalised NOOP fill
[Rodrigo Vivi], added W/A space to reserved amount and updated
code comments [Dave Gordon],
v4:
Made #define for WA_TAIL_DWORDS a function-type macro in case we
want
: bc3d674462e5df5f2b33adbfcaad9edff8b827f4
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35caa9b..f25b443 100644
--- a
On 19/08/16 14:39, Chris Wilson wrote:
On Fri, Aug 19, 2016 at 02:31:15PM +0100, Dave Gordon wrote:
@@ -654,6 +680,14 @@ int intel_logical_ring_alloc_request_extras(struct
drm_i915_gem_request *request
*/
request->reserved_space += EXECLISTS_REQUEST_S
On 19/08/16 15:30, Chris Wilson wrote:
On Fri, Aug 19, 2016 at 03:23:42PM +0100, Dave Gordon wrote:
In the recent patch
bc3d674 drm/i915: Allow userspace to request no-error-capture upon ...
the final version moved the flags and the associated #defines around
so they were adjacent
On 19/08/16 15:49, Patchwork wrote:
== Series Details ==
Series: drm/i915: Reattach comment, complete type specification
URL : https://patchwork.freedesktop.org/series/11327/
State : failure
== Summary ==
Series 11327v1 drm/i915: Reattach comment, complete type specification
http://patchwork
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
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: Jani Nikula
---
drivers/gpu/drm/i915/i915_guc_su
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
Cc: Jani Nikula
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_par
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: Jani Nikula
---
drivers/gpu/drm/i915/intel_guc.h
umeric value that is already used.
This should produce identical code to the previous version!
Signed-off-by: Dave Gordon
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.c| 2 +-
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
et as it seems unlikely that they'll be as useful.
v2:
Fix whitespace, missing ## (Eric Engestrom)
v5:
Much simplified after underlying functions were reworked.
Signed-off-by: Dave Gordon
Previously-Reviewed-by: Eric Engestrom (v2)
Cc: Eric Engestrom
Cc: dri-de...@lists.freed
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
bout failure or mode change are NOTICEs
* anything else (messages for developer rather than sysadmin) is DEBUG
v4:
Resend with added cover letter
v5:
Drop most of patch 1 (superseded by upstream changes).
Dave Gordon (4):
drm: two more (drm_)printk() wrapper macros
drm/i915/guc: downgrade
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
is time in default mode. Without this patch,
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
---
drivers/gpu/drm/i915/i915_drv.h| 2 --
drive
On 26/08/16 19:47, Chris Wilson wrote:
On Fri, Aug 26, 2016 at 07:25:57PM +0100, Dave Gordon wrote:
'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and aut
ug.cgi?id=92448
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h| 2 -
drivers/gpu/drm/i915/i915_gem.c| 3 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 70 ++
3 files changed, 43 insertions(+), 32 deletions(-)
diff --git a/
another variant, which still uses the fast-skip mechanism
but without requiring the temporary, for the cost of a slight increase
in code size (~20 bytes per callsite).
Signed-off-by: Dave Gordon
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h
The gem_exec_nop test generally works by submitting batches to an engine
as fast as possible for a fixed time, then finally calling gem_sync() to
wait for the last submitted batch to complete. The time-per-batch is
then calculated as the total elapsed time, divided by the total number
of batche
On 01/09/16 15:48, Chris Wilson wrote:
On Thu, Sep 01, 2016 at 03:17:44PM +0100, Dave Gordon wrote:
This macro was recently updated to skip testing for non-existent or
uninteresting engines by using ffs() to directly find the next engine of
interest. However, it required the introduction of a
On 01/09/16 21:00, Chris Wilson wrote:
On Thu, Sep 01, 2016 at 05:51:09PM +0100, Dave Gordon wrote:
The gem_exec_nop test generally works by submitting batches to an
engine as fast as possible for a fixed time, then finally calling
gem_sync() to wait for the last submitted batch to complete
On 30/08/16 09:18, Chris Wilson wrote:
Currently the presumption is that the request construction and its
submission to the GuC are all under the same holding of struct_mutex. We
wish to relax this to separate the request construction and the later
submission to the GuC. This requires us to reser
On 29/08/16 14:32, Daniel Vetter wrote:
On Fri, Aug 26, 2016 at 02:42:47PM +0300, Imre Deak wrote:
On pe, 2016-08-26 at 14:10 +0300, Imre Deak wrote:
On pe, 2016-08-26 at 11:39 +0100, Chris Wilson wrote:
On Fri, Aug 26, 2016 at 12:25:01PM +0200, Takashi Iwai wrote:
On Fri, 26 Aug 2016 11:18:0
hat then it doesn't understand that passing
&data allows it to be set. If it doesn't complain about this version,
then the original error was actually correct, in the sense that data can
indeed be used uninitialised if certain error paths can be taken.
Here's an R-b for your f
On 22/08/16 09:03, Chris Wilson wrote:
The obj->dirty bit is a companion to the obj->active bits that were
moved to the obj->flags bitmask. Since we also update this bit inside
the i915_vma_move_to_active() hotpath, we can aide gcc by also moving
the obj->dirty bit to obj->flags bitmask.
Signed-
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_su
clarify DRM_INFO fallback message.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 8 +++-
drivers/gpu/drm/i915/intel_guc_loader.c | 12
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915
firmware loading
Those warnings have been resolved, so this patch re-enables GuC
loading and submission by default.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b
On 07/06/16 10:51, Tvrtko Ursulin wrote:
On 07/06/16 09:14, Dave Gordon wrote:
When resetting and reloading the GuC, the GuC submission management code
also needs to destroy and recreate the GuC client(s). Currently this is
done by a separate call from the GuC loader, but really, it's ju
On 07/06/16 09:43, Patchwork wrote:
== Series Details ==
Series: series starting with [1/3] drm/i915/guc: fix GuC loading/submission
check
URL : https://patchwork.freedesktop.org/series/8380/
State : failure
== Summary ==
Series 8380v1 Series without cover letter
http://patchwork.freedeskto
On 07/06/16 21:00, Chris Wilson wrote:
On Tue, Jun 07, 2016 at 02:23:34PM +0100, Tvrtko Ursulin wrote:
On 07/06/16 11:54, Dave Gordon wrote:
On 07/06/16 09:43, Patchwork wrote:
== Series Details ==
Series: series starting with [1/3] drm/i915/guc: fix GuC
loading/submission check
URL
On 08/06/16 09:40, Daniel Vetter wrote:
On Wed, Jun 08, 2016 at 01:57:44PM +0530, Akshu Agrawal wrote:
CHV pipe C hits underrun when we get -ve X values of cursor. To avoid
this we crop the cursor image for by -ve X value and thus use '0' as
least X value.
You're talking about "-ve" here and t
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
assigning and releasing each
in turn, so that 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.
v2: don't use kmap_atomic() now that client page 0 is kept mapped.
Signed-off-by: Dave Gordon
---
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 | 9 +
1 file chan
that the doorbell hardware is fully (re-)initialised when
the GuC is (re-)loaded.
Dave Gordon (4):
drm/i915/guc: add doorbell map to debugfs/i915_guc_info
drm/i915/guc: move guc_ring_doorbell() nearer to callsite
drm/i915/guc: refactor doorbell management code
drm/i915/guc: (re)initialise
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 | 110 ++---
1 file changed, 55 insertions(+), 55
On 08/06/16 14:11, Tvrtko Ursulin wrote:
On 08/06/16 11:55, 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 09/06/16 12:04, Tvrtko Ursulin wrote:
On 07/06/16 09:41, Tvrtko Ursulin wrote:
On 07/06/16 09:14, Dave Gordon wrote:
The last stage of the GuC loader also sanitises the GuC submission
settings, so should be called unconditionally (even on platforms
without a GuC) to ensure consistent
ERROR) for ease of comprehension.
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_guc_loader.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 41f7c7d..05
re is fully (re-)initialised when
the GuC is (re-)loaded.
Dave Gordon (6):
drm/i915/guc: add doorbell map to debugfs/i915_guc_info
drm/i915/guc: move guc_ring_doorbell() nearer to callsite
drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()
drm/i915/guc: remove writes to GEN8_D
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.
v2: use kernel bitmap-printing format (%pb) rather than %x.
Signed-off-by: Dave Gordon
---
drive
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
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 110 ++---
1 file c
These registers are not actually writable by the CPU; only the GuC can
actually program them. So let's not do writes that have no effect.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm
Bitmap operators are overkill when touching only one bit.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
re lifetime
of the client. We will use this new feature in the next patch.
v2: Trivial independent fixes pushed ahead as separate patches.
MUCH longer commit message :) [Tvrtko Ursulin]
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 94 +
ng each
in turn, so that 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.
v2: don't use kmap_atomic() now that client page 0 is kept mapped.
Signed-off-by: Dave Gordon
---
drive
Convert all static functions in i915_guc_submission.c that currently
take a 'dev' pointer to take 'dev_priv' instead (there are three,
guc_client_alloc(), guc_client_free(), and gem_allocate_guc_obj().
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_g
There are four non-static functions in i915_guc_submission.c that take a
'dev' parameter. All are called only from GuC loader code, and can be
easily converted to accept 'dev_priv' instead.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 14 +++
ion struct drm_device *DEV;
identifier DEV_PRIV;
expression E;
@@
{
...
(
struct drm_i915_private *DEV_PRIV;
|
struct drm_i915_private *DEV_PRIV = E;
)
<...
- INTEL_INFO(DEV)->gen
+ INTEL_GEN(DEV_PRIV)
...>
}
Plus manual deletion of one now-unused local "
On 10/06/16 17:59, Patchwork wrote:
== Series Details ==
Series: series starting with drm/i915/guc: suppress GuC-related message on
non-GuC platforms (rev2)
URL : https://patchwork.freedesktop.org/series/8380/
State : failure
== Summary ==
Series 8380v2 Series without cover letter
http://pa
On 13/06/16 10:48, Tvrtko Ursulin wrote:
On 10/06/16 17:51, Dave Gordon wrote:
This patch refactors the driver's handling and tracking of doorbells, in
preparation for a later one which will resolve a suspend-resume issue.
There are three resources to be managed:
1. Cachelines: a single
On 13/06/16 10:28, Tvrtko Ursulin wrote:
On 10/06/16 18:35, Dave Gordon wrote:
More Coccinellery ...
Wherever we find "INTEL_INFO(dev)->gen", and have a suitable
"dev_priv" in scope, replace it with "INTEL_GEN(dev_priv)".
At this time, we've found 189 ins
On 11/06/16 06:50, Patchwork wrote:
== Series Details ==
Series: series starting with [1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for
static functions
URL : https://patchwork.freedesktop.org/series/8556/
State : warning
== Summary ==
Series 8556v1 Series without cover letter
http://patch
On 13/06/16 11:53, Tvrtko Ursulin wrote:
On 13/06/16 11:25, Dave Gordon wrote:
On 13/06/16 10:48, Tvrtko Ursulin wrote:
On 10/06/16 17:51, Dave Gordon wrote:
This patch refactors the driver's handling and tracking of
doorbells, in
preparation for a later one which will resolve a su
simplify error handling.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 62 +++---
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drive
Bitmap operators are overkill when touching only one bit.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm
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.
v2: use kernel bitmap-printing format (%pb) rather than %x.
Signed-off-by: Dave Gordon
Revie
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
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 110 ++---
1 file c
s
the doorbell handling, and then (in the last patch of the set)
ensures that the doorbell hardware is fully (re-)initialised when
the GuC is (re-)loaded.
v2:
Patches reorganised (split), with longer commit message
v3:
Rebased, patch [6/7] inserted into sequence
Dave Gordon (7):
drm/i915/guc
ng each
in turn, so that 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.
v2: don't use kmap_atomic() now that client page 0 is kept mapped.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
-
s and simplify recovery.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 62 +++---
1 file changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/dr
These registers are not actually writable by the CPU; only the GuC can
actually program them. So let's not do writes that have no effect.
Signed-off-by: Dave Gordon
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 5 -
1 file changed, 5 deletions(-)
diff
re lifetime
of the client. We will use this new feature in the next patch.
v2: Trivial independent fixes pushed ahead as separate patches.
MUCH longer commit message :) [Tvrtko Ursulin]
Signed-off-by: Dave Gordon
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_guc_submission.c | 94
On 13/06/16 10:13, Tvrtko Ursulin wrote:
On 10/06/16 18:29, Dave Gordon wrote:
Convert all static functions in i915_guc_submission.c that currently
take a 'dev' pointer to take 'dev_priv' instead (there are three,
guc_client_alloc(), guc_client_free(), and gem_allocate_gu
On 13/06/16 10:35, Tvrtko Ursulin wrote:
On 10/06/16 17:50, Dave Gordon wrote:
These registers are not actually writable by the CPU; only the GuC can
actually program them. So let's not do writes that have no effect.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submiss
On 14/06/16 06:27, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: updates to GuC doorbell handling (rev2)
URL : https://patchwork.freedesktop.org/series/8553/
State : failure
== Summary ==
Series 8553v2 drm/i915/guc: updates to GuC doorbell handling
http://patchwork.freedesktop.
On 15/06/16 09:42, vinoth eswaran wrote:
Hello Mr.David Gordon,
I working on an embedded project with Minnowboard Turbot. The goal is
to have a camera application running as fast as possible (within 2
sec).
For this, I have replaced the UEFI bootloader with the U-boot (Latest
git version - uboo
k may get satisfied right after
> sending interrupt to guc and context may complete. Scheduler will
> then incorrectly mark the context to be in wait state.
So we need to change this register setting to GFX_FORWARD_VBLANK_COND.
Signed-off-by: Dave Gordon
Cc: Harsh Chheda
---
drivers/gpu/
efore should not) be used to index GuC statistics
or similar host-managed tracking data. In particular, i915_guc_submit()
produces (and debugfs decodes) GuC submission statistics which should be
indexed by driver-engine-id rather then guc-engine-id.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm
this case cannot arise.
Consequently, the GuC doesn't need to see VBlanks, and we may be
waking it up unnecessarily by sending them. So let's not ...
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_guc_loader.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
efore should not) be used to index GuC statistics
or similar host-managed tracking data. In particular, i915_guc_submit()
produces (and debugfs decodes) GuC submission statistics which should be
indexed by driver-engine-id rather then guc-engine-id.
Signed-off-by: Dave Gordon
Reviewed-by: Chris W
On 22/06/16 09:31, Daniel Vetter wrote:
On Tue, Jun 21, 2016 at 07:11:22PM +0100, Peter Antoine wrote:
From: Alex Dai
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 bef
y set the field to "never send VBlanks to the GuC".)
v3:
Remove the line of code completely (original set the field
to ALWAYS forward, v1 changed it to CONDITIONAL forwarding,
v2 explicitly set it to NEVER, v3 just doesn't touch it at
all, as we know it's already
On 24/06/16 17:37, Chris Wilson wrote:
On Fri, Jun 24, 2016 at 05:04:46PM +0100, Matthew Auld wrote:
The gen6_for_all_pdes macro does the upper-bound evaluation after
accessing the page_table array, hence on the final iteration we end up
hitting an out-of-bounds error:
[ 1023.831657] UBSAN: Und
e
of using "&& (..., true)" rather than ": (..., 1) : 0", and
of course eliminating the redundant 'temp'.
Furthermore, the "all_pdes" version is only used in one place,
so we can improve code efficiency by changing both the macro
parameters and the c
On 25/06/16 06:26, Patchwork wrote:
== Series Details ==
Series: drm/i915: fix out-of-bounds page_table access (rev2)
URL : https://patchwork.freedesktop.org/series/9148/
State : warning
== Summary ==
Series 9148v2 drm/i915: fix out-of-bounds page_table access
http://patchwork.freedesktop.or
On 21/06/16 19:11, Peter Antoine wrote:
Rename some of the GuC fw loading code to make them more general. We
will utilize 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 intel_uc_fw. Prefix of tts members,
such a
On 21/06/16 19:11, Peter Antoine wrote:
From: Alex Dai
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
On 21/06/16 19:11, Peter Antoine wrote:
From: Alex Dai
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.
Signed-off-by: Alex Dai
Signed-off-by
5_drpc_info", i915_drpc_info, 0},
This is OK, although it should probably be unified with the GuC load
status function (i.e. two trivial wrappers round a common printing
function). But we can do that later, so:
Reviewed-by: Dave Gordon
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 21/06/16 19:11, Peter Antoine wrote:
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_guc_submission.c | 65 ++
drivers/gpu/
On 21/06/16 19:11, Peter Antoine wrote:
This patch adds the HuC Loading for the BXT.
Version 1.x of the HuC firmware.
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_gem.c | 13 +++--
drivers/gpu/drm/i915/intel_guc_loader.c | 29 +
driv
On 28/06/16 15:54, Dave Gordon wrote:
On 21/06/16 19:11, Peter Antoine wrote:
From: Alex Dai
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
few microseconds, which some of them do. Maybe we need an optimistic
spin for a few uS to handle the quick commands followed by a sleeping
wait in the cases where it takes long enough that we don't mind the
extra wakeup latency?
.Dave.
Signed-off-by: Tvrtko Ursulin
Reported-by: Imre Deak
Part spin-wait, part sleep-wait.
Plus one example of where it might be used.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
On 29/06/16 00:03, Rodrigo Vivi wrote:
I don't believe we need to be that extreme here.
Daniel asked a cleaner version, but we don't need to block the huc on
a full rework of an unified fw loader.
Oh, I agree, we should take this "mostly" as-is and then reunify them after.
.Dave.
___
On 10/11/15 23:27, yu@intel.com wrote:
From: Alex Dai
We keep a copy of GuC fw in a GEM obj. However its content is lost
if the GEM obj is swapped (igt/gem_evict_*). Therefore, the later
fw loading during GPU reset will fail. Mark the obj dirty after
copying data into the pages. So its cont
On 24/11/15 16:04, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 03:47:02PM +, Dave Gordon wrote:
On 10/11/15 23:27, yu@intel.com wrote:
From: Alex Dai
We keep a copy of GuC fw in a GEM obj. However its content is lost
if the GEM obj is swapped (igt/gem_evict_*). Therefore, the later
On 25/11/15 13:17, Wang, Zhi A wrote:
OK. I see. Thanks Michel! :) Have a nice day. :)
Thanks,
Zhi.
-Original Message-
From: Thierry, Michel
Sent: Wednesday, November 25, 2015 9:15 PM
To: Wang, Zhi A; intel-gfx@lists.freedesktop.org
Cc: Han, Xu; Li, Weinan Z; He, Min; Lv, Zhiyuan; Tian
201 - 300 of 1151 matches
Mail list logo
