[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dsi: enable DSC

2019-11-16 Thread Patchwork
== Series Details == Series: drm/i915/dsi: enable DSC URL : https://patchwork.freedesktop.org/series/69540/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7354_full -> Patchwork_15287_full Summary --- **FAILURE** S

[Intel-gfx] ✗ Fi.CI.IGT: failure for Refactor Gen11+ SAGV support (rev11)

2019-11-16 Thread Patchwork
== Series Details == Series: Refactor Gen11+ SAGV support (rev11) URL : https://patchwork.freedesktop.org/series/68028/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7353_full -> Patchwork_15285_full Summary --- **FA

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Mention which device failed

2019-11-16 Thread Patchwork
== Series Details == Series: drm/i915/gt: Mention which device failed URL : https://patchwork.freedesktop.org/series/69528/ State : success == Summary == CI Bug Log - changes from CI_DRM_7352_full -> Patchwork_15282_full Summary ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: fix accidental static variable use

2019-11-16 Thread Patchwork
== Series Details == Series: drm/i915: fix accidental static variable use URL : https://patchwork.freedesktop.org/series/69525/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7352_full -> Patchwork_15280_full Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Use gt locals for accessing rc6

2019-11-16 Thread Patchwork
== Series Details == Series: drm/i915/gt: Use gt locals for accessing rc6 URL : https://patchwork.freedesktop.org/series/69523/ State : success == Summary == CI Bug Log - changes from CI_DRM_7352_full -> Patchwork_15279_full Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests (rev2)

2019-11-16 Thread Patchwork
== Series Details == Series: series starting with [01/11] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests (rev2) URL : https://patchwork.freedesktop.org/series/69570/ State : warning == Summary == $ dim checkpatch origin/drm-tip ba37fa6d8ab8 drm/i915/gt: Close race be

[Intel-gfx] [PATCH] drm/i915: Mark up the calling context for intel_wakeref_put()

2019-11-16 Thread Chris Wilson
Previously, we assumed we could use mutex_trylock() within an atomic context, falling back to a working if contended. However, such trickery is illegal inside interrupt context, and so we need to always use a worker under such circumstances. As we normally are in process context, we can typically u

Re: [Intel-gfx] [PATCH 01/11] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests

2019-11-16 Thread Chris Wilson
Quoting Chris Wilson (2019-11-16 17:54:38) > Quoting Chris Wilson (2019-11-16 17:51:29) > > The general concept was that intel_timeline.active_count was locked by > > the intel_timeline.mutex. The exception was for power management, where > > the engine->kernel_context->timeline could be manipulate

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests

2019-11-16 Thread Patchwork
== Series Details == Series: series starting with [01/11] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests URL : https://patchwork.freedesktop.org/series/69570/ State : warning == Summary == $ dim checkpatch origin/drm-tip 10b85def7734 drm/i915/gt: Close race between e

Re: [Intel-gfx] [PATCH 01/11] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests

2019-11-16 Thread Chris Wilson
Quoting Chris Wilson (2019-11-16 17:51:29) > The general concept was that intel_timeline.active_count was locked by > the intel_timeline.mutex. The exception was for power management, where > the engine->kernel_context->timeline could be manipulated under the > global wakeref.mutex. > > This was q

[Intel-gfx] [PATCH 07/11] drm/i915/gt: Flush the requests after wedging on suspend

2019-11-16 Thread Chris Wilson
Retire all requests if we resort to wedged the driver on suspend. They will now be idle, so we might as we free them before shutting down. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm

[Intel-gfx] [PATCH 09/11] drm/i915/selftests: Be explicit in ERR_PTR handling

2019-11-16 Thread Chris Wilson
When setting up a full GGTT, we expect the next insert to fail with -ENOSPC. Simplify the use of ERR_PTR to not confuse either the reader or smatch. Reported-by: Dan Carpenter References: f40a7b7558ef ("drm/i915: Initial selftests for exercising eviction") Signed-off-by: Chris Wilson --- driver

[Intel-gfx] [PATCH 05/11] drm/i915/gt: Move new timelines to the end of active_list

2019-11-16 Thread Chris Wilson
When adding a new active timeline, place it at the end of the list. This allows for intel_gt_retire_requests() to pick up the newcomer more quickly and hopefully complete the retirement sooner. References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in intel_gt_retire_requests()") Signed-of

[Intel-gfx] [PATCH 04/11] drm/i915/gt: Declare timeline.lock to be irq-free

2019-11-16 Thread Chris Wilson
Now that we never allow the intel_wakeref callbacks to be invoked from interrupt context, we do not need the irqsafe spinlock for the timeline. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gt_requests.c | 9 - drivers/gpu/drm/i915/gt/intel_reset.c | 9 -

[Intel-gfx] [PATCH 06/11] drm/i915/gt: Schedule next retirement worker first

2019-11-16 Thread Chris Wilson
As we may park the gt during request retirement, we may then cancel the retirement worker only to then program the delayed worker once more. If we schedule the next delayed retirement worker first, if we then park the gt, the work remain cancelled [until we unpark]. Signed-off-by: Chris Wilson -

[Intel-gfx] [PATCH 02/11] drm/i915: Mark up the calling context for intel_wakeref_put()

2019-11-16 Thread Chris Wilson
Previously, we assumed we could use mutex_trylock() within an atomic context, falling back to a working if contended. However, such trickery is illegal inside interrupt context, and so we need to always use a worker under such circumstances. As we normally are in process context, we can typically u

[Intel-gfx] [PATCH 10/11] drm/i915/selftests: Exercise rc6 handling

2019-11-16 Thread Chris Wilson
Reading from CTX_INFO upsets rc6, requiring us to detect and prevent possible rc6 context corruption. Poke at the bear! Signed-off-by: Chris Wilson Cc: Imre Deak Cc: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 + drivers/gpu/drm/i915/gt/selftest_gt_pm.c | 13 ++

[Intel-gfx] [PATCH 03/11] drm/i915: Wait until the intel_wakeref idle callback is complete

2019-11-16 Thread Chris Wilson
When waiting for idle, serialise with any ongoing callback so that it will have completed before completing the wait. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_wakeref.c | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 01/11] drm/i915/gt: Close race between engine_park and intel_gt_retire_requests

