== Series Details ==
Series: drm/i915/ringbuffer: Drop gen7_xcs_emit_breadcrumb
URL : https://patchwork.freedesktop.org/series/54721/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5361_full -> Patchwork_11184_full
Summary
-
== Series Details ==
Series: drm/i915/ringbuffer: Drop gen7_xcs_emit_breadcrumb
URL : https://patchwork.freedesktop.org/series/54721/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5361_full -> Patchwork_11184_full
Summary
-
Quoting Eric Wong (2019-01-04 03:06:26)
> Joonas Lahtinen wrote:
> > Quoting Eric Wong (2018-12-27 13:49:48)
> > > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
> > > chipset) and hit some kernel panics while trying to view
> > > image/animation-intensive stuff in Firefox (X11) unless
Chris Wilson writes:
> If we declare the driver wedged during early initialisation, we leave
> the driver in an undefined state (with respect to GEM execution). As
> this leads to unexpected behaviour if we allow the user to unwedge the
> device (through debugfs, and performed by igt at test star
Chris Wilson writes:
> The additional flushes for gen7 appear to have been a red herring as the
> more efficacious workaround seems to be commit 476af9c26063 ("drm/i915/gen6:
> Flush RING_IMR changes before changing the global GT IMR"). Trusting the
> updated results means we can remove the speci
== Series Details ==
Series: drm/i915/ringbuffer: Drop gen7_xcs_emit_breadcrumb
URL : https://patchwork.freedesktop.org/series/54721/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5361_full -> Patchwork_11184_full
Summary
-
Quoting Mika Kuoppala (2019-01-04 09:36:05)
> Chris Wilson writes:
>
> > The additional flushes for gen7 appear to have been a red herring as the
> > more efficacious workaround seems to be commit 476af9c26063 ("drm/i915/gen6:
> > Flush RING_IMR changes before changing the global GT IMR"). Trusti
From: Tvrtko Ursulin
No functional or code size change - just notice we can compact the source
by re-using a single helper for adding workarounds.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 32 +---
1 file changed, 6 insertions(+), 26 delet
From: Tvrtko Ursulin
Top comment in intel_workarounds.c says common code should come first so
lets respect that. Also, by moving the common code together opportunities
to reduce duplication will become more obvious.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_workarounds.c | 7
== Series Details ==
Series: drm/i915/ringbuffer: Drop gen7_xcs_emit_breadcrumb (rev2)
URL : https://patchwork.freedesktop.org/series/54721/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d50ab641c85a drm/i915/ringbuffer: Drop gen7_xcs_emit_breadcrumb
-:7: WARNING:COMMIT_LOG_LON
Quoting Tvrtko Ursulin (2019-01-04 11:40:53)
> From: Tvrtko Ursulin
>
> No functional or code size change - just notice we can compact the source
> by re-using a single helper for adding workarounds.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_workarounds.c | 32 +-
Quoting Tvrtko Ursulin (2019-01-02 15:21:21)
> > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/intel_engine_cs.c
> > index 36177546f68b..7b80a087cc32 100644
> > --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> > @@ -91
== Series Details ==
Series: drm/i915/ringbuffer: Drop gen7_xcs_emit_breadcrumb (rev2)
URL : https://patchwork.freedesktop.org/series/54721/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11185
Summary
== Series Details ==
Series: series starting with [1/2] drm/i915: Move workaround infrastructure
code up
URL : https://patchwork.freedesktop.org/series/54739/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11186
===
On 04/01/2019 12:01, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-04 11:40:53)
From: Tvrtko Ursulin
No functional or code size change - just notice we can compact the source
by re-using a single helper for adding workarounds.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i
== Series Details ==
Series: drm/i915/ringbuffer: Drop gen7_xcs_emit_breadcrumb (rev2)
URL : https://patchwork.freedesktop.org/series/54721/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11185_full
Su
On 04/01/2019 12:13, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-02 15:21:21)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 36177546f68b..7b80a087cc32 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/int
On Fri, 2019-01-04 at 07:53 +0100, Maarten Lankhorst wrote:
> Op 03-01-2019 om 15:21 schreef José Roberto de Souza:
> > intel_psr_set_debugfs_mode() don't just handle the PSR mode but it
> > is
> > also handling input validation, setting the new debug value and
> > changing PSR IRQ masks.
> > Lets
== Series Details ==
Series: series starting with [v2,1/6] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks (rev3)
URL : https://patchwork.freedesktop.org/series/54692/
State : failure
== Summary ==
Applying: drm/i915/psr: Allow PSR2 to be enabled when debugfs asks
Applying: drm/i915:
Chris Wilson writes:
> Include the total size of closed vma when reporting the per_ctx_stats of
> debugfs/i915_gem_objects.
>
> Whilst adjusting the context tracking, note that we can simply use our
> list of contexts in i915->contexts rather than circumlocute via
> dev->filelist and the per-file
From: Tvrtko Ursulin
In two codepaths internal to the shrinker we know we will end up taking
the resursive mutex path.
It instead feels more elegant to avoid this altogether and not call
mutex_trylock_recursive in those cases.
We achieve this by extracting the shrinking part to __i915_gem_shrin
From: Tvrtko Ursulin
The code tries to grab struct mutex for 5ms every time the unlocked GPU
idle wait succeeds. But the GPU idle wait itself is practically unbound
which means the 5ms timeout might not be honoured.
Cap the GPU idle wait to 5ms as well to fix this.
Signed-off-by: Tvrtko Ursulin
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking
from the shrinker
URL : https://patchwork.freedesktop.org/series/54744/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
30228d4da273 drm/i915: Reduce recursive mutex locking from the
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking
from the shrinker
URL : https://patchwork.freedesktop.org/series/54744/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Reduce recursive mutex lo
== Series Details ==
Series: series starting with [1/2] drm/i915: Move workaround infrastructure
code up
URL : https://patchwork.freedesktop.org/series/54739/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11186_full
=
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking
from the shrinker
URL : https://patchwork.freedesktop.org/series/54744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11188
=
Op 04-01-2019 om 14:28 schreef Souza, Jose:
> On Fri, 2019-01-04 at 07:53 +0100, Maarten Lankhorst wrote:
>> Op 03-01-2019 om 15:21 schreef José Roberto de Souza:
>>> intel_psr_set_debugfs_mode() don't just handle the PSR mode but it
>>> is
>>> also handling input validation, setting the new debug
From: Tvrtko Ursulin
In two codepaths internal to the shrinker we know we will end up taking
the resursive mutex path.
It instead feels more elegant to avoid this altogether and not call
mutex_trylock_recursive in those cases.
We achieve this by extracting the shrinking part to __i915_gem_shrin
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Reduce recursive mutex locking
from the shrinker (rev2)
URL : https://patchwork.freedesktop.org/series/54744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11189
===
== Series Details ==
Series: series starting with [1/2] drm/i915: Reduce recursive mutex locking
from the shrinker
URL : https://patchwork.freedesktop.org/series/54744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11188_full
===
From: Tvrtko Ursulin
A set of subtests which exercises different paths to our shrinker code
(including the OOM killer) in predictable and reasonable time budget.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.c| 19 ++
lib/igt_core.h| 1 +
tes
On Fri, 2019-01-04 at 15:35 +0100, Maarten Lankhorst wrote:
> Op 04-01-2019 om 14:28 schreef Souza, Jose:
> > On Fri, 2019-01-04 at 07:53 +0100, Maarten Lankhorst wrote:
> > > Op 03-01-2019 om 15:21 schreef José Roberto de Souza:
> > > > intel_psr_set_debugfs_mode() don't just handle the PSR mode b
On Fri, 4 Jan 2019 12:02:34 +0800
Chris Chiu wrote:
> On Thu, Jan 3, 2019 at 1:50 AM Guang Bai wrote:
> >
> > On Wed, 2 Jan 2019 17:29:46 +0800
> > Chris Chiu wrote:
> >
> > > Happy New Year.
> > > Sorry for bothering you guys again, I don't really want to make
> > > myself a nuisance.
> > >
== Series Details ==
Series: series starting with [v3,1/2] drm/i915: Reduce recursive mutex locking
from the shrinker (rev2)
URL : https://patchwork.freedesktop.org/series/54744/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11189_full
=
According to Workaround database ICL also needs
WaEnablePreemptionGranularityControlByUMD, to allow userspace to do
fine-granularity preemptions per-context.
BSpec: 11348
Cc: Oscar Mateo
Cc: Radhakrishna Sripada
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_workarounds.c
== Series Details ==
Series: drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
URL : https://patchwork.freedesktop.org/series/54751/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11190
Summary
== Series Details ==
Series: drm/i915/icl: Apply WaEnablePreemptionGranularityControlByUMD
URL : https://patchwork.freedesktop.org/series/54751/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11190_full
Quoting Chris Wilson (2018-08-08 11:20:09)
> Some setups (e.g. guc and gen10+) can not disable the MI_USER_INTERRUPT
> generation and so can not simulate missed interrupts. These tests would
> fail, so skip when the kernel reports no tests available.
Ping?
-Chris
__
On Fri, Dec 21, 2018 at 11:56:43AM +, Tvrtko Ursulin wrote:
>
> On 14/12/2018 18:20, Lucas De Marchi wrote:
> > Instead of checking the gen number every time we need to know the max
> > number of entries, just save it into the table struct so we don't need
> > extra branches throughout the cod
This has never actually worked, and isn't needed anyway: the driver's
always going to try to deallocate VCPI when it tears down the display
that the VCPI belongs to.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/d
This is the series I've been working on for a while now to get all of
the atomic DRM drivers in the tree to use the atomic MST helpers, and to
make the atomic MST helpers actually idempotent. Turns out it's a lot
more difficult to do that without also fixing how port and branch device
refcounting w
So that the ports stay around until we've destroyed the connectors, in
order to ensure that we don't pass an invalid pointer to any MST helpers
once we introduce the new MST VCPI helpers.
Changes since v1:
* Move drm_dp_mst_get_port_malloc() to where we assign
intel_connector->port - danvet
Sig
While this isn't a complete fix, this will improve the reliability of
drm_dp_get_last_connected_port_and_mstb() pretty significantly during
hotplug events, since there's a chance that the in-memory topology tree
may not be fully updated when drm_dp_get_last_connected_port_and_mstb()
is called and t
s/drm_dp_get_validated_port_ref/drm_dp_mst_topology_get_port_validated/
s/drm_dp_put_port/drm_dp_mst_topology_put_port/
s/drm_dp_get_validated_mstb_ref/drm_dp_mst_topology_get_mstb_validated/
s/drm_dp_put_mst_branch_device/drm_dp_mst_topology_put_mstb/
This is a much more consistent naming scheme,
The current way of handling refcounting in the DP MST helpers is really
confusing and probably just plain wrong because it's been hacked up many
times over the years without anyone actually going over the code and
seeing if things could be simplified.
To the best of my understanding, the current s
Just like i915 and nouveau, it's a good idea for us to hold a malloc
reference to the port here so that we never pass a freed pointer to any
of the DP MST helper functions.
Also, we stop unsetting aconnector->port in
dm_dp_destroy_mst_connector(). There's literally no point to that
assignment that
Same as we did for i915, but for nouveau this time. Additionally, we
grab a malloc reference to the port that lasts for the entire lifetime
of nv50_mstc, which gives us the guarantee that mstc->port will always
point to valid memory for as long as the mstc stays around.
Signed-off-by: Lyude Paul
Trying to destroy the connector using mstc->connector.funcs->destroy()
if connector initialization fails is wrong: there is no possible
codepath in nv50_mstc_new where nv50_mstm_add_connector() would return
<0 and mstc would be non-NULL.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airl
Up until now, freeing payloads on remote MST hubs that just had ports
removed has almost never worked because we've been relying on port
validation in order to stop us from accessing ports that have already
been freed from memory, but ports which need their payloads released due
to being removed wi
There is no need to look at the port's VCPI allocation before calling
drm_dp_mst_deallocate_vcpi(), as we already have msto->disabled to let
us avoid cleaning up an msto more then once. The DP MST core will never
call drm_dp_mst_deallocate_vcpi() on it's own, which is presumably what
these checks a
Now that we finally have a sane way to keep port allocations around, use
it to fix the potential unchecked ->port accesses that nouveau makes by
making sure we keep the mst port allocated for as long as it's
drm_connector is accessible.
Additionally, now that we've guaranteed that mstc->port is al
Changes since v6:
- Move EXPORT_SYMBOL() for drm_dp_mst_topology_state_funcs to this
commit
- Document __drm_dp_mst_state_iter_get() and note that it shouldn't be
called directly
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc:
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
Going through the currently programmed payloads isn't safe without
holding mgr->payload_lock, so actually do that and warn if anyone tries
calling nv50_msto_payload() in the future without grabbing the right
locks.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc:
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actual
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Reviewed-by: Daniel Vetter
Cc: David Airlie
Cc: Jerry Zuo
Cc: Harry Wentland
Cc: Juston Li
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1 del
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2a2093f380b0 drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and
friends
-:84: CHECK:OPEN_
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and friends
Okay
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11191
Summary
---
**SUC
On Fri, Dec 21, 2018 at 12:29:41PM +, Tvrtko Ursulin wrote:
>
> On 14/12/2018 18:20, Lucas De Marchi wrote:
> > From: Tomasz Lis
> >
> > The table has been unified across OSes to minimize virtualization overhead.
> >
> > The MOCS table is now published as part of bspec, and versioned. Entri
CC [M] drivers/gpu/drm/i915/intel_device_info.o
drivers/gpu/drm/i915/intel_device_info.c:727: warning: Function parameter or
member 'dev_priv' not described in 'intel_device_info_runtime_init'
drivers/gpu/drm/i915/intel_device_info.c:727: warning: Excess function
parameter 'info' description i
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev4)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11191_full
Summary
--
== Series Details ==
Series: drm/i915: Fixup kerneldoc for intel_device_info_runtime_init
URL : https://patchwork.freedesktop.org/series/54767/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11192
Summary
-
From: Michel Thierry
Final enablement patch for GPU hang detection using watchdog timeout.
Using the gem_context_setparam ioctl, users can specify the desired
timeout value in microseconds, and the driver will do the conversion to
'timestamps'.
The recommended default watchdog threshold for vide
This is a rebased on the original patch series from Michel Thierry
that can be found here:
https://patchwork.freedesktop.org/series/21868
Note that this series is only limited to the GPU Watchdog timeout
for execlists as it leaves out support
for GuC based submission for a later time.
The series
Not checking for BSD2 causes a segfault on GPU revs
with no h/w support for the extra media engines.
Segfault on ULX GT2 (0x591e) follows:
Patch shared by Michel Thierry on IIRC.
[ 468.625970] BUG: unable to handle kernel NULL pointer dereference at
02c0
[ 468.625978] IP: gen8_cs_
From: Michel Thierry
XXX: What to do when the watchdog irq fired twice but our hangcheck
logic thinks the engine is not hung? For example, what if the
active-head moved since the irq handler?
One option is to just ignore the watchdog, if the engine is really hung,
then the driver will detect the
From: Michel Thierry
Save the watchdog threshold (in us) as part of the engine state.
v2: Only do it for gen8+ (and prevent a missing-case warn).
v3: use ctx->__engine.
v4: Rebase.
Cc: Antonio Argenziano
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
Signed-off-by: Carlos Santa
---
drive
From: Michel Thierry
*** General ***
Watchdog timeout (or "media engine reset") is a feature that allows
userland applications to enable hang detection on individual batch buffers.
The detection mechanism itself is mostly bound to the hardware and the only
thing that the driver needs to do to su
From: Michel Thierry
Emit the required commands into the ring buffer for starting and
stopping the watchdog timer before/after batch buffer start during
batch buffer submission.
v2: Support watchdog threshold per context engine, merge lri commands,
and move watchdog commands emission to emit_bb_
From: Michel Thierry
On command streams that could potentially hang the GPU after a last
flush command, it's best not to cancel the watchdog
until after all commands have executed.
Patch shared by Michel Thierry through IIRC after reproduction on
my local setup.
Tested-by: Carlos Santa
CC: Ant
From: Michel Thierry
Users/tests relying on the total reset count will start seeing a smaller
number since most of the hangs can be handled by engine reset.
Note that if reset engine x, context a running on engine y will be unaware
and unaffected.
To start the discussion, include just a total en
== Series Details ==
Series: drm/i915: Watchdog timeout: Blindly trust watchdog timeout for reset?
URL : https://patchwork.freedesktop.org/series/54768/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
285c27ee5aed drm/i915: Add engine reset count in get-reset-stats ioctl
-:17: WA
== Series Details ==
Series: drm/i915: Watchdog timeout: Blindly trust watchdog timeout for reset?
URL : https://patchwork.freedesktop.org/series/54768/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363 -> Patchwork_11193
== Series Details ==
Series: drm/i915: Fixup kerneldoc for intel_device_info_runtime_init
URL : https://patchwork.freedesktop.org/series/54767/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11192_full
Hi Michel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.20 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Michel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.20 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Michel,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.20 next-20190103]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
== Series Details ==
Series: drm/i915: Watchdog timeout: Blindly trust watchdog timeout for reset?
URL : https://patchwork.freedesktop.org/series/54768/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5363_full -> Patchwork_11193_full
79 matches
Mail list logo
