Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with drm/i915/guc: suppress GuC-related message on non-GuC platforms (rev2)

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

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

truct 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 "dev

[Intel-gfx] [PATCH 2/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for intra-module functions

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

[Intel-gfx] [PATCH 1/2] drm/i915/guc: prefer 'dev_priv' to 'dev' for static functions

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

[Intel-gfx] [PATCH v2 6/6] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

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 <david.s.gor...@intel.com> --- drive

[Intel-gfx] [PATCH v2 5/6] drm/i915/guc: refactor doorbell management code

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

[Intel-gfx] [PATCH v2 4/6] drm/i915/guc: remove writes to GEN8_DRBREG registers

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submission.c | 5 - 1 file changed, 5 deletions(-) diff

[Intel-gfx] [PATCH v2 3/6] drm/i915/guc: prefer __set/clear_bit() to bitmap_set/clear()

Bitmap operators are overkill when touching only one bit. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- 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/g

[Intel-gfx] [PATCH v2 2/6] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

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

[Intel-gfx] [PATCH v2 0/6] drm/i915/guc: updates to GuC doorbell handling

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_DRBREG

[Intel-gfx] [PATCH v2 1/6] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

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 <da

[Intel-gfx] [PATCH] drm/i915/guc: suppress GuC-related message on non-GuC platforms

ase of comprehension. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- 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/drive

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: fix GuC loading/submission check

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915/guc: refactor doorbell management code

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 later one

[Intel-gfx] [PATCH 2/4] drm/i915/guc: move guc_ring_doorbell() nearer to callsite

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 <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submission.c | 110 ++--- 1 file chang

[Intel-gfx] [PATCH 0/4] drm/i915: updates to GuC doorbell handling

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

[Intel-gfx] [PATCH 1/4] drm/i915/guc: add doorbell map to debugfs/i915_guc_info

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

[Intel-gfx] [PATCH 3/4] drm/i915/guc: refactor doorbell management code

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 <david.s.

[Intel-gfx] [PATCH 4/4] drm/i915/guc: (re)initialise doorbell h/w when enabling GuC submission

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 <david.s.

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Crop cursor image for CHV pipe C cursor issue

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/3] drm/i915/guc: fix GuC loading/submission check

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

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/3] drm/i915/guc: fix GuC loading/submission check

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: disable GuC submission earlier during GuC (re)load

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 just

[Intel-gfx] [PATCH 3/3] drm/i915/guc: enable GuC loading & submission by default

firmware loading Those warnings have been resolved, so this patch re-enables GuC loading and submission by default. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_params.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/g

[Intel-gfx] [PATCH 1/3] drm/i915/guc: fix GuC loading/submission check

and clarify DRM_INFO fallback message. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- 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/dr

[Intel-gfx] [PATCH 2/3] drm/i915/guc: disable GuC submission earlier during GuC (re)load

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

[Intel-gfx] [PATCH v4 4/4] Try inlining sg_next()

Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_drv.h | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i91

[Intel-gfx] [PATCH v4 2/4] drm/i915: optimise i915_gem_object_map() for small objects

a context image (currently up to 22 pages). v5: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_gem.c | 15 ++- 1 file changed, 10 inse

[Intel-gfx] [PATCH v4 1/4] drm/i915: refactor i915_gem_object_pin_map()

t clearer and easier to modify. v2: Restructure loop-over-pages & error check [Chris Wilson] v3: Add page count to debug messages [Chris Wilson] Convert WARN_ON() to GEM_BUG_ON() v4: Drop the DEBUG messages [Tvrtko Ursulin] Signed-off-by: Dave Gordon <david.s.gor...@int

[Intel-gfx] [PATCH v4 3/4] Introduce & use new lightweight SGL iterators

with the DMA address of each page in turn; the other provides the 'struct page' pointer required by many memory management operations. Various uses of for_each_sg_page() are then converted to the new macros. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Chris Wilson <ch...@chris-wil

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM

