== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5358_full -> Patchwork_11177_full
Summary
--
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev3)
URL : https://patchwork.freedesktop.org/series/54030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5358 -> Patchwork_11177
Summary
---
**WAR
== Series Details ==
Series: MST refcounting/atomic helpers cleanup (rev3)
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 (rev3)
URL : https://patchwork.freedesktop.org/series/54030/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
220fc69cfc1d drm/dp_mst: Rename drm_dp_mst_get_validated_(port|mstb)_ref and
friends
-:84: CHECK:OPEN_
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
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:
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
Hi!
> > > So if you could please try drm-tip reproducing AND open a bug in Bugzilla.
> > > If you are unwilling to do that, it is very difficult to help you
> > > more.
> >
> > Website says I have to read and agree to two different pieces of
> > legalesee, and I'd need to keep track of yet anothe
On Wed, 2019-01-02 at 09:09 -0800, Souza, Jose wrote:
> On Tue, 2018-12-11 at 18:54 +, Souza, Jose wrote:
> > On Tue, 2018-12-11 at 10:32 -0800, Dhinakaran Pandiyan wrote:
> > > On Tue, 2018-12-11 at 04:44 -0800, Souza, Jose wrote:
> > > > On Mon, 2018-12-10 at 22:51 -0800, Dhinakaran Pandiyan
== Series Details ==
Series: drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR
URL : https://patchwork.freedesktop.org/series/54655/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5358_full -> Patchwork_11176_full
==
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.
> Is there any better idea for fixing this issue?
I've already back ported this change into the kernel 4.18.17 and sent
it to our customer f
drm-misc-next-fixes-2019-01-02:
Fixes for v4.21:
- Fix null pointer dereference on null state pointer.
- Fix leaking damage clip when destroying plane state.
The following changes since commit 2e6e902d185027f8e3cb8b7305238f7e35d6a436:
Linux 4.20-rc4 (2018-11-25 14:19:31 -0800)
are available in
On Tue, 2018-12-11 at 18:54 +, Souza, Jose wrote:
> On Tue, 2018-12-11 at 10:32 -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2018-12-11 at 04:44 -0800, Souza, Jose wrote:
> > > On Mon, 2018-12-10 at 22:51 -0800, Dhinakaran Pandiyan wrote:
> > > > On Tue, 2018-12-04 at 15:00 -0800, José Roberto
== Series Details ==
Series: drm/i915/gen6: Flush RING_IMR changes before changing the global GT IMR
URL : https://patchwork.freedesktop.org/series/54655/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5358 -> Patchwork_11176
On Baytail, notably, we can still detect missed interrupt syndrome
(where we never spot a completed request). In this case, it can be
alleviated by always keeping the interrupt unmasked, implying that the
interrupt is being lost in the window after modifying the IMR. (This is
the reason we still ha
On 02/01/2019 09:41, Chris Wilson wrote:
Some commit text please.
References: d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 39
drivers/gpu/drm/i915/intel_engine_cs.c |
On 02/01/2019 09:41, Chris Wilson wrote:
Move the debug pretty printer into a standalone routine prior to
extending it in upcoming feature work.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 55 ++--
drivers/gpu/drm/i915/intel_lrc.c | 58
On 02/01/2019 09:41, Chris Wilson wrote:
Remove the struct_mutex requirement for looking up the vma for an
object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
drivers/gpu/drm/i915/i915_gem.c | 33 +++--
drivers/gpu/drm/i915/i915_gem
On 02/01/2019 09:41, Chris Wilson wrote:
Commit text to explain why please.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 12 ++---
drivers/gpu/drm/i915/i915_gem_gtt.c | 27 ++--
== Series Details ==
Series: drm/i915/selftests: Take a breath during check_partial_mappings()
URL : https://patchwork.freedesktop.org/series/54639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5357_full -> Patchwork_11174_full
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-01-02 13:19:52)
>> Chris Wilson writes:
>>
>> > When we first introduced the reset to sanitize the GPU on taking over
>> > from the BIOS and before returning control to third parties (the BIOS!),
>> > we restricted it to only systems utilizing
Quoting Tvrtko Ursulin (2019-01-02 13:13:23)
>
> On 02/01/2019 09:41, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > b/drivers/gpu/drm/i915/i915_gem_gtt.h
> > index a0039ea97cdc..bd679c8c56dd 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> > +++ b/drivers/gpu/
Quoting Mika Kuoppala (2019-01-02 13:19:52)
> Chris Wilson writes:
>
> > When we first introduced the reset to sanitize the GPU on taking over
> > from the BIOS and before returning control to third parties (the BIOS!),
> > we restricted it to only systems utilizing HW contexts as we were
> > unc
Quoting Tvrtko Ursulin (2019-01-02 13:21:17)
>
> On 02/01/2019 09:41, Chris Wilson wrote:
>
> Give it a bit of commit text please.
A starting point to counter the pervasive struct_mutex. For the goal of
avoiding (or at least blocking under them!) global locks during user
request subm
Chris Wilson writes:
> When we first introduced the reset to sanitize the GPU on taking over
> from the BIOS and before returning control to third parties (the BIOS!),
> we restricted it to only systems utilizing HW contexts as we were
> uncertain of how stable our reset mechanism truly was. We n
On 02/01/2019 09:41, Chris Wilson wrote:
Give it a bit of commit text please.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
drivers/gpu/drm/i915/i915_gem_evict.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15
On 02/01/2019 09:41, Chris Wilson wrote:
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a
Chris Wilson writes:
> Ensure that the hangcheck notices the hanging batch by using a
> non-preemptible spin batch, as some future versions of hangcheck may
> allow a preemptible GPU hog to survive.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> tests/i915/gem_busy.c | 5
== Series Details ==
Series: drm/i915/selftests: Take a breath during check_partial_mappings()
URL : https://patchwork.freedesktop.org/series/54639/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5357 -> Patchwork_11174
Summ
== Series Details ==
Series: series starting with [01/39] drm: Reorder set_property_atomic to avoid
returning with an active ww_ctx
URL : https://patchwork.freedesktop.org/series/54636/
State : failure
== Summary ==
Applying: drm: Reorder set_property_atomic to avoid returning with an active
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c |
Currently Ironlake operates under the assumption that rpm awake (and its
error checking is disabled). As such, we have missed a few places where we
access registers without taking the rpm wakeref and thus trigger
warnings. intel_ips being one culprit.
As this involved adding a potentially sleeping
Currently the code to reset the GPU and our state is spread widely
across a few files. Pull the logic together into a common file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile |3 +-
drivers/gpu/drm/i915/i915_debugfs.c |2 +
drivers/gpu/drm/i915
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 12 ++---
drivers/gpu/drm/i915/i915_gem_gtt.c | 27 ++-
drivers/gpu/drm/i915/i915_gem_gtt.h | 10 +--
drivers/gpu/drm
With kasan on a slow machine, it can take an age to check all the
partial mappings in a single iteration, so break it up with a
cond_resched) to avoid RCU stall reports.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 1 +
1 file cha
On Wed, 02 Jan 2019, Tvrtko Ursulin wrote:
> On 02/01/2019 09:13, Jani Nikula wrote:
>> On Tue, 01 Jan 2019, Chris Wilson wrote:
>>> Quoting Jani Nikula (2018-12-31 14:56:40)
The mkwrite_device_info removal series [1] seems to have stalled. I'm
trying to nudge things forward a bit with
Quoting Mika Kuoppala (2019-01-02 11:07:31)
> Chris Wilson writes:
>
> > With kasan on a slow machine, it can take an age to check all the
> > partial mappings in a single iteration, so break it up with a
> > cond_resched) to avoid RCU stall reports.
> >
> > Signed-off-by: Chris Wilson
> > ---
>
On 02/01/2019 10:44, Jani Nikula wrote:
On Wed, 02 Jan 2019, Tvrtko Ursulin wrote:
On 31/12/2018 14:56, Jani Nikula wrote:
Encourage use of INTEL_INFO() to access dev_priv->info to not accumulate
more direct users of ->info, making further changes easier.
Cc: Tvrtko Ursulin
Signed-off-by: J
On 02/01/2019 10:42, Jani Nikula wrote:
On Wed, 02 Jan 2019, Tvrtko Ursulin wrote:
On 31/12/2018 14:56, Jani Nikula wrote:
The debugfs, error state and regular dmesg logging dump needs seem to be
different. Remove the generic dump function only used for the welcome
message. This may be added
Chris Wilson writes:
> With kasan on a slow machine, it can take an age to check all the
> partial mappings in a single iteration, so break it up with a
> cond_resched) to avoid RCU stall reports.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_object.c | 1 +
>
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving c
Now that the submission backends are controlled via their own spinlocks,
with a wave of a magic wand we can lift the struct_mutex requirement
around GPU reset. That is we allow the submission frontend (userspace)
to keep on submitting while we process the GPU reset as we can suspend
the backend ind
We have two classes of VM, global GTT and per-process GTT. In order to
allow ourselves the freedom to mix both along call chains, distinguish
the two classes with regards to their mutex and lockdep maps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +-
d
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
drivers/gpu/drm/i915/i915_gem_evict.c | 2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 15 +--
drivers/gpu/drm/i915/i915_gem_shrinker.c| 4
drivers/gp
On Wed, 02 Jan 2019, Tvrtko Ursulin wrote:
> On 31/12/2018 14:56, Jani Nikula wrote:
>> Encourage use of INTEL_INFO() to access dev_priv->info to not accumulate
>> more direct users of ->info, making further changes easier.
>>
>> Cc: Tvrtko Ursulin
>> Signed-off-by: Jani Nikula
>> ---
>> driv
On Wed, 02 Jan 2019, Tvrtko Ursulin wrote:
> On 31/12/2018 14:56, Jani Nikula wrote:
>> The debugfs, error state and regular dmesg logging dump needs seem to be
>> different. Remove the generic dump function only used for the welcome
>> message. This may be added back later when better abstraction
On Wed, 02 Jan 2019, Tvrtko Ursulin wrote:
> On 31/12/2018 14:56, Jani Nikula wrote:
>> @@ -2198,10 +2199,11 @@ intel_info(const struct drm_i915_private *dev_priv)
>> }
>>
>> #define INTEL_INFO(dev_priv) intel_info((dev_priv))
>> +#define RUNTIME_INFO(dev_priv) (&(dev_priv)->__ru
On 02/01/2019 09:13, Jani Nikula wrote:
On Tue, 01 Jan 2019, Chris Wilson wrote:
Quoting Jani Nikula (2018-12-31 14:56:40)
The mkwrite_device_info removal series [1] seems to have stalled. I'm
trying to nudge things forward a bit with this series. This isn't near
as complete as Tvrtko's work,
Op 28-12-2018 om 11:10 schreef Jani Nikula:
> On Mon, 17 Dec 2018, Maarten Lankhorst
> wrote:
>> Restore our saved values for backlight. This way even with fastset on
>> S4 resume we will correctly restore the backlight to the active values.
> I think this is a non-trivial commit that requires mo
On 31/12/2018 14:56, Jani Nikula wrote:
Encourage use of INTEL_INFO() to access dev_priv->info to not accumulate
more direct users of ->info, making further changes easier.
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 10 ++
1 file changed, 2
On 31/12/2018 14:56, Jani Nikula wrote:
The debugfs, error state and regular dmesg logging dump needs seem to be
different. Remove the generic dump function only used for the welcome
message. This may be added back later when better abstractions are
identified, but at the moment this seems to be
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
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 context idr, with the result that
We want to exclude any GGTT objects from being present on our internal
lists to avoid the deadlock we may run into with our requirement for
struct_mutex during invalidate. However, if the gup_fast fails, we put
the userptr onto the workqueue and mark it as active, so that we
remember to serialise t
As the GT_IRQ power domain implies a wakeref, we can use it inplace of
our existing redundant rpm grab.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 11 ---
drivers/gpu/drm/i915/intel_lrc.c
Hi Sean, Maarten & Maxime -
I embarked on removing drmP.h includes from i915, but that requires a
bunch of drm header cleanup to add relevant includes and forward
declarations. Due to the timing, propagating the patches back to i915
would take eons, so Daniel suggested a topic branch to be merged
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has advanced
Currently, the list of timelines is serialised by the struct_mutex, but
to alleviate difficulties with using that mutex in future, move the
list management under its own dedicated mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i9
Previously we only accommodated having a vma pinned by a small number of
users, with the maximum being pinned for use by the display engine. As
such, we used a small bitfield only large enough to allow the vma to
be pinned twice (for back/front buffers) in each scanout plane. Keeping
the maximum pe
Remove the struct_mutex requirement for looking up the vma for an
object.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
drivers/gpu/drm/i915/i915_gem.c | 33 +++--
drivers/gpu/drm/i915/i915_gem_object.h| 45 ++---
drivers/gp
Move the debug pretty printer into a standalone routine prior to
extending it in upcoming feature work.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 55 ++--
drivers/gpu/drm/i915/intel_lrc.c | 58 ++
drivers/gpu/drm/i9
References: d4ccceb05591 ("drm/i915/icl: Ringbuffer interrupt handling")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 39
drivers/gpu/drm/i915/intel_engine_cs.c | 11 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
drivers/g
Allocate a page for use as a status page by a group of timelines, as we
only need a dword of storage for each (rounded up to the cacheline for
safety) we can pack multiple timelines into the same page. Each timeline
will then be able to track its own HW seqno.
Signed-off-by: Chris Wilson
---
dri
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 25 ---
On 31/12/2018 14:56, Jani Nikula wrote:
Hide the way device info is stored, in preparation of making device info
a pointer to the const rodata in i915_pci.c. No functional changes.
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/dr
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 I use
> "iommu_intel=igfx_off".
>
> With Debian stable backport kernels, "linux-
Make i915_gem_set_wedged() and i915_gem_unset_wedged() behaviour more
consistently if called concurrently.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 32 ++-
drivers/gpu/drm/i915/i915_gpu_error.h | 4 ++-
.../gpu/dr
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by: Chri
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
To correctly simulate preemption between contexts, we need independent
timelines along each context. Make it so.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 90 ++--
1 file changed, 47 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm
Since commit 93065ac753e4 ("mm, oom: distinguish blockable mode for mmu
notifiers") we have been able to report failure from
mmu_invalidate_range_start which allows us to use a trylock on the
struct_mutex to avoid potential recursion and report -EBUSY instead.
Furthermore, this allows us to pull th
On Wed, 02 Jan 2019, Laurent Pinchart wrote:
> Hi Jani,
>
> On Wednesday, 2 January 2019 09:47:58 EET Jani Nikula wrote:
>> On Fri, 28 Dec 2018, Jani Nikula wrote:
>> > Thanks for all the reviews, pushed patches 1-5 to topic/drmp-cleanup
>> > with $(git merge-base drm-misc-next drm-intel-next-que
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 | 231 +---
1 file changed, 121 insertions(+), 110 deleti
With kasan on a slow machine, it can take an age to check all the
partial mappings in a single iteration, so break it up with a
cond_resched) to avoid RCU stall reports.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_gem_object.c | 1 +
1 file changed, 1 insertion(+)
diff -
Our goal is to remove struct_mutex and replace it with fine grained
locking. One of the thorny issues is our eviction logic for reclaiming
space for an execbuffer (or GTT mmaping, among a few other examples).
While eviction itself is easy to move under a per-VM mutex, performing
the activity tracki
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
Ignore trying to shrink from i915 if we fail to acquire the struct_mutex
in the shrinker while performing direct-reclaim. The trade-off being
(much) lower latency for non-i915 clients at an increased risk of being
unable to obtain a page from direct-reclaim without hitting the
oom-notifier. The pro
When we first introduced the reset to sanitize the GPU on taking over
from the BIOS and before returning control to third parties (the BIOS!),
we restricted it to only systems utilizing HW contexts as we were
uncertain of how stable our reset mechanism truly was. We now have
reasonable coverage acr
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
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
The evict selftests presumed that all objects in use had been allocated
by itself. This is a dubious claim and so instead of asserting complete
control over the object lists, take (temporary) ownership of them
instead.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/i915_gem_evict.c
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/
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without
Delay the drm_modeset_acquire_init() until after we check for an
allocation failure so that we can return immediately upon error without
having to unwind.
WARNING: lock held when returning to user space!
4.20.0+ #174 Not tainted
syz-executor556/8153
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need to
1 - 100 of 107 matches
Mail list logo
