== Series Details ==
Series: Handle link training failure during modeset for DDI (rev3)
URL : https://patchwork.freedesktop.org/series/14556/
State : failure
== Summary ==
Series 14556v3 Handle link training failure during modeset for DDI
https://patchwork.freedesktop.org/api/1.0/series/14556/
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio
(rev2)
URL : https://patchwork.freedesktop.org/series/14688/
State : warning
== Summary ==
Series 14688v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14688/revis
On Tue, 2016-11-01 at 21:50 +0200, Jani Nikula wrote:
> On Tue, 01 Nov 2016, "Pandiyan, Dhinakaran"
> wrote:
> > On Tue, 2016-11-01 at 21:35 +0200, Jani Nikula wrote:
> >> On Tue, 01 Nov 2016, Dhinakaran Pandiyan
> >> wrote:
> >> > According to BSpec, cdclk for BDW has to be not less than 432 M
According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.
Let's apply this work around to GEN9 platforms too, as it fix
== Series Details ==
Series: series starting with [01/12] drm/i915: Split request submit/execute
phase into two
URL : https://patchwork.freedesktop.org/series/14751/
State : success
== Summary ==
Series 14751v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/14751
== Series Details ==
Series: drm/i915/sw_fence: Allocate callbacks from dedicates slab caches
URL : https://patchwork.freedesktop.org/series/14750/
State : success
== Summary ==
Series 14750v1 drm/i915/sw_fence: Allocate callbacks from dedicates slab caches
https://patchwork.freedesktop.org/ap
On Wed, Nov 02, 2016 at 05:44:07PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Not sure if it matters for performance at all but it should
> save some wastage and enable a better insight into the usage.
With the caveat of avoiding the plug into the i915.ko...
This should wait until
Now that the tree has caught up, we can now look at the next steps
towards a basic scheduler. No timeslicing, no preemption, no fairness,
we simply choose the highest priority request to execute next. (An
incoming high priority request will bump the priority on its
prerequisites so that it will exe
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via
Defer the transfer from the client's timeline onto the execution
timeline from the point of readiness to the point of actual submission.
For example, in execlists, a request is finally submitted to hardware
when the hardware is ready, and only put onto the hardware queue when
the request is ready.
Track the priority of each request and use it to determine the order in
which we submit requests to the hardware via execlists.
The priority of the request is determined by the user (eventually via
the context) but may be overridden at any time by the driver. When we set
the priority of the reques
The start of the scheduler, add a hook into request submission for the
scheduler to see the arrival of new requests and prepare its runqueues.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_gem_request.c | 13 +
drivers/gp
In order to support deferred scheduling, we need to differentiate
between when the request is ready to run (i.e. the submit fence is
signaled) and when the request is actually run (a new execute fence).
This is typically split between the request itself wanting to wait upon
others (for which we use
Userspace is faced with a dilemma. The kernel requires implicit fencing
to manage resource usage (we always must wait for the GPU to finish
before releasing its PTE) and for third parties. However, userspace may
wish to avoid this serialisation if it is either using explicit fencing
between parties
Now that the user can opt-out of implicit fencing, we need to give them
back control over the fencing. We employ sync_file to wrap our
drm_i915_gem_request and provide an fd that userspace can merge with
other sync_file fds and pass back to the kernel to wait upon before
future execution.
Testcase
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up
Use i915_gem_object_pin_map() for the guc client's lifetime to replace
the peristent kmap + frequent kmap_atomic with a permanent vmapping.
This avoids taking the obj->mm.lock mutex whilst inside irq context
later.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 38 +
The scheduler needs to know the dependencies of each request for the
lifetime of the request, as it may choose to reschedule the requests at
any time and must ensure the dependency tree is not broken. This is in
additional to using the fence to only allow execution after all
dependencies have been
Boost the priority of any rendering required to show the next pageflip
as we want to avoid missing the vblank by being delayed by invisible
workload. We prioritise avoiding jank and jitter in the GUI over
starving background tasks.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h
The execlist_lock is now completely subsumed by the engine->timeline->lock,
and so we can remove the redundant layer of locking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/intel_engine_c
== Series Details ==
Series: drm/i915/sw_fence: Replace private use of wq->flags with bit zero in
wq->private
URL : https://patchwork.freedesktop.org/series/14745/
State : success
== Summary ==
Series 14745v1 drm/i915/sw_fence: Replace private use of wq->flags with bit
zero in wq->private
ht
From: Tvrtko Ursulin
Not sure if it matters for performance at all but it should
save some wastage and enable a better insight into the usage.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_sw_fence.c | 67 +++
On Wed, Nov 02, 2016 at 05:00:28PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use of an un-allocated bit in flags is making me nervous so I
> thought to use the bit zero of the private pointer instead.
>
> That should be safer against the core kernel changes and safe
> since I can't
From: Tvrtko Ursulin
Use of an un-allocated bit in flags is making me nervous so I
thought to use the bit zero of the private pointer instead.
That should be safer against the core kernel changes and safe
since I can't imagine we can get a fence at the odd address.
Signed-off-by: Tvrtko Ursulin
Regards
Shashank
On 11/2/2016 10:27 PM, Ville Syrjälä wrote:
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.
Our existing CEA modedb contai
== Series Details ==
Series: drm/i915: Tidy slab cache allocations (rev2)
URL : https://patchwork.freedesktop.org/series/14731/
State : warning
== Summary ==
Series 14731v2 drm/i915: Tidy slab cache allocations
https://patchwork.freedesktop.org/api/1.0/series/14731/revisions/2/mbox/
Test drv_
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to p
Regards
Shashank
On 11/2/2016 10:04 PM, Ville Syrjälä wrote:
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.
Our existing CEA modedb contai
On Wed, Nov 02, 2016 at 09:57:12PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/2/2016 9:50 PM, Ville Syrjälä wrote:
> > On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/2/2016 9:32 PM, Ville Syrjälä wrote
On Wed, Nov 02, 2016 at 03:16:10PM +0530, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to p
> -Original Message-
> From: Shashank Sharma [mailto:shashank.sha...@intel.com]
> Sent: Wednesday, November 02, 2016 5:46 AM
> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: airl...@redhat.com; daniel.vet...@intel.com;
> jose.ab...@synopsys.com; Shashank Sharma;
Regards
Shashank
On 11/2/2016 9:50 PM, Ville Syrjälä wrote:
On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 11/2/2016 7:5
On Wed, Nov 02, 2016 at 09:39:48PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
> > On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/2/2016 7:58 PM, Andrzej Hajda wrote
Regards
Shashank
On 11/2/2016 9:32 PM, Ville Syrjälä wrote:
On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
On 02.11.2016 10:46, Shashank Sharma wrote:
CEA-861-F specs defines new 4k video modes to be used with
On Wed, Nov 02, 2016 at 08:14:22PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
> > On 02.11.2016 10:46, Shashank Sharma wrote:
> >> CEA-861-F specs defines new 4k video modes to be used with
> >> HDMI 2.0 EDIDs. These modes start at VIC=
On Wed, Nov 2, 2016 at 2:03 AM, Patrik Jakobsson
wrote:
> On Tue, Nov 1, 2016 at 4:40 PM, Jani Nikula wrote:
>> If we define drm_compat_ioctl NULL on CONFIG_COMPAT=n, we don't have to
>> check for the config everywhere.
>>
>> Signed-off-by: Jani Nikula
>
> Looks good and I like the idea.
>
> Rev
On ke, 2016-11-02 at 15:14 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We can use the preferred KMEM_CACHE helper for brevity.
>
> Also simplifiy error unwind by only setting the ENOMEM
> error code once.
>
> v2: Add forgotten changes. (Joonas Lahtinen)
>
> Signed-off-by: Tvrtko Ur
Regards
Shashank
On 11/2/2016 8:44 PM, Andrzej Hajda wrote:
On 02.11.2016 15:44, Sharma, Shashank wrote:
Regards
Shashank
On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
On 02.11.2016 10:46, Shashank Sharma wrote:
CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. Thes
From: Tvrtko Ursulin
We can use the preferred KMEM_CACHE helper for brevity.
Also simplifiy error unwind by only setting the ENOMEM
error code once.
v2: Add forgotten changes. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen (v1)
Cc: Joonas Lahtinen
---
drivers/
On 02.11.2016 15:44, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
>> On 02.11.2016 10:46, Shashank Sharma wrote:
>>> CEA-861-F specs defines new 4k video modes to be used with
>>> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
>>> way t
On ke, 2016-11-02 at 13:25 +, Chris Wilson wrote:
> On Wed, Nov 02, 2016 at 02:55:36PM +0200, Joonas Lahtinen wrote:
> >
> > Move has_64bit_reloc into dev_priv->info.
>
> ... so that it is shown in the feature list for debugging
Ok, I'll add more detail.
> > @@ -288,7 +288,8 @@ static const
On ke, 2016-11-02 at 14:07 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> We can use the preferred KMEM_CACHE helper for brevity.
>
> Also simplifiy error unwind by only setting the ENOMEM
> error code once.
You did not do this part in this patch.
>
> Signed-off-by: Tvrtko Ursulin
== Series Details ==
Series: drm/i915: Tidy slab cache allocations
URL : https://patchwork.freedesktop.org/series/14731/
State : success
== Summary ==
Series 14731v1 drm/i915: Tidy slab cache allocations
https://patchwork.freedesktop.org/api/1.0/series/14731/revisions/1/mbox/
Test kms_flip:
Regards
Shashank
On 11/2/2016 7:58 PM, Andrzej Hajda wrote:
On 02.11.2016 10:46, Shashank Sharma wrote:
CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.
Our existing CEA modedb contains only 64 modes (VIC=
On 02.11.2016 10:46, Shashank Sharma wrote:
> CEA-861-F specs defines new 4k video modes to be used with
> HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
> way till VIC=107.
>
> Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
> to be able to parse 4k modes using th
From: Tvrtko Ursulin
We can use the preferred KMEM_CACHE helper for brevity.
Also simplifiy error unwind by only setting the ENOMEM
error code once.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
On to, 2016-10-27 at 01:03 +0100, Chris Wilson wrote:
> When looking at freezes whilst working on execlists, knowing the order
> of the pending requests in the driver is useful.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
I think this can be merged already.
Regards, Joonas
--
On Wed, Nov 02, 2016 at 02:55:36PM +0200, Joonas Lahtinen wrote:
> Move has_64bit_reloc into dev_priv->info.
... so that it is shown in the feature list for debugging
>
> v2:
> - Keep the struct member to keep GCC fragile but happy (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Joonas Lahtinen
== Series Details ==
Series: drm/i915: Introduce HAS_64BIT_RELOC (rev2)
URL : https://patchwork.freedesktop.org/series/14730/
State : success
== Summary ==
Series 14730v2 drm/i915: Introduce HAS_64BIT_RELOC
https://patchwork.freedesktop.org/api/1.0/series/14730/revisions/2/mbox/
Test gem_ctx_
On ke, 2016-11-02 at 11:58 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Unify global_list into global_link
> URL : https://patchwork.freedesktop.org/series/14722/
> State : warning
>
> == Summary ==
>
> Series 14722v1 drm/i915: Unify global_list into global_link
> https
Move has_64bit_reloc into dev_priv->info.
v2:
- Keep the struct member to keep GCC fragile but happy (Chris)
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 ++-
drivers/gpu/drm/i915/i915
On Wed, Nov 02, 2016 at 02:32:54PM +0200, Joonas Lahtinen wrote:
> Unify {use,has}_64bit_reloc into dev_priv->info.
>
> Cc: Chris Wilson
> Signed-off-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++-
>
Unify {use,has}_64bit_reloc into dev_priv->info.
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +++-
drivers/gpu/drm/i915/i915_gem_render_state.c | 3 +--
drivers/gpu/drm/i915/i915_p
== Series Details ==
Series: drm/i915: Unify global_list into global_link
URL : https://patchwork.freedesktop.org/series/14722/
State : warning
== Summary ==
Series 14722v1 drm/i915: Unify global_list into global_link
https://patchwork.freedesktop.org/api/1.0/series/14722/revisions/1/mbox/
Te
== Series Details ==
Series: drm/i915: Fix pages pin counting around swizzle quirk
URL : https://patchwork.freedesktop.org/series/14720/
State : success
== Summary ==
Series 14720v1 drm/i915: Fix pages pin counting around swizzle quirk
https://patchwork.freedesktop.org/api/1.0/series/14720/rev
On Wed, Nov 02, 2016 at 12:16:04PM +0200, Joonas Lahtinen wrote:
> $ sed -i -r 's/\bglobal_list\b/global_link/g' *.c *.h
>
> Cc: Chris Wilson
> Signed-off-by: Joonas Lahtinen
Ok, I keep trying to find a better name than global_*, but it falls into
the "when we fix the shrinker" category.
Revie
The failure has nothing to do with the patch, seems irrelevant.
Regards
Shashank
-Original Message-
From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
Sent: Wednesday, November 2, 2016 3:48 PM
To: Sharma, Shashank
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: warning
== Series Details ==
Series: drm: Complete CEA modedb(VIC 1-107) (rev3)
URL : https://patchwork.freedesktop.org/series/14090/
State : warning
== Summary ==
Series 14090v3 drm: Complete CEA modedb(VIC 1-107)
https://patchwork.freedesktop.org/api/1.0/series/14090/revisions/3/mbox/
Test gem_mmap
$ sed -i -r 's/\bglobal_list\b/global_link/g' *.c *.h
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 12 ++--
drivers/gpu/drm/i915/
commit bc0629a76726 ("drm/i915: Track pages pinned due to swizzling
quirk") fixed one problem, but revealed a whole lot more. The root cause
of the pin count mismatch for the swizzle quirk (for L-shaped memory on
gen3/4) was that we were incrementing the pages_pin_count upon getting
the backing pag
This is a testcase with multiple planes. The idea here is the following
- draw a uniform frame with blue color
- grab crc for reference
- put planes randomly on top with the same blue color
- punch holes with black color into the primary framebuffer
- ideally the planes should cover these hol
CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (
On ti, 2016-11-01 at 15:27 +0200, Mika Kuoppala wrote:
> Comparing pte index to a number of entries is wrong
> when clearing a range of pte entries. Use end marker
> of 'one past' to correctly point adequate number of
> ptes to the scratch page.
>
> v2: assert early instead of warning late (Chris)
On 02/11/2016 08:37, Chris Wilson wrote:
On Wed, Nov 02, 2016 at 08:33:56AM +, Tvrtko Ursulin wrote:
On 01/11/2016 16:41, Chris Wilson wrote:
On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote:
Merged to dinq, thanks for the review!
Almost as bad as me in forgetting to add
On Wed, Nov 02, 2016 at 08:33:56AM +, Tvrtko Ursulin wrote:
>
> On 01/11/2016 16:41, Chris Wilson wrote:
> >On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote:
> >>
> >>Merged to dinq, thanks for the review!
> >
> >Almost as bad as me in forgetting to add the r-b. dim save us! :)
>
On 01/11/2016 16:41, Chris Wilson wrote:
On Tue, Nov 01, 2016 at 04:36:34PM +, Tvrtko Ursulin wrote:
Merged to dinq, thanks for the review!
Almost as bad as me in forgetting to add the r-b. dim save us! :)
Took me some time to figure out what is bad in this case. :)
For the reference
Op 01-11-16 om 14:41 schreef Ville Syrjälä:
> On Tue, Nov 01, 2016 at 02:34:00PM +0100, Maarten Lankhorst wrote:
>> Op 01-11-16 om 14:09 schreef Ville Syrjälä:
>>> On Mon, Oct 17, 2016 at 02:37:00PM +0200, Maarten Lankhorst wrote:
Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterato
== Series Details ==
Series: drm/i915/gvt: Fix workload status after wait (rev2)
URL : https://patchwork.freedesktop.org/series/14711/
State : failure
== Summary ==
Series 14711v2 drm/i915/gvt: Fix workload status after wait
https://patchwork.freedesktop.org/api/1.0/series/14711/revisions/2/mb
On Wed, 2016-11-02 at 07:24 +, Saarinen, Jani wrote:
> >
> > == Series Details ==
> >
> > Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init
> > sequence (rev2)
> > URL : https://patchwork.freedesktop.org/series/14669/
> > State : warning
> >
> > == Summary ==
> >
> > Se
> == Series Details ==
>
> Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init
> sequence (rev2)
> URL : https://patchwork.freedesktop.org/series/14669/
> State : warning
>
> == Summary ==
>
> Series 14669v2 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy
> init sequen
== Series Details ==
Series: drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init sequence
(rev2)
URL : https://patchwork.freedesktop.org/series/14669/
State : warning
== Summary ==
Series 14669v2 drm/i915/bxt: Don't set OCL2_LDOFUSE_PWR_DIS bit in phy init
sequence
https://patchwork
On 2016.11.02 08:47:52 +0200, Joonas Lahtinen wrote:
> On ke, 2016-11-02 at 13:41 +0800, Zhenyu Wang wrote:
> > From commit e95433c73a11759203af1cae5958f998c9673370, workload status
> > setting
> > was changed to only capture on error path, but we need to set it properly in
> > normal path too, ot
> == Series Details ==
>
> Series: drm/i915/gvt: Fix workload status after wait
> URL : https://patchwork.freedesktop.org/series/14711/
> State : failure
>
> == Summary ==
>
> Series 14711v1 drm/i915/gvt: Fix workload status after wait
> https://patchwork.freedesktop.org/api/1.0/series/14711/r
From commit e95433c73a11759203af1cae5958f998c9673370, workload status setting
was changed to only capture on error path, but we need to set it properly in
normal path too, otherwise we'll fail to complete workload which could lead
guest VM vGPU reset.
v2: uses braces and add Fixes tag.
Fixes: e95
75 matches
Mail list logo
