Re: [Intel-gfx] [PATCH 05/18] drm/i915: Move GEM activity tracking into a common struct reservation_object

On 14/09/16 18:35, Chris Wilson wrote: On Wed, Sep 14, 2016 at 12:44:04PM +0300, Joonas Lahtinen wrote: On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote: -static inline bool -i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj, - int

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

On 14/09/16 16:22, Tvrtko Ursulin wrote: On 12/09/2016 21:19, Dave Gordon wrote: Renaming to more consistent scheme, and updating comments, mostly about i915_guc_wq_reserve(), aka i915_guc_wq_check_space(). Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/dr

[Intel-gfx] [PATCH v3] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

ris Wilson's preferred names for flag-related functions v3: Remove a couple of changes left over from a prototype version Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com> Sign

Re: [Intel-gfx] [PATCH] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

On 12/09/16 16:48, Tvrtko Ursulin wrote: Hi, On 09/09/16 20:48, Dave Gordon wrote: This just hides the existing obj->dirty flag inside a trivial inline setter, to discourage non-GEM code from looking too closely. The flag is renamed to emphasise that it is private to the GEM mem

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

On 14/09/16 13:32, Dave Gordon wrote: On 13/09/16 10:10, Jani Nikula wrote: On Sat, 10 Sep 2016, Dave Gordon <david.s.gor...@intel.com> wrote: Thanks, the other things I was thinking of fixing in the remaining files were generally things like if (INTEL_INFO(dev)->gen < 5 |

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

On 13/09/16 10:10, Jani Nikula wrote: On Sat, 10 Sep 2016, Dave Gordon <david.s.gor...@intel.com> wrote: Thanks, the other things I was thinking of fixing in the remaining files were generally things like if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev)) Is that a real or a mad

[Intel-gfx] [PATCH] drm/i915: Only expand COND once in wait_for()