2019-11-16 Thread Chris Wilson
The general concept was that intel_timeline.active_count was locked by the intel_timeline.mutex. The exception was for power management, where the engine->kernel_context->timeline could be manipulated under the global wakeref.mutex. This was quite solid, as we always manipulated the timeline only

[Intel-gfx] [PATCH 08/11] drm/i915/selftests: Flush the active callbacks

2019-11-16 Thread Chris Wilson
Before checking the current i915_active state for the asynchronous work we submitted, flush any ongoing callback. This ensures that our sampling is robust and does not sporadically fail due to bad timing as the work is running on another cpu. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 11/11] drm/i915/gt: Track engine round-trip times

2019-11-16 Thread Chris Wilson
Knowing the round trip time of an engine is useful for tracking the health of the system as well as providing a metric for the baseline responsiveness of the engine. We can use the latter metric for automatically tuning our waits in selftests and when idling so we don't confuse a slower system with

[Intel-gfx] ✓ Fi.CI.BAT: success for Improve error handling on DSB (rev4)

2019-11-16 Thread Patchwork
== Series Details == Series: Improve error handling on DSB (rev4) URL : https://patchwork.freedesktop.org/series/69319/ State : success == Summary == CI Bug Log - changes from CI_DRM_7358 -> Patchwork_15304 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: move power domains dumped variable to drm_i915_private

2019-11-16 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915: move power domains dumped variable to drm_i915_private URL : https://patchwork.freedesktop.org/series/69519/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7350_full -> Patchwork_15277_full =

Re: [Intel-gfx] [PATCH xf86-video-intel v2] SNA: fix PRIME output support since xserver 1.20

2019-11-16 Thread Peter Wu
On Fri, Nov 15, 2019 at 08:14:05PM +0200, Ville Syrjälä wrote: > On Fri, Nov 15, 2019 at 04:32:47PM +0100, Peter Wu wrote: > > Since "Make PixmapDirtyUpdateRec::src a DrawablePtr" in xserver, the > > "src" pointer might point to the root window (created by the server) > > instead of a pixmap (as cr

Re: [Intel-gfx] drm core/helpers and MIT license

2019-11-16 Thread Emmanuel Vadot
Hi Daniel, On Tue, 12 Nov 2019 16:03:33 +0100 Daniel Vetter wrote: > Hi all, > > Dave and me chatted about this last week on irc. Essentially we have: > > $ git grep SPDX.*GPL -- ':(glob)drivers/gpu/drm/*c' > drivers/gpu/drm/drm_client.c:// SPDX-License-Identifier: GPL-2.0 > drivers/gpu/drm/

[Intel-gfx] ✗ Fi.CI.IGT: failure for Improve error handling on DSB (rev2)

2019-11-16 Thread Patchwork
== Series Details == Series: Improve error handling on DSB (rev2) URL : https://patchwork.freedesktop.org/series/69319/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7348_full -> Patchwork_15272_full Summary --- **FA

Re: [Intel-gfx] [PATCH] drm/i915/guc: Skip suspend/resume GuC action on platforms w/o GuC submission

2019-11-16 Thread Chris Wilson
Quoting don.hi...@intel.com (2019-11-15 23:15:38) > From: Don Hiatt > > On some platforms (e.g. KBL) that do not support GuC submission, but > the user enabled the GuC communication (e.g for HuC authentication) > calling the GuC EXIT_S_STATE action results in lose of ability to > enter RC6. We ca

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/guc: Add GuC method to determine if submission is active.

2019-11-16 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/guc: Add GuC method to determine if submission is active. URL : https://patchwork.freedesktop.org/series/69499/ State : success == Summary == CI Bug Log - changes from CI_DRM_7348_full -> Patchwork_15271_full ===