Re: [Intel-gfx] [PATCH 0/2] drm/i915/opregion: proper handling of DIDL and CADL

Op 25-08-16 om 20:56 schreef Paolo Stivanin: > Hello, > I applied these patches[1][2] to the latest kernel revision ( > 4.8.0-rc3-g61c0457) but the brightness keys are not working on my > laptop. > With the older patches from the 29th of June the brightness keys were > working correctly. > > Cheers

Re: [Intel-gfx] [PATCH] drm/i915: remove leftover for_each_intel_crtc_masked

On Thu, 2016-08-25 at 15:04 +0300, Jani Nikula wrote: > The last user of for_each_intel_crtc_masked macro was removed in > > commit 0a9ab303b87a94115e361a7f3a15d9f481bc453b > Author: Ander Conselvan de Oliveira > Date:   Tue Apr 21 17:13:04 2015 +0300 > > drm/i915: Remove all *_pipes flags f

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

This week's new regressions +---+---+++ | BugId | Summary | Created on | Bisect | +---+---+++ | 97450 | [SKL] [regression

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

== Series Details == Series: series starting with [01/17] drm/i915: Add a sw fence for collecting up dma fences URL : https://patchwork.freedesktop.org/series/11684/ State : success == Summary == Series 11684v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/11684/

Re: [Intel-gfx] [PATCH] dma-buf: Do a fast lockless check for poll with timeout=0

On Sun, Aug 28, 2016 at 09:33:54PM +0100, Chris Wilson wrote: > On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote: > > Currently we install a callback for performing poll on a dma-buf, > > irrespective of the timeout. This involves taking a spinlock, as well as > > unnecessary work, and

[Intel-gfx] [PATCH 13/17] drm/i915: Move execbuf object synchronisation to i915_gem_execbuffer

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 Wilso

[Intel-gfx] [PATCH 11/17] 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 09/17] 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 --- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_gem_request.c | 7 --- drivers/gpu/drm/i915/i915_gem_reques

[Intel-gfx] [PATCH 06/17] 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 bec

[Intel-gfx] [PATCH 15/17] 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 --- drivers/gpu/drm/i915/i915_gem_execbuffer.c

[Intel-gfx] [PATCH 14/17] 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.) Signed-off-by: C

[Intel-gfx] [PATCH 05/17] 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 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c

[Intel-gfx] Explicit fencing + nonblocking execbuf

Ran into a bit of bother with hang testing which meant pulling in a couple more patches to do request patching on reset. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/17] 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 re

[Intel-gfx] [PATCH 17/17] 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. Testcase

[Intel-gfx] [PATCH 08/17] 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 --- drivers/gpu/drm/i915/intel_pm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/driv

[Intel-gfx] [PATCH 16/17] 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 parties

[Intel-gfx] [PATCH 10/17] 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 usele

[Intel-gfx] [PATCH 12/17] 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 side-effect

[Intel-gfx] [PATCH 02/17] 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 Reviewed-by: Mika Kuoppala --- dri

[Intel-gfx] [PATCH 07/17] 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 wait

[Intel-gfx] [PATCH 03/17] 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 +-- drivers/gpu/drm/i915/intel_lrc.c| 4 ++-- 2

[Intel-gfx] [PATCH 01/17] 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 s

Re: [Intel-gfx] [PATCH] dma-buf: Do a fast lockless check for poll with timeout=0

On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote: > Currently we install a callback for performing poll on a dma-buf, > irrespective of the timeout. This involves taking a spinlock, as well as > unnecessary work, and greatly reduces scaling of poll(.timeout=0) across > multiple threads.

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf: Do a fast lockless check for poll with timeout=0

== Series Details == Series: dma-buf: Do a fast lockless check for poll with timeout=0 URL : https://patchwork.freedesktop.org/series/11679/ State : success == Summary == Series 11679v1 dma-buf: Do a fast lockless check for poll with timeout=0 http://patchwork.freedesktop.org/api/1.0/series/11

Re: [Intel-gfx] [PATCH] dma-buf: Do a fast lockless check for poll with timeout=0

On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote: > Currently we install a callback for performing poll on a dma-buf, > irrespective of the timeout. This involves taking a spinlock, as well as > unnecessary work, and greatly reduces scaling of poll(.timeout=0) across > multiple threads.

[Intel-gfx] [PATCH] dma-buf: Do a fast lockless check for poll with timeout=0

Currently we install a callback for performing poll on a dma-buf, irrespective of the timeout. This involves taking a spinlock, as well as unnecessary work, and greatly reduces scaling of poll(.timeout=0) across multiple threads. We can query whether the poll will block prior to installing the cal