== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev2)
URL : https://patchwork.freedesktop.org/series/47680/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9899 =
== Summary - FAILURE ==
Serious
== Series Details ==
Series: drm/i915/selftests: Hold rpm for unparking
URL : https://patchwork.freedesktop.org/series/47930/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4636_full -> Patchwork_9897_full =
== Summary - SUCCESS ==
No regressions found.
== Known
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
---
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
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev2)
URL : https://patchwork.freedesktop.org/series/47897/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/tracing: Enable user interrupts while
On 09/08/2018 10:22, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-08-09 10:07:51)
diff --git a/drivers/gpu/drm/i915/i915_tracing.h
b/drivers/gpu/drm/i915/i915_tracing.h
new file mode 100644
index ..4d8710f5687b
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_tracing.h
@@ -0,0
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev2)
URL : https://patchwork.freedesktop.org/series/47897/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9901 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable
to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/47934/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Introduce
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev3)
URL : https://patchwork.freedesktop.org/series/47897/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/tracing: Enable user interrupts while
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev3)
URL : https://patchwork.freedesktop.org/series/47897/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9903 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev4)
URL : https://patchwork.freedesktop.org/series/47897/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9904 =
== Summary - SUCCESS ==
No
Quoting Daniel Vetter (2018-08-09 09:33:49)
> On Wed, Jul 04, 2018 at 11:29:08AM +0200, Daniel Vetter wrote:
> > static void vgem_fence_release(struct dma_fence *base)
> > {
> > struct vgem_fence *fence = container_of(base, typeof(*fence), base);
> > @@ -76,11 +66,7 @@ static void
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
Op 09-08-18 om 01:44 schreef Dhinakaran Pandiyan:
> On Wed, 2018-08-08 at 16:19 +0200, Maarten Lankhorst wrote:
>> 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.
>>
>>
From: Tvrtko Ursulin
Keep the user interrupt enabled and emit intel_engine_notify tracepoint
every time as long as it is enabled. Premise is that if someone is
listening, they want to see interrupts logged.
We use tracepoint (de)registration callbacks to enable user interrupts on
all devices
From: Tvrtko Ursulin
Keep the user interrupt enabled and emit intel_engine_notify tracepoint
every time as long as it is enabled. Premise is that if someone is
listening, they want to see interrupts logged.
We use tracepoint (de)registration callbacks to enable user interrupts on
all devices
== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev2)
URL : https://patchwork.freedesktop.org/series/47680/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9898 =
== Summary - FAILURE ==
Serious
== Series Details ==
Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable
to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/47934/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1787a18142d6 drm/i915: Introduce
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev4)
URL : https://patchwork.freedesktop.org/series/47897/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915/tracing: Enable user interrupts while
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev4)
URL : https://patchwork.freedesktop.org/series/47897/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
424835b61710 drm/i915/tracing: Enable user interrupts while
Chris Wilson writes:
> The call to i915_gem_unpark() checks that we hold a rpm wakeref before
> taking a long term wakeref for i915->gt.awake. We should therefore make
> sure we do hold the wakeref when directly calling unpark to disable
> the retire worker.
>
> Fixes: 932cac10c8fb
On Wed, Jul 04, 2018 at 11:29:08AM +0200, Daniel Vetter wrote:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> Also remove the ->signaled callback, vgem can't peek ahead with a
> fastpath, returning false is the default implementation.
>
>
Quoting José Roberto de Souza (2018-08-09 01:15:47)
> GPU accelerators usually don't have display block or the display
> driver part can be disabled when building driver(for servers it saves
> some resources) so it is important let userspace check this
> capability too.
>
> Right now we are
Quoting Tvrtko Ursulin (2018-08-09 10:07:51)
> diff --git a/drivers/gpu/drm/i915/i915_tracing.h
> b/drivers/gpu/drm/i915/i915_tracing.h
> new file mode 100644
> index ..4d8710f5687b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_tracing.h
> @@ -0,0 +1,29 @@
> +//
Quoting Tvrtko Ursulin (2018-08-09 11:01:28)
> +#if IS_ENABLED(CONFIG_TRACEPOINTS)
> +
> +void i915_tracing_register(struct drm_i915_private *i915);
> +void i915_tracing_unregister(struct drm_i915_private *i915);
> +
> +int intel_engine_notify_tracepoint_register(void);
> +void
On Wed, 08 Aug 2018, José Roberto de Souza wrote:
> 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()
> ...
>
Quoting José Roberto de Souza (2018-08-09 01:15:48)
> 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().
One major thing missed is that if you disable the displays via modparam,
you need
On 09/08/2018 10:07, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Keep the user interrupt enabled and emit intel_engine_notify tracepoint
every time as long as it is enabled. Premise is that if someone is
listening, they want to see interrupts logged.
We use tracepoint (de)registration
== Series Details ==
Series: drm/i915: Introduce intel_runtime_pm_disable to pair
intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/47932/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9900 =
== Summary - FAILURE ==
Serious
Quoting Patchwork (2018-08-09 10:25:42)
> == Series Details ==
>
> Series: drm/i915: Introduce intel_runtime_pm_disable to pair
> intel_runtime_pm_enable
> URL : https://patchwork.freedesktop.org/series/47932/
> State : failure
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4636 ->
Chris Wilson writes:
> The call to i915_gem_unpark() checks that we hold a rpm wakeref before
> taking a long term wakeref for i915->gt.awake. We should therefore make
> sure we do hold the wakeref when directly calling unpark to disable
> the retire worker.
We as a caller need to hold the rpm
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev2)
URL : https://patchwork.freedesktop.org/series/47897/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dea5a6eb6bc8 drm/i915/tracing: Enable user interrupts while
== Series Details ==
Series: series starting with [1/2] drm/i915: Introduce intel_runtime_pm_disable
to pair intel_runtime_pm_enable
URL : https://patchwork.freedesktop.org/series/47934/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9902 =
== Summary -
From: Tvrtko Ursulin
Keep the user interrupt enabled and emit intel_engine_notify tracepoint
every time as long as it is enabled. Premise is that if someone is
listening, they want to see interrupts logged.
We use tracepoint (de)registration callbacks to enable user interrupts on
all devices
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev3)
URL : https://patchwork.freedesktop.org/series/47897/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
877808443224 drm/i915/tracing: Enable user interrupts while
Quoting Mika Kuoppala (2018-08-09 11:40:35)
> Chris Wilson writes:
>
> > The call to i915_gem_unpark() checks that we hold a rpm wakeref before
> > taking a long term wakeref for i915->gt.awake. We should therefore make
> > sure we do hold the wakeref when directly calling unpark to disable
> >
On Thu, 09 Aug 2018 00:58:53 +0200, Paulo Zanoni
wrote:
Em Qua, 2018-08-08 às 22:22 +, Patchwork escreveu:
== Series Details ==
Series: series starting with [1/4] drm/i915: kill
intel_display_power_well_is_enabled()
URL : https://patchwork.freedesktop.org/series/47908/
State :
== Series Details ==
Series: drm/i915/selftests: Hold rpm for unparking
URL : https://patchwork.freedesktop.org/series/47930/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9897 =
== Summary - SUCCESS ==
No regressions found.
External URL:
The call to i915_gem_unpark() checks that we hold a rpm wakeref before
taking a long term wakeref for i915->gt.awake. We should therefore make
sure we do hold the wakeref when directly calling unpark to disable
the retire worker.
Fixes: 932cac10c8fb ("drm/i915/selftests: Prevent background
On 08/08/2018 22:08, Chris Wilson wrote:
On suspend, we cancel the automatic forcewake and clear all other sources
of forcewake so the machine can sleep before we do suspend. However, we
expose the forcewake to userspace (only via debugfs, but nevertheless we
do) and want to restore that upon
Quoting Tvrtko Ursulin (2018-08-09 12:46:05)
>
> On 08/08/2018 22:08, Chris Wilson wrote:
> > On suspend, we cancel the automatic forcewake and clear all other sources
> > of forcewake so the machine can sleep before we do suspend. However, we
> > expose the forcewake to userspace (only via
== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev3)
URL : https://patchwork.freedesktop.org/series/47680/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4637 -> Patchwork_9907 =
== Summary - FAILURE ==
Serious
Quoting Chris Wilson (2018-08-09 14:07:01)
> If the request is currently on the HW (in port 0), then we do not need
> to kick the submission tasklet to evaluate whether we should be
> preempting itself in order to execute it again.
So in the case that was annoying me:
[ 70.883173]
Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
Hi everyone,
This set of patches tries to improve read after write hazard handling
for reservation objects.
It allows us to specify for each shared fence if it represents a write
Am 09.08.2018 um 14:08 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 12:37:08)
void reservation_object_add_shared_fence(struct reservation_object *obj,
struct dma_fence *fence)
{
- struct reservation_object_list *old, *fobj =
If the request is currently on the HW (in port 0), then we do not need
to kick the submission tasklet to evaluate whether we should be
preempting itself in order to execute it again.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 32
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
> Hi everyone,
>
> This set of patches tries to improve read after write hazard handling
> for reservation objects.
>
> It allows us to specify for each shared fence if it represents a write
> operation.
>
> Based on this the i915
Quoting Daniel Vetter (2018-08-09 13:45:44)
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> Also remove the ->signaled callback, vgem can't peek ahead with a
> fastpath, returning false is the default implementation.
>
> v2: Protect the
== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev3)
URL : https://patchwork.freedesktop.org/series/47680/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8c821c599a13 drm/i915: Add detection of changing of edid on
== Series Details ==
Series: drm/i915/tracing: Enable user interrupts while intel_engine_notify is
active (rev4)
URL : https://patchwork.freedesktop.org/series/47897/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4636_full -> Patchwork_9904_full =
== Summary - WARNING ==
== Series Details ==
Series: series starting with [1/6] dma-buf: remove shared fence staging in
reservation object
URL : https://patchwork.freedesktop.org/series/47948/
State : failure
== Summary ==
Applying: dma-buf: remove shared fence staging in reservation object
Using index info to
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 iterations,
to try and keep the error in check.
== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev3)
URL : https://patchwork.freedesktop.org/series/47680/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4636 -> Patchwork_9905 =
== Summary - FAILURE ==
Serious
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.
1) plug display device to a connector
2) system suspend
3) unplug
Hi everyone,
This set of patches tries to improve read after write hazard handling for
reservation objects.
It allows us to specify for each shared fence if it represents a write
operation.
Based on this the i915 driver is modified to always wait for all writes before
pageflip and the
No need for that any more. Just replace the list when there isn't enough
room any more for at least one additional fence.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c | 180 ++
include/linux/reservation.h | 4 -
2 files changed, 60
That allows us to only retreive fences of write operations.
Signed-off-by: Christian König
---
drivers/dma-buf/reservation.c| 19 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 3 ++-
We now note that all fences are potential writers.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1
Note if the added fence is a write by using the lsb in the fenc pointer.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c| 8 +++-
drivers/dma-buf/reservation.c| 59 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2
Wait for all write operations before page flipping.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/intel_display.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
Add a helper to access the shared fences in an reservation object.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 3 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
Quoting Christian König (2018-08-09 12:37:08)
> void reservation_object_add_shared_fence(struct reservation_object *obj,
> struct dma_fence *fence)
> {
> - struct reservation_object_list *old, *fobj = obj->staged;
> + struct
dma_fence_default_wait is the default now, same for the trivial
enable_signaling implementation.
Also remove the ->signaled callback, vgem can't peek ahead with a
fastpath, returning false is the default implementation.
v2: Protect the meaningful space! (Chris)
Signed-off-by: Daniel Vetter
Cc:
On Wed, Aug 08, 2018 at 10:08:42PM +0100, Chris Wilson wrote:
> On suspend, we cancel the automatic forcewake and clear all other sources
> of forcewake so the machine can sleep before we do suspend. However, we
> expose the forcewake to userspace (only via debugfs, but nevertheless we
> do) and
On Wed, 2018-08-08 at 16:41 -0700, Rodrigo Vivi wrote:
> On Thu, Jul 26, 2018 at 04:02:53PM +0300, StanLis wrote:
> > From: Stanislav Lisovskiy
> >
> > This was inspired, by a bugs like this:
> >
> > Bugzilla: https://bugs.freedesktop.org/93361
> >
> > In short, when TV advertises 12bpc, the
== Series Details ==
Series: series starting with [v6,1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v6 (rev2)
URL : https://patchwork.freedesktop.org/series/47888/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f12e3f989693 drm/i915: Allow control of PSR at
== Series Details ==
Series: series starting with [v6,1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v6 (rev2)
URL : https://patchwork.freedesktop.org/series/47888/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9911 =
== Summary -
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:
>>>
>>> Hi everyone,
>>>
>>> This set of patches tries to improve read after write hazard handling
>>> for reservation
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]
See to me the explicit fence in the reservation object is not even
== Series Details ==
Series: RESEND: dma-buf cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/45890/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e8a45f5bac39 drm/i915: Remove unecessary dma_fence_ops
-:4: WARNING:TYPO_SPELLING: 'unecessary' may be misspelled -
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
the override through the module parameter, and add some
If the request is currently on the HW (in port 0), then we do not need
to kick the submission tasklet to evaluate whether we should be
preempting itself in order to execute it again.
In the case that was annoying me:
execlists_schedule: rq(18:211173).prio=0 -> 2
need_preempt:
== Series Details ==
Series: drm/i915: Add detection of changing of edid on between suspend and
resume (rev3)
URL : https://patchwork.freedesktop.org/series/47680/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9909 =
== Summary - FAILURE ==
Serious
== Series Details ==
Series: drm/i915/execlists: Avoid kicking priority on the current context
URL : https://patchwork.freedesktop.org/series/47951/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9910 =
== Summary - SUCCESS ==
No regressions found.
== Series Details ==
Series: series starting with [v6,1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v6 (rev2)
URL : https://patchwork.freedesktop.org/series/47888/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Allow control of PSR at runtime
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file
i915_edp_psr_status.
Suggested-by: Dhinakaran Pandiyan
Signed-off-by: Azhar Shaikh
Reviewed-by: Dhinakaran Pandiyan
---
Changes in v2:
- Fix checkpatch warning.
- Add Reviewed-by: from v1
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/47902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639_full -> Patchwork_9915_full =
== Summary - SUCCESS ==
No regressions found.
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. The machine hangs,
== Series Details ==
Series: series starting with [1/2] drm/i915/psr: Print PSR_STATUS when PSR idle
wait times out.
URL : https://patchwork.freedesktop.org/series/47978/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639_full -> Patchwork_9917_full =
== Summary - WARNING
== Series Details ==
Series: drm/i915/execlists: Avoid kicking priority on the current context (rev2)
URL : https://patchwork.freedesktop.org/series/47951/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9912 =
== Summary - SUCCESS ==
No regressions
Em Qui, 2018-08-09 às 08:29 +0200, Michal Wajdeczko escreveu:
> On Thu, 09 Aug 2018 00:58:53 +0200, Paulo Zanoni
> wrote:
>
> > Em Qua, 2018-08-08 às 22:22 +, Patchwork escreveu:
> > > == Series Details ==
> > >
> > > Series: series starting with [1/4] drm/i915: kill
> > >
If the request is currently on the HW (in port 0), then we do not need
to kick the submission tasklet to evaluate whether we should be
preempting itself in order to execute it again.
In the case that was annoying me:
execlists_schedule: rq(18:211173).prio=0 -> 2
need_preempt:
If the request is currently on the HW (in port 0), then we do not need
to kick the submission tasklet to evaluate whether we should be
preempting itself in order to execute it again.
In the case that was annoying me:
execlists_schedule: rq(18:211173).prio=0 -> 2
need_preempt:
== Series Details ==
Series: drm/i915/execlists: Avoid kicking priority on the current context (rev4)
URL : https://patchwork.freedesktop.org/series/47951/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9914 =
== Summary - SUCCESS ==
No regressions
== Series Details ==
Series: series starting with [v6,1/2] drm/i915: Allow control of PSR at runtime
through debugfs, v6 (rev2)
URL : https://patchwork.freedesktop.org/series/47888/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4639_full -> Patchwork_9911_full =
==
== Series Details ==
Series: drm/i915/execlists: Avoid kicking priority on the current context (rev3)
URL : https://patchwork.freedesktop.org/series/47951/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639_full -> Patchwork_9913_full =
== Summary - SUCCESS ==
No
== Series Details ==
Series: drm/i915/execlists: Avoid kicking priority on the current context (rev3)
URL : https://patchwork.freedesktop.org/series/47951/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9913 =
== Summary - SUCCESS ==
No regressions
== Series Details ==
Series: drm/i915/execlists: Avoid kicking priority on the current context (rev4)
URL : https://patchwork.freedesktop.org/series/47951/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6e8f4cfda77f drm/i915/execlists: Avoid kicking priority on the current
== Series Details ==
Series: series starting with [1/2] drm/i915/psr: Print PSR_STATUS when PSR idle
wait times out.
URL : https://patchwork.freedesktop.org/series/47978/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9917 =
== Summary - SUCCESS ==
No
== Series Details ==
Series: drm/i915/psr: Add PSR mode/revision to debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/47902/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9915 =
== Summary - SUCCESS ==
No regressions found.
External URL:
Quoting Paulo Zanoni (2018-08-10 00:58:52)
> 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
Knowing the status of the PSR HW state machine is useful for debug,
especially since we are seeing errors with PSR2 in CI.
Cc: José Roberto de Souza
Cc: Rodrigo Vivi
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_drv.h| 3 ++-
CI runs show PSR2 does not go to IDLE with selective update enabled on
all PSR exit triggers. Specifically, logs indicate the hardware enters
"SLEEP Selective Update" and not "IDLE Reset state' like the kernel
expects. This check was added for PSR1 but incorrectly extended to PSR2,
remove this
== 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_4639_full -> Patchwork_9916_full =
== Summary - WARNING ==
Minor unknown changes
== Series Details ==
Series: drm/i915/execlists: Avoid kicking priority on the current context (rev4)
URL : https://patchwork.freedesktop.org/series/47951/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639_full -> Patchwork_9914_full =
== Summary - SUCCESS ==
No
== 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_4639 -> Patchwork_9916 =
== Summary - SUCCESS ==
No regressions found.
On Thu, 2018-08-09 at 09:36 +0100, Chris Wilson wrote:
> Quoting José Roberto de Souza (2018-08-09 01:15:48)
> > 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().
>
> One major thing
On Thu, 2018-08-09 at 11:16 +0300, Jani Nikula wrote:
> On Wed, 08 Aug 2018, José Roberto de Souza
> wrote:
> > 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().
> >
> >
On Wed, 2018-08-08 at 12:16 -0700, Azhar Shaikh wrote:
> Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file
This is not the revision.
> i915_edp_psr_status.
>
> Suggested-by: Dhinakaran Pandiyan
> Signed-off-by: Azhar Shaikh
> ---
>
99 matches
Mail list logo
