== 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
== 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
== 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
---
== 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
---
== 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
---
== 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
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
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
== 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
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
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
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
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
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 -
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
-
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
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 ++
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/
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
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/
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
== 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**
== 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
=
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
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/
== 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
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
== 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
===
28 matches
Mail list logo