[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/atomic: Reject properties not part of the object.

== Series Details == Series: drm/atomic: Reject properties not part of the object. URL : https://patchwork.freedesktop.org/series/11993/ State : failure == Summary == Series 11993v1 drm/atomic: Reject properties not part of the object.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Try harder to reset the gen8+ engines

== Series Details == Series: drm/i915: Try harder to reset the gen8+ engines URL : https://patchwork.freedesktop.org/series/11998/ State : success == Summary == Series 11998v1 drm/i915: Try harder to reset the gen8+ engines

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Use new CRC debugfs API

On 5 September 2016 at 14:44, Emil Velikov wrote: > On 5 September 2016 at 10:45, Tomeu Vizoso wrote: >> On 2 September 2016 at 17:18, Emil Velikov wrote: >>> Hi Tomeu, >>> >>> IMHO it would be better to split out

[Intel-gfx] [PATCH] drm/i915: Try harder to reset the gen8+ engines

If at first we don't succeed, try again. Running the reset and recovery routines in a loop ends in a "reset request timeout" with a mtbf of an hour on Braswell. This is eerily similar to the unrecoverable reset condition that first prompted us to use the reset-request mechanism in commit

[Intel-gfx] [PATCH v5 1/4] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. Signed-off-by: Tomeu Vizoso ---

[Intel-gfx] [PATCH v5 3/4] drm/i915: Use new CRC debugfs API

The core provides now an ABI to userspace for generation of frame CRCs, so implement the ->set_crc_source() callback and reuse as much code as possible with the previous ABI implementation. v2: - Leave the legacy implementation in place as the ABI implementation in the core is

[Intel-gfx] [PATCH v5 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

Use drm_accurate_vblank_count so we have the full 32 bit to represent the frame counter and userspace has a simpler way of knowing when the counter wraps around. Signed-off-by: Tomeu Vizoso --- drivers/gpu/drm/i915/i915_irq.c | 6 +++--- 1 file changed, 3

Re: [Intel-gfx] [PATCH xf86-video-intel] uxa: only call intel_sync_close when built with HAVE_DRI3

On Mon, Sep 05, 2016 at 10:04:33AM +0100, Chris Wilson wrote: > On Fri, Sep 02, 2016 at 08:58:22PM +1000, Jonathan Gray wrote: > > Avoid calling a function only built with dri3, fixes an undefined > > symbol crash when opting into uxa reported by Walter Alejandro Iglesias > > when running OpenBSD.

Re: [Intel-gfx] [PATCH xf86-video-intel] uxa: only call intel_sync_close when built with HAVE_DRI3

On Mon, Sep 05, 2016 at 09:10:02PM +1000, Jonathan Gray wrote: > On Mon, Sep 05, 2016 at 10:04:33AM +0100, Chris Wilson wrote: > > On Fri, Sep 02, 2016 at 08:58:22PM +1000, Jonathan Gray wrote: > > > Avoid calling a function only built with dri3, fixes an undefined > > > symbol crash when opting

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Use new CRC debugfs API

On 2 September 2016 at 17:18, Emil Velikov wrote: > Hi Tomeu, > > IMHO it would be better to split out the refactoring into preparatory > patch. It brings a minor change which (not 100% sure on that) should > not cause issues but is worth pointing out. I think at this

Re: [Intel-gfx] [PATCH 0/4] Backported vlv fixes for 4.7.y

On Mon, Aug 29, 2016 at 05:27:38PM -0400, Lyude Paul wrote: > drm/i915/vlv: Make intel_crt_reset() per-encoder: > 4570d833390b10043d082fe535375d4a0e071d9c > drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init(): > 4c732e6ee9e71903934d75b12a021eb3520b6197 > drm/i915/vlv: Disable HPD in

Re: [Intel-gfx] [PATCH xf86-video-intel] uxa: only call intel_sync_close when built with HAVE_DRI3

On Fri, Sep 02, 2016 at 08:58:22PM +1000, Jonathan Gray wrote: > Avoid calling a function only built with dri3, fixes an undefined > symbol crash when opting into uxa reported by Walter Alejandro Iglesias > when running OpenBSD. > > Signed-off-by: Jonathan Gray > --- >

[Intel-gfx] [PATCH v5 0/4] New debugfs API for capturing CRC of frames

Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers

Re: [Intel-gfx] [PATCH v4 3/4] drm/i915: Use new CRC debugfs API

On 5 September 2016 at 10:45, Tomeu Vizoso wrote: > On 2 September 2016 at 17:18, Emil Velikov wrote: >> Hi Tomeu, >> >> IMHO it would be better to split out the refactoring into preparatory >> patch. It brings a minor change which (not 100%

[Intel-gfx] [PATCH 19/21] drm/i915: Serialise execbuf operation after a dma-buf reservation object

Now that we can wait upon fences before emitting the request, it becomes trivial to wait upon any implicit fence provided by the dma-buf reservation object. Testcase: igt/prime_vgem/fence-wait Signed-off-by: Chris Wilson Reviewed-by: John Harrison

[Intel-gfx] [PATCH 06/21] drm/i915: Simplify ELSP queue request tracking

Emulate HW to track and manage ELSP queue. A set of SW ports are defined and requests are assigned to these ports before submitting them to HW. This helps in cleaning up incomplete requests during reset recovery easier especially after engine reset by decoupling elsp queue management. This will

[Intel-gfx] [PATCH 07/21] drm/i915: Separate out reset flags from the reset counter

In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this is solved by advancing the seqno so that a

[Intel-gfx] [PATCH 10/21] drm/i915: Mark up all locked waiters

In the next patch we want to handle reset directly by a locked waiter in order to avoid issues with returning before the reset is handled. To handle the reset, we must first know whether we hold the struct_mutex. If we do not hold the struct_mtuex we can not perform the reset, but we do not block

[Intel-gfx] [PATCH 16/21] drm/i915: Prepare object synchronisation for asynchronicity

We are about to specialize object synchronisation to enable nonblocking execbuf submission. First we make a copy of the current object synchronisation for execbuffer. The general i915_gem_object_sync() will be removed following the removal of CS flips in the near future. Signed-off-by: Chris

[Intel-gfx] [PATCH 20/21] drm/i915: Enable userspace to opt-out of implicit fencing

Userspace is faced with a dilemma. The kernel requires implicit fencing to manage resource usage (we always must wait for the GPU to finish before releasing its PTE) and for third parties. However, userspace may wish to avoid this serialisation if it is either using explicit fencing between

[Intel-gfx] [PATCH 21/21] drm/i915: Support explicit fencing for execbuf

Now that the user can opt-out of implicit fencing, we need to give them back control over the fencing. We employ sync_file to wrap our drm_i915_gem_request and provide an fd that userspace can merge with other sync_file fds and pass back to the kernel to wait upon before future execution.

[Intel-gfx] [PATCH 14/21] drm/i915: Drive request submission through fence callbacks

Drive final request submission from a callback from the fence. This way the request is queued until all dependencies are resolved, at which point it is handed to the backend for queueing to hardware. At this point, no dependencies are set on the request, so the callback is immediate. A

[Intel-gfx] [PATCH 15/21] drm/i915: Reorder i915_add_request to separate the phases better

Let's avoid mixing sealing the hardware commands for the request and adding the request to the software tracking. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 28 ++-- 1 file changed, 14 insertions(+), 14

[Intel-gfx] [PATCH 12/21] drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker

Since we have a cooperative mode now with a direct reset, we can avoid the contention on struct_mutex and instead try then sleep on the I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is cleared, all is fine. Otherwise, we sleep for a bit and try again. In the worst case we sleep for

[Intel-gfx] [PATCH 11/21] drm/i915: Perform a direct reset of the GPU from the waiter

If a waiter is holding the struct_mutex, then the reset worker cannot reset the GPU until the waiter returns. We do not want to return -EAGAIN form i915_wait_request as that breaks delicate operations like i915_vma_unbind() which often cannot be restarted easily, and returning -EIO is just as

[Intel-gfx] [PATCH 13/21] drm/i915: Update reset path to fix incomplete requests

Update reset path in preparation for engine reset which requires identification of incomplete requests and associated context and fixing their state so that engine can resume correctly after reset. The request that caused the hang will be skipped and head is reset to the start of breadcrumb. This

[Intel-gfx] [PATCH 18/21] drm/i915: Nonblocking request submission

Now that we have fences in place to drive request submission, we can employ those to queue requests after their dependencies as opposed to stalling in the middle of an execbuf ioctl. (However, we still choose to spin before enabling the IRQ as that is faster - though contentious.) v2: Do the

[Intel-gfx] [PATCH 17/21] drm/i915/guc: Prepare for nonblocking execbuf submission

Currently the presumption is that the request construction and its submission to the GuC are all under the same holding of struct_mutex. We wish to relax this to separate the request construction and the later submission to the GuC. This requires us to reserve some space in the GuC command queue

[Intel-gfx] [PATCH 08/21] drm/i915: Drop local struct_mutex around intel_init_emon[ilk]

Access to intel_init_emon() is strictly ordered by gt_powersave, using struct_mutex around it is overkill (and will conflict with the caller holding struct_mutex themselves). Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala ---

[Intel-gfx] [PATCH 05/21] drm/i915: Reorder submitting the requests to ELSP

Just rearrange the code to reduce churn in the next patch. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 76 1 file changed, 38 insertions(+), 38

[Intel-gfx] [PATCH 03/21] drm/i915: Record the position of the workarounds in the tail of the request

Rather than blindly assuming we need to advance the tail for resubmitting the request via the ELSP, record the position. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_request.h | 15 +--

[Intel-gfx] [PATCH 09/21] drm/i915: Expand bool interruptible to pass flags to i915_wait_request()

We need finer control over wakeup behaviour during i915_wait_request(), so expand the current bool interruptible to a bitmask. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_debugfs.c | 2

[Intel-gfx] [PATCH 04/21] drm/i915: Compute the ELSP register location once

Similar to the issue with reading from the context status buffer, see commit 26720ab97fea ("drm/i915: Move CSB MMIO reads out of the execlists lock"), we frequently write to the ELSP register (4 writes per interrupt) and know we hold the required spinlock and forcewake throughout. We can further

[Intel-gfx] [PATCH 02/21] drm/i915: Only queue requests during execlists submission

Leave the more complicated request dequeueing to the tasklet and instead just kick start the tasklet if we detect we are adding the first request. v2: Play around with list operators until we agree upon something Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 01/21] drm/i915: Add a sw fence for collecting up dma fences

This is really a core kernel struct in disguise until we can finally place it in kernel/. There is an immediate need for a fence collection mechanism that is more flexible than fence-array, in particular being able to easily drive request submission via events (and not just interrupt driven). The

[Intel-gfx] Non-blocking, explict fences

For Mika :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/21] drm/i915: Add a sw fence for collecting up dma fences

== Series Details == Series: series starting with [01/21] drm/i915: Add a sw fence for collecting up dma fences URL : https://patchwork.freedesktop.org/series/12007/ State : failure == Summary == Series 12007v1 Series without cover letter

[Intel-gfx] [PATCH 0/2] GVT-g guest patch for 4.8

Hi, Here're two patches for GVT-g guest to fix run against future GVT-g host driver, which try to ensure 4.8 will be ready to use for VM. thanks. Ping Gao (1): drm/i915: enable vGPU detection for all Zhi Wang (1): drm/i915: disable 48bit full PPGTT when vGPU is active

[Intel-gfx] [PATCH 2/2] drm/i915: disable 48bit full PPGTT when vGPU is active

From: Zhi Wang Disable 48bit full PPGTT on vGPU too for now. Signed-off-by: Zhi Wang Signed-off-by: Zhenyu Wang --- drivers/gpu/drm/i915/i915_gem_gtt.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff

[Intel-gfx] [PATCH 1/2] drm/i915: enable vGPU detection for all

From: Ping Gao vGPU capability is handled by GVT-g host driver, not needed to put extra HW check for vGPU detection. And we'll actually support vGPU from BDW. Signed-off-by: Ping Gao Signed-off-by: Zhenyu Wang ---

[Intel-gfx] ✗ Fi.CI.BAT: warning for GVT-g guest patch for 4.8

== Series Details == Series: GVT-g guest patch for 4.8 URL : https://patchwork.freedesktop.org/series/12026/ State : warning == Summary == Series 12026v1 GVT-g guest patch for 4.8 http://patchwork.freedesktop.org/api/1.0/series/12026/revisions/1/mbox/ Test drv_module_reload_basic:

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/21] drm/i915: Add a sw fence for collecting up dma fences

