Check that we restore runtime pm around debug suspends and hibernates.
v2: Differentiate between external test setup failure and one of
interest
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tests/pm_rpm.c
It doesn't work right now and desperately needs to be fixed...
Signed-off-by: Chris Wilson
---
tests/intel-ci/fast-feedback.testlist | 1 +
tests/pm_rpm.c| 28 ---
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/tests/intel-ci/fast
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
Frequently, we use intel_runtime_pm_get/_put around a small block.
Formalise that usage by providing a macro to define such a block with an
automatic closure to scope the intel_runtime_pm wakeref to that block,
i.e. macro abuse smelling of python.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
Track where and when we acquire and release the power well for pps
access along the dp aux link, with a view to detecting if we leak any
wakerefs.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_dp.c | 226 +---
1 file changed, 117 insertions(+), 109 deleti
Currently, we cancel the extra wakeref we have for !runtime-pm devices
inside power_wells_fini_hw. However, this is not strictly paired with
the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may
be called on errors paths before we even call runtime_pm_enable). Make
the symmetry m
Modesetting is one of the more complex interactions with power wells as
it acquires multiple wells to do its business. Fortunately, we do not
have to track every one individually as they are all called from the
same location and thus will have matching wakerefs (being a hash of its
stacktrace).
Si
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get
As we only release each power well once, we assume that each transcoder
maps to a different domain. Complain if this is not so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/d
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig
On Thu, Aug 09, 2018 at 01:37:09PM +0200, Christian König wrote:
> Add a helper to access the shared fences in an reservation object.
>
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ++-
> drivers/gpu/drm/amd/amdgpu/a
Quoting Christian König (2018-08-09 15:54:31)
> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
> > On Thu, Aug 9, 2018 at 3:58 PM, Christian König
> > wrote:
> >> Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
> >>> On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
> >>> [SNIP]
> >> S
Am 10.08.2018 um 09:51 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 15:54:31)
Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wrote:
Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian Kö
On Thu, Aug 9, 2018 at 4:54 PM, Christian König
wrote:
> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
>>
>> On Thu, Aug 9, 2018 at 3:58 PM, Christian König
>> wrote:
>>>
>>> Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
>
On Fri, Aug 10, 2018 at 10:24 AM, Christian König
wrote:
> Am 10.08.2018 um 09:51 schrieb Chris Wilson:
>>
>> Quoting Christian König (2018-08-09 15:54:31)
>>>
>>> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wrote:
>
> Am 09
Am 10.08.2018 um 10:32 schrieb Daniel Vetter:
On Fri, Aug 10, 2018 at 10:24 AM, Christian König
wrote:
Am 10.08.2018 um 09:51 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 15:54:31)
Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wro
Reloading the module may impact subsequent tests by destabilising the
system. As we do for BAT, if we want to test reloads, it should be
handled explicitly at the end of the run, rather than placed at random
in the middle of the test list.
References: https://bugs.freedesktop.org/show_bug.cgi?id=1
On Fri, Aug 10, 2018 at 10:02:46AM +0100, Chris Wilson wrote:
> Reloading the module may impact subsequent tests by destabilising the
> system. As we do for BAT, if we want to test reloads, it should be
> handled explicitly at the end of the run, rather than placed at random
> in the middle of the
Am 10.08.2018 um 10:29 schrieb Daniel Vetter:
[SNIP]
I'm only interested in the case of shared buffers. And for those you
_do_ pessimistically assume that all access must be implicitly synced.
Iirc amdgpu doesn't support EGL_ANDROID_native_fence_sync, so this
makes sense that you don't bother wit
On Fri, Aug 10, 2018 at 11:14 AM, Christian König
wrote:
> Am 10.08.2018 um 10:29 schrieb Daniel Vetter:
>>
>> [SNIP]
>> I'm only interested in the case of shared buffers. And for those you
>> _do_ pessimistically assume that all access must be implicitly synced.
>> Iirc amdgpu doesn't support EGL
Quoting Petri Latvala (2018-08-10 10:11:29)
> On Fri, Aug 10, 2018 at 10:02:46AM +0100, Chris Wilson wrote:
> > Reloading the module may impact subsequent tests by destabilising the
> > system. As we do for BAT, if we want to test reloads, it should be
> > handled explicitly at the end of the run,
On Fri, Aug 10, 2018 at 10:51 AM, Christian König
wrote:
> Am 10.08.2018 um 10:32 schrieb Daniel Vetter:
>>
>> On Fri, Aug 10, 2018 at 10:24 AM, Christian König
>> wrote:
>>>
>>> Am 10.08.2018 um 09:51 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 15:54:31)
>
> Am 09
On Fri, Aug 10, 2018 at 11:14 AM, Christian König
wrote:
> Am 10.08.2018 um 10:29 schrieb Daniel Vetter:
>>
>> [SNIP]
>> I'm only interested in the case of shared buffers. And for those you
>> _do_ pessimistically assume that all access must be implicitly synced.
>> Iirc amdgpu doesn't support EGL
On Fri, Aug 10, 2018 at 10:21:59AM +0100, Chris Wilson wrote:
> Quoting Petri Latvala (2018-08-10 10:11:29)
> > On Fri, Aug 10, 2018 at 10:02:46AM +0100, Chris Wilson wrote:
> > > Reloading the module may impact subsequent tests by destabilising the
> > > system. As we do for BAT, if we want to tes
The kernel selftests are excluded from the shard lists as those lists
are compiled separately.
Signed-off-by: Chris Wilson
---
tests/intel-ci/blacklist.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/intel-ci/blacklist.txt b/tests/intel-ci/blacklist.txt
index 1d
Reloading the module may impact subsequent tests by destabilising the
system. As we do for BAT, if we want to test reloads, it should be
handled explicitly at the end of the run, rather than placed at random
in the middle of the test list.
v2: Commentary
References: https://bugs.freedesktop.org/s
On Fri, Aug 10, 2018 at 10:41:45AM +0100, Chris Wilson wrote:
> Reloading the module may impact subsequent tests by destabilising the
> system. As we do for BAT, if we want to test reloads, it should be
> handled explicitly at the end of the run, rather than placed at random
> in the middle of the
Quoting Petri Latvala (2018-08-10 10:55:06)
> On Fri, Aug 10, 2018 at 10:41:45AM +0100, Chris Wilson wrote:
> > Reloading the module may impact subsequent tests by destabilising the
> > system. As we do for BAT, if we want to test reloads, it should be
> > handled explicitly at the end of the run,
Normally we wait on the last request, but that overlooks any
difficulties in waiting on a request while the next is being qeued.
Check those.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 72
1 file changed, 72 insertions(+)
diff --git a/tes
More variants on stress waits to serve the dual purpose of investigating
different aspects of the latency (this time while also serving
execlists interrupts) while also checking that we never miss the wakeup.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 142
This exercises a special case that may be of interest, waiting for a
context that may be preempted in order to reduce the wait.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 146 +++
1 file changed, 146 insertions(+)
diff --git a/tests/gem_sync.c
== Series Details ==
Series: series starting with [RFC,1/8] drm/i915: Introduce
intel_runtime_pm_disable to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/47989/
State : failure
== Summary ==
Applying: drm/i915: Introduce intel_runtime_pm_disable to pair
intel_ru
Op 09-08-18 om 16:21 schreef Maarten Lankhorst:
> Currently tests modify i915.enable_psr and then do a modeset cycle
> to change PSR. We can write a value to i915_edp_psr_debug to force
> a certain PSR mode without a modeset.
>
> To retain compatibility with older userspace, we also still allow
> t
== Series Details ==
Series: drm/i915/icl: account for context save/restore removed bits
URL : https://patchwork.freedesktop.org/series/47976/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4643 -> Patchwork_9919 =
== Summary - SUCCESS ==
No regressions found.
External
On Fri, Aug 10, 2018 at 08:11:31AM +0100, Chris Wilson wrote:
> Currently, we cancel the extra wakeref we have for !runtime-pm devices
> inside power_wells_fini_hw. However, this is not strictly paired with
> the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may
> be called on er
Quoting Imre Deak (2018-08-10 13:22:43)
> On Fri, Aug 10, 2018 at 08:11:31AM +0100, Chris Wilson wrote:
> > @@ -1474,6 +1476,8 @@ void i915_driver_unload(struct drm_device *dev)
> > i915_driver_cleanup_mmio(dev_priv);
> >
> > intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
> > +
== Series Details ==
Series: series starting with [RFC,1/8] drm/i915: Introduce
intel_runtime_pm_disable to pair intel_runtime_pm_enable (rev2)
URL : https://patchwork.freedesktop.org/series/47989/
State : failure
== Summary ==
Applying: drm/i915: Introduce intel_runtime_pm_disable to pair
i
On Thu, 2018-08-09 at 14:13 +0300, Gwan-gyeong Mun wrote:
> The hotplug detection routine of i915 uses
> drm_helper_hpd_irq_event(). This
> helper can detect changing of status of connector, but it can not
> detect
> changing of edid.
>
> Following scenario requires detection of changing of edid.
From: Stanislav Lisovskiy
Introduced new XYUV scan-in format for framebuffer and
added support for it to i915 driver.
Stanislav Lisovskiy (2):
drm: Introduce new DRM_FORMAT_XYUV
drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.
drivers/gpu/drm/drm_fourcc.c | 1 +
driv
From: Stanislav Lisovskiy
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
Quoting Tvrtko Ursulin (2018-08-09 12:54:41)
>
> On 08/08/2018 15:59, Chris Wilson wrote:
> > Our observation is that the systematic error is proportional to the
> > number of iterations we perform; the suspicion is that it directly
> > correlates with the number of sleeps. Reduce the number of it
If engine reports that it is not ready for reset, we
give up. Evidence shows that forcing a per engine reset
on an engine which is not reporting to be ready for reset,
can bring it back into a working order. There is risk that
we corrupt the context image currently executing on that
engine. But tha
There is a possibility for per gen reset logic to
be more nasty if the softer approach on resetting does
not bear fruit.
Expose retry count to per gen reset logic if it
wants to take such tough measures.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c | 40
On Fri, Aug 10, 2018 at 01:33:19PM +0100, Chris Wilson wrote:
> Quoting Imre Deak (2018-08-10 13:22:43)
> > On Fri, Aug 10, 2018 at 08:11:31AM +0100, Chris Wilson wrote:
> > > @@ -1474,6 +1476,8 @@ void i915_driver_unload(struct drm_device *dev)
> > > i915_driver_cleanup_mmio(dev_priv);
> > >
Quoting Mika Kuoppala (2018-08-10 15:00:36)
> If engine reports that it is not ready for reset, we
> give up. Evidence shows that forcing a per engine reset
> on an engine which is not reporting to be ready for reset,
> can bring it back into a working order. There is risk that
> we corrupt the con
Quoting Mika Kuoppala (2018-08-10 15:00:35)
> There is a possibility for per gen reset logic to
> be more nasty if the softer approach on resetting does
> not bear fruit.
>
> Expose retry count to per gen reset logic if it
> wants to take such tough measures.
>
> Cc: Chris Wilson
> Signed-off-by
Am 10.08.2018 um 11:21 schrieb Daniel Vetter:
[SNIP]
Then don't track _any_ of the amdgpu internal fences in the reservation object:
- 1 reservation object that you hand to ttm, for use internally within amdgpu
- 1 reservation object that you attach to the dma-buf (or get from the
imported dma-bu
== Series Details ==
Series: series starting with [1/2] drm/i915: Expose retry count to per gen
reset logic
URL : https://patchwork.freedesktop.org/series/48019/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4643 -> Patchwork_9921 =
== Summary - WARNING ==
Minor unknown
== Series Details ==
Series: drm/i915/icl: account for context save/restore removed bits
URL : https://patchwork.freedesktop.org/series/47976/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4643_full -> Patchwork_9919_full =
== Summary - SUCCESS ==
No regressions found.
From: Paulo Zanoni
The RS_CTX_ENABLE and CTX_SAVE_INHIBIT bits are not present on ICL
anymore, but we still try to set them and then check them with
GEM_BUG_ON, resulting in a BUG() call. The bug can be reproduced by
igt/drv_selftest/live_hangcheck/others-priority and our CI was able
to catch it.
== Series Details ==
Series: drm/i915/icl: account for context save/restore removed bits (rev2)
URL : https://patchwork.freedesktop.org/series/47976/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
afe5704847eb drm/i915/icl: account for context save/restore removed bits
-:20: ERR
== Series Details ==
Series: drm/i915/icl: account for context save/restore removed bits (rev2)
URL : https://patchwork.freedesktop.org/series/47976/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4643 -> Patchwork_9922 =
== Summary - SUCCESS ==
No regressions found.
E
On 10/08/18 04:01, Chris Wilson wrote:
Normally we wait on the last request, but that overlooks any
difficulties in waiting on a request while the next is being qeued.
/s/qeued/queued
Check those.
Signed-off-by: Chris Wilson
---
tests/gem_sync.c | 72
Quoting Antonio Argenziano (2018-08-10 18:41:22)
>
>
> On 10/08/18 04:01, Chris Wilson wrote:
> > Normally we wait on the last request, but that overlooks any
> > difficulties in waiting on a request while the next is being qeued.
>
> /s/qeued/queued
>
> > Check those.
> >
> > Signed-off-by: C
Hi Stanislav,
FYI, we are trying to add same format under a slightly different name.
See https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html
On Fri, Aug 10, 2018 at 04:19:03PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> v5: This is YUV444 packed format same as AYUV,
On 10/08/18 10:51, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-08-10 18:41:22)
On 10/08/18 04:01, Chris Wilson wrote:
Normally we wait on the last request, but that overlooks any
difficulties in waiting on a request while the next is being qeued.
/s/qeued/queued
Check those.
S
== Series Details ==
Series: series starting with [1/2] drm/i915: Expose retry count to per gen
reset logic
URL : https://patchwork.freedesktop.org/series/48019/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4643_full -> Patchwork_9921_full =
== Summary - SUCCESS ==
No
== Series Details ==
Series: drm/i915/icl: account for context save/restore removed bits (rev2)
URL : https://patchwork.freedesktop.org/series/47976/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4643_full -> Patchwork_9922_full =
== Summary - WARNING ==
Minor unknown ch
We print the last attempted entry and last exit timestamps only when
IRQ debug is requested. This check was missed when new debug flags were
added in 'commit c44301fce614 ("drm/i915: Allow control of PSR at
runtime through debugfs, v6")
Cc: Maarten Lankhorst
Signed-off-by: Dhinakaran Pandiyan
--
== Series Details ==
Series: drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit
URL : https://patchwork.freedesktop.org/series/48048/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4645 -> Patchwork_9923 =
== Summary - SUCCESS ==
No regressions found.
External
== Series Details ==
Series: drm/i915/psr: Add missing check for I915_PSR_DEBUG_IRQ bit
URL : https://patchwork.freedesktop.org/series/48048/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4645_full -> Patchwork_9923_full =
== Summary - WARNING ==
Minor unknown changes co
62 matches
Mail list logo
