On 10/10/2019 23:18, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/4] drm/i915/display: Handle fused off display
> correctly
> URL : https://patchwork.freedesktop.org/series/67872/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7058 -> P
When the kernel supports O_NONBLOCK reporting of a full execbuf queue,
take advantage of that to immediately report when the output would block
due to the ring being full.
Signed-off-by: Chris Wilson
---
lib/i915/gem_ring.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
di
On 10/10/2019 08:14, Chris Wilson wrote:
Since writing the comment that the scheduler is entirely passive, we've
added minimal timeslicing which adds the most primitive of active
elements (a timeout and reschedule).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Ramalingam C
---
driver
Hi all:
There are hardware that can do virtio datapath offloading while having
its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and reg
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
This patch adds bus uevent support for mdev bus in order to allow
cooperation with userspace.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_driver.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/vfio/mdev/mdev_driver.c
index b7c40ce8
Add support to parse mdev class id table.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/vfio_mdev.c | 2 ++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 10 ++
3 files changed, 15 insertions(+)
diff --git a/drivers/vfio/mdev/vfio_mdev.c b/driver
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
include/linux/mdev.h| 1 +
include/linux/virtio_mdev.h | 148
2 files changed, 149 insertions(+)
create mode
Currently, except for the create and remove, the rest of
mdev_parent_ops is designed for vfio-mdev driver only and may not help
for kernel mdev driver. With the help of class id, this patch
introduces device specific callbacks inside mdev_device
structure. This allows different set of callback to b
On 10/10/2019 14:58, Chris Wilson wrote:
Quoting Chris Wilson (2019-10-10 14:48:49)
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
duri
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the
On 10/10/2019 14:48, Chris Wilson wrote:
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only 'v
On 11/10/2019 09:06, Chris Wilson wrote:
When the kernel supports O_NONBLOCK reporting of a full execbuf queue,
take advantage of that to immediately report when the output would block
due to the ring being full.
Signed-off-by: Chris Wilson
---
lib/i915/gem_ring.c | 13 ++---
1 file
Quoting Tvrtko Ursulin (2019-10-11 09:20:12)
>
> On 10/10/2019 14:58, Chris Wilson wrote:
> > Quoting Chris Wilson (2019-10-10 14:48:49)
> >> Check the user's flags on the struct file before deciding whether or not
> >> to stall before submitting a request. This allows us to reasonably
> >> cheapl
On 10/10/2019 08:14, Chris Wilson wrote:
Before we BUG out with bad pending state, leave a telltale as to which
test failed.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 30 -
drivers/gpu/drm/i915/i9
On 10/10/2019 08:14, Chris Wilson wrote:
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell,
On 10/10/2019 08:14, Chris Wilson wrote:
Sometimes we want to emit a terminator request, a request that flushes
the pipeline and allows no request to come after it. This can be used
for a "preempt-to-idle" to ensure that upon processing the
context-switch to that request, all other active contex
Quoting Tvrtko Ursulin (2019-10-11 09:44:16)
>
> On 10/10/2019 08:14, Chris Wilson wrote:
> > Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
> > that we can expose properties on each engine to the sysadmin.
> >
> > To start with we have basic analogues of the i915_query ioct
== Series Details ==
Series: series starting with [1/2] drm/i915/selftests: Check known register
values within the context
URL : https://patchwork.freedesktop.org/series/67862/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7057_full -> Patchwork_14754_full
===
On 11/10/2019 09:49, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-11 09:44:16)
On 10/10/2019 08:14, Chris Wilson wrote:
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analog
On 10/10/2019 08:14, Chris Wilson wrote:
To flush idle barriers, and even inflight requests, we want to send a
preemptive 'pulse' along an engine. We use a no-op request along the
pinned kernel_context at high priority so that it should run or else
kick off the stuck requests. We can use this to
== Series Details ==
Series: mdev based hardware virtio offloading support (rev4)
URL : https://patchwork.freedesktop.org/series/66989/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1c00a9513524 mdev: class id support
ca514b262666 mdev: bus uevent support
136343b6a2ec modpost:
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later
On 10/10/2019 08:14, Chris Wilson wrote:
On completion of a banned context, scrub the context image so that we do
s/completion/schedule out/ like in the subject line? Otherwise I
struggle to understand how banned context is completing. Presumably it
was banned because it keeps hanging.
no
== Series Details ==
Series: series starting with [01/10] drm/i915: Note the addition of timeslicing
to the pretend scheduler (rev2)
URL : https://patchwork.freedesktop.org/series/67827/
State : failure
== Summary ==
Applying: drm/i915: Note the addition of timeslicing to the pretend schedule
Quoting Tvrtko Ursulin (2019-10-11 10:11:58)
>
> On 10/10/2019 08:14, Chris Wilson wrote:
> > +#include "intel_context.h"
> > +#include "intel_engine_heartbeat.h"
> > +#include "intel_engine_pm.h"
> > +#include "intel_engine.h"
> > +#include "intel_gt.h"
> > +
> > +static void idle_pulse(struct in
Quoting Tvrtko Ursulin (2019-10-11 10:47:26)
>
> On 10/10/2019 08:14, Chris Wilson wrote:
> > On completion of a banned context, scrub the context image so that we do
>
> s/completion/schedule out/ like in the subject line? Otherwise I
> struggle to understand how banned context is completing. P
== Series Details ==
Series: mdev based hardware virtio offloading support (rev4)
URL : https://patchwork.freedesktop.org/series/66989/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7061 -> Patchwork_14764
Summary
---
On Thu, Oct 10, 2019 at 01:15:09PM -0400, John Maguire wrote:
> Hi there,
>
> I wasn't sure which mailing list to use so I BCC'd
> intel-gfx@lists.freedesktop.org and dri-de...@lists.freedesktop.org
Just use Cc. We want all replies to go to the list(s) as well.
>
> I'm using a Lenovo Thinkpad T
Quoting Tvrtko Ursulin (2019-10-11 10:47:26)
> > +static void
> > +mark_complete(struct i915_request *rq, struct intel_engine_cs *engine)
> > +{
> > + const struct intel_timeline * const tl =
> > rcu_dereference(rq->timeline);
> > +
> > + *(u32 *)tl->hwsp_seqno = rq->fence.seqno;
> > +
Hi Baolu,
On Friday, October 11, 2019 8:54:09 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 9/3/19 3:41 PM, Janusz Krzysztofik wrote:
> > Hi Baolu,
> >
> > On Tuesday, September 3, 2019 3:29:40 AM CEST Lu Baolu wrote:
> >> Hi Janusz,
> >>
> >> On 9/2/19 4:37 PM, Janusz Krzysztofik wrote:
> I
Only the requests that have not completed do we want to change the
status of to signal the -EIO when cancelling the inflight set of requests
upon wedging.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 8 ++--
1 file cha
Quoting Chris Wilson (2019-10-11 11:15:58)
> Quoting Tvrtko Ursulin (2019-10-11 10:47:26)
> > > + if (unlikely(i915_gem_context_is_banned(ce->gem_context)))
> > > + cancel_active(rq, engine);
> >
> > Or you are counting this is already the last runnable request from this
> > conte
== Series Details ==
Series: series starting with [CI,1/9] drm/i915/perf: Replace global wakeref
tracking with engine-pm (rev4)
URL : https://patchwork.freedesktop.org/series/67874/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7058_full -> Patchwork_14761_full
==
== Series Details ==
Series: drm/i915/execlists: Only mark incomplete requests as -EIO on cancelling
URL : https://patchwork.freedesktop.org/series/67904/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7061 -> Patchwork_14766
On schedule-out (CS completion) of a banned context, scrub the context
image so that we do not replay the active payload. The intent is that we
skip banned payloads on request submission so that the timeline
advancement continues on in the background. However, if we are returning
to a preempted req
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell, and flesh out the
directory structure. Later
== Series Details ==
Series: series starting with [01/10] drm/i915: Note the addition of timeslicing
to the pretend scheduler (rev3)
URL : https://patchwork.freedesktop.org/series/67827/
State : failure
== Summary ==
Applying: drm/i915: Note the addition of timeslicing to the pretend schedule
Hello Chris Wilson,
This is a semi-automatic email about new static checker warnings.
The patch 50d16d44cce4: "drm/i915/selftests: Exercise context
switching in parallel" from Sep 30, 2019, leads to the following
Smatch complaint:
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:349
== Series Details ==
Series: drm/i915: Expose engine properties via sysfs (rev3)
URL : https://patchwork.freedesktop.org/series/66849/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
379c8db3d036 drm/i915: Expose engine properties via sysfs
-:66: WARNING:FILE_PATH_CHANGES: added,
== Series Details ==
Series: drm/i915: Expose engine properties via sysfs (rev3)
URL : https://patchwork.freedesktop.org/series/66849/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: drm/i915: Expose engine properties via sysfs
-
+drivers/gpu/drm/i915/g
On Thu, Oct 10, 2019 at 06:09:02PM -0700, Lucas De Marchi wrote:
> Those init functions mark their success in the intel_dig_port
> struct, the return values are not really used.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 11 +--
> drivers/gpu
Quoting Dan Carpenter (2019-10-11 12:42:09)
> Hello Chris Wilson,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch 50d16d44cce4: "drm/i915/selftests: Exercise context
> switching in parallel" from Sep 30, 2019, leads to the following
> Smatch complaint:
>
>
On 11/10/2019 11:33, Chris Wilson wrote:
Only the requests that have not completed do we want to change the
status of to signal the -EIO when cancelling the inflight set of requests
upon wedging.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm
On Thu, Oct 10, 2019 at 06:09:03PM -0700, Lucas De Marchi wrote:
> Both Ice Lake and Elkhart Lake (gen 11) support MST on all external
> connections except DDI A. Tiger Lake (gen 12) supports on all external
> connections.
>
> Move the check to happen inside intel_dp_mst_encoder_init() and add
> s
On Thu, Oct 10, 2019 at 06:09:04PM -0700, Lucas De Marchi wrote:
> The new line is already added by pipe_config_mismatch(), so the callers
> shouldn't add it.
I guess fallout from commit 48c38154d539 ("drm/i915: use DRM_DEBUG_KMS()
instead of drm_dbg(DRM_UT_KMS, ...)") ?
Looks correct to me.
Revi
== Series Details ==
Series: drm/i915: Expose engine properties via sysfs (rev3)
URL : https://patchwork.freedesktop.org/series/66849/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7061 -> Patchwork_14768
Summary
---
On Thu, Oct 10, 2019 at 06:09:05PM -0700, Lucas De Marchi wrote:
> This way it's easier to figure out what didn't match when we have
> multiple pipes enabled.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 33 +++-
> 1 file changed, 18 i
On Thu, Oct 10, 2019 at 06:09:06PM -0700, Lucas De Marchi wrote:
> s/?/:/ so it's get correctly colored by dmesg.
What do you mean correctly?
The debug message was asking the question "(is) MST supported?"
After this it just declares that MST is not supported. I guess no real
difference so I coul
On 11/10/2019 12:36, Chris Wilson wrote:
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
that we can expose properties on each engine to the sysadmin.
To start with we have basic analogues of the i915_query ioctl so that we
can pretty print engine discovery from the shell,
On Thu, Oct 10, 2019 at 02:01:32PM -0700, Manasi Navare wrote:
> We no longer use the connection mutex and hence no need to
> define drm_device *dev, it causes a unused variable build warning
>
> Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
> Cc: Sean Paul
Reviewed-by: Sean Pa
On Thu, Oct 10, 2019 at 12:32:38PM -0700, José Roberto de Souza wrote:
> If all pipes are fused off it means that display is disabled, similar
> like we handle for GEN 7 and 8 right above.
>
> On GEN 9 the bit 31 is "Internal Graphics Disable" and on newer GENs
> it has another function, probably
On Thu, Oct 10, 2019 at 12:32:39PM -0700, José Roberto de Souza wrote:
> HDCP could be fused off, so not all GEN9+ platforms will support it.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> drivers/gpu/drm/i915/i915_pci.c | 2 ++
> d
On Thu, Oct 10, 2019 at 12:32:41PM -0700, José Roberto de Souza wrote:
> Those features could be fused off on GEN9 non-low power and newer
> GENs.
Should probably be two patches.
>
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm
On Thu, Oct 10, 2019 at 08:45:42PM +, Souza, Jose wrote:
> I messed up on this patch, please ignore this one.
> Will send the fixed version soon.
The whole thing is wrong according to the spec:
"This field is unused on BXT. Any CD clock frequency limitation must be
done in software."
>
> On
Quoting Tvrtko Ursulin (2019-10-11 13:16:33)
>
> On 11/10/2019 12:36, Chris Wilson wrote:
> > Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
> > that we can expose properties on each engine to the sysadmin.
> >
> > To start with we have basic analogues of the i915_query ioct
We already check that debugfs do not cause spam (and they tend to be
more heavyhanded and so more likely to break), but that does not excuse
not checking our sysfs directory!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/debugfs_test.c | 8 ++--
1 file changed, 6 insertions(+), 2
On 11/10/2019 12:16, Chris Wilson wrote:
On schedule-out (CS completion) of a banned context, scrub the context
image so that we do not replay the active payload. The intent is that we
skip banned payloads on request submission so that the timeline
advancement continues on in the background. How
On 11/10/2019 13:43, Chris Wilson wrote:
We already check that debugfs do not cause spam (and they tend to be
more heavyhanded and so more likely to break), but that does not excuse
not checking our sysfs directory!
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/debugfs_test.c | 8
On 11/10/2019 13:31, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-10-11 13:16:33)
[snip]
Looks fine in principle.
I am tempted to go with some of the engine->flags from the start but I
don't have an use case apart from saying that it sounds like it makes sense.
The problem I saw with
On 11/10/2019 00:23, Chris Wilson wrote:
Introduce a new perf_ioctl command to change the OA configuration of the
active stream. This allows the OA stream to be reconfigured between
batch buffers, giving greater flexibility in sampling. We inject a
request into the OA context to reconfigure the s
Quoting Chris Wilson (2019-10-10 14:48:49)
> Check the user's flags on the struct file before deciding whether or not
> to stall before submitting a request. This allows us to reasonably
> cheaply honour O_NONBLOCK without checking at more critical phases
> during request submission.
>
> Suggested
In order to ensure constant caches are invalidated
properly with a0, we need extra hdc flush after invalidation.
References: HSDES#1604544889
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/d
Aim for completeness and invalidate also the ro parts
in l3 cache. This might allow to get rid of the preparser
disable/enable workaround on invalidation path.
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc
Add hdc pipeline flush to ensure memory state is coherent
in L3 when we are done.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_
== Series Details ==
Series: drm/i915/ehl: Port C's hotplug interrupt is associated with TC1 bits
URL : https://patchwork.freedesktop.org/series/67881/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7060_full -> Patchwork_14762_full
=
On 10/10/2019 08:14, Chris Wilson wrote:
Normally, we rely on our hangcheck to prevent persistent batches from
hogging the GPU. However, if the user disables hangcheck, this mechanism
breaks down. Despite our insistence that this is unsafe, the users are
equally insistent that they want to use e
Quoting Tvrtko Ursulin (2019-10-11 14:10:21)
>
> On 11/10/2019 12:16, Chris Wilson wrote:
> > On schedule-out (CS completion) of a banned context, scrub the context
> > image so that we do not replay the active payload. The intent is that we
> > skip banned payloads on request submission so that t
Quoting Tvrtko Ursulin (2019-10-11 14:55:00)
>
> On 10/10/2019 08:14, Chris Wilson wrote:
> > Normally, we rely on our hangcheck to prevent persistent batches from
> > hogging the GPU. However, if the user disables hangcheck, this mechanism
> > breaks down. Despite our insistence that this is unsa
On 10/10/2019 08:14, Chris Wilson wrote:
Replace sampling the engine state every so often with a periodic
heartbeat request to measure the health of an engine. This is coupled
with the forced-preemption to allow long running requests to survive so
long as they do not block other users.
The hear
== Series Details ==
Series: Small fixes before fixing MST
URL : https://patchwork.freedesktop.org/series/67883/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7060_full -> Patchwork_14763_full
Summary
---
**SUCCESS**
On 10/10/2019 08:14, Chris Wilson wrote:
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
The point of this one completely escapes me at the moment. Idle barriers
are kept in there to be consumed by
On Fri, 2019-10-11 at 15:25 +0300, Ville Syrjälä wrote:
> On Thu, Oct 10, 2019 at 12:32:38PM -0700, José Roberto de Souza
> wrote:
> > If all pipes are fused off it means that display is disabled,
> > similar
> > like we handle for GEN 7 and 8 right above.
> >
> > On GEN 9 the bit 31 is "Internal
Quoting Tvrtko Ursulin (2019-10-11 15:24:21)
>
> On 10/10/2019 08:14, Chris Wilson wrote:
> > +config DRM_I915_HEARTBEAT_INTERVAL
> > + int "Interval between heartbeat pulses (ms)"
> > + default 2500 # milliseconds
> > + help
> > + While active the driver uses a periodic request,
Quoting Tvrtko Ursulin (2019-10-11 15:56:35)
>
> On 10/10/2019 08:14, Chris Wilson wrote:
> > If we do find ourselves with an idle barrier inside our active while
> > waiting, attempt to flush it by emitting a pulse using the kernel
> > context.
>
> The point of this one completely escapes me at
On Fri, 2019-10-11 at 12:36 +0100, Chris Wilson wrote:
> Preliminary stub to add engines underneath /sys/class/drm/cardN/, so
> that we can expose properties on each engine to the sysadmin.
>
> To start with we have basic analogues of the i915_query ioctl so that
> we
> can pretty print engine dis
Quoting Summers, Stuart (2019-10-11 16:14:07)
> On Fri, 2019-10-11 at 12:36 +0100, Chris Wilson wrote:
> > +void intel_engines_add_sysfs(struct drm_i915_private *i915)
> > +{
> > + static const struct attribute *files[] = {
> > + &name_attr.attr,
> > + &class_attr.attr,
== Series Details ==
Series: series starting with [1/3] drm/i915/tgl: Include ro parts of l3 to
invalidate
URL : https://patchwork.freedesktop.org/series/67912/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9438571a7abe drm/i915/tgl: Include ro parts of l3 to invalidate
-:21:
Quoting Chris Wilson (2019-10-11 15:22:17)
> Quoting Tvrtko Ursulin (2019-10-11 14:55:00)
> >
> > On 10/10/2019 08:14, Chris Wilson wrote:
> > > + if (engine)
> > > + active |= engine->mask;
> > > +
> > > + dma_fence_put(fence);
> > > + }
> > > +
> >
== Series Details ==
Series: series starting with [1/3] drm/i915/tgl: Include ro parts of l3 to
invalidate
URL : https://patchwork.freedesktop.org/series/67912/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7064 -> Patchwork_14769
=
On Wed, Oct 09, 2019 at 02:27:41PM -0700, Matt Roper wrote:
> On Wed, Oct 09, 2019 at 05:01:20PM -0400, Daniele Castagna wrote:
> > On Wed, Oct 9, 2019 at 1:34 PM Matt Roper wrote:
> > >
> > > The previous version of this series was posted in February here:
> > >
> > > https://lists.freed
On Fri, Oct 11, 2019 at 03:08:50PM +0300, Ville Syrjälä wrote:
On Thu, Oct 10, 2019 at 06:09:06PM -0700, Lucas De Marchi wrote:
s/?/:/ so it's get correctly colored by dmesg.
What do you mean correctly?
The debug message was asking the question "(is) MST supported?"
After this it just declare
On Fri, Oct 11, 2019 at 10:08:32AM -0700, Lucas De Marchi wrote:
> On Fri, Oct 11, 2019 at 03:08:50PM +0300, Ville Syrjälä wrote:
> >On Thu, Oct 10, 2019 at 06:09:06PM -0700, Lucas De Marchi wrote:
> >> s/?/:/ so it's get correctly colored by dmesg.
> >
> >What do you mean correctly?
> >
> >The deb
On Fri, Oct 11, 2019 at 08:14:32PM +0300, Ville Syrjälä wrote:
On Fri, Oct 11, 2019 at 10:08:32AM -0700, Lucas De Marchi wrote:
On Fri, Oct 11, 2019 at 03:08:50PM +0300, Ville Syrjälä wrote:
>On Thu, Oct 10, 2019 at 06:09:06PM -0700, Lucas De Marchi wrote:
>> s/?/:/ so it's get correctly colored
Sometimes a test has to wait for RCU to complete a grace period and
perform its callbacks, for example waiting for a close(fd) to actually
perform the fput(filp) and so trigger all the callbacks such as closing
GEM contexts. There is no trivial means of triggering an RCU barrier
from userspace, so
== Series Details ==
Series: mdev based hardware virtio offloading support (rev4)
URL : https://patchwork.freedesktop.org/series/66989/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7061_full -> Patchwork_14764_full
Summary
+dri, +Daniel
On Thu, Oct 10, 2019 at 06:09:07PM -0700, Lucas De Marchi wrote:
Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/drm_dp_mst_topology.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_
On Thu, 2019-10-10 at 17:26 -0700, Vivek Kasireddy wrote:
> On some platforms that have the MCC PCH, Port C's hotplug interrupt
Some?
> bits are mapped to TC1 bits.
>
> Suggested-by: Matt Roper
> Signed-off-by: Vivek Kasireddy
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
> drivers
On Thu, 2019-10-10 at 18:09 -0700, Lucas De Marchi wrote:
> Instead of the ever growing switch, just compute the ddi io power
> domain
> based on the port number.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 43 ++
Reviewed-by: José Roberto de Souza
On Thu, 2019-10-10 at 18:09 -0700, Lucas De Marchi wrote:
> Fixes: 83fa9842afe7 ("drm/dp-mst: Drop connection_mutex check")
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git
On Fri, 11 Oct 2019 at 18:38, Chris Wilson wrote:
>
> Sometimes a test has to wait for RCU to complete a grace period and
> perform its callbacks, for example waiting for a close(fd) to actually
> perform the fput(filp) and so trigger all the callbacks such as closing
> GEM contexts. There is no t
Quoting Mika Kuoppala (2019-10-11 14:39:10)
> Add hdc pipeline flush to ensure memory state is coherent
> in L3 when we are done.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
> 2 files changed,
Quoting Mika Kuoppala (2019-10-11 14:39:09)
> Aim for completeness and invalidate also the ro parts
> in l3 cache. This might allow to get rid of the preparser
> disable/enable workaround on invalidation path.
>
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/i
Quoting Mika Kuoppala (2019-10-11 14:39:10)
> Add hdc pipeline flush to ensure memory state is coherent
> in L3 when we are done.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 +
> drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
> 2 files changed,
Quoting Mika Kuoppala (2019-10-11 14:39:11)
> In order to ensure constant caches are invalidated
> properly with a0, we need extra hdc flush after invalidation.
>
> References: HSDES#1604544889
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 18 ++
>
This includes other platforms that utilize the same gen graphics as
CFL: AML, WHL and CML.
Signed-off-by: Juston Li
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/
== Series Details ==
Series: drm/i915: Add an rcu_barrier option to i915_drop_caches
URL : https://patchwork.freedesktop.org/series/67922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7065 -> Patchwork_14770
Summary
--
Corresponding kernel commit 54895010a893 ("drm/i915: Add an rcu_barrier
option to i915_drop_caches")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
lib/igt_debugfs.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index 36b638177..a56f09dd2 100
On Fri, 11 Oct 2019 at 19:37, Chris Wilson wrote:
>
> Corresponding kernel commit 54895010a893 ("drm/i915: Add an rcu_barrier
> option to i915_drop_caches")
>
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mai
1 - 100 of 134 matches
Mail list logo