turned out that due to a missing iniitialiser, gcc had "gone wild trimming undefined code" :( This version acheives a rather more modest (but still worthwhile) gain of ~550 bytes. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Original-idea-by: Chris Wilson <ch...@chris-wils

[Intel-gfx] [PATCH 2/3] drm/i915/guc: general tidying up (loader)

Renaming to more consistent scheme, delete unused definitions Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_guc_reg.h | 3 --- drivers/gpu/drm/i915/intel_guc_loader.c | 27 --- 2 files changed, 16 insertions(+), 14 del

[Intel-gfx] [PATCH 1/3] drm/i915: clarify PMINTRMSK/pm_intr_keep usage

No functional changes; just renaming a bit, tweaking a datatype, prettifying layout, and adding comments, in particular in the GuC setup code that touches this data. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/dr

[Intel-gfx] [PATCH 3/3] drm/i915/guc: general tidying up (submission)

Renaming to more consistent scheme, and updating comments, mostly about i915_guc_wq_reserve(), aka i915_guc_wq_check_space(). Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submission.c | 63 +++--- drivers/gpu/drm/i915/intel

[Intel-gfx] [PATCH 0/3] (Final) tidying up of GuC code

Mostly renaming the GuC functions to use a more consistent naming scheme, along with updating comments to clarify some of the code. Dave Gordon (3): drm/i915: clarify PMINTRMSK/pm_intr_keep usage drm/i915/guc: general tidying up (loader) drm/i915/guc: general tidying up (submission

[Intel-gfx] [PATCH 0/3] drm/i915: use INTEL_GEN(dev_priv) wherever possible

als with those that needed a little manual tweaking, and patch 3 is just intel_display.c separated out 'cos it's huge. Dave Gordon (3): drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen (part 2) drm/i915: p

[Intel-gfx] [PATCH 3/3] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen (part 3)

hange also lets us remove a local variable. This patch covers just intel_display.c, which gets its own patch because it's large, and is also a particularly heavy user of "INTEL_INFO()->gen"; about as many uses as the whole of the rest of the driver put together. Signed-off-by: Dave Gordon &

[Intel-gfx] [PATCH 1/3] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

NFO(DEV)->gen + INTEL_GEN(DEV_PRIV) ...> } @dev_priv_local@ idexpression 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(

[Intel-gfx] [PATCH 2/3] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen (part 2)

IS_CHERRYVIEW(dev))" and then manually to "if (INTEL_GEN(dev_priv) < 7 || IS_CHERRYVIEW(dev_priv))" Also in a few cases we can remove or move a local variable. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_gem_fence.c | 9 ++

Re: [Intel-gfx] [PATCH v3] drm/i915: Emit to ringbuffer directly

we're between a begin and an advance, or an advance and a begin (when writing to the ring is not allowed!). .Dave. * Rebase and tidy. Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gor...@intel.com&

Re: [Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

On 09/09/16 22:58, Chris Wilson wrote: On Fri, Sep 09, 2016 at 10:37:46PM +0100, 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)", which is the pre

[Intel-gfx] [PATCH] drm/i915: prefer INTEL_GEN(dev_priv) to INTEL_INFO(dev)->gen

NFO(DEV)->gen + INTEL_GEN(DEV_PRIV) ...> } @dev_priv_local@ idexpression 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(

[Intel-gfx] [PATCH] drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()

ris Wilson's preferred names for flag-related functions Inspired-by: http://www.spinics.net/lists/intel-gfx/msg92390.html Cc: Chris Wilson <ch...@chris-wilson.co.uk> Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c| 2 +- drive

Re: [Intel-gfx] [RFC] drm/i915: Emit to ringbuffer directly

On 09/09/16 09:32, Tvrtko Ursulin wrote: On 08/09/16 17:40, Chris Wilson wrote: On Thu, Sep 08, 2016 at 04:12:55PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin This removes the usage of intel_ring_emit in favour of directly writing to the ring buffer. I have

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

On 08/09/16 00:02, Nicolas Iooss wrote: On 07/09/16 18:03, Dave Gordon wrote: On 06/09/16 21:36, Nicolas Iooss wrote: On 06/09/16 12:21, Dave Gordon wrote: On 04/09/16 19:58, Nicolas Iooss wrote: When building the kernel with clang and some warning flags, the compiler reports that the return

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: use symbolic names for module parameter values (rev5)

On 08/09/16 08:52, Patchwork wrote: == Series Details == Series: drm/i915/guc: use symbolic names for module parameter values (rev5) URL : https://patchwork.freedesktop.org/series/10188/ State : failure == Summary == Series 10188v5 drm/i915/guc: use symbolic names for module parameter

[Intel-gfx] [CI_RESEND v4 4/5] drm/i915/guc: use symbolic names in setting defaults for module parameters

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_params.c | 10 +-

[Intel-gfx] [CI_RESEND v4 5/5] drm/i915/guc: ignore unrecognised loading & submission options

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 <david.s.gor...@intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> --- drivers/gpu/drm/i915/intel_guc.h

[Intel-gfx] [CI_RESEND v4 2/5] drm/i915/guc: symbolic names for GuC firmare loading preferences

uses names 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 <david.s.gor...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@

[Intel-gfx] [CI_RESEND v4 0/5] drm/i915/guc: use symbolic names for module parameter values

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

[Intel-gfx] [CI_RESEND v4 3/5] drm/i915/guc: symbolic name for GuC log-level none

e same numeric value that is already used. This should produce identical code to the previous version! Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> --- drivers/gpu/drm/i915/i915_guc_sub

[Intel-gfx] [CI_RESEND v4 1/5] drm/i915/guc: symbolic names for GuC submission preferences

uses 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 <david.s.gor...@intel.com> Cc: Tvrtko Ursu

Re: [Intel-gfx] [PATCH v2] drm/i915: don't track relative-constants-mode

On 26/08/16 20:55, Chris Wilson wrote: On Fri, Aug 26, 2016 at 08:46:25PM +0100, Dave Gordon wrote: @@ -1520,6 +1528,14 @@ static void eb_export_fence(struct drm_i915_gem_object *obj, if (ret) return ret; + if (instp_mode != I915_EXEC_CONSTANTS_REL_GENERAL

[Intel-gfx] [PATCH v6] drm: two more (drm_)printk() wrapper macros (fixup)

it seems unlikely that they'll be as useful. v2: Fix whitespace, missing ## (Eric Engestrom) v3: Much simplified after underlying functions were reworked. v6: Fixup, effectively revert v2 and apply v3 Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Eric Engestrom

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

On 06/09/16 21:36, Nicolas Iooss wrote: On 06/09/16 12:21, Dave Gordon wrote: On 04/09/16 19:58, Nicolas Iooss wrote: When building the kernel with clang and some warning flags, the compiler reports that the return value of dcs_get_backlight() may be uninitialized: drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH v4 10/25] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

On 07/09/16 14:52, kbuild test robot wrote: Hi Tom, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160907] [cannot apply to v4.8-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] [Suggest to use

Re: [Intel-gfx] [PATCH 06/17] drm/i915: Move obj->dirty:1 to obj->flags

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.

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dsi: silence a warning about uninitialized return value

. 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 fix anyway ... Reviewed-by: Dave Gordon <david.s.gor...@intel.com> .Dave. drivers/gp

Re: [Intel-gfx] S4 resume breakage with i915 driver

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

Re: [Intel-gfx] [PATCH 14/18] drm/i915/guc: Prepare for nonblocking execbuf submission

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

Re: [Intel-gfx] igt/gem_exec_nop parallel test: why it isn't useful

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

Re: [Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

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

[Intel-gfx] igt/gem_exec_nop parallel test: why it isn't useful

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

[Intel-gfx] [PATCH] Another flavour of for_each_engine_masked()

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 <david.s.gor...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Joonas Lahtinen &

[Intel-gfx] [PATCH v2] drm/i915: don't track relative-constants-mode

Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- 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(-)

Re: [Intel-gfx] [PATCH] drm/i915: don't track relative-constants-mode

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 automatically

[Intel-gfx] [PATCH] drm/i915: don't track relative-constants-mode

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH v5 3/4] drm/i915/guc: revisit GuC loader message levels

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: D

[Intel-gfx] [PATCH v5 0/4] Reclassify messages from GuC loader/submission

ut 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 some

[Intel-gfx] [PATCH v5 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

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 <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submi

[Intel-gfx] [PATCH v5 1/4] drm: two more (drm_)printk() wrapper macros

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 <david.s.gor...@intel.com> Previously-Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com> (

[Intel-gfx] [PATCH v5 4/4] NOMERGE: next version of GuC firmware is 8.11

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_pa

[Intel-gfx] [PATCH v4 3/5] drm/i915/guc: symbolic name for GuC log-level none

e same numeric value that is already used. This should produce identical code to the previous version! Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> --- drivers/gpu/drm/i915/i915_guc_submission.c | 2 +- drivers/gpu/drm/i915/intel_guc_fwif.h

[Intel-gfx] [PATCH v4 5/5] drm/i915/guc: ignore unrecognised loading & submission options

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 <david.s.gor...@intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> --- drivers/gpu/drm/i915/intel_guc.h

[Intel-gfx] [PATCH v4 4/5] drm/i915/guc: use symbolic names in setting defaults for module parameters

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 <david.s.gor...@intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> Cc: Tv

[Intel-gfx] [PATCH v4 2/5] drm/i915/guc: symbolic names for GuC firmare loading preferences

uses names 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 <david.s.gor...@intel.com> Cc: Jani Nikula <jani.nik

[Intel-gfx] [PATCH v4 1/5] drm/i915/guc: symbolic names for GuC submission preferences

uses 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 <david.s.gor...@intel.com> Cc: Jani

[Intel-gfx] [PATCH v4 0/5] drm/i915/guc: use symbolic names for module parameter values

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Reattach comment, complete type specification

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

Re: [Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

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

Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

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

[Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> --- 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..f2

[Intel-gfx] [PATCH v7] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

for 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

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

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: D

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_pa

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

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 <david.s.gor...@intel.com> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

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 <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submi

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

ut 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 load

[Intel-gfx] [PATCH v4 3/5] drm/i915/guc: symbolic name for GuC log-level none

e same numeric value that is already used. This should produce identical code to the previous version! Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@linux.intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> --- drivers/gpu/drm/i915/i915_guc_sub

[Intel-gfx] [PATCH v4 5/5] drm/i915/guc: ignore unrecognised loading & submission options

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 <david.s.gor...@intel.com> Cc: Jani Nikula <jani.nik...@linux.intel.com> --- drivers/gpu/drm/i915/intel_guc.h

[Intel-gfx] [PATCH v4 1/5] drm/i915/guc: symbolic names for GuC submission preferences

uses 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 <david.s.gor...@intel.com> Cc: Tvrtko Ursu

[Intel-gfx] [PATCH v4 0/5] drm/i915/guc: use symbolic names for module parameter values

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

[Intel-gfx] [PATCH v4 2/5] drm/i915/guc: symbolic names for GuC firmare loading preferences

uses names 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 <david.s.gor...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@

[Intel-gfx] [PATCH v4 4/5] drm/i915/guc: use symbolic names in setting defaults for module parameters

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_params.c | 10 +-

Re: [Intel-gfx] [PATCH 2/2] drm/i915/error: capture errored context based on request context-id

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 <david.s.gor...@intel.com> Context capture hasn't worked for a while now, since the introduction of execlists because the function that records active context is usin

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

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

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

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-time round

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

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 (new) test

Re: [Intel-gfx] [PATCH 1/2] igt/gem_exec_nop: add burst submission to parallel execution test

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

Re: [Intel-gfx] [PATCH 5/5 v3] drm/i915: debugfs spring cleaning

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.

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Reclassify messages from GuC loader/submission (rev3)

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

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

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 <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submi

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

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 <david.s.gor...@intel.com> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

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: D

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_pa

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

ut 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 load

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915/huc: Add HuC fw loading support

today's version. There are three minor points (numbered below) to be addressed, but once those are fixed, then: Reviewed-by: Dave Gordon <david.s.gor...@intel.com> 1: Several typos in the commit message above (e.g. 'dev_provate', 'automic'), --- drivers/gpu/drm/i915/Makefile

Re: [Intel-gfx] [PATCH v4 6/6] drm/i915/huc: Add BXT HuC Loading Support

we'll fix that in the next version, when the naming gets unified across all the uC devices :) So Reviewed-by: Dave Gordon <david.s.gor...@intel.com> /** * intel_huc_load_ucode() - DMA's the firmware * @dev: the drm device @@ -157,6 +160,10 @@ void intel_huc_init(struct drm_devi

Re: [Intel-gfx] [PATCH 15/33] drm/i915: Track pinned vma inside guc

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

[Intel-gfx] [PATCH v4 3/4] drm/i915/guc: revisit GuC loader message levels

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: D

[Intel-gfx] [PATCH v4 4/4] NOMERGE: next version of GuC firmware is 8.11

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_pa

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

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 <david.s.gor...@intel.com> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>

[Intel-gfx] [PATCH v4 0/4] Reclassify messages from GuC loader/submission

ode 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 levels

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

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 <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submi

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915/huc: Unified css_header struct for GuC and HuC

; + err = -ENOEXEC; + goto fail; + } 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 <david.s.gor...@intel.com> even without the extra blank lines. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

;yu@intel.com> Signed-off-by: Peter Antoine <peter.anto...@intel.com> Reviewed-by: Dave Gordon <david.s.gor...@intel.com> 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_debu

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

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

Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/guc: Make the GuC fw loading helper functions general

eter.anto...@intel.com> Reviewed-by: Dave Gordon <david.s.gor...@intel.com> 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

Re: [Intel-gfx] Correct DMC version for Skylake (1.23 vs 1.26)

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

Re: [Intel-gfx] [PATCH] drm/i915: Store number of active engines in device info

les changed, 11 insertions(+), 10 deletions(-) LGTM. Reviewed-by: Dave Gordon <david.s.gor...@intel.com> 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

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Consolidate firmware major-minor to one place

orrect major and minor versions per platform. v2: Rebased for KBL. Signed-off-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Dave Gordon <david.s.gor...@intel.com> Cc: Rodrigo Vivi <rodrigo.v...@intel.com> Cc: Peter Antoine <peter.anto...@intel.com> Cc: Michel Thierry <m

Re: [Intel-gfx] [PATCH] drm/i915: Restore DMC file names and the proper 1.26 for SKL.

e the file names instead keeping the symbolic links (Dave). Cc: sta...@vger.kernel.org Cc: Dave Gordon <david.s.gor...@intel.com> Cc: Jani Nikula <jani.nik...@intel.com> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: Patrik Jakobsson <patrik.jakobs...@linux.intel.com>

[Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

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 <david.s.gor...@intel.com> Reviewed-by: Eric Engestrom <eric.engest...@imgtec.com>

[Intel-gfx] [PATCH v4 2/4] drm/i915/guc: downgrade some DRM_ERROR() messages to DRM_WARN()

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 <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submi

  1   2   3   4   5   6   7   8   9   10   >