On 17/05/16 17:03, Patchwork wrote: == Series Details == Series: drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM URL : https://patchwork.freedesktop.org/series/7300/ State : failure == Summary == Series 7300v1 drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM

[Intel-gfx] [PATCH v2] drm/i915/bxt: reserve space for RC6 in the the GuC WOPCM

-check and the register-programming operations [Dave Gordon]. Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter Antoine <peter.anto...@intel.com> Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Nick Hoath <nicholas.ho...@intel.com> Tested-by:

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [v4,1/2] drm/i915: refactor i915_gem_object_pin_map()

On 17/05/16 14:23, Patchwork wrote: == Series Details == Series: series starting with [v4,1/2] drm/i915: refactor i915_gem_object_pin_map() URL : https://patchwork.freedesktop.org/series/7292/ State : failure == Summary == Series 7292v1 Series without cover letter

Re: [Intel-gfx] [PATCH 1/3] drm/i915: refactor i915_gem_object_pin_map()

On 17/05/16 10:22, Tvrtko Ursulin wrote: On 16/05/16 16:19, Dave Gordon wrote: The recently-added i915_gem_object_pin_map() can be further optimised for "small" objects. To facilitate this, and simplify the error paths before adding the new code, this patch pulls out the &quo

[Intel-gfx] [PATCH v4 2/2] drm/i915: optimise i915_gem_object_map() for small objects

a context image (currently up to 22 pages). v2: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH v4 1/2] drm/i915: refactor i915_gem_object_pin_map()

t clearer and easier to modify. v2: Restructure loop-over-pages & error check [Chris Wilson] v3: Add page count to debug messages [Chris Wilson] Convert WARN_ON() to GEM_BUG_ON() v4: Drop the DEBUG messages [Tvrtko Ursulin] Signed-off-by: Dave Gordon <david.s.gor...@in

[Intel-gfx] [PATCH v5 3/7] drm/i915/guc: add enable_guc_loading parameter

error-message levels, mostly ERROR->INFO, per review comments by Tvrtko Ursulin. v5: Dropped one more error message, disabled GuC submission on hypothetical firmware-free devices [Tvrtko Ursulin]. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Tvrtko Ursulin &l

Re: [Intel-gfx] [PATCH v4 3/7] drm/i915/guc: add enable_guc_loading parameter

On 13/05/16 16:31, Tvrtko Ursulin wrote: On 13/05/16 15:36, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The exist

[Intel-gfx] [PATCH 3/3] Introduce & use new lightweight SGL iterators

with the DMA address of each page in turn; the other provides the 'struct page' pointer required by many memory management operations. Various uses of for_each_sg_page() are then converted to the new macros. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Chris Wilson <ch...@chris-wil

[Intel-gfx] [PATCH 2/3] drm/i915: optimise i915_gem_object_map() for small objects

a context image (currently up to 22 pages). v5: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 1/3] drm/i915: refactor i915_gem_object_pin_map()

t clearer and easier to modify. v2: Restructure loop-over-pages & error check (Chris Wilson) v3: Add page count to debug messages (Chris Wilson) Convert WARN_ON() to GEM_BUG_ON() Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursu..

Re: [Intel-gfx] [PATCH RESEND 1/2] drm/i915: make device info bitfield flags bools

On 13/05/16 16:05, Tvrtko Ursulin wrote: On 13/05/16 15:47, Jani Nikula wrote: On Fri, 13 May 2016, Chris Wilson wrote: On Fri, May 13, 2016 at 03:25:05PM +0100, Tvrtko Ursulin wrote: On 13/05/16 15:04, Jani Nikula wrote: This is more robust for assignments and

[Intel-gfx] [PATCH v4 2/7] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED

or testing enable_guc_submission. v4: Added a couple more uses of the new macro. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 10 -- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 2 +- driv

[Intel-gfx] [PATCH v4 3/7] drm/i915/guc: add enable_guc_loading parameter

