Re: [Intel-gfx] [Announcement] 2016-Q2 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Hi all, We are pleased to announce another update of Intel GVT-g for Xen. Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/9] drm/i915: Rename request reference/unreference to get/put (rev2)

== Series Details == Series: series starting with [1/9] drm/i915: Rename request reference/unreference to get/put (rev2) URL : https://patchwork.freedesktop.org/series/10081/ State : failure == Summary == Applying: drm/i915: Rename request reference/unreference to get/put Using index info to

Re: [Intel-gfx] [I-G-T] igt/gem_mocs_settings: improve RC6 testings

-Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Thursday, July 21, 2016 9:40 PM To: Antoine, Peter Cc: intel-gfx@lists.freedesktop.org Subject: Re: [I-G-T] igt/gem_mocs_settings: improve RC6 testings On Tue, Jul 19, 2016 at

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/skl: Update plane watermarks atomically during plane updates

On Thu, Jul 21, 2016 at 03:23:40PM -0400, Lyude wrote: > Thanks to Ville for suggesting this as a potential solution to pipe > underruns on Skylake. > > On Skylake all of the registers for configuring planes, including the > registers for configuring their watermarks, are double buffered. New >

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/skl: Only flush pipes when we change the ddb allocation

On Thu, Jul 21, 2016 at 03:23:38PM -0400, Lyude wrote: > Manual pipe flushes are only necessary in order to make sure that we prevent > pipes with changed ddb allocations from overlapping from one another at > any point in time. Additionally, forcing us to wait for the next vblank > every time we

Re: [Intel-gfx] [I-G-T] igt/gem_mocs_settings: improve RC6 testings

On Tue, Jul 19, 2016 at 11:25:29AM +0100, Peter Antoine wrote: > On some platforms the MOCS values are not always saved and restored > on RC6 enter/exit. The rational is that the context with restore > these values. On these platforms the test will fail as it tests the > values by directly reading

[Intel-gfx] [PATCH] Revert "drm/i915: Enable RC6 immediately"

This reverts commit b12e0ee2080c ("drm/i915: Enable RC6 immediately"), as it was never meant to be sent anywhere other than the bug report for experimentation. Signed-off-by: Chris Wilson Cc: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH] Revert "drm/i915: Enable RC6 immediately"

This reverts commit b12e0ee2080c ("drm/i915: Enable RC6 immediately"), as it was never meant to be sent anywhere other than the bug report for experimentation. Signed-off-by: Chris Wilson Cc: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH v2 3/4] drm/i915/skl: Fix extra whitespace in skl_flush_wm_values()

Similar to how a vehicle will travel faster if you paint flames on it, cleaning up this extra whitespace is guaranteed to provide additional stability while updating watermark values. Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_pm.c | 1 - 1 file changed, 1 deletion(-)

[Intel-gfx] [PATCH v2 4/4] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[Intel-gfx] [PATCH v2 2/4] drm/i915/skl: Only flush pipes when we change the ddb allocation

Manual pipe flushes are only necessary in order to make sure that we prevent pipes with changed ddb allocations from overlapping from one another at any point in time. Additionally, forcing us to wait for the next vblank every time we have to update the watermark values because the cursor was

[Intel-gfx] [PATCH v2 1/4] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[Intel-gfx] [PATCH v2 0/4] drm/i915/skl: Finally fix watermarks

To Sebastian Reichel: I *think* I may have found the problem. Looked at ./scripts/get_maintainer.pl and apparently it's defaults aren't actually expected to work well with `git send-email`. I've added --norolestats and hopefully that should fix the issue. If the

[Intel-gfx] [PATCH] drm/i915: Correctly handle limited range YCbCr data on VLV/CHV

