Hi,
There's a regression reported that HDMI output stops working after os upgrade:
https://bugs.launchpad.net/bugs/1871721
Here's the bisect result:
0519c102f5285476d7868a387bdb6c58385e4074 is the first bad commit
commit 0519c102f5285476d7868a387bdb6c58385e4074
Author: Ville Syrjälä
Date: Mon
== Series Details ==
Series: drm/i915: Apply Wa_14011264657:gen11+ (rev2)
URL : https://patchwork.freedesktop.org/series/78430/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8879_full -> Patchwork_18349_full
Summary
== Series Details ==
Series: series starting with [1/3] drm/i915: Cancel outstanding work after
disabling heartbeats on an engine (rev2)
URL : https://patchwork.freedesktop.org/series/80573/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8879 -> Patchwork_18351
== Series Details ==
Series: series starting with [1/3] drm/i915: Cancel outstanding work after
disabling heartbeats on an engine (rev2)
URL : https://patchwork.freedesktop.org/series/80573/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode
== Series Details ==
Series: series starting with [1/3] drm/i915: Cancel outstanding work after
disabling heartbeats on an engine
URL : https://patchwork.freedesktop.org/series/80573/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8879 -> Patchwork_18350
== Series Details ==
Series: series starting with [1/3] drm/i915: Cancel outstanding work after
disabling heartbeats on an engine
URL : https://patchwork.freedesktop.org/series/80573/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each
Verify that if a context is active at the time it is closed, that it is
either persistent and preemptible (with hangcheck running) or it shall
be removed from execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Testcase: igt/gem_ctx_persistence/heartbeat-close
== Series Details ==
Series: drm/i915: Apply Wa_14011264657:gen11+ (rev2)
URL : https://patchwork.freedesktop.org/series/78430/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8879 -> Patchwork_18349
Summary
---
Currently, we check we can send a pulse prior to disabling the
heartbeat to verify that we can change the heartbeat, but since we may
re-evaluate execution upon changing the heartbeat interval we need another
pulse afterwards to refresh execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose
Verify that if a context is active at the time it is closed, that it is
either persistent and preemptible (with hangcheck running) or it shall
be removed from execution.
Fixes: 9a40bddd47ca ("drm/i915/gt: Expose heartbeat interval via sysfs")
Testcase: igt/gem_ctx_persistence/heartbeat-close
We only allow persistent requests to remain on the GPU past the closure
of their containing context (and process) so long as they are continuously
checked for hangs or allow other requests to preempt them, as we need to
ensure forward progress of the system. If we allow persistent contexts
to
== Series Details ==
Series: drm/i915: Apply Wa_14011264657:gen11+ (rev2)
URL : https://patchwork.freedesktop.org/series/78430/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9ee56d53b00b drm/i915: Apply Wa_14011264657:gen11+
-:74: CHECK:BRACES: braces {} should be used on all
On Wed, Aug 05, 2020 at 04:29:20PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Enable HW Default flip for small PL.
>
> bspec: 52890
> bspec: 53508
> bspec: 53273
>
> v2: rebase to drm-tip
> Reviewed-by: Matt Atwood
> Signed-off-by: Clint Taylor
> ---
>
We expose the heartbeat interval on each engine, allowing the sysadim to
disable them if they prefer avoiding any interruption for their GPU
tasks. A caveat to allowing the contexts to run without checks is that
we require such contexts to be non-persistent and so cleaned up on
closure (including
We expose the heartbeat interval on each engine, allowing the sysadim to
disable them if they prefer avoiding any interruption for their GPU
tasks. A caveat to allowing the contexts to run without checks is that
we require such contexts to be non-persistent and so cleaned up on
closure (including
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
With the WW locking, we will drop all references only at the
end, so refcounting can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
Add minimum width to planes, variable with specific formats for gen11+
to reflect recent bspec changes.
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/display/intel_display.c | 54 +---
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's
On 8/10/20 12:31 PM, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst
Commit message, please.
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
On 8/12/20 9:32 PM, Thomas Hellström (Intel) wrote:
+ if (!err && ce->ring->vma->obj)
+ err = i915_gem_object_lock(ce->ring->vma->obj, ww);
+ if (!err && ce->state)
+ err = i915_gem_object_lock(ce->state->obj, ww);
Could these three locks be made interruptible?
Never
On 8/10/20 12:31 PM, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst
Commit message, please.
Otherwise, looks good.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 8/10/20 12:31 PM, Maarten Lankhorst wrote:
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Ensure that execbuf selftests keep passing by using ww handling.
Changes since v2:
- Fix i915_gem_context finally.
Signed-off-by:
On 8/10/20 12:31 PM, Maarten Lankhorst wrote:
We want to get rid of intel_context_pin(),
This answers a previous review question.
convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
LGTM. Reviewed-by: Thomas Hellström
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in
On 8/10/20 12:30 PM, Maarten Lankhorst wrote:
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to
On Wed, Aug 12, 2020 at 3:15 AM Anshuman Gupta wrote:
>
> On 2020-08-11 at 13:28:46 -0400, Sean Paul wrote:
> > On Thu, Jul 9, 2020 at 8:40 AM Anshuman Gupta
> > wrote:
> > >
> >
> > \snip
> >
> > > > > +static int
> > > > > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> > >
Hello there,
I am seeing this error after recently installing Archlinux on my Razer
Blade Stealth with the kernel version 5.7.12. I have seen it as well on
4.19, 5.4.55 and 5.8.0.
The error happens during boot time where it significantly increases boot
time. It starts with a time out in
drm-misc-fixes-2020-08-12:
drm-misc-fixes for v5.9-rc1:
- Add missing dma_fence_put() in virtio_gpu_execbuffer_ioctl().
- Fix memory leak in virtio_gpu_cleanup_object().
The following changes since commit b5ac98cbb8e5e30c34ebc837d1e5a3982d2b5f5c:
drm: Added orientation quirk for ASUS tablet
On Mon, 10 Aug 2020, Dave Airlie wrote:
> Like this stuff has been getting past me for years but I'm not happy
> about it anymore, I'm going to just be grumpy asshole going forward.
> If we introduced scheduler races in linux-next, I want to see reverts,
> and reverts only until we stopped
On 2020-08-11 at 13:21:38 -0400, Sean Paul wrote:
> On Thu, Jul 9, 2020 at 9:09 AM Anshuman Gupta
> wrote:
> >
> > On 2020-07-02 at 20:07:36 +0530, Anshuman Gupta wrote:
> > > On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> > > > On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
> > > >
Quoting Maarten Lankhorst (2020-08-10 11:30:40)
> This reverts commit 9e0f9464e2ab36b864359a59b0e9058fdef0ce47,
> and related commit 7ac2d2536dfa7 ("drm/i915/gem: Delete unused code").
>
> Async GPU relocations are not the path forward, we want to remove
> GPU accelerated relocation support
On 2020-08-11 at 13:28:46 -0400, Sean Paul wrote:
> On Thu, Jul 9, 2020 at 8:40 AM Anshuman Gupta
> wrote:
> >
>
> \snip
>
> > > > +static int
> > > > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> > > > *intel_dig_port,
> > > > + enum
38 matches
Mail list logo