error-message levels, mostly ERROR->INFO, per review comments by Tvrtko Ursulin. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_gem.c| 1 - drivers/gpu/drm/i915/i915_guc_submission.c | 4 +- drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] [PATCH v4 0/7] Enable GuC submission

by default on suitable platforms [PATCH 7/7]. Dave Gordon (7): drm/i915/guc: rename loader entry points drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED drm/i915/guc: add enable_guc_loading parameter drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space,submi

[Intel-gfx] [PATCH v4 6/7] drm/i915/guc: rework guc_add_workqueue_item()

in a GuC log) [Tvrtko Ursulin]. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submission.c | 71 +++--- drivers/gpu/drm/i915/intel_guc.h | 2 +- drivers/gpu

[Intel-gfx] [PATCH v4 7/7] drm/i915/guc: change default to using GuC submission if possible

ed. If any of these conditions are not met, the driver will fall back to using execlist mode. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

[Intel-gfx] [PATCH v4 5/7] drm/i915/guc: don't spinwait if the GuC's workqueue is full

how often we find the WQ full. v2: Flag the likely() code path (Tvtrko Ursulin). v4: Add/update comments about failure counters (Tvtrko Ursulin). Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c| 1 + drivers/gpu/dr

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

On 10/05/16 15:37, Tvrtko Ursulin wrote: On 06/05/16 17:39, Dave Gordon wrote: On 29/04/16 16:03, Tvrtko Ursulin wrote: [snip] +goto fail; +if (fw_path == NULL) +goto fail; +if (*fw_path == '\0') { +DRM_ERROR("No GuC firmware known for this platf

[Intel-gfx] [PATCH v4 4/7] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

from) the request. v2: GEM_BUG_ON() for bad GuC client (Tvrtko Ursulin). Add/update kerneldoc explaining check_space/submit protocol Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> --- drivers/gpu/drm/i915/i915_guc_

[Intel-gfx] [PATCH v4 1/7] drm/i915/guc: rename loader entry points

The GuC initialisation code could do other things apart from loading firmware, so here we rename the three primary entry points to remove any specific reference to "ucode" (no functional changes, just renaming). Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- driv

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On 09/05/16 13:32, Jani Nikula wrote: On Fri, 06 May 2016, Dave Gordon <david.s.gor...@intel.com> wrote: On 06/05/16 15:33, Chris Wilson wrote: On Fri, May 06, 2016 at 03:16:25PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin <tvrtko.ursu...@intel.com> To be used for more e

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

On 06/05/16 14:43, Tvrtko Ursulin wrote: From: Tvrtko Ursulin This way optimization from a previous patch works even better. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--

[Intel-gfx] [PATCH 2/3] drm/i915: refactor i915_gem_object_pin_map()

t clearer and easier to modify. v2: Restructure loop-over-pages & error check (Chris Wilson) v3: Use new nicer SGL page-range iterator (Dave Gordon) Add page count to debug messages (Chris Wilson) Convert WARN_ON() to GEM_BUG_ON() Signed-off-by: Dave Gordon <david.s.gor...@in

[Intel-gfx] [PATCH 3/3] drm/i915: optimise i915_gem_object_map() for small objects

a context image (currently up to 22 pages). v5: change name of local array [Chris Wilson] Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursu...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 1/3] Introduce & use new SG page iterators

() are then converted to the new simpler macros. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Imre Deak <imre.d...@intel.com> Cc: linux-ker...@vger.kernel.org --- drivers/gpu/drm/i915/i915_cmd_parser.c | 8 drivers/gpu/drm/i915/i915_gem.c | 10 -- dri

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmabuf: Pin pages as we flush for CPU access

On 06/05/16 15:36, Chris Wilson wrote: As a precautionary defensive measure against changes to the core (where we stop changing domains when unbinding), we want to ensure that the pages are available when we want to start CPU access, otherwise we will not perform the requisite clflushes to make

