== Series Details ==
Series: series starting with [01/19] drm/i915/selftests: Force bonded
submission to overlap
URL : https://patchwork.freedesktop.org/series/69647/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7367_full -> Patchwork_15322_full
Only serialise with the chipset using an mmio if the chipset is
currently active. We expect that any writes into the chipset range will
simply be forgotten until it wakes up.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Since igt now defaults to not enabling ftrace-on-oops, we need to
manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
GEM_BUG_ON panicking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
Chris Wilson writes:
> Only serialise with the chipset using an mmio if the chipset is
> currently active. We expect that any writes into the chipset range will
> simply be forgotten until it wakes up.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
>
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
---
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 | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/perf: Allow non-privileged
access when OA buffer is not sampled
URL : https://patchwork.freedesktop.org/series/69645/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7367_full -> Patchwork_15321_full
== Series Details ==
Series: drm/i915/dsi: Do not read the transcoder register.
URL : https://patchwork.freedesktop.org/series/69654/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7368 -> Patchwork_15324
Summary
---
We only need the one loop to find the dirty vma flush them, and their
chipset.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git
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
Take the obj->vma.lock to prevent modifications to the list as we
iterate, to avoid the dreaded the NULL pointer.
<1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
0150
<1>[ 347.820856] #PF: supervisor read access in kernel mode
<1>[ 347.820874] #PF:
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
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()")
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
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 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
---
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 -
Platforms without display do not map the MCHBAR MMIO into the GFX
device BAR. Skip this sequence when display is not available.
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
== Series Details ==
Series: drm/i915: Cleanups around .crtc_enable/disable() (rev4)
URL : https://patchwork.freedesktop.org/series/69352/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7371_full -> Patchwork_15329_full
On 11/19/19 4:21 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-11-20 00:04:25)
When GuC is in use we need to make sure it is re-loaded before the call
to gt_resume, otherwise communication from the engines to the GuC will
not be processed, which blocks the engines from ctx
== Series Details ==
Series: drm/i915/selftests: re-init the GT in live_gt_pm
URL : https://patchwork.freedesktop.org/series/69710/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380 -> Patchwork_15337
Summary
---
On Fri, Nov 15, 2019 at 04:54:01PM +0200, Stanislav Lisovskiy wrote:
> According to BSpec 53998, we should try to
> restrict qgv points, which can't provide
> enough bandwidth for desired display configuration.
>
> Currently we are just comparing against all of
> those and take minimum(worst
== Series Details ==
Series: Skip MCHBAR queries when display is not available
URL : https://patchwork.freedesktop.org/series/69712/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380 -> Patchwork_15338
Summary
---
== Series Details ==
Series: drm/i915: make pool objects read-only
URL : https://patchwork.freedesktop.org/series/69684/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371_full -> Patchwork_15330_full
Summary
---
On 2019/11/19 下午10:14, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
On Mon, Nov 18, 2019 at 03:27:13PM
@@ -220,7 +200,7 @@ static void guc_wq_item_append(struct intel_guc_client
*client,
GEM_BUG_ON(wq_off & (wqi_size - 1));
/* WQ starts from the page after process_desc */
Just realized that I stupidly forgot to actually commit the fix...
I'll send the fixed (for real) version
Quoting Daniele Ceraolo Spurio (2019-11-20 00:04:25)
> When GuC is in use we need to make sure it is re-loaded before the call
> to gt_resume, otherwise communication from the engines to the GuC will
> not be processed, which blocks the engines from ctx switching and from
> being reset.
>
>
On Tue, Nov 19, 2019 at 1:08 PM Daniel Vetter wrote:
>
> For locking semantics it really doesn't matter when we grab the
> ticket. But for lockdep validation it does: the acquire ctx is a fake
> lockdep. Since other drivers might want to do a full multi-lock dance
> in their fault-handler, not
When GuC is in use we need to make sure it is re-loaded before the call
to gt_resume, otherwise communication from the engines to the GuC will
not be processed, which blocks the engines from ctx switching and from
being reset.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112205
Cc: Andi
When display is not available, finding the memory bandwidth available
for display is not useful. Skip this sequence here.
References: HSDES 1209978255
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/display/intel_bw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
== Series Details ==
Series: drm/i915: Do not initialize display BW when display not available
URL : https://patchwork.freedesktop.org/series/69714/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7380 -> Patchwork_15339
Reference:
https://bugs.freedesktop.org/show_bug.cgi?id=112126
The issue we hit is the GPU keeps very high load after running
the subtest min-max-config-loaded.
Some background of the issue:
Currently the rps is not fully enabled yet on TGL, and running
the subtest min-max-config-loaded will hit
On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Yank out the code for the plane->fb/old_fb/crtc handling from
> the page flip path into page_flip_internal(), and provide a
> simpler variant for atomic drivers.
>
> We'll also move the fb vs. src viewport
Quoting Mika Kuoppala (2019-11-19 10:48:22)
> Chris Wilson writes:
>
> > We only need the one loop to find the dirty vma flush them, and their
> > chipset.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
> >
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fdc21d81bb9e drm/i915/dsi: Configure transcoder operation for command mode.
-:60: CHECK:BRACES: braces {}
== Series Details ==
Series: series starting with [1/4] drm/i915: Allow i915 to manage the vma
offset nodes instead of drm core
URL : https://patchwork.freedesktop.org/series/69674/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15327
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin() needed to be atomic and
ordered in a nice
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap
Chris Wilson writes:
> Only serialise with the chipset using an mmio if the chipset is
> currently active. We expect that any writes into the chipset range will
> simply be forgotten until it wakes up.
>
> Signed-off-by: Chris Wilson
From other threads,
Reviewed-by: Mika Kuoppala
> ---
>
Chris Wilson writes:
> Take the obj->vma.lock to prevent modifications to the list as we
> iterate, to avoid the dreaded the NULL pointer.
>
> <1>[ 347.820823] BUG: kernel NULL pointer dereference, address:
> 0150
> <1>[ 347.820856] #PF: supervisor read access in kernel mode
>
On 08/11/2019 11:04, Arkadiusz Hiler wrote:
On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote:
Quoting Arkadiusz Hiler (2019-11-07 17:38:20)
We don't want you to translate C into English, we want you to provide a bit of
that extra information that you would have put in the comments
On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
>
> On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
> > On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin wrote:
> > > On Mon, Nov 18, 2019 at 01:41:00PM +, Jason Gunthorpe wrote:
> > > > On Mon, Nov 18, 2019 at 06:59:21PM
On Tue, Nov 19, 2019 at 02:37:17PM +0200, Lionel Landwerlin wrote:
> On 08/11/2019 11:04, Arkadiusz Hiler wrote:
> > On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote:
> > > Quoting Arkadiusz Hiler (2019-11-07 17:38:20)
> > > > We don't want you to translate C into English, we want you
== Series Details ==
Series: series starting with [1/4] drm/i915: Allow i915 to manage the vma
offset nodes instead of drm core
URL : https://patchwork.freedesktop.org/series/69674/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
badcc07981f3 drm/i915: Allow i915 to manage the
Adding TE flags and periodic command mode flags
as part of private flags to indicate what TE interrupts
we would be getting instead of vblanks in case of mipi dsi
command mode.
v2: Add TE flag description (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Vandita Kulkarni
---
In case of dual link, we get the TE on slave.
So clear the TE on slave DSI IIR.
v2: Pass only relevant masked bits to the handler (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 64 +
1 file changed, 64 insertions(+)
diff --git
Configure the transcoder to operate in TE GATE command mode
and take TE events from GPIO.
Also disable the periodic command mode, that GOP would have
programmed.
v2: Disable util pin (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 52
We need to configure TE interrupt in two places.
Port interrupt and DSI interrupt mask registers.
v2: Hide the private flags check inside configure_te (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/i915_irq.c | 55 +++--
1 file changed, 53
Addressed comments on RFC-v2 from Jani, thanks.
Vandita Kulkarni (8):
drm/i915/dsi: Configure transcoder operation for command mode.
drm/i915/dsi: Add vblank calculation for command mode
drm/i915/dsi: Add cmd mode flags in display mode private flags
drm/i915/dsi: Add check for periodic
In TE Gate mode, on every flip we need to set the
frame update request bit. After this bit is set
transcoder hardware will automatically send the
frame data to the panel when it receives the TE event.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 22
If the GOP has programmed periodic command mode,
we need to disable that which would need a
deconfigure and configure sequence.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 22 ++
1 file changed, 22 insertions(+)
diff --git
Transcoder timing calculation differ for command mode.
v2: Use is_vid_mode, and use same I915_WRITE (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 39 +-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git
On dsi cmd mode we do not receive vblanks instead
we would get TE and these flags indicate TE is expected on
which port.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 15 +++
1 file changed, 15 insertions(+)
diff --git
On Mon, 2019-11-18 at 20:25 +, Lisovskiy, Stanislav wrote:
P.S: (In addition to my last yesterday letter):
>
> That is actually a violation of BSpec, we are not using two slices
> for same
> pipe while we could. We had already enough of bw issues, why should
> we make our life even harder?
Bonded request submission is designed to allow requests to execute in
parallel as laid out by the user. If the master request is already
finished before its bonded pair is submitted, the pair were not destined
to run in parallel and we lose the information about the master engine
to dictate
On Fri, Nov 15, 2019 at 09:42:02PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Test the basics of drm_atomic_set_mode_for_crtc(), and in particular
> verify that the function doesn't take the shortcut incorrectly.
>
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
>
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e14d64857e27 drm/i915/gem: Manually dump the debug trace on
Have i915 replace the core drm_gem_mmap implementation to overcome its
limitation in having only a single mmap offset node per gem object.
This change allows us to have multiple mmap offsets per object and
enables a mmapping instance to use unique fault-handlers per user vma.
This allows i915 to
Prefer CPU WC mmaps via our new mmap offset plumbing otherwise fall-
back to GTT mmaps when hw doesn't support PAT
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
Acked-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 18 ++
This is really just an alias of mmap_gtt. The 'mmap offset' nomenclature
comes from the value returned by this ioctl which is the offset into the
device fd which userpace uses with mmap(2).
mmap_gtt was our initial mmap_offset implementation, this extends
our CPU mmap support to allow additional
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915/dsi: Configure transcoder operation for command mode.
Okay!
Commit:
== Series Details ==
Series: Add support for mipi dsi cmd mode (rev2)
URL : https://patchwork.freedesktop.org/series/69290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15328
Summary
---
On Fri, Nov 15, 2019 at 09:42:03PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The early return in drm_atomic_set_mode_for_crtc() isn't quite
> right. It would mistakenly return and fail to update
> crtc_state->enable if someone actually tried to set a zeroed
> mode on a currently
On 19/11/2019 13.37, Abdiel Janulgue wrote:
> +struct drm_i915_gem_mmap_offset {
> + /** Handle for the object being mapped. */
> + __u32 handle;
> + __u32 pad;
> + /**
> + * Fake offset to use for subsequent mmap call
> + *
> + * This is a fixed-size type for
== Series Details ==
Series: drm/i915/gem: Track ggtt writes from userspace on the bound vma
URL : https://patchwork.freedesktop.org/series/69672/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15326
On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote:
> > Also, see the other conversations we are having about a "virtual" bus
> > and devices. I do not want to have two different ways of doing the same
> > thing in the kernel at the same time please. Please work together with
> > the
On 19/11/2019 15:02, Arkadiusz Hiler wrote:
The goal is to have those descriptions in the first place and make them
more accessible to people. You have to keep in mind that we have
decently sized organization, people are coming and going. Not everyone
becomes a seasoned kernel developer day one
Dear Tomáš,
On 2019-11-04 18:31, Tomas Janousek wrote:
> On Mon, Nov 04, 2019 at 01:57:54PM +0100, Paul Menzel wrote:
>> On the Dell XPS 13 9380 with Debian Sid/unstable with Linux 5.3.7
>> resuming0with Dell’s Thunderbolt TB16 dock connected, Linux spews
>> the errors below.
>>
>> ```
>> [
Chris Wilson writes:
> We only need the one loop to find the dirty vma flush them, and their
> chipset.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git
On Fri, Nov 15, 2019 at 09:42:04PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently setplane grabs all modeset locks, which seems a bit
> excessive. Let's reduce that to just the locks we really need
> on atomic drivers. For non-atomic drivers let's stick to the
> current scheme
When userspace writes into the GTT itself, it is supposed to call
set-domain to let the kernel keep track and so manage the CPU/GPU
caches. As we track writes on the individual i915_vma, we should also be
sure to mark them as dirty.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Fault handler to handle missing pages for shmem-backed objects.
v2: bail out of inserting PTEs when failing to insert the
fault address
v3: has struct page check
v4: Add self-test for validating CPU fault handler to ensure PTEs
are revoked when an object is unbound.
v5: Add comment where
== Series Details ==
Series: series starting with [01/17] drm/i915/gem: Manually dump the debug
trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69669/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7370 -> Patchwork_15325
== Series Details ==
Series: drm/i915/dsi: Do not read the transcoder register.
URL : https://patchwork.freedesktop.org/series/69654/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7368_full -> Patchwork_15324_full
Summary
On Tue, Nov 19, 2019 at 02:37:17PM +0200, Lionel Landwerlin wrote:
> On 08/11/2019 11:04, Arkadiusz Hiler wrote:
> > On Thu, Nov 07, 2019 at 09:09:34PM +, Chris Wilson wrote:
> > > Quoting Arkadiusz Hiler (2019-11-07 17:38:20)
> > > > We don't want you to translate C into English, we want you
On Tue, Nov 19, 2019 at 10:02:08PM +0800, Jason Wang wrote:
>
> On 2019/11/19 下午8:38, Jason Gunthorpe wrote:
> > On Tue, Nov 19, 2019 at 10:41:31AM +0800, Jason Wang wrote:
> > > On 2019/11/19 上午4:28, Jason Gunthorpe wrote:
> > > > On Mon, Nov 18, 2019 at 03:27:13PM -0500, Michael S. Tsirkin
Hi Chris,
On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> 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
it looks good,
Reviewed-by:
On 19/11/2019 16:20, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-11-19 15:04:46)
On 18/11/2019 23:02, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 33ce258d484f..f7c8fec436a9 100644
---
On 2019/11/19 下午8:40, Jason Gunthorpe wrote:
On Tue, Nov 19, 2019 at 11:03:39AM +0800, Jason Wang wrote:
Also, see the other conversations we are having about a "virtual" bus
and devices. I do not want to have two different ways of doing the same
thing in the kernel at the same time please.
On 18/11/2019 23:02, Chris Wilson wrote:
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
Fork and remap the same object into a new process space under a new file
descriptor. Principally to check list management and find scaling issues
in using such lists.
Signed-off-by: Chris Wilson
Cc: Abdiel Janulgue
---
tests/i915/gem_mmap_gtt.c | 72 ++-
1
On Mon, Nov 18, 2019 at 08:00:07PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Cleanups around .crtc_enable/disable() (rev3)
> URL : https://patchwork.freedesktop.org/series/69352/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7365 ->
On 18/11/2019 23:02, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine
Quoting Andi Shyti (2019-11-19 15:24:59)
> Hi Chris,
>
> On Tue, Nov 19, 2019 at 10:09:29AM +, Chris Wilson wrote:
> > 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
On 18/11/2019 23:02, Chris Wilson wrote:
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
== Series Details ==
Series: drm/i915: make pool objects read-only
URL : https://patchwork.freedesktop.org/series/69684/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> Patchwork_15330
Summary
---
**SUCCESS**
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
Chris Wilson writes:
> Since igt now defaults to not enabling ftrace-on-oops, we need to
> manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
> GEM_BUG_ON panicking.
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem.h | 3 +++
> 1
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. A miniscule
optimisation.
References: 7936a22dd466 ("drm/i915/gt: Wait for new requests in
Quoting Mika Kuoppala (2019-11-19 16:12:18)
> Chris Wilson writes:
>
> > When waiting for idle, serialise with any ongoing callback so that it
> > will have completed before completing the wait.
>
> Might be come apparent and evident when reading the patch
> that introduce the
On 18/11/2019 23:02, Chris Wilson wrote:
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued
Quoting Tvrtko Ursulin (2019-11-19 14:15:49)
>
> On 18/11/2019 23:02, Chris Wilson wrote:
> > 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
Chris Wilson writes:
> When userspace writes into the GTT itself, it is supposed to call
> set-domain to let the kernel keep track and so manage the CPU/GPU
> caches. As we track writes on the individual i915_vma, we should also be
> sure to mark them as dirty.
>
> Signed-off-by: Chris Wilson
>
On 18/11/2019 23:02, Chris Wilson wrote:
In order to avoid some nasty mutex inversions, commit 09c5ab384f6f
("drm/i915: Keep rings pinned while the context is active") allowed the
intel_ring unpinning to be run concurrently with the next context
pinning it. Thus each step in intel_ring_unpin()
== Series Details ==
Series: i915/gem_mmap_gtt: Exercise many, many mappings of the same objects
URL : https://patchwork.freedesktop.org/series/69678/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7371 -> IGTPW_3727
On Tue, Nov 19, 2019 at 04:18:18PM +0100, Hans de Goede wrote:
> At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2
> different PWM controllers for controlling the LCD's backlight brightness.
> Either the one integrated into the PMIC or the one integrated into the
> SoC (the
On Tue, 19 Nov 2019, Vandita Kulkarni wrote:
> As per the Bspec, port mapping is fixed for mipi dsi.
>
> v2: Reuse the existing function (Jani)
>
> Signed-off-by: Vandita Kulkarni
Pushed, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 17
On 18/11/2019 23:02, Chris Wilson wrote:
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 -
On 18/11/2019 23:02, Chris Wilson wrote:
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 | 11 +--
1 file changed, 9 insertions(+), 2
1 - 100 of 161 matches
Mail list logo
