On Tue, Aug 07, 2018 at 07:36:47PM +0100, Chris Wilson wrote:
> Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), the core provides the no-op functions when map and
> map_atomic are not provided, so we no longer need assert that are
> supplied by a dma-buf
== 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/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 c
== 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 r
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 ++-
drivers/gpu/drm/i
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 chec
== 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.
External
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 an
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, w
== 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.
==
== 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:
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 ++
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
> ---
> drivers/gpu/drm/i915/i915_debugfs
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 m
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().
> >
> > i915_driver_l
== 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 regress
== 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 regress
== 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 found
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
> > > intel_display_po
== 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 conte
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: last(18:211174
== 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 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 : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4639_full -> Patchwork_9911_full =
== Summary
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: last(18:211174
== 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 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 : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4639 -> Patchwork_9911 =
== Summary - SUCCESS
== 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 thr
== 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 ru
== 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.
Ex
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: last(18:211174
== 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 unk
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 remotel
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 objec
== 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 - pe
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 trac
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 re
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
oper
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] rq(18:211173)
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
== 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 unk
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 debugf
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 +++
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 mea
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:
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 = obj->s
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 reservation_object_
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.
Signed-off-b
== 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 unk
== 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 recon
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 re
== 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 ==
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 ++-
drivers/gpu/drm/amd/
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
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 +-
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 ++--
drivers/gpu/
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 -
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
b/drivers/gpu/drm/i915/intel_display
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 previou
== 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 between
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 wa
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 1)
== 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 regre
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 ("drm/i915/sel
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
> > t
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 a
== 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 intel_engine_
== 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 inte
== 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 regre
== 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 intel_engine_
== 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 inte
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 (fu
== 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 - FA
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 intel_engine_notify_
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 (fu
== 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 intel_runtime_pm_dis
== 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 intel_runti
== 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 regre
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 ->
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 +1,
== 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 intel_engine_
== 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 inte
== 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 unknown
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 @@
> +// SPDX-License-Identi
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
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 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 callback
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 (fu
== 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 unk
== 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 issu
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.
>>
>>
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
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 vgem_fenc
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 to
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 checki
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.
>
>
== 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 unk
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()
> ...
>
== 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:
https://pa
98 matches
Mail list logo