[Intel-gfx] [PATCH v3 5/6] drm/i915/guc: rework guc_add_workqueue_item()

happen" errors. With those changes, we can convert it to void, as suggested by Chris Wilson, and update the calling code appropriately. v3: Note that we're now putting the request seqno in the "fence_id" field of each GuC-work-item, in case it turns up somewhere useful (Tvrtko

[Intel-gfx] [PATCH v3 6/6] drm/i915/guc: change default to using GuC submission if possible

ed. If any of these conditions are not met, the driver will fall back to using execlist mode. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/driv

[Intel-gfx] [PATCH v3 4/6] drm/i915/guc: don't spinwait if the GuC's workqueue is full

how often we find the WQ full. v3: Flag the likely() code path (Tvtrko Ursulin). Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c| 1 + drivers/gpu/drm/i915/i915_guc_submission.c | 18 +++--- drivers/gpu/drm/i915/intel

[Intel-gfx] [PATCH v3 1/6] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED

GuC exists, not whether we're trying to use it for submission. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 10 -- drivers/gpu/drm/i915/intel_uncore.c | 2 +- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i

[Intel-gfx] [PATCH v3 3/6] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

from) the request. v3: GEM_BUG_ON() for bad GuC client (Tvrtko Ursulin). Add/update kerneldoc explaining check_space/submit protocol Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submission.c | 46 -- drivers/gpu/dr

[Intel-gfx] [PATCH v3 2/6] drm/i915/guc: add enable_guc_loading parameter

QUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. Signed-off-by: Dave

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Do not use a bitfield for INTEL_INFO->num_pipes

quite a lot! Reviewed-by: Dave Gordon <david.s.gor...@intel.com> .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On 06/05/16 15:33, Chris Wilson wrote: On Fri, May 06, 2016 at 03:16:25PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin To be used for more efficient Gen range checking. Signed-off-by: Tvrtko Ursulin ---

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

On 29/04/16 16:17, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

On 29/04/16 16:03, Tvrtko Ursulin wrote: Hi, On 27/04/16 19:03, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The exist

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

On 29/04/16 16:45, Tvrtko Ursulin wrote: One late comment: On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On 06/05/16 09:55, Tvrtko Ursulin wrote: On 05/05/16 19:38, Dave Gordon wrote: On 29/04/2016 16:44, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of

Re: [Intel-gfx] [PATCH] drm/i915: Small display interrupt handlers tidy

On 06/05/16 14:27, Tvrtko Ursulin wrote: On 06/05/16 12:27, Chris Wilson wrote: On Fri, May 06, 2016 at 12:07:04PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away

