Am Sonntag, 27. Januar 2019, 04:41:26 CET schrieb Stephen Rothwell:
> Hi all,
>
> In commit
>
> 053ff09f1a8f ("drm/rockchip: rgb: update SPDX license identifier")
>
> Fixes tag
>
> Fixes: 1f0f01515172 ("Add support for Rockchip Soc RGB output interface")
looks like I accidentially lost the
Check that we are allowed to hang/reset the GPU before we actually do so
for the first time.
Signed-off-by: Chris Wilson
---
tests/i915/gem_eio.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
index 5250a414c..09059c311 100
Skip trying to stop unused fork helpers to avoid the various asserts
that they were running and didn't die early.
Signed-off-by: Chris Wilson
---
lib/igt_core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 49fbf70de..0794e11a0 100644
--- a/lib/igt_
Check that we are allowed to reset the GPU prior to execution.
Signed-off-by: Chris Wilson
---
tests/i915/gem_workarounds.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_workarounds.c b/tests/i915/gem_workarounds.c
index 78478ad2c..0e9ab2386 100644
--- a
Check the GPU (using GEM) is up an operational before submitting
commands.
Signed-off-by: Chris Wilson
---
tests/pm_rpm.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/pm_rpm.c b/tests/pm_rpm.c
index 7dcb5586d..be296f525 100644
--- a/tests/pm_rpm.c
+++ b/tests/pm_rpm.c
@@ -1220,6
On 01/22, Shayenne Moura wrote:
> This patch adds one test to evaluate suspend/resume operations using kms_flip.
>
> Signed-off-by: Shayenne Moura
>
> v2: Reduce test time to 10 (Daniel)
> ---
> tests/kms_flip.c | 1 +
> 1 file changed, 1 insertion(+)
> mode change 100644 => 100755 tests/kms_f
Am Donnerstag, 24. Januar 2019, 17:58:26 CET schrieb Daniel Vetter:
> This will set an fb name for the first time!
>
> Signed-off-by: Daniel Vetter
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
After looking up the r
The kms_flip test relies on VBlank support, and this situation may
exclude some virtual drivers to take advantage of this set of tests.
This commit adds a mechanism that checks if a module has VBlank. If the
target module has VBlank support, kms_flip will run all the VBlank
tests; otherwise, the VB
During igt, we ask to reset the device if any requests are still
outstanding at the end of a test, as this quickly kills off any
erroneous hanging request streams that may escape a test. However, since
it may take the device a few milliseconds to flush itself after the end
of a normal test, *cough*
== Series Details ==
Series: drm/i915: Wait for a moment before forcibly resetting the device
URL : https://patchwork.freedesktop.org/series/55817/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5490 -> Patchwork_12054
Summa
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
In preparation for enabling HW semaphores, we need to keep in flight
timeline HWSP alive until the entire system is idle, as any other
timeline active on the GPU may still refer back to the already retired
timeline. We both have to delay recycling available cachelines and
unpinning old HWSP until t
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 submission, a simple but important step is being able to manage
each clients GTT separately. For which, we want to replace using the
struct_mutex as t
Currently we only allocate an object and vma if we are using a GGTT
virtual HWSP, and a plain struct page for a physical HWSP. For
convenience later on with global timelines, it will be useful to always
have the status page being tracked by a struct i915_vma. Make it so.
Signed-off-by: Chris Wilso
During igt, we ask to reset the device if any requests are still
outstanding at the end of a test, as this quickly kills off any
erroneous hanging request streams that may escape a test. However, since
it may take the device a few milliseconds to flush itself after the end
of a normal test, *cough*
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
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh alloca
On unwinding the active request we give it a small (limited to internal
priority levels) boost to prevent it from being gazumped a second time.
However, this means that it can be promoted to above the request that
triggered the preemption request, causing a preempt-to-idle cycle for no
change. We c
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes
From: Tvrtko Ursulin
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically
Build a chain using 2 contexts (A, B) then request a preemption such
that a later A request runs before the spinner in B.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_lrc.c | 103 +
1 file changed, 103 insertions(+)
diff --git a/drivers/gpu/drm/i915/s
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
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
Remove the struct_mutex requirement for looking up the vma for an
object.
v2: Highlight how the race for duplicate vma creation is resolved on
reacquiring the lock with a short comment.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +
After noticing that we trigger preemption events for currently executing
requests, as well as requests that complete before the preemption and
attempting to suppress those preemption events, it is wise to not
consider the queue_priority to be authoritative. As we only track the
maximum priority see
Looking forward, we need to break the struct_mutex dependency on
i915_gem_active. In the meantime, external use of i915_gem_active is
quite beguiling, little do new users suspect that it implies a barrier
as each request it tracks must be ordered wrt the previous one. As one
of many, it can be used
Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and keep track of inflight nodes so we can reap the
stale entries upon parking (thereby trimming our memory usage).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c| 55
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
Missed breadcrumb detection is defunct due to the tight coupling with
dma_fence signaling and the myriad ways we may signal fences from
everywhere but from an interrupt, i.e. we frequently signal a fence
before we even see its interrupt. This means that even if we miss an
interrupt for a fence, it
We currently track GPU memory usage inside VMA, such that we never
release memory used by the GPU until after it has finished accessing it.
However, we may want to track other resources aside from VMA, or we may
want to split a VMA into multiple independent regions and track each
separately. For th
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
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915
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
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
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.
v2: Reuse the common per-engine HWSP
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
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h |
In the next patch, we add another user that wants to check whether
requests can be merge into a single HW execution, and in the future we
want to add more conditions under which requests from the same context
cannot be merge. In preparation, extract out can_merge_rq().
Signed-off-by: Chris Wilson
We don't want to busywait on the GPU if we have other work to do. If we
give non-busywaiting workloads higher (initial) priority than workloads
that require a busywait, we will prioritise work that is ready to run
immediately.
Testcase: igt/gem_exec_schedule/semaphore
Signed-off-by: Chris Wilson
Having introduced per-context seqno, we know have a means to identity
progress across the system without feel of rollback as befell the
global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in
advance of submission safe in the knowledge that our target seqno and
address is stable.
How
== Series Details ==
Series: series starting with [01/28] drm/i915: Wait for a moment before
forcibly resetting the device
URL : https://patchwork.freedesktop.org/series/55819/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d1a18083cdf2 drm/i915: Wait for a moment before forcib
== Series Details ==
Series: series starting with [01/28] drm/i915: Wait for a moment before
forcibly resetting the device
URL : https://patchwork.freedesktop.org/series/55819/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Wait for a moment
== Series Details ==
Series: series starting with [01/28] drm/i915: Wait for a moment before
forcibly resetting the device
URL : https://patchwork.freedesktop.org/series/55819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5490 -> Patchwork_12055
=
Hi,
On Fri, Jan 25, 2019 at 8:38 PM Imre Deak wrote:
>
> On Tue, Jan 22, 2019 at 02:49:13PM +0530, Mahesh Kumar wrote:
> > Hi,
> >
> >
> > On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > The code managing the dbuf slices is borked and needs s
Hi,
On Fri, Jan 25, 2019 at 8:58 PM Ville Syrjälä
wrote:
>
> On Tue, Jan 22, 2019 at 02:58:46PM +0530, Mahesh Kumar wrote:
> > Hi,
> >
> > On Mon, Jan 21, 2019 at 9:01 PM Ville Syrjala
> > wrote:
> > >
> > > From: Ville Syrjälä
> > >
> > > The code managing the dbuf slices is borked and needs s
== Series Details ==
Series: series starting with [01/28] drm/i915: Wait for a moment before
forcibly resetting the device
URL : https://patchwork.freedesktop.org/series/55819/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5490_full -> Patchwork_12055_full
===
44 matches
Mail list logo
