Re: [Intel-gfx] [PATCH 1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice
On Thu, May 28, 2020 at 01:03:53PM -0700, José Roberto de Souza wrote:
> It will be programed right before the link training, so no need to do
> it twice.
> It will not strictly follow BSpec sequences but most of this sequences
> are not matching anyways.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 19 ---
> 1 file changed, 4 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index aa22465bb56e..c100efc6a2c4 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3115,7 +3115,6 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> - int level = intel_ddi_dp_level(intel_dp);
> enum transcoder transcoder = crtc_state->cpu_transcoder;
>
> intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> @@ -3190,9 +3189,10 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>* down this function.
>*/
>
> - /* 7.e Configure voltage swing and related IO settings */
> - tgl_ddi_vswing_sequence(encoder, crtc_state->port_clock, level,
> - encoder->type);
> + /*
> + * 7.e Configure voltage swing and related IO settings
> + * It will be done in intel_dp_start_link_train(), no need to do twice
> + */
Hmm. Do we still set it up before turning on the port?
>
> /*
>* 7.f Combo PHY: Configure PORT_CL_DW10 Static Power Down to power up
> @@ -3257,7 +3257,6 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
> enum phy phy = intel_port_to_phy(dev_priv, port);
> struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> - int level = intel_ddi_dp_level(intel_dp);
>
> if (INTEL_GEN(dev_priv) < 11)
> drm_WARN_ON(&dev_priv->drm,
> @@ -3279,16 +3278,6 @@ static void hsw_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>
> icl_program_mg_dp_mode(dig_port, crtc_state);
>
> - if (INTEL_GEN(dev_priv) >= 11)
> - icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
> - level, encoder->type);
> - else if (IS_CANNONLAKE(dev_priv))
> - cnl_ddi_vswing_sequence(encoder, level, encoder->type);
> - else if (IS_GEN9_LP(dev_priv))
> - bxt_ddi_vswing_sequence(encoder, level, encoder->type);
> - else
> - intel_prepare_dp_ddi_buffers(encoder, crtc_state);
This last one definitely has to stay IIRC. HSW/BDW/SKL buf trans
stuff works quite bit differently than the BXT+ style more manual
programming.
> -
> if (intel_phy_is_combo(dev_priv, phy)) {
> bool lane_reversal =
> dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
> --
> 2.26.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 02/17] dma-fence: basic lockdep annotations
On Thu, May 28, 2020 at 11:54 PM Luben Tuikov wrote:
>
> On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> > this explicit annotation can be more liberally sprinkled around.
> > With read locks lockdep isn't going to complain if the read-side
> > isn't nested the same way under all circumstances, so ABBA deadlocks
> > are ok. Which they are, since this is an annotation only.
> >
> > - We're using non-recursive lockdep read lock mode, since in recursive
> > read lock mode lockdep does not catch read side hazards. And we
> > _very_ much want read side hazards to be caught. For full details of
> > this limitation see
> >
> > commit e91498589746065e3ae95d9a00b068e525eec34f
> > Author: Peter Zijlstra
> > Date: Wed Aug 23 13:13:11 2017 +0200
> >
> > locking/lockdep/selftests: Add mixed read-write ABBA tests
> >
> > - To allow nesting of the read-side explicit annotations we explicitly
> > keep track of the nesting. lock_is_held() allows us to do that.
> >
> > - The wait-side annotation is a write lock, and entirely done within
> > dma_fence_wait() for everyone by default.
> >
> > - To be able to freely annotate helper functions I want to make it ok
> > to call dma_fence_begin/end_signalling from soft/hardirq context.
> > First attempt was using the hardirq locking context for the write
> > side in lockdep, but this forces all normal spinlocks nested within
> > dma_fence_begin/end_signalling to be spinlocks. That bollocks.
> >
> > The approach now is to simple check in_atomic(), and for these cases
> > entirely rely on the might_sleep() check in dma_fence_wait(). That
> > will catch any wrong nesting against spinlocks from soft/hardirq
> > contexts.
> >
> > The idea here is that every code path that's critical for eventually
> > signalling a dma_fence should be annotated with
> > dma_fence_begin/end_signalling. The annotation ideally starts right
> > after a dma_fence is published (added to a dma_resv, exposed as a
> > sync_file fd, attached to a drm_syncobj fd, or anything else that
> > makes the dma_fence visible to other kernel threads), up to and
> > including the dma_fence_wait(). Examples are irq handlers, the
> > scheduler rt threads, the tail of execbuf (after the corresponding
> > fences are visible), any workers that end up signalling dma_fences and
> > really anything else. Not annotated should be code paths that only
> > complete fences opportunistically as the gpu progresses, like e.g.
> > shrinker/eviction code.
> >
> > The main class of deadlocks this is supposed to catch are:
> >
> > Thread A:
> >
> > mutex_lock(A);
> > mutex_unlock(A);
> >
> > dma_fence_signal();
> >
> > Thread B:
> >
> > mutex_lock(A);
> > dma_fence_wait();
> > mutex_unlock(A);
> >
> > Thread B is blocked on A signalling the fence, but A never gets around
> > to that because it cannot acquire the lock A.
> >
> > Note that dma_fence_wait() is allowed to be nested within
> > dma_fence_begin/end_signalling sections. To allow this to happen the
> > read lock needs to be upgraded to a write lock, which means that any
> > other lock is acquired between the dma_fence_begin_signalling() call and
> > the call to dma_fence_wait(), and still held, this will result in an
> > immediate lockdep complaint. The only other option would be to not
> > annotate such calls, defeating the point. Therefore these annotations
> > cannot be sprinkled over the code entirely mindless to avoid false
> > positives.
> >
> > v2: handle soft/hardirq ctx better against write side and dont forget
> > EXPORT_SYMBOL, drivers can't use this otherwise.
> >
> > Cc: linux-me...@vger.kernel.org
> > Cc: linaro-mm-...@lists.linaro.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: amd-...@lists.freedesktop.org
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: Chris Wilson
> > Cc: Maarten Lankhorst
> > Cc: Christian König
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/dma-buf/dma-fence.c | 53 +
> > include/linux/dma-fence.h | 12 +
> > 2 files changed, 65 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 6802125349fb..d5c0fd2efc70 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
> > }
> > EXPORT_SYMBOL(dma_fence_context_alloc);
> >
> > +#ifdef CONFIG_LOCKDEP
> > +struct lockdep_map dma_fence_lockdep_map = {
> > + .name = "dma_fence_map"
> > +};
> > +
> > +bool dma_fence_begin_signalling(void)
> > +{
> > + /* explicitly nesting ... */
> > + if (lock_is_held_type(&dma_fence_lockdep_map, 1))
> > + return true;
> > +
> > + /* rely on might_sleep check for soft/hardirq locks */
> > + if (in_ato
Re: [Intel-gfx] [PATCH v3 0/5] Asynchronous flip implementation for i915
On 5/28/2020 11:17 PM, Paulo Zanoni wrote: Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu: Without async flip support in the kernel, fullscreen apps where game resolution is equal to the screen resolution, must perform an extra blit per frame prior to flipping. Asynchronous page flips will also boost the FPS of Mesa benchmarks. v2: Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. v3: Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. Hello I asked quite a few questions in the review of v2, but never got any replies. I see some things regarding those questions are different in v3, but I still would really like to have those answers in direct text/email form in order to clarify my understanding of your original intent (and also help me understand why things are different in v3). Would you mind replying to those emails? Hi, Sorry for not doing this earlier. I've now responded to the questions on the v2 of this series. Thank you for all the reviews. Thanks, Karthik.B.S Thanks, Paulo Karthik B S (5): drm/i915: Add enable/disable flip done and flip done handler drm/i915: Add support for async flips in I915 drm/i915: Add checks specific to async flips drm/i915: Do not call drm_crtc_arm_vblank_event in async flips drm/i915: Enable async flips in i915 drivers/gpu/drm/i915/display/intel_display.c | 71 drivers/gpu/drm/i915/display/intel_sprite.c | 8 ++- drivers/gpu/drm/i915/i915_irq.c | 52 ++ drivers/gpu/drm/i915/i915_irq.h | 2 + drivers/gpu/drm/i915/i915_reg.h | 1 + 5 files changed, 133 insertions(+), 1 deletion(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount
On Thu, May 28, 2020 at 10:58:52PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> > On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > While the current locking/serialization of the global state
> > > suffices for protecting the obj->state access and the actual
> > > hardware reprogramming, we do have a problem with accessing
> > > the old/new states during nonblocking commits.
> > >
> > > The state computation and swap will be protected by the crtc
> > > locks, but the commit_tails can finish out of order, thus also
> > > causing the atomic states to be cleaned up out of order. This
> > > would mean the commit that started first but finished last has
> > > had its new state freed as the no-longer-needed old state by the
> > > other commit.
> > >
> > > To fix this let's just refcount the states. obj->state amounts
> > > to one reference, and the intel_atomic_state holds extra references
> > > to both its new and old global obj states.
> > >
> > > Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state handling")
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > .../gpu/drm/i915/display/intel_global_state.c | 45 ---
> > > .../gpu/drm/i915/display/intel_global_state.h | 3 ++
> > > 2 files changed, 42 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c
> > > b/drivers/gpu/drm/i915/display/intel_global_state.c
> > > index 212d4ee68205..7a19215ad844 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_global_state.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_global_state.c
> > > @@ -10,6 +10,28 @@
> > > #include "intel_display_types.h"
> > > #include "intel_global_state.h"
> > >
> > > +static void __intel_atomic_global_state_free(struct kref *kref)
> > > +{
> > > + struct intel_global_state *obj_state =
> > > + container_of(kref, struct intel_global_state, ref);
> > > + struct intel_global_obj *obj = obj_state->obj;
> > > +
> > > + obj->funcs->atomic_destroy_state(obj, obj_state);
> > > +}
> > > +
> > > +static void intel_atomic_global_state_put(struct intel_global_state
> > > *obj_state)
> > > +{
> > > + kref_put(&obj_state->ref, __intel_atomic_global_state_free);
> > > +}
> > > +
> > > +static struct intel_global_state *
> > > +intel_atomic_global_state_get(struct intel_global_state *obj_state)
> > > +{
> > > + kref_get(&obj_state->ref);
> > > +
> > > + return obj_state;
> > > +}
> > > +
> > > void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv,
> > > struct intel_global_obj *obj,
> > > struct intel_global_state *state,
> > > @@ -17,6 +39,10 @@ void intel_atomic_global_obj_init(struct
> > > drm_i915_private *dev_priv,
> > > {
> > > memset(obj, 0, sizeof(*obj));
> > >
> > > + state->obj = obj;
> > > +
> > > + kref_init(&state->ref);
> > > +
> > > obj->state = state;
> > > obj->funcs = funcs;
> > > list_add_tail(&obj->head, &dev_priv->global_obj_list);
> > > @@ -28,7 +54,9 @@ void intel_atomic_global_obj_cleanup(struct
> > > drm_i915_private *dev_priv)
> > >
> > > list_for_each_entry_safe(obj, next, &dev_priv->global_obj_list, head) {
> > > list_del(&obj->head);
> > > - obj->funcs->atomic_destroy_state(obj, obj->state);
> > > +
> > > + drm_WARN_ON(&dev_priv->drm, kref_read(&obj->state->ref) != 1);
> > > + intel_atomic_global_state_put(obj->state);
> > > }
> > > }
> > >
> > > @@ -97,10 +125,14 @@ intel_atomic_get_global_obj_state(struct
> > > intel_atomic_state *state,
> > > if (!obj_state)
> > > return ERR_PTR(-ENOMEM);
> > >
> > > + obj_state->obj = obj;
> > > obj_state->changed = false;
> > >
> > > + kref_init(&obj_state->ref);
> > > +
> > > state->global_objs[index].state = obj_state;
> > > - state->global_objs[index].old_state = obj->state;
> > > + state->global_objs[index].old_state =
> > > + intel_atomic_global_state_get(obj->state);
> > > state->global_objs[index].new_state = obj_state;
> > > state->global_objs[index].ptr = obj;
> > > obj_state->state = state;
> > > @@ -163,7 +195,9 @@ void intel_atomic_swap_global_state(struct
> > > intel_atomic_state *state)
> > > new_obj_state->state = NULL;
> > >
> > > state->global_objs[i].state = old_obj_state;
> > > - obj->state = new_obj_state;
> > > +
> > > + intel_atomic_global_state_put(obj->state);
> > > + obj->state = intel_atomic_global_state_get(new_obj_state);
> > > }
> > > }
> > >
> > > @@ -172,10 +206,9 @@ void intel_atomic_clear_global_state(struct
> > > intel_atomic_state *state)
> > > int i;
> > >
> > > for (i = 0; i < state->num_global_objs; i++) {
> > > - struct intel_global_obj *obj = state->global_objs[i].ptr;
> > > + intel_atomic_global_state_put(state->global_objs[i].old_state);
> > > + i
Re: [Intel-gfx] [PATCHES] uaccess i915
On Fri, 29 May 2020, Al Viro wrote: > Low-hanging fruit in i915 uaccess-related stuff. > There's some subtler stuff remaining after that; these > are the simple ones. Please Cc: intel-gfx@lists.freedesktop.org for i915 changes. Also added Chris who I believe will be able to best review the changes. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Add checks specific to async flips
On 4/20/2020 11:28 PM, Paulo Zanoni wrote:
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
Support added only for async flips on primary plane.
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 59
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a5203de24045..ac7f26a9ac4a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14669,6 +14669,57 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
return false;
}
+static int intel_atomic_check_async(struct intel_atomic_state *state)
+{
+ struct drm_plane *plane;
+ struct drm_plane_state *plane_state;
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_plane_state *new_plane_state, *old_plane_state;
+ struct intel_crtc *crtc;
+ struct intel_plane *intel_plane;
+ int i, j;
+
+ /*FIXME: Async flip is only supported for primary plane currently
+* Support for overlays to be added.
+*/
+
+ /*TODO: Check if the user space can handle the EINVAL return
+* or if it needs to be handled differently
+*/
Does this mean we still didn't test the series against real user space?
I mean, X server with xf86-video-modesetting and some real workload
instead of just igt. I can't feel confident to give r-b tags if I know
the patches were not tested yet. The series should probably have been
marked as an RFC.
I've now run benchmarking tests for this series on Gen9 platform and the
initial results are positive.
Thanks,
Karthik.B.S
+ for_each_new_plane_in_state(&state->base, plane, plane_state, j) {
+ if (plane->type != DRM_PLANE_TYPE_PRIMARY) {
+ DRM_DEBUG_KMS("Async flips is NOT supported for non-primary
plane\n");
+ return -EINVAL;
+ }
+ }
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (old_crtc_state->enable_fbc != new_crtc_state->enable_fbc) {
+ DRM_DEBUG_KMS("FBC status cannot be changed in async
flip\n");
+ return -EINVAL;
+ }
+ }
+
+ for_each_oldnew_intel_plane_in_state(state, intel_plane,
old_plane_state,
+new_plane_state, i) {
+ if ((old_plane_state->color_plane[0].x !=
+new_plane_state->color_plane[0].x) ||
+ (old_plane_state->color_plane[0].y !=
+new_plane_state->color_plane[0].y)) {
+ DRM_DEBUG_KMS("Offsets cannot be changed in async\n");
+ return -EINVAL;
+ }
+
+ if (old_plane_state->uapi.fb->modifier !=
+ new_plane_state->uapi.fb->modifier) {
+ DRM_DEBUG_KMS("Framebuffer modifiers cannot be changed in
async flip\n");
+ return -EINVAL;
+ }
+ }
+ return 0;
+}
+
/**
* intel_atomic_check - validate state object
* @dev: drm device
@@ -14697,6 +14748,14 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
goto fail;
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip) {
+ ret = intel_atomic_check_async(state);
+ if (ret)
+ goto fail;
+ }
+ }
+
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
if (!needs_modeset(new_crtc_state)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/6] drm/i915: Make commit call blocking in case of async flips
On 4/24/2020 11:16 PM, Paulo Zanoni wrote:
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
Make the commit call blocking in case of async flips
so that there is no delay in completing the flip.
I'm trying to understand the code. Can you please elaborate more here
in this commit message? Why exactly does the call need to block? What
would be the problem of not having this patch? And how does blocking
ensures no delay?
My initial assumption was that blocking call would ensure lesser delay
as commit tail is immediately called, but after running some
benchmarking tests, its clearly not the case.
So no point in having this, removed this patch in V3.
Thanks,
Karthik.B.S
v2: -Rebased
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8601b159f425..a5203de24045 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15563,7 +15563,9 @@ static int intel_atomic_commit(struct drm_device *dev,
{
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
- int ret = 0;
+ struct intel_crtc_state *new_crtc_state;
+ struct intel_crtc *crtc;
+ int ret = 0, i;
state->wakeref = intel_runtime_pm_get(&dev_priv->runtime_pm);
@@ -15589,10 +15591,6 @@ static int intel_atomic_commit(struct drm_device *dev,
* (assuming we had any) would solve these problems.
*/
if (INTEL_GEN(dev_priv) < 9 && state->base.legacy_cursor_update) {
- struct intel_crtc_state *new_crtc_state;
- struct intel_crtc *crtc;
- int i;
-
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i)
if (new_crtc_state->wm.need_postvbl_update ||
new_crtc_state->update_wm_post)
@@ -15634,6 +15632,13 @@ static int intel_atomic_commit(struct drm_device *dev,
drm_atomic_state_get(&state->base);
INIT_WORK(&state->base.commit_work, intel_atomic_commit_work);
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip) {
+ nonblock = false;
+ break;
+ }
+ }
+
i915_sw_fence_commit(&state->commit_ready);
if (nonblock && state->modeset) {
queue_work(dev_priv->modeset_wq, &state->base.commit_work);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Enable async flips in i915
On 4/20/2020 11:34 PM, Paulo Zanoni wrote: Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu: Enable asynchronous flips in i915 for gen9+ platforms. v2: -Async flip enablement should be a stand alone patch (Paulo) ... and at the very end of the series. If someone is bisecting the Kernel for some problem unrelated to async flips, and they end up exactly at this commit, and their user space happens to try to do async flips, will their system be broken? A quick check at patches 4, 5 and 6 suggests they are necessary for the feature to work, so here we're enabling a feature that we know won't work because its support is not fully merged yet. A patch series is not allowed to break the Kernel in the middle and then fix it later. Understood. Moved this patch to the end of the series. Thanks, Karthik.B.S Signed-off-by: Karthik B S --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index cf8f5779dee4..8601b159f425 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -17574,6 +17574,9 @@ static void intel_mode_config_init(struct drm_i915_private *i915) mode_config->funcs = &intel_mode_funcs; + if (INTEL_GEN(i915) >= 9) + mode_config->async_page_flip = true; + /* * Maximum framebuffer dimensions, chosen to match * the maximum render engine surface size on gen4+. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add enable/disable flip done and flip done handler
On 4/24/2020 11:14 PM, Paulo Zanoni wrote:
Em seg, 2020-04-20 às 15:17 +0530, Karthik B S escreveu:
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
Flip done handler is used to send the page flip event as soon as the
surface address is written as per the requirement of async flips.
The interrupt is disabled after the event is sent.
v2: -Change function name from icl_* to skl_* (Paulo)
-Move flip handler to this patch (Paulo)
-Remove vblank_put() (Paulo)
-Enable flip done interrupt for gen9+ only (Paulo)
-Enable flip done interrupt in power_well_post_enable hook (Paulo)
-Removed the event check in flip done handler to handle async
flips without pageflip events.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/i915_irq.c | 51
drivers/gpu/drm/i915/i915_irq.h | 2 +
3 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bae1d89875d6..3ce80634d047 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15391,6 +15391,13 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
if (state->modeset)
icl_dbuf_slice_pre_update(state);
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip) {
+ skl_enable_flip_done(&crtc->base);
+ break;
+ }
+ }
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1502ab44f1a5..9b64ed78523e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1253,6 +1253,22 @@ display_pipe_crc_irq_handler(struct drm_i915_private
*dev_priv,
u32 crc4) {}
#endif
+static void flip_done_handler(struct drm_i915_private *dev_priv,
+ unsigned int pipe)
+{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
+ struct drm_crtc_state *crtc_state = crtc->base.state;
+ struct drm_device *dev = &dev_priv->drm;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&dev->event_lock, irqflags);
+
+ drm_crtc_send_vblank_event(&crtc->base, crtc_state->event);
+ crtc_state->event = NULL;
+
+ spin_unlock_irqrestore(&dev->event_lock, irqflags);
+ skl_disable_flip_done(&crtc->base);
I am trying to understand the code here but I'm not 100% confident, so
my comments may be wrong. Please correct me if needed.
Can you please elaborate on why we have to disable the interrupt from
the interrupt handler? This looks racy to me, but I may be wrong, so an
explanation would help.
In my head this would be the ideal:
- If the whole ioctl is blocked until we get the interrupt (which is
what patch 04 suggests), then whatever is blocking waiting on the
interrupt should enable+disable the interrupt (so no disable_flip_done
here).
- If the ioctl is not blocked, then isn't there a race risk in case
user space finds a way to submit 2 ioctls before we get an interrupt?
If no, why would this be impossible? Some sort of refcounting could
help in this case. I'm also thinking in cases like alternating between
flips requiring events and flips not requiring events.
Agreed on this fully. My thinking was to just disable the interrupt soon
after we've got it. But doing this in commit tail makes more sense, and
especially now as I've made the call non blocking, it will definitely
have a risk of being racy as you've mentioned.
Moved this out of interrupt handler to intel_atomic_commit_tail
function, where I'm disabling it after the wait for flip done.
Thanks,
Karthik.B.S
+}
static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
enum pipe pipe)
@@ -2355,6 +2371,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
if (iir & GEN8_PIPE_VBLANK)
intel_handle_vblank(dev_priv, pipe);
+ if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
+ flip_done_handler(dev_priv, pipe);
+
if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
hsw_pipe_crc_irq_handler(dev_priv, pipe);
@@ -2636,6 +2655,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
return 0;
}
+void skl_enable_flip_done(struct drm_crtc *crtc)
+{
+ struct drm_i915_priv
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/11] drm/i915/gt: Start timeslice on partial submission
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8549_full -> Patchwork_17809_full
Summary
---
**SUCCESS**
No regressions found.
New tests
-
New tests have been introduced between CI_DRM_8549_full and
Patchwork_17809_full:
### New IGT tests (1) ###
* igt@dmabuf@all@dma_fence_proxy:
- Statuses : 7 pass(s)
- Exec time: [0.02, 0.12] s
Known issues
Here are the changes found in Patchwork_17809_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#1602] /
[i915#456])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-tglb8/igt@gem_exec_susp...@basic-s0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-tglb6/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-kbl: [PASS][3] -> [FAIL][4] ([i915#54] / [i915#93] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
* igt@kms_cursor_legacy@all-pipes-torture-move:
- shard-tglb: [PASS][5] -> [DMESG-WARN][6] ([i915#128]) +1 similar
issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-tglb6/igt@kms_cursor_leg...@all-pipes-torture-move.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-tglb5/igt@kms_cursor_leg...@all-pipes-torture-move.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#1188]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl6/igt@kms_...@bpc-switch-dpms.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-skl6/igt@kms_...@bpc-switch-dpms.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265])
+1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +3 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-iclb6/igt@kms_psr@psr2_cursor_mmap_cpu.html
Possible fixes
* igt@gem_eio@in-flight-suspend:
- shard-skl: [INCOMPLETE][13] ([i915#69]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl4/igt@gem_...@in-flight-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-skl8/igt@gem_...@in-flight-suspend.html
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-tglb: [FAIL][15] ([i915#1930]) -> [PASS][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-tglb3/igt@gem_exec_re...@basic-concurrent0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-tglb3/igt@gem_exec_re...@basic-concurrent0.html
- shard-apl: [FAIL][17] ([i915#1930]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-apl7/igt@gem_exec_re...@basic-concurrent0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-apl7/igt@gem_exec_re...@basic-concurrent0.html
- shard-kbl: [FAIL][19] ([i915#1930]) -> [PASS][20] +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-kbl6/igt@gem_exec_re...@basic-concurrent0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-kbl2/igt@gem_exec_re...@basic-concurrent0.html
- shard-snb: [FAIL][21] ([i915#1930]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-snb5/igt@gem_exec_re...@basic-concurrent0.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-snb1/igt@gem_exec_re...@basic-concurrent0.html
* {igt@gem_exec_reloc@basic-concurrent16}:
- shard-iclb: [FAIL][23] ([i915#1930]) -> [PASS][24] +1 similar
issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-iclb5/igt@gem_exec_re...@basic-concurrent16.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/shard-iclb3/igt@gem_exec_re...@basic
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Start timeslice on partial submission
== Series Details == Series: drm/i915/gt: Start timeslice on partial submission URL : https://patchwork.freedesktop.org/series/77761/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8549_full -> Patchwork_17808_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17808_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17808_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17808_full: ### IGT changes ### Possible regressions * igt@gen9_exec_parse@bb-chained: - shard-glk: NOTRUN -> [TIMEOUT][1] +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-glk2/igt@gen9_exec_pa...@bb-chained.html Warnings * igt@runner@aborted: - shard-hsw: [FAIL][2] ([fdo#109271]) -> [FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-hsw8/igt@run...@aborted.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-hsw8/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17808_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@invalid-ctx-get: - shard-hsw: [PASS][4] -> [DMESG-WARN][5] ([i915#1927]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-hsw8/igt@gem_ctx_pa...@invalid-ctx-get.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-hsw8/igt@gem_ctx_pa...@invalid-ctx-get.html * igt@gem_exec_suspend@basic-s0: - shard-tglb: [PASS][6] -> [INCOMPLETE][7] ([i915#1602] / [i915#456]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-tglb8/igt@gem_exec_susp...@basic-s0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-tglb3/igt@gem_exec_susp...@basic-s0.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][8] -> [DMESG-WARN][9] ([i915#180]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-kbl2/igt@gem_soft...@noreloc-s3.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-kbl7/igt@gem_soft...@noreloc-s3.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][10] -> [DMESG-WARN][11] ([i915#180]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#1119] / [i915#118] / [i915#95]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-glk1/igt@kms_big...@y-tiled-64bpp-rotate-180.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#54] / [i915#93] / [i915#95]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html * igt@kms_cursor_legacy@cursorb-vs-flipa-atomic: - shard-hsw: [PASS][16] -> [INCOMPLETE][17] ([i915#61]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-hsw1/igt@kms_cursor_leg...@cursorb-vs-flipa-atomic.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-hsw1/igt@kms_cursor_leg...@cursorb-vs-flipa-atomic.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][18] -> [FAIL][19] ([fdo#108145] / [i915#265]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109441]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/shard-iclb4/igt@kms_psr@psr2_cursor_mmap_cpu.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-skl: [INCOMPLETE][22] ([i915#69]) -> [PASS][23] +1 similar issue [22]: https://intel-gfx-ci.01.org/tr
Re: [Intel-gfx] [PATCH 0/8] Convert the intel iommu driver to the dma-iommu api
Hi Tom, On 2019-12-21 8:03 a.m., Tom Murphy wrote: > This patchset converts the intel iommu driver to the dma-iommu api. Just wanted to note that I've rebased your series on recent kernels and have done some testing on my old Sandybridge machine (without the DO NOT MERGE patch) and have found no issues. I hope this can make progress soon and get merged soon. If you like you can add: Tested-By: Logan Gunthorpe > While converting the driver I exposed a bug in the intel i915 driver which > causes a huge amount of artifacts on the screen of my laptop. You can see a > picture of it here: > https://github.com/pippy360/kernelPatches/blob/master/IMG_20191219_225922.jpg > > This issue is most likely in the i915 driver and is most likely caused by the > driver not respecting the return value of the dma_map_ops::map_sg function. > You can see the driver ignoring the return value here: > https://github.com/torvalds/linux/blob/7e0165b2f1a912a06e381e91f0f4e495f4ac3736/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c#L51 > > Previously this didn’t cause issues because the intel map_sg always returned > the same number of elements as the input scatter gather list but with the > change to this dma-iommu api this is no longer the case. I wasn’t able to > track the bug down to a specific line of code unfortunately. I did some digging into this myself and while I don't have full patch, I think I traced it closer to the problem. Sadly, ignoring the number of nents returned by map_sg() is endemic to dma-buf users, but AMD's GPU driver seems to do the same thing, presumably without issues. Digging a bit further, I found that the i915 has an "innovative" way of iterating through SGLs, see [1]. I suspect if __sgt_iter is changed to increment with sg_dma_len() and return NULL when there is no length left, it may fix the issue. But, sorry, I don't really have the means or time to fix and test this myself. Thanks, Logan [1] https://elixir.bootlin.com/linux/v5.7-rc7/source/drivers/gpu/drm/i915/i915_scatterlist.h#L76 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Track i915_vma with its own reference counter
== Series Details == Series: drm/i915: Track i915_vma with its own reference counter URL : https://patchwork.freedesktop.org/series/77763/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8550 -> Patchwork_17810 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17810 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17810, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17810/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17810: ### IGT changes ### Possible regressions * igt@kms_busy@basic@modeset: - fi-ivb-3770:[PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8550/fi-ivb-3770/igt@kms_busy@ba...@modeset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17810/fi-ivb-3770/igt@kms_busy@ba...@modeset.html Known issues Here are the changes found in Patchwork_17810 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@sanitycheck: - fi-skl-lmem:[PASS][3] -> [INCOMPLETE][4] ([i915#198]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8550/fi-skl-lmem/igt@i915_selftest@l...@sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17810/fi-skl-lmem/igt@i915_selftest@l...@sanitycheck.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-skl-lmem:[PASS][5] -> [FAIL][6] ([fdo#103375]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8550/fi-skl-lmem/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17810/fi-skl-lmem/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Possible fixes * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][7] ([i915#541]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8550/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17810/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#198]: https://gitlab.freedesktop.org/drm/intel/issues/198 [i915#541]: https://gitlab.freedesktop.org/drm/intel/issues/541 Participating hosts (50 -> 43) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8550 -> Patchwork_17810 CI-20190529: 20190529 CI_DRM_8550: 0f5fdd75c2eaf3734f28639a9efc47a997f18839 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5683: 757b6e72d546fd2dbc3801a73796d67b0854021b @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17810: 55980f47bd93a87db93357529f1be537aebd2677 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 55980f47bd93 drm/i915: Track i915_vma with its own reference counter == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17810/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Track i915_vma with its own reference counter
== Series Details == Series: drm/i915: Track i915_vma with its own reference counter URL : https://patchwork.freedesktop.org/series/77763/ State : warning == Summary == $ dim checkpatch origin/drm-tip 55980f47bd93 drm/i915: Track i915_vma with its own reference counter -:2210: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #2210: FILE: drivers/gpu/drm/i915/gt/intel_gtt.h:267: + spinlock_t lock; -:3974: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #3974: FILE: drivers/gpu/drm/i915/i915_vma.h:386: + spinlock_t lock; -:4221: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4221: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:394: + if (offset < hole_start + vma->size) -:4232: WARNING:LONG_LINE: line over 100 characters #4232: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:402: + __func__, p->name, err, npages, prime, offset, -:4242: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4242: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:419: + if (offset + vma->node.size > hole_end) -:4258: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4258: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:428: + if (offset < hole_start + vma->node.size) -:4270: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4270: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:451: + if (offset + vma->node.size > hole_end) -:4286: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4286: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:460: + if (offset < hole_start + vma->node.size) -:4298: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4298: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:484: + if (offset + vma->size >= hole_end) -:4314: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4314: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:493: + if (offset < hole_start + vma->size) -:4326: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code refactoring #4326: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:516: + if (offset + vma->size >= hole_end) total: 0 errors, 9 warnings, 2 checks, 4754 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915/gt: Start timeslice on partial submission
== Series Details == Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial submission URL : https://patchwork.freedesktop.org/series/77762/ State : success == Summary == CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17809 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/index.html New tests - New tests have been introduced between CI_DRM_8549 and Patchwork_17809: ### New IGT tests (1) ### * igt@dmabuf@all@dma_fence_proxy: - Statuses : 41 pass(s) - Exec time: [0.03, 0.10] s Changes --- No changes found Participating hosts (50 -> 43) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8549 -> Patchwork_17809 CI-20190529: 20190529 CI_DRM_8549: e50e9c6bf4efd00b02d91ff470993bbd0db94f67 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5682: e5371a99a877be134c6ad5361a5f03843a66f775 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17809: 70c78cfa6ea58dde569696417b5e00d7ad6b7151 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 70c78cfa6ea5 drm/i915/gem: Make relocations atomic within execbuf 372342371047 drm/i915: Unpeel awaits on a proxy fence eba65e7de8ae dma-buf: Proxy fence, an unsignaled fence placeholder 71c20a444d9e drm/i915/gem: Add all GPU reloc awaits/signals en masse c2d55803a60c drm/i915/gem: Build the reloc request first 10ad05422c96 drm/i915/gem: Lift GPU relocation allocation fb12696a43ec drm/i915/gem: Separate reloc validation into an earlier step 283e921c4b08 drm/i915: Add list_for_each_entry_safe_continue_reverse 7c0380bdfab2 drm/i915/gem: Async GPU relocations only af3a1406b2d8 drm/i915/gem: Mark the buffer pool as active for the cmdparser dc44da7a88e6 drm/i915/gt: Start timeslice on partial submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17809/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice
== Series Details ==
Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the
same vswing entry twice
URL : https://patchwork.freedesktop.org/series/77758/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8549_full -> Patchwork_17806_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17806_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17806_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17806_full:
### IGT changes ###
Possible regressions
* igt@gen9_exec_parse@bb-chained:
- shard-glk: NOTRUN -> [TIMEOUT][1] +6 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-glk9/igt@gen9_exec_pa...@bb-chained.html
Known issues
Here are the changes found in Patchwork_17806_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][2] -> [INCOMPLETE][3] ([i915#1602] /
[i915#456])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-tglb8/igt@gem_exec_susp...@basic-s0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-tglb5/igt@gem_exec_susp...@basic-s0.html
* igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-kbl: [PASS][4] -> [FAIL][5] ([i915#54] / [i915#93] /
[i915#95])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-kbl4/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][6] -> [DMESG-WARN][7] ([i915#180]) +2 similar
issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][8] -> [FAIL][9] ([i915#1188])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl4/igt@kms_...@bpc-switch-suspend.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-skl9/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [PASS][10] -> [FAIL][11] ([fdo#108145] / [i915#265])
+2 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109441]) +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-iclb6/igt@kms_psr@psr2_cursor_blt.html
* igt@kms_setmode@basic:
- shard-hsw: [PASS][14] -> [FAIL][15] ([i915#31])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-hsw4/igt@kms_setm...@basic.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-hsw4/igt@kms_setm...@basic.html
Possible fixes
* igt@gem_eio@in-flight-suspend:
- shard-skl: [INCOMPLETE][16] ([i915#69]) -> [PASS][17] +1 similar
issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl4/igt@gem_...@in-flight-suspend.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-skl9/igt@gem_...@in-flight-suspend.html
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-apl: [FAIL][18] ([i915#1930]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-apl7/igt@gem_exec_re...@basic-concurrent0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-apl3/igt@gem_exec_re...@basic-concurrent0.html
* {igt@gem_exec_reloc@basic-concurrent16}:
- shard-skl: [FAIL][20] ([i915#1930]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-skl2/igt@gem_exec_re...@basic-concurrent16.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/shard-skl7/igt@gem_exec_re...@basic-concurrent16.html
* igt@i915_pm_rpm@system-suspend:
- shard-kbl: [FAIL][22] ([fdo#103375]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/shard-kbl2/igt@i915_p
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/11] drm/i915/gt: Start timeslice on partial submission
== Series Details == Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial submission URL : https://patchwork.freedesktop.org/series/77762/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock co
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/gt: Start timeslice on partial submission
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Start timeslice on partial
submission
URL : https://patchwork.freedesktop.org/series/77762/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dc44da7a88e6 drm/i915/gt: Start timeslice on partial submission
af3a1406b2d8 drm/i915/gem: Mark the buffer pool as active for the cmdparser
7c0380bdfab2 drm/i915/gem: Async GPU relocations only
283e921c4b08 drm/i915: Add list_for_each_entry_safe_continue_reverse
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
total: 0 errors, 0 warnings, 3 checks, 12 lines checked
fb12696a43ec drm/i915/gem: Separate reloc validation into an earlier step
-:101: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#101: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1408:
+ return (int)offset;
+ } else {
total: 0 errors, 1 warnings, 0 checks, 217 lines checked
10ad05422c96 drm/i915/gem: Lift GPU relocation allocation
c2d55803a60c drm/i915/gem: Build the reloc request first
71c20a444d9e drm/i915/gem: Add all GPU reloc awaits/signals en masse
eba65e7de8ae dma-buf: Proxy fence, an unsignaled fence placeholder
-:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#45:
new file mode 100644
-:438: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#438: FILE: drivers/dma-buf/st-dma-fence-proxy.c:20:
+ spinlock_t lock;
total: 0 errors, 1 warnings, 1 checks, 1158 lines checked
372342371047 drm/i915: Unpeel awaits on a proxy fence
70c78cfa6ea5 drm/i915/gem: Make relocations atomic within execbuf
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Start timeslice on partial submission
== Series Details == Series: drm/i915/gt: Start timeslice on partial submission URL : https://patchwork.freedesktop.org/series/77761/ State : success == Summary == CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17808 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/index.html Known issues Here are the changes found in Patchwork_17808 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@coherency: - fi-gdg-551: [PASS][1] -> [DMESG-FAIL][2] ([i915#1748]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-gdg-551/igt@i915_selftest@l...@coherency.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/fi-gdg-551/igt@i915_selftest@l...@coherency.html [i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748 Participating hosts (50 -> 43) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8549 -> Patchwork_17808 CI-20190529: 20190529 CI_DRM_8549: e50e9c6bf4efd00b02d91ff470993bbd0db94f67 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5682: e5371a99a877be134c6ad5361a5f03843a66f775 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17808: 2ea880d898ed9a9a66cfdfc5706d8f1089f8d652 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2ea880d898ed drm/i915/gt: Start timeslice on partial submission == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17808/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: build failure after merge of the drm-intel-fixes tree
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5472:
drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'live_timeslice_nopreempt':
drivers/gpu/drm/i915/gt/selftest_lrc.c:1311:3: error: too few arguments to
function 'engine_heartbeat_disable'
1311 | engine_heartbeat_disable(engine);
| ^~~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:53:13: note: declared here
53 | static void engine_heartbeat_disable(struct intel_engine_cs *engine,
| ^~~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:1380:3: error: too few arguments to
function 'engine_heartbeat_enable'
1380 | engine_heartbeat_enable(engine);
| ^~~
drivers/gpu/drm/i915/gt/selftest_lrc.c:63:13: note: declared here
63 | static void engine_heartbeat_enable(struct intel_engine_cs *engine,
| ^~~
Caused by commit
1f65efb624c4 ("drm/i915/gt: Prevent timeslicing into unpreemptable requests")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
pgpuu5ITVtIoG.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm: use drm_dev_has_vblank more (rev2)
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17798_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume:
- shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([i915#180])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl7/igt@gem_workarou...@suspend-resume.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-kbl3/igt@gem_workarou...@suspend-resume.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#1436] /
[i915#716])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl4/igt@gen9_exec_pa...@allowed-all.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109349])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-iclb4/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#1188])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl1/igt@kms_...@bpc-switch-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-skl7/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180] / [i915#93]
/ [i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#180])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-iclb4/igt@kms_psr@psr2_cursor_render.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][17] -> [FAIL][18] ([i915#31])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl2/igt@kms_setm...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl2/igt@kms_setm...@basic.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][19] ([i915#1930]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
* igt@i915_suspend@forcewake:
- shard-kbl: [DMESG-WARN][21] ([i915#180]) -> [PASS][22] +2
similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl7/igt@i915_susp...@forcewake.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-kbl3/igt@i915_susp...@forcewake.html
- shard-skl: [INCOMPLETE][23] ([i915#636] / [i915#69]) ->
[PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl5/igt@i915_susp...@forcewake.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-skl6/igt@i915_susp...@forcewake.html
* igt@kms_big_fb@linear-64bpp-rotate-180:
- shard-glk: [FAIL][25] ([i915#1119] / [i915#118] / [i915#95]) ->
[PASS][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk8/igt@kms_big..
Re: [Intel-gfx] [RFC 02/17] dma-fence: basic lockdep annotations
On 2020-05-12 4:59 a.m., Daniel Vetter wrote:
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lockdep isn't going to complain if the read-side
> isn't nested the same way under all circumstances, so ABBA deadlocks
> are ok. Which they are, since this is an annotation only.
>
> - We're using non-recursive lockdep read lock mode, since in recursive
> read lock mode lockdep does not catch read side hazards. And we
> _very_ much want read side hazards to be caught. For full details of
> this limitation see
>
> commit e91498589746065e3ae95d9a00b068e525eec34f
> Author: Peter Zijlstra
> Date: Wed Aug 23 13:13:11 2017 +0200
>
> locking/lockdep/selftests: Add mixed read-write ABBA tests
>
> - To allow nesting of the read-side explicit annotations we explicitly
> keep track of the nesting. lock_is_held() allows us to do that.
>
> - The wait-side annotation is a write lock, and entirely done within
> dma_fence_wait() for everyone by default.
>
> - To be able to freely annotate helper functions I want to make it ok
> to call dma_fence_begin/end_signalling from soft/hardirq context.
> First attempt was using the hardirq locking context for the write
> side in lockdep, but this forces all normal spinlocks nested within
> dma_fence_begin/end_signalling to be spinlocks. That bollocks.
>
> The approach now is to simple check in_atomic(), and for these cases
> entirely rely on the might_sleep() check in dma_fence_wait(). That
> will catch any wrong nesting against spinlocks from soft/hardirq
> contexts.
>
> The idea here is that every code path that's critical for eventually
> signalling a dma_fence should be annotated with
> dma_fence_begin/end_signalling. The annotation ideally starts right
> after a dma_fence is published (added to a dma_resv, exposed as a
> sync_file fd, attached to a drm_syncobj fd, or anything else that
> makes the dma_fence visible to other kernel threads), up to and
> including the dma_fence_wait(). Examples are irq handlers, the
> scheduler rt threads, the tail of execbuf (after the corresponding
> fences are visible), any workers that end up signalling dma_fences and
> really anything else. Not annotated should be code paths that only
> complete fences opportunistically as the gpu progresses, like e.g.
> shrinker/eviction code.
>
> The main class of deadlocks this is supposed to catch are:
>
> Thread A:
>
> mutex_lock(A);
> mutex_unlock(A);
>
> dma_fence_signal();
>
> Thread B:
>
> mutex_lock(A);
> dma_fence_wait();
> mutex_unlock(A);
>
> Thread B is blocked on A signalling the fence, but A never gets around
> to that because it cannot acquire the lock A.
>
> Note that dma_fence_wait() is allowed to be nested within
> dma_fence_begin/end_signalling sections. To allow this to happen the
> read lock needs to be upgraded to a write lock, which means that any
> other lock is acquired between the dma_fence_begin_signalling() call and
> the call to dma_fence_wait(), and still held, this will result in an
> immediate lockdep complaint. The only other option would be to not
> annotate such calls, defeating the point. Therefore these annotations
> cannot be sprinkled over the code entirely mindless to avoid false
> positives.
>
> v2: handle soft/hardirq ctx better against write side and dont forget
> EXPORT_SYMBOL, drivers can't use this otherwise.
>
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Cc: linux-r...@vger.kernel.org
> Cc: amd-...@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: Chris Wilson
> Cc: Maarten Lankhorst
> Cc: Christian König
> Signed-off-by: Daniel Vetter
> ---
> drivers/dma-buf/dma-fence.c | 53 +
> include/linux/dma-fence.h | 12 +
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 6802125349fb..d5c0fd2efc70 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
> }
> EXPORT_SYMBOL(dma_fence_context_alloc);
>
> +#ifdef CONFIG_LOCKDEP
> +struct lockdep_map dma_fence_lockdep_map = {
> + .name = "dma_fence_map"
> +};
> +
> +bool dma_fence_begin_signalling(void)
> +{
> + /* explicitly nesting ... */
> + if (lock_is_held_type(&dma_fence_lockdep_map, 1))
> + return true;
> +
> + /* rely on might_sleep check for soft/hardirq locks */
> + if (in_atomic())
> + return true;
> +
> + /* ... and non-recursive readlock */
> + lock_acquire(&dma_fence_lockdep_map, 0, 0, 1, 1, NULL, _RET_IP_);
> +
> + return false;
> +}
> +EXPORT_SYMBOL(dma_fence_begin_signalling);
Hi Daniel,
This is great work
[Intel-gfx] [PATCH 10/11] drm/i915: Unpeel awaits on a proxy fence
If the real target for a proxy fence is known at the time we are
attaching our awaits, use the real target in preference to hooking up to
the proxy. If use the real target instead, we can optimize the awaits,
e.g. if it along the same engine, we can order the submission and avoid
the wait-for-completion.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_request.c | 157 ++
drivers/gpu/drm/i915/i915_scheduler.c | 41 +++
drivers/gpu/drm/i915/i915_scheduler.h | 3 +
3 files changed, 201 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 0d810a62ff46..91a210234904 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include
#include
#include
@@ -413,6 +414,7 @@ static bool fatal_error(int error)
case 0: /* not an error! */
case -EAGAIN: /* innocent victim of a GT reset (__i915_request_reset) */
case -ETIMEDOUT: /* waiting for Godot (timer_i915_sw_fence_wake) */
+ case -EDEADLK: /* cyclic fence lockup (await_proxy) */
return false;
default:
return true;
@@ -1194,6 +1196,138 @@ i915_request_await_external(struct i915_request *rq,
struct dma_fence *fence)
return err;
}
+struct await_proxy {
+ struct wait_queue_entry base;
+ struct i915_request *request;
+ struct dma_fence *fence;
+ struct timer_list timer;
+ struct work_struct work;
+ int (*attach)(struct await_proxy *ap);
+ void *data;
+};
+
+static void await_proxy_work(struct work_struct *work)
+{
+ struct await_proxy *ap = container_of(work, typeof(*ap), work);
+ struct i915_request *rq = ap->request;
+
+ del_timer_sync(&ap->timer);
+
+ if (ap->fence) {
+ int err = 0;
+
+ /*
+* If the fence is external, we impose a 10s timeout.
+* However, if the fence is internal, we skip a timeout in
+* the belief that all fences are in-order (DAG, no cycles)
+* and we can enforce forward progress by reset the GPU if
+* necessary. A future fence, provided userspace, can trivially
+* generate a cycle in the dependency graph, and so cause
+* that entire cycle to become deadlocked and for no forward
+* progress to either be made, and the driver being kept
+* eternally awake.
+*/
+ if (dma_fence_is_i915(ap->fence) &&
+ !i915_sched_node_verify_dag(&rq->sched,
+ &to_request(ap->fence)->sched))
+ err = -EDEADLK;
+
+ if (!err) {
+ mutex_lock(&rq->context->timeline->mutex);
+ err = ap->attach(ap);
+ mutex_unlock(&rq->context->timeline->mutex);
+ }
+
+ /* Don't flag an error for co-dependent scheduling */
+ if (err == -EDEADLK) {
+ struct i915_sched_node *waiter =
+ &to_request(ap->fence)->sched;
+ struct i915_dependency *p;
+
+ list_for_each_entry_lockless(p,
+&rq->sched.waiters_list,
+wait_link) {
+ if (p->waiter == waiter &&
+ p->flags & I915_DEPENDENCY_WEAK) {
+ err = 0;
+ break;
+ }
+ }
+ }
+
+ if (err < 0)
+ i915_sw_fence_set_error_once(&rq->submit, err);
+ }
+
+ i915_sw_fence_complete(&rq->submit);
+
+ dma_fence_put(ap->fence);
+ kfree(ap);
+}
+
+static int
+await_proxy_wake(struct wait_queue_entry *entry,
+unsigned int mode,
+int flags,
+void *fence)
+{
+ struct await_proxy *ap = container_of(entry, typeof(*ap), base);
+
+ ap->fence = dma_fence_get(fence);
+ schedule_work(&ap->work);
+
+ return 0;
+}
+
+static void
+await_proxy_timer(struct timer_list *t)
+{
+ struct await_proxy *ap = container_of(t, typeof(*ap), timer);
+
+ if (dma_fence_remove_proxy_listener(ap->base.private, &ap->base)) {
+ struct i915_request *rq = ap->request;
+
+ pr_notice("Asynchronous wait on unset proxy fence by %s:%s:%llx
timed out\n",
+ rq->fence.ops->get_driver_name(&rq->fence),
+ rq->fence.ops->get_timeline_name(&rq->fence),
+ rq->fence.seqno);
+ i915_sw_fence_set_error_once(&rq->submit, -ETIMEDOUT)
[Intel-gfx] [PATCH 09/11] dma-buf: Proxy fence, an unsignaled fence placeholder
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real fence completes, and any future listeners will instead be
attach directly to the real fence avoiding any indirection overhead.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
---
drivers/dma-buf/Makefile | 13 +-
drivers/dma-buf/dma-fence-private.h | 20 +
drivers/dma-buf/dma-fence-proxy.c| 306 +++
drivers/dma-buf/dma-fence.c | 4 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-proxy.c | 752 +++
include/linux/dma-fence-proxy.h | 38 ++
7 files changed, 1130 insertions(+), 4 deletions(-)
create mode 100644 drivers/dma-buf/dma-fence-private.h
create mode 100644 drivers/dma-buf/dma-fence-proxy.c
create mode 100644 drivers/dma-buf/st-dma-fence-proxy.c
create mode 100644 include/linux/dma-fence-proxy.h
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 995e05f609ff..afaf6dadd9a3 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,6 +1,12 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
-dma-resv.o seqno-fence.o
+obj-y := \
+ dma-buf.o \
+ dma-fence.o \
+ dma-fence-array.o \
+ dma-fence-chain.o \
+ dma-fence-proxy.o \
+ dma-resv.o \
+ seqno-fence.o
obj-$(CONFIG_DMABUF_HEAPS) += dma-heap.o
obj-$(CONFIG_DMABUF_HEAPS) += heaps/
obj-$(CONFIG_SYNC_FILE)+= sync_file.o
@@ -10,6 +16,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
dmabuf_selftests-y := \
selftest.o \
st-dma-fence.o \
- st-dma-fence-chain.o
+ st-dma-fence-chain.o \
+ st-dma-fence-proxy.o
obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/dma-fence-private.h
b/drivers/dma-buf/dma-fence-private.h
new file mode 100644
index ..6924d28af0fa
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-private.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Fence mechanism for dma-buf and to allow for asynchronous dma access
+ *
+ * Copyright (C) 2012 Canonical Ltd
+ * Copyright (C) 2012 Texas Instruments
+ *
+ * Authors:
+ * Rob Clark
+ * Maarten Lankhorst
+ */
+
+#ifndef DMA_FENCE_PRIVATE_H
+#define DMA_FENCE_PRIAVTE_H
+
+struct dma_fence;
+
+bool __dma_fence_enable_signaling(struct dma_fence *fence);
+
+#endif /* DMA_FENCE_PRIAVTE_H */
diff --git a/drivers/dma-buf/dma-fence-proxy.c
b/drivers/dma-buf/dma-fence-proxy.c
new file mode 100644
index ..42674e92b0f9
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-proxy.c
@@ -0,0 +1,306 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * dma-fence-proxy: placeholder unsignaled fence
+ *
+ * Copyright (C) 2017-2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "dma-fence-private.h"
+
+struct dma_fence_proxy {
+ struct dma_fence base;
+
+ struct dma_fence *real;
+ struct dma_fence_cb cb;
+ struct irq_work work;
+
+ wait_queue_head_t wq;
+};
+
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+#define same_lockclass(A, B) (A)->dep_map.key == (B)->dep_map.key
+#else
+#define same_lockclass(A, B) 0
+#endif
+
+static const char *proxy_get_driver_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_driver_name(real) : "proxy";
+}
+
+static const char *proxy_get_timeline_name(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
+ return real ? real->ops->get_timeline_name(real) : "unset";
+}
+
+static void proxy_irq_work(struct irq_work *work)
+{
+ struct dma_fence_proxy *p = container_of(work, typeof(*p), work);
+
+ dma_fence_signal(&p->base);
+ dma_fence_put(&p->base);
+}
+
+static void proxy_callback(struct dma_fence *real, struct dma_fence_cb *cb)
+{
+ struct dma_fence_proxy *p = container_of(cb, typeof(*p), cb);
+
+ /* Signaled before enabling signalling callbacks? */
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &p->base.flags)) {
+ dma_fence_put(&p->base);
+ return;
+ }
+
+ if (real->error)
+ dma_fence_set_error(&p->base, real->error);
+
+ /* Lower the height of the proxy chain -> single stack frame */
+ irq_work_queue(&p->work);
+}
+
+static bool proxy_enable_signaling(struct dma_fence *fence)
+{
+ struct dma_fence_proxy *p = container_of(fence, typeof(*p), base);
+ struct dma_fence *real = READ_ONCE(p->real);
+
[Intel-gfx] [PATCH 07/11] drm/i915/gem: Build the reloc request first
If we get interrupted in the middle of chaining up the relocation
entries, we will fail to submit the relocation batch. However, we will
report having already completed some of the relocations, and so the
reloc.presumed_offset will no longer match the batch contents, causing
confusion and invalid future batches. If we build the relocation request
packet first, we can always emit as far as we get up in the relocation
chain.
Fixes: 0e97fbb08055 ("drm/i915/gem: Use a single chained reloc batches for a
single execbuf")
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 51 ++-
.../i915/gem/selftests/i915_gem_execbuffer.c | 8 +--
2 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9537fd87e3a4..c48950d7f1c9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1021,11 +1021,27 @@ static unsigned int reloc_bb_flags(const struct
reloc_cache *cache)
return cache->gen > 5 ? 0 : I915_DISPATCH_SECURE;
}
-static int reloc_gpu_flush(struct reloc_cache *cache)
+static int reloc_gpu_emit(struct reloc_cache *cache)
{
struct i915_request *rq = cache->rq;
int err;
+ err = 0;
+ if (rq->engine->emit_init_breadcrumb)
+ err = rq->engine->emit_init_breadcrumb(rq);
+ if (!err)
+ err = rq->engine->emit_bb_start(rq,
+ rq->batch->node.start,
+ PAGE_SIZE,
+ reloc_bb_flags(cache));
+
+ return err;
+}
+
+static void reloc_gpu_flush(struct reloc_cache *cache)
+{
+ struct i915_request *rq = cache->rq;
+
if (cache->rq_vma) {
struct drm_i915_gem_object *obj = cache->rq_vma->obj;
@@ -1037,21 +1053,8 @@ static int reloc_gpu_flush(struct reloc_cache *cache)
i915_gem_object_unpin_map(obj);
}
- err = 0;
- if (rq->engine->emit_init_breadcrumb)
- err = rq->engine->emit_init_breadcrumb(rq);
- if (!err)
- err = rq->engine->emit_bb_start(rq,
- rq->batch->node.start,
- PAGE_SIZE,
- reloc_bb_flags(cache));
- if (err)
- i915_request_set_error_once(rq, err);
-
intel_gt_chipset_flush(rq->engine->gt);
i915_request_add(rq);
-
- return err;
}
static int reloc_move_to_gpu(struct i915_request *rq, struct i915_vma *vma)
@@ -1139,7 +1142,7 @@ __reloc_gpu_alloc(struct i915_execbuffer *eb, struct
intel_engine_cs *engine)
err = i915_vma_move_to_active(batch, rq, 0);
i915_vma_unlock(batch);
if (err)
- goto skip_request;
+ goto err_request;
rq->batch = batch;
i915_vma_unpin(batch);
@@ -1152,8 +1155,6 @@ __reloc_gpu_alloc(struct i915_execbuffer *eb, struct
intel_engine_cs *engine)
/* Return with batch mapping (cmd) still pinned */
goto out_pool;
-skip_request:
- i915_request_set_error_once(rq, err);
err_request:
i915_request_add(rq);
err_unpin:
@@ -1186,10 +1187,8 @@ static u32 *reloc_batch_grow(struct i915_execbuffer *eb,
if (unlikely(cache->rq_size + len >
PAGE_SIZE / sizeof(u32) - RELOC_TAIL)) {
err = reloc_gpu_chain(cache);
- if (unlikely(err)) {
- i915_request_set_error_once(cache->rq, err);
+ if (unlikely(err))
return ERR_PTR(err);
- }
}
GEM_BUG_ON(cache->rq_size + len >= PAGE_SIZE / sizeof(u32));
@@ -1571,23 +1570,25 @@ static int reloc_gpu_alloc(struct i915_execbuffer *eb)
static int reloc_gpu(struct i915_execbuffer *eb)
{
struct eb_vma *ev;
- int flush, err;
+ int err;
err = reloc_gpu_alloc(eb);
if (err)
return err;
GEM_BUG_ON(!eb->reloc_cache.rq);
+ err = reloc_gpu_emit(&eb->reloc_cache);
+ if (err)
+ goto out;
+
list_for_each_entry(ev, &eb->relocs, reloc_link) {
err = eb_relocate_vma(eb, ev);
if (err)
- goto out;
+ break;
}
out:
- flush = reloc_gpu_flush(&eb->reloc_cache);
- if (!err)
- err = flush;
+ reloc_gpu_flush(&eb->reloc_cache);
return err;
}
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
index 50fe22d87ae1..faed6480a792 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c
@@ -
[Intel-gfx] [PATCH 08/11] drm/i915/gem: Add all GPU reloc awaits/signals en masse
Asynchronous waits and signaling form a traditional semaphore with all
the usual ordering problems with taking multiple locks. If we want to
add more than one wait on a shared resource by the GPU, we must ensure
that all the associated timelines are advanced atomically, ergo we must
lock all the timelines en masse.
Testcase: igt/gem_exec_reloc/basic-concurrent16
Fixes: 0e97fbb08055 ("drm/i915/gem: Use a single chained reloc batches for a
single execbuf")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1889
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 114 --
.../i915/gem/selftests/i915_gem_execbuffer.c | 24 ++--
2 files changed, 93 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index c48950d7f1c9..37855ae8f8b3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -259,7 +259,6 @@ struct i915_execbuffer {
bool has_fence : 1;
bool needs_unfenced : 1;
- struct i915_vma *target;
struct i915_request *rq;
struct i915_vma *rq_vma;
u32 *rq_cmd;
@@ -924,7 +923,6 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->has_fence = cache->gen < 4;
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
- cache->target = NULL;
}
static inline void *unmask_page(unsigned long p)
@@ -1057,26 +1055,6 @@ static void reloc_gpu_flush(struct reloc_cache *cache)
i915_request_add(rq);
}
-static int reloc_move_to_gpu(struct i915_request *rq, struct i915_vma *vma)
-{
- struct drm_i915_gem_object *obj = vma->obj;
- int err;
-
- i915_vma_lock(vma);
-
- if (obj->cache_dirty & ~obj->cache_coherent)
- i915_gem_clflush_object(obj, 0);
- obj->write_domain = 0;
-
- err = i915_request_await_object(rq, vma->obj, true);
- if (err == 0)
- err = i915_vma_move_to_active(vma, rq, EXEC_OBJECT_WRITE);
-
- i915_vma_unlock(vma);
-
- return err;
-}
-
static int
__reloc_gpu_alloc(struct i915_execbuffer *eb, struct intel_engine_cs *engine)
{
@@ -1166,24 +1144,12 @@ __reloc_gpu_alloc(struct i915_execbuffer *eb, struct
intel_engine_cs *engine)
return err;
}
-static u32 *reloc_batch_grow(struct i915_execbuffer *eb,
-struct i915_vma *vma,
-unsigned int len)
+static u32 *reloc_batch_grow(struct i915_execbuffer *eb, unsigned int len)
{
struct reloc_cache *cache = &eb->reloc_cache;
u32 *cmd;
int err;
- if (vma != cache->target) {
- err = reloc_move_to_gpu(cache->rq, vma);
- if (unlikely(err)) {
- i915_request_set_error_once(cache->rq, err);
- return ERR_PTR(err);
- }
-
- cache->target = vma;
- }
-
if (unlikely(cache->rq_size + len >
PAGE_SIZE / sizeof(u32) - RELOC_TAIL)) {
err = reloc_gpu_chain(cache);
@@ -1229,7 +1195,7 @@ static int __reloc_entry_gpu(struct i915_execbuffer *eb,
else
len = 3;
- batch = reloc_batch_grow(eb, vma, len);
+ batch = reloc_batch_grow(eb, len);
if (IS_ERR(batch))
return PTR_ERR(batch);
@@ -1549,6 +1515,78 @@ static long eb_reloc_vma_validate(struct i915_execbuffer
*eb, struct eb_vma *ev)
return required;
}
+static int reloc_move_to_gpu(struct reloc_cache *cache, struct eb_vma *ev)
+{
+ struct i915_request *rq = cache->rq;
+ struct i915_vma *vma = ev->vma;
+ struct drm_i915_gem_object *obj = vma->obj;
+ int err;
+
+ if (obj->cache_dirty & ~obj->cache_coherent)
+ i915_gem_clflush_object(obj, 0);
+
+ obj->write_domain = I915_GEM_DOMAIN_RENDER;
+ obj->read_domains = I915_GEM_DOMAIN_RENDER;
+
+ err = i915_request_await_object(rq, obj, true);
+ if (err)
+ return err;
+
+ err = __i915_vma_move_to_active(vma, rq);
+ if (err)
+ return err;
+
+ dma_resv_add_excl_fence(vma->resv, &rq->fence);
+
+ return 0;
+}
+
+static int
+lock_relocs(struct i915_execbuffer *eb)
+{
+ struct ww_acquire_ctx acquire;
+ struct eb_vma *ev;
+ int err = 0;
+
+ ww_acquire_init(&acquire, &reservation_ww_class);
+
+ list_for_each_entry(ev, &eb->relocs, reloc_link) {
+ struct i915_vma *vma = ev->vma;
+
+ err = ww_mutex_lock_interruptible(&vma->resv->lock, &acquire);
+ if (err == -EDEADLK) {
+ struct eb_vma *unlock = ev, *en;
+
+ list_for_each_entry_safe_continue_reverse(unlock, en,
+
[Intel-gfx] [PATCH 06/11] drm/i915/gem: Lift GPU relocation allocation
Since we have reduced the relocations paths to just use the async GPU,
we can lift the request allocation to the start of the relocations.
Knowing that we use one request for all relocations will simplify
tracking the relocation fence.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 98 ++-
.../i915/gem/selftests/i915_gem_execbuffer.c | 5 +-
2 files changed, 56 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index bed7c7ea2723..9537fd87e3a4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -900,8 +900,6 @@ eb_get_vma(const struct i915_execbuffer *eb, unsigned long
handle)
static void eb_destroy(const struct i915_execbuffer *eb)
{
- GEM_BUG_ON(eb->reloc_cache.rq);
-
if (eb->array)
eb_vma_array_put(eb->array);
@@ -926,7 +924,6 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->has_fence = cache->gen < 4;
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
- cache->rq = NULL;
cache->target = NULL;
}
@@ -1026,13 +1023,9 @@ static unsigned int reloc_bb_flags(const struct
reloc_cache *cache)
static int reloc_gpu_flush(struct reloc_cache *cache)
{
- struct i915_request *rq;
+ struct i915_request *rq = cache->rq;
int err;
- rq = fetch_and_zero(&cache->rq);
- if (!rq)
- return 0;
-
if (cache->rq_vma) {
struct drm_i915_gem_object *obj = cache->rq_vma->obj;
@@ -1081,9 +1074,8 @@ static int reloc_move_to_gpu(struct i915_request *rq,
struct i915_vma *vma)
return err;
}
-static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
-struct intel_engine_cs *engine,
-unsigned int len)
+static int
+__reloc_gpu_alloc(struct i915_execbuffer *eb, struct intel_engine_cs *engine)
{
struct reloc_cache *cache = &eb->reloc_cache;
struct intel_gt_buffer_pool_node *pool;
@@ -1173,33 +1165,14 @@ static int __reloc_gpu_alloc(struct i915_execbuffer *eb,
return err;
}
-static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
-{
- return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
-}
-
-static u32 *reloc_gpu(struct i915_execbuffer *eb,
- struct i915_vma *vma,
- unsigned int len)
+static u32 *reloc_batch_grow(struct i915_execbuffer *eb,
+struct i915_vma *vma,
+unsigned int len)
{
struct reloc_cache *cache = &eb->reloc_cache;
u32 *cmd;
int err;
- if (unlikely(!cache->rq)) {
- struct intel_engine_cs *engine = eb->engine;
-
- if (!reloc_can_use_engine(engine)) {
- engine = engine->gt->engine_class[COPY_ENGINE_CLASS][0];
- if (!engine)
- return ERR_PTR(-ENODEV);
- }
-
- err = __reloc_gpu_alloc(eb, engine, len);
- if (unlikely(err))
- return ERR_PTR(err);
- }
-
if (vma != cache->target) {
err = reloc_move_to_gpu(cache->rq, vma);
if (unlikely(err)) {
@@ -1257,7 +1230,7 @@ static int __reloc_entry_gpu(struct i915_execbuffer *eb,
else
len = 3;
- batch = reloc_gpu(eb, vma, len);
+ batch = reloc_batch_grow(eb, vma, len);
if (IS_ERR(batch))
return PTR_ERR(batch);
@@ -1577,6 +1550,47 @@ static long eb_reloc_vma_validate(struct i915_execbuffer
*eb, struct eb_vma *ev)
return required;
}
+static bool reloc_can_use_engine(const struct intel_engine_cs *engine)
+{
+ return engine->class != VIDEO_DECODE_CLASS || !IS_GEN(engine->i915, 6);
+}
+
+static int reloc_gpu_alloc(struct i915_execbuffer *eb)
+{
+ struct intel_engine_cs *engine = eb->engine;
+
+ if (!reloc_can_use_engine(engine)) {
+ engine = engine->gt->engine_class[COPY_ENGINE_CLASS][0];
+ if (!engine)
+ return -ENODEV;
+ }
+
+ return __reloc_gpu_alloc(eb, engine);
+}
+
+static int reloc_gpu(struct i915_execbuffer *eb)
+{
+ struct eb_vma *ev;
+ int flush, err;
+
+ err = reloc_gpu_alloc(eb);
+ if (err)
+ return err;
+ GEM_BUG_ON(!eb->reloc_cache.rq);
+
+ list_for_each_entry(ev, &eb->relocs, reloc_link) {
+ err = eb_relocate_vma(eb, ev);
+ if (err)
+ goto out;
+ }
+
+out:
+ flush = reloc_gpu_flush(&eb->reloc_cache);
+ if (!err)
+ err = flush;
+ return err;
+}
+
static int eb_relocate(struct i915_execbuffer *eb)
{
int err;
@
[Intel-gfx] [PATCH 02/11] drm/i915/gem: Mark the buffer pool as active for the cmdparser
If the execbuf is interrupted after building the cmdparser pipeline, and
before we commit to submitting the request to HW, we would attempt to
clean up the cmdparser early. While we held active references to the vma
being parsed and constructed, we did not hold an active reference for
the buffer pool itself. The result was that an interrupted execbuf could
still have run the cmdparser pipeline, but since the buffer pool was
idle, its target vma could have been recycled.
Note this problem only occurs if the cmdparser is running async due to
pipelined waits on busy fences, and the execbuf is interrupted.
Fixes: 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser")
Fixes: 16e87459673a ("drm/i915/gt: Move the batch buffer pool from the engine
to the gt")
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 56 ---
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 219a36995b96..0829ac8a55bf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1987,6 +1987,38 @@ static const struct dma_fence_work_ops eb_parse_ops = {
.release = __eb_parse_release,
};
+static inline int
+__parser_mark_active(struct i915_vma *vma,
+struct intel_timeline *tl,
+struct dma_fence *fence)
+{
+ struct intel_gt_buffer_pool_node *node = vma->private;
+
+ return i915_active_ref(&node->active, tl, fence);
+}
+
+static int
+parser_mark_active(struct eb_parse_work *pw, struct intel_timeline *tl)
+{
+ int err;
+
+ mutex_lock(&tl->mutex);
+
+ err = __parser_mark_active(pw->shadow, tl, &pw->base.dma);
+ if (err)
+ goto unlock;
+
+ if (pw->trampoline) {
+ err = __parser_mark_active(pw->trampoline, tl, &pw->base.dma);
+ if (err)
+ goto unlock;
+ }
+
+unlock:
+ mutex_unlock(&tl->mutex);
+ return err;
+}
+
static int eb_parse_pipeline(struct i915_execbuffer *eb,
struct i915_vma *shadow,
struct i915_vma *trampoline)
@@ -2021,20 +2053,25 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
pw->shadow = shadow;
pw->trampoline = trampoline;
+ /* Mark active refs for this worker, in case we get interrupted */
+ err = parser_mark_active(pw, eb->context->timeline);
+ if (err)
+ goto err_commit;
+
err = dma_resv_lock_interruptible(pw->batch->resv, NULL);
if (err)
- goto err_trampoline;
+ goto err_commit;
err = dma_resv_reserve_shared(pw->batch->resv, 1);
if (err)
- goto err_batch_unlock;
+ goto err_commit_unlock;
/* Wait for all writes (and relocs) into the batch to complete */
err = i915_sw_fence_await_reservation(&pw->base.chain,
pw->batch->resv, NULL, false,
0, I915_FENCE_GFP);
if (err < 0)
- goto err_batch_unlock;
+ goto err_commit_unlock;
/* Keep the batch alive and unwritten as we parse */
dma_resv_add_shared_fence(pw->batch->resv, &pw->base.dma);
@@ -2049,11 +2086,13 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
dma_fence_work_commit_imm(&pw->base);
return 0;
-err_batch_unlock:
+err_commit_unlock:
dma_resv_unlock(pw->batch->resv);
-err_trampoline:
- if (trampoline)
- i915_active_release(&trampoline->active);
+err_commit:
+ i915_sw_fence_set_error_once(&pw->base.chain, err);
+ dma_fence_work_commit_imm(&pw->base);
+ return err;
+
err_shadow:
i915_active_release(&shadow->active);
err_batch:
@@ -2099,6 +2138,7 @@ static int eb_parse(struct i915_execbuffer *eb)
goto err;
}
i915_gem_object_set_readonly(shadow->obj);
+ shadow->private = pool;
trampoline = NULL;
if (CMDPARSER_USES_GGTT(eb->i915)) {
@@ -2112,6 +2152,7 @@ static int eb_parse(struct i915_execbuffer *eb)
shadow = trampoline;
goto err_shadow;
}
+ shadow->private = pool;
eb->batch_flags |= I915_DISPATCH_SECURE;
}
@@ -2128,7 +2169,6 @@ static int eb_parse(struct i915_execbuffer *eb)
eb->trampoline = trampoline;
eb->batch_start_offset = 0;
- shadow->private = pool;
return 0;
err_trampoline:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm/i915/gt: Start timeslice on partial submission
We may choose to only submit ELSP[0], even though we have sufficient
requests to fill the whole ELSP. Normally, we only start timeslicing if
we fill more than one port, but in this case we need to start
timeslicing for the queue that we choose not to submit.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 69fff36ec0cc..6fc0966b75ff 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2358,8 +2358,10 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (last->context == rq->context)
goto done;
- if (i915_request_has_sentinel(last))
+ if (i915_request_has_sentinel(last)) {
+ start_timeslice(engine, rq_prio(rq));
goto done;
+ }
/*
* If GVT overrides us we only ever submit
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915/gem: Make relocations atomic within execbuf
Although we may chide userspace for reusing the same batches
concurrently from multiple threads, at the same time we must be very
careful to only execute the batch and its relocations as supplied by the
user. If we are not careful, we may allow another thread to rewrite the
current batch with its own relocations. We must order the relocations
and their batch such that they are an atomic pair on the GPU, and that
the ioctl itself appears atomic to userspace. The order of execution may
be undetermined, but it will not be subverted.
We could do this by moving the relocations into the main request, if it
were not for the situation where we need a second engine to perform the
relocations for us. Instead, we use the dependency tracking to only
publish the write fence on the main request and not on the relocation
request, so that concurrent updates are queued after the batch has
consumed its relocations.
Testcase: igt/gem_exec_reloc/basic-concurrent
Fixes: ef398881d27d ("drm/i915/gem: Limit struct_mutex to eb_reserve")
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 92 ++-
.../i915/gem/selftests/i915_gem_execbuffer.c | 11 ++-
2 files changed, 73 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 37855ae8f8b3..2844274c37bb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -5,6 +5,7 @@
*/
#include
+#include
#include
#include
#include
@@ -259,6 +260,8 @@ struct i915_execbuffer {
bool has_fence : 1;
bool needs_unfenced : 1;
+ struct dma_fence *fence;
+
struct i915_request *rq;
struct i915_vma *rq_vma;
u32 *rq_cmd;
@@ -555,16 +558,6 @@ eb_add_vma(struct i915_execbuffer *eb,
ev->exec = entry;
ev->flags = entry->flags;
- if (eb->lut_size > 0) {
- ev->handle = entry->handle;
- hlist_add_head(&ev->node,
- &eb->buckets[hash_32(entry->handle,
- eb->lut_size)]);
- }
-
- if (entry->relocation_count)
- list_add_tail(&ev->reloc_link, &eb->relocs);
-
/*
* SNA is doing fancy tricks with compressing batch buffers, which leads
* to negative relocation deltas. Usually that works out ok since the
@@ -581,9 +574,21 @@ eb_add_vma(struct i915_execbuffer *eb,
if (eb->reloc_cache.has_fence)
ev->flags |= EXEC_OBJECT_NEEDS_FENCE;
+ INIT_LIST_HEAD(&ev->reloc_link);
+
eb->batch = ev;
}
+ if (entry->relocation_count)
+ list_add_tail(&ev->reloc_link, &eb->relocs);
+
+ if (eb->lut_size > 0) {
+ ev->handle = entry->handle;
+ hlist_add_head(&ev->node,
+ &eb->buckets[hash_32(entry->handle,
+ eb->lut_size)]);
+ }
+
if (eb_pin_vma(eb, entry, ev)) {
if (entry->offset != vma->node.start) {
entry->offset = vma->node.start | UPDATE;
@@ -923,6 +928,7 @@ static void reloc_cache_init(struct reloc_cache *cache,
cache->has_fence = cache->gen < 4;
cache->needs_unfenced = INTEL_INFO(i915)->unfenced_needs_alignment;
cache->node.flags = 0;
+ cache->fence = NULL;
}
static inline void *unmask_page(unsigned long p)
@@ -1052,6 +1058,7 @@ static void reloc_gpu_flush(struct reloc_cache *cache)
}
intel_gt_chipset_flush(rq->engine->gt);
+ i915_request_get(rq);
i915_request_add(rq);
}
@@ -1284,16 +1291,6 @@ eb_relocate_entry(struct i915_execbuffer *eb,
if (gen8_canonical_addr(target->vma->node.start) ==
reloc->presumed_offset)
return 0;
- /*
-* If we write into the object, we need to force the synchronisation
-* barrier, either with an asynchronous clflush or if we executed the
-* patching using the GPU (though that should be serialised by the
-* timeline). To be completely sure, and since we are required to
-* do relocations we are already stalling, disable the user's opt
-* out of our synchronisation.
-*/
- ev->flags &= ~EXEC_OBJECT_ASYNC;
-
/* and update the user's relocation entry */
return relocate_entry(eb, ev->vma, reloc, target->vma);
}
@@ -1527,6 +1524,11 @@ static int reloc_move_to_gpu(struct reloc_cache *cache,
struct eb_vma *ev)
obj->write_domain = I915_GEM_DOMAIN_RENDER;
obj->read_domains = I915_GEM_DOMAIN_RENDER;
+ ev->flags |= EXEC_OBJECT_ASYNC;
+
+ err = dma_resv_reserve_shared(vma->resv, 1);
+ if (err)
+ return err;
err = i915_request_await_object(rq, ob
[Intel-gfx] [PATCH 05/11] drm/i915/gem: Separate reloc validation into an earlier step
Over the next couple of patches, we will want to lock all the modified
vma for relocation processing under a single ww_mutex. We neither want
to have to include the vma that are skipped (due to no modifications
required) nor do we want those to be marked as written too. So separate
out the reloc validation into an early step, which we can use both to
reject the execbuf before committing to making our changes, and to
filter out the unmodified vma.
This does introduce a second pass through the reloc[], but only if we
need to emit relocations.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 178 +-
1 file changed, 133 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 540188454b6d..bed7c7ea2723 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1331,6 +1331,117 @@ static u64
eb_relocate_entry(struct i915_execbuffer *eb,
struct eb_vma *ev,
const struct drm_i915_gem_relocation_entry *reloc)
+{
+ struct eb_vma *target;
+
+ /* we've already hold a reference to all valid objects */
+ target = eb_get_vma(eb, reloc->target_handle);
+ if (unlikely(!target))
+ return -ENOENT;
+
+ /*
+* If the relocation already has the right value in it, no
+* more work needs to be done.
+*/
+ if (gen8_canonical_addr(target->vma->node.start) ==
reloc->presumed_offset)
+ return 0;
+
+ /*
+* If we write into the object, we need to force the synchronisation
+* barrier, either with an asynchronous clflush or if we executed the
+* patching using the GPU (though that should be serialised by the
+* timeline). To be completely sure, and since we are required to
+* do relocations we are already stalling, disable the user's opt
+* out of our synchronisation.
+*/
+ ev->flags &= ~EXEC_OBJECT_ASYNC;
+
+ /* and update the user's relocation entry */
+ return relocate_entry(eb, ev->vma, reloc, target->vma);
+}
+
+static int eb_relocate_vma(struct i915_execbuffer *eb, struct eb_vma *ev)
+{
+#define N_RELOC(x) ((x) / sizeof(struct drm_i915_gem_relocation_entry))
+ struct drm_i915_gem_relocation_entry stack[N_RELOC(512)];
+ const struct drm_i915_gem_exec_object2 *entry = ev->exec;
+ struct drm_i915_gem_relocation_entry __user *urelocs =
+ u64_to_user_ptr(entry->relocs_ptr);
+ unsigned long remain = entry->relocation_count;
+
+ if (unlikely(remain > N_RELOC(ULONG_MAX)))
+ return -EINVAL;
+
+ /*
+* We must check that the entire relocation array is safe
+* to read. However, if the array is not writable the user loses
+* the updated relocation values.
+*/
+ if (unlikely(!access_ok(urelocs, remain * sizeof(*urelocs
+ return -EFAULT;
+
+ do {
+ struct drm_i915_gem_relocation_entry *r = stack;
+ unsigned int count =
+ min_t(unsigned long, remain, ARRAY_SIZE(stack));
+ unsigned int copied;
+
+ /*
+* This is the fast path and we cannot handle a pagefault
+* whilst holding the struct mutex lest the user pass in the
+* relocations contained within a mmaped bo. For in such a case
+* we, the page fault handler would call i915_gem_fault() and
+* we would try to acquire the struct mutex again. Obviously
+* this is bad and so lockdep complains vehemently.
+*/
+ copied = __copy_from_user(r, urelocs, count * sizeof(r[0]));
+ if (unlikely(copied))
+ return -EFAULT;
+
+ remain -= count;
+ do {
+ u64 offset = eb_relocate_entry(eb, ev, r);
+
+ if (likely(offset == 0)) {
+ } else if ((s64)offset < 0) {
+ return (int)offset;
+ } else {
+ /*
+* Note that reporting an error now
+* leaves everything in an inconsistent
+* state as we have *already* changed
+* the relocation value inside the
+* object. As we have not changed the
+* reloc.presumed_offset or will not
+* change the execobject.offset, on the
+* call we may not rewrite the value
+* inside the object, leaving it
+* dangling and causing a GPU hang. Unless
+
[Intel-gfx] [PATCH 03/11] drm/i915/gem: Async GPU relocations only
Reduce the 3 relocation patches down to the single path that accommodates
all. The primary motivation for this is to guard the relocations with a
natural fence (derived from the i915_request used to write the
relocation from the GPU).
The tradeoff in using async gpu relocations is that it increases latency
over using direct CPU relocations, for the cases where the target is
idle and accessible by the CPU. The benefit is greatly reduced lock
contention and improved concurrency by pipelining.
Note that forcing the async gpu relocations does reveal a few issues
they have. Firstly, is that they are visible as writes to gem_busy,
causing to mark some buffers are being to written to by the GPU even
though userspace only reads. Secondly is that, in combination with the
cmdparser, they can cause priority inversions. This should be the case
where the work is being put into a common workqueue losing our priority
information and so being executed in FIFO from the worker, denying us
the opportunity to reorder the requests afterwards.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 295 ++
.../i915/gem/selftests/i915_gem_execbuffer.c | 21 +-
2 files changed, 27 insertions(+), 289 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 0829ac8a55bf..540188454b6d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -45,13 +45,6 @@ struct eb_vma_array {
struct eb_vma vma[];
};
-enum {
- FORCE_CPU_RELOC = 1,
- FORCE_GTT_RELOC,
- FORCE_GPU_RELOC,
-#define DBG_FORCE_RELOC 0 /* choose one of the above! */
-};
-
#define __EXEC_OBJECT_HAS_PIN BIT(31)
#define __EXEC_OBJECT_HAS_FENCEBIT(30)
#define __EXEC_OBJECT_NEEDS_MAPBIT(29)
@@ -260,8 +253,6 @@ struct i915_execbuffer {
*/
struct reloc_cache {
struct drm_mm_node node; /** temporary GTT binding */
- unsigned long vaddr; /** Current kmap address */
- unsigned long page; /** Currently mapped page index */
unsigned int gen; /** Cached value of INTEL_GEN */
bool use_64bit_reloc : 1;
bool has_llc : 1;
@@ -605,23 +596,6 @@ eb_add_vma(struct i915_execbuffer *eb,
}
}
-static inline int use_cpu_reloc(const struct reloc_cache *cache,
- const struct drm_i915_gem_object *obj)
-{
- if (!i915_gem_object_has_struct_page(obj))
- return false;
-
- if (DBG_FORCE_RELOC == FORCE_CPU_RELOC)
- return true;
-
- if (DBG_FORCE_RELOC == FORCE_GTT_RELOC)
- return false;
-
- return (cache->has_llc ||
- obj->cache_dirty ||
- obj->cache_level != I915_CACHE_NONE);
-}
-
static int eb_reserve_vma(const struct i915_execbuffer *eb,
struct eb_vma *ev,
u64 pin_flags)
@@ -945,8 +919,6 @@ relocation_target(const struct
drm_i915_gem_relocation_entry *reloc,
static void reloc_cache_init(struct reloc_cache *cache,
struct drm_i915_private *i915)
{
- cache->page = -1;
- cache->vaddr = 0;
/* Must be a variable in the struct to allow GCC to unroll. */
cache->gen = INTEL_GEN(i915);
cache->has_llc = HAS_LLC(i915);
@@ -1089,181 +1061,6 @@ static int reloc_gpu_flush(struct reloc_cache *cache)
return err;
}
-static void reloc_cache_reset(struct reloc_cache *cache)
-{
- void *vaddr;
-
- if (!cache->vaddr)
- return;
-
- vaddr = unmask_page(cache->vaddr);
- if (cache->vaddr & KMAP) {
- if (cache->vaddr & CLFLUSH_AFTER)
- mb();
-
- kunmap_atomic(vaddr);
- i915_gem_object_finish_access((struct drm_i915_gem_object
*)cache->node.mm);
- } else {
- struct i915_ggtt *ggtt = cache_to_ggtt(cache);
-
- intel_gt_flush_ggtt_writes(ggtt->vm.gt);
- io_mapping_unmap_atomic((void __iomem *)vaddr);
-
- if (drm_mm_node_allocated(&cache->node)) {
- ggtt->vm.clear_range(&ggtt->vm,
-cache->node.start,
-cache->node.size);
- mutex_lock(&ggtt->vm.mutex);
- drm_mm_remove_node(&cache->node);
- mutex_unlock(&ggtt->vm.mutex);
- } else {
- i915_vma_unpin((struct i915_vma *)cache->node.mm);
- }
- }
-
- cache->vaddr = 0;
- cache->page = -1;
-}
-
-static void *reloc_kmap(struct drm_i915_gem_object *obj,
- struct reloc_cache *cache,
- unsigned long page)
-{
- void *vaddr;
-
- i
[Intel-gfx] [PATCH 04/11] drm/i915: Add list_for_each_entry_safe_continue_reverse
One more list iterator variant, for when we want to unwind from inside one list iterator with the intention of restarting from the current entry as the new head of the list. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_utils.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h index 03a73d2bd50d..6ebccdd12d4c 100644 --- a/drivers/gpu/drm/i915/i915_utils.h +++ b/drivers/gpu/drm/i915/i915_utils.h @@ -266,6 +266,12 @@ static inline int list_is_last_rcu(const struct list_head *list, return READ_ONCE(list->next) == head; } +#define list_for_each_entry_safe_continue_reverse(pos, n, head, member) \ + for (pos = list_prev_entry(pos, member),\ +n = list_prev_entry(pos, member); \ +&pos->member != (head);\ +pos = n, n = list_prev_entry(n, member)) + /* * Wait until the work is finally complete, even if it tries to postpone * by requeueing itself. Note, that if the worker never cancels itself, -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Start timeslice on partial submission
Chris Wilson writes:
> We may choose to only submit ELSP[0], even though we have sufficient
> requests to fill the whole ELSP. Normally, we only start timeslicing if
> we fill more than one port, but in this case we need to start
> timeslicing for the queue that we choose not to submit.
If this is last in a line, it makes sense to make sure
that we get woken up.
Reviewed-by: Mika Kuoppala
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 69fff36ec0cc..6fc0966b75ff 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -2358,8 +2358,10 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> if (last->context == rq->context)
> goto done;
>
> - if (i915_request_has_sentinel(last))
> + if (i915_request_has_sentinel(last)) {
> + start_timeslice(engine, rq_prio(rq));
> goto done;
> + }
>
> /*
>* If GVT overrides us we only ever submit
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Start timeslice on partial submission
We may choose to only submit ELSP[0], even though we have sufficient
requests to fill the whole ELSP. Normally, we only start timeslicing if
we fill more than one port, but in this case we need to start
timeslicing for the queue that we choose not to submit.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 69fff36ec0cc..6fc0966b75ff 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2358,8 +2358,10 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (last->context == rq->context)
goto done;
- if (i915_request_has_sentinel(last))
+ if (i915_request_has_sentinel(last)) {
+ start_timeslice(engine, rq_prio(rq));
goto done;
+ }
/*
* If GVT overrides us we only ever submit
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Special handling for bonded requests (rev2)
== Series Details == Series: drm/i915: Special handling for bonded requests (rev2) URL : https://patchwork.freedesktop.org/series/77688/ State : failure == Summary == Applying: drm/i915: Special handling for bonded requests error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915: Special handling for bonded requests When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice
== Series Details == Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice URL : https://patchwork.freedesktop.org/series/77758/ State : success == Summary == CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17806 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/index.html Known issues Here are the changes found in Patchwork_17806 that come from known issues: ### IGT changes ### Issues hit * igt@kms_chamelium@dp-crc-fast: - fi-icl-u2: [PASS][1] -> [FAIL][2] ([i915#262]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/fi-icl-u2/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@dp-edid-read: - fi-icl-u2: [PASS][3] -> [FAIL][4] ([i915#976]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html [i915#262]: https://gitlab.freedesktop.org/drm/intel/issues/262 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (50 -> 41) -- Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-n2820 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8549 -> Patchwork_17806 CI-20190529: 20190529 CI_DRM_8549: e50e9c6bf4efd00b02d91ff470993bbd0db94f67 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5682: e5371a99a877be134c6ad5361a5f03843a66f775 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17806: 243da8b64910288d152b148272e64fa8301d62f4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 243da8b64910 drm/i915/display: Enable HOBL regardless the VBT value 957a89b1b93d drm/i915/display: Implement HOBL ee42cab5f9b5 drm/i915/bios: Parse HOBL parameter 245f5bdf6d69 drm/i915/display/hsw+: Do not program the same vswing entry twice == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17806/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] i915/gem_exec_balancer: Randomise bonded submission
Randomly submit a paired spinner and its cancellation as a bonded
(submit fence) pair. Apply congestion to the engine with more bonded
pairs to see if the execution order fails. If we prevent a cancellation
from running, then the spinner will remain spinning forever.
v2: Test both immediate submission and fenced submission
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/i915/gem_exec_balancer.c | 172 +
1 file changed, 172 insertions(+)
diff --git a/tests/i915/gem_exec_balancer.c b/tests/i915/gem_exec_balancer.c
index 80ae82416..04b14dd3a 100644
--- a/tests/i915/gem_exec_balancer.c
+++ b/tests/i915/gem_exec_balancer.c
@@ -1154,6 +1154,175 @@ static void bonded_semaphore(int i915)
gem_context_destroy(i915, ctx);
}
+static void __bonded_dual(int i915,
+ const struct i915_engine_class_instance *siblings,
+ unsigned int count,
+ unsigned int flags,
+ unsigned long *out)
+#define BD_FENCE 0x1
+#define BD_HOSTILE 0x2
+#define BD_MANY 0x4
+{
+ struct drm_i915_gem_exec_object2 batch = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&batch),
+ .buffer_count = 1,
+ };
+ unsigned long cycles = 0;
+ unsigned int spinner;
+ igt_spin_t *a, *b;
+ int timeline;
+ uint32_t A, B;
+
+ srandom(getpid());
+
+ spinner = IGT_SPIN_POLL_RUN;
+ if (flags & BD_HOSTILE)
+ spinner |= IGT_SPIN_NO_PREEMPTION;
+
+ A = gem_context_create(i915);
+ set_load_balancer(i915, A, siblings, count, NULL);
+ a = igt_spin_new(i915, A, .flags = spinner);
+ igt_spin_end(a);
+ gem_sync(i915, a->handle);
+
+ B = gem_context_create(i915);
+ set_load_balancer(i915, B, siblings, count, NULL);
+ b = igt_spin_new(i915, B, .flags = spinner);
+ igt_spin_end(b);
+ gem_sync(i915, b->handle);
+
+ timeline = sw_sync_timeline_create();
+
+ igt_until_timeout(2) {
+ unsigned int master;
+ int fence;
+
+ master = 1;
+ if (flags & BD_MANY)
+ master = rand() % count + 1;
+
+ fence = -1;
+ if (flags & BD_FENCE)
+ fence = sw_sync_timeline_create_fence(timeline,
+ cycles + 1);
+
+ igt_spin_reset(a);
+ a->execbuf.flags = master | I915_EXEC_FENCE_OUT;
+ if (fence != -1) {
+ a->execbuf.rsvd2 = fence;
+ a->execbuf.flags |= I915_EXEC_FENCE_IN;
+ }
+ gem_execbuf_wr(i915, &a->execbuf);
+
+ igt_spin_reset(b);
+ b->execbuf.flags = master | I915_EXEC_FENCE_OUT;
+ if (fence != -1) {
+ b->execbuf.rsvd2 = fence;
+ b->execbuf.flags |= I915_EXEC_FENCE_IN;
+ }
+ gem_execbuf_wr(i915, &b->execbuf);
+
+ if (rand() % 1)
+ igt_swap(a, b);
+
+ batch.handle = create_semaphore_to_spinner(i915, a);
+ execbuf.rsvd1 = a->execbuf.rsvd1;
+ execbuf.rsvd2 = a->execbuf.rsvd2 >> 32;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, &execbuf);
+ gem_close(i915, batch.handle);
+
+ batch.handle = create_semaphore_to_spinner(i915, b);
+ execbuf.rsvd1 = b->execbuf.rsvd1;
+ execbuf.rsvd2 = b->execbuf.rsvd2 >> 32;
+ do {
+ execbuf.flags = rand() % count + 1;
+ } while (execbuf.flags == master);
+ execbuf.flags |= I915_EXEC_FENCE_SUBMIT;
+ gem_execbuf(i915, &execbuf);
+ gem_close(i915, batch.handle);
+
+ if (fence != -1) {
+ sw_sync_timeline_inc(timeline, 1);
+ close(fence);
+ }
+ close(a->execbuf.rsvd2 >> 32);
+ close(b->execbuf.rsvd2 >> 32);
+
+ gem_sync(i915, a->handle);
+ gem_sync(i915, b->handle);
+
+ cycles++;
+ }
+
+ *out = cycles;
+
+ close(timeline);
+
+ igt_spin_free(i915, a);
+ igt_spin_free(i915, b);
+
+ gem_context_destroy(i915, A);
+ gem_context_destroy(i915, B);
+}
+
+static void bonded_dual(int i915)
+{
+ unsigned long *cycles;
+
+ /*
+* The purpose of bonded submission is to execute one or more requests
+* concurrently. However, the very nature of that requires coordinated
+* submission across multiple engines.
+
Re: [Intel-gfx] [PATCH] drm/i915: Special handling for bonded requests
Quoting Tvrtko Ursulin (2020-05-28 11:20:07)
>
> On 28/05/2020 10:57, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> >> +static void
> >> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> >> +{
> >> + /*
> >> +* Give (temporary) special meaning to a pair requests with
> >> requested
> >> +* aligned start along the video engines.
> >> +*
> >> +* They should be non-preemptable and have all ELSP ports to
> >> themselves
> >> +* to avoid any deadlocks caused by inversions.
> >> +*
> >> +* Gen11+
> >> +*/
> >> + if (INTEL_GEN(rq->i915) < 11 ||
> >> + rq->engine->class != VIDEO_DECODE_CLASS ||
> >> + rq->engine->class != signal->engine->class)
> >> + return;
> >> +
> >> + set_bit(I915_FENCE_FLAG_NOPREEMPT, &rq->fence.flags);
> >> + set_bit(I915_FENCE_FLAG_NOPREEMPT, &signal->fence.flags);
> >> +
> >> + intel_context_set_single_submission(rq->context);
> >> + intel_context_set_single_submission(signal->context);
> >
> > The thought that just popped into my head:
> >
> > This can be after signal is already submitted into ELSP[1].
>
> Yep I knew that but thought it would still work.
>
> Master in vcs0 port1, slave in vcs1 port0 or queued.
>
> If queued that means at worst case another bonded pair is running on
> same engines, so they should be able to complete.
>
> If slave submitted to vcs1 port0 then it will stay there until whatever
> is in vcs0 port0 finishes and lets master in.
>
> Do you see a possibility for things to go bad?
Because the master is already submitted in port1, the bond can go into
port0. Then a second bond turns up for the master in port0, and we're
back at square one.
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 37855ae8f8b3..698608e11df3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2502,6 +2502,7 @@ static void eb_request_add(struct i915_execbuffer *eb)
lockdep_unpin_lock(&tl->mutex, rq->cookie);
trace_i915_request_add(rq);
+ set_bit(I915_FENCE_FLAG_SENTINEL, &rq->fence.flags);
prev = __i915_request_commit(rq);
Will do the trick.
(Plus fixing up the rules for assert_pending_valid).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice
== Series Details == Series: series starting with [1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice URL : https://patchwork.freedesktop.org/series/77758/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warnin
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath". (rev2)
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8549 -> Patchwork_17805
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17805 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17805, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_17805:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gem_contexts:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
- fi-skl-lmem:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-skl-lmem/igt@i915_selftest@live@gem_contexts.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-pnv-d510/igt@run...@aborted.html
- fi-gdg-551: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-gdg-551/igt@run...@aborted.html
- fi-snb-2520m: NOTRUN -> [FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-snb-2520m/igt@run...@aborted.html
- fi-byt-n2820: NOTRUN -> [FAIL][8]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-byt-n2820/igt@run...@aborted.html
- fi-ivb-3770:NOTRUN -> [FAIL][9]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-ivb-3770/igt@run...@aborted.html
- fi-byt-j1900: NOTRUN -> [FAIL][10]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-byt-j1900/igt@run...@aborted.html
- fi-elk-e7500: NOTRUN -> [FAIL][11]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-elk-e7500/igt@run...@aborted.html
- fi-blb-e6850: NOTRUN -> [FAIL][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-blb-e6850/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gem_contexts:
- {fi-kbl-7560u}: [PASS][13] -> [DMESG-WARN][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-kbl-7560u/igt@i915_selftest@live@gem_contexts.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-kbl-7560u/igt@i915_selftest@live@gem_contexts.html
* {igt@i915_selftest@live@gem_execbuf}:
- fi-skl-6600u: [PASS][15] -> [INCOMPLETE][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-skl-6600u/igt@i915_selftest@live@gem_execbuf.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-skl-6600u/igt@i915_selftest@live@gem_execbuf.html
- fi-cfl-8109u: [PASS][17] -> [INCOMPLETE][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-cfl-8109u/igt@i915_selftest@live@gem_execbuf.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-cfl-8109u/igt@i915_selftest@live@gem_execbuf.html
- fi-kbl-7500u: [PASS][19] -> [INCOMPLETE][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-kbl-7500u/igt@i915_selftest@live@gem_execbuf.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-kbl-7500u/igt@i915_selftest@live@gem_execbuf.html
- fi-kbl-guc: [PASS][21] -> [INCOMPLETE][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-kbl-guc/igt@i915_selftest@live@gem_execbuf.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-kbl-guc/igt@i915_selftest@live@gem_execbuf.html
- fi-bsw-nick:[PASS][23] -> [INCOMPLETE][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-bsw-nick/igt@i915_selftest@live@gem_execbuf.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-bsw-nick/igt@i915_selftest@live@gem_execbuf.html
- fi-kbl-8809g: [PASS][25] -> [INCOMPLETE][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8549/fi-kbl-8809g/igt@i915_selftest@live@gem_execbuf.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17805/fi-k
[Intel-gfx] [PATCH 2/4] drm/i915/bios: Parse HOBL parameter
HOBL means hours of battery life, it is a power-saving feature
were supported motherboards can use a special voltage swing table
that uses less power.
So here parsing the VBT to check if this feature is supported.
While at it already added the VRR parameter too.
BSpec: 20150
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_bios.c | 3 +++
drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 ++
drivers/gpu/drm/i915/i915_drv.h | 1 +
3 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 839124647202..b3c453aa7623 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -722,6 +722,9 @@ parse_power_conservation_features(struct drm_i915_private
*dev_priv,
*/
if (!(power->drrs & BIT(panel_type)))
dev_priv->vbt.drrs_type = DRRS_NOT_SUPPORTED;
+
+ if (bdb->version >= 232)
+ dev_priv->vbt.edp.hobl = power->hobl & BIT(panel_type);
}
static void
diff --git a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
index aef7fe932d1a..65f552f57e06 100644
--- a/drivers/gpu/drm/i915/display/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/display/intel_vbt_defs.h
@@ -820,6 +820,8 @@ struct bdb_lfp_power {
u16 adb;
u16 lace_enabled_status;
struct agressiveness_profile_entry aggressivenes[16];
+ u16 hobl; /* 232+ */
+ u16 vrr; /* 233+ */
} __packed;
/*
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 98f2c448cd92..1e060de3edc4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -690,6 +690,7 @@ struct intel_vbt_data {
bool initialized;
int bpp;
struct edp_power_seq pps;
+ bool hobl;
} edp;
struct {
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/display/hsw+: Do not program the same vswing entry twice
It will be programed right before the link training, so no need to do
it twice.
It will not strictly follow BSpec sequences but most of this sequences
are not matching anyways.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index aa22465bb56e..c100efc6a2c4 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3115,7 +3115,6 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
- int level = intel_ddi_dp_level(intel_dp);
enum transcoder transcoder = crtc_state->cpu_transcoder;
intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
@@ -3190,9 +3189,10 @@ static void tgl_ddi_pre_enable_dp(struct
intel_atomic_state *state,
* down this function.
*/
- /* 7.e Configure voltage swing and related IO settings */
- tgl_ddi_vswing_sequence(encoder, crtc_state->port_clock, level,
- encoder->type);
+ /*
+* 7.e Configure voltage swing and related IO settings
+* It will be done in intel_dp_start_link_train(), no need to do twice
+*/
/*
* 7.f Combo PHY: Configure PORT_CL_DW10 Static Power Down to power up
@@ -3257,7 +3257,6 @@ static void hsw_ddi_pre_enable_dp(struct
intel_atomic_state *state,
enum phy phy = intel_port_to_phy(dev_priv, port);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
- int level = intel_ddi_dp_level(intel_dp);
if (INTEL_GEN(dev_priv) < 11)
drm_WARN_ON(&dev_priv->drm,
@@ -3279,16 +3278,6 @@ static void hsw_ddi_pre_enable_dp(struct
intel_atomic_state *state,
icl_program_mg_dp_mode(dig_port, crtc_state);
- if (INTEL_GEN(dev_priv) >= 11)
- icl_ddi_vswing_sequence(encoder, crtc_state->port_clock,
- level, encoder->type);
- else if (IS_CANNONLAKE(dev_priv))
- cnl_ddi_vswing_sequence(encoder, level, encoder->type);
- else if (IS_GEN9_LP(dev_priv))
- bxt_ddi_vswing_sequence(encoder, level, encoder->type);
- else
- intel_prepare_dp_ddi_buffers(encoder, crtc_state);
-
if (intel_phy_is_combo(dev_priv, phy)) {
bool lane_reversal =
dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL;
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/display: Enable HOBL regardless the VBT value
HOBL worked in my TGL RVP even without the necessary HW support, also
it worked in more than half of the TGL machines in CI so it is worthy
to enable it by default.
Even if link training fails with this new vswing table it will only
cause one additional link training, that is worthy the try to get the
additional power-savings.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
index db078780542f..86de1187d363 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -108,7 +108,7 @@ intel_dp_reset_link_train(struct intel_dp *intel_dp, u8
dp_train_pat)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
- if (intel_dp_is_edp(intel_dp) && dev_priv->vbt.edp.hobl)
+ if (HAS_HOBL(dev_priv) && intel_dp_is_edp(intel_dp))
intel_dp->try_hobl = true;
memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/display: Implement HOBL
Hours Of Battery Life is a new GEN12+ power-saving feature that allows
supported motherboards to use a special voltage swing table for eDP
panels that uses less power.
So here if supported by HW, OEM will set it in VBT and i915 will try
to train link with HOBL vswing table if link training fails it fall
back to the original table.
Just not sure if DP compliance should also use this new voltage swing
table too, cced some folks that worked in DP compliance.
BSpec: 49291
BSpec: 49399
Cc: Animesh Manna
Cc: Manasi Navare
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 48 +--
.../drm/i915/display/intel_display_types.h| 2 +
.../drm/i915/display/intel_dp_link_training.c | 20 +++-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_reg.h | 2 +
5 files changed, 69 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index c100efc6a2c4..a44e190de79f 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -692,6 +692,10 @@ static const struct cnl_ddi_buf_trans
tgl_combo_phy_ddi_translations_dp_hbr2[] =
{ 0x6, 0x7F, 0x3F, 0x00, 0x00 },/* 900 900 0.0 */
};
+static const struct cnl_ddi_buf_trans
tgl_combo_phy_ddi_translations_edp_hbr2_hobl[] = {
+ { 0x6, 0x7F, 0x3F, 0x00, 0x00 }
+};
+
static const struct ddi_buf_trans *
bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
{
@@ -2297,14 +2301,51 @@ static void cnl_ddi_vswing_sequence(struct
intel_encoder *encoder,
intel_de_write(dev_priv, CNL_PORT_TX_DW5_GRP(port), val);
}
+/*
+ * If supported return HOBL vswing table and set registers to enable HOBL
+ * otherwise returns NULL and unset registers to enable HOBL.
+ */
+static const struct cnl_ddi_buf_trans *
+hobl_get_combo_buf_trans(struct drm_i915_private *dev_priv,
+struct intel_encoder *encoder, int type, int rate,
+u32 level, int *n_entries)
+{
+ const u32 hobl_en = EDP4K2K_MODE_OVRD_EN | EDP4K2K_MODE_OVRD_OPTIMIZED;
+ enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
+ struct intel_dp *intel_dp;
+
+ if (!HAS_HOBL(dev_priv) || type != INTEL_OUTPUT_EDP)
+ return NULL;
+
+ intel_dp = enc_to_intel_dp(encoder);
+ if (!intel_dp->try_hobl || rate > 54) {
+ intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), hobl_en, 0);
+ return NULL;
+ }
+
+ drm_dbg_kms(&dev_priv->drm, "Enabling HOBL in PHY %c\n", phy_name(phy));
+ drm_WARN_ON_ONCE(&dev_priv->drm, level > 0);
+
+ intel_de_rmw(dev_priv, ICL_PORT_CL_DW10(phy), hobl_en, hobl_en);
+ /* Same table applies to TGL, RKL and DG1 */
+ *n_entries = ARRAY_SIZE(tgl_combo_phy_ddi_translations_edp_hbr2_hobl);
+ return tgl_combo_phy_ddi_translations_edp_hbr2_hobl;
+}
+
static void icl_ddi_combo_vswing_program(struct drm_i915_private *dev_priv,
- u32 level, enum phy phy, int type,
- int rate)
+struct intel_encoder *encoder,
+u32 level, enum phy phy, int type,
+int rate)
{
const struct cnl_ddi_buf_trans *ddi_translations = NULL;
u32 n_entries, val;
int ln;
+ ddi_translations = hobl_get_combo_buf_trans(dev_priv, encoder, type,
+ rate, level, &n_entries);
+ if (ddi_translations)
+ goto hobl_found;
+
if (INTEL_GEN(dev_priv) >= 12)
ddi_translations = tgl_get_combo_buf_trans(dev_priv, type, rate,
&n_entries);
@@ -2317,6 +2358,7 @@ static void icl_ddi_combo_vswing_program(struct
drm_i915_private *dev_priv,
if (!ddi_translations)
return;
+hobl_found:
if (level >= n_entries) {
drm_dbg_kms(&dev_priv->drm,
"DDI translation not found for level %d. Using %d
instead.",
@@ -2424,7 +2466,7 @@ static void icl_combo_phy_ddi_vswing_sequence(struct
intel_encoder *encoder,
intel_de_write(dev_priv, ICL_PORT_TX_DW5_GRP(phy), val);
/* 5. Program swing and de-emphasis */
- icl_ddi_combo_vswing_program(dev_priv, level, phy, type, rate);
+ icl_ddi_combo_vswing_program(dev_priv, encoder, level, phy, type, rate);
/* 6. Set training enable to trigger update */
val = intel_de_read(dev_priv, ICL_PORT_TX_DW5_LN0(phy));
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 30b2767578dc..9e7dbff7dd43 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/dri
Re: [Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount
On Thu, May 28, 2020 at 10:38:52PM +0300, Lisovskiy, Stanislav wrote:
> On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > While the current locking/serialization of the global state
> > suffices for protecting the obj->state access and the actual
> > hardware reprogramming, we do have a problem with accessing
> > the old/new states during nonblocking commits.
> >
> > The state computation and swap will be protected by the crtc
> > locks, but the commit_tails can finish out of order, thus also
> > causing the atomic states to be cleaned up out of order. This
> > would mean the commit that started first but finished last has
> > had its new state freed as the no-longer-needed old state by the
> > other commit.
> >
> > To fix this let's just refcount the states. obj->state amounts
> > to one reference, and the intel_atomic_state holds extra references
> > to both its new and old global obj states.
> >
> > Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state handling")
> > Signed-off-by: Ville Syrjälä
> > ---
> > .../gpu/drm/i915/display/intel_global_state.c | 45 ---
> > .../gpu/drm/i915/display/intel_global_state.h | 3 ++
> > 2 files changed, 42 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c
> > b/drivers/gpu/drm/i915/display/intel_global_state.c
> > index 212d4ee68205..7a19215ad844 100644
> > --- a/drivers/gpu/drm/i915/display/intel_global_state.c
> > +++ b/drivers/gpu/drm/i915/display/intel_global_state.c
> > @@ -10,6 +10,28 @@
> > #include "intel_display_types.h"
> > #include "intel_global_state.h"
> >
> > +static void __intel_atomic_global_state_free(struct kref *kref)
> > +{
> > + struct intel_global_state *obj_state =
> > + container_of(kref, struct intel_global_state, ref);
> > + struct intel_global_obj *obj = obj_state->obj;
> > +
> > + obj->funcs->atomic_destroy_state(obj, obj_state);
> > +}
> > +
> > +static void intel_atomic_global_state_put(struct intel_global_state
> > *obj_state)
> > +{
> > + kref_put(&obj_state->ref, __intel_atomic_global_state_free);
> > +}
> > +
> > +static struct intel_global_state *
> > +intel_atomic_global_state_get(struct intel_global_state *obj_state)
> > +{
> > + kref_get(&obj_state->ref);
> > +
> > + return obj_state;
> > +}
> > +
> > void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv,
> > struct intel_global_obj *obj,
> > struct intel_global_state *state,
> > @@ -17,6 +39,10 @@ void intel_atomic_global_obj_init(struct
> > drm_i915_private *dev_priv,
> > {
> > memset(obj, 0, sizeof(*obj));
> >
> > + state->obj = obj;
> > +
> > + kref_init(&state->ref);
> > +
> > obj->state = state;
> > obj->funcs = funcs;
> > list_add_tail(&obj->head, &dev_priv->global_obj_list);
> > @@ -28,7 +54,9 @@ void intel_atomic_global_obj_cleanup(struct
> > drm_i915_private *dev_priv)
> >
> > list_for_each_entry_safe(obj, next, &dev_priv->global_obj_list, head) {
> > list_del(&obj->head);
> > - obj->funcs->atomic_destroy_state(obj, obj->state);
> > +
> > + drm_WARN_ON(&dev_priv->drm, kref_read(&obj->state->ref) != 1);
> > + intel_atomic_global_state_put(obj->state);
> > }
> > }
> >
> > @@ -97,10 +125,14 @@ intel_atomic_get_global_obj_state(struct
> > intel_atomic_state *state,
> > if (!obj_state)
> > return ERR_PTR(-ENOMEM);
> >
> > + obj_state->obj = obj;
> > obj_state->changed = false;
> >
> > + kref_init(&obj_state->ref);
> > +
> > state->global_objs[index].state = obj_state;
> > - state->global_objs[index].old_state = obj->state;
> > + state->global_objs[index].old_state =
> > + intel_atomic_global_state_get(obj->state);
> > state->global_objs[index].new_state = obj_state;
> > state->global_objs[index].ptr = obj;
> > obj_state->state = state;
> > @@ -163,7 +195,9 @@ void intel_atomic_swap_global_state(struct
> > intel_atomic_state *state)
> > new_obj_state->state = NULL;
> >
> > state->global_objs[i].state = old_obj_state;
> > - obj->state = new_obj_state;
> > +
> > + intel_atomic_global_state_put(obj->state);
> > + obj->state = intel_atomic_global_state_get(new_obj_state);
> > }
> > }
> >
> > @@ -172,10 +206,9 @@ void intel_atomic_clear_global_state(struct
> > intel_atomic_state *state)
> > int i;
> >
> > for (i = 0; i < state->num_global_objs; i++) {
> > - struct intel_global_obj *obj = state->global_objs[i].ptr;
> > + intel_atomic_global_state_put(state->global_objs[i].old_state);
> > + intel_atomic_global_state_put(state->global_objs[i].new_state);
>
> Shouldn't we clean old_state only?
>
> As I understand in absence of any transaction you now have a pool of
> global_obj each has a state with single kref tak
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath". (rev2)
== Series Details == Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath". (rev2) URL : https://patchwork.freedesktop.org/series/77472/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/23] Revert "drm/i915/gem: Drop relocation slowpath". (rev2)
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath". (rev2)
URL : https://patchwork.freedesktop.org/series/77472/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d9487c8b0b0d Revert "drm/i915/gem: Drop relocation slowpath".
-:80: WARNING:LINE_SPACING: Missing a blank line after declarations
#80: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1802:
+ int err = __get_user(c, addr);
+ if (err)
total: 0 errors, 1 warnings, 0 checks, 264 lines checked
a6440b9f94ef drm/i915: Add an implementation for i915_gem_ww_ctx locking, v2.
-:493: WARNING:LONG_LINE: line over 100 characters
#493: FILE: drivers/gpu/drm/i915/i915_gem.c:1341:
+ while ((obj = list_first_entry_or_null(&ww->obj_list, struct
drm_i915_gem_object, obj_link))) {
total: 0 errors, 1 warnings, 0 checks, 473 lines checked
e8da908480c7 drm/i915: Remove locking from i915_gem_object_prepare_read/write
ef08f55abbdc drm/i915: Parse command buffer earlier in eb_relocate(slow)
f044defb7a38 Revert "drm/i915/gem: Split eb_vma into its own allocation"
1c64f1102879 drm/i915/gem: Make eb_add_lut interruptible wait on object lock.
e4ec453ceb93 drm/i915: Use per object locking in execbuf, v10.
-:463: CHECK:LINE_SPACING: Please don't use multiple blank lines
#463: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1398:
+
-:510: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#510: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1510:
+static int __reloc_entry_gpu(struct i915_execbuffer *eb,
struct i915_vma *vma,
-:530: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#530: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1583:
+static int reloc_entry_gpu(struct i915_execbuffer *eb,
struct i915_vma *vma,
-:542: ERROR:TRAILING_WHITESPACE: trailing whitespace
#542: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1608:
+^I$
-:801: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided
#801: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2947:
+ eb.reloc_pool = eb.batch_pool = NULL;
total: 1 errors, 0 warnings, 4 checks, 803 lines checked
456650be2110 drm/i915: Use ww locking in intel_renderstate.
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
Convert to using ww-waiting, and make sure we always pin intel_context_state,
total: 0 errors, 1 warnings, 0 checks, 209 lines checked
ae010588e8f7 drm/i915: Add ww context handling to context_barrier_task
-:19: WARNING:LONG_LINE: line over 100 characters
#19: FILE: drivers/gpu/drm/i915/gem/i915_gem_context.c:1097:
+ int (*pin)(struct intel_context *ce, struct
i915_gem_ww_ctx *ww, void *data),
total: 0 errors, 1 warnings, 0 checks, 146 lines checked
702fdc1c44ab drm/i915: Nuke arguments to eb_pin_engine
5252cb40e5b1 drm/i915: Pin engine before pinning all objects, v4.
acc7cf29898a drm/i915: Rework intel_context pinning to do everything outside of
pin_mutex
-:125: CHECK:LINE_SPACING: Please don't use multiple blank lines
#125: FILE: drivers/gpu/drm/i915/gt/intel_context.c:176:
+
+
-:338: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#338: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:3441:
+ *vaddr = i915_gem_object_pin_map(ce->state->obj,
+
i915_coherent_map_type(ce->engine->i915) |
total: 0 errors, 0 warnings, 2 checks, 435 lines checked
be4ae42ef97a drm/i915: Make sure execbuffer always passes ww state to
i915_vma_pin.
-:95: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#95: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:596:
+ err = i915_vma_pin_ww(vma, &eb->ww,
entry->pad_to_size, entry->alignment,
-:213: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#213: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2462:
+* hsw should have this fixed, but bdw mucks it up again. */
total: 0 errors, 1 warnings, 1 checks, 850 lines checked
ee11c6a35842 drm/i915: Convert i915_gem_object/client_blt.c to use ww locking
as well, v2.
0a8312f18acd drm/i915: Kill last user of intel_context_create_request outside
of selftests
e275216d5a7b drm/i915: Convert i915_perf to ww locking as well
c4ecc3f83b68 drm/i915: Dirty hack to fix selftests locking inversion
43ec8d9fdd0d drm/i915/selftests: Fix locking inversion in lrc selftest.
6ff9944cb187 drm/i915: Use ww pinning for intel_context_create_request()
238eed520bff drm/i915: Move i915_vma_lock in the selftests to avoid lock
inversion, v2.
-:108: ERROR:TRAILING_WHITESPACE: trailing whitespace
#108: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_execbuffer.c:154:
+^I^Ii915_gem_ww_ctx_fini(&eb.ww); $
total: 1 errors, 0 warnings, 0 checks, 347 lines checked
a213e785a
Re: [Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount
On Wed, May 27, 2020 at 11:02:45PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> While the current locking/serialization of the global state
> suffices for protecting the obj->state access and the actual
> hardware reprogramming, we do have a problem with accessing
> the old/new states during nonblocking commits.
>
> The state computation and swap will be protected by the crtc
> locks, but the commit_tails can finish out of order, thus also
> causing the atomic states to be cleaned up out of order. This
> would mean the commit that started first but finished last has
> had its new state freed as the no-longer-needed old state by the
> other commit.
>
> To fix this let's just refcount the states. obj->state amounts
> to one reference, and the intel_atomic_state holds extra references
> to both its new and old global obj states.
>
> Fixes: 0ef1905ecf2e ("drm/i915: Introduce better global state handling")
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_global_state.c | 45 ---
> .../gpu/drm/i915/display/intel_global_state.h | 3 ++
> 2 files changed, 42 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_global_state.c
> b/drivers/gpu/drm/i915/display/intel_global_state.c
> index 212d4ee68205..7a19215ad844 100644
> --- a/drivers/gpu/drm/i915/display/intel_global_state.c
> +++ b/drivers/gpu/drm/i915/display/intel_global_state.c
> @@ -10,6 +10,28 @@
> #include "intel_display_types.h"
> #include "intel_global_state.h"
>
> +static void __intel_atomic_global_state_free(struct kref *kref)
> +{
> + struct intel_global_state *obj_state =
> + container_of(kref, struct intel_global_state, ref);
> + struct intel_global_obj *obj = obj_state->obj;
> +
> + obj->funcs->atomic_destroy_state(obj, obj_state);
> +}
> +
> +static void intel_atomic_global_state_put(struct intel_global_state
> *obj_state)
> +{
> + kref_put(&obj_state->ref, __intel_atomic_global_state_free);
> +}
> +
> +static struct intel_global_state *
> +intel_atomic_global_state_get(struct intel_global_state *obj_state)
> +{
> + kref_get(&obj_state->ref);
> +
> + return obj_state;
> +}
> +
> void intel_atomic_global_obj_init(struct drm_i915_private *dev_priv,
> struct intel_global_obj *obj,
> struct intel_global_state *state,
> @@ -17,6 +39,10 @@ void intel_atomic_global_obj_init(struct drm_i915_private
> *dev_priv,
> {
> memset(obj, 0, sizeof(*obj));
>
> + state->obj = obj;
> +
> + kref_init(&state->ref);
> +
> obj->state = state;
> obj->funcs = funcs;
> list_add_tail(&obj->head, &dev_priv->global_obj_list);
> @@ -28,7 +54,9 @@ void intel_atomic_global_obj_cleanup(struct
> drm_i915_private *dev_priv)
>
> list_for_each_entry_safe(obj, next, &dev_priv->global_obj_list, head) {
> list_del(&obj->head);
> - obj->funcs->atomic_destroy_state(obj, obj->state);
> +
> + drm_WARN_ON(&dev_priv->drm, kref_read(&obj->state->ref) != 1);
> + intel_atomic_global_state_put(obj->state);
> }
> }
>
> @@ -97,10 +125,14 @@ intel_atomic_get_global_obj_state(struct
> intel_atomic_state *state,
> if (!obj_state)
> return ERR_PTR(-ENOMEM);
>
> + obj_state->obj = obj;
> obj_state->changed = false;
>
> + kref_init(&obj_state->ref);
> +
> state->global_objs[index].state = obj_state;
> - state->global_objs[index].old_state = obj->state;
> + state->global_objs[index].old_state =
> + intel_atomic_global_state_get(obj->state);
> state->global_objs[index].new_state = obj_state;
> state->global_objs[index].ptr = obj;
> obj_state->state = state;
> @@ -163,7 +195,9 @@ void intel_atomic_swap_global_state(struct
> intel_atomic_state *state)
> new_obj_state->state = NULL;
>
> state->global_objs[i].state = old_obj_state;
> - obj->state = new_obj_state;
> +
> + intel_atomic_global_state_put(obj->state);
> + obj->state = intel_atomic_global_state_get(new_obj_state);
> }
> }
>
> @@ -172,10 +206,9 @@ void intel_atomic_clear_global_state(struct
> intel_atomic_state *state)
> int i;
>
> for (i = 0; i < state->num_global_objs; i++) {
> - struct intel_global_obj *obj = state->global_objs[i].ptr;
> + intel_atomic_global_state_put(state->global_objs[i].old_state);
> + intel_atomic_global_state_put(state->global_objs[i].new_state);
Shouldn't we clean old_state only?
As I understand in absence of any transaction you now have a pool of
global_obj each has a state with single kref taken.
So when we are going to get a new state, we do +1 kref to old_state(which is
current global obj->state)
in order to prevent it being cleared by competing commit.
However the new state doesn't have any kref taken by that moment.
Th
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave and Daniel, Here goes drm-intel-fixes-2020-05-28: couple compilation fixes for gcc-9+, and couple fixes for timeslicing, one to respect I915_REQUEST_NOPREEMPT flag and another to incorporate virtual engine into timeslicing. Thanks, Rodrigo. The following changes since commit 9cb1fd0efd195590b828b9b865421ad345a4a145: Linux 5.7-rc7 (2020-05-24 15:32:54 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2020-05-28 for you to fetch changes up to 1f65efb624c4164bfd2e2a025fc25e8bfb651daa: drm/i915/gt: Prevent timeslicing into unpreemptable requests (2020-05-28 06:06:27 -0700) couple compilation fixes for gcc-9+, and couple fixes for timeslicing, one to respect I915_REQUEST_NOPREEMPT flag and another to incorporate virtual engine into timeslicing. Arnd Bergmann (2): drm/i915/pmu: avoid an maybe-uninitialized warning drm/i915: work around false-positive maybe-uninitialized warning Chris Wilson (2): drm/i915/gt: Incorporate the virtual engine into timeslicing drm/i915/gt: Prevent timeslicing into unpreemptable requests drivers/gpu/drm/i915/gt/intel_lrc.c| 31 +-- drivers/gpu/drm/i915/gt/selftest_lrc.c | 118 - drivers/gpu/drm/i915/gt/selftest_workarounds.c | 2 + drivers/gpu/drm/i915/i915_pmu.c| 84 +- drivers/gpu/drm/i915/i915_priolist_types.h | 2 +- 5 files changed, 187 insertions(+), 50 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: use drm_dev_has_vblank more (rev2)
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17798_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17798_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17798_full:
### IGT changes ###
Possible regressions
* igt@gem_userptr_blits@readonly-mmap-unsync:
- shard-glk: NOTRUN -> [TIMEOUT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-glk9/igt@gem_userptr_bl...@readonly-mmap-unsync.html
Known issues
Here are the changes found in Patchwork_17798_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume:
- shard-kbl: [PASS][2] -> [DMESG-WARN][3] ([i915#180])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl7/igt@gem_workarou...@suspend-resume.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-kbl3/igt@gem_workarou...@suspend-resume.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][4] -> [DMESG-WARN][5] ([i915#1436] /
[i915#716])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl4/igt@gen9_exec_pa...@allowed-all.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109349])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-iclb4/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][8] -> [FAIL][9] ([i915#1188])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl1/igt@kms_...@bpc-switch-suspend.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-skl7/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#180] /
[i915#93] / [i915#95])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: [PASS][14] -> [FAIL][15] ([fdo#108145] / [i915#265])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109441]) +2 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-iclb4/igt@kms_psr@psr2_cursor_render.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][18] -> [FAIL][19] ([i915#31])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl2/igt@kms_setm...@basic.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl2/igt@kms_setm...@basic.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][20] ([i915#1930]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
* igt@i915_suspend@forcewake:
- shard-kbl: [DMESG-WARN][22] ([i915#180]) -> [PASS][23] +2
similar issues
[22]:
https:/
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Restore both GGTT bindings on resume
== Series Details == Series: drm/i915/gt: Restore both GGTT bindings on resume URL : https://patchwork.freedesktop.org/series/77750/ State : success == Summary == CI Bug Log - changes from CI_DRM_8547_full -> Patchwork_17804_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17804_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#1602] / [i915#456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-tglb2/igt@gem_exec_susp...@basic-s0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-tglb7/igt@gem_exec_susp...@basic-s0.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#69]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-skl9/igt@gem_workarou...@suspend-resume-fd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-skl8/igt@gem_workarou...@suspend-resume-fd.html * igt@kms_big_fb@y-tiled-64bpp-rotate-180: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#1119] / [i915#118] / [i915#95]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-glk1/igt@kms_big...@y-tiled-64bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen: - shard-kbl: [PASS][7] -> [FAIL][8] ([i915#54] / [i915#93] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#108145] / [i915#265]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-skl8/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109441]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-iclb6/igt@kms_psr@psr2_cursor_mmap_cpu.html Possible fixes * igt@gem_eio@in-flight-suspend: - shard-skl: [INCOMPLETE][13] ([i915#69]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-skl6/igt@gem_...@in-flight-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-skl8/igt@gem_...@in-flight-suspend.html * igt@gen9_exec_parse@allowed-all: - shard-apl: [DMESG-WARN][15] ([i915#1436] / [i915#716]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-apl1/igt@gen9_exec_pa...@allowed-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-apl8/igt@gen9_exec_pa...@allowed-all.html * igt@kms_big_fb@linear-64bpp-rotate-180: - shard-glk: [FAIL][17] ([i915#1119] / [i915#118] / [i915#95]) -> [PASS][18] +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-glk7/igt@kms_big...@linear-64bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-snb: [INCOMPLETE][19] ([i915#82]) -> [PASS][20] +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-snb6/igt@kms_cursor_...@pipe-a-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-snb4/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-256x85-onscreen: - shard-skl: [FAIL][21] ([i915#54]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-skl5/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-256x85-onscreen.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-hsw: [INCOMPLETE][23] ([i915#61]) -> [PASS][24] +3 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-hsw7/igt@kms_cursor_...@pipe-c-cursor-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/shard-hsw8/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_lega
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gem: Mark the buffer pool as active for the cmdparser
== Series Details ==
Series: drm/i915/gem: Mark the buffer pool as active for the cmdparser
URL : https://patchwork.freedesktop.org/series/77749/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8547_full -> Patchwork_17803_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17803_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17803_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17803_full:
### IGT changes ###
Possible regressions
* igt@gen9_exec_parse@bb-chained:
- shard-glk: [PASS][1] -> [TIMEOUT][2] +6 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-glk5/igt@gen9_exec_pa...@bb-chained.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-glk8/igt@gen9_exec_pa...@bb-chained.html
Known issues
Here are the changes found in Patchwork_17803_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0:
- shard-tglb: [PASS][3] -> [INCOMPLETE][4] ([i915#1602] /
[i915#456])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-tglb2/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-tglb6/igt@gem_exec_susp...@basic-s0.html
* igt@i915_suspend@sysfs-reader:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69]) +2 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-skl3/igt@i915_susp...@sysfs-reader.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-skl1/igt@i915_susp...@sysfs-reader.html
* igt@kms_big_fb@x-tiled-64bpp-rotate-180:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#1119] / [i915#118] /
[i915#95])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-glk2/igt@kms_big...@x-tiled-64bpp-rotate-180.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-glk8/igt@kms_big...@x-tiled-64bpp-rotate-180.html
* igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-kbl: [PASS][9] -> [FAIL][10] ([i915#54] / [i915#93] /
[i915#95])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-kbl2/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#72])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-glk6/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-kbl1/igt@kms_fbcon_...@fbc-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-kbl3/igt@kms_fbcon_...@fbc-suspend.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-apl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +3
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-apl7/igt@kms_...@bpc-switch-suspend.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-apl4/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
+1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-iclb4/igt@kms_psr@psr2_cursor_blt.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent16}:
- shard-snb: [FAIL][21] ([i915#1930]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/shard-snb5/igt@gem_exec_re...@basic-concurrent16.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/shard-snb4/igt@gem_exec_re...@basic-concurrent16.html
* igt@gem_userptr_blits@
Re: [Intel-gfx] [PATCH v3 0/5] Asynchronous flip implementation for i915
Em qui, 2020-05-28 às 11:09 +0530, Karthik B S escreveu: > Without async flip support in the kernel, fullscreen apps where game > resolution is equal to the screen resolution, must perform an extra blit > per frame prior to flipping. > > Asynchronous page flips will also boost the FPS of Mesa benchmarks. > > v2: Few patches have been squashed and patches have been shuffled as > per the reviews on the previous version. > > v3: Few patches have been squashed and patches have been shuffled as > per the reviews on the previous version. Hello I asked quite a few questions in the review of v2, but never got any replies. I see some things regarding those questions are different in v3, but I still would really like to have those answers in direct text/email form in order to clarify my understanding of your original intent (and also help me understand why things are different in v3). Would you mind replying to those emails? Thanks, Paulo > > Karthik B S (5): > drm/i915: Add enable/disable flip done and flip done handler > drm/i915: Add support for async flips in I915 > drm/i915: Add checks specific to async flips > drm/i915: Do not call drm_crtc_arm_vblank_event in async flips > drm/i915: Enable async flips in i915 > > drivers/gpu/drm/i915/display/intel_display.c | 71 > drivers/gpu/drm/i915/display/intel_sprite.c | 8 ++- > drivers/gpu/drm/i915/i915_irq.c | 52 ++ > drivers/gpu/drm/i915/i915_irq.h | 2 + > drivers/gpu/drm/i915/i915_reg.h | 1 + > 5 files changed, 133 insertions(+), 1 deletion(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Don't declare hangs if engine is stalled
Quoting Chris Wilson (2020-05-28 17:50:55)
> Quoting Mika Kuoppala (2020-05-28 17:23:18)
> > Chris Wilson writes:
> >
> > > If the ring submission is stalled on an external request, nothing can be
> > > submitted, not even the heartbeat in the kernel context. Since nothing
> > > is running, resetting the engine/device does not unblock the system and
> > > is pointless. We can see if the heartbeat is supposed to be running
> > > before declaring foul.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 19 ---
> > > 1 file changed, 16 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > > index 5136c8bf112d..f67ad937eefb 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > > @@ -48,8 +48,10 @@ static void show_heartbeat(const struct i915_request
> > > *rq,
> > > struct drm_printer p = drm_debug_printer("heartbeat");
> > >
> > > intel_engine_dump(engine, &p,
> > > - "%s heartbeat {prio:%d} not ticking\n",
> > > + "%s heartbeat {seqno:%llx:%lld, prio:%d} not
> > > ticking\n",
> > > engine->name,
> > > + rq->fence.context,
> > > + rq->fence.seqno,
> > > rq->sched.attr.priority);
> > > }
> > >
> > > @@ -76,8 +78,19 @@ static void heartbeat(struct work_struct *wrk)
> > > goto out;
> > >
> > > if (engine->heartbeat.systole) {
> > > - if (engine->schedule &&
> > > - rq->sched.attr.priority < I915_PRIORITY_BARRIER) {
> > > + if (!i915_sw_fence_signaled(&rq->submit)) {
> > > + /*
> > > + * Not yet submitted, system is stalled.
> > > + *
> > > + * This more often happens for ring submission,
> > > + * where all contexts are funnelled into a common
> > > + * ringbuffer. If one context is blocked on an
> > > + * external fence, not only is it not submitted,
> > > + * but all other contexts, including the kernel
> > > + * context are stuck waiting for the signal.
> > > + */
> >
> > The solution how to save the system evades me.
> > But piling the heartbeat on top does not help with it in
> > any case.
>
> Last resort could be hangcheck again, but over a much much longer
> interval, say 2 minutes with work queued to the engine, but it remains
> idle, mark the device as wedged (and stop using it altogether). We have
> to be really confident that the cure is worth it.
To be effective we would also need to brute force complete the requests
waiting on external fences so that we could power down the device. Hmm,
that reminds me I need something similar to power down an active device
at suspend.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Don't declare hangs if engine is stalled
Quoting Mika Kuoppala (2020-05-28 17:23:18)
> Chris Wilson writes:
>
> > If the ring submission is stalled on an external request, nothing can be
> > submitted, not even the heartbeat in the kernel context. Since nothing
> > is running, resetting the engine/device does not unblock the system and
> > is pointless. We can see if the heartbeat is supposed to be running
> > before declaring foul.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 19 ---
> > 1 file changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > index 5136c8bf112d..f67ad937eefb 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > @@ -48,8 +48,10 @@ static void show_heartbeat(const struct i915_request *rq,
> > struct drm_printer p = drm_debug_printer("heartbeat");
> >
> > intel_engine_dump(engine, &p,
> > - "%s heartbeat {prio:%d} not ticking\n",
> > + "%s heartbeat {seqno:%llx:%lld, prio:%d} not
> > ticking\n",
> > engine->name,
> > + rq->fence.context,
> > + rq->fence.seqno,
> > rq->sched.attr.priority);
> > }
> >
> > @@ -76,8 +78,19 @@ static void heartbeat(struct work_struct *wrk)
> > goto out;
> >
> > if (engine->heartbeat.systole) {
> > - if (engine->schedule &&
> > - rq->sched.attr.priority < I915_PRIORITY_BARRIER) {
> > + if (!i915_sw_fence_signaled(&rq->submit)) {
> > + /*
> > + * Not yet submitted, system is stalled.
> > + *
> > + * This more often happens for ring submission,
> > + * where all contexts are funnelled into a common
> > + * ringbuffer. If one context is blocked on an
> > + * external fence, not only is it not submitted,
> > + * but all other contexts, including the kernel
> > + * context are stuck waiting for the signal.
> > + */
>
> The solution how to save the system evades me.
> But piling the heartbeat on top does not help with it in
> any case.
Last resort could be hangcheck again, but over a much much longer
interval, say 2 minutes with work queued to the engine, but it remains
idle, mark the device as wedged (and stop using it altogether). We have
to be really confident that the cure is worth it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/gt: Don't declare hangs if engine is stalled
Chris Wilson writes:
> If the ring submission is stalled on an external request, nothing can be
> submitted, not even the heartbeat in the kernel context. Since nothing
> is running, resetting the engine/device does not unblock the system and
> is pointless. We can see if the heartbeat is supposed to be running
> before declaring foul.
>
> Signed-off-by: Chris Wilson
> ---
> .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index 5136c8bf112d..f67ad937eefb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -48,8 +48,10 @@ static void show_heartbeat(const struct i915_request *rq,
> struct drm_printer p = drm_debug_printer("heartbeat");
>
> intel_engine_dump(engine, &p,
> - "%s heartbeat {prio:%d} not ticking\n",
> + "%s heartbeat {seqno:%llx:%lld, prio:%d} not
> ticking\n",
> engine->name,
> + rq->fence.context,
> + rq->fence.seqno,
> rq->sched.attr.priority);
> }
>
> @@ -76,8 +78,19 @@ static void heartbeat(struct work_struct *wrk)
> goto out;
>
> if (engine->heartbeat.systole) {
> - if (engine->schedule &&
> - rq->sched.attr.priority < I915_PRIORITY_BARRIER) {
> + if (!i915_sw_fence_signaled(&rq->submit)) {
> + /*
> + * Not yet submitted, system is stalled.
> + *
> + * This more often happens for ring submission,
> + * where all contexts are funnelled into a common
> + * ringbuffer. If one context is blocked on an
> + * external fence, not only is it not submitted,
> + * but all other contexts, including the kernel
> + * context are stuck waiting for the signal.
> + */
The solution how to save the system evades me.
But piling the heartbeat on top does not help with it in
any case.
Reviewed-by: Mika Kuoppala
> + } else if (engine->schedule &&
> +rq->sched.attr.priority < I915_PRIORITY_BARRIER) {
> /*
>* Gradually raise the priority of the heartbeat to
>* give high priority work [which presumably desires
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Restore both GGTT bindings on resume
== Series Details == Series: drm/i915/gt: Restore both GGTT bindings on resume URL : https://patchwork.freedesktop.org/series/77750/ State : success == Summary == CI Bug Log - changes from CI_DRM_8547 -> Patchwork_17804 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/index.html Known issues Here are the changes found in Patchwork_17804 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (50 -> 43) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8547 -> Patchwork_17804 CI-20190529: 20190529 CI_DRM_8547: 055c59085e117a2433d3862d645e049e30f3a2dc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5682: e5371a99a877be134c6ad5361a5f03843a66f775 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17804: e7cf0f47d10925d3fc7df4ee60361be3c496df0c @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e7cf0f47d109 drm/i915/gt: Restore both GGTT bindings on resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17804/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Mark the buffer pool as active for the cmdparser
== Series Details == Series: drm/i915/gem: Mark the buffer pool as active for the cmdparser URL : https://patchwork.freedesktop.org/series/77749/ State : success == Summary == CI Bug Log - changes from CI_DRM_8547 -> Patchwork_17803 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/index.html Known issues Here are the changes found in Patchwork_17803 that come from known issues: ### IGT changes ### Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [FAIL][1] ([i915#62]) -> [SKIP][2] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8547/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 Participating hosts (50 -> 44) -- Additional (1): fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8547 -> Patchwork_17803 CI-20190529: 20190529 CI_DRM_8547: 055c59085e117a2433d3862d645e049e30f3a2dc @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5682: e5371a99a877be134c6ad5361a5f03843a66f775 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17803: b52716aad58146379ec2bdfef5ad751855a37365 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b52716aad581 drm/i915/gem: Mark the buffer pool as active for the cmdparser == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17803/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Remove local entries from GGTT on suspend
On Thu, 28 May 2020 at 09:24, Chris Wilson wrote: > > Across suspend/resume, we clear the entire GGTT and rebuild from > scratch. In particular, we only preserve the global entries for use by > the HW, and delay reinstating the local binds until required by the > user. This means that we can evict and recover any local binds in the > global GTT, saving any time in preserving their state. > > References: https://gitlab.freedesktop.org/drm/intel/-/issues/1947 > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] drm/i915/gt: Restore both GGTT bindings on resume
We should be able to skip restoing LOCAL (user) binds within the GGTT on
resume and let them be restored upon demand. However, our consistency
checks demand that the bind flags match the node state, and we cannot
simply clear the flags, we need to evict as well. For now, make sure we
restore the bind flags exactly upon resume.
Fixes: 0109a16ef391 ("drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume")
Fixes: bf0840cdb304 ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with
PIN_USER with no-ppgtt")
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 317172ad5ef3..ffe285b0b3bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1183,13 +1183,11 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
/* clflush objects bound into the GGTT and rebind them. */
list_for_each_entry(vma, &ggtt->vm.bound_list, vm_link) {
struct drm_i915_gem_object *obj = vma->obj;
-
- if (!(clear_bind(vma) & I915_VMA_GLOBAL_BIND))
- continue;
+ unsigned int was_bound = clear_bind(vma);
WARN_ON(i915_vma_bind(vma,
obj ? obj->cache_level : 0,
- PIN_GLOBAL, NULL));
+ was_bound, NULL));
if (obj) { /* only used during resume => exclusive access */
flush |= fetch_and_zero(&obj->write_domain);
obj->read_domains |= I915_GEM_DOMAIN_GTT;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gt: Restore both GGTT bindings on resume
On Thu, 28 May 2020 at 09:24, Chris Wilson wrote:
>
> We should be able to skip restoing LOCAL (user) binds within the GGTT on
> resume and let them be restored upon demand. However, our consistency
> checks demand that the bind flags match the node state, and we cannot
> simply clear the flags we need to evict as well. For now, make sure we
> restore the bind flags exactly upon resume.
>
> Fixes: 0109a16ef391 ("drm/i915/gt: Clear LOCAL_BIND from shared GGTT on
> resume")
> Fixes: bf0840cdb304 ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with
> PIN_USER with no-ppgtt")
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Mark the buffer pool as active for the cmdparser
If the execbuf is interrupted after building the cmdparser pipeline, and
before we commit to submitting the request to HW, we would attempt to
clean up the cmdparser early. While we held active references to the vma
being parsed and constructed, we did not hold an active reference for
the buffer pool itself. The result was that an interrupted execbuf could
still have run the cmdparser pipeline, but since the buffer pool was
idle, its target vma could have been recycled.
Note this problem only occurs if the cmdparser is running async due to
pipelined waits on busy fences, and the execbuf is interrupted.
Fixes: 686c7c35abc2 ("drm/i915/gem: Asynchronous cmdparser")
Fixes: 16e87459673a ("drm/i915/gt: Move the batch buffer pool from the engine
to the gt")
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 56 ---
1 file changed, 48 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 219a36995b96..0829ac8a55bf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1987,6 +1987,38 @@ static const struct dma_fence_work_ops eb_parse_ops = {
.release = __eb_parse_release,
};
+static inline int
+__parser_mark_active(struct i915_vma *vma,
+struct intel_timeline *tl,
+struct dma_fence *fence)
+{
+ struct intel_gt_buffer_pool_node *node = vma->private;
+
+ return i915_active_ref(&node->active, tl, fence);
+}
+
+static int
+parser_mark_active(struct eb_parse_work *pw, struct intel_timeline *tl)
+{
+ int err;
+
+ mutex_lock(&tl->mutex);
+
+ err = __parser_mark_active(pw->shadow, tl, &pw->base.dma);
+ if (err)
+ goto unlock;
+
+ if (pw->trampoline) {
+ err = __parser_mark_active(pw->trampoline, tl, &pw->base.dma);
+ if (err)
+ goto unlock;
+ }
+
+unlock:
+ mutex_unlock(&tl->mutex);
+ return err;
+}
+
static int eb_parse_pipeline(struct i915_execbuffer *eb,
struct i915_vma *shadow,
struct i915_vma *trampoline)
@@ -2021,20 +2053,25 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
pw->shadow = shadow;
pw->trampoline = trampoline;
+ /* Mark active refs for this worker, in case we get interrupted */
+ err = parser_mark_active(pw, eb->context->timeline);
+ if (err)
+ goto err_commit;
+
err = dma_resv_lock_interruptible(pw->batch->resv, NULL);
if (err)
- goto err_trampoline;
+ goto err_commit;
err = dma_resv_reserve_shared(pw->batch->resv, 1);
if (err)
- goto err_batch_unlock;
+ goto err_commit_unlock;
/* Wait for all writes (and relocs) into the batch to complete */
err = i915_sw_fence_await_reservation(&pw->base.chain,
pw->batch->resv, NULL, false,
0, I915_FENCE_GFP);
if (err < 0)
- goto err_batch_unlock;
+ goto err_commit_unlock;
/* Keep the batch alive and unwritten as we parse */
dma_resv_add_shared_fence(pw->batch->resv, &pw->base.dma);
@@ -2049,11 +2086,13 @@ static int eb_parse_pipeline(struct i915_execbuffer *eb,
dma_fence_work_commit_imm(&pw->base);
return 0;
-err_batch_unlock:
+err_commit_unlock:
dma_resv_unlock(pw->batch->resv);
-err_trampoline:
- if (trampoline)
- i915_active_release(&trampoline->active);
+err_commit:
+ i915_sw_fence_set_error_once(&pw->base.chain, err);
+ dma_fence_work_commit_imm(&pw->base);
+ return err;
+
err_shadow:
i915_active_release(&shadow->active);
err_batch:
@@ -2099,6 +2138,7 @@ static int eb_parse(struct i915_execbuffer *eb)
goto err;
}
i915_gem_object_set_readonly(shadow->obj);
+ shadow->private = pool;
trampoline = NULL;
if (CMDPARSER_USES_GGTT(eb->i915)) {
@@ -2112,6 +2152,7 @@ static int eb_parse(struct i915_execbuffer *eb)
shadow = trampoline;
goto err_shadow;
}
+ shadow->private = pool;
eb->batch_flags |= I915_DISPATCH_SECURE;
}
@@ -2128,7 +2169,6 @@ static int eb_parse(struct i915_execbuffer *eb)
eb->trampoline = trampoline;
eb->batch_start_offset = 0;
- shadow->private = pool;
return 0;
err_trampoline:
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave & Daniel, Two bigger fixes to corner case kernel access faults and three workload scheduling fixups this week. CI_DINF_191 at: https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/combined-alt.html? I got gvt-next-fixes pull today, I'll pull it next week so it has time to run through CI. PS. Update on igt@i915_selftest@live@gt_pm is that subtest was updated and the added part is failing for now. The granularity of the kernel selftests is short one level from normal IGT due to nature of how they integrate to CI. Regards, Joonas *** drm-intel-next-fixes-2020-05-28: One empty list iteration bug (Cc: stable), One use after free fix and three workload scheduling fixups. The following changes since commit d96536f0fe699729a0974eb5b65eb0d87cc747e1: drm/i915: Fix AUX power domain toggling across TypeC mode resets (2020-05-19 17:54:07 +0300) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2020-05-28 for you to fetch changes up to 757a9395f33c51c4e6eff2c7c0fbd50226a58224: drm/i915/gem: Avoid iterating an empty list (2020-05-25 15:40:43 +0300) One empty list iteration bug (Cc: stable), One use after free fix and three workload scheduling fixups. Chris Wilson (5): drm/i915: Don't set queue-priority hint when supressing the reschedule drm/i915/gt: Remove errant assertion in __intel_context_do_pin drm/i915: Disable semaphore inter-engine sync without timeslicing drm/i915: Avoid using rq->engine after free during i915_fence_release drm/i915/gem: Avoid iterating an empty list drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 ++-- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 15 - drivers/gpu/drm/i915/gt/intel_context.c | 2 -- drivers/gpu/drm/i915/i915_request.c | 35 +++-- drivers/gpu/drm/i915/i915_scheduler.c | 16 ++--- 5 files changed, 52 insertions(+), 20 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 02/17] dma-fence: basic lockdep annotations
On Thu, May 28, 2020 at 3:37 PM Thomas Hellström (Intel) wrote: > > On 2020-05-12 10:59, Daniel Vetter wrote: > > Design is similar to the lockdep annotations for workers, but with > > some twists: > > > > - We use a read-lock for the execution/worker/completion side, so that > >this explicit annotation can be more liberally sprinkled around. > >With read locks lockdep isn't going to complain if the read-side > >isn't nested the same way under all circumstances, so ABBA deadlocks > >are ok. Which they are, since this is an annotation only. > > > > - We're using non-recursive lockdep read lock mode, since in recursive > >read lock mode lockdep does not catch read side hazards. And we > >_very_ much want read side hazards to be caught. For full details of > >this limitation see > > > >commit e91498589746065e3ae95d9a00b068e525eec34f > >Author: Peter Zijlstra > >Date: Wed Aug 23 13:13:11 2017 +0200 > > > >locking/lockdep/selftests: Add mixed read-write ABBA tests > > > > - To allow nesting of the read-side explicit annotations we explicitly > >keep track of the nesting. lock_is_held() allows us to do that. > > > > - The wait-side annotation is a write lock, and entirely done within > >dma_fence_wait() for everyone by default. > > > > - To be able to freely annotate helper functions I want to make it ok > >to call dma_fence_begin/end_signalling from soft/hardirq context. > >First attempt was using the hardirq locking context for the write > >side in lockdep, but this forces all normal spinlocks nested within > >dma_fence_begin/end_signalling to be spinlocks. That bollocks. > > > >The approach now is to simple check in_atomic(), and for these cases > >entirely rely on the might_sleep() check in dma_fence_wait(). That > >will catch any wrong nesting against spinlocks from soft/hardirq > >contexts. > > > > The idea here is that every code path that's critical for eventually > > signalling a dma_fence should be annotated with > > dma_fence_begin/end_signalling. The annotation ideally starts right > > after a dma_fence is published (added to a dma_resv, exposed as a > > sync_file fd, attached to a drm_syncobj fd, or anything else that > > makes the dma_fence visible to other kernel threads), up to and > > including the dma_fence_wait(). Examples are irq handlers, the > > scheduler rt threads, the tail of execbuf (after the corresponding > > fences are visible), any workers that end up signalling dma_fences and > > really anything else. Not annotated should be code paths that only > > complete fences opportunistically as the gpu progresses, like e.g. > > shrinker/eviction code. > > > > The main class of deadlocks this is supposed to catch are: > > > > Thread A: > > > > mutex_lock(A); > > mutex_unlock(A); > > > > dma_fence_signal(); > > > > Thread B: > > > > mutex_lock(A); > > dma_fence_wait(); > > mutex_unlock(A); > > > > Thread B is blocked on A signalling the fence, but A never gets around > > to that because it cannot acquire the lock A. > > > > Note that dma_fence_wait() is allowed to be nested within > > dma_fence_begin/end_signalling sections. To allow this to happen the > > read lock needs to be upgraded to a write lock, which means that any > > other lock is acquired between the dma_fence_begin_signalling() call and > > the call to dma_fence_wait(), and still held, this will result in an > > immediate lockdep complaint. The only other option would be to not > > annotate such calls, defeating the point. Therefore these annotations > > cannot be sprinkled over the code entirely mindless to avoid false > > positives. > > > > v2: handle soft/hardirq ctx better against write side and dont forget > > EXPORT_SYMBOL, drivers can't use this otherwise. > > > > Cc: linux-me...@vger.kernel.org > > Cc: linaro-mm-...@lists.linaro.org > > Cc: linux-r...@vger.kernel.org > > Cc: amd-...@lists.freedesktop.org > > Cc: intel-gfx@lists.freedesktop.org > > Cc: Chris Wilson > > Cc: Maarten Lankhorst > > Cc: Christian König > > Signed-off-by: Daniel Vetter > > LGTM. Perhaps some in-code documentation on how to use the new functions > are called. See cover letter, that's going to be done for next round. For this one here I just wanted to showcase a bit how it's used in a few different places, mostly selected to get as much feedback from across different drivers. Hence e.g. annotating drm/scheduler. > Otherwise for patch 2 and 3, > > Reviewed-by: Thomas Hellstrom I think I'll just cc you for the next round with docs, so you can make sure it looks ok :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove
Hi Chris,
On Thu, 2020-05-28 at 14:41 +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2020-05-28 14:34:42)
> > On 28/05/2020 13:10, Janusz Krzysztofik wrote:
> > > Hi Tvrtko,
> > >
> > > On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> > > > On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> > > > > Contexts associated with open device file descriptors together with
> > > > > their assigned address spaces are now closed on device file close. On
> > > >
> > > > i915_gem_driver_remove looks like module unload to me, not device file
> > > > close. So..
> > >
> > > Not only module unload ...
> > >
> > > > > address space closure its associated DMA mappings are revoked. If the
> > > > > device is removed while being open, subsequent attempts to revoke
> > > > > those mappings while closing the device file descriptor may may be
> > > > > judged by intel-iommu code as a bug and result in kernel panic.
> > > > >
> > > > > Since user contexts become useless after the device is no longer
> > > > > available, drop them on device removal.
> > > > >
> > > > > <4> [36.900985] [ cut here ]
> > > > > <2> [36.901005] kernel BUG at drivers/iommu/intel-iommu.c:3717!
> > > > > <4> [36.901105] invalid opcode: [#1] PREEMPT SMP NOPTI
> > > > > <4> [36.901117] CPU: 0 PID: 39 Comm: kworker/u8:1 Tainted: G U W
> > > > > 5.7.0-rc5-CI-CI_DRM_8485+ #1
> > > > > <4> [36.901133] Hardware name: Intel Corporation Elkhart Lake
> > > > > Embedded Platform/ElkhartLake LPDDR4x T3 CRB, BIOS
> > > > > EHLSFWI1.R00.1484.A00.1911290833 11/29/2019
> > > > > <4> [36.901250] Workqueue: i915 __i915_vm_release [i915]
> > > > > <4> [36.901264] RIP: 0010:intel_unmap+0x1f5/0x230
> > > > > <4> [36.901274] Code: 01 e8 9f bc a9 ff 85 c0 74 09 80 3d df 60 09 01
> > > > > 00 74 19 65 ff 0d 13 12 97 7e 0f 85 fc fe ff ff e8 82 b0 95 ff e9 f2
> > > > > fe ff ff <0f> 0b e8 d4 bd a9 ff 85 c0 75 de 48 c7 c2 10 84 2c 82 be
> > > > > 54 00 00
> > > > > <4> [36.901302] RSP: 0018:c91ebdc0 EFLAGS: 00010246
> > > > > <4> [36.901313] RAX: RBX: 8882561dd000 RCX:
> > > > >
> > > > > <4> [36.901324] RDX: 1000 RSI: ffd9c000 RDI:
> > > > > 888274c94000
> > > > > <4> [36.901336] RBP: 888274c940b0 R08: R09:
> > > > > 0001
> > > > > <4> [36.901348] R10: 0a25d812 R11: 112af2d4 R12:
> > > > > 888252c70200
> > > > > <4> [36.901360] R13: ffd9c000 R14: 1000 R15:
> > > > > 8882561dd010
> > > > > <4> [36.901372] FS: () GS:88827800()
> > > > > knlGS:
> > > > > <4> [36.901386] CS: 0010 DS: ES: CR0: 80050033
> > > > > <4> [36.901396] CR2: 7f06def54950 CR3: 000255844000 CR4:
> > > > > 00340ef0
> > > > > <4> [36.901408] Call Trace:
> > > > > <4> [36.901418] ? process_one_work+0x1de/0x600
> > > > > <4> [36.901494] cleanup_page_dma+0x37/0x70 [i915]
> > > > > <4> [36.901573] free_pd+0x9/0x20 [i915]
> > > > > <4> [36.901644] gen8_ppgtt_cleanup+0x59/0xc0 [i915]
> > > > > <4> [36.901721] __i915_vm_release+0x14/0x30 [i915]
> > > > > <4> [36.901733] process_one_work+0x268/0x600
> > > > > <4> [36.901744] ? __schedule+0x307/0x8d0
> > > > > <4> [36.901756] worker_thread+0x37/0x380
> > > > > <4> [36.901766] ? process_one_work+0x600/0x600
> > > > > <4> [36.901775] kthread+0x140/0x160
> > > > > <4> [36.901783] ? kthread_park+0x80/0x80
> > > > > <4> [36.901792] ret_from_fork+0x24/0x50
> > > > > <4> [36.901804] Modules linked in: mei_hdcp i915 x86_pkg_temp_thermal
> > > > > coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
> > > > > ax88179_178a usbnet mii mei_me mei prime_numbers intel_lpss_pci
> > > > > <4> [36.901857] ---[ end trace 52d1b4d81f8d1ea7 ]---
> > > > >
> > > > > Signed-off-by: Janusz Krzysztofik
> > > > > ---
> > > > >drivers/gpu/drm/i915/gem/i915_gem_context.c | 38
> > > > > +
> > > > >drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 +
> > > > >drivers/gpu/drm/i915/i915_gem.c | 2 ++
> > > > >3 files changed, 41 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > index 900ea8b7fc8f..0096a69fbfd3 100644
> > > > > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > > > > @@ -927,6 +927,44 @@ void i915_gem_driver_release__contexts(struct
> > > > > drm_i915_private *i915)
> > > > > rcu_barrier(); /* and flush the left over RCU frees */
> > > > >}
> > > > >
> > > > > +void i915_gem_driver_remove__contexts(struct drm_i915_private *i915)
> > > > > +{
> > > > > + struct i915_gem_context *ctx, *cn;
> > > > > +
> > > > > + list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link)
> > > > > {
> > > > > + struct drm_i915_file_p
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on resume
== Series Details ==
Series: series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on
resume
URL : https://patchwork.freedesktop.org/series/77734/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8546_full -> Patchwork_17802_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17802_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#1528])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-apl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-apl4/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@vebox.html
* igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen:
- shard-kbl: [PASS][3] -> [FAIL][4] ([i915#54] / [i915#93] /
[i915#95])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [PASS][5] -> [INCOMPLETE][6] ([i915#61])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][7] -> [FAIL][8] ([i915#1188])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-skl8/igt@kms_...@bpc-switch-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-skl8/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][9] -> [DMESG-WARN][10] ([i915#180])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-apl4/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-apl8/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265])
+1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-iclb3/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_setmode@basic:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#31])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-skl2/igt@kms_setm...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-skl10/igt@kms_setm...@basic.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-apl: [FAIL][17] ([i915#1930]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-apl3/igt@gem_exec_re...@basic-concurrent0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-apl1/igt@gem_exec_re...@basic-concurrent0.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-skl: [INCOMPLETE][19] ([i915#69]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-skl10/igt@gem_workarou...@suspend-resume-fd.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-skl6/igt@gem_workarou...@suspend-resume-fd.html
* igt@kms_big_fb@y-tiled-addfb-size-overflow:
- shard-glk: [TIMEOUT][21] ([i915#1958]) -> [PASS][22] +4 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-glk2/igt@kms_big...@y-tiled-addfb-size-overflow.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-glk6/igt@kms_big...@y-tiled-addfb-size-overflow.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-snb: [INCOMPLETE][23] ([i915#82]) -> [PASS][24] +2 similar
issues
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/shard-snb1/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/shard-snb2/i
Re: [Intel-gfx] [RFC 02/17] dma-fence: basic lockdep annotations
On 2020-05-12 10:59, Daniel Vetter wrote: Design is similar to the lockdep annotations for workers, but with some twists: - We use a read-lock for the execution/worker/completion side, so that this explicit annotation can be more liberally sprinkled around. With read locks lockdep isn't going to complain if the read-side isn't nested the same way under all circumstances, so ABBA deadlocks are ok. Which they are, since this is an annotation only. - We're using non-recursive lockdep read lock mode, since in recursive read lock mode lockdep does not catch read side hazards. And we _very_ much want read side hazards to be caught. For full details of this limitation see commit e91498589746065e3ae95d9a00b068e525eec34f Author: Peter Zijlstra Date: Wed Aug 23 13:13:11 2017 +0200 locking/lockdep/selftests: Add mixed read-write ABBA tests - To allow nesting of the read-side explicit annotations we explicitly keep track of the nesting. lock_is_held() allows us to do that. - The wait-side annotation is a write lock, and entirely done within dma_fence_wait() for everyone by default. - To be able to freely annotate helper functions I want to make it ok to call dma_fence_begin/end_signalling from soft/hardirq context. First attempt was using the hardirq locking context for the write side in lockdep, but this forces all normal spinlocks nested within dma_fence_begin/end_signalling to be spinlocks. That bollocks. The approach now is to simple check in_atomic(), and for these cases entirely rely on the might_sleep() check in dma_fence_wait(). That will catch any wrong nesting against spinlocks from soft/hardirq contexts. The idea here is that every code path that's critical for eventually signalling a dma_fence should be annotated with dma_fence_begin/end_signalling. The annotation ideally starts right after a dma_fence is published (added to a dma_resv, exposed as a sync_file fd, attached to a drm_syncobj fd, or anything else that makes the dma_fence visible to other kernel threads), up to and including the dma_fence_wait(). Examples are irq handlers, the scheduler rt threads, the tail of execbuf (after the corresponding fences are visible), any workers that end up signalling dma_fences and really anything else. Not annotated should be code paths that only complete fences opportunistically as the gpu progresses, like e.g. shrinker/eviction code. The main class of deadlocks this is supposed to catch are: Thread A: mutex_lock(A); mutex_unlock(A); dma_fence_signal(); Thread B: mutex_lock(A); dma_fence_wait(); mutex_unlock(A); Thread B is blocked on A signalling the fence, but A never gets around to that because it cannot acquire the lock A. Note that dma_fence_wait() is allowed to be nested within dma_fence_begin/end_signalling sections. To allow this to happen the read lock needs to be upgraded to a write lock, which means that any other lock is acquired between the dma_fence_begin_signalling() call and the call to dma_fence_wait(), and still held, this will result in an immediate lockdep complaint. The only other option would be to not annotate such calls, defeating the point. Therefore these annotations cannot be sprinkled over the code entirely mindless to avoid false positives. v2: handle soft/hardirq ctx better against write side and dont forget EXPORT_SYMBOL, drivers can't use this otherwise. Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Cc: linux-r...@vger.kernel.org Cc: amd-...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: Chris Wilson Cc: Maarten Lankhorst Cc: Christian König Signed-off-by: Daniel Vetter LGTM. Perhaps some in-code documentation on how to use the new functions are called. Otherwise for patch 2 and 3, Reviewed-by: Thomas Hellstrom ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove
Quoting Tvrtko Ursulin (2020-05-28 14:34:42)
>
> On 28/05/2020 13:10, Janusz Krzysztofik wrote:
> > Hi Tvrtko,
> >
> > On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> >> On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> >>> Contexts associated with open device file descriptors together with
> >>> their assigned address spaces are now closed on device file close. On
> >>
> >> i915_gem_driver_remove looks like module unload to me, not device file
> >> close. So..
> >
> > Not only module unload ...
> >
> >>
> >>> address space closure its associated DMA mappings are revoked. If the
> >>> device is removed while being open, subsequent attempts to revoke
> >>> those mappings while closing the device file descriptor may may be
> >>> judged by intel-iommu code as a bug and result in kernel panic.
> >>>
> >>> Since user contexts become useless after the device is no longer
> >>> available, drop them on device removal.
> >>>
> >>> <4> [36.900985] [ cut here ]
> >>> <2> [36.901005] kernel BUG at drivers/iommu/intel-iommu.c:3717!
> >>> <4> [36.901105] invalid opcode: [#1] PREEMPT SMP NOPTI
> >>> <4> [36.901117] CPU: 0 PID: 39 Comm: kworker/u8:1 Tainted: G U W
> >>> 5.7.0-rc5-CI-CI_DRM_8485+ #1
> >>> <4> [36.901133] Hardware name: Intel Corporation Elkhart Lake Embedded
> >>> Platform/ElkhartLake LPDDR4x T3 CRB, BIOS
> >>> EHLSFWI1.R00.1484.A00.1911290833 11/29/2019
> >>> <4> [36.901250] Workqueue: i915 __i915_vm_release [i915]
> >>> <4> [36.901264] RIP: 0010:intel_unmap+0x1f5/0x230
> >>> <4> [36.901274] Code: 01 e8 9f bc a9 ff 85 c0 74 09 80 3d df 60 09 01 00
> >>> 74 19 65 ff 0d 13 12 97 7e 0f 85 fc fe ff ff e8 82 b0 95 ff e9 f2 fe ff
> >>> ff <0f> 0b e8 d4 bd a9 ff 85 c0 75 de 48 c7 c2 10 84 2c 82 be 54 00 00
> >>> <4> [36.901302] RSP: 0018:c91ebdc0 EFLAGS: 00010246
> >>> <4> [36.901313] RAX: RBX: 8882561dd000 RCX:
> >>>
> >>> <4> [36.901324] RDX: 1000 RSI: ffd9c000 RDI:
> >>> 888274c94000
> >>> <4> [36.901336] RBP: 888274c940b0 R08: R09:
> >>> 0001
> >>> <4> [36.901348] R10: 0a25d812 R11: 112af2d4 R12:
> >>> 888252c70200
> >>> <4> [36.901360] R13: ffd9c000 R14: 1000 R15:
> >>> 8882561dd010
> >>> <4> [36.901372] FS: () GS:88827800()
> >>> knlGS:
> >>> <4> [36.901386] CS: 0010 DS: ES: CR0: 80050033
> >>> <4> [36.901396] CR2: 7f06def54950 CR3: 000255844000 CR4:
> >>> 00340ef0
> >>> <4> [36.901408] Call Trace:
> >>> <4> [36.901418] ? process_one_work+0x1de/0x600
> >>> <4> [36.901494] cleanup_page_dma+0x37/0x70 [i915]
> >>> <4> [36.901573] free_pd+0x9/0x20 [i915]
> >>> <4> [36.901644] gen8_ppgtt_cleanup+0x59/0xc0 [i915]
> >>> <4> [36.901721] __i915_vm_release+0x14/0x30 [i915]
> >>> <4> [36.901733] process_one_work+0x268/0x600
> >>> <4> [36.901744] ? __schedule+0x307/0x8d0
> >>> <4> [36.901756] worker_thread+0x37/0x380
> >>> <4> [36.901766] ? process_one_work+0x600/0x600
> >>> <4> [36.901775] kthread+0x140/0x160
> >>> <4> [36.901783] ? kthread_park+0x80/0x80
> >>> <4> [36.901792] ret_from_fork+0x24/0x50
> >>> <4> [36.901804] Modules linked in: mei_hdcp i915 x86_pkg_temp_thermal
> >>> coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ax88179_178a
> >>> usbnet mii mei_me mei prime_numbers intel_lpss_pci
> >>> <4> [36.901857] ---[ end trace 52d1b4d81f8d1ea7 ]---
> >>>
> >>> Signed-off-by: Janusz Krzysztofik
> >>> ---
> >>>drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +
> >>>drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 +
> >>>drivers/gpu/drm/i915/i915_gem.c | 2 ++
> >>>3 files changed, 41 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> index 900ea8b7fc8f..0096a69fbfd3 100644
> >>> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >>> @@ -927,6 +927,44 @@ void i915_gem_driver_release__contexts(struct
> >>> drm_i915_private *i915)
> >>> rcu_barrier(); /* and flush the left over RCU frees */
> >>>}
> >>>
> >>> +void i915_gem_driver_remove__contexts(struct drm_i915_private *i915)
> >>> +{
> >>> + struct i915_gem_context *ctx, *cn;
> >>> +
> >>> + list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link) {
> >>> + struct drm_i915_file_private *file_priv = ctx->file_priv;
> >>> + struct i915_gem_context *entry;
> >>> + unsigned long int id;
> >>> +
> >>> + if (i915_gem_context_is_closed(ctx) || IS_ERR(file_priv))
> >>> + continue;
> >>> +
> >>> + xa_for_each(&file_priv->context_xa, id, entry) {
> >>
> >> ... how is driver unload possible with open drm file descriptors, or
> >> active contexts?
> >
> > ... but also
Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove
On 28/05/2020 13:10, Janusz Krzysztofik wrote:
Hi Tvrtko,
On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
On 18/05/2020 19:17, Janusz Krzysztofik wrote:
Contexts associated with open device file descriptors together with
their assigned address spaces are now closed on device file close. On
i915_gem_driver_remove looks like module unload to me, not device file
close. So..
Not only module unload ...
address space closure its associated DMA mappings are revoked. If the
device is removed while being open, subsequent attempts to revoke
those mappings while closing the device file descriptor may may be
judged by intel-iommu code as a bug and result in kernel panic.
Since user contexts become useless after the device is no longer
available, drop them on device removal.
<4> [36.900985] [ cut here ]
<2> [36.901005] kernel BUG at drivers/iommu/intel-iommu.c:3717!
<4> [36.901105] invalid opcode: [#1] PREEMPT SMP NOPTI
<4> [36.901117] CPU: 0 PID: 39 Comm: kworker/u8:1 Tainted: G U W
5.7.0-rc5-CI-CI_DRM_8485+ #1
<4> [36.901133] Hardware name: Intel Corporation Elkhart Lake Embedded
Platform/ElkhartLake LPDDR4x T3 CRB, BIOS EHLSFWI1.R00.1484.A00.1911290833 11/29/2019
<4> [36.901250] Workqueue: i915 __i915_vm_release [i915]
<4> [36.901264] RIP: 0010:intel_unmap+0x1f5/0x230
<4> [36.901274] Code: 01 e8 9f bc a9 ff 85 c0 74 09 80 3d df 60 09 01 00 74 19 65 ff
0d 13 12 97 7e 0f 85 fc fe ff ff e8 82 b0 95 ff e9 f2 fe ff ff <0f> 0b e8 d4 bd a9 ff
85 c0 75 de 48 c7 c2 10 84 2c 82 be 54 00 00
<4> [36.901302] RSP: 0018:c91ebdc0 EFLAGS: 00010246
<4> [36.901313] RAX: RBX: 8882561dd000 RCX:
<4> [36.901324] RDX: 1000 RSI: ffd9c000 RDI:
888274c94000
<4> [36.901336] RBP: 888274c940b0 R08: R09:
0001
<4> [36.901348] R10: 0a25d812 R11: 112af2d4 R12:
888252c70200
<4> [36.901360] R13: ffd9c000 R14: 1000 R15:
8882561dd010
<4> [36.901372] FS: () GS:88827800()
knlGS:
<4> [36.901386] CS: 0010 DS: ES: CR0: 80050033
<4> [36.901396] CR2: 7f06def54950 CR3: 000255844000 CR4:
00340ef0
<4> [36.901408] Call Trace:
<4> [36.901418] ? process_one_work+0x1de/0x600
<4> [36.901494] cleanup_page_dma+0x37/0x70 [i915]
<4> [36.901573] free_pd+0x9/0x20 [i915]
<4> [36.901644] gen8_ppgtt_cleanup+0x59/0xc0 [i915]
<4> [36.901721] __i915_vm_release+0x14/0x30 [i915]
<4> [36.901733] process_one_work+0x268/0x600
<4> [36.901744] ? __schedule+0x307/0x8d0
<4> [36.901756] worker_thread+0x37/0x380
<4> [36.901766] ? process_one_work+0x600/0x600
<4> [36.901775] kthread+0x140/0x160
<4> [36.901783] ? kthread_park+0x80/0x80
<4> [36.901792] ret_from_fork+0x24/0x50
<4> [36.901804] Modules linked in: mei_hdcp i915 x86_pkg_temp_thermal coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ax88179_178a usbnet mii mei_me mei
prime_numbers intel_lpss_pci
<4> [36.901857] ---[ end trace 52d1b4d81f8d1ea7 ]---
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +
drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 2 ++
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..0096a69fbfd3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -927,6 +927,44 @@ void i915_gem_driver_release__contexts(struct
drm_i915_private *i915)
rcu_barrier(); /* and flush the left over RCU frees */
}
+void i915_gem_driver_remove__contexts(struct drm_i915_private *i915)
+{
+ struct i915_gem_context *ctx, *cn;
+
+ list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link) {
+ struct drm_i915_file_private *file_priv = ctx->file_priv;
+ struct i915_gem_context *entry;
+ unsigned long int id;
+
+ if (i915_gem_context_is_closed(ctx) || IS_ERR(file_priv))
+ continue;
+
+ xa_for_each(&file_priv->context_xa, id, entry) {
... how is driver unload possible with open drm file descriptors, or
active contexts?
... but also PCI driver unbind or PCI device remove, with the module
still loaded. That may perfectly happen even if a device file
descriptor is still kept open.
I see. What do we do, or plan to do, with those left open drm fds after
the driver is unbound from the device? Is there a path connected to keep
saying -ENODEV (Or is a different errno standard for this case, like
ENXIO?) from that point onward for everything done with that fd. So
userspace couldn't do anything more with it, attempt to create a new
context etc. Is the DRM core handling this?
Regards,
Tvrtko
If something i
Re: [Intel-gfx] [RFC] GPU-bound energy efficiency improvements for the intel_pstate driver (v2.99)
On 5/15/20 7:09 PM, Valentin Schneider wrote: On 15/05/20 01:48, Francisco Jerez wrote: Valentin Schneider writes: (+Lukasz) On 11/05/20 22:01, Francisco Jerez wrote: What I'm missing is an explanation for why this isn't using the infrastructure that was build for these kinds of things? The thermal framework, was AFAIU, supposed to help with these things, and the IPA thing in particular is used by ARM to do exactly this GPU/CPU power budget thing. If thermal/IPA is found wanting, why aren't we improving that? The GPU/CPU power budget "thing" is only a positive side effect of this series on some TDP-bound systems. Its ultimate purpose is improving the energy efficiency of workloads which have a bottleneck on a device other than the CPU, by giving the bottlenecking device driver some influence over the response latency of CPUFREQ governors via a PM QoS interface. This seems to be completely outside the scope of the thermal framework and IPA AFAIU. It's been a while since I've stared at IPA, but it does sound vaguely familiar. When thermally constrained, IPA figures out a budget and splits it between actors (cpufreq and devfreq devices) depending on how much juice they are asking for; see cpufreq_get_requested_power() and devfreq_cooling_get_requested_power(). There's also some weighing involved. I'm aware of those. Main problem is that the current mechanism for IPA to figure out the requested power of each actor is based on a rough estimate of their past power consumption: If an actor was operating at a highly energy-inefficient regime it will end up requesting more power than another actor with the same load but more energy-efficient behavior. This can be tweaked by changing the weight of an actor (unfortunately not in a real-time by kernel). We usually setup them once, in DT. So, it's possible to set different weight for the LITTLE cores (which are more energy-efficient) and the big cores (in a good way or bad). Right, we do mix load (busy time for either cpufreq and devfreq devices AFAIR) and current state (freq) into one single power value. The IPA power allocator is therefore ineffective at improving the energy efficiency of an agent beyond its past behavior -- Furthermore it seems to *rely* on individual agents being somewhat energetically responsible in order for its power allocation result to be anywhere close to optimal. But improving the energy efficiency of an agent seems useful in its own right, whether IPA is used to balance power across agents or not. That's precisely the purpose of this series. I don't fully agree here, i.e. in a properly setup platform we promote more energy-efficient LITTLE cores when there is a limited power budget. That would cause capping on big cores and scheduler should see it. There are some limitations in the IPA, but the requirements where different back then, mainline code was different, etc. If you look at the cpufreq cooling side of things, you'll see it also uses the PM QoS interface. For instance, should IPA decide to cap the CPUs (perhaps because say the GPU is the one drawing most of the juice), it'll lead to a maximum frequency capping request. So it does sound like that's what you want, only not just when thermally constrained. Capping the CPU frequency from random device drivers is highly problematic, because the CPU is a shared resource which a number of different concurrent applications might be using beyond the GPU client. The GPU driver has no visibility over its impact on the performance of other applications. And even in a single-task environment, in order to behave as effectively as the present series the GPU driver would need to monitor the utilization of *all* CPUs in the system and place a frequency constraint on each one of them (since there is the potential of the task scheduler migrating the process from one CPU to another without notice). Furthermore these frequency constraints would need to be updated at high frequency in order to avoid performance degradation whenever the balance of load between CPU and IO device fluctuates. The present series attempts to remove the burden of computing frequency constraints out of individual device drivers into the CPUFREQ governor. Instead the device driver provides a response latency constraint when it encounters a bottleneck, which can be more easily derived from hardware and protocol characteristics than a CPU frequency. PM QoS aggregates the response latency constraints provided by all applications and gives CPUFREQ a single response latency target compatible with all of them (so a device driver specifying a high latency target won't lead to performance degradation in a concurrent application with lower latency constraints). The CPUFREQ governor then computes frequency constraints for each CPU core that minimize energy usage without limiting throughput, based on the results obtained from CPU performance counters, while guaranteeing that a discontinuous tr
Re: [Intel-gfx] [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
> -Original Message- > From: Greg KH > Sent: Wednesday, May 27, 2020 9:02 PM > To: Ashwin H > Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; intel- > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org; > Srivatsa Bhat ; sriva...@csail.mit.edu; > rost...@goodmis.org; Steven Rostedt ; Linus > Torvalds > Subject: Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' > > On Wed, May 13, 2020 at 05:08:19PM +, Ashwin H wrote: > > > Ok, but what does that mean for us? > > > > > > You need to say why you are sending a patch, otherwise we will guess > wrong. > > > > In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does > user_access_begin() without doing access_ok(Checks if a user space pointer > is valid) first. > > A local attacker can craft a malicious ioctl function call to > > overwrite arbitrary kernel memory, resulting in a Denial of Service or > > privilege escalation (CVE-2018-20669) > > > > This patch makes sure that user_access_begin always does access_ok. > > user_access_begin has been modified to do access_ok internally. > > I had this in the tree, but it broke the build on alpha, sh, and maybe a few > others :( > Thanks Greg for including this patch. I am sorry that this patch caused the failure. As I see this is not a build failure but tests have failed. Build results: total: 155 pass: 155 fail: 0 Qemu test results: total: 421 pass: 390 fail: 31 Failed tests: > See: > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F > %2Flore.kernel.org%2Fr%2F20200527140225.GA214763%40roeck- > us.net&data=02%7C01%7Cashwinh%40vmware.com%7Cd8f60bb8a4584 > 7caa10f08d802530997%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7 > C637261902960990057&sdata=Vjv9v0QhebfcOGSq1UUDKshTDA%2FOV > 4aKbqzKKJkEQxM%3D&reserved=0 > for the details. > > Can you dig out all of the needed follow-on patches as well, and send them > all as a patch series for 4.19.y so that I can queue them all up at once? > I will check for follow-on patches and get back. > thanks, > > greg k-h Thanks, Ashwin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'
> -Original Message- > From: Ashwin H > Sent: Thursday, May 28, 2020 1:01 PM > To: Greg KH > Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; intel- > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; sta...@kernel.org; > Srivatsa Bhat ; sriva...@csail.mit.edu; > rost...@goodmis.org; Steven Rostedt ; Linus > Torvalds > Subject: RE: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' > > > > > -Original Message- > > From: Greg KH > > Sent: Wednesday, May 27, 2020 9:02 PM > > To: Ashwin H > > Cc: x...@kernel.org; dri-de...@lists.freedesktop.org; intel- > > g...@lists.freedesktop.org; linux-ker...@vger.kernel.org; > > sta...@kernel.org; Srivatsa Bhat ; > > sriva...@csail.mit.edu; rost...@goodmis.org; Steven Rostedt > > ; Linus Torvalds > > Subject: Re: [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()' > > > > On Wed, May 13, 2020 at 05:08:19PM +, Ashwin H wrote: > > > > Ok, but what does that mean for us? > > > > > > > > You need to say why you are sending a patch, otherwise we will > > > > guess > > wrong. > > > > > > In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does > > user_access_begin() without doing access_ok(Checks if a user space > > pointer is valid) first. > > > A local attacker can craft a malicious ioctl function call to > > > overwrite arbitrary kernel memory, resulting in a Denial of Service > > > or privilege escalation (CVE-2018-20669) > > > > > > This patch makes sure that user_access_begin always does access_ok. > > > user_access_begin has been modified to do access_ok internally. > > > > I had this in the tree, but it broke the build on alpha, sh, and maybe > > a few others :( > > > Thanks Greg for including this patch. > I am sorry that this patch caused the failure. As I see this is not a build > failure > but tests have failed. > Build results: > total: 155 pass: 155 fail: 0 > Qemu test results: > total: 421 pass: 390 fail: 31 > Failed tests: > > > > > > See: > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F > > %2Flore.kernel.org%2Fr%2F20200527140225.GA214763%40roeck- > > > us.net&data=02%7C01%7Cashwinh%40vmware.com%7Cd8f60bb8a4584 > > > 7caa10f08d802530997%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7 > > > C637261902960990057&sdata=Vjv9v0QhebfcOGSq1UUDKshTDA%2FOV > > 4aKbqzKKJkEQxM%3D&reserved=0 > > for the details. > > > > Can you dig out all of the needed follow-on patches as well, and send > > them all as a patch series for 4.19.y so that I can queue them all up at > > once? > > > > I will check for follow-on patches and get back. This seems to be the issue in alpha and SH https://lore.kernel.org/lkml/6a4fe075-a644-1b06-305b-9e55b8c95...@roeck-us.net/#t alpha and SH had buggy implementation of access_ok Thanks, Ashwin > > > thanks, > > > > greg k-h > > Thanks, > Ashwin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf
Hi Am 27.05.20 um 21:34 schrieb Daniel Vetter: > On Wed, May 27, 2020 at 8:32 PM Thomas Zimmermann wrote: >> >> Hi Daniel, >> >> what's your plan for this patch set? I'd need this patch for the udl >> shmem cleanup. > > I was pinging some people for a tested-by, I kinda don't want to push > this entirely untested. I think at least one of the rendering drivers > using shmem would be nice to run this on, I've pinged Rob Herring a > bit. OK, makes sense. FWIW I tested the patchset with udl as secondary adapter. No problems noticed. Tested-by: Thomas Zimmermann Best regards Thomas > -Daniel > >> >> Best regards >> Thomas >> >> Am 11.05.20 um 11:35 schrieb Daniel Vetter: >>> Currently this seems to work by converting the sgt into a pages array, >>> and then treating it like a native object. Do the right thing and >>> redirect mmap to the exporter. >>> >>> With this nothing is calling get_pages anymore on imported dma-buf, >>> and we can start to remove the use of the ->pages array for that case. >>> >>> v2: Rebase >>> >>> Cc: Gerd Hoffmann >>> Cc: Rob Herring >>> Cc: Noralf Trønnes >>> Signed-off-by: Daniel Vetter >>> --- >>> drivers/gpu/drm/drm_gem_shmem_helper.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c >>> b/drivers/gpu/drm/drm_gem_shmem_helper.c >>> index b9cba5cc61c3..117a7841e284 100644 >>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c >>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c >>> @@ -551,6 +551,9 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, >>> struct vm_area_struct *vma) >>> /* Remove the fake offset */ >>> vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node); >>> >>> + if (obj->import_attach) >>> + return dma_buf_mmap(obj->dma_buf, vma, 0); >>> + >>> shmem = to_drm_gem_shmem_obj(obj); >>> >>> ret = drm_gem_shmem_get_pages(shmem); >>> >> >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 Nürnberg, Germany >> (HRB 36809, AG Nürnberg) >> Geschäftsführer: Felix Imendörffer >> > > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove
Hi Tvrtko,
On Thu, 2020-05-28 at 11:14 +0100, Tvrtko Ursulin wrote:
> On 18/05/2020 19:17, Janusz Krzysztofik wrote:
> > Contexts associated with open device file descriptors together with
> > their assigned address spaces are now closed on device file close. On
>
> i915_gem_driver_remove looks like module unload to me, not device file
> close. So..
Not only module unload ...
>
> > address space closure its associated DMA mappings are revoked. If the
> > device is removed while being open, subsequent attempts to revoke
> > those mappings while closing the device file descriptor may may be
> > judged by intel-iommu code as a bug and result in kernel panic.
> >
> > Since user contexts become useless after the device is no longer
> > available, drop them on device removal.
> >
> > <4> [36.900985] [ cut here ]
> > <2> [36.901005] kernel BUG at drivers/iommu/intel-iommu.c:3717!
> > <4> [36.901105] invalid opcode: [#1] PREEMPT SMP NOPTI
> > <4> [36.901117] CPU: 0 PID: 39 Comm: kworker/u8:1 Tainted: G U W
> > 5.7.0-rc5-CI-CI_DRM_8485+ #1
> > <4> [36.901133] Hardware name: Intel Corporation Elkhart Lake Embedded
> > Platform/ElkhartLake LPDDR4x T3 CRB, BIOS EHLSFWI1.R00.1484.A00.1911290833
> > 11/29/2019
> > <4> [36.901250] Workqueue: i915 __i915_vm_release [i915]
> > <4> [36.901264] RIP: 0010:intel_unmap+0x1f5/0x230
> > <4> [36.901274] Code: 01 e8 9f bc a9 ff 85 c0 74 09 80 3d df 60 09 01 00 74
> > 19 65 ff 0d 13 12 97 7e 0f 85 fc fe ff ff e8 82 b0 95 ff e9 f2 fe ff ff
> > <0f> 0b e8 d4 bd a9 ff 85 c0 75 de 48 c7 c2 10 84 2c 82 be 54 00 00
> > <4> [36.901302] RSP: 0018:c91ebdc0 EFLAGS: 00010246
> > <4> [36.901313] RAX: RBX: 8882561dd000 RCX:
> >
> > <4> [36.901324] RDX: 1000 RSI: ffd9c000 RDI:
> > 888274c94000
> > <4> [36.901336] RBP: 888274c940b0 R08: R09:
> > 0001
> > <4> [36.901348] R10: 0a25d812 R11: 112af2d4 R12:
> > 888252c70200
> > <4> [36.901360] R13: ffd9c000 R14: 1000 R15:
> > 8882561dd010
> > <4> [36.901372] FS: () GS:88827800()
> > knlGS:
> > <4> [36.901386] CS: 0010 DS: ES: CR0: 80050033
> > <4> [36.901396] CR2: 7f06def54950 CR3: 000255844000 CR4:
> > 00340ef0
> > <4> [36.901408] Call Trace:
> > <4> [36.901418] ? process_one_work+0x1de/0x600
> > <4> [36.901494] cleanup_page_dma+0x37/0x70 [i915]
> > <4> [36.901573] free_pd+0x9/0x20 [i915]
> > <4> [36.901644] gen8_ppgtt_cleanup+0x59/0xc0 [i915]
> > <4> [36.901721] __i915_vm_release+0x14/0x30 [i915]
> > <4> [36.901733] process_one_work+0x268/0x600
> > <4> [36.901744] ? __schedule+0x307/0x8d0
> > <4> [36.901756] worker_thread+0x37/0x380
> > <4> [36.901766] ? process_one_work+0x600/0x600
> > <4> [36.901775] kthread+0x140/0x160
> > <4> [36.901783] ? kthread_park+0x80/0x80
> > <4> [36.901792] ret_from_fork+0x24/0x50
> > <4> [36.901804] Modules linked in: mei_hdcp i915 x86_pkg_temp_thermal
> > coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ax88179_178a
> > usbnet mii mei_me mei prime_numbers intel_lpss_pci
> > <4> [36.901857] ---[ end trace 52d1b4d81f8d1ea7 ]---
> >
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +
> > drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 +
> > drivers/gpu/drm/i915/i915_gem.c | 2 ++
> > 3 files changed, 41 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 900ea8b7fc8f..0096a69fbfd3 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -927,6 +927,44 @@ void i915_gem_driver_release__contexts(struct
> > drm_i915_private *i915)
> > rcu_barrier(); /* and flush the left over RCU frees */
> > }
> >
> > +void i915_gem_driver_remove__contexts(struct drm_i915_private *i915)
> > +{
> > + struct i915_gem_context *ctx, *cn;
> > +
> > + list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link) {
> > + struct drm_i915_file_private *file_priv = ctx->file_priv;
> > + struct i915_gem_context *entry;
> > + unsigned long int id;
> > +
> > + if (i915_gem_context_is_closed(ctx) || IS_ERR(file_priv))
> > + continue;
> > +
> > + xa_for_each(&file_priv->context_xa, id, entry) {
>
> ... how is driver unload possible with open drm file descriptors, or
> active contexts?
... but also PCI driver unbind or PCI device remove, with the module
still loaded. That may perfectly happen even if a device file
descriptor is still kept open.
> If something is going wrong sounds like something else.
I think we might consider that "something" as intel-iommu code, but see
also the last paragraph of my response be
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, Daniel, Here's this week drm-misc-fixes PR. Thanks! Maxime drm-misc-fixes-2020-05-28: Two ingenic fixes, one for a wrong cast, the other for a typo in a comparison The following changes since commit c54a8f1f329197d83d941ad84c4aa38bf282cbbd: drm/meson: pm resume add return errno branch (2020-05-13 12:00:37 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-05-28 for you to fetch changes up to abf56fadf0e208abfb13ad1ac0094416058da0ad: gpu/drm: Ingenic: Fix opaque pointer casted to wrong type (2020-05-17 14:16:15 +0200) Two ingenic fixes, one for a wrong cast, the other for a typo in a comparison Paul Cercueil (2): gpu/drm: ingenic: Fix bogus crtc_atomic_check callback gpu/drm: Ingenic: Fix opaque pointer casted to wrong type drivers/gpu/drm/ingenic/ingenic-drm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/11] drm/i915/gt: Prevent timeslicing into unpreemptable requests
== Series Details == Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into unpreemptable requests URL : https://patchwork.freedesktop.org/series/77729/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8545_full -> Patchwork_17800_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17800_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17800_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17800_full: ### IGT changes ### Possible regressions * igt@gem_ctx_engines@execute-oneforall: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-apl7/igt@gem_ctx_engi...@execute-oneforall.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-apl7/igt@gem_ctx_engi...@execute-oneforall.html - shard-hsw: [PASS][3] -> [FAIL][4] +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-hsw1/igt@gem_ctx_engi...@execute-oneforall.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-hsw8/igt@gem_ctx_engi...@execute-oneforall.html * igt@gem_linear_blits@interruptible: - shard-apl: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-apl4/igt@gem_linear_bl...@interruptible.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-apl7/igt@gem_linear_bl...@interruptible.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][7] -> [DMESG-FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html New tests - New tests have been introduced between CI_DRM_8545_full and Patchwork_17800_full: ### New IGT tests (1) ### * igt@dmabuf@all@dma_fence_proxy: - Statuses : 8 pass(s) - Exec time: [0.03, 0.12] s Known issues Here are the changes found in Patchwork_17800_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_linear_blits@interruptible: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#1263]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-kbl3/igt@gem_linear_bl...@interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-kbl6/igt@gem_linear_bl...@interruptible.html - shard-hsw: [PASS][11] -> [FAIL][12] ([i915#1263]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-hsw1/igt@gem_linear_bl...@interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-hsw8/igt@gem_linear_bl...@interruptible.html - shard-glk: [PASS][13] -> [INCOMPLETE][14] ([i915#58] / [k.org#198133]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-glk5/igt@gem_linear_bl...@interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-glk7/igt@gem_linear_bl...@interruptible.html * igt@i915_pm_rps@reset: - shard-hsw: [PASS][15] -> [FAIL][16] ([i915#39]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-hsw2/igt@i915_pm_...@reset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-hsw7/igt@i915_pm_...@reset.html * igt@i915_suspend@debugfs-reader: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#69]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-skl8/igt@i915_susp...@debugfs-reader.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-skl1/igt@i915_susp...@debugfs-reader.html * igt@kms_big_fb@y-tiled-64bpp-rotate-0: - shard-glk: [PASS][19] -> [FAIL][20] ([i915#1119] / [i915#118] / [i915#95]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-glk7/igt@kms_big...@y-tiled-64bpp-rotate-0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-glk8/igt@kms_big...@y-tiled-64bpp-rotate-0.html * igt@kms_cursor_crc@pipe-a-cursor-256x85-offscreen: - shard-kbl: [PASS][21] -> [FAIL][22] ([i915#54] / [i915#93] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/shard-kbl7/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/shard-kbl3/igt@kms_cursor_...@pipe-a-cursor-256x85-offscreen.html * igt@kms_cursor_crc@pipe-c
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on resume
== Series Details == Series: series starting with [1/2] drm/i915/gt: Restore both GGTT bindings on resume URL : https://patchwork.freedesktop.org/series/77734/ State : success == Summary == CI Bug Log - changes from CI_DRM_8546 -> Patchwork_17802 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/index.html Known issues Here are the changes found in Patchwork_17802 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@coherency: - fi-gdg-551: [PASS][1] -> [DMESG-FAIL][2] ([i915#1748]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/fi-gdg-551/igt@i915_selftest@l...@coherency.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/fi-gdg-551/igt@i915_selftest@l...@coherency.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-kbl-guc: [FAIL][3] ([i915#138]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8546/fi-kbl-guc/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/fi-kbl-guc/igt@i915_pm_...@module-reload.html [i915#138]: https://gitlab.freedesktop.org/drm/intel/issues/138 [i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748 Participating hosts (51 -> 43) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8546 -> Patchwork_17802 CI-20190529: 20190529 CI_DRM_8546: 08f7fbd2ef0e82c13fd6e3bd6d7438a14746ae42 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5681: 2991a5d60b1bbf2b2b6004669cd0f9471bd687a2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17802: 46d403b2a10e5d755907017720e1ddb14d3590ac @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 46d403b2a10e drm/i915/gt: Remove local entries from GGTT on suspend 8b64f8f634ee drm/i915/gt: Restore both GGTT bindings on resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17802/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Special handling for bonded requests
On 28/05/2020 10:57, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
+static void
+mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
+{
+ /*
+* Give (temporary) special meaning to a pair requests with requested
+* aligned start along the video engines.
+*
+* They should be non-preemptable and have all ELSP ports to themselves
+* to avoid any deadlocks caused by inversions.
+*
+* Gen11+
+*/
+ if (INTEL_GEN(rq->i915) < 11 ||
+ rq->engine->class != VIDEO_DECODE_CLASS ||
+ rq->engine->class != signal->engine->class)
+ return;
+
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, &rq->fence.flags);
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, &signal->fence.flags);
+
+ intel_context_set_single_submission(rq->context);
+ intel_context_set_single_submission(signal->context);
The thought that just popped into my head:
This can be after signal is already submitted into ELSP[1].
Yep I knew that but thought it would still work.
Master in vcs0 port1, slave in vcs1 port0 or queued.
If queued that means at worst case another bonded pair is running on
same engines, so they should be able to complete.
If slave submitted to vcs1 port0 then it will stay there until whatever
is in vcs0 port0 finishes and lets master in.
Do you see a possibility for things to go bad?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove
On 18/05/2020 19:17, Janusz Krzysztofik wrote:
Contexts associated with open device file descriptors together with
their assigned address spaces are now closed on device file close. On
i915_gem_driver_remove looks like module unload to me, not device file
close. So..
address space closure its associated DMA mappings are revoked. If the
device is removed while being open, subsequent attempts to revoke
those mappings while closing the device file descriptor may may be
judged by intel-iommu code as a bug and result in kernel panic.
Since user contexts become useless after the device is no longer
available, drop them on device removal.
<4> [36.900985] [ cut here ]
<2> [36.901005] kernel BUG at drivers/iommu/intel-iommu.c:3717!
<4> [36.901105] invalid opcode: [#1] PREEMPT SMP NOPTI
<4> [36.901117] CPU: 0 PID: 39 Comm: kworker/u8:1 Tainted: G U W
5.7.0-rc5-CI-CI_DRM_8485+ #1
<4> [36.901133] Hardware name: Intel Corporation Elkhart Lake Embedded
Platform/ElkhartLake LPDDR4x T3 CRB, BIOS EHLSFWI1.R00.1484.A00.1911290833 11/29/2019
<4> [36.901250] Workqueue: i915 __i915_vm_release [i915]
<4> [36.901264] RIP: 0010:intel_unmap+0x1f5/0x230
<4> [36.901274] Code: 01 e8 9f bc a9 ff 85 c0 74 09 80 3d df 60 09 01 00 74 19 65 ff
0d 13 12 97 7e 0f 85 fc fe ff ff e8 82 b0 95 ff e9 f2 fe ff ff <0f> 0b e8 d4 bd a9 ff
85 c0 75 de 48 c7 c2 10 84 2c 82 be 54 00 00
<4> [36.901302] RSP: 0018:c91ebdc0 EFLAGS: 00010246
<4> [36.901313] RAX: RBX: 8882561dd000 RCX:
<4> [36.901324] RDX: 1000 RSI: ffd9c000 RDI:
888274c94000
<4> [36.901336] RBP: 888274c940b0 R08: R09:
0001
<4> [36.901348] R10: 0a25d812 R11: 112af2d4 R12:
888252c70200
<4> [36.901360] R13: ffd9c000 R14: 1000 R15:
8882561dd010
<4> [36.901372] FS: () GS:88827800()
knlGS:
<4> [36.901386] CS: 0010 DS: ES: CR0: 80050033
<4> [36.901396] CR2: 7f06def54950 CR3: 000255844000 CR4:
00340ef0
<4> [36.901408] Call Trace:
<4> [36.901418] ? process_one_work+0x1de/0x600
<4> [36.901494] cleanup_page_dma+0x37/0x70 [i915]
<4> [36.901573] free_pd+0x9/0x20 [i915]
<4> [36.901644] gen8_ppgtt_cleanup+0x59/0xc0 [i915]
<4> [36.901721] __i915_vm_release+0x14/0x30 [i915]
<4> [36.901733] process_one_work+0x268/0x600
<4> [36.901744] ? __schedule+0x307/0x8d0
<4> [36.901756] worker_thread+0x37/0x380
<4> [36.901766] ? process_one_work+0x600/0x600
<4> [36.901775] kthread+0x140/0x160
<4> [36.901783] ? kthread_park+0x80/0x80
<4> [36.901792] ret_from_fork+0x24/0x50
<4> [36.901804] Modules linked in: mei_hdcp i915 x86_pkg_temp_thermal coretemp
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel ax88179_178a usbnet mii mei_me mei
prime_numbers intel_lpss_pci
<4> [36.901857] ---[ end trace 52d1b4d81f8d1ea7 ]---
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 +
drivers/gpu/drm/i915/gem/i915_gem_context.h | 1 +
drivers/gpu/drm/i915/i915_gem.c | 2 ++
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 900ea8b7fc8f..0096a69fbfd3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -927,6 +927,44 @@ void i915_gem_driver_release__contexts(struct
drm_i915_private *i915)
rcu_barrier(); /* and flush the left over RCU frees */
}
+void i915_gem_driver_remove__contexts(struct drm_i915_private *i915)
+{
+ struct i915_gem_context *ctx, *cn;
+
+ list_for_each_entry_safe(ctx, cn, &i915->gem.contexts.list, link) {
+ struct drm_i915_file_private *file_priv = ctx->file_priv;
+ struct i915_gem_context *entry;
+ unsigned long int id;
+
+ if (i915_gem_context_is_closed(ctx) || IS_ERR(file_priv))
+ continue;
+
+ xa_for_each(&file_priv->context_xa, id, entry) {
... how is driver unload possible with open drm file descriptors, or
active contexts? If something is going wrong sounds like something else.
drm postclose -> i915_gem_context_close -> closes all contexts and puts
all vm. What can remain dangling? An active context? But there is idling
via i915_gem_driver_remove -> i915_gem_suspend_late.
Regards,
Tvrtko
+ struct i915_address_space *vm;
+ unsigned long int idx;
+
+ if (entry != ctx)
+ continue;
+
+ xa_erase(&file_priv->context_xa, id);
+
+ if (id)
+ break;
+
+ xa_for_each(&file_priv->vm_xa, idx, vm) {
+ xa_erase(&file_priv->vm_xa, idx);
+
Re: [Intel-gfx] [PATCH] drm/i915: Special handling for bonded requests
Quoting Tvrtko Ursulin (2020-05-27 09:53:22)
> +static void
> +mark_bonded_pair(struct i915_request *rq, struct i915_request *signal)
> +{
> + /*
> +* Give (temporary) special meaning to a pair requests with requested
> +* aligned start along the video engines.
> +*
> +* They should be non-preemptable and have all ELSP ports to
> themselves
> +* to avoid any deadlocks caused by inversions.
> +*
> +* Gen11+
> +*/
> + if (INTEL_GEN(rq->i915) < 11 ||
> + rq->engine->class != VIDEO_DECODE_CLASS ||
> + rq->engine->class != signal->engine->class)
> + return;
> +
> + set_bit(I915_FENCE_FLAG_NOPREEMPT, &rq->fence.flags);
> + set_bit(I915_FENCE_FLAG_NOPREEMPT, &signal->fence.flags);
> +
> + intel_context_set_single_submission(rq->context);
> + intel_context_set_single_submission(signal->context);
The thought that just popped into my head:
This can be after signal is already submitted into ELSP[1].
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 4/4] drm/i915: Move UC firmware cleanup from driver_release to _remove
Hi Michał, On Wed, 2020-05-27 at 21:15 +0200, Michał Winiarski wrote: > Quoting Janusz Krzysztofik (2020-05-18 20:17:20) > > UC firmware is stored in a GEM object. Clean it up on driver remove to >^ double whitespace That's a result of my addiction to an old-fashioned style of separating sentences with double space. BTW, that's how my vi editor still joins two lines when first of them ends with a full stop. > > avoid intel-iommu triggered kernel panic on late DMA unmapping or even > > an RPM related warning on object late removal in no IOMMU setups. > > This is no longer the case after: > drm/i915/gem: Lazily acquire the device wakeref for freeing objects > > Right? Not really. That was only a first step in that direction, some operations called from that processing path still try to acquire the wakaref unconditionally. > > > <4> [93.335282] [ cut here ] > > <4> [93.335515] pm_runtime_get_sync() failed: -13 > > <4> [93.336056] WARNING: CPU: 6 PID: 200 at > > drivers/gpu/drm/i915/intel_runtime_pm.c:361 > > __intel_runtime_pm_get+0x4d/0x60 [i915] > > <4> [93.336104] Modules linked in: snd_hda_codec_hdmi mei_hdcp i915 > > x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul > > ghash_clmulni_intel snd_hda_intel cdc_ether snd_intel_dspcfg usbnet > > snd_hda_codec mii snd_hwdep snd_hda_core e1000e snd_pcm ptp pps_core mei_me > > mei intel_lpss_pci prime_numbers > > <4> [93.336268] CPU: 6 PID: 200 Comm: kworker/u16:3 Tainted: G U > > 5.7.0-rc4-CI-Trybot_6405+ #1 > > <4> [93.336289] Hardware name: Intel Corporation Tiger Lake Client > > Platform/TigerLake Y LPDDR4x T4 Crb, BIOS TGLSFWI1.R00.2457.A16.1912270059 > > 12/27/2019 > > <4> [93.336811] Workqueue: i915 __i915_gem_free_work [i915] > > <4> [93.337296] RIP: 0010:__intel_runtime_pm_get+0x4d/0x60 [i915] > > <4> [93.337332] Code: ff ff 48 89 df 5b 5d e9 a1 fa ff ff 80 3d 4b 7a 2e 00 > > 00 75 e1 89 c6 48 c7 c7 a8 2d 40 a0 c6 05 39 7a 2e 00 01 e8 53 fc e9 e0 > > <0f> 0b eb c8 0f 1f 44 00 00 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 > > <4> [93.337357] RSP: 0018:c9000144bdd8 EFLAGS: 00010282 > > <4> [93.337384] RAX: RBX: 88838ee5bc40 RCX: > > 0001 > > <4> [93.337409] RDX: 8001 RSI: 88839d264928 RDI: > > > > <4> [93.337440] RBP: 0001 R08: 88839d264928 R09: > > > > <4> [93.337467] R10: R11: R12: > > 88838ee5bc40 > > <4> [93.337493] R13: 0006 R14: 82769a30 R15: > > 88839376bab0 > > <4> [93.337515] FS: () GS:8883a410() > > knlGS: > > <4> [93.337542] CS: 0010 DS: ES: CR0: 80050033 > > <4> [93.337563] CR2: 55bc19b16ff8 CR3: 0003a11c4005 CR4: > > 00760ee0 > > <4> [93.337583] PKRU: 5554 > > <4> [93.337605] Call Trace: > > <4> [93.338148] i915_gem_object_release_mmap+0x23/0x70 [i915] > > <4> [93.338665] __i915_gem_free_objects.isra.21+0x10a/0x4b0 [i915] > > <4> [93.338741] process_one_work+0x268/0x600 > > <4> [93.338785] ? __schedule+0x307/0x8d0 > > <4> [93.338878] worker_thread+0x37/0x380 > > <4> [93.338929] ? process_one_work+0x600/0x600 > > <4> [93.338963] kthread+0x140/0x160 > > <4> [93.339006] ? kthread_park+0x80/0x80 > > <4> [93.339057] ret_from_fork+0x24/0x50 > > <4> [93.339181] irq event stamp: 204220 > > <4> [93.339219] hardirqs last enabled at (204219): [] > > console_unlock+0x4cd/0x5a0 > > <4> [93.339250] hardirqs last disabled at (204220): [] > > trace_hardirqs_off_thunk+0x1a/0x1c > > <4> [93.339277] softirqs last enabled at (204208): [] > > __do_softirq+0x395/0x49e > > <4> [93.339307] softirqs last disabled at (204197): [] > > irq_exit+0xba/0xc0 > > <4> [93.339330] ---[ end trace f066187622b8c484 ]--- > > > > Signed-off-by: Janusz Krzysztofik > > Reviewed-by: Michał Winiarski Thanks, Janusz > > -Michał > > > --- > > drivers/gpu/drm/i915/i915_gem.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index 87d3c4f5b6c6..f9d37c7e6d6f 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -1191,6 +1191,8 @@ void i915_gem_driver_remove(struct drm_i915_private > > *dev_priv) > > > > i915_gem_driver_remove__contexts(dev_priv); > > > > + intel_uc_cleanup_firmwares(&dev_priv->gt.uc); > > + > > i915_gem_drain_freed_objects(dev_priv); > > } > > > > @@ -1202,7 +1204,6 @@ void i915_gem_driver_release(struct drm_i915_private > > *dev_priv) > > > > intel_wa_list_free(&dev_priv->gt_wa_list); > > > > - intel_uc_cleanup_firmwares(&dev_priv->gt.uc); > > i915_gem_cleanup_userptr(dev_priv); > > > > i915_gem_drain_freed_objects(dev_priv); > > -- > > 2.21.1 > > > > __
Re: [Intel-gfx] [RFC PATCH 3/4] drm/i915: Move GGTT cleanup from driver_release to _remove
On Wed, 2020-05-27 at 21:12 +0200, Michał Winiarski wrote: > Quoting Janusz Krzysztofik (2020-05-18 20:17:19) > > GGTT including its scratch page is not cleaned up until driver release. > > Since DMA mappings still exist before scratch page cleanup, unmapping > > them on last device close after the driver has been already removed may > > be judged by intel-iommu code as a bug and result in kernel panic. > > > > Since we abort requests and block user access to hardware on device > > removal, there seems not much sense in still keeping GGTT. Clean it up > > on driver remove. However, skip GGTT address space cleanup as its > > mutext may still be needed if there are objects to be freed. That > > cleanup is always called on address space release after all. > > > > [ 81.290284] [ cut here ] > > [ 81.291602] kernel BUG at drivers/iommu/intel-iommu.c:3591! > > [ 81.293558] invalid opcode: [#1] PREEMPT SMP > > [ 81.294695] CPU: 0 PID: 207 Comm: core_hotunplug Tainted: G U > > 5.4.17 #2 > > [ 81.296579] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 > > [ 81.297959] RIP: 0010:intel_unmap+0x200/0x230 > > [ 81.299015] Code: 00 e8 e4 45 c5 ff 85 c0 74 09 80 3d 2b 84 c0 00 00 74 > > 19 65 ff 0d 78 9a b2 7e 0f 85 fa fe ff ff e8 95 57 b1 ff e9 f0 fe ff ff > > <0f> 0b e8 19 4c c5 ff 85 c0 75 de 48 c7 c2 48 d2 e1 81 be 57 00 00 > > [ 81.303425] RSP: 0018:c913fda0 EFLAGS: 00010246 > > [ 81.304683] RAX: RBX: 8882228dd0b0 RCX: > > > > [ 81.306384] RDX: 1000 RSI: af801000 RDI: > > 8882228dd0b0 > > [ 81.308086] RBP: R08: R09: > > > > [ 81.309788] R10: R11: R12: > > af801000 > > [ 81.311489] R13: 888223a0 R14: 1000 R15: > > 888223a0a2e8 > > [ 81.313191] FS: 7f5408e3c940() GS:88822860() > > knlGS: > > [ 81.315116] CS: 0010 DS: ES: CR0: 80050033 > > [ 81.316495] CR2: 01fc0048 CR3: 00022464a000 CR4: > > 06b0 > > [ 81.318196] Call Trace: > > [ 81.318967] cleanup_scratch_page+0x44/0x80 [i915] > > [ 81.320281] i915_ggtt_driver_release+0x15b/0x220 [i915] > > [ 81.321717] i915_driver_release+0x33/0x90 [i915] > > [ 81.322856] drm_release+0xbc/0xd0 > > [ 81.323691] __fput+0xcd/0x260 > > [ 81.324447] task_work_run+0x90/0xc0 > > [ 81.325323] do_syscall_64+0x3da/0x560 > > [ 81.326240] entry_SYSCALL_64_after_hwframe+0x49/0xbe > > [ 81.327457] RIP: 0033:0x7f54096ecba3 > > [ 81.328332] Code: 00 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f > > 80 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 03 00 00 00 0f 05 > > <48> 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 > > [ 81.332741] RSP: 002b:7ffcc5165698 EFLAGS: 0246 ORIG_RAX: > > 0003 > > [ 81.334546] RAX: RBX: RCX: > > 7f54096ecba3 > > [ 81.336247] RDX: 005cc5d0 RSI: 0005 RDI: > > 0004 > > [ 81.337949] RBP: 0003 R08: 005b8014 R09: > > 0004 > > [ 81.339650] R10: 005cc650 R11: 0246 R12: > > 004022f0 > > [ 81.341352] R13: 7ffcc5165850 R14: R15: > > > > [ 81.343059] Modules linked in: i915 mfd_core intel_gtt prime_numbers > > [ 81.345015] ---[ end trace 010aae55e56f8998 ]--- > > > > Signed-off-by: Janusz Krzysztofik > > > > drm/i915: Defer GGTT vm address space fini to vm release > > Hum? That's a patch squashing left-over I apparently missed, sorry. > > > Signed-off-by: Janusz Krzysztofik > > --- > > drivers/gpu/drm/i915/gt/intel_ggtt.c | 13 + > > drivers/gpu/drm/i915/gt/intel_gtt.h | 1 + > > drivers/gpu/drm/i915/i915_drv.c | 2 ++ > > 3 files changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c > > b/drivers/gpu/drm/i915/gt/intel_ggtt.c > > index 66165b10256e..ff2b4f74149a 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c > > +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c > > @@ -701,7 +701,6 @@ static void ggtt_cleanup_hw(struct i915_ggtt *ggtt) > > ggtt->vm.cleanup(&ggtt->vm); > > > > mutex_unlock(&ggtt->vm.mutex); > > - i915_address_space_fini(&ggtt->vm); > > Ok, so this was defered to release. Where are we going to drop the final ref? > And also - I can see that we have a: > > GEM_BUG_ON(i915_is_ggtt(vm)); > > in i915_vm_release(). > Which means that we probably don't drop the final ref and don't ever call > i915_address_space_fini for ggtt. Uh, that renders my solution invalid. Let me take another approach. Thanks, Janusz > > -Michał > > > > > arch_phys_wc_del(ggtt->mtrr); > > > > @@ -709,6 +708,15 @@ static void ggtt_cleanup_hw(struct i915_ggtt
[Intel-gfx] ✓ Fi.CI.IGT: success for Asynchronous flip implementation for i915 (rev3)
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev3)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17799_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_17799_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume:
- shard-apl: [PASS][1] -> [DMESG-WARN][2] ([i915#180]) +2 similar
issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl7/igt@gem_workarou...@suspend-resume.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-apl8/igt@gem_workarou...@suspend-resume.html
* igt@i915_pm_rpm@system-suspend:
- shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#151] / [i915#69])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl2/igt@i915_pm_...@system-suspend.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-skl3/igt@i915_pm_...@system-suspend.html
* igt@i915_suspend@debugfs-reader:
- shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#69])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl6/igt@i915_susp...@debugfs-reader.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-skl10/igt@i915_susp...@debugfs-reader.html
* igt@kms_busy@basic-flip-pipe-a:
- shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-snb4/igt@kms_b...@basic-flip-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-snb6/igt@kms_b...@basic-flip-pipe-a.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#72])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#109349])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-iclb1/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl1/igt@kms_...@bpc-switch-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-skl1/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265])
+1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-skl4/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-iclb1/igt@kms_psr@psr2_cursor_render.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][19] ([i915#1930]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-glk4/igt@gem_exec_re...@basic-concurrent0.html
* igt@i915_suspend@forcewake:
- shard-skl: [INCOMPLETE][21] ([i915#636] / [i915#69]) ->
[PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl5/igt@i915_susp...@forcewake.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-skl1/igt@i915_susp...@forcewake.html
* igt@kms_big_fb@linear-64bpp-rotate-180:
- shard-glk: [FAIL][23] ([i915#1119] / [i915#118] / [i915#95]) ->
[PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk8/igt@kms_big...@linear-64bpp-rotate-180.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17799/shard-glk9/igt@kms_big...@linear-64bpp-rotate-180.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [DMESG-WARN][25] ([i915#180]) -> [PASS][26] +2
similar issues
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl4/igt@kms_cursor_...@pipe-a-cu
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Prevent timeslicing into unpreemptable requests
On 27/05/2020 17:24, Chris Wilson wrote:
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to avoid preempting into the topmost priority band,
leaving the unpreemptable requests in blissful peace running
uninterrupted on the HW.
v2: Set the I915_PRIORITY_BARRIER to be less than
I915_PRIORITY_UNPREEMPTABLE so that we never submit a request
(heartbeat or barrier) that can legitimately preempt the current
non-premptable request.
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a
request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 1 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 118 -
drivers/gpu/drm/i915/i915_priolist_types.h | 2 +-
3 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3214a4ecc31a..197efd9ea1e9 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1928,6 +1928,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(&rq->sched.link, &engine->active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
+ GEM_BUG_ON(hint == I915_PRIORITY_UNPREEMPTABLE);
return hint >= effective_prio(rq);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 66f710b1b61e..3e35a45d6218 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -823,7 +823,7 @@ slice_semaphore_queue(struct intel_engine_cs *outer,
}
}
- err = release_queue(outer, vma, n, INT_MAX);
+ err = release_queue(outer, vma, n, I915_PRIORITY_BARRIER);
if (err)
goto out;
@@ -1289,6 +1289,121 @@ static int live_timeslice_queue(void *arg)
return err;
}
+static int live_timeslice_nopreempt(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ struct igt_spinner spin;
+ int err = 0;
+
+ /*
+* We should not timeslice into a request that is marked with
+* I915_REQUEST_NOPREEMPT.
+*/
+ if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ return 0;
+
+ if (igt_spinner_init(&spin, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce;
+ struct i915_request *rq;
+ unsigned long timeslice;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ break;
+ }
+
+ engine_heartbeat_disable(engine);
+ timeslice = xchg(&engine->props.timeslice_duration_ms, 1);
+
+ /* Create an unpreemptible spinner */
+
+ rq = igt_spinner_create_request(&spin, ce, MI_ARB_CHECK);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_heartbeat;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(&spin, rq)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, &rq->fence.flags);
+ i915_request_put(rq);
+
+ /* Followed by a maximum priority barrier (heartbeat) */
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq = intel_context_create_request(ce);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ /*
+* Wait until the barrier is in ELSP, and we know timeslicing
+* will have been activated.
+*/
+ if (wait_for_submit(engine, rq, HZ / 2)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ /*
+* Since th
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/gt: Prevent timeslicing into unpreemptable requests
== Series Details == Series: series starting with [1/3] drm/i915/gt: Prevent timeslicing into unpreemptable requests URL : https://patchwork.freedesktop.org/series/77730/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8545 -> Patchwork_17801 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17801 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17801, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17801/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17801: ### IGT changes ### Possible regressions * igt@i915_selftest@live@gem_contexts: - fi-bwr-2160:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17801/fi-bwr-2160/igt@i915_selftest@live@gem_contexts.html * igt@kms_busy@basic@modeset: - fi-ivb-3770:[PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/fi-ivb-3770/igt@kms_busy@ba...@modeset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17801/fi-ivb-3770/igt@kms_busy@ba...@modeset.html Participating hosts (49 -> 43) -- Additional (2): fi-bdw-gvtdvm fi-cfl-8700k Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-kbl-7560u fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8545 -> Patchwork_17801 CI-20190529: 20190529 CI_DRM_8545: 76540f7be4ff04851e47d0865c2bb07a15106bcb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5681: 2991a5d60b1bbf2b2b6004669cd0f9471bd687a2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17801: ee61f90a8c75a2e40c30cda9beba279a8e6e0500 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ee61f90a8c75 drm/i915: Track i915_vma with its own reference counter 78e4f820cf01 drm/i915/gt: Don't declare hangs if engine is stalled 006567321620 drm/i915/gt: Prevent timeslicing into unpreemptable requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17801/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
On Thu, May 28, 2020 at 10:19:46AM +0200, Stefan Agner wrote: > On 2020-05-28 10:06, Daniel Vetter wrote: > > On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote: > >> > >> Hi Daniel, > >> > >> On 2020-05-28 07:46, Daniel Vetter wrote: > >> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote: > >> >> mxsfb has vblank support, is atomic, but doesn't call > >> >> drm_crtc_vblank_on/off as it should. Not good. > >> >> > >> >> With my next patch to add the drm_crtc_vblank_reset to helpers this > >> >> means not even the very first crtc enabling will vblanks work anymore, > >> >> since they'll just stay off forever. > >> >> > >> >> Since mxsfb doesn't have any vblank waits of its own in the > >> >> enable/disable flow, nor an enable/disable_vblank callback we can do > >> >> the on/off as the first respectively last operation, and it should all > >> >> work. > >> >> > >> >> Signed-off-by: Daniel Vetter > >> >> Cc: Marek Vasut > >> >> Cc: Stefan Agner > >> >> Cc: Shawn Guo > >> >> Cc: Sascha Hauer > >> >> Cc: Pengutronix Kernel Team > >> >> Cc: Fabio Estevam > >> >> Cc: NXP Linux Team > >> >> Cc: linux-arm-ker...@lists.infradead.org > >> > > >> > Ping for some ack/review on this one here, it's holding up the subsystem > >> > wide fix in patch 2. > >> > >> Sorry for the delay. > >> > >> I guess that has the same effect as patch 14 in Laurent's patchset would > >> have: > >> https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinch...@ideasonboard.com/ > > > > Uh, looking at that patch I realized that mxsfb indeed calls > > drm_vblank_init before mode_config.num_crtc is set. Which means it > > never had working vblank support in upstream. That also explains the > > lack of fireworks, since all other drivers that actually do initialize > > vblank support have the drm_crtc_vblank_on/off calls - without them > > the driver doesn't survive for very long. > > > > tldr; I don't need this patch here to apply the 2nd one, so no > > conflict potential at all. And the patch from Laurent does fix up > > everything correctly, so we should be good. > > Uh I see, that is somehow unfortunate and fortunate at the same time! > > Ok, I hope we get this cleaned up soon. I recommend igt tests for actually making sure your driver does something, instead of just thinking you've enabled a feature :-) -Daniel > > -- > Stefan > > > -Daniel > > > >> But should be rather trivial to rebase. So until Laurent's patchset is > >> ready, we can go with this fix. > >> > >> Acked-by: Stefan Agner > >> > >> -- > >> Stefan > >> > >> > > >> > Thanks, Daniel > >> > > >> >> --- > >> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++ > >> >> 1 file changed, 2 insertions(+) > >> >> > >> >> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> >> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> >> index 497cf443a9af..1891cd6deb2f 100644 > >> >> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> >> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> >> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct > >> >> drm_simple_display_pipe *pipe, > >> >> drm_panel_prepare(mxsfb->panel); > >> >> mxsfb_crtc_enable(mxsfb); > >> >> drm_panel_enable(mxsfb->panel); > >> >> +drm_crtc_vblank_on(&pipe->crtc); > >> >> } > >> >> > >> >> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe) > >> >> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct > >> >> drm_simple_display_pipe *pipe) > >> >> struct drm_crtc *crtc = &pipe->crtc; > >> >> struct drm_pending_vblank_event *event; > >> >> > >> >> +drm_crtc_vblank_off(&pipe->crtc); > >> >> drm_panel_disable(mxsfb->panel); > >> >> mxsfb_crtc_disable(mxsfb); > >> >> drm_panel_unprepare(mxsfb->panel); > >> >> -- > >> >> 2.26.2 > >> >> -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/gt: Remove local entries from GGTT on suspend
Across suspend/resume, we clear the entire GGTT and rebuild from
scratch. In particular, we only preserve the global entries for use by
the HW, and delay reinstating the local binds until required by the
user. This means that we can evict and recover any local binds in the
global GTT, saving any time in preserving their state.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1947
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 23 ++-
drivers/gpu/drm/i915/i915_vma.c | 59 +++-
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 54 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index ffe285b0b3bd..323c328d444a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -108,13 +108,32 @@ static bool needs_idle_maps(struct drm_i915_private *i915)
void i915_ggtt_suspend(struct i915_ggtt *ggtt)
{
- struct i915_vma *vma;
+ struct i915_vma *vma, *vn;
+ int open;
+
+ mutex_lock(&ggtt->vm.mutex);
+
+ /* Skip rewriting PTE on VMA unbind. */
+ open = atomic_xchg(&ggtt->vm.open, 0);
- list_for_each_entry(vma, &ggtt->vm.bound_list, vm_link)
+ list_for_each_entry_safe(vma, vn, &ggtt->vm.bound_list, vm_link) {
+ GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
i915_vma_wait_for_bind(vma);
+ if (i915_vma_is_pinned(vma))
+ continue;
+
+ if (!i915_vma_is_bound(vma, I915_VMA_GLOBAL_BIND)) {
+ __i915_vma_evict(vma);
+ drm_mm_remove_node(&vma->node);
+ }
+ }
+
ggtt->vm.clear_range(&ggtt->vm, 0, ggtt->vm.total);
ggtt->invalidate(ggtt);
+ atomic_set(&ggtt->vm.open, open);
+
+ mutex_unlock(&ggtt->vm.mutex);
intel_gt_check_and_clear_faults(ggtt->vm.gt);
}
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 22198b758459..9b30ddc49e4b 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1229,31 +1229,9 @@ int i915_vma_move_to_active(struct i915_vma *vma,
return 0;
}
-int __i915_vma_unbind(struct i915_vma *vma)
+void __i915_vma_evict(struct i915_vma *vma)
{
- int ret;
-
- lockdep_assert_held(&vma->vm->mutex);
-
- if (i915_vma_is_pinned(vma)) {
- vma_print_allocator(vma, "is pinned");
- return -EAGAIN;
- }
-
- /*
-* After confirming that no one else is pinning this vma, wait for
-* any laggards who may have crept in during the wait (through
-* a residual pin skipping the vm->mutex) to complete.
-*/
- ret = i915_vma_sync(vma);
- if (ret)
- return ret;
-
- if (!drm_mm_node_allocated(&vma->node))
- return 0;
-
GEM_BUG_ON(i915_vma_is_pinned(vma));
- GEM_BUG_ON(i915_vma_is_active(vma));
if (i915_vma_is_map_and_fenceable(vma)) {
/* Force a pagefault for domain tracking on next user access */
@@ -1292,6 +1270,33 @@ int __i915_vma_unbind(struct i915_vma *vma)
i915_vma_detach(vma);
vma_unbind_pages(vma);
+}
+
+int __i915_vma_unbind(struct i915_vma *vma)
+{
+ int ret;
+
+ lockdep_assert_held(&vma->vm->mutex);
+
+ if (!drm_mm_node_allocated(&vma->node))
+ return 0;
+
+ if (i915_vma_is_pinned(vma)) {
+ vma_print_allocator(vma, "is pinned");
+ return -EAGAIN;
+ }
+
+ /*
+* After confirming that no one else is pinning this vma, wait for
+* any laggards who may have crept in during the wait (through
+* a residual pin skipping the vm->mutex) to complete.
+*/
+ ret = i915_vma_sync(vma);
+ if (ret)
+ return ret;
+
+ GEM_BUG_ON(i915_vma_is_active(vma));
+ __i915_vma_evict(vma);
drm_mm_remove_node(&vma->node); /* pairs with i915_vma_release() */
return 0;
@@ -1303,13 +1308,13 @@ int i915_vma_unbind(struct i915_vma *vma)
intel_wakeref_t wakeref = 0;
int err;
- if (!drm_mm_node_allocated(&vma->node))
- return 0;
-
/* Optimistic wait before taking the mutex */
err = i915_vma_sync(vma);
if (err)
- goto out_rpm;
+ return err;
+
+ if (!drm_mm_node_allocated(&vma->node))
+ return 0;
if (i915_vma_is_pinned(vma)) {
vma_print_allocator(vma, "is pinned");
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 8ad1daabcd58..d0d01f909548 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -203,6 +203,7 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
u64 size, u64 alignment, u64 flag
[Intel-gfx] [PATCH 1/2] drm/i915/gt: Restore both GGTT bindings on resume
We should be able to skip restoing LOCAL (user) binds within the GGTT on
resume and let them be restored upon demand. However, our consistency
checks demand that the bind flags match the node state, and we cannot
simply clear the flags we need to evict as well. For now, make sure we
restore the bind flags exactly upon resume.
Fixes: 0109a16ef391 ("drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume")
Fixes: bf0840cdb304 ("drm/i915/gt: Stop cross-polluting PIN_GLOBAL with
PIN_USER with no-ppgtt")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 317172ad5ef3..ffe285b0b3bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -1183,13 +1183,11 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
/* clflush objects bound into the GGTT and rebind them. */
list_for_each_entry(vma, &ggtt->vm.bound_list, vm_link) {
struct drm_i915_gem_object *obj = vma->obj;
-
- if (!(clear_bind(vma) & I915_VMA_GLOBAL_BIND))
- continue;
+ unsigned int was_bound = clear_bind(vma);
WARN_ON(i915_vma_bind(vma,
obj ? obj->cache_level : 0,
- PIN_GLOBAL, NULL));
+ was_bound, NULL));
if (obj) { /* only used during resume => exclusive access */
flush |= fetch_and_zero(&obj->write_domain);
obj->read_domains |= I915_GEM_DOMAIN_GTT;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/gt: Prevent timeslicing into unpreemptable requests
== Series Details ==
Series: series starting with [1/3] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77730/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
006567321620 drm/i915/gt: Prevent timeslicing into unpreemptable requests
78e4f820cf01 drm/i915/gt: Don't declare hangs if engine is stalled
ee61f90a8c75 drm/i915: Track i915_vma with its own reference counter
-:2210: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#2210: FILE: drivers/gpu/drm/i915/gt/intel_gtt.h:267:
+ spinlock_t lock;
-:3960: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#3960: FILE: drivers/gpu/drm/i915/i915_vma.h:385:
+ spinlock_t lock;
-:4123: WARNING:BRACES: braces {} are not necessary for single statement blocks
#4123: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:149:
+ if (IS_ERR(obj)) {
+ return ERR_CAST(obj);
+ }
-:4206: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4206: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:395:
+ if (offset < hole_start +
vma->size)
-:4217: WARNING:LONG_LINE: line over 100 characters
#4217: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:403:
+ __func__, p->name, err,
npages, prime, offset,
-:4227: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4227: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:420:
+ if (offset + vma->node.size >
hole_end)
-:4243: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4243: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:429:
+ if (offset < hole_start +
vma->node.size)
-:4255: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4255: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:452:
+ if (offset + vma->node.size >
hole_end)
-:4271: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4271: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:461:
+ if (offset < hole_start +
vma->node.size)
-:4283: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4283: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:485:
+ if (offset + vma->size >=
hole_end)
-:4299: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4299: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:494:
+ if (offset < hole_start +
vma->size)
-:4311: WARNING:DEEP_INDENTATION: Too many leading tabs - consider code
refactoring
#4311: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:517:
+ if (offset + vma->size >=
hole_end)
total: 0 errors, 10 warnings, 2 checks, 4744 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
On 2020-05-28 10:06, Daniel Vetter wrote: > On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote: >> >> Hi Daniel, >> >> On 2020-05-28 07:46, Daniel Vetter wrote: >> > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote: >> >> mxsfb has vblank support, is atomic, but doesn't call >> >> drm_crtc_vblank_on/off as it should. Not good. >> >> >> >> With my next patch to add the drm_crtc_vblank_reset to helpers this >> >> means not even the very first crtc enabling will vblanks work anymore, >> >> since they'll just stay off forever. >> >> >> >> Since mxsfb doesn't have any vblank waits of its own in the >> >> enable/disable flow, nor an enable/disable_vblank callback we can do >> >> the on/off as the first respectively last operation, and it should all >> >> work. >> >> >> >> Signed-off-by: Daniel Vetter >> >> Cc: Marek Vasut >> >> Cc: Stefan Agner >> >> Cc: Shawn Guo >> >> Cc: Sascha Hauer >> >> Cc: Pengutronix Kernel Team >> >> Cc: Fabio Estevam >> >> Cc: NXP Linux Team >> >> Cc: linux-arm-ker...@lists.infradead.org >> > >> > Ping for some ack/review on this one here, it's holding up the subsystem >> > wide fix in patch 2. >> >> Sorry for the delay. >> >> I guess that has the same effect as patch 14 in Laurent's patchset would >> have: >> https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinch...@ideasonboard.com/ > > Uh, looking at that patch I realized that mxsfb indeed calls > drm_vblank_init before mode_config.num_crtc is set. Which means it > never had working vblank support in upstream. That also explains the > lack of fireworks, since all other drivers that actually do initialize > vblank support have the drm_crtc_vblank_on/off calls - without them > the driver doesn't survive for very long. > > tldr; I don't need this patch here to apply the 2nd one, so no > conflict potential at all. And the patch from Laurent does fix up > everything correctly, so we should be good. Uh I see, that is somehow unfortunate and fortunate at the same time! Ok, I hope we get this cleaned up soon. -- Stefan > -Daniel > >> But should be rather trivial to rebase. So until Laurent's patchset is >> ready, we can go with this fix. >> >> Acked-by: Stefan Agner >> >> -- >> Stefan >> >> > >> > Thanks, Daniel >> > >> >> --- >> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++ >> >> 1 file changed, 2 insertions(+) >> >> >> >> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> >> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> >> index 497cf443a9af..1891cd6deb2f 100644 >> >> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> >> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> >> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct >> >> drm_simple_display_pipe *pipe, >> >> drm_panel_prepare(mxsfb->panel); >> >> mxsfb_crtc_enable(mxsfb); >> >> drm_panel_enable(mxsfb->panel); >> >> +drm_crtc_vblank_on(&pipe->crtc); >> >> } >> >> >> >> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe) >> >> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct >> >> drm_simple_display_pipe *pipe) >> >> struct drm_crtc *crtc = &pipe->crtc; >> >> struct drm_pending_vblank_event *event; >> >> >> >> +drm_crtc_vblank_off(&pipe->crtc); >> >> drm_panel_disable(mxsfb->panel); >> >> mxsfb_crtc_disable(mxsfb); >> >> drm_panel_unprepare(mxsfb->panel); >> >> -- >> >> 2.26.2 >> >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915/gt: Prevent timeslicing into unpreemptable requests
== Series Details == Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into unpreemptable requests URL : https://patchwork.freedesktop.org/series/77729/ State : success == Summary == CI Bug Log - changes from CI_DRM_8545 -> Patchwork_17800 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/index.html New tests - New tests have been introduced between CI_DRM_8545 and Patchwork_17800: ### New IGT tests (1) ### * igt@dmabuf@all@dma_fence_proxy: - Statuses : 41 pass(s) - Exec time: [0.03, 0.10] s Known issues Here are the changes found in Patchwork_17800 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@active: - fi-skl-6600u: [PASS][1] -> [DMESG-FAIL][2] ([i915#666]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/fi-skl-6600u/igt@i915_selftest@l...@active.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/fi-skl-6600u/igt@i915_selftest@l...@active.html Warnings * igt@i915_pm_rpm@module-reload: - fi-kbl-x1275: [SKIP][3] ([fdo#109271]) -> [FAIL][4] ([i915#62] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8545/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/fi-kbl-x1275/igt@i915_pm_...@module-reload.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62 [i915#666]: https://gitlab.freedesktop.org/drm/intel/issues/666 [i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95 Participating hosts (49 -> 44) -- Additional (2): fi-bdw-gvtdvm fi-cfl-8700k Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_8545 -> Patchwork_17800 CI-20190529: 20190529 CI_DRM_8545: 76540f7be4ff04851e47d0865c2bb07a15106bcb @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5681: 2991a5d60b1bbf2b2b6004669cd0f9471bd687a2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17800: 6571dd270ea5be73c0e958eebdaaa16b8b022899 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 6571dd270ea5 drm/i915/gem: Make relocations atomic within execbuf eb43b54bec13 drm/i915: Unpeel awaits on a proxy fence 53c8e6601d79 dma-buf: Proxy fence, an unsignaled fence placeholder 167c2cf62a5f drm/i915/gem: Build the reloc request first cf93e1fda67c drm/i915/gem: Add all GPU reloc awaits/signals en masse 75206988e02e drm/i915/gem: Lift GPU relocation allocation 9c0586c970ee drm/i915/gem: Separate reloc validation into an earlier step f0df73f7c503 drm/i915: Add list_for_each_entry_safe_continue_reverse 1fbd041e4db7 drm/i915/gem: Async GPU relocations only afdac8049573 drm/i915/gt: Don't declare hangs if engine is stalled 55a37e373e5e drm/i915/gt: Prevent timeslicing into unpreemptable requests == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17800/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: use drm_dev_has_vblank more (rev2)
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17798_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_17798_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_17798_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17798_full:
### IGT changes ###
Possible regressions
* igt@kms_plane_alpha_blend@pipe-b-alpha-basic:
- shard-glk: NOTRUN -> [TIMEOUT][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-glk9/igt@kms_plane_alpha_bl...@pipe-b-alpha-basic.html
Known issues
Here are the changes found in Patchwork_17798_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_workarounds@suspend-resume:
- shard-kbl: [PASS][2] -> [DMESG-WARN][3] ([i915#180])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl7/igt@gem_workarou...@suspend-resume.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-kbl3/igt@gem_workarou...@suspend-resume.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][4] -> [DMESG-WARN][5] ([i915#1436] /
[i915#716])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl4/igt@gen9_exec_pa...@allowed-all.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl6/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109349])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_dp_...@basic-dsc-enable-edp.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-iclb4/igt@kms_dp_...@basic-dsc-enable-edp.html
* igt@kms_hdr@bpc-switch-suspend:
- shard-skl: [PASS][8] -> [FAIL][9] ([i915#1188])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl1/igt@kms_...@bpc-switch-suspend.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-skl7/igt@kms_...@bpc-switch-suspend.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes:
- shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([i915#180] /
[i915#93] / [i915#95])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-kbl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-a-planes.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#180])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: [PASS][14] -> [FAIL][15] ([fdo#108145] / [i915#265])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][16] -> [SKIP][17] ([fdo#109441]) +2 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-iclb4/igt@kms_psr@psr2_cursor_render.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][18] -> [FAIL][19] ([i915#31])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-apl2/igt@kms_setm...@basic.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-apl2/igt@kms_setm...@basic.html
Possible fixes
* {igt@gem_exec_reloc@basic-concurrent0}:
- shard-glk: [FAIL][20] ([i915#1930]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8544/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17798/shard-glk7/igt@gem_exec_re...@basic-concurrent0.html
* igt@i915_suspend@forcewake:
- shard-kbl: [DMESG-WARN][22] ([i915#180]) -> [PASS][23] +2
similar iss
Re: [Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
On Thu, May 28, 2020 at 9:56 AM Stefan Agner wrote: > > Hi Daniel, > > On 2020-05-28 07:46, Daniel Vetter wrote: > > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote: > >> mxsfb has vblank support, is atomic, but doesn't call > >> drm_crtc_vblank_on/off as it should. Not good. > >> > >> With my next patch to add the drm_crtc_vblank_reset to helpers this > >> means not even the very first crtc enabling will vblanks work anymore, > >> since they'll just stay off forever. > >> > >> Since mxsfb doesn't have any vblank waits of its own in the > >> enable/disable flow, nor an enable/disable_vblank callback we can do > >> the on/off as the first respectively last operation, and it should all > >> work. > >> > >> Signed-off-by: Daniel Vetter > >> Cc: Marek Vasut > >> Cc: Stefan Agner > >> Cc: Shawn Guo > >> Cc: Sascha Hauer > >> Cc: Pengutronix Kernel Team > >> Cc: Fabio Estevam > >> Cc: NXP Linux Team > >> Cc: linux-arm-ker...@lists.infradead.org > > > > Ping for some ack/review on this one here, it's holding up the subsystem > > wide fix in patch 2. > > Sorry for the delay. > > I guess that has the same effect as patch 14 in Laurent's patchset would > have: > https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinch...@ideasonboard.com/ Uh, looking at that patch I realized that mxsfb indeed calls drm_vblank_init before mode_config.num_crtc is set. Which means it never had working vblank support in upstream. That also explains the lack of fireworks, since all other drivers that actually do initialize vblank support have the drm_crtc_vblank_on/off calls - without them the driver doesn't survive for very long. tldr; I don't need this patch here to apply the 2nd one, so no conflict potential at all. And the patch from Laurent does fix up everything correctly, so we should be good. -Daniel > But should be rather trivial to rebase. So until Laurent's patchset is > ready, we can go with this fix. > > Acked-by: Stefan Agner > > -- > Stefan > > > > > Thanks, Daniel > > > >> --- > >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> index 497cf443a9af..1891cd6deb2f 100644 > >> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c > >> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct > >> drm_simple_display_pipe *pipe, > >> drm_panel_prepare(mxsfb->panel); > >> mxsfb_crtc_enable(mxsfb); > >> drm_panel_enable(mxsfb->panel); > >> +drm_crtc_vblank_on(&pipe->crtc); > >> } > >> > >> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe) > >> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct > >> drm_simple_display_pipe *pipe) > >> struct drm_crtc *crtc = &pipe->crtc; > >> struct drm_pending_vblank_event *event; > >> > >> +drm_crtc_vblank_off(&pipe->crtc); > >> drm_panel_disable(mxsfb->panel); > >> mxsfb_crtc_disable(mxsfb); > >> drm_panel_unprepare(mxsfb->panel); > >> -- > >> 2.26.2 > >> -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off
Hi Daniel, On 2020-05-28 07:46, Daniel Vetter wrote: > On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote: >> mxsfb has vblank support, is atomic, but doesn't call >> drm_crtc_vblank_on/off as it should. Not good. >> >> With my next patch to add the drm_crtc_vblank_reset to helpers this >> means not even the very first crtc enabling will vblanks work anymore, >> since they'll just stay off forever. >> >> Since mxsfb doesn't have any vblank waits of its own in the >> enable/disable flow, nor an enable/disable_vblank callback we can do >> the on/off as the first respectively last operation, and it should all >> work. >> >> Signed-off-by: Daniel Vetter >> Cc: Marek Vasut >> Cc: Stefan Agner >> Cc: Shawn Guo >> Cc: Sascha Hauer >> Cc: Pengutronix Kernel Team >> Cc: Fabio Estevam >> Cc: NXP Linux Team >> Cc: linux-arm-ker...@lists.infradead.org > > Ping for some ack/review on this one here, it's holding up the subsystem > wide fix in patch 2. Sorry for the delay. I guess that has the same effect as patch 14 in Laurent's patchset would have: https://lore.kernel.org/dri-devel/20200309195216.31042-15-laurent.pinch...@ideasonboard.com/ But should be rather trivial to rebase. So until Laurent's patchset is ready, we can go with this fix. Acked-by: Stefan Agner -- Stefan > > Thanks, Daniel > >> --- >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> index 497cf443a9af..1891cd6deb2f 100644 >> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c >> @@ -124,6 +124,7 @@ static void mxsfb_pipe_enable(struct >> drm_simple_display_pipe *pipe, >> drm_panel_prepare(mxsfb->panel); >> mxsfb_crtc_enable(mxsfb); >> drm_panel_enable(mxsfb->panel); >> +drm_crtc_vblank_on(&pipe->crtc); >> } >> >> static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe) >> @@ -133,6 +134,7 @@ static void mxsfb_pipe_disable(struct >> drm_simple_display_pipe *pipe) >> struct drm_crtc *crtc = &pipe->crtc; >> struct drm_pending_vblank_event *event; >> >> +drm_crtc_vblank_off(&pipe->crtc); >> drm_panel_disable(mxsfb->panel); >> mxsfb_crtc_disable(mxsfb); >> drm_panel_unprepare(mxsfb->panel); >> -- >> 2.26.2 >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/11] drm/i915/gt: Prevent timeslicing into unpreemptable requests
== Series Details == Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into unpreemptable requests URL : https://patchwork.freedesktop.org/series/77729/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1222:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1225:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1228:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/display/intel_display.c:1231:22: error: Expected constant expression in case statement +drivers/gpu/drm/i915/gem/i915_gem_context.c:2274:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2275:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2276:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2277:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2278:17: error: bad integer constant expression +drivers/gpu/drm/i915/gem/i915_gem_context.c:2279:17: error: bad integer constant expression +drivers/gpu/drm/i915/gt/intel_reset.c:1310:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/sysfs_engines.c:61:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:62:10: error: bad integer constant expression +drivers/gpu/drm/i915/gt/sysfs_engines.c:66:10: error: bad integer constant expression +drivers/gpu/drm/i915/gvt/mmio.c:287:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1425:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1479:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/intel_wakeref.c:137:19: warning: context imbalance in 'wakeref_auto_timeout' - unexpected unlock +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:408:9: warning: context imbalance in 'gen6_read16' - differe
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/gt: Prevent timeslicing into unpreemptable requests
== Series Details ==
Series: series starting with [01/11] drm/i915/gt: Prevent timeslicing into
unpreemptable requests
URL : https://patchwork.freedesktop.org/series/77729/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
55a37e373e5e drm/i915/gt: Prevent timeslicing into unpreemptable requests
afdac8049573 drm/i915/gt: Don't declare hangs if engine is stalled
1fbd041e4db7 drm/i915/gem: Async GPU relocations only
f0df73f7c503 drm/i915: Add list_for_each_entry_safe_continue_reverse
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pos' - possible side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'n' - possible side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
-:20: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'member' - possible
side-effects?
#20: FILE: drivers/gpu/drm/i915/i915_utils.h:269:
+#define list_for_each_entry_safe_continue_reverse(pos, n, head, member)
\
+ for (pos = list_prev_entry(pos, member),\
+n = list_prev_entry(pos, member); \
+&pos->member != (head);\
+pos = n, n = list_prev_entry(n, member))
total: 0 errors, 0 warnings, 3 checks, 12 lines checked
9c0586c970ee drm/i915/gem: Separate reloc validation into an earlier step
-:101: WARNING:UNNECESSARY_ELSE: else is not generally useful after a break or
return
#101: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1408:
+ return (int)offset;
+ } else {
total: 0 errors, 1 warnings, 0 checks, 215 lines checked
75206988e02e drm/i915/gem: Lift GPU relocation allocation
cf93e1fda67c drm/i915/gem: Add all GPU reloc awaits/signals en masse
167c2cf62a5f drm/i915/gem: Build the reloc request first
53c8e6601d79 dma-buf: Proxy fence, an unsignaled fence placeholder
-:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#45:
new file mode 100644
-:427: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment
#427: FILE: drivers/dma-buf/st-dma-fence-proxy.c:20:
+ spinlock_t lock;
total: 0 errors, 1 warnings, 1 checks, 1147 lines checked
eb43b54bec13 drm/i915: Unpeel awaits on a proxy fence
6571dd270ea5 drm/i915/gem: Make relocations atomic within execbuf
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/2] drm/i915: Add a new debugfs to request HDCP version
Hi Jani,
Thanks for the comments and suggestions. Please find my response inline.
On 5/27/2020 7:44 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
As per the current HDCP design, the driver selects the highest
version of HDCP that can be used to satisfy the content-protection
requirements of the user. Due to this, the content-protection
tests cannot test a lower version of HDCP, if the platform and the
display panel, both support higher HDCP version.
To provide some support for testing and debugging, a per-connector
debugfs is required to set the HDCP version via debugfs that the
kernel can consider, while enabling HDCP.
This patch adds a new debugfs entry for each connector that supports
HDCP. For enforcing a particular HDCP version for a connector, the user
can write into the debugfs for that connector.
To make design simple, the HDCP version request can only be made via
debugfs, if there is no ongoing request for Content-Protection for
the connector. The tests are expected to make sure that HDCP is disabled
before making HDCP version request via the debugfs for the connector.
Otherwise, the write request to the debugfs will be failed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_debugfs.c | 98 +++
1 file changed, 98 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 70525623bcdf..e65abca1a1fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2185,6 +2185,102 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_hdcp_ver_request_show(struct seq_file *m, void *data)
+{
+
+ struct drm_connector *connector = m->private;
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ u64 hdcp_ver_flag;
u64 seems a little excessive for something that needs 2 bits.
Agreed. Will change this in next version.
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ /* HDCP is supported by connector */
+ if (!intel_connector->hdcp.shim)
+ return -EINVAL;
Why do you need to check these? The version request is valid regardless
of connection or hdcp, no?
Hmm, for connectors that are unconnected or do not support hdcp, the
member `hdcp` will not have any useful value.
The `debugfs_ver_request` is initialized to dafault value only if
hdcp.shim exists.
It might show perhaps incorrect flag.
+
+ hdcp_ver_flag = intel_connector->hdcp.debugfs_ver_request;
+ seq_printf(m, "HDCP_VER_FLAGS: %llu\n", hdcp_ver_flag);
+
+ seq_printf(m, "Requested Versions:\n");
+ if (hdcp_ver_flag & HDCP_VERSION_1_4)
+ seq_printf(m, "HDCP1.4\n");
+ if (hdcp_ver_flag & HDCP_VERSION_2_2)
+ seq_printf(m, "HDCP2.2\n");
Why do you need to print duplicated information? One or the other, not
both. Simplify, don't complicate.
Alright, I will just keep the print with HDCP_VER_FLAGS, that should be
sufficient.
+
+ return 0;
+}
+
+static int i915_hdcp_ver_request_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_hdcp_ver_request_show,
+inode->i_private);
+}
+
+static int intel_hdcp_debugfs_ver_set(struct intel_connector *connector, u64
val)
+{
+ struct intel_hdcp *hdcp = &connector->hdcp;
+
+ if (!hdcp->shim || val > HDCP_VERSION_MASK)
+ return -EINVAL;
+
+ if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
+ return -EINVAL;
What does it matter if you can request the version independent of what's
currently going on? I think it's just extra code that can go wrong here.
I was a little skeptical about the behavior if the authentication is
getting retried, and in between
there is a change in the requested version. But again since this is a
debug environment, the
test should be knowing what it is doing. I can do away with this code.
+
+ hdcp->debugfs_ver_request = val;
Usually there's a blank line before the return.
Noted. Will take care in the next version.
+ return 0;
+}
Perhaps even the helper is excessive here.
Alright, will get rid of this in next version.
+
+static ssize_t i915_hdcp_ver_request_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ unsigned int hdcp_ver = 0;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_connector *intel_con = to_intel_connector(connector);
It's *never* intel_con. It's either intel_connector or just connector.
Noted. I think I was trying to squeeze into 80 chars.
I will conform to the existing norms f
Re: [Intel-gfx] [RFC 1/2] drm/i915: Add support for considering HDCP ver requested via debugfs
On 5/27/2020 7:48 PM, Jani Nikula wrote:
On Wed, 27 May 2020, Ankit Nautiyal wrote:
For testing and debugging each HDCP version separately, a debugfs
entry for requesting a specific version is required. The vesion
requested via debugfs needs to be stored in hdcp structure. This can
then be considered while enabling HDCP, provided the platform and the
display supports the requested version.
This patch adds the support for storing the version requested as a 32bit
flag. The default value is set to signify that any of the HDCP version
can be used.
If a specific HDCP version is requested through the debugfs, the driver
chooses that version, instead of policy of choosing the highest HDCP
version supported.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_display_types.h | 10 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 8 ++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9488449e4b94..cfa641c70717 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -408,6 +408,16 @@ struct intel_hdcp {
* Hence caching the transcoder here.
*/
enum transcoder cpu_transcoder;
+
+ /*
+ * HDCP version requested from debugfs i915_hdcp_ver_request.
+ * Kernel will read these bits and entertain the request, as per
+ * the HDCP capability of the panel and platform.
+ */
+#define HDCP_VERSION_1_4 0x01
+#define HDCP_VERSION_2_2 0x02
+#define HDCP_VERSION_MASK0x03
+ u32 debugfs_ver_request;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 2cbc4619b4ce..951401046804 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1977,6 +1977,8 @@ int intel_hdcp_init(struct intel_connector *connector,
if (!shim)
return -EINVAL;
+ hdcp->debugfs_ver_request = HDCP_VERSION_MASK;
It's almost always better to keep 0 as the default or initial value. If
the member is non-zero, you do as requested.
I was thinking if we can have a request for "neither of the versions" to
be represented as 0.
But that seems to be silly now, without any actual use case, when I look
closely.
I will have this set to 0 by default and only use the member if non-zero.
Thanks,
Ankit
+
if (is_hdcp2_supported(dev_priv))
intel_hdcp2_init(connector, shim);
@@ -2023,7 +2025,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* Considering that HDCP2.2 is more secure than HDCP1.4, If the setup
* is capable of HDCP2.2, it is preferred to use HDCP2.2.
*/
- if (intel_hdcp2_capable(connector)) {
+ if ((hdcp->debugfs_ver_request & HDCP_VERSION_2_2) &&
+ intel_hdcp2_capable(connector)) {
ret = _intel_hdcp2_enable(connector);
if (!ret)
check_link_interval = DRM_HDCP2_CHECK_PERIOD_MS;
@@ -2033,7 +2036,8 @@ int intel_hdcp_enable(struct intel_connector *connector,
* When HDCP2.2 fails and Content Type is not Type1, HDCP1.4 will
* be attempted.
*/
- if (ret && intel_hdcp_capable(connector) &&
+ if (ret && (hdcp->debugfs_ver_request & HDCP_VERSION_1_4) &&
+ intel_hdcp_capable(connector) &&
hdcp->content_type != DRM_MODE_HDCP_CONTENT_TYPE1) {
ret = _intel_hdcp_enable(connector);
}
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/gt: Prevent timeslicing into unpreemptable requests
We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent
the HW from preempting during the course of this request. We need to
honour this flag and protect the HW even if we have a heartbeat request,
or other maximum priority barrier, pending. As such, restrict the
timeslicing check to avoid preempting into the topmost priority band,
leaving the unpreemptable requests in blissful peace running
uninterrupted on the HW.
v2: Set the I915_PRIORITY_BARRIER to be less than
I915_PRIORITY_UNPREEMPTABLE so that we never submit a request
(heartbeat or barrier) that can legitimately preempt the current
non-premptable request.
Fixes: 2a98f4e65bba ("drm/i915: add infrastructure to hold off preemption on a
request")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c| 1 +
drivers/gpu/drm/i915/gt/selftest_lrc.c | 118 -
drivers/gpu/drm/i915/i915_priolist_types.h | 2 +-
3 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3214a4ecc31a..197efd9ea1e9 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1928,6 +1928,7 @@ need_timeslice(const struct intel_engine_cs *engine,
if (!list_is_last(&rq->sched.link, &engine->active.requests))
hint = max(hint, rq_prio(list_next_entry(rq, sched.link)));
+ GEM_BUG_ON(hint == I915_PRIORITY_UNPREEMPTABLE);
return hint >= effective_prio(rq);
}
diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
b/drivers/gpu/drm/i915/gt/selftest_lrc.c
index 66f710b1b61e..3e35a45d6218 100644
--- a/drivers/gpu/drm/i915/gt/selftest_lrc.c
+++ b/drivers/gpu/drm/i915/gt/selftest_lrc.c
@@ -823,7 +823,7 @@ slice_semaphore_queue(struct intel_engine_cs *outer,
}
}
- err = release_queue(outer, vma, n, INT_MAX);
+ err = release_queue(outer, vma, n, I915_PRIORITY_BARRIER);
if (err)
goto out;
@@ -1289,6 +1289,121 @@ static int live_timeslice_queue(void *arg)
return err;
}
+static int live_timeslice_nopreempt(void *arg)
+{
+ struct intel_gt *gt = arg;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+ struct igt_spinner spin;
+ int err = 0;
+
+ /*
+* We should not timeslice into a request that is marked with
+* I915_REQUEST_NOPREEMPT.
+*/
+ if (!IS_ACTIVE(CONFIG_DRM_I915_TIMESLICE_DURATION))
+ return 0;
+
+ if (igt_spinner_init(&spin, gt))
+ return -ENOMEM;
+
+ for_each_engine(engine, gt, id) {
+ struct intel_context *ce;
+ struct i915_request *rq;
+ unsigned long timeslice;
+
+ if (!intel_engine_has_preemption(engine))
+ continue;
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(ce);
+ break;
+ }
+
+ engine_heartbeat_disable(engine);
+ timeslice = xchg(&engine->props.timeslice_duration_ms, 1);
+
+ /* Create an unpreemptible spinner */
+
+ rq = igt_spinner_create_request(&spin, ce, MI_ARB_CHECK);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_heartbeat;
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ if (!igt_wait_for_spinner(&spin, rq)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ set_bit(I915_FENCE_FLAG_NOPREEMPT, &rq->fence.flags);
+ i915_request_put(rq);
+
+ /* Followed by a maximum priority barrier (heartbeat) */
+
+ ce = intel_context_create(engine);
+ if (IS_ERR(ce)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq = intel_context_create_request(ce);
+ intel_context_put(ce);
+ if (IS_ERR(rq)) {
+ err = PTR_ERR(rq);
+ goto out_spin;
+ }
+
+ rq->sched.attr.priority = I915_PRIORITY_BARRIER;
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ /*
+* Wait until the barrier is in ELSP, and we know timeslicing
+* will have been activated.
+*/
+ if (wait_for_submit(engine, rq, HZ / 2)) {
+ i915_request_put(rq);
+ err = -ETIME;
+ goto out_spin;
+ }
+
+ /*
+* Since the ELSP[0] request is unpreemptible, it should no