From: Ville Syrjälä Turns out the VLV/CHV fixed function sprite CSC expects full range data as input. We've been feeding it limited range data to it all along. To expand the data out to full range we'll use the color correction registers (brightness, contrast, and

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Check for a stuck waiter before a missed interrupt

On Thu, Jul 21, 2016 at 07:57:39AM +0100, Chris Wilson wrote: > As the interrupt wakeup counter only increments when we have a waiter, > before testing to see if that counter is unchanged we have to first > check that we do expect it to change (i.e. we have a waiter). > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/guc: use a separate GuC client for each engine

On Thu, Jul 21, 2016 at 07:15:39PM +0100, Dave Gordon wrote: > When using a single GuC client for multiple engines, the i915 driver has > to merge all work items into a single work queue, which the GuC firmware > then demultiplexes into separate submission queues per engine. In > theory, this

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

We had only DRM_INFO() and DRM_ERROR(), whereas the underlying printk() provides several other useful intermediate levels such as NOTICE and WARNING. So this patch fills out the set by providing both regular and once-only macros for each of the levels INFO, NOTICE, and WARNING, using a common

[Intel-gfx] [PATCH v4 3/3] 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: Dave Gordon

[Intel-gfx] [PATCH v4 2/3] 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 Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_guc_submission.c | 18

[Intel-gfx] [PATCH v4 0/3] drm/i915/guc: emit (drm) messages at the most appropriate level

A few adjustments to the messages emitted from the driver, promoting or demoting them to the level most suited to the target audience as well as the impact of the thing being reported. Dave Gordon (3): drm: extra printk() wrapper macros drm/i915/guc: downgrade some DRM_ERROR() messages to

[Intel-gfx] [PATCH v2 5/6] drm/i915/guc: use for_each_engine_id() where appropriate

Now that host structures are indexed by host engine-id rather than guc_id, we can usefully convert some for_each_engine() loops to use for_each_engine_id() and avoid multiple dereferences of engine->id. Also a few related tweaks to cache structure members locally wherever they're used more than

[Intel-gfx] [PATCH v2 6/6] drm/i915/guc: re-optimise i915_guc_client layout

As we're tweaking the GuC-related code in debugfs, we can drop the now-used 'q_fail' and repack the structure. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_debugfs.c | 1 - drivers/gpu/drm/i915/intel_guc.h| 6 ++ 2 files changed, 2 insertions(+), 5

[Intel-gfx] [PATCH v2 4/6] drm/i915/guc: add engine mask to GuC client & pass to GuC

The Context Descriptor passed by the kernel to the GuC contains a field specifying which engine(s) the context will use. Historically, this was always set to "all of them", but now that we have one client per engine, we can be more precise, and set only the single bit for the engine that the

[Intel-gfx] [PATCH v2 2/6] drm/i915/guc: refactor guc_init_doorbell_hw()

We have essentially the same code in each of two different loops, so we can refactor it into a little helper function. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 54 +- 1 file changed, 30 insertions(+), 24

[Intel-gfx] [PATCH v2 3/6] drm/i915/guc: use a separate GuC client for each engine

When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission queues per engine. In theory, this could lead to the single queue becoming a bottleneck in which an excess

[Intel-gfx] [PATCH v2 1/6] drm/i915/guc: doorbell reset should avoid used doorbells

guc_init_doorbell_hw() borrows the (currently single) GuC client to use in reinitialising ALL the doorbell registers (as the hardware doesn't reset them when the GuC is reset). As a prerequisite for accommodating multiple clients, it should only reset doorbells that are supposed to be disabled,

[Intel-gfx] [PATCH v2 0/6] drm/i915/guc: use one GuC client per GPU engine

When using a single GuC client for multiple engines, the i915 driver has to merge all work items into a single work queue, which the GuC firmware then demultiplexes into separate submission queues per engine. In theory, this could lead to the single queue becoming a bottleneck in which an excess

Re: [Intel-gfx] [PATCH v2] drm/i915: use i915_gem_object_put_unlocked() after releasing mutex

On Thu, Jul 21, 2016 at 06:39:38PM +0100, Dave Gordon wrote: > The exit path in intel_overlay_put_image_ioctl() first unlocks the > struct_mutex, then drops its reference to 'new_bo' by calling > i915_gem_object_put(). As it isn't holding the mutex at this point, > this should be

Re: [Intel-gfx] [PATCH v2] drm/i915: use i915_gem_object_put_unlocked() after releasing mutex

On Thu, Jul 21, 2016 at 06:39:38PM +0100, Dave Gordon wrote: > The exit path in intel_overlay_put_image_ioctl() first unlocks the > struct_mutex, then drops its reference to 'new_bo' by calling > i915_gem_object_put(). As it isn't holding the mutex at this point, > this should be

[Intel-gfx] [PATCH v2] drm/i915: use i915_gem_object_put_unlocked() after releasing mutex

The exit path in intel_overlay_put_image_ioctl() first unlocks the struct_mutex, then drops its reference to 'new_bo' by calling i915_gem_object_put(). As it isn't holding the mutex at this point, this should be i915_gem_object_put_unlocked(). This was previously correct but got splatted in the

Re: [Intel-gfx] [PATCH] drm/i915: use i915_gem_object_put_unlocked() after releasing mutex

On Thu, Jul 21, 2016 at 05:58:03PM +0100, Dave Gordon wrote: > The exit path in intel_overlay_put_image_ioctl() first unlocks the > struct_mutex, then drops its reference to 'new_bo' by calling > i915_gem_object_put(). As it isn't holding the mutex at this point, > this should be

Re: [Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

On 21/07/16 11:38, Tvrtko Ursulin wrote: On 20/07/16 22:07, Rodrigo Vivi wrote: please kill this _ucode variation that is just a alias to guc instead Not sure, it was added with a particular goal. Cc Dave in case he wants to comment. Regards, Tvrtko The comment is already in the

Re: [Intel-gfx] [PATCH 4/6] drm/i915/skl: Always wait for pipes to update after a flush

Two things for this one: 1. I completely messed up the description on this patchset, this was for fixing underruns on pipe disablement. I'm impressed I wrote up that whole description without realizing that at all, lol. 2. This patch may not actually be necessary. On the original git branch I was

[Intel-gfx] [PATCH] drm/i915: use i915_gem_object_put_unlocked() after releasing mutex

The exit path in intel_overlay_put_image_ioctl() first unlocks the struct_mutex, then drops its reference to 'new_bo' by calling i915_gem_object_put(). As it isn't holding the mutex at this point, this should be i915_gem_object_put_unlocked(). This was previously correct but got splatted in the

Re: [Intel-gfx] [PATCH 10/23] drm/i915: Move HAS_RC6 definition to platform definition

On Thu, Jul 21, 2016 at 3:50 AM, Tvrtko Ursulin wrote: > > On 20/07/16 18:40, Carlos Santa wrote: >> >> Moving all GPU features to the platform struct definition allows for >> - standard place when adding new features from new platforms >> -

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Remove duplicate golden render state init from execlists

On Thu, Jul 21, 2016 at 05:27:06PM +0100, Chris Wilson wrote: > On Thu, Jul 21, 2016 at 05:18:17PM +0300, Joonas Lahtinen wrote: > > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > > >  static const struct intel_renderstate_rodata * > > >  render_state_get_rodata(const int gen) > > >  { >

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Remove duplicate golden render state init from execlists

On Thu, Jul 21, 2016 at 05:18:17PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > >  static const struct intel_renderstate_rodata * > >  render_state_get_rodata(const int gen) > >  { > > @@ -51,6 +60,7 @@ static int render_state_init(struct render_state

Re: [Intel-gfx] [PATCH] drm/i915: Disable GT powersaving upon suspend

On Thu, Jul 21, 2016 at 04:30:08PM +0100, Chris Wilson wrote: > In the refactoring to stop the rpm refleak, the call to > intel_disable_gt_powersave() was mistakenly dropped from > i915_drm_suspend(). It is still required in order to set the rps.enabled > flag back to false so that it will

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Disable GT powersaving upon suspend

== Series Details == Series: drm/i915: Disable GT powersaving upon suspend URL : https://patchwork.freedesktop.org/series/10137/ State : warning == Summary == Series 10137v1 drm/i915: Disable GT powersaving upon suspend http://patchwork.freedesktop.org/api/1.0/series/10137/revisions/1/mbox

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Rename struct intel_ringbuffer to struct intel_ring

On Thu, Jul 21, 2016 at 02:59:23PM +0300, Joonas Lahtinen wrote: > > @@ -4567,8 +4567,8 @@ int i915_gem_init(struct drm_device *dev) > >   > >   if (!i915.enable_execlists) { > >   dev_priv->gt.execbuf_submit = i915_gem_ringbuffer_submission; > > - dev_priv->gt.cleanup_engine

[Intel-gfx] [PATCH] drm/i915: Disable GT powersaving upon suspend

In the refactoring to stop the rpm refleak, the call to intel_disable_gt_powersave() was mistakenly dropped from i915_drm_suspend(). It is still required in order to set the rps.enabled flag back to false so that it will re-enabled upon resume. Fixes: b7137e0cf1e5 ("drm/i915: Defer enabling rc6

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On Thu, Jul 21, 2016 at 02:46:01PM +0100, Tvrtko Ursulin wrote: > > On 21/07/16 14:31, Chris Wilson wrote: > >Hmm. This was in intel_ringbuffer.c, at least I assumed so as this only > >applies to legacy submission, for gen6-7. > > It uses the static intel_engines array since the

Re: [Intel-gfx] [PATCH 16/18] drm/i915: Remove duplicate golden render state init from execlists

On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: >  static const struct intel_renderstate_rodata * >  render_state_get_rodata(const int gen) >  { > @@ -51,6 +60,7 @@ static int render_state_init(struct render_state *so, >   int ret; >   >   so->gen = INTEL_GEN(dev_priv); > +

Re: [Intel-gfx] [PATCH 10/18] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

On Thu, Jul 21, 2016 at 04:39:58PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > >   if (so.aux_batch_size > 8) { > > - ret = req->engine->dispatch_execbuffer(req, > > -  (so.ggtt_offset + > > -

Re: [Intel-gfx] [PATCH 15/18] drm/i915/ringbuffer: Specialise SNB+ request emission for semaphores

On Thu, Jul 21, 2016 at 04:55:00PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > > As gen6_emit_request() only differs from i9xx_emit_request() when > > semaphores are enabled, only use the specialised vfunc in that scenario. > > > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH 11/18] drm/i915: Convert engine->write_tail to operate on a request

On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > If we rewrite the I915_WRITE_TAIL specialisation for the legacy > ringbuffer as submitting the request onto the ringbuffer, we can unify > the vfunc with both execlists and GuC in the next patch. > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 15/18] drm/i915/ringbuffer: Specialise SNB+ request emission for semaphores

On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > As gen6_emit_request() only differs from i9xx_emit_request() when > semaphores are enabled, only use the specialised vfunc in that scenario. > > Signed-off-by: Chris Wilson > --- >  

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915:gen9: restrict WaC6DisallowByGfxPause (rev2)

On 21/07/16 13:31, Gore, Tim wrote: -Original Message- From: Patchwork [mailto:patchw...@emeril.freedesktop.org] Sent: Wednesday, July 20, 2016 11:38 AM To: Gore, Tim Cc: intel-gfx@lists.freedesktop.org Subject: ✗ Ro.CI.BAT: failure for drm/i915:gen9: restrict WaC6DisallowByGfxPause

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On 21/07/16 14:31, Chris Wilson wrote: On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote: On 21/07/16 13:59, Chris Wilson wrote: On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Static table wastes space for

Re: [Intel-gfx] [PATCH 10/18] drm/i915: Unify legacy/execlists emission of MI_BATCHBUFFER_START

On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > Both the ->dispatch_execbuffer and ->emit_bb_start callbacks do exactly > the same thing, add MI_BATCHBUFFER_START to the request's ringbuffer - > we need only one vfunc. > Some ranting below, Reviewed-by: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 03/23] drm/i915: Move HAS_RUNTIME_PM definition to platform

On ke, 2016-07-20 at 13:25 -0700, Rodrigo Vivi wrote: > On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa wrote: > > Moving all GPU features to the platform struct definition allows for > > - standard place when adding new features from new platforms > > - possible to see supported

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Accept symbolic link in firmware name

If you look back we did have both no-black listing (only required a proper major version) and black listing before we ended up deciding that we'll use white listing. The reasons for this were too many obscure firmware issues, undocumented interoperability details between firmware and the driver

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On Thu, Jul 21, 2016 at 02:16:22PM +0100, Tvrtko Ursulin wrote: > > On 21/07/16 13:59, Chris Wilson wrote: > >On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Static table wastes space for invalid combinations and >

Re: [Intel-gfx] [PATCH] drm/i915: Replace gen6 semaphore signal table with code

On 21/07/16 12:56, Dave Gordon wrote: On 21/07/16 10:31, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Static table wastes space for invalid combinations and engines which are not supported by Gen6 (legacy semaphores). Replace it with a function devised by Dave

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On 21/07/16 14:16, Tvrtko Ursulin wrote: [snip] +{ +if (x == y) +return -1; + +x = intel_engines[x].guc_id; +y = intel_engines[y].guc_id; hw_id. Some guys named Chris and Dave removed it. ;D I need to take this back, I was confusing two tables and some past

Re: [Intel-gfx] [PATCH 09/18] drm/i915: Simplify request_alloc by returning the allocated request

On Thu, Jul 21, 2016 at 04:07:59PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > > - trace_i915_gem_ring_sync_to(*to_req, from, from_req); > > - ret = to->semaphore.sync_to(*to_req, from, seqno); > > +

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On 21/07/16 13:59, Chris Wilson wrote: On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Static table wastes space for invalid combinations and engines which are not supported by Gen6 (legacy semaphores). Replace it with a

Re: [Intel-gfx] [PATCH 09/18] drm/i915: Simplify request_alloc by returning the allocated request

On ke, 2016-07-20 at 14:12 +0100, Chris Wilson wrote: > If is simpler and leads to more readable code through the callstack if > the allocation returns the allocated struct through the return value. > > The importance of this is that it no longer looks like we accidentally > allocate requests as

Re: [Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

On Thu, Jul 21, 2016 at 01:00:47PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Static table wastes space for invalid combinations and > engines which are not supported by Gen6 (legacy semaphores). > > Replace it with a function devised by Dave Gordon. > >

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Replace gen6 semaphore signal table with code (rev3)

== Series Details == Series: drm/i915: Replace gen6 semaphore signal table with code (rev3) URL : https://patchwork.freedesktop.org/series/10129/ State : failure == Summary == Series 10129v3 drm/i915: Replace gen6 semaphore signal table with code

Re: [Intel-gfx] [PATCH i-g-t v2 09/15] igt_kms: Clear all _changed members centrally

Op 21-07-16 om 14:13 schreef Ander Conselvan De Oliveira: > On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: >> This will make it easier to support TEST_ONLY commits. >> >> Signed-off-by: Maarten Lankhorst >> --- >> lib/igt_kms.c | 84

Re: [Intel-gfx] [PATCH i-g-t v2 08/15] igt_kms: Remove pan members from igt_plane, v2.

Op 21-07-16 om 13:42 schreef Ander Conselvan De Oliveira: > On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: >> They're duplicates with src_x/y, so just use those. >> >> Changes since v1: >> - Fix order of parameters in calls to igt_fb_set_position. >> >> Signed-off-by: Maarten

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915:gen9: restrict WaC6DisallowByGfxPause (rev2)

Tim Gore  Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > -Original Message- > From: Patchwork [mailto:patchw...@emeril.freedesktop.org] > Sent: Wednesday, July 20, 2016 11:38 AM > To: Gore, Tim > Cc: intel-gfx@lists.freedesktop.org > Subject: ✗

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Replace gen6 semaphore signal table with code (rev2)

== Series Details == Series: drm/i915: Replace gen6 semaphore signal table with code (rev2) URL : https://patchwork.freedesktop.org/series/10129/ State : failure == Summary == Series 10129v2 drm/i915: Replace gen6 semaphore signal table with code

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Rename residual ringbuf parameters

On Thu, Jul 21, 2016 at 03:01:07PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > > Now that we have a clear ring/engine split and a struct intel_ring, we > > no longer need the stopgap ringbuf names. > > > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH i-g-t v2 09/15] igt_kms: Clear all _changed members centrally

On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: > This will make it easier to support TEST_ONLY commits. > > Signed-off-by: Maarten Lankhorst > --- >  lib/igt_kms.c | 84 ++-- > --- >  1 file

Re: [Intel-gfx] [PATCH 01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

On Thu, Jul 21, 2016 at 02:26:19PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > > Both perform the same actions with more or less indirection, so just > > unify the code. > > > > Don't really like removing the engine = req->engine aliases, but seems >

Re: [Intel-gfx] [PATCH 07/18] drm/i915: Rename intel_pin_and_map_ring()

On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > For more consistent oop-naming, we would use intel_ring_verb, so pick > intel_ring_pin() and intel_ring_unpin(). > The done renames clearly here, then; Reviewed-by: Joonas Lahtinen > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH 06/18] drm/i915: Rename residual ringbuf parameters

On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > Now that we have a clear ring/engine split and a struct intel_ring, we > no longer need the stopgap ringbuf names. > > Signed-off-by: Chris Wilson Why is this a separate patch? List the renames here too, with

[Intel-gfx] [PATCH v3] drm/i915: Replace gen6 semaphore signal table with code

From: Tvrtko Ursulin Static table wastes space for invalid combinations and engines which are not supported by Gen6 (legacy semaphores). Replace it with a function devised by Dave Gordon. I have verified that it generates the same mappings between mbox selectors and

[Intel-gfx] [PATCH v2] drm/i915: Replace gen6 semaphore signal table with code

From: Tvrtko Ursulin Static table wastes space for invalid combinations and engines which are not supported by Gen6 (legacy semaphores). Replace it with a function devised by Dave Gordon. I have verified that it generates the same mappings between mbox selectors and

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Rename struct intel_ringbuffer to struct intel_ring

On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > The state stored in this struct is not only the information about the > buffer object, but the ring used to communicate with the hardware. Using > buffer here is overly specific and, for me at least, conflates with the > notion of buffer

Re: [Intel-gfx] [PATCH] drm/i915: Replace gen6 semaphore signal table with code

On 21/07/16 10:31, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Static table wastes space for invalid combinations and engines which are not supported by Gen6 (legacy semaphores). Replace it with a function devised by Dave Gordon. I have verified that it generates the

Re: [Intel-gfx] [PATCH 04/18] drm/i915: Rename intel_context[engine].ringbuf

On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > Perform s/ringbuf/ring/ on the context struct for consistency with the > ring/engine split. > > Signed-off-by: Chris Wilson > --- >  drivers/gpu/drm/i915/i915_debugfs.c|  8 >  

Re: [Intel-gfx] [PATCH i-g-t v2 08/15] igt_kms: Remove pan members from igt_plane, v2.

On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: > They're duplicates with src_x/y, so just use those. > > Changes since v1: > - Fix order of parameters in calls to igt_fb_set_position. > > Signed-off-by: Maarten Lankhorst > --- >  lib/igt_kms.c 

Re: [Intel-gfx] [PATCH 03/18] drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs

On Thu, Jul 21, 2016 at 02:32:52PM +0300, Joonas Lahtinen wrote: > On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > > Having ringbuf->ring point to an engine is confusing, so rename it once > > again to ring->engine. > > > > Commit message and content do not seem to match. It does, but

Re: [Intel-gfx] [PATCH 03/18] drm/i915: Rename backpointer from intel_ringbuffer to intel_engine_cs

On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > Having ringbuf->ring point to an engine is confusing, so rename it once > again to ring->engine. > Commit message and content do not seem to match. > Signed-off-by: Chris Wilson > --- >  

Re: [Intel-gfx] [PATCH 01/18] drm/i915: Unify intel_logical_ring_emit and intel_ring_emit

On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > Both perform the same actions with more or less indirection, so just > unify the code. > Don't really like removing the engine = req->engine aliases, but seems like req->engine is used plenty already. And assuming this was a mechanical

Re: [Intel-gfx] [PATCH 02/18] drm/i915: Rename request->ringbuf to request->ring

On ke, 2016-07-20 at 14:11 +0100, Chris Wilson wrote: > Now that we have disambuigated ring and engine, we can use the clearer > and more consistent name for the intel_ringbuffer pointer in the > request. > The cocci data would be useful, or sed expression. And would make me more confident this

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_rotation_crc: Add bad-rotation subtest

On Thu, Jul 21, 2016 at 01:32:48PM +0300, Joonas Lahtinen wrote: > Was not this implemented once and then dropped for some reason? Dunno. > > On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Add

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker

On Thu, Jul 21, 2016 at 11:28:02AM +0100, Tvrtko Ursulin wrote: > > On 21/07/16 11:10, Chris Wilson wrote: > >On Thu, Jul 21, 2016 at 10:58:05AM +0100, Tvrtko Ursulin wrote: > >> > >>On 21/07/16 07:57, Chris Wilson wrote: > >>>During the idle-worker we disable the hangcheck and so kick any

Re: [Intel-gfx] [PATCH 10/23] drm/i915: Move HAS_RC6 definition to platform definition

On 20/07/16 18:40, Carlos Santa wrote: Moving all GPU features to the platform struct definition allows for - standard place when adding new features from new platforms - possible to see supported features when dumping struct definitions Signed-off-by: Carlos Santa

Re: [Intel-gfx] [PATCH 07/23] drm/i915: Move HAS_GUC_UCODE definition to platform definition

On 20/07/16 22:07, Rodrigo Vivi wrote: please kill this _ucode variation that is just a alias to guc instead Not sure, it was added with a particular goal. Cc Dave in case he wants to comment. Regards, Tvrtko On Wed, Jul 20, 2016 at 10:40 AM, Carlos Santa

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_rotation_crc: Add bad-rotation subtest

Was not this implemented once and then dropped for some reason? On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Add "bad-rotation" subtest to make sure the kernel rejects some > invalid rotation values (0 and

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Add horizontal mirroring support for CHV pipe B planes

On ke, 2016-07-20 at 16:18 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The primary and sprite planes on CHV pipe B support horizontal > mirroring. Expose it to the world. > > Sadly the hardware ignores the mirror bit when the rotate bit

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker

On 21/07/16 11:10, Chris Wilson wrote: On Thu, Jul 21, 2016 at 10:58:05AM +0100, Tvrtko Ursulin wrote: On 21/07/16 07:57, Chris Wilson wrote: During the idle-worker we disable the hangcheck and so kick any waiters that should have been completed (since the GPU is now idle). Unlike the

Re: [Intel-gfx] [PATCH] drm/i915: Replace gen6 semaphore signal table with code

On Thu, Jul 21, 2016 at 10:31:35AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Static table wastes space for invalid combinations and > engines which are not supported by Gen6 (legacy semaphores). > > Replace it with a function devised by Dave Gordon. > >

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker

On Thu, Jul 21, 2016 at 10:58:05AM +0100, Tvrtko Ursulin wrote: > > On 21/07/16 07:57, Chris Wilson wrote: > >During the idle-worker we disable the hangcheck and so kick any waiters > >that should have been completed (since the GPU is now idle). Unlike the > >hangcheck, we do not take any care to

Re: [Intel-gfx] [PATCH i-g-t v2 07/15] igt_kms: Handle atomic pipe properties better.

On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: > Move properties to the pipe, they don't belong in the output > and make atomic commit use the pipes for crtc properties. > > Signed-off-by: Maarten Lankhorst Reviewed-by: Ander Conselvan de Oliveira

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Replace gen6 semaphore signal table with code

== Series Details == Series: drm/i915: Replace gen6 semaphore signal table with code URL : https://patchwork.freedesktop.org/series/10129/ State : failure == Summary == Series 10129v1 drm/i915: Replace gen6 semaphore signal table with code

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker

On 21/07/16 07:57, Chris Wilson wrote: During the idle-worker we disable the hangcheck and so kick any waiters that should have been completed (since the GPU is now idle). Unlike the hangcheck, we do not take any care to avoid the race between the irq handler and ourselves, and so it is

Re: [Intel-gfx] [PATCH 17/17] drm/i915: Use rt priority kthread to do GuC log buffer sampling

On 21/07/16 07:18, Goel, Akash wrote: On 7/21/2016 11:13 AM, Chris Wilson wrote: On Thu, Jul 21, 2016 at 09:11:42AM +0530, Goel, Akash wrote: On 7/21/2016 1:04 AM, Chris Wilson wrote: In the end, just the silly locking and placement of complete_all() is dangerous. reinit_completion() lacks

Re: [Intel-gfx] [PATCH 3/3] drm/i915: rename & update eb_select_ring()

On 20/07/16 18:31, Chris Wilson wrote: On Wed, Jul 20, 2016 at 06:16:07PM +0100, Dave Gordon wrote: 'ring' is an old deprecated term for a GPU engine, so we're trying to phase out all such terminology. eb_select_ring() not only has 'ring' (meaning engine) in its name, but it has an ugly

[Intel-gfx] [PATCH] drm/i915: Replace gen6 semaphore signal table with code

From: Tvrtko Ursulin Static table wastes space for invalid combinations and engines which are not supported by Gen6 (legacy semaphores). Replace it with a function devised by Dave Gordon. I have verified that it generates the same mappings between mbox selectors and

Re: [Intel-gfx] [PATCH i-g-t v2 06/15] igt_kms: Change PIPE_ANY behavior to mean unassigned

On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: > None of the tests requires that a output bound to PIPE_ANY is assigned, > so don't do it. Fix the display commit to iterate over crtc's instead > of outputs to properly disable pipes without outputs. > > This also means that

Re: [Intel-gfx] [PATCH i-g-t v2 05/15] tests/kms: Clean up more users of unassigned pipes.

Op 20-07-16 om 14:56 schreef Ander Conselvan De Oliveira: > On Wed, 2016-07-06 at 11:55 +0200, Maarten Lankhorst wrote: >> Use for_each_pipe_with_valid_output instead. >> >> Signed-off-by: Maarten Lankhorst >> --- >> tests/kms_crtc_background_color.c | 3 +--

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [1/3] drm/i915: rename macro parameter(ring) to (engine)

On Thu, Jul 21, 2016 at 05:49:32AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/3] drm/i915: rename macro parameter(ring) to > (engine) > URL : https://patchwork.freedesktop.org/series/10101/ > State : success Pick these up, just a few more stray rings

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Introduce fault-injection

== Series Details == Series: drm/i915: Introduce fault-injection URL : https://patchwork.freedesktop.org/series/10126/ State : failure == Summary == LD drivers/scsi/scsi_mod.o CC [M] drivers/net/ethernet/intel/igb/e1000_mbx.o CC [M] drivers/net/ethernet/intel/igbvf/netdev.o CC

[Intel-gfx] [RFC] drm/i915: Introduce fault-injection

So many corner cases are virtually impossible to hit in contrived test cases, but are immediately apparent when run on the diverse conditions in the wild. To trigger fallbacks of fallbacks we need to inject errors whilst testing, to guide the tests along the long forgotten paths. This patch

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [v2,1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker

== Series Details == Series: series starting with [v2,1/3] drm/i915: Drop racy markup of missed-irqs from idle-worker URL : https://patchwork.freedesktop.org/series/10124/ State : success == Summary == Series 10124v1 Series without cover letter

  1   2   >