== Series Details ==
Series: Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
URL : https://patchwork.freedesktop.org/series/80235/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8836_full -> Patchwork_18305_full
===
On 04.08.20 08:35, Oleksandr Andrushchenko wrote:
On 8/4/20 9:12 AM, Jürgen Groß wrote:
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following st
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
This is the sync up with the canonical definition of the
display protocol in Xen.
1. Add protocol version as an integer
Version string, which is in fact an integer, is hard to handle in the
code that supports diff
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_ge
On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
It is possible that the scatter-gather table during dmabuf import has
non-zero offset of the data, but user-space doesn't expect that.
Fix this by failing the import, so user-space doesn't access wrong data.
Fixes:
On 8/4/2020 11:19 AM, Kulkarni, Vandita wrote:
-Original Message-
From: Michel Dänzer
Sent: Wednesday, July 29, 2020 1:04 PM
To: Kulkarni, Vandita ; Zanoni, Paulo R
; Vetter, Daniel ; B S,
Karthik ; intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Shankar, Uma
; nic
> -Original Message-
> From: Michel Dänzer
> Sent: Wednesday, July 29, 2020 1:04 PM
> To: Kulkarni, Vandita ; Zanoni, Paulo R
> ; Vetter, Daniel ; B S,
> Karthik ; intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org; Shankar, Uma
> ; nicholas.kazlaus...@amd.com
> Subject:
== Series Details ==
Series: Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
URL : https://patchwork.freedesktop.org/series/80235/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8836 -> Patchwork_18305
Sum
== Series Details ==
Series: Revert "drm/i915/rkl: Add Wa_14011224835 for PHY B initialization"
URL : https://patchwork.freedesktop.org/series/80235/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
The hardware team has dropped this workaround from the bspec; it is no
longer needed.
This reverts commit 111822b21be995a3a4a731066db3d820523c57f7.
Bspec: 49291
Cc: José Roberto de Souza
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_combo_phy.c| 50 ---
drive
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev3)
URL : https://patchwork.freedesktop.org/series/79615/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8836_full -> Patchwork_18304_full
Summary
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Matt Roper <
> matthew.d.ro...@intel.com
> >
>
> DG1's vswing tables are the same for eDP and HDMI but have slight
> differences from ICL/TGL for DP.
Reviewed-by: José Roberto de Souza
>
> Bspec: 49291
> Cc: Clinton Taylor <
> c
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Anshuman Gupta <
> anshuman.gu...@intel.com
> >
>
> DC6 is not supported on DG1, so change the allowed DC mask for DG1.
>
> Cc: Uma Shankar <
> uma.shan...@intel.com
> >
> Signed-off-by: Anshuman Gupta <
> anshuman.gu...@intel.com
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Anshuman Gupta <
> anshuman.gu...@intel.com
> >
>
> DGFX devices have different DMC_DEBUG* counter MMIO address
> offset. Incorporate these changes in i915_reg.h for DG1 DC5/DC6
> counter and handle i915_dmc_info accordingly.
>
> C
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Matt Atwood <
> matthew.s.atw...@intel.com
> >
>
> Add support to load DMC v2.0.2 on DG1
>
> While we're at it, tweak the TGL and RKL firmware size definition to
> follow the convention used in previous platforms. Remove obsolete
>
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> From: Matt Roper <
> matthew.d.ro...@intel.com
> >
>
> DG1 does some additional pcode/uncore handshaking at
> boot time; this handshaking must complete before various other pcode
> commands are effective and before general work is submitt
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev3)
URL : https://patchwork.freedesktop.org/series/79615/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8836 -> Patchwork_18304
Summary
---
**S
== Series Details ==
Series: drm/kmb: Add support for KeemBay Display (rev3)
URL : https://patchwork.freedesktop.org/series/79615/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e5e28d2e25e4 drm/kmb: Add support for KeemBay Display
-:57: WARNING:FILE_PATH_CHANGES: added, moved o
This is a new DRM driver for Intel's KeemBay SOC.
The SoC couples an ARM Cortex A53 CPU with an Intel
Movidius VPU.
This driver is tested with the KMB EVM board which is the refernce baord
for Keem Bay SOC. The SOC's display pipeline is as follows
+--++-++-
+Chris Wilson
On Mon, Aug 3, 2020 at 12:59 PM Lucas De Marchi
wrote:
>
> On Fri, Jul 10, 2020 at 5:00 AM Matthew Auld wrote:
> >
> > We may be without a context to perform various internal blitter
> > operations, for example when performing object migration. Piggybacking
> > off the kernel_conte
On Fri, Jul 10, 2020 at 5:00 AM Matthew Auld wrote:
>
> We may be without a context to perform various internal blitter
> operations, for example when performing object migration. Piggybacking
> off the kernel_context is probably a bad idea, since it has other uses.
>
> Signed-off-by: Matthew Auld
On Mon, 2020-08-03 at 16:38 +, Patchwork wrote:
> Patch Details
> Series: drm/i915: Fix wrong return value in intel_atomic_check()
> URL: https://patchwork.freedesktop.org/series/80208/
> State:failure
> Details:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18299/in
On Sun, 2020-08-02 at 19:15 +0800, Tianjia Zhang wrote:
> In the case of calling check_digital_port_conflicts() failed, a
> negative error code -EINVAL should be returned.
Reviewed-by: José Roberto de Souza
>
> Fixes: bf5da83e4bd80 ("drm/i915: Move check_digital_port_conflicts() earier")
> Cc:
On 03/08/2020 17:23, Chris Wilson wrote:
-enum drm_i915_gem_execbuffer_ext {
- /**
-* See drm_i915_gem_execbuf_ext_timeline_fences.
-*/
- DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES = 1,
-
- DRM_I915_GEM_EXECBUFFER_EXT_MAX /* non-ABI */
-};
+/**
+ * See drm_i915_
== Series Details ==
Series: drm/i915/tgl: Wa_1607138340
URL : https://patchwork.freedesktop.org/series/80210/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8834_full -> Patchwork_18301_full
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915: Fix wrong return value in intel_atomic_check()
URL : https://patchwork.freedesktop.org/series/80208/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8834_full -> Patchwork_18299_full
Sum
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80219/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18303
===
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80219/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commi
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80219/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
378bbbd633f5 drm/i915/gem: Reduce context terminatio
== Series Details ==
Series: drm/i915: timeline semaphore support (rev2)
URL : https://patchwork.freedesktop.org/series/80214/
State : failure
== Summary ==
Applying: drm/i915: introduce a mechanism to extend execbuf2
Applying: drm/i915: add syncobj timeline support
Using index info to reconst
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 28 +++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we wer
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reuse
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client late
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running
As we now protect the timeline list using RCU, we can drop the
timeline->mutex for guarding the list iteration during context close, as
we are searching for an inflight request. Any new request will see the
context is banned and not be submitted. In doing so, pull the checks for
a concurrent submis
This is the bunch of trivial changes that I had wanted.
- stop arbitrarily limiting the uABI to a single extension block
- handle timeline syncobj as an extension of binary syncobj
- num_fences to appease Tvrtko who objects to me calling things nobject
- the only way not to have ABI values is n
On 03/08/2020 17:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-08-03 15:01:47)
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring whic
Quoting Lionel Landwerlin (2020-08-03 15:01:47)
> To allow faster engine to engine synchronization, peel the layer of
> dma-fence-chain to expose potential i915 fences so that the
> i915-request code can emit HW semaphore wait/signal operations in the
> ring which is faster than waking up the host
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
v4: Rebase
Move array fence parsing in i915_gem_do_execbuffer()
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads after interrupt notificati
Hi all,
Hopefully last CI run with the IGT tests :)
Test-with: 20200803135851.316355-1-lionel.g.landwer...@intel.com
Cheers,
Lionel Landwerlin (3):
drm/i915: introduce a mechanism to extend execbuf2
drm/i915: add syncobj timeline support
drm/i915: peel dma-fence-chains wait fences
.../g
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_UL
An important property for multi-client systems is that each client gets
a 'fair' allotment of system time. (Where fairness is at the whim of the
context properties, such as priorities.) This test forks N independent
clients (albeit they happen to share a single vm), and does an equal
amount of work
== Series Details ==
Series: drm/i915/tgl: Wa_1607138340
URL : https://patchwork.freedesktop.org/series/80210/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18301
Summary
---
**SUCCESS**
No regre
== Series Details ==
Series: drm/i915/tgl: Wa_1607138340
URL : https://patchwork.freedesktop.org/series/80210/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/tgl: Wa_1607138340
URL : https://patchwork.freedesktop.org/series/80210/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cfeda9f90aed drm/i915/tgl: Wa_1607138340
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
== Series Details ==
Series: drm/i915: Fix wrong return value in intel_atomic_check()
URL : https://patchwork.freedesktop.org/series/80208/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18299
Summary
-
Quoting Chris Wilson (2020-08-03 14:20:17)
> From: Mika Kuoppala
>
> Avoid possible cs hang with semaphores by disabling lite restore.
>
> References: 921f0c47f228 ("drm/i915: Revert "drm/i915/tgl: Wa_1607138340"")
> Signed-off-by: Mika Kuoppala
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> Cc: Chris
== Series Details ==
Series: drm/i915: Fix wrong return value (rev2)
URL : https://patchwork.freedesktop.org/series/80175/
State : failure
== Summary ==
Applying: drm/i915: Fix wrong return value
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i915_active.c
M
From: Mika Kuoppala
Avoid possible cs hang with semaphores by disabling lite restore.
References: 921f0c47f228 ("drm/i915: Revert "drm/i915/tgl: Wa_1607138340"")
Signed-off-by: Mika Kuoppala
Cc: Tvrtko Ursulin
Cc: Tony Ye
Cc: Chris Wilson
---
Let's give this another spin. The hangs are still
== Series Details ==
Series: drm/i915: Fix wrong return value in intel_atomic_check()
URL : https://patchwork.freedesktop.org/series/80208/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
___
In the case of calling check_digital_port_conflicts() failed, a
negative error code -EINVAL should be returned.
Fixes: bf5da83e4bd80 ("drm/i915: Move check_digital_port_conflicts() earier")
Cc: Ville Syrjälä
Signed-off-by: Tianjia Zhang
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of chec
On Sun, Aug 02, 2020 at 02:14:06PM -0500, Bjorn Helgaas wrote:
> But what guarantees that a PCI config register cannot contain ~0?
> If there's something about that in the spec I'd love to know where it
> is because it would simplify a lot of things.
There isn't. An we even have cases like the NV
In function i915_active_acquire_preallocate_barrier(), not all
paths have the return value set correctly, and in case of memory
allocation failure, a negative error code should be returned.
Cc: Chris Wilson
Signed-off-by: Tianjia Zhang
---
drivers/gpu/drm/i915/i915_active.c| 4 ++--
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two overlapping ways of reporting
errors and complicates error checking.
It is possible to move to one single way of chec
On 8/1/20 2:56 PM, Borislav Petkov wrote:
On Sat, Aug 01, 2020 at 01:24:29PM +0200, Saheed O. Bolarinwa wrote:
The return value of pci_read_config_*() may not indicate a device error.
However, the value read by these functions is more likely to indicate
this kind of error. This presents two ov
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80201/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8834_full -> Patchwork_18297_full
Summary
---
**FA
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80203/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18298
===
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80203/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commi
== Series Details ==
Series: series starting with [1/7] drm/i915/gem: Reduce context termination
list iteration guard to RCU
URL : https://patchwork.freedesktop.org/series/80203/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4421ede59e7d drm/i915/gem: Reduce context terminatio
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8834 -> Patchwork_18297
Summary
---
**SUCCESS**
Mix in a modicum of generic userptr thrashing for a quick (1s) BAT pass,
as we have currently no coverage of userptr at all in BAT.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_parallel.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80201/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
___
== Series Details ==
Series: drm/i915: timeline semaphore support
URL : https://patchwork.freedesktop.org/series/80201/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d38db3114f74 drm/i915: introduce a mechanism to extend execbuf2
-:377: CHECK:SPACING: spaces preferred around th
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reuse
As we now protect the timeline list using RCU, we can drop the
timeline->mutex for guarding the list iteration during context close, as
we are searching for an inflight request. Any new request will see the
context is banned and not be submitted. In doing so, pull the checks for
a concurrent submis
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 28 +++
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/gpu/drm/i915/i915_request.h
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client late
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we wer
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 48 ++---
1 file changed, 41 insertions(+), 7 deletions
Mix in a modicum of generic userptr thrashing for a quick (1s) BAT pass,
as we have currently no coverage of userptr at all in BAT.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_parallel.c| 31 +--
tests/intel-ci/fast-feedback.testlist | 5 -
2 files ch
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads after interrupt notificati
Hi all,
Hopefully this last run is all clean. No changes in this series, just
a rebase on top of Danvet's s/DRM_ERROR/DRM_DEBUG/.
Test-with: 20200803090053.260115-1-lionel.g.landwer...@intel.com
Cheers,
Lionel Landwerlin (3):
drm/i915: introduce a mechanism to extend execbuf2
drm/i915: add
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
v4: Rebase
Move array fence parsing in i915_gem_do_execbuffer()
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_UL
On Sun, Aug 02, 2020 at 10:51:34PM +0200, Hans de Goede wrote:
> On 7/29/20 10:12 AM, Andy Shevchenko wrote:
...
> Ok, I've added the suggested/discussed helper in my personal tree. Is it ok
> if I add your Reviewed-by with that change in place.
Yes, go ahead!
> This is the last unreviewed
> bi
On Wed, 29 Jul 2020 at 01:21, Chris Wilson wrote:
>
> The flags passed to the wait_entry.func are passed onwards to
> try_to_wake_up(), which has a very particular interpretation for its
> wake_flags. In particular, beyond the published WF_SYNC, it has a few
> internal flags as well. Since we pass
81 matches
Mail list logo
