Hi,
Left fixes for all W=1 warnings, I think better to send
to catch up last train for 4.19, mostly kernel doc comments
fixes with a trivial refactor.
Thanks
--
The following changes since commit 279ce5d117078ee8ea40c40199399889981fd808:
drm/i915/gvt: declare gvt as i915's soft dependency
On Mon, Jul 16, 2018 at 04:12:49PM -0700, Andrew Morton wrote:
> On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > There are several blockable mmu notifiers which might sleep in
> > mmu_notifier_invalidate_range_start and that is a problem for the
> >
Hi Ramalingam,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.18-rc4 next-20180713]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
I would be glad if someone helps/bothers to review the change :C
Thanks,
Dmitry
On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote:
> Currently ratelimit_state is protected with spin_lock. If the .lock
> is
> taken at the moment of ___ratelimit() call, the message is suppressed
> to
> make
>> I think the bug is with this infinite loop which is at the mercy of an
>> external device
>> and in my case I have this MST hub which appears to be DP 1.2 that triggers
>> the
>> infinite loop case. We have to limit the number of iterations and
>> DP 1.4 spec happened to fix this issue. I'm
Em Qui, 2018-06-28 às 15:35 -0700, Manasi Navare escreveu:
> This sequence is used to setup voltage swing before enabling MG PHY
> DDI
> as well as for changing the voltage during DisplayPort Link training.
>
> For ICL, there are two types of DDIs. This sequence needs to be used
> for MG PHY DDI
On Mon, Jul 16, 2018 at 04:23:23PM -0700, Nathan Ciobanu wrote:
> On Mon, Jul 16, 2018 at 03:34:58PM -0700, Rodrigo Vivi wrote:
> > On Mon, Jul 16, 2018 at 11:14:45AM -0700, Nathan Ciobanu wrote:
> > > Limit the link training clock recovery loop to 10 failed attempts at
> > > LANEx_CR_DONE per DP
On Mon, Jul 16, 2018 at 04:27:47PM -0700, Nathan Ciobanu wrote:
> On Mon, Jul 16, 2018 at 03:30:49PM -0700, Rodrigo Vivi wrote:
> > On Mon, Jul 16, 2018 at 12:22:13PM -0700, Marc Herbert wrote:
> > >
> > > While the shortness of v3 is really nice, I think it's rather a good
> > > opportunity to
On Mon, Jul 16, 2018 at 03:30:49PM -0700, Rodrigo Vivi wrote:
> On Mon, Jul 16, 2018 at 12:22:13PM -0700, Marc Herbert wrote:
> >
> > While the shortness of v3 is really nice, I think it's rather a good
> > opportunity to make much clearer (as a separate, no functional change
> > patch?) its
On Mon, Jul 16, 2018 at 03:34:58PM -0700, Rodrigo Vivi wrote:
> On Mon, Jul 16, 2018 at 11:14:45AM -0700, Nathan Ciobanu wrote:
> > Limit the link training clock recovery loop to 10 failed attempts at
> > LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2.
>
> Thanks... so this made me look to DP
On Mon, Jul 16, 2018 at 04:05:52PM -0700, Paulo Zanoni wrote:
> Em Seg, 2018-07-16 às 15:47 -0700, Rodrigo Vivi escreveu:
> > On Fri, Jul 13, 2018 at 03:57:45PM -0700, Paulo Zanoni wrote:
> > > Em Sex, 2018-07-13 às 14:08 -0700, Rodrigo Vivi escreveu:
> > > > On Wed, Jul 11, 2018 at 02:59:02PM
On Mon, Jul 16, 2018 at 03:04:01PM -0700, Paulo Zanoni wrote:
> Em Qui, 2018-07-12 às 23:14 -0700, Rodrigo Vivi escreveu:
> > On Wed, Jul 11, 2018 at 02:59:04PM -0700, Paulo Zanoni wrote:
> > > The type is detected based on the interrupt ISR bit. Once detected,
> > > it's not supposed to be
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
Em Seg, 2018-07-16 às 15:47 -0700, Rodrigo Vivi escreveu:
> On Fri, Jul 13, 2018 at 03:57:45PM -0700, Paulo Zanoni wrote:
> > Em Sex, 2018-07-13 às 14:08 -0700, Rodrigo Vivi escreveu:
> > > On Wed, Jul 11, 2018 at 02:59:02PM -0700, Paulo Zanoni wrote:
> > > > Use the hardcoded tables provided by
On Fri, Jul 13, 2018 at 03:57:45PM -0700, Paulo Zanoni wrote:
> Em Sex, 2018-07-13 às 14:08 -0700, Rodrigo Vivi escreveu:
> > On Wed, Jul 11, 2018 at 02:59:02PM -0700, Paulo Zanoni wrote:
> > > Use the hardcoded tables provided by our spec.
> > >
> > > v2:
> > > - SSC stays disabled.
> > > -
This 'if's will always be false because of previous changes.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 12 +++-
drivers/gpu/drm/i915/intel_audio.c | 3 ---
drivers/gpu/drm/i915/intel_display.c | 3 ---
drivers/gpu/drm/i915/intel_i2c.c | 3
No need to run i915_load_modeset_init() when num_pipes == 0 also
kms depends on things initialized in i915_load_modeset_init() so not
initializing it too. fbdev and audio have guards against
num_pipes == 0 but lets move it to the if block to make it explicit
to readers.
Also as planes, CRTCs,
num_pipes is set to 0 if disable_display is set inside
intel_device_info_runtime_init() but when that happen PCH will
already be set in intel_detect_pch().
i915_driver_load()
i915_driver_init_early()
...
intel_detect_pch()
...
...
i915_load_modeset_init() is a more suitable place than
i915_driver_load() as vblank is part of modeset API.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git
i915_load_modeset_init() and intel_modeset_cleanup() was initializing
and cleaning up things that is not modeset only.
This will make easy initialize drive without display part.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.c | 56 ++--
GPU accelerators usually don't have display block or the display
driver part can be disable when building driver(for servers it save
some resources) so it is important let userspace check this
capability too.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_ioctl.c | 3 +++
On Mon, Jul 16, 2018 at 11:14:45AM -0700, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 failed attempts at
> LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2.
Thanks... so this made me look to DP 1.3 and DP 1.4 differences here.
Are we already addressing all new
On Mon, Jul 16, 2018 at 12:22:13PM -0700, Marc Herbert wrote:
>
> While the shortness of v3 is really nice, I think it's rather a good
> opportunity to make much clearer (as a separate, no functional change
> patch?) its existing terminating condition(s) and what the existing loop
> iterates on.
== Series Details ==
Series: series starting with [v3] drm/i915/execlists: Always clear preempt
status on cancelling all (rev3)
URL : https://patchwork.freedesktop.org/series/46597/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4495_full -> Patchwork_9677_full =
==
Em Qui, 2018-07-12 às 23:14 -0700, Rodrigo Vivi escreveu:
> On Wed, Jul 11, 2018 at 02:59:04PM -0700, Paulo Zanoni wrote:
> > The type is detected based on the interrupt ISR bit. Once detected,
> > it's not supposed to be changed, so we have some sanity checks for
> > that.
> >
> > Cc: Animesh
Em Sex, 2018-07-13 às 12:43 -0700, Manasi Navare escreveu:
> This patch adds the remaining register definitions and bit fields
> required for MG PHy DDI buffer initializations and voltage
> swing programming for MG PHy DDI ports.
>
> While at it this patch also fixes the naming for previously
On Mon, 16 Jul 2018 19:50:48 +0200,
Takashi Iwai wrote:
>
> On Mon, 16 Jul 2018 19:22:17 +0200,
> Rodrigo Vivi wrote:
> >
> > > --- /dev/null
> > > +++ b/include/drm/drm_audio_component.h
> > > @@ -0,0 +1,115 @@
> > > +/*
> > > + * Copyright © 2014 Intel Corporation
> > > + *
> > > + *
On Mon, 16 Jul 2018 15:48:15 +0200,
Takashi Iwai wrote:
>
> +static int hdac_component_master_bind(struct device *dev)
> +{
> + struct drm_audio_component *acomp = hdac_get_acomp(dev);
> + int ret;
> +
> + ret = component_bind_all(dev, acomp);
> + if (ret < 0)
> +
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev6)
URL : https://patchwork.freedesktop.org/series/40747/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4493_full -> Patchwork_9676_full =
== Summary - FAILURE ==
Serious unknown
While the shortness of v3 is really nice, I think it's rather a good
opportunity to make much clearer (as a separate, no functional change
patch?) its existing terminating condition(s) and what the existing loop
iterates on. I mean it's painful and risky enough to _combine multiple
counters in
On 7/16/2018 1:49 AM, Tvrtko Ursulin wrote:
From: John Harrison
Improve the timeline legend to show actual context colours.
v2: (Tvrtko Ursulin)
* Commit msg.
* Tweak layout for more compactness and more readability.
v3:
* Limit number of shown contexts in the legend. (John Harrison)
== Series Details ==
Series: Make the audio component binding more generic
URL : https://patchwork.freedesktop.org/series/46603/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4499 -> Patchwork_9679 =
== Summary - FAILURE ==
Serious unknown changes coming with
== Series Details ==
Series: drm/i915/selftests: Exercise reset to break stuck GTT eviction (rev2)
URL : https://patchwork.freedesktop.org/series/46593/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4499 -> Patchwork_9678 =
== Summary - FAILURE ==
Serious unknown
== Series Details ==
Series: drm/i915/selftests: Remove redundant code
URL : https://patchwork.freedesktop.org/series/46599/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4493_full -> Patchwork_9675_full =
== Summary - FAILURE ==
Serious unknown changes coming with
Limit the link training clock recovery loop to 10 failed attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2. Some USB-C MST hubs
cause us to get stuck in this loop indefinitely requesting
voltage swing: 0, pre-emphasis level: 2
voltage swing: 1, pre-emphasis level: 2
voltage
On 7/13/2018 3:02 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
vis library has a limited precision compared to our trace data which
prevents zooming into the timeline and seeing the fine detail.
Scale the HTML view by a thousand to work around it.
v2: Rebase for time axis changes.
v3:
== Series Details ==
Series: drm/i915/selftests: Exercise reset to break stuck GTT eviction (rev2)
URL : https://patchwork.freedesktop.org/series/46593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6c8f1c3ed3ce drm/i915/selftests: Exercise reset to break stuck GTT eviction
On 7/13/2018 2:55 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It is possible to customize the axis display so change it to display
timestamps in seconds on the major axis (with six decimal spaces) and
millisecond offsets on the minor axis.
v2:
* Give up on broken relative timestamps.
On Mon, 16 Jul 2018 19:22:17 +0200,
Rodrigo Vivi wrote:
>
> > --- /dev/null
> > +++ b/include/drm/drm_audio_component.h
> > @@ -0,0 +1,115 @@
> > +/*
> > + * Copyright © 2014 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> > + * copy of
On 07/13/2018 10:29 AM, Chris Wilson wrote:
As we try to blit into the buffer to check CPU<->GPU snooping, we have
to check we have a functional GPU first.
Signed-off-by: Chris Wilson
---
tests/gem_pwrite_snooped.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Mon, Jul 16, 2018 at 03:48:13PM +0200, Takashi Iwai wrote:
> For allowing other drivers to use the DRM audio component, rename the
> i915_audio_component_* with drm_audio_component_*, and split the
> generic part into drm_audio_component.h. The i915 specific stuff
> remains in struct
== Series Details ==
Series: series starting with [v3] drm/i915/execlists: Always clear preempt
status on cancelling all (rev3)
URL : https://patchwork.freedesktop.org/series/46597/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4495 -> Patchwork_9677 =
== Summary -
== Series Details ==
Series: series starting with [v3] drm/i915/execlists: Always clear preempt
status on cancelling all (rev3)
URL : https://patchwork.freedesktop.org/series/46597/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f5a7b007b612 drm/i915/execlists: Always clear
== Series Details ==
Series: series starting with [RESEND,1/6] drm/i915/selftests: Force a
preemption hang
URL : https://patchwork.freedesktop.org/series/46569/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4492_full -> Patchwork_9667_full =
== Summary - WARNING ==
On 07/16/2018 01:11 AM, Andy Shevchenko wrote:
> On Fri, 2018-07-13 at 16:42 -0700, Randy Dunlap wrote:
>> On 07/13/2018 04:37 PM, NeilBrown wrote:
>
>>
>> coding-style.rst says:
>> Also, use braces when a loop contains more than a single simple
>> statement:
>
> Independently on a) would we use
On Wed, Jul 11 2018, Andrew Morton wrote:
> On Wed, 11 Jul 2018 13:51:08 +0200 Daniel Vetter wrote:
>
>> But I still have the situation that a bunch of maintainers acked this
>> and Andrew Morton defacto nacked it, which I guess means I'll keep the
>> macro in drm? The common way to go about
This was always a placeholder for GVT stakeholders to provide some
better tests. 2 years later and none have been put forward so stop
wasting CI's time running a placeholder.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106989
Signed-off-by: Chris Wilson
Cc: Zhi Wang
---
As we try to blit into the buffer to check CPU<->GPU snooping, we have
to check we have a functional GPU first.
Signed-off-by: Chris Wilson
---
tests/gem_pwrite_snooped.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/gem_pwrite_snooped.c b/tests/gem_pwrite_snooped.c
index
== Series Details ==
Series: series starting with [RESEND,1/6] drm/i915/selftests: Force a
preemption hang
URL : https://patchwork.freedesktop.org/series/46571/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4492_full -> Patchwork_9666_full =
== Summary - WARNING ==
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev6)
URL : https://patchwork.freedesktop.org/series/40747/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4493 -> Patchwork_9676 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev6)
URL : https://patchwork.freedesktop.org/series/40747/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Add IOCTL Param to control data port coherency.
== Series Details ==
Series: drm/i915/gen11: Preempt-to-idle support in execlists. (rev6)
URL : https://patchwork.freedesktop.org/series/40747/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
26cf0c5fcc46 drm/i915: Add IOCTL Param to control data port coherency.
-:15:
== Series Details ==
Series: drm/i915/selftests: Remove redundant code
URL : https://patchwork.freedesktop.org/series/46599/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4493 -> Patchwork_9675 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9675
Hi,
thanks for the review.
On 7/12/2018 4:38 PM, Laurent Pinchart wrote:
Hi Mahesh,
Thank you for the patches.
When resubmitting patch series, could you please add a version number to the
[PATCH] prefix ? Otherwise it gets difficult to figure out which version is
the latest. This can be
== Series Details ==
Series: drm/i915/execlists: Always clear preempt status on cancelling all (rev7)
URL : https://patchwork.freedesktop.org/series/46528/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4493 -> Patchwork_9674 =
== Summary - FAILURE ==
Serious unknown
For allowing other drivers to use the DRM audio component, rename the
i915_audio_component_* with drm_audio_component_*, and split the
generic part into drm_audio_component.h. The i915 specific stuff
remains in struct i915_audio_component, which contains
drm_audio_component as the base.
This is
Hi,
this is a preliminiary patch set to convert the existing i915 /
HD-audio component binding to be applicable to other drivers like
radeon / amdgpu. This patchset itself doesn't change the
functionality but only renames and split to a new drm_audio_component
stuff from i915_audio_component.
This is the final step for more generic support of DRM audio
component. The generic audio component code is now moved to its own
file, and the symbols are renamed from snd_hac_i915_* to
snd_hdac_acomp_*, respectively. The generic code is enabled via the
new kconfig, CONFIG_SND_HDA_COMPONENT,
The HD-audio i915 binding code contains a single pointer, hdac_acomp,
for allowing the access to audio component from the master bind/unbind
callbacks. This was needed because the callbacks pass only the device
pointer and we can't guarantee the object type assigned to the drvdata
(which is free
On 16/07/2018 14:40, Chris Wilson wrote:
We must be able to reset the GPU while we are waiting on it to perform
an eviction (unbinding an active vma). So attach a spinning request to a
target vma and try and it evict it from a thread to see if that blocks
indefinitely.
v2: Add a wait for the
== Series Details ==
Series: series starting with [v3] drm/i915/execlists: Always clear preempt
status on cancelling all (rev2)
URL : https://patchwork.freedesktop.org/series/46597/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4493 -> Patchwork_9673 =
== Summary -
We must be able to reset the GPU while we are waiting on it to perform
an eviction (unbinding an active vma). So attach a spinning request to a
target vma and try and it evict it from a thread to see if that blocks
indefinitely.
v2: Add a wait for the thread to start just in case that takes more
On 16/07/2018 14:07, Tomasz Lis wrote:
The patch adds a parameter to control the data port coherency functionality
on a per-context level. When the IOCTL is called, a command to switch data
port coherency state is added to the ordered list. All prior requests are
executed on old coherency
Inject a failure into preemption completion to pretend as if the HW
didn't successfully handle preemption and we are forced to do a reset in
the middle.
v2: Wait for preemption, to force testing with the missed preemption.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko
On 16/07/18 15:10, Ville Syrjälä wrote:
> On Sat, Jul 14, 2018 at 02:50:28PM +0200, Hans Verkuil wrote:
>> On 11/07/18 17:24, Ville Syrjälä wrote:
>>> On Wed, Jul 11, 2018 at 04:09:03PM +0200, Hans Verkuil wrote:
Hi Ville,
On 11/07/18 15:41, Patchwork wrote:
> == Series Details
== Series Details ==
Series: series starting with [v3] drm/i915/execlists: Always clear preempt
status on cancelling all (rev2)
URL : https://patchwork.freedesktop.org/series/46597/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7a09e4391067 drm/i915/execlists: Always clear
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Always clear preempt
status on cancelling all
URL : https://patchwork.freedesktop.org/series/46597/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4493 -> Patchwork_9672 =
== Summary - FAILURE ==
On Sat, Jul 14, 2018 at 02:50:28PM +0200, Hans Verkuil wrote:
> On 11/07/18 17:24, Ville Syrjälä wrote:
> > On Wed, Jul 11, 2018 at 04:09:03PM +0200, Hans Verkuil wrote:
> >> Hi Ville,
> >>
> >> On 11/07/18 15:41, Patchwork wrote:
> >>> == Series Details ==
> >>>
> >>> Series: drm/i915: add
The patch adds a parameter to control the data port coherency functionality
on a per-context level. When the IOCTL is called, a command to switch data
port coherency state is added to the ordered list. All prior requests are
executed on old coherency settings, and all exec requests after the IOCTL
err is assigned to -EIO, but this value is never actually
used and *err* is updated later on.
Remove such reduntant code.
Addresses-Coverity-ID: 1471816 ("Unused value")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/selftests/intel_guc.c | 1 -
1 file changed, 1 deletion(-)
diff
Quoting Chris Wilson (2018-07-16 13:56:46)
> On reset/wedging, we cancel all pending replies from the HW and we also
> want to cancel an outstanding preemption event. Since we use the same
> function to cancel the pending replies for reset and for a preemption
> event, we can simply clear the
On 16/07/2018 13:56, Chris Wilson wrote:
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active
Quoting Tvrtko Ursulin (2018-07-16 13:55:55)
>
> On 16/07/2018 13:54, Chris Wilson wrote:
> > On reset/wedging, we cancel all pending replies from the HW and we also
> > want to cancel an outstanding preemption event. Since we use the same
> > function to cancel the pending replies for reset and
On 16/07/2018 13:48, Chris Wilson wrote:
Inject a failure into preemption completion to pretend as if the HW
didn't successfully handle preemption and we are forced to do a reset in
the middle.
v2: Wait for preemption, to force testing with the missed preemption.
Signed-off-by: Chris Wilson
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active tracking for all.
v2: Keep execlists_user_end()
On 16/07/2018 13:54, Chris Wilson wrote:
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active tracking for all.
v2: Keep execlists_user_end()
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Always clear preempt
status on cancelling all
URL : https://patchwork.freedesktop.org/series/46597/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3c43096cb418 drm/i915/execlists: Always clear preempt
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active tracking for all.
v2: Keep execlists_user_end()
Inject a failure into preemption completion to pretend as if the HW
didn't successfully handle preemption and we are forced to do a reset in
the middle.
v2: Wait for preemption, to force testing with the missed preemption.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
Quoting Gustavo A. R. Silva (2018-07-16 13:39:33)
> err is assigned to -EIO, but this value is never actually
> used and *err* is updated later on.
>
> Remove such reduntant code.
The mistake is that err is lost, possible masking the test failure.
Looks like the unwind needs to be refactored?
>-Original Message-
>From: Alexandru-Cosmin Gheorghe [mailto:Alexandru-
>cosmin.gheor...@arm.com]
>Sent: Thursday, July 12, 2018 10:02 PM
>To: Shankar, Uma
>Cc: dcasta...@chromium.org; intel-gfx@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-de...@lists.freedesktop.org; Syrjala,
== Series Details ==
Series: drm/i915/selftests: Downgrade igt_timeout message
URL : https://patchwork.freedesktop.org/series/46554/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4489_full -> Patchwork_9664_full =
== Summary - WARNING ==
Minor unknown changes coming
== Series Details ==
Series: drm/i915/selftests: Exercise reset to break stuck GTT eviction
URL : https://patchwork.freedesktop.org/series/46593/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4493 -> Patchwork_9670 =
== Summary - FAILURE ==
Serious unknown changes
== Series Details ==
Series: mm, oom: distinguish blockable mode for mmu notifiers (rev7)
URL : https://patchwork.freedesktop.org/series/45263/
State : failure
== Summary ==
Applying: mm, oom: distinguish blockable mode for mmu notifiers
Using index info to reconstruct a base tree...
M
== Series Details ==
Series: drm/i915/selftests: Exercise reset to break stuck GTT eviction
URL : https://patchwork.freedesktop.org/series/46593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b5b59b84a80b drm/i915/selftests: Exercise reset to break stuck GTT eviction
-:142:
From: Michal Hocko
There are several blockable mmu notifiers which might sleep in
mmu_notifier_invalidate_range_start and that is a problem for the
oom_reaper because it needs to guarantee a forward progress so it cannot
depend on any sleepable locks.
Currently we simply back off and mark an
== Series Details ==
Series: drm/i915/guc: Disable rpm wakeref asserts in GuC irq handler (rev2)
URL : https://patchwork.freedesktop.org/series/46551/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4489_full -> Patchwork_9663_full =
== Summary - WARNING ==
Minor unknown
We must be able to reset the GPU while we are waiting on it to perform
an eviction (unbinding an active vma). So attach a spinning request to a
target vma and try and it evict it from a thread to see if that blocks
indefinitely.
v2: Add a wait for the thread to start just in case that takes more
== Series Details ==
Series: drm/i915/execlists: Always clear preempt status on cancelling all (rev6)
URL : https://patchwork.freedesktop.org/series/46528/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4493 -> Patchwork_9669 =
== Summary - FAILURE ==
Serious unknown
Quoting Chris Wilson (2018-07-16 11:47:27)
> On reset/wedging, we cancel all pending replies from the HW and we also
> want to cancel an outstanding preemption event. Since we use the same
> function to cancel the pending replies for reset and for a preemption
> event, we can simply clear the
== Series Details ==
Series: drm/i915: Differentiate between ggtt->mutex and ppgtt->mutex
URL : https://patchwork.freedesktop.org/series/46547/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4489_full -> Patchwork_9662_full =
== Summary - WARNING ==
Minor unknown changes
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active tracking for all.
v2: Keep execlists_user_end()
Quoting Michal Wajdeczko (2018-07-16 11:32:22)
> On Mon, 16 Jul 2018 10:03:31 +0200, Chris Wilson
> wrote:
>
> > On an aborted module load, we unwind and free our device private - but
> > we left a dangling pointer to our privates inside the pci_device. After
> > the attempted aborted unload,
On Mon, 16 Jul 2018 10:03:31 +0200, Chris Wilson
wrote:
On an aborted module load, we unwind and free our device private - but
we left a dangling pointer to our privates inside the pci_device. After
the attempted aborted unload, we may still get a call to
i915_pci_remove()
when the module
== Series Details ==
Series: drm/i915/execlists: Disable submission tasklet upon wedging (rev2)
URL : https://patchwork.freedesktop.org/series/46542/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4489_full -> Patchwork_9661_full =
== Summary - WARNING ==
Minor unknown
On 16/07/2018 09:03, Chris Wilson wrote:
Give in, since CI continues to incorrectly insist that KERN_NOTICE is a
warning and flags the timeout message as unwanted spam. At first, the
intention was to use the message to indicate which tests might warrant
an extended run, but virtually all tests
On 16/07/2018 09:03, Chris Wilson wrote:
On an aborted module load, we unwind and free our device private - but
we left a dangling pointer to our privates inside the pci_device. After
the attempted aborted unload, we may still get a call to i915_pci_remove()
when the module is removed,
On 16/07/2018 09:03, Chris Wilson wrote:
If we declare the driver wedged before the GPU truly is, then we may see
the GPU complete some CS events following our cancellation. This leaves
us quite confused as we deleted all the bookkeeping and thus complain
about the inconsistent state.
We can
On 16/07/2018 09:03, Chris Wilson wrote:
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active
1 - 100 of 129 matches
Mail list logo