Re: [Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6

On 06/05/16 10:37, Nick Hoath wrote: On 05/05/2016 16:04, Dave Gordon wrote: On 05/05/2016 15:02, Antoine, Peter wrote: The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space. That's NOT what WOPCM_TOP means. The GuC is allowed to use

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On 29/04/2016 16:44, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a

Re: [Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6

On 05/05/2016 15:02, Antoine, Peter wrote: The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space. That's NOT what WOPCM_TOP means. The GuC is allowed to use the space up to the value stored in the GUC_WOPCM_SIZE register (as the comment above

Re: [Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6

y, Swindon SN3 1RJ This patch resizes the GuC WOPCM (specifically on BXT) so that the GuC and RC6 memory spaces do not overlap. Issue: https://jira01.devtools.intel.com/browse/VIZ-6638 Signed-off-by: Peter Antoine <peter.anto...@intel.com> Signed-off-by: Dave Gordon <david.s.gor...@int

Re: [Intel-gfx] [PATCH 03/10] drm/i915: Fix gen8 semaphores id for legacy mode

On 29/04/2016 09:49, Chris Wilson wrote: On Fri, Apr 29, 2016 at 09:36:37AM +0100, Tvrtko Ursulin wrote: On 28/04/16 17:24, Chris Wilson wrote: With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

On 29/04/16 16:08, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Fix ordering of sanitize ppgtt and sanitize execlists

On 28/04/16 17:24, Chris Wilson wrote: The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_dma.c | 13 +

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()

On 28/04/16 18:48, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915: introduce & use i915_gem_object_mark_dirty() URL : https://patchwork.freedesktop.org/series/6491/ State : warning == Summary == Series 6491v1 Series without cover letter

Re: [Intel-gfx] [CI 22/25] drm/i915: Track the previous pinned context inside the request

On 28/04/16 09:56, Chris Wilson wrote: As the contexts are accessed by the hardware until the switch is completed to a new context, the hardware may still be writing to the context object after the breadcrumb is visible. We must not unpin/unbind/prune that object whilst still active and so we

Re: [Intel-gfx] [CI 17/25] drm/i915: Assign every HW context a unique ID

On 28/04/16 16:32, Chris Wilson wrote: On Thu, Apr 28, 2016 at 03:55:44PM +0100, Dave Gordon wrote: On 28/04/16 09:56, Chris Wilson wrote: The hardware tracks contexts and expects all live contexts (those active on the hardware) to have a unique identifier. This is used by the hardware

Re: [Intel-gfx] [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()

On 28/04/16 17:34, Chris Wilson wrote: On Thu, Apr 28, 2016 at 05:26:20PM +0100, 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. Existing code that sets obj->dirty is then changed

Re: [Intel-gfx] [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()

On 28/04/16 17:36, Chris Wilson wrote: On Thu, Apr 28, 2016 at 05:26:21PM +0100, Dave Gordon wrote: intel_pin_and_map_ringbuffer_obj() should have been setting the dirty flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also updated to use the new function. Technically

[Intel-gfx] [PATCH 1/2] drm/i915: introduce & use i915_gem_object_mark_dirty()

on <ch...@chris-wilson.co.uk> Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_drv.h| 11 +++ drivers/gpu/drm/i915/i915_gem.c| 6 +++--- drivers/gpu/drm/i915/i915_gem_context.c| 2 +- drivers/gpu/drm/i915/i915_gem

[Intel-gfx] [PATCH 2/2] drm/i915: a couple more uses for i915_gem_object_mark_dirty()

intel_pin_and_map_ringbuffer_obj() should have been setting the dirty flag, but wasn't; and the LRC code in intel_lr_context_do_pin() is also updated to use the new function. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/intel_lrc.c

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Refactor common engine setup

On 28/04/16 14:47, Chris Wilson wrote: Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. Signed-off-by: Chris Wilson Cc: Tvrtko

Re: [Intel-gfx] [CI 18/25] drm/i915: Replace the pinned context address with its unique ID

On 28/04/16 09:56, Chris Wilson wrote: Rather than reuse the current location of the context in the global GTT for its hardware identifier, use the context's unique ID assigned to it for its whole lifetime. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin

Re: [Intel-gfx] [CI 17/25] drm/i915: Assign every HW context a unique ID

On 28/04/16 09:56, Chris Wilson wrote: The hardware tracks contexts and expects all live contexts (those active on the hardware) to have a unique identifier. This is used by the hardware to assign pagefaults and the like to a particular context. v2: Reorder to make sure ctx->link is not left

Re: [Intel-gfx] [CI 14/25] drm/i915: Manually unwind after a failed request allocation

On 28/04/16 09:56, Chris Wilson wrote: In the next patches, we want to move the work out of freeing the request and into its retirement (so that we can free the request without requiring the struct_mutex). This means that we cannot rely on unreferencing the request to completely teardown the

Re: [Intel-gfx] [CI 13/25] drm/i915: Remove the identical implementations of request space reservation

On 28/04/16 09:56, Chris Wilson wrote: Now that we share intel_ring_begin(), reserving space for the tail of the request is identical between legacy/execlists and so the tautology can be removed. In the process, we move the reserved space tracking from the ringbuffer on to the request. This is

Re: [Intel-gfx] Kernel Oops on 3.14.66

On 28/04/16 09:58, Andreas Lampersperger wrote: Hi Dave, thank you again. I searched, where the memory for the request came from, it is set in line 2158 of i915_gem.c

Re: [Intel-gfx] [PATCH] drm/i915: Validate execbuffer start/length arguments against the target bo

On 28/04/16 10:02, Chris Wilson wrote: On Thu, Apr 28, 2016 at 11:54:04AM +0300, Jani Nikula wrote: On Thu, 28 Apr 2016, Jani Nikula wrote: On Fri, 20 Nov 2015, Ville Syrjälä wrote: On Fri, Nov 20, 2015 at 03:11:04PM +, Chris

Re: [Intel-gfx] [CI-ping 15/15] drm/i915: Late request cancellations are harmful

On 22/04/16 23:57, John Harrison wrote: On 21/04/2016 14:04, John Harrison wrote: On 19/04/2016 13:35, Dave Gordon wrote: On 13/04/16 15:21, John Harrison wrote: On 13/04/2016 10:57, Daniel Vetter wrote: On Tue, Apr 12, 2016 at 09:03:09PM +0100, Chris Wilson wrote: Conceptually, each

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/bxt: Fix inadvertent CPU snooping due to incorrect MOCS config

On 27/04/16 15:53, Chris Wilson wrote: On Wed, Apr 27, 2016 at 04:25:09PM +0300, Eero Tamminen wrote: Hi, On 26.04.2016 20:25, Frederick, Michael T wrote: Sorry I'm not tracking all the MOCs discussions. I just want to indicate what the coherency means in SoC for BXT. GTI sets the

Re: [Intel-gfx] Kernel Oops on 3.14.66

2016-04-27 12:03 GMT+02:00 Dave Gordon <david.s.gor...@intel.com>: On 27/04/16 10:19, Andreas Lampersperger wrote: Hello, has anyone here a hint for me, what can cause this error. The error occures highly sporadic on different machines with intel hd graphics (ivb_gt1). I did also some

[Intel-gfx] [PATCH v2 5/5] DO NOT MERGE: change default to using GuC submission if possible

ed. If any of these conditions are not met, the driver will fall back to using execlist mode. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/driv

[Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

s Wilson, and update the calling code appropriately. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_guc_submission.c | 69 +++--- drivers/gpu/drm/i915/intel_guc.h | 2 +- drive

[Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

how often we find the WQ full. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c| 1 + drivers/gpu/drm/i915/i915_guc_submission.c | 16 +--- drivers/gpu/drm/i915/intel_guc.h | 8 3 files changed, 10 inse

[Intel-gfx] [PATCH v2 2/5] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

from) the request. Signed-off-by: Dave Gordon <david.s.gor...@intel.com> --- drivers/gpu/drm/i915/i915_guc_submission.c | 11 ++- drivers/gpu/drm/i915/intel_guc.h | 5 ++--- drivers/gpu/drm/i915/intel_lrc.c | 9 +++-- 3 files changed, 11 insertions(+), 14 del

[Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

2 REQUIRE must load/use the GuC, else leave the GPU wedged The new platform default (as coded here) will be to attempt to load the GuC iff the device has a GuC that requires firmware, but not yet to use it for submission. A later patch will change to enable it if appropriate. Signed-off-by: Dave

Re: [Intel-gfx] [PATCH 2/2] drm/i915/guc: default to using GuC submission where possible

On 26/04/16 15:00, Daniel Vetter wrote: On Mon, Apr 25, 2016 at 09:29:42AM +0100, Chris Wilson wrote: On Mon, Apr 25, 2016 at 08:31:07AM +0100, Dave Gordon wrote: On 22/04/16 19:51, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07:45:15PM +0100, Chris Wilson wrote: On Fri, Apr 22, 2016 at 07

<    1   2   3   4   5   6   7   8   9   10   >