== Series Details ==
Series: drm/i915/selftests: Refactor common live_test framework
URL : https://patchwork.freedesktop.org/series/55429/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5451_full -> Patchwork_11989_full
Summ
== Series Details ==
Series: drm/i915/selftests: Refactor common live_test framework
URL : https://patchwork.freedesktop.org/series/55429/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5451 -> Patchwork_11989
Summary
--
== Series Details ==
Series: drm/i915/selftests: Allocate mock ring/timeline per context
URL : https://patchwork.freedesktop.org/series/55424/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5449_full -> Patchwork_11988_full
== Series Details ==
Series: drm/i915/selftests: Refactor common live_test framework
URL : https://patchwork.freedesktop.org/series/55429/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/selftests: Refactor common live_test framework
+./include
== Series Details ==
Series: drm/i915/selftests: Refactor common live_test framework
URL : https://patchwork.freedesktop.org/series/55429/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
50297f5b1435 drm/i915/selftests: Refactor common live_test framework
-:435: WARNING:FILE_PATH
Before adding yet another copy of struct live_test and its handler,
refactor the existing code into a common framework for live selftests.
For many live selftests, we want to know if the GPU hung or otherwise
misbehaved during the execution of the test (beyond any infraction in
the behaviour under
== Series Details ==
Series: series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks (rev2)
URL : https://patchwork.freedesktop.org/series/55379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5449_full -> Patchwork_11987_full
===
If the device has error capturing disabled, we still allow previous
error state to be cleared by a write to sysfs/error. To actually confirm
that we can capture a fresh error state, we have to perform a read().
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_capture.c | 1 +
1 file changed,
== Series Details ==
Series: drm/i915/selftests: Allocate mock ring/timeline per context
URL : https://patchwork.freedesktop.org/series/55424/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5449 -> Patchwork_11988
Summary
--
To correctly simulate preemption between contexts, we need independent
timelines along each context. Make it so.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/mock_engine.c | 90 ++--
1 file changed, 47 insertions(+), 43 deletions(-)
== Series Details ==
Series: series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks (rev2)
URL : https://patchwork.freedesktop.org/series/55379/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5449 -> Patchwork_11987
=
== Series Details ==
Series: series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be enabled
when debugfs asks (rev2)
URL : https://patchwork.freedesktop.org/series/55379/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ef8a0eafdd9e drm/i915/psr: Allow PSR2 to be enabled wh
On Thu, 2019-01-17 at 21:59 -0800, Rodrigo Vivi wrote:
> We just got aware that there was more IDs available
> at spec, so let's add them already.
Reviewed-by: José Roberto de Souza
>
> Cc: James Ausmus
> Cc: José Roberto de Souza
> Signed-off-by: Rodrigo Vivi
> ---
> include/drm/i915_pciid
== Series Details ==
Series: Support 64 bpp half float formats (rev2)
URL : https://patchwork.freedesktop.org/series/53212/
State : failure
== Summary ==
Applying: drm/fourcc: Add 64 bpp half float formats
Applying: drm/i915/icl: Implement half float formats
Using index info to reconstruct a b
== Series Details ==
Series: series starting with [v2,1/8] drm/i915/sdvo: switch to kernel types
URL : https://patchwork.freedesktop.org/series/55405/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5447_full -> Patchwork_11982_full
==
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't use
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
https://patchwork.kernel.o
This series defines new formats and adds implementation to the i915 driver.
Since posting v1 I have removed the pixel normalize property, as it's not needed
for basic functionality. Also, I have been working on adding support to
userspace.
I have submitted an RFC to Mesa to make use of the new for
== Series Details ==
Series: drm/i915: GTT remapping for display (rev2)
URL : https://patchwork.freedesktop.org/series/55415/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5449 -> Patchwork_11985
Summary
---
**FAILUR
== Series Details ==
Series: drm/i915: Use b->irq_enable() as predicate for mock engine
URL : https://patchwork.freedesktop.org/series/55402/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5447_full -> Patchwork_11980_full
S
== Series Details ==
Series: drm/i915: GTT remapping for display (rev2)
URL : https://patchwork.freedesktop.org/series/55415/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add a new "remapped" gtt_view
+drivers/gpu/drm/i915/i915_gem_gtt.c:36
== Series Details ==
Series: drm/i915: GTT remapping for display (rev2)
URL : https://patchwork.freedesktop.org/series/55415/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
08b5a861466d drm/i915: Add a new "remapped" gtt_view
-:96: CHECK:LINE_SPACING: Please don't use multiple b
From: Ville Syrjälä
v2: Leave the stride alone for buffers that look to be for the cursor
---
drivers/gpu/drm/i915/i915_gem.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1e7c95d0fea1..b4b34519af
On 18/01/2019 14:00, Chris Wilson wrote:
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
Regard
On 18/01/2019 14:00, Chris Wilson wrote:
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(+),
On 18/01/2019 14:00, Chris Wilson wrote:
Remove the struct_mutex requirement for looking up the vma for an
object.
With the change log added:
Reviewed-by: Tvrtko Ursulin
It's not cool to keep omitting it and creating extra cross referencing
work every time you post it. It's not like we don
Quoting Tvrtko Ursulin (2019-01-18 16:03:27)
>
> On 18/01/2019 14:00, 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 othe
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/55415/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5449 -> Patchwork_11984
Summary
---
**FAILURE**
On 18/01/2019 14:00, Chris Wilson wrote:
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
On 18/01/2019 14:00, 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 un
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/55415/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: Add a new "remapped" gtt_view
+drivers/gpu/drm/i915/i915_gem_gtt.c:3637:34:
== Series Details ==
Series: drm/i915: GTT remapping for display
URL : https://patchwork.freedesktop.org/series/55415/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6c45cc6e9157 drm/i915: Add a new "remapped" gtt_view
-:96: CHECK:LINE_SPACING: Please don't use multiple blank li
From: Ville Syrjälä
With gtt remapping in place we can use arbitrarily large
framebuffers. Let's bump the limits to 16kx16k on gen7+.
The limit was chosen to match the maximum 2D surface size
of the 3D engine.
With the remapping we could easily go higher than that for the
display engine. However
From: Ville Syrjälä
With gtt remapping plugged in we can simply raise the stride
limit on gen4+. Let's just arbitraily pick 256 KiB as the limit.
No remapping CCS because the virtual address of each page actually
matters due to the new hash mode
(WaCompressedResourceDisplayNewHashMode:skl,kbl et
From: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1e7c95d0fea1..365125c6683b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i
From: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4053ed93e73c..fbe71fb23c9e 100644
--- a/drivers/gpu/drm/i915/intel_display.
From: Ville Syrjälä
Extend the rotated vma mock selftest to cover remapped vmas as
well.
TODO: reindent the loops I guess? Left like this for now to
ease review
v2: Include the vma type in the error message (Chris)
v3: Deal with trimmed sg
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
d
From: Ville Syrjälä
Another posting of the gtt remapping series. This time with Chris's idea
of forcing gtt remapping for ci. A slight gap in that testing comes from
the fact that igt will not align linear stride to 4k for non-dumb
buffers. I'd need to pair this with an igt patch to make that hap
From: Ville Syrjälä
Add a live selftest to excercise rotated/remapped vmas. We simply
write through the rotated/remapped vma, and confirm that the data
appears in the right page when read through the normal vma.
Not sure what the fallout of making all rotated/remapped vmas
mappable/fenceable wou
From: Ville Syrjälä
The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller strid
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.
v2: Use intel_remapped_plane_info base type
s/unused/unused_mbz/ (Chris)
Separate BUILD
Chris Wilson writes:
> Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged()
> as a reminder that it must be callable without struct_mutex held.
>
> Signed-off-by: Chris Wilson
> Cc: Michal Wajdeczko
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/
Chris Wilson writes:
> 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 atomi
== Series Details ==
Series: series starting with [01/38] drm/i915/execlists: Store the highest
priority context
URL : https://patchwork.freedesktop.org/series/55411/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
CC [
On 17/01/2019 14:35, Chris Wilson wrote:
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
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
It can be useful to have a single ioctl to create a context with all
the initial parameters instead of a series of create + setparam + setparam
ioctls. This extension to create context allows any of the parameters
to be passed in as a linked list to be applied to the newly constructed
context.
Sig
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
Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged()
as a reminder that it must be callable without struct_mutex held.
Signed-off-by: Chris Wilson
Cc: Michal Wajdeczko
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 6 +++---
1 file changed, 3 inser
For future GuC implementations, the execution order of individual
requests will be opaque. As such we will not have a single execution
timeline and will not know the last request/context to be run on each
engine. The major consequence for this is that we do not know which
context is still volatile
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 | 5 +-
drivers/gpu/drm/i915/i
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
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
To determine whether an engine has 'struck', we simply check whether or
not is still on the same seqno for several seconds. To keep this simple
mechanism intact over the loss of a global seqno, we can simply add a
new global heartbeat seqno instead. As we cannot know the sequence in
which requests
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
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/gpu/
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
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
An idea for extending uABI inspired by Vulkan's extension chains.
Instead of expanding the data struct for each ioctl every time we need
to add a new feature, define an extension chain instead. As we add
optional interfaces to control the ioctl, we define a new extension
struct that can be linked i
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
In preparation to making the ppGTT binding for a context explicit (to
facilitate reusing the same ppGTT between different contexts), allow the
user to create and destroy named ppGTT.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h
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
Previously, our view has been always to run the engines independently
within a context. (Multiple engines happened before we had contexts and
timelines, so they always operated independently and that behaviour
persisted into contexts.) However, at the user level the context often
represents a singl
Keep track of partially allocated pages for use in allocating future
timeline HWSP. This is still without migration, so it is possible for
the system to end up with each timeline in its own page, but we ensure
that no new allocation would needless allocate a fresh page!
Signed-off-by: Chris Wilson
A continuation of the series under review to show the current path to
load balancing. After the HWSP timeline reworking, we have the removal
of global seqno, and then the patches to construct a virtual engine with
load balancing across the equivalent siblings. Wrt veng, the changes
since last time
As we allow per-context engine allows the legacy concept of
I915_EXEC_RING no longer applies universally. We are still exposing the
unrelated exec-id in GEM_BUSY, so transition this ioctl (once more
slightly changing its ABI, but no one cares) over to only reporting the
uabi-class (not instance as
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with a
For future GuC firmware, the intention is to submit a large number of
contexts and their interdependencies and leave the execution order to
the firmware. As such, we want to allow the firmware freedom to execute
independent contexts in whatever order suits it and so must forgo the
concept of a sing
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
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
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 |
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 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
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
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
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 ---
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
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
From: Tvrtko Ursulin
Needed for a following patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer
In the next patch, we are introducing a broad virtual engine to encompass
multiple physical engines, losing the 1:1 nature of BIT(engine->id). To
reflect the broader set of engines implied by the virtual instance, lets
store the full bitmask.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
As we no longer have a precise indication of requests queued to an
engine, make no presumptions and just sample the ring registers to see
if the engine is busy.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_pmu.c | 47 +++--
1 file changed, 16 insertions(+
This was supposed to be a mask of all known rings, but it is being used
by execbuffer to filter out invalid rings, and so is instead mapping high
unused values onto valid rings. Instead of a mask of all known rings,
we need it to be the mask of all possible rings.
Fixes: 549f7365820a ("drm/i915: E
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load.
Allow the user to share ppGTT between contexts on the same fd. This
gives the user the ability to relax their context isolation to share vm
between their own contexts, but does not allow them to import a vm from
another fd. The use case for sharing a vm is for the proposed virtual
engine work where
On Thu, 17 Jan 2019, Mika Kuoppala wrote:
> Jani Nikula writes:
>
>> It's superfluous.
>
> One could argue that it has a minor documentative purpose.
> But there is comment for that.
>
> Reviewed-by: Mika Kuoppala
Thanks, pushed this one.
BR,
Jani.
>
>>
>> Signed-off-by: Jani Nikula
>> ---
>
== Series Details ==
Series: series starting with [v2,1/8] drm/i915/sdvo: switch to kernel types
URL : https://patchwork.freedesktop.org/series/55405/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5447 -> Patchwork_11982
Su
On Fri, 18 Jan 2019 at 11:53, Chris Wilson wrote:
>
> 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:
== Series Details ==
Series: drm/i915/icl: Adding few more device IDs for Ice Lake
URL : https://patchwork.freedesktop.org/series/55393/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5444_full -> Patchwork_11978_full
Summar
== Series Details ==
Series: series starting with [v2,1/8] drm/i915/sdvo: switch to kernel types
URL : https://patchwork.freedesktop.org/series/55405/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/sdvo: switch to kernel types
Okay!
Commit: d
== Series Details ==
Series: drm/i915/selftests: Make evict tolerant of foreign objects
URL : https://patchwork.freedesktop.org/series/55404/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5447 -> Patchwork_11981
Summary
---
On 17/01/2019 14:34, Chris Wilson wrote:
Keep track of partially allocated pages for use in allocating future
timeline HWSP. This is still without migration, so it is possible for
the system to end up with each timeline in its own page, but we ensure
that no new allocation would needless allocat
Chris Wilson writes:
> Keep track of partially allocated pages for use in allocating future
> timeline HWSP. This is still without migration, so it is possible for
timeline from HWSP?
> the system to end up with each timeline in its own page, but we ensure
> that no new allocation would needles
On 17/01/2019 14:34, Chris Wilson wrote:
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
On 1/18/19 3:05 AM, Rafael J. Wysocki wrote:
On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
wrote:
On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
wrote:
Hi Guenter,
Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit :
On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guitt
Chris Wilson writes:
> 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
On 1/18/19 2:42 AM, Vincent Guittot wrote:
Hi Guenter,
Le Thursday 17 Jan 2019 à 14:16:28 (-0800), Guenter Roeck a écrit :
On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote:
From: Thara Gopinath
This patch replaces jiffies based accounting for runtime_active_time
and runtime_su
Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Reviewed-by: Chris Wilson
Acked-by: Tvrtko Ursulin
Reviewed-by: Ville Syrjälä
Reviewed-by: José Roberto de Souza
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |
Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Minor checkpatch fixes sprinkled on top of the changed lines.
Acked-by: Chris Wilson
Acked-by: Tvrtko Ursulin
Reviewed-by: Ville Syrjälä
Reviewed-by: José Roberto de Souza
Signed
Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Acked-by: Chris Wilson
Acked-by: Tvrtko Ursulin
Reviewed-by: Ville Syrjälä
Reviewed-by: José Roberto de Souza
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_display.c
Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Minor checkpatch/whitepace fixes sprinkled on top of the changed lines.
v2: more whitespace fixes (Ville, José)
Acked-by: Chris Wilson
Acked-by: Tvrtko Ursulin
Reviewed-by: Ville
1 - 100 of 124 matches
Mail list logo