On Mon, Sep 05, 2016 at 01:59:46PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [01/21] drm/i915: Add a sw fence for collecting > up dma fences > URL : https://patchwork.freedesktop.org/series/12007/ > State : failure > > == Summary == > > Series 12007v1

[Intel-gfx] [PATCH] drm/atomic: Reject properties not part of the object.

The legacy setprop ioctl doesn't attempt to set properties that are not enumerated on the object. The atomic ioctl does, fix this by validating first. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic.c | 11 ++- 1 file changed, 10

Re: [Intel-gfx] [PATCH 14/18] drm/i915/guc: Prepare for nonblocking execbuf submission

On Fri, Sep 02, 2016 at 07:20:52PM +0100, Dave Gordon wrote: > On 30/08/16 09:18, Chris Wilson wrote: > >Currently the presumption is that the request construction and its > >submission to the GuC are all under the same holding of struct_mutex. We > >wish to relax this to separate the request

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/bxt: Broxton decoupled MMIO

== Series Details == Series: drm/i915/bxt: Broxton decoupled MMIO URL : https://patchwork.freedesktop.org/series/12028/ State : warning == Summary == Series 12028v1 drm/i915/bxt: Broxton decoupled MMIO http://patchwork.freedesktop.org/api/1.0/series/12028/revisions/1/mbox/ Test

[Intel-gfx] [PATCH] drm/i915/bxt: Broxton decoupled MMIO

Decoupled MMIO is an alternative way to access forcewake domain registers, which requires less cycles and avoids frequent software forcewake. Signed-off-by: Zhe Wang Signed-off-by: Damien Lespiau Signed-off-by: Ankitprasad Sharma

[Intel-gfx] [Regression report] Weekly regression report WW36

This week new regressions +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 97573 |