* Re: [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()
From: Tvrtko Ursulin @ 2017-01-03 14:04 UTC (permalink / raw)
To: Chris Wilson, dri-devel; +Cc: intel-gfx
In-Reply-To: <20170103110533.31880-1-chris@chris-wilson.co.uk>
On 03/01/2017 11:05, Chris Wilson wrote:
> As the fence->status is an optional field that may be set before
> dma_fence_signal() is called to convey that the fence completed with an
> error, we have to ensure that it is always set to zero on initialisation
> so that the typical use (i.e. unset) always flags a successful completion.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
> drivers/dma-buf/dma-fence.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 3444f293ad4a..9130f790ebf3 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
> fence->context = context;
> fence->seqno = seqno;
> fence->flags = 0UL;
> + fence->status = 0;
>
> trace_dma_fence_init(fence);
> }
>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] drm/i915/execlists: Reorder execlists register enabling
From: Chris Wilson @ 2017-01-03 14:04 UTC (permalink / raw)
To: intel-gfx; +Cc: Mika Kuoppala
Empirically we restart more successfully if we call lrc_init_hws()
(which contains a posting read) last. (The failure mode that was
observed was that breadcrumb writes into the HWS from the recovered
request went astray leading to the context-switch maintaining forward
progress, but the requests not being retired/completed.)
For clarity, lrc_init_hws() is inlined (and the unused function then
removed).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
---
drivers/gpu/drm/i915/intel_lrc.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index cc229d5998bb..33fe7e5c9364 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1329,15 +1329,6 @@ static int intel_init_workaround_bb(struct intel_engine_cs *engine)
return ret;
}
-static void lrc_init_hws(struct intel_engine_cs *engine)
-{
- struct drm_i915_private *dev_priv = engine->i915;
-
- I915_WRITE(RING_HWS_PGA(engine->mmio_base),
- engine->status_page.ggtt_offset);
- POSTING_READ(RING_HWS_PGA(engine->mmio_base));
-}
-
static int gen8_init_common_ring(struct intel_engine_cs *engine)
{
struct drm_i915_private *dev_priv = engine->i915;
@@ -1347,20 +1338,19 @@ static int gen8_init_common_ring(struct intel_engine_cs *engine)
if (ret)
return ret;
- lrc_init_hws(engine);
-
intel_engine_reset_breadcrumbs(engine);
+ intel_engine_init_hangcheck(engine);
I915_WRITE(RING_HWSTAM(engine->mmio_base), 0xffffffff);
-
I915_WRITE(RING_MODE_GEN7(engine),
_MASKED_BIT_DISABLE(GFX_REPLAY_MODE) |
_MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
+ I915_WRITE(RING_HWS_PGA(engine->mmio_base),
+ engine->status_page.ggtt_offset);
+ POSTING_READ(RING_HWS_PGA(engine->mmio_base));
DRM_DEBUG_DRIVER("Execlists enabled for %s\n", engine->name);
- intel_engine_init_hangcheck(engine);
-
/* After a GPU reset, we may have requests to replay */
if (!i915.enable_guc_submission && !execlists_elsp_idle(engine)) {
engine->execlist_port[0].count = 0;
--
2.11.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH] drm/i915: Initialize num_scalers for skl and glk too
From: Chris Wilson @ 2017-01-03 13:58 UTC (permalink / raw)
To: Ander Conselvan De Oliveira; +Cc: Tomi Sarvela, intel-gfx, Daniel Vetter
In-Reply-To: <1483451355.5671.13.camel@gmail.com>
On Tue, Jan 03, 2017 at 03:49:15PM +0200, Ander Conselvan De Oliveira wrote:
> On Tue, 2017-01-03 at 12:26 +0200, Ander Conselvan De Oliveira wrote:
> > On Mon, 2017-01-02 at 14:57 +0000, Chris Wilson wrote:
> > >
> > > On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> > > >
> > > >
> > > > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers
> > > > initialization
> > > > to
> > > > runtime init"), scalers are not initialized properly for skl and glk
> > > > since num_scalers is left as 0 for those platforms.
> > > Next question is why this user visible change is not causing test
> > > failures in BAT?
> > There isn't a single test in BAT that tries to setup a plane with scaling. The
> > kms_panel_fitting and kms_plane_scaling tests would have caught the issue, but
> > they are not part of BAT. kms_plane and kms_universal_plane are also not part
> > of
> > BAT, and they also don't test scaling.
>
> Is it feasible to add one of those tests to BAT? Would it help with the time
> constraints if we run it only on gen9+? There's already a test for gen9 specific
> things in kms_universal_plane, maybe we could use that?
Yes, it is definitely a hole that needs addressing, and needs to be
checked on all gen (some just have more versatile panel fitters than
others). The challenge for you is to devise the smallest test with the
widest coverage of the scalers - which may just be an existing test.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/i915: Initialize num_scalers for skl and glk too
From: Ander Conselvan De Oliveira @ 2017-01-03 13:49 UTC (permalink / raw)
To: Chris Wilson, Tomi Sarvela, Petri Latvala; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <1483439189.5671.6.camel@gmail.com>
On Tue, 2017-01-03 at 12:26 +0200, Ander Conselvan De Oliveira wrote:
> On Mon, 2017-01-02 at 14:57 +0000, Chris Wilson wrote:
> >
> > On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> > >
> > >
> > > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers
> > > initialization
> > > to
> > > runtime init"), scalers are not initialized properly for skl and glk
> > > since num_scalers is left as 0 for those platforms.
> > Next question is why this user visible change is not causing test
> > failures in BAT?
> There isn't a single test in BAT that tries to setup a plane with scaling. The
> kms_panel_fitting and kms_plane_scaling tests would have caught the issue, but
> they are not part of BAT. kms_plane and kms_universal_plane are also not part
> of
> BAT, and they also don't test scaling.
Is it feasible to add one of those tests to BAT? Would it help with the time
constraints if we run it only on gen9+? There's already a test for gen9 specific
things in kms_universal_plane, maybe we could use that?
Ander
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/i915: Only skip requests once a context is banned
From: Tvrtko Ursulin @ 2017-01-03 13:49 UTC (permalink / raw)
To: Chris Wilson, intel-gfx; +Cc: Mika Kuoppala
In-Reply-To: <20170103115906.2461-1-chris@chris-wilson.co.uk>
On 03/01/2017 11:59, Chris Wilson wrote:
> If we skip before banning, we have an inconsistent interface between
> execbuf still queueing valid request but those requests already queued
> being cancelled. If we only cancel the pending requests once we stop
> accepting new requests, the interface is more consistent.
>
> Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0bfc99fcac8c..3d0eb9391d3d 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2739,7 +2739,7 @@ static void reset_request(struct drm_i915_gem_request *request)
> static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> {
> struct drm_i915_gem_request *request;
> - struct i915_gem_context *incomplete_ctx;
> + struct i915_gem_context *hung_ctx;
> struct intel_timeline *timeline;
> unsigned long flags;
> bool ring_hung;
> @@ -2751,6 +2751,8 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> if (!request)
> return;
>
> + hung_ctx = request->ctx;
> +
> ring_hung = engine->hangcheck.stalled;
> if (engine->hangcheck.seqno != intel_engine_get_seqno(engine)) {
> DRM_DEBUG_DRIVER("%s pardoned, was guilty? %s\n",
> @@ -2760,10 +2762,10 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> }
>
> if (ring_hung) {
> - i915_gem_context_mark_guilty(request->ctx);
> + i915_gem_context_mark_guilty(hung_ctx);
> request->fence.status = -EIO;
> } else {
> - i915_gem_context_mark_innocent(request->ctx);
> + i915_gem_context_mark_innocent(hung_ctx);
> }
>
> if (!ring_hung)
> @@ -2775,6 +2777,10 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> /* Setup the CS to resume from the breadcrumb of the hung request */
> engine->reset_hw(engine, request);
>
> + /* If this context is now banned, skip all of its pending requests. */
> + if (!i915_gem_context_is_banned(hung_ctx))
> + return;
> +
> /* Users of the default context do not rely on logical state
> * preserved between batches. They have to emit full state on
> * every batch and so it is safe to execute queued requests following
> @@ -2783,17 +2789,16 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> * Other contexts preserve state, now corrupt. We want to skip all
> * queued requests that reference the corrupt context.
> */
> - incomplete_ctx = request->ctx;
> - if (i915_gem_context_is_default(incomplete_ctx))
> + if (i915_gem_context_is_default(hung_ctx))
> return;
>
> - timeline = i915_gem_context_lookup_timeline(incomplete_ctx, engine);
> + timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
>
> spin_lock_irqsave(&engine->timeline->lock, flags);
> spin_lock(&timeline->lock);
>
> list_for_each_entry_continue(request, &engine->timeline->requests, link)
> - if (request->ctx == incomplete_ctx)
> + if (request->ctx == hung_ctx)
> reset_request(request);
>
> list_for_each_entry(request, &timeline->requests, link)
>
LGTM, but hopefully Mika can also double-check.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/i915: Initialize num_scalers for skl and glk too
From: Conselvan De Oliveira, Ander @ 2017-01-03 13:45 UTC (permalink / raw)
To: ville.syrjala@linux.intel.com
Cc: Vetter, Daniel, intel-gfx@lists.freedesktop.org
In-Reply-To: <20170103133500.GD31595@intel.com>
On Tue, 2017-01-03 at 15:35 +0200, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> >
> > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization
> > to
> > runtime init"), scalers are not initialized properly for skl and glk
> > since num_scalers is left as 0 for those platforms.
> >
> > Fixes: 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to
> > runtime init")
> > Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
> > Cc: Chris Wilson <chris@chris-wilson.co.uk> (v2)
> > Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
> > Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: intel-gfx@lists.freedesktop.org
> > Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@inte
> > l.com>
> Fixes my CCS test. What happened was apparently the BIOS leaving the
> scaler enabled and then when i915 took over all but the preferred mode
> of the display came out garbled on account of the scaler output not
> fitting within the h/vactive of the mode.
>
> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Pushed. Thanks for reviewing.
Ander
>
> >
> > ---
> > drivers/gpu/drm/i915/intel_device_info.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> > b/drivers/gpu/drm/i915/intel_device_info.c
> > index 1b5ffc4..f642f6d 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.c
> > +++ b/drivers/gpu/drm/i915/intel_device_info.c
> > @@ -310,6 +310,12 @@ void intel_device_info_runtime_init(struct
> > drm_i915_private *dev_priv)
> > struct intel_device_info *info = mkwrite_device_info(dev_priv);
> > enum pipe pipe;
> >
> > + if (INTEL_GEN(dev_priv) >= 9) {
> > + info->num_scalers[PIPE_A] = 2;
> > + info->num_scalers[PIPE_B] = 2;
> > + info->num_scalers[PIPE_C] = 1;
> > + }
> > +
> > /*
> > * Skylake and Broxton currently don't expose the topmost plane as
> > its
> > * use is exclusive with the legacy cursor and we only want to
> > expose
> > @@ -325,9 +331,6 @@ void intel_device_info_runtime_init(struct
> > drm_i915_private *dev_priv)
> > info->num_sprites[PIPE_A] = 2;
> > info->num_sprites[PIPE_B] = 2;
> > info->num_sprites[PIPE_C] = 1;
> > - info->num_scalers[PIPE_A] = 2;
> > - info->num_scalers[PIPE_B] = 2;
> > - info->num_scalers[PIPE_C] = 1;
> > } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> > for_each_pipe(dev_priv, pipe)
> > info->num_sprites[pipe] = 2;
> > --
> > 2.5.5
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/i915: Initialize num_scalers for skl and glk too
From: Ville Syrjälä @ 2017-01-03 13:35 UTC (permalink / raw)
To: Ander Conselvan de Oliveira; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <1483365281-10569-1-git-send-email-ander.conselvan.de.oliveira@intel.com>
On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to
> runtime init"), scalers are not initialized properly for skl and glk
> since num_scalers is left as 0 for those platforms.
>
> Fixes: 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to runtime init")
> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
> Cc: Chris Wilson <chris@chris-wilson.co.uk> (v2)
> Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Fixes my CCS test. What happened was apparently the BIOS leaving the
scaler enabled and then when i915 took over all but the preferred mode
of the display came out garbled on account of the scaler output not
fitting within the h/vactive of the mode.
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_device_info.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c
> index 1b5ffc4..f642f6d 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -310,6 +310,12 @@ void intel_device_info_runtime_init(struct drm_i915_private *dev_priv)
> struct intel_device_info *info = mkwrite_device_info(dev_priv);
> enum pipe pipe;
>
> + if (INTEL_GEN(dev_priv) >= 9) {
> + info->num_scalers[PIPE_A] = 2;
> + info->num_scalers[PIPE_B] = 2;
> + info->num_scalers[PIPE_C] = 1;
> + }
> +
> /*
> * Skylake and Broxton currently don't expose the topmost plane as its
> * use is exclusive with the legacy cursor and we only want to expose
> @@ -325,9 +331,6 @@ void intel_device_info_runtime_init(struct drm_i915_private *dev_priv)
> info->num_sprites[PIPE_A] = 2;
> info->num_sprites[PIPE_B] = 2;
> info->num_sprites[PIPE_C] = 1;
> - info->num_scalers[PIPE_A] = 2;
> - info->num_scalers[PIPE_B] = 2;
> - info->num_scalers[PIPE_C] = 1;
> } else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
> for_each_pipe(dev_priv, pipe)
> info->num_sprites[pipe] = 2;
> --
> 2.5.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: linux-next: build failure after merge of the drm-intel-fixes tree
From: Jani Nikula @ 2017-01-03 13:25 UTC (permalink / raw)
To: Zhenyu Wang, Alex Williamson
Cc: Stephen Rothwell, Daniel Vetter, Intel Graphics, linux-kernel,
DRI, linux-next
In-Reply-To: <20170103092317.slzmtrdzzrjzbypw@zhen-hp.sh.intel.com>
On Tue, 03 Jan 2017, Zhenyu Wang <zhenyuw@linux.intel.com> wrote:
> On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
>> > Alex, I liked to have kvmgt related mdev interface change be merged through
>> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
>> > below fix in your tree? I think in general for possible interface change in
>> > future we still need a pull request for i915 to resolve dependence earlier.
>>
>> Hi Zhenyu,
>>
>> Hopefully this abstraction will help to isolate vendor drivers from
>> mdev API changes in the future. I can certainly roll this patch into
>> the original to maintain bisectability. I want to get these changes in
>> for rc3, will a pull request for the i915 changes be sent this week?
>
> Send to Jani who is managing i915 fixes pull.
Send what to me? I've pushed fixes to drm-intel-fixes today for testing,
and expect to send a pull request to Dave early Thursday. If there's a
conflict, it can usually be solved while merging, like Stephen has done.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Chris Wilson @ 2017-01-03 13:25 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, dri-devel
In-Reply-To: <1943b5da-fd46-9fce-d79b-0ba28ba89bd8@linux.intel.com>
On Tue, Jan 03, 2017 at 01:17:19PM +0000, Tvrtko Ursulin wrote:
>
> On 03/01/2017 12:38, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 12:34:16PM +0000, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 12:13, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017 at 11:57:44AM +0000, Tvrtko Ursulin wrote:
> >>>>
> >>>>On 03/01/2017 11:46, Chris Wilson wrote:
> >>>>>On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
> >>>>>>
> >>>>>>On 03/01/2017 11:05, Chris Wilson wrote:
> >>>>>>>The struct dma_fence carries a status field exposed to userspace by
> >>>>>>>sync_file. This is inspected after the fence is signaled and can convey
> >>>>>>>whether or not the request completed successfully, or in our case if we
> >>>>>>>detected a hang during the request (signaled via -EIO in
> >>>>>>>SYNC_IOC_FILE_INFO).
> >>>>>>>
> >>>>>>>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>>>Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>>>>>Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> >>>>>>>---
> >>>>>>>drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
> >>>>>>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>>diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> >>>>>>>index 204c4a673bf3..bc99c0e292d8 100644
> >>>>>>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>>>>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>>>>>@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> >>>>>>> ring_hung = false;
> >>>>>>> }
> >>>>>>>
> >>>>>>>- if (ring_hung)
> >>>>>>>+ if (ring_hung) {
> >>>>>>> i915_gem_context_mark_guilty(request->ctx);
> >>>>>>>- else
> >>>>>>>+ request->fence.status = -EIO;
> >>>>>>>+ } else {
> >>>>>>> i915_gem_context_mark_innocent(request->ctx);
> >>>>>>>+ }
> >>>>>>>
> >>>>>>> if (!ring_hung)
> >>>>>>> return;
> >>>>>>>
> >>>>>>
> >>>>>>Reading what happens later in this function, should we set the
> >>>>>>status of all the other requests we are about to clear?
> >>>>>>
> >>>>>>However one thing I don't understand is how this scheme interacts
> >>>>>>with the current userspace. We will clear/no-nop some of the
> >>>>>>submitted requests since the state is corrupt. But how will
> >>>>>>userspace notice this before it submits more requets?
> >>>>>
> >>>>>There is no mechanism currently for user space to be able to detect a
> >>>>>hung request. (It can use the uevent for async notification of the
> >>>>>hang/reset, but that will not tell you who caused the hang.) Userspace
> >>>>>can track the number of hangs it caused, but the delay makes any
> >>>>>roundtripping impractical (i.e. you have to synchronise before all
> >>>>>rendering if you must detect the event immediately). Note also that we
> >>>>>do not want to give out interprocess information (i.e. to allow one
> >>>>>client to spy on another), which makes things harder to get right.
> >>>>
> >>>>So idea is to clear already submitted requests _if_ the userspace is
> >>>>synchronising before all rendering and looking at reset stats, to
> >>>>make it theoretically possible to detect the corrupt state?
> >>>
> >>>No, I'm just don't see a way that userspace can detect the hang without
> >>>testing after seeing the request signaled (either by waiting on the
> >>>batch or by waiting on the fence), i.e. by being completely synchronous
> >>>(or at least chosing its synchronous points very carefully, such as
> >>>around IPC). It can either poll reset-count or use sync_file (which
> >>>requires fence exporting).
> >>>
> >>>The current robustness interfaces is a basic query on whether any reset
> >>>occurred within the context, not when.
> >>
> >>Why do we bother with clearing the submitted requests then?
> >
> >The same reason we ban processes from submitting new requests if they
> >cause repeated hangs. If before we ban that client, it has already
> >submitted 1000 hanging requests, it has successfully locked the machine
> >up for a couple of hours.
>
> So we would need to gate clearing on the transition to banned state
> I think. Because currently it does in unconditionally.
Yes, see the other patch :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Tvrtko Ursulin @ 2017-01-03 13:17 UTC (permalink / raw)
To: Chris Wilson, dri-devel, intel-gfx
In-Reply-To: <20170103123824.GL16295@nuc-i3427.alporthouse.com>
On 03/01/2017 12:38, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 12:34:16PM +0000, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 12:13, Chris Wilson wrote:
>>> On Tue, Jan 03, 2017 at 11:57:44AM +0000, Tvrtko Ursulin wrote:
>>>>
>>>> On 03/01/2017 11:46, Chris Wilson wrote:
>>>>> On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
>>>>>>
>>>>>> On 03/01/2017 11:05, Chris Wilson wrote:
>>>>>>> The struct dma_fence carries a status field exposed to userspace by
>>>>>>> sync_file. This is inspected after the fence is signaled and can convey
>>>>>>> whether or not the request completed successfully, or in our case if we
>>>>>>> detected a hang during the request (signaled via -EIO in
>>>>>>> SYNC_IOC_FILE_INFO).
>>>>>>>
>>>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>>>>>>> ---
>>>>>>> drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
>>>>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>>>>>>> index 204c4a673bf3..bc99c0e292d8 100644
>>>>>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>>>>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>>>>>> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
>>>>>>> ring_hung = false;
>>>>>>> }
>>>>>>>
>>>>>>> - if (ring_hung)
>>>>>>> + if (ring_hung) {
>>>>>>> i915_gem_context_mark_guilty(request->ctx);
>>>>>>> - else
>>>>>>> + request->fence.status = -EIO;
>>>>>>> + } else {
>>>>>>> i915_gem_context_mark_innocent(request->ctx);
>>>>>>> + }
>>>>>>>
>>>>>>> if (!ring_hung)
>>>>>>> return;
>>>>>>>
>>>>>>
>>>>>> Reading what happens later in this function, should we set the
>>>>>> status of all the other requests we are about to clear?
>>>>>>
>>>>>> However one thing I don't understand is how this scheme interacts
>>>>>> with the current userspace. We will clear/no-nop some of the
>>>>>> submitted requests since the state is corrupt. But how will
>>>>>> userspace notice this before it submits more requets?
>>>>>
>>>>> There is no mechanism currently for user space to be able to detect a
>>>>> hung request. (It can use the uevent for async notification of the
>>>>> hang/reset, but that will not tell you who caused the hang.) Userspace
>>>>> can track the number of hangs it caused, but the delay makes any
>>>>> roundtripping impractical (i.e. you have to synchronise before all
>>>>> rendering if you must detect the event immediately). Note also that we
>>>>> do not want to give out interprocess information (i.e. to allow one
>>>>> client to spy on another), which makes things harder to get right.
>>>>
>>>> So idea is to clear already submitted requests _if_ the userspace is
>>>> synchronising before all rendering and looking at reset stats, to
>>>> make it theoretically possible to detect the corrupt state?
>>>
>>> No, I'm just don't see a way that userspace can detect the hang without
>>> testing after seeing the request signaled (either by waiting on the
>>> batch or by waiting on the fence), i.e. by being completely synchronous
>>> (or at least chosing its synchronous points very carefully, such as
>>> around IPC). It can either poll reset-count or use sync_file (which
>>> requires fence exporting).
>>>
>>> The current robustness interfaces is a basic query on whether any reset
>>> occurred within the context, not when.
>>
>> Why do we bother with clearing the submitted requests then?
>
> The same reason we ban processes from submitting new requests if they
> cause repeated hangs. If before we ban that client, it has already
> submitted 1000 hanging requests, it has successfully locked the machine
> up for a couple of hours.
So we would need to gate clearing on the transition to banned state I
think. Because currently it does in unconditionally.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Chris Wilson @ 2017-01-03 12:38 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, dri-devel
In-Reply-To: <246ff8ce-1fd3-7dc5-010c-6a38051f3206@linux.intel.com>
On Tue, Jan 03, 2017 at 12:34:16PM +0000, Tvrtko Ursulin wrote:
>
> On 03/01/2017 12:13, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:57:44AM +0000, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:46, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
> >>>>
> >>>>On 03/01/2017 11:05, Chris Wilson wrote:
> >>>>>The struct dma_fence carries a status field exposed to userspace by
> >>>>>sync_file. This is inspected after the fence is signaled and can convey
> >>>>>whether or not the request completed successfully, or in our case if we
> >>>>>detected a hang during the request (signaled via -EIO in
> >>>>>SYNC_IOC_FILE_INFO).
> >>>>>
> >>>>>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>>>>Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>>>Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> >>>>>---
> >>>>>drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
> >>>>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>>>
> >>>>>diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> >>>>>index 204c4a673bf3..bc99c0e292d8 100644
> >>>>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>>>@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> >>>>> ring_hung = false;
> >>>>> }
> >>>>>
> >>>>>- if (ring_hung)
> >>>>>+ if (ring_hung) {
> >>>>> i915_gem_context_mark_guilty(request->ctx);
> >>>>>- else
> >>>>>+ request->fence.status = -EIO;
> >>>>>+ } else {
> >>>>> i915_gem_context_mark_innocent(request->ctx);
> >>>>>+ }
> >>>>>
> >>>>> if (!ring_hung)
> >>>>> return;
> >>>>>
> >>>>
> >>>>Reading what happens later in this function, should we set the
> >>>>status of all the other requests we are about to clear?
> >>>>
> >>>>However one thing I don't understand is how this scheme interacts
> >>>>with the current userspace. We will clear/no-nop some of the
> >>>>submitted requests since the state is corrupt. But how will
> >>>>userspace notice this before it submits more requets?
> >>>
> >>>There is no mechanism currently for user space to be able to detect a
> >>>hung request. (It can use the uevent for async notification of the
> >>>hang/reset, but that will not tell you who caused the hang.) Userspace
> >>>can track the number of hangs it caused, but the delay makes any
> >>>roundtripping impractical (i.e. you have to synchronise before all
> >>>rendering if you must detect the event immediately). Note also that we
> >>>do not want to give out interprocess information (i.e. to allow one
> >>>client to spy on another), which makes things harder to get right.
> >>
> >>So idea is to clear already submitted requests _if_ the userspace is
> >>synchronising before all rendering and looking at reset stats, to
> >>make it theoretically possible to detect the corrupt state?
> >
> >No, I'm just don't see a way that userspace can detect the hang without
> >testing after seeing the request signaled (either by waiting on the
> >batch or by waiting on the fence), i.e. by being completely synchronous
> >(or at least chosing its synchronous points very carefully, such as
> >around IPC). It can either poll reset-count or use sync_file (which
> >requires fence exporting).
> >
> >The current robustness interfaces is a basic query on whether any reset
> >occurred within the context, not when.
>
> Why do we bother with clearing the submitted requests then?
The same reason we ban processes from submitting new requests if they
cause repeated hangs. If before we ban that client, it has already
submitted 1000 hanging requests, it has successfully locked the machine
up for a couple of hours.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Tvrtko Ursulin @ 2017-01-03 12:34 UTC (permalink / raw)
To: Chris Wilson, dri-devel, intel-gfx
In-Reply-To: <20170103121320.GK16295@nuc-i3427.alporthouse.com>
On 03/01/2017 12:13, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 11:57:44AM +0000, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 11:46, Chris Wilson wrote:
>>> On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
>>>>
>>>> On 03/01/2017 11:05, Chris Wilson wrote:
>>>>> The struct dma_fence carries a status field exposed to userspace by
>>>>> sync_file. This is inspected after the fence is signaled and can convey
>>>>> whether or not the request completed successfully, or in our case if we
>>>>> detected a hang during the request (signaled via -EIO in
>>>>> SYNC_IOC_FILE_INFO).
>>>>>
>>>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>>>>> ---
>>>>> drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
>>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>>>>> index 204c4a673bf3..bc99c0e292d8 100644
>>>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>>>> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
>>>>> ring_hung = false;
>>>>> }
>>>>>
>>>>> - if (ring_hung)
>>>>> + if (ring_hung) {
>>>>> i915_gem_context_mark_guilty(request->ctx);
>>>>> - else
>>>>> + request->fence.status = -EIO;
>>>>> + } else {
>>>>> i915_gem_context_mark_innocent(request->ctx);
>>>>> + }
>>>>>
>>>>> if (!ring_hung)
>>>>> return;
>>>>>
>>>>
>>>> Reading what happens later in this function, should we set the
>>>> status of all the other requests we are about to clear?
>>>>
>>>> However one thing I don't understand is how this scheme interacts
>>>> with the current userspace. We will clear/no-nop some of the
>>>> submitted requests since the state is corrupt. But how will
>>>> userspace notice this before it submits more requets?
>>>
>>> There is no mechanism currently for user space to be able to detect a
>>> hung request. (It can use the uevent for async notification of the
>>> hang/reset, but that will not tell you who caused the hang.) Userspace
>>> can track the number of hangs it caused, but the delay makes any
>>> roundtripping impractical (i.e. you have to synchronise before all
>>> rendering if you must detect the event immediately). Note also that we
>>> do not want to give out interprocess information (i.e. to allow one
>>> client to spy on another), which makes things harder to get right.
>>
>> So idea is to clear already submitted requests _if_ the userspace is
>> synchronising before all rendering and looking at reset stats, to
>> make it theoretically possible to detect the corrupt state?
>
> No, I'm just don't see a way that userspace can detect the hang without
> testing after seeing the request signaled (either by waiting on the
> batch or by waiting on the fence), i.e. by being completely synchronous
> (or at least chosing its synchronous points very carefully, such as
> around IPC). It can either poll reset-count or use sync_file (which
> requires fence exporting).
>
> The current robustness interfaces is a basic query on whether any reset
> occurred within the context, not when.
Why do we bother with clearing the submitted requests then?
Regards,
Tvrtko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Chris Wilson @ 2017-01-03 12:13 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, dri-devel
In-Reply-To: <b5cb288b-1ba4-290b-cc7e-856a752d39c3@linux.intel.com>
On Tue, Jan 03, 2017 at 11:57:44AM +0000, Tvrtko Ursulin wrote:
>
> On 03/01/2017 11:46, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:05, Chris Wilson wrote:
> >>>The struct dma_fence carries a status field exposed to userspace by
> >>>sync_file. This is inspected after the fence is signaled and can convey
> >>>whether or not the request completed successfully, or in our case if we
> >>>detected a hang during the request (signaled via -EIO in
> >>>SYNC_IOC_FILE_INFO).
> >>>
> >>>Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >>>Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> >>>---
> >>>drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
> >>>1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> >>>index 204c4a673bf3..bc99c0e292d8 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem.c
> >>>@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> >>> ring_hung = false;
> >>> }
> >>>
> >>>- if (ring_hung)
> >>>+ if (ring_hung) {
> >>> i915_gem_context_mark_guilty(request->ctx);
> >>>- else
> >>>+ request->fence.status = -EIO;
> >>>+ } else {
> >>> i915_gem_context_mark_innocent(request->ctx);
> >>>+ }
> >>>
> >>> if (!ring_hung)
> >>> return;
> >>>
> >>
> >>Reading what happens later in this function, should we set the
> >>status of all the other requests we are about to clear?
> >>
> >>However one thing I don't understand is how this scheme interacts
> >>with the current userspace. We will clear/no-nop some of the
> >>submitted requests since the state is corrupt. But how will
> >>userspace notice this before it submits more requets?
> >
> >There is no mechanism currently for user space to be able to detect a
> >hung request. (It can use the uevent for async notification of the
> >hang/reset, but that will not tell you who caused the hang.) Userspace
> >can track the number of hangs it caused, but the delay makes any
> >roundtripping impractical (i.e. you have to synchronise before all
> >rendering if you must detect the event immediately). Note also that we
> >do not want to give out interprocess information (i.e. to allow one
> >client to spy on another), which makes things harder to get right.
>
> So idea is to clear already submitted requests _if_ the userspace is
> synchronising before all rendering and looking at reset stats, to
> make it theoretically possible to detect the corrupt state?
No, I'm just don't see a way that userspace can detect the hang without
testing after seeing the request signaled (either by waiting on the
batch or by waiting on the fence), i.e. by being completely synchronous
(or at least chosing its synchronous points very carefully, such as
around IPC). It can either poll reset-count or use sync_file (which
requires fence exporting).
The current robustness interfaces is a basic query on whether any reset
occurred within the context, not when.
> Still with the fences do you agree error status needs to be set on
> those as well?
Yes.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/i915: Update comment in vlv_set_rps_idle()
From: Chris Wilson @ 2017-01-03 12:07 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
In-Reply-To: <20170102155651.GC31595@intel.com>
On Mon, Jan 02, 2017 at 05:56:51PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 03:28:45PM +0000, Chris Wilson wrote:
> > Ville explained that the wakelock was being acquired during set-idle in
> > order to flush the voltage change from the punit.
> >
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com
> > ---
> > drivers/gpu/drm/i915/intel_pm.c | 14 ++++++++++++--
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index 4406359c5f81..4c9a1b12dfee 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5011,8 +5011,18 @@ static void vlv_set_rps_idle(struct drm_i915_private *dev_priv)
> > if (dev_priv->rps.cur_freq <= val)
> > return;
> >
> > - /* Wake up the media well, as that takes a lot less
> > - * power than the Render well. */
> > + /* The punit delays the write of the frequency and voltage until it
> > + * determines the GPU is awake. During normal usage we don't want to
> > + * waste power changing the frequency if the GPU is sleeping (rc6).
> > + * However, the GPU and driver is now idle and we do not want to delay
> > + * switching to minimum voltage (reducing power whilst idle) as we do
> > + * not expect to be woken in the near future and so must flush the
> > + * change by waking the device.
> > + *
> > + * We choose to take the media powerwell (either would do to trick the
> > + * punit into commiting the voltage change) as that takes a lot less
> > + * power than the render powerwell.
> > + */
>
> lgtm
>
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Ta, fixed a spelling mistake and pushed.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] drm/i915: Only skip requests once a context is banned
From: Chris Wilson @ 2017-01-03 11:59 UTC (permalink / raw)
To: intel-gfx; +Cc: Mika Kuoppala
If we skip before banning, we have an inconsistent interface between
execbuf still queueing valid request but those requests already queued
being cancelled. If we only cancel the pending requests once we stop
accepting new requests, the interface is more consistent.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
---
drivers/gpu/drm/i915/i915_gem.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0bfc99fcac8c..3d0eb9391d3d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2739,7 +2739,7 @@ static void reset_request(struct drm_i915_gem_request *request)
static void i915_gem_reset_engine(struct intel_engine_cs *engine)
{
struct drm_i915_gem_request *request;
- struct i915_gem_context *incomplete_ctx;
+ struct i915_gem_context *hung_ctx;
struct intel_timeline *timeline;
unsigned long flags;
bool ring_hung;
@@ -2751,6 +2751,8 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
if (!request)
return;
+ hung_ctx = request->ctx;
+
ring_hung = engine->hangcheck.stalled;
if (engine->hangcheck.seqno != intel_engine_get_seqno(engine)) {
DRM_DEBUG_DRIVER("%s pardoned, was guilty? %s\n",
@@ -2760,10 +2762,10 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
}
if (ring_hung) {
- i915_gem_context_mark_guilty(request->ctx);
+ i915_gem_context_mark_guilty(hung_ctx);
request->fence.status = -EIO;
} else {
- i915_gem_context_mark_innocent(request->ctx);
+ i915_gem_context_mark_innocent(hung_ctx);
}
if (!ring_hung)
@@ -2775,6 +2777,10 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
/* Setup the CS to resume from the breadcrumb of the hung request */
engine->reset_hw(engine, request);
+ /* If this context is now banned, skip all of its pending requests. */
+ if (!i915_gem_context_is_banned(hung_ctx))
+ return;
+
/* Users of the default context do not rely on logical state
* preserved between batches. They have to emit full state on
* every batch and so it is safe to execute queued requests following
@@ -2783,17 +2789,16 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
* Other contexts preserve state, now corrupt. We want to skip all
* queued requests that reference the corrupt context.
*/
- incomplete_ctx = request->ctx;
- if (i915_gem_context_is_default(incomplete_ctx))
+ if (i915_gem_context_is_default(hung_ctx))
return;
- timeline = i915_gem_context_lookup_timeline(incomplete_ctx, engine);
+ timeline = i915_gem_context_lookup_timeline(hung_ctx, engine);
spin_lock_irqsave(&engine->timeline->lock, flags);
spin_lock(&timeline->lock);
list_for_each_entry_continue(request, &engine->timeline->requests, link)
- if (request->ctx == incomplete_ctx)
+ if (request->ctx == hung_ctx)
reset_request(request);
list_for_each_entry(request, &timeline->requests, link)
--
2.11.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Tvrtko Ursulin @ 2017-01-03 11:57 UTC (permalink / raw)
To: Chris Wilson, dri-devel, intel-gfx
In-Reply-To: <20170103114612.GI16295@nuc-i3427.alporthouse.com>
On 03/01/2017 11:46, Chris Wilson wrote:
> On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
>>
>> On 03/01/2017 11:05, Chris Wilson wrote:
>>> The struct dma_fence carries a status field exposed to userspace by
>>> sync_file. This is inspected after the fence is signaled and can convey
>>> whether or not the request completed successfully, or in our case if we
>>> detected a hang during the request (signaled via -EIO in
>>> SYNC_IOC_FILE_INFO).
>>>
>>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>>> ---
>>> drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
>>> index 204c4a673bf3..bc99c0e292d8 100644
>>> --- a/drivers/gpu/drm/i915/i915_gem.c
>>> +++ b/drivers/gpu/drm/i915/i915_gem.c
>>> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
>>> ring_hung = false;
>>> }
>>>
>>> - if (ring_hung)
>>> + if (ring_hung) {
>>> i915_gem_context_mark_guilty(request->ctx);
>>> - else
>>> + request->fence.status = -EIO;
>>> + } else {
>>> i915_gem_context_mark_innocent(request->ctx);
>>> + }
>>>
>>> if (!ring_hung)
>>> return;
>>>
>>
>> Reading what happens later in this function, should we set the
>> status of all the other requests we are about to clear?
>>
>> However one thing I don't understand is how this scheme interacts
>> with the current userspace. We will clear/no-nop some of the
>> submitted requests since the state is corrupt. But how will
>> userspace notice this before it submits more requets?
>
> There is no mechanism currently for user space to be able to detect a
> hung request. (It can use the uevent for async notification of the
> hang/reset, but that will not tell you who caused the hang.) Userspace
> can track the number of hangs it caused, but the delay makes any
> roundtripping impractical (i.e. you have to synchronise before all
> rendering if you must detect the event immediately). Note also that we
> do not want to give out interprocess information (i.e. to allow one
> client to spy on another), which makes things harder to get right.
So idea is to clear already submitted requests _if_ the userspace is
synchronising before all rendering and looking at reset stats, to make
it theoretically possible to detect the corrupt state?
Still with the fences do you agree error status needs to be set on those
as well?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* ✗ Fi.CI.BAT: failure for series starting with [1/2] dma-fence: Clear fence->status during dma_fence_init()
From: Patchwork @ 2017-01-03 11:53 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20170103110533.31880-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [1/2] dma-fence: Clear fence->status during dma_fence_init()
URL : https://patchwork.freedesktop.org/series/17403/
State : failure
== Summary ==
Series 17403v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17403/revisions/1/mbox/
Test gem_busy:
Subgroup basic-hang-default:
fail -> PASS (fi-hsw-4770r)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass -> INCOMPLETE (fi-snb-2600)
fi-bdw-5557u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14
fi-bsw-n3050 total:246 pass:207 dwarn:0 dfail:0 fail:0 skip:39
fi-bxt-j4205 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22
fi-bxt-t5700 total:82 pass:69 dwarn:0 dfail:0 fail:0 skip:12
fi-byt-j1900 total:246 pass:219 dwarn:0 dfail:0 fail:0 skip:27
fi-byt-n2820 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31
fi-hsw-4770 total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19
fi-hsw-4770r total:246 pass:227 dwarn:0 dfail:0 fail:0 skip:19
fi-ivb-3520m total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21
fi-ivb-3770 total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21
fi-kbl-7500u total:246 pass:225 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6260u total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13
fi-skl-6700hq total:246 pass:226 dwarn:0 dfail:0 fail:0 skip:20
fi-skl-6700k total:246 pass:222 dwarn:3 dfail:0 fail:0 skip:21
fi-skl-6770hq total:246 pass:233 dwarn:0 dfail:0 fail:0 skip:13
fi-snb-2520m total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31
fi-snb-2600 total:209 pass:181 dwarn:0 dfail:0 fail:0 skip:27
c882640c3f6f9571df175774c5609a798e859fe2 drm-tip: 2017y-01m-03d-10h-16m-34s UTC integration manifest
a0752fa drm/i915: Set guilty-flag on fence after detecting a hang
0269bc0 dma-fence: Clear fence->status during dma_fence_init()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3421/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Chris Wilson @ 2017-01-03 11:46 UTC (permalink / raw)
To: Tvrtko Ursulin; +Cc: intel-gfx, dri-devel
In-Reply-To: <c2cd4d31-9ce2-5180-ec26-11e764ba8a49@linux.intel.com>
On Tue, Jan 03, 2017 at 11:34:45AM +0000, Tvrtko Ursulin wrote:
>
> On 03/01/2017 11:05, Chris Wilson wrote:
> >The struct dma_fence carries a status field exposed to userspace by
> >sync_file. This is inspected after the fence is signaled and can convey
> >whether or not the request completed successfully, or in our case if we
> >detected a hang during the request (signaled via -EIO in
> >SYNC_IOC_FILE_INFO).
> >
> >Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> >---
> > drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> >index 204c4a673bf3..bc99c0e292d8 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> > ring_hung = false;
> > }
> >
> >- if (ring_hung)
> >+ if (ring_hung) {
> > i915_gem_context_mark_guilty(request->ctx);
> >- else
> >+ request->fence.status = -EIO;
> >+ } else {
> > i915_gem_context_mark_innocent(request->ctx);
> >+ }
> >
> > if (!ring_hung)
> > return;
> >
>
> Reading what happens later in this function, should we set the
> status of all the other requests we are about to clear?
>
> However one thing I don't understand is how this scheme interacts
> with the current userspace. We will clear/no-nop some of the
> submitted requests since the state is corrupt. But how will
> userspace notice this before it submits more requets?
There is no mechanism currently for user space to be able to detect a
hung request. (It can use the uevent for async notification of the
hang/reset, but that will not tell you who caused the hang.) Userspace
can track the number of hangs it caused, but the delay makes any
roundtripping impractical (i.e. you have to synchronise before all
rendering if you must detect the event immediately). Note also that we
do not want to give out interprocess information (i.e. to allow one
client to spy on another), which makes things harder to get right.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Tvrtko Ursulin @ 2017-01-03 11:34 UTC (permalink / raw)
To: Chris Wilson, dri-devel; +Cc: intel-gfx
In-Reply-To: <20170103110533.31880-2-chris@chris-wilson.co.uk>
On 03/01/2017 11:05, Chris Wilson wrote:
> The struct dma_fence carries a status field exposed to userspace by
> sync_file. This is inspected after the fence is signaled and can convey
> whether or not the request completed successfully, or in our case if we
> detected a hang during the request (signaled via -EIO in
> SYNC_IOC_FILE_INFO).
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 204c4a673bf3..bc99c0e292d8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
> ring_hung = false;
> }
>
> - if (ring_hung)
> + if (ring_hung) {
> i915_gem_context_mark_guilty(request->ctx);
> - else
> + request->fence.status = -EIO;
> + } else {
> i915_gem_context_mark_innocent(request->ctx);
> + }
>
> if (!ring_hung)
> return;
>
Reading what happens later in this function, should we set the status of
all the other requests we are about to clear?
However one thing I don't understand is how this scheme interacts with
the current userspace. We will clear/no-nop some of the submitted
requests since the state is corrupt. But how will userspace notice this
before it submits more requets?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 2/2] drm/i915: Set guilty-flag on fence after detecting a hang
From: Chris Wilson @ 2017-01-03 11:05 UTC (permalink / raw)
To: dri-devel; +Cc: Mika Kuoppala, intel-gfx, Tvrtko Ursulin
In-Reply-To: <20170103110533.31880-1-chris@chris-wilson.co.uk>
The struct dma_fence carries a status field exposed to userspace by
sync_file. This is inspected after the fence is signaled and can convey
whether or not the request completed successfully, or in our case if we
detected a hang during the request (signaled via -EIO in
SYNC_IOC_FILE_INFO).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 204c4a673bf3..bc99c0e292d8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2757,10 +2757,12 @@ static void i915_gem_reset_engine(struct intel_engine_cs *engine)
ring_hung = false;
}
- if (ring_hung)
+ if (ring_hung) {
i915_gem_context_mark_guilty(request->ctx);
- else
+ request->fence.status = -EIO;
+ } else {
i915_gem_context_mark_innocent(request->ctx);
+ }
if (!ring_hung)
return;
--
2.11.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 1/2] dma-fence: Clear fence->status during dma_fence_init()
From: Chris Wilson @ 2017-01-03 11:05 UTC (permalink / raw)
To: dri-devel; +Cc: intel-gfx
As the fence->status is an optional field that may be set before
dma_fence_signal() is called to convey that the fence completed with an
error, we have to ensure that it is always set to zero on initialisation
so that the typical use (i.e. unset) always flags a successful completion.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/dma-buf/dma-fence.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 3444f293ad4a..9130f790ebf3 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -534,6 +534,7 @@ dma_fence_init(struct dma_fence *fence, const struct dma_fence_ops *ops,
fence->context = context;
fence->seqno = seqno;
fence->flags = 0UL;
+ fence->status = 0;
trace_dma_fence_init(fence);
}
--
2.11.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH] drm/i915: Initialize num_scalers for skl and glk too
From: Ander Conselvan De Oliveira @ 2017-01-03 10:28 UTC (permalink / raw)
To: Maiti, Nabendu Bikash, Chris Wilson, intel-gfx, Daniel Vetter,
Jani Nikula
In-Reply-To: <48ec54eb-c524-5705-810d-8ee8725029e7@intel.com>
On Mon, 2017-01-02 at 21:19 +0530, Maiti, Nabendu Bikash wrote:
> I am wondering why the number of sprite initialization is not done in
> runtime init for skylake/glk similarly.
It is done in the "else if (INTEL_GEN(dev_priv) >= 5)" branch. The comment
explains why the topmost plane is not enabled.
Ander
>
> On 1/2/2017 8:27 PM, Chris Wilson wrote:
> >
> > On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> > >
> > > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers
> > > initialization to
> > > runtime init"), scalers are not initialized properly for skl and glk
> > > since num_scalers is left as 0 for those platforms.
> > Next question is why this user visible change is not causing test
> > failures in BAT?
> > -Chris
> >
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/i915: Initialize num_scalers for skl and glk too
From: Ander Conselvan De Oliveira @ 2017-01-03 10:26 UTC (permalink / raw)
To: Chris Wilson; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <20170102145733.GG16295@nuc-i3427.alporthouse.com>
On Mon, 2017-01-02 at 14:57 +0000, Chris Wilson wrote:
> On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> >
> > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization
> > to
> > runtime init"), scalers are not initialized properly for skl and glk
> > since num_scalers is left as 0 for those platforms.
> Next question is why this user visible change is not causing test
> failures in BAT?
There isn't a single test in BAT that tries to setup a plane with scaling. The
kms_panel_fitting and kms_plane_scaling tests would have caught the issue, but
they are not part of BAT. kms_plane and kms_universal_plane are also not part of
BAT, and they also don't test scaling.
Ander
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: ✓ Fi.CI.BAT: success for drm/i915/guc: Make intel_guc_recv static.
From: Tvrtko Ursulin @ 2017-01-03 10:17 UTC (permalink / raw)
To: intel-gfx, Michal Wajdeczko
In-Reply-To: <20161220134548.23056.61556@emeril.freedesktop.org>
On 20/12/2016 13:45, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/guc: Make intel_guc_recv static.
> URL : https://patchwork.freedesktop.org/series/17052/
> State : success
>
> == Summary ==
>
> Series 17052v1 drm/i915/guc: Make intel_guc_recv static.
> https://patchwork.freedesktop.org/api/1.0/series/17052/revisions/1/mbox/
>
> Test gem_sync:
> Subgroup basic-store-all:
> fail -> PASS (fi-ivb-3520m)
>
> fi-bdw-5557u total:247 pass:233 dwarn:0 dfail:0 fail:0 skip:14
> fi-bsw-n3050 total:247 pass:208 dwarn:0 dfail:0 fail:0 skip:39
> fi-bxt-j4205 total:247 pass:225 dwarn:1 dfail:0 fail:0 skip:21
> fi-byt-j1900 total:247 pass:220 dwarn:0 dfail:0 fail:0 skip:27
> fi-byt-n2820 total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31
> fi-hsw-4770 total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19
> fi-hsw-4770r total:247 pass:228 dwarn:0 dfail:0 fail:0 skip:19
> fi-ilk-650 total:247 pass:195 dwarn:0 dfail:0 fail:0 skip:52
> fi-ivb-3520m total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21
> fi-ivb-3770 total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21
> fi-kbl-7500u total:247 pass:226 dwarn:0 dfail:0 fail:0 skip:21
> fi-skl-6260u total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13
> fi-skl-6700hq total:247 pass:227 dwarn:0 dfail:0 fail:0 skip:20
> fi-skl-6700k total:247 pass:224 dwarn:3 dfail:0 fail:0 skip:20
> fi-skl-6770hq total:247 pass:234 dwarn:0 dfail:0 fail:0 skip:13
> fi-snb-2520m total:247 pass:216 dwarn:0 dfail:0 fail:0 skip:31
> fi-snb-2600 total:247 pass:215 dwarn:0 dfail:0 fail:0 skip:32
>
> b8e68c1d31266b62356d578435246516c39de36b drm-tip: 2016y-12m-20d-12h-47m-27s UTC integration manifest
> 3a2f809 drm/i915/guc: Make intel_guc_recv static.
Pushed, thanks for the patch!
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: linux-next: build failure after merge of the drm-intel-fixes tree
From: Zhenyu Wang @ 2017-01-03 9:23 UTC (permalink / raw)
To: Alex Williamson, Jani Nikula
Cc: Stephen Rothwell, Daniel Vetter, Intel Graphics, linux-kernel,
DRI, linux-next
In-Reply-To: <20170102214857.6ad8f2eb@t450s.home>
[-- Attachment #1.1: Type: text/plain, Size: 848 bytes --]
On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
> > Alex, I liked to have kvmgt related mdev interface change be merged through
> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> > below fix in your tree? I think in general for possible interface change in
> > future we still need a pull request for i915 to resolve dependence earlier.
>
> Hi Zhenyu,
>
> Hopefully this abstraction will help to isolate vendor drivers from
> mdev API changes in the future. I can certainly roll this patch into
> the original to maintain bisectability. I want to get these changes in
> for rc3, will a pull request for the i915 changes be sent this week?
Send to Jani who is managing i915 fixes pull.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox