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 transcoder
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 eventu
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
> > > > wrote:
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 introdu
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 mode
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
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
> > > >
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 wai
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 i915_ac
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:
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 selftes
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:
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 i915_gem_ww_ctx
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:
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: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: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: Maar
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/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 mi
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(-)
dif
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 before
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 a/drivers/gpu/drm/i915/displ
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
_
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 a
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 a
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
> ---
> drivers/gpu/drm/
== 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 a
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 remai
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 heartbea
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
Signe
== 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
---
**SUCC
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
Signe
== 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
== 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 (rev2)
URL : https://patchwork.freedesktop.org/series/80573/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used
== 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: 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
---
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
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes: bf8dc55b1358 ("xen/gntdev: Implement dma-buf import
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to 'ERR_CAST'
From: Oleksandr Andrushchenko
Add YUYV to supported formats, so the frontend can work with the
formats used by cameras and other HW.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/xen/xen_drm_front_conn.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports different protocol versions. To simplify that
also add t
From: Oleksandr Andrushchenko
Hello,
This series contains an assorted set of fixes and improvements for
the Xen para-virtualized display driver and grant device driver which
I have collected over the last couple of months:
1. Minor fixes to grant device driver and drm/xen-front.
2. New format
From: Oleksandr Andrushchenko
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko
Acked-by: Noralf Trønnes
---
drivers/gpu/dr
== Series Details ==
Series: Fixes and improvements for Xen pvdrm (rev2)
URL : https://patchwork.freedesktop.org/series/80141/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
18bd08b8bf52 xen/gntdev: Fix dmabuf import with non-zero sgt offset
edc113ee2576 drm/xen-front: Fix misus
45 matches
Mail list logo
