[Intel-gfx] [PATCH v6 1/2] drm/i915/psr: Lockless version of psr_wait_for_idle

This is a lockless version of the exisiting psr_wait_for_idle(). We want to wait for PSR to idle out inside intel_pipe_update_start. At the time of a pipe update, we should never race with any psr enable or disable code, which is a part of crtc enable/disable. So, we can live w/o taking any psr

[Intel-gfx] [PATCH v6 2/2] drm/i915: Wait for PSR exit before checking for vblank evasion

The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then the pipe_update_start call schedules itself out to check back later. On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but lags w.r.t core kernel code, hot plugging an external display triggers tons of

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Kill useless function pointers.

== Series Details == Series: drm/i915/psr: Kill useless function pointers. URL : https://patchwork.freedesktop.org/series/45373/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4376 -> Patchwork_9418 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/psr: Kill useless function pointers.

== Series Details == Series: drm/i915/psr: Kill useless function pointers. URL : https://patchwork.freedesktop.org/series/45373/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/psr: Kill useless function pointers.

[Intel-gfx] [PATCH] drm/i915/psr: Kill useless function pointers.

At some point we introduced the function pointers on PSR code to help with VLV/CHV separation logic because it had a different HW implementation from PSR. Since all converged to HSW PSR and we dropped the VLV/CHV support, let's also kill the useless function pointers and leave the code cleaner.

Re: [Intel-gfx] [RFC] i915: make the probe asynchronous

On Mon, Jun 25, 2018 at 05:36:32PM +0200, Daniel Vetter wrote: > > > The binding with i915 from HD-audio controller is done in an async > > work invoked from the probe callback. It makes harder to deal with > > EPROBEDEFER. > > > > IMO, a saner way would be to rather wait for the component

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix assert_plane() warning on bootup with external display (rev3)

== Series Details == Series: drm/i915: Fix assert_plane() warning on bootup with external display (rev3) URL : https://patchwork.freedesktop.org/series/44909/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4376_full -> Patchwork_9417_full = == Summary - WARNING == Minor

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix assert_plane() warning on bootup with external display (rev3)

== Series Details == Series: drm/i915: Fix assert_plane() warning on bootup with external display (rev3) URL : https://patchwork.freedesktop.org/series/44909/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4376 -> Patchwork_9417 = == Summary - SUCCESS == No regressions

Re: [Intel-gfx] [PATCH] drm/dp: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

What is the status of this patch? I am hitting this issue with one of the DP 1.4 sinks where the correct values of DPCD are present at this new offset of 0x2200 else I see bad values for REV and Max_link_rate etc.. So we absolutely need this for DP 1.4 sinks. Manasi On Wed, May 16, 2018 at

[Intel-gfx] [PATCH v3] drm/i915: Fix assert_plane() warning on bootup with external display

On KBL, WHL RVPs, booting up with an external display connected, triggers below warning, when the BiOS brings up the external display too. This warning is not seen during hotplug. [3.615226] [ cut here ] [3.619829] plane 1A assertion failure (expected on, current

[Intel-gfx] [PATCH v2] drm/i915: Fix assert_plane() warning on bootup with external display

On KBL, WHL RVPs, booting up with an external display connected, triggers below warning, when the BiOS brings up the external display too. This warning is not seen during hotplug. [3.615226] [ cut here ] [3.619829] plane 1A assertion failure (expected on, current

Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Fix race in intel_psr_work()

On Sun, Jun 24, 2018 at 10:47:40PM -0700, Dhinakaran Pandiyan wrote: > Commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr > back.") switched from delayed work to the plain variant and while doing so > removed the check for work_busy() before scheduling a PSR activation. > This

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Warn for erroneous enabling of both PSR1 and PSR2.

On Sun, Jun 24, 2018 at 10:47:41PM -0700, Dhinakaran Pandiyan wrote: > Depending whether PSR1 or PSR2 was configured, we print a warning if the > corresponding control mmio indicated PSR was erroneously enabled. As > Chris pointed out, it makes more sense to check for both the mmio's > since we

Re: [Intel-gfx] [PATCH v3] drm/i915/ddi: Get AUX power domain for DP main link too

On Thu, 2018-06-21 at 21:44 +0300, Imre Deak wrote: > So far we got an AUX power domain reference only for the duration of > DP > AUX transfers. However, the following suggests that we also need > these > for main link functionality: > - The specification doesn't state whether it's needed or not

Re: [Intel-gfx] [PATCH 1/2] drm/i915/icp: Add Interrupt Support

Em Qua, 2018-06-20 às 14:36 -0700, Anusha Srivatsa escreveu: > This patch addresses Interrupts from south display engine (SDE). > > ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC. > Introduce these registers and their intended values. > > Introduce icp_irq_handler(). > > v2: > -

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Wait for PSR exit before checking for vblank evasion

On Mon, Jun 25, 2018 at 01:56:24PM +0100, Chris Wilson wrote: > Quoting Tarun Vyas (2018-06-25 08:09:18) > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then > > the pipe_update_start call schedules itself out to check back later. > > > > On ChromeOS-4.4 kernel, which is

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint

== Series Details == Series: series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint URL : https://patchwork.freedesktop.org/series/45352/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4375_full -> Patchwork_9415_full = == Summary - WARNING

Re: [Intel-gfx] [PATCH] Revert "net/sch_generic: Shut up noise"

Quoting Daniel Vetter (2018-06-25 17:07:54) > On Tue, May 29, 2018 at 09:15:22AM +0200, Daniel Vetter wrote: > > This reverts commit c5cab0d5fc9aa1cf14c7bc7ea88c80155e46e22f. > > > > Jani believes the noise is gone, so let's see whether it's really > > gone, before we drop this hack. > > > > Cc:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

Quoting Tvrtko Ursulin (2018-06-25 18:25:46) > From: Tvrtko Ursulin > > This Kconfig option was added to protect the implementation specific > internals from user expectations but so far it was mostly hassle. > > Remove it so it is possible to debug request submission on any kernel > anywhere.

[Intel-gfx] ✓ Fi.CI.IGT: success for mm, oom: distinguish blockable mode for mmu notifiers (rev4)

== Series Details == Series: mm, oom: distinguish blockable mode for mmu notifiers (rev4) URL : https://patchwork.freedesktop.org/series/45263/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373_full -> Patchwork_9413_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Populate possible_crtcs correctly

On Mon, 2018-06-25 at 14:10 +0300, Ville Syrjälä wrote: > On Thu, Jun 21, 2018 at 06:26:04PM -0700, Dhinakaran Pandiyan wrote: > > > > On Fri, 2018-06-15 at 19:49 +0300, Ville Syrjala wrote: > > > > > > From: Ville Syrjälä > > > > > > Don't advertize non-exisiting crtcs in the encoder

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RFC,1/2] drm/i915: Keep a list of probed devices

== Series Details == Series: series starting with [RFC,1/2] drm/i915: Keep a list of probed devices URL : https://patchwork.freedesktop.org/series/45353/ State : failure == Summary == Applying: drm/i915: Keep a list of probed devices Applying: drm/i915/tracing: Enable user interrupts while

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint

== Series Details == Series: series starting with [1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint URL : https://patchwork.freedesktop.org/series/45352/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4375 -> Patchwork_9415 = == Summary - WARNING ==

Re: [Intel-gfx] [PATCH] drm/i915/psr: Fix race in intel_psr_work()

On Sun, 2018-06-24 at 09:54 +0100, Chris Wilson wrote: > Quoting Dhinakaran Pandiyan (2018-06-23 05:45:06) > > > > commit 5422b37c907e ("drm/i915/psr: Kill delays when activating psr > > back.") switched from delayed work to the plain variant and while > > doing so > > remove the check for

[Intel-gfx] [RFC 1/2] drm/i915: Keep a list of probed devices

From: Tvrtko Ursulin Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 12 drivers/gpu/drm/i915/i915_drv.h | 5 + 2 files changed, 17 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index

[Intel-gfx] [RFC 2/2] drm/i915/tracing: Enable user interrupts while intel_engine_notify is active

From: Tvrtko Ursulin Keep the user interrupt enabled while intel_engine_notify tracepoint is enabled. We use tracepoint (de)registration callbacks to enable user interrupts on all devices (future proofing and avoiding ugly global pointers) and all engines. Premise is that if someone is

[Intel-gfx] [PATCH 2/2] drm/i915/tracepoints: Remove DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option

From: Tvrtko Ursulin This Kconfig option was added to protect the implementation specific internals from user expectations but so far it was mostly hassle. Remove it so it is possible to debug request submission on any kernel anywhere. This adds around 4k to default i915.ko build but should

[Intel-gfx] [PATCH 1/2] drm/i915/tracepoints: Remove i915_request_execute tracepoint

From: Tvrtko Ursulin Long time ago execute was a fence and it made sense to have a tracepoint corresponding to it. Nowadays it completely aligns either with request_ submit or request_in tracepoints and so is redundant. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_request.c |

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Block enabling FBC until flips have been completed

== Series Details == Series: series starting with [1/2] drm/i915: Block enabling FBC until flips have been completed URL : https://patchwork.freedesktop.org/series/45349/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4375 -> Patchwork_9414 = == Summary - FAILURE ==

[Intel-gfx] [PULL] drm-intel-next

Hi Dave, Here goes another pull request for 4.19. Highlights here to Ice Lake Display enabling, and to preparation for full-ppgtt enabling for older gens, and to hangcheck and gpu reset improvements in general. drm-intel-next-2018-06-20: Chris is doing many reworks that allow us to get

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Block enabling FBC until flips have been completed

== Series Details == Series: series starting with [1/2] drm/i915: Block enabling FBC until flips have been completed URL : https://patchwork.freedesktop.org/series/45349/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Block enabling FBC until flips have been

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Block enabling FBC until flips have been completed

== Series Details == Series: series starting with [1/2] drm/i915: Block enabling FBC until flips have been completed URL : https://patchwork.freedesktop.org/series/45349/ State : warning == Summary == $ dim checkpatch origin/drm-tip 155e8eaf0d4b drm/i915: Block enabling FBC until flips have

[Intel-gfx] [PATCH 2/2] drm/i915: Remove delayed FBC activation.

The only time we should start FBC is when we have waited a vblank after the atomic update. We've already forced a vblank wait by doing wait_for_flip_done before intel_post_plane_update(), so we don't need to wait a second time before enabling. Removing the worker simplifies the code and removes

[Intel-gfx] [PATCH 1/2] drm/i915: Block enabling FBC until flips have been completed

There is a small race window in which FBC can be enabled after pre_plane_update is called, but before the page flip has been queued or completed. Signed-off-by: Maarten Lankhorst Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103167 --- drivers/gpu/drm/i915/i915_drv.h | 1 +

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Context objects can never be active when freed

Quoting Tvrtko Ursulin (2018-06-25 11:42:27) > > On 25/06/2018 11:06, Chris Wilson wrote: > > Due to how we only release the pining on the context state on > > retirement and never track activity on the context vma itself, the > > object can never be active at the point of release. Replace the >

Re: [Intel-gfx] [PATCH] drm/i915: Defer modeset cleanup to a secondary task

Quoting Chris Wilson (2018-06-25 12:00:16) > Quoting Chris Wilson (2018-06-25 11:16:58) > > Quoting Chris Wilson (2018-06-23 11:39:51) > > > If we avoid cleaning up the old state immediately in > > > intel_atomic_commit_tail() and defer it to a second task, we can avoid > > > taking heavily

Re: [Intel-gfx] [PATCH] Revert "net/sch_generic: Shut up noise"

On Tue, May 29, 2018 at 09:15:22AM +0200, Daniel Vetter wrote: > This reverts commit c5cab0d5fc9aa1cf14c7bc7ea88c80155e46e22f. > > Jani believes the noise is gone, so let's see whether it's really > gone, before we drop this hack. > > Cc: "Saarinen, Jani" > Cc: Martin Peres > Signed-off-by:

Re: [Intel-gfx] [PATCH 01/10] drm: crc: Introduce verify_crc_source callback

On Fri, Jun 22, 2018 at 04:11:25PM +0530, Mahesh Kumar wrote: > This patch adds a new callback function "verify_crc_source" which will > be used during setting the crc source in control node and while opening > data node for crc reading. This will help in avoiding setting of wrong > string for

Re: [Intel-gfx] [RFC] i915: make the probe asynchronous

On Wed, Jun 20, 2018 at 11:45:25AM +0200, Takashi Iwai wrote: > On Wed, 20 Jun 2018 10:02:42 +0200, > Daniel Vetter wrote: > > > > On Wed, Jun 20, 2018 at 10:11:34AM +0300, Jani Nikula wrote: > > > On Wed, 20 Jun 2018, Feng Tang wrote: > > > > Hi Takashi, > > > > > > > > On Wed, Jun 20, 2018 at

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/execlists: Check for ce->state before destroy

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Check for ce->state before destroy URL : https://patchwork.freedesktop.org/series/45328/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373_full -> Patchwork_9412_full = == Summary - WARNING ==

Re: [Intel-gfx] [PATCH i-g-t v2 1/7] igt: lib/igt_crc: Split out CRC functionality

On Fri, Jul 14, 2017 at 04:18:50PM +0100, Liviu Dudau wrote: > From: Brian Starkey > > Separate out the CRC code for better compartmentalisation. Should ease > the addition of more/different CRC sources in the future. > > Signed-off-by: Brian Starkey Needs adjustements to gtkdoc I assume,

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task

== Series Details == Series: series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task URL : https://patchwork.freedesktop.org/series/45325/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4373_full -> Patchwork_9411_full = == Summary - FAILURE ==

Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation

Den 18.06.2018 16.17, skrev Noralf Trønnes: This patchset adds generic fbdev emulation for drivers that supports GEM based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An API is begun to support in-kernel clients in general. Notable changes since version 1: - Rework client

[Intel-gfx] ✓ Fi.CI.BAT: success for mm, oom: distinguish blockable mode for mmu notifiers (rev4)

== Series Details == Series: mm, oom: distinguish blockable mode for mmu notifiers (rev4) URL : https://patchwork.freedesktop.org/series/45263/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373 -> Patchwork_9413 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.IGT: success for mm, oom: distinguish blockable mode for mmu notifiers (rev3)

== Series Details == Series: mm, oom: distinguish blockable mode for mmu notifiers (rev3) URL : https://patchwork.freedesktop.org/series/45263/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373_full -> Patchwork_9410_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mm, oom: distinguish blockable mode for mmu notifiers (rev4)

== Series Details == Series: mm, oom: distinguish blockable mode for mmu notifiers (rev4) URL : https://patchwork.freedesktop.org/series/45263/ State : warning == Summary == $ dim checkpatch origin/drm-tip debbcdd2c559 mm, oom: distinguish blockable mode for mmu notifiers -:17:

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

On Mon 25-06-18 10:01:03, Michal Hocko wrote: > On Fri 22-06-18 16:09:06, Felix Kuehling wrote: > > On 2018-06-22 11:24 AM, Michal Hocko wrote: > > > On Fri 22-06-18 17:13:02, Christian König wrote: > > >> Hi Michal, > > >> > > >> [Adding Felix as well] > > >> > > >> Well first of all you have a

[Intel-gfx] [PATCH i-g-t 1/2] lib: Convert spin batch constructor to a factory

In order to make adding more options easier, expose the full set of options to the caller. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- lib/igt_dummyload.c| 147 + lib/igt_dummyload.h| 42 +- tests/drv_missed_irq.c

[Intel-gfx] [PATCH i-g-t 2/2] lib: Spin fast, retire early

When using the pollable spinner, we often want to use it as a means of ensuring the task is running on the GPU before switching to something else. In which case we don't want to add extra delay inside the spinner, but the current 1000 NOPs add on order of 5us, which is often larger than the target

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Wait for PSR exit before checking for vblank evasion

Quoting Tarun Vyas (2018-06-25 08:09:18) > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then > the pipe_update_start call schedules itself out to check back later. > > On ChromeOS-4.4 kernel, which is fairly up-to-date w.r.t drm/i915 but > lags w.r.t core kernel code, hot

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/6] kms_writeback: Add initial writeback tests

Op 01-03-18 om 18:38 schreef Liviu Dudau: > From: Brian Starkey > > Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and > WRITEBACK_FB_ID properties on writeback connectors, ensuring their > behaviour is correct. > > Signed-off-by: Brian Starkey > --- > lib/igt_kms.c

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/6] lib/igt_kms: Add writeback support in lib/

Op 01-03-18 om 18:38 schreef Liviu Dudau: > From: Brian Starkey > > Add support in igt_kms for Writeback connectors, with the ability to > attach framebuffers and retrieve fences. > > Signed-off-by: Brian Starkey > --- > lib/igt_kms.c | 72 >

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v5,1/2] drm/i915/psr: Lockless version of psr_wait_for_idle

== Series Details == Series: series starting with [v5,1/2] drm/i915/psr: Lockless version of psr_wait_for_idle URL : https://patchwork.freedesktop.org/series/45319/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4372_full -> Patchwork_9409_full = == Summary - FAILURE ==

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/crt: make intel_crt_reset() static again

== Series Details == Series: drm/i915/crt: make intel_crt_reset() static again URL : https://patchwork.freedesktop.org/series/45167/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4372_full -> Patchwork_9408_full = == Summary - WARNING == Minor unknown changes coming

Re: [Intel-gfx] [PATCH 10/14] drm/i915: Populate possible_crtcs correctly

On Thu, Jun 21, 2018 at 06:26:04PM -0700, Dhinakaran Pandiyan wrote: > On Fri, 2018-06-15 at 19:49 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Don't advertize non-exisiting crtcs in the encoder possible_crtcs > > bitmask. > > > How do we end up advertising non-existing CRTCs?

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Check for ce->state before destroy

== Series Details == Series: series starting with [1/2] drm/i915/execlists: Check for ce->state before destroy URL : https://patchwork.freedesktop.org/series/45328/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373 -> Patchwork_9412 = == Summary - SUCCESS == No

Re: [Intel-gfx] [PATCH] drm/i915: Defer modeset cleanup to a secondary task

Quoting Chris Wilson (2018-06-25 11:16:58) > Quoting Chris Wilson (2018-06-23 11:39:51) > > If we avoid cleaning up the old state immediately in > > intel_atomic_commit_tail() and defer it to a second task, we can avoid > > taking heavily contended locks when the caller is ready to procede. > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task

== Series Details == Series: series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task URL : https://patchwork.freedesktop.org/series/45325/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373 -> Patchwork_9411 = == Summary - SUCCESS == No

[Intel-gfx] ✓ Fi.CI.BAT: success for mm, oom: distinguish blockable mode for mmu notifiers (rev3)

== Series Details == Series: mm, oom: distinguish blockable mode for mmu notifiers (rev3) URL : https://patchwork.freedesktop.org/series/45263/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4373 -> Patchwork_9410 = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH 03/31] drm/i915/execlists: Pull submit after dequeue under timeline lock

Quoting Tvrtko Ursulin (2018-06-25 11:51:30) > > On 25/06/2018 10:48, Chris Wilson wrote: > > In the next patch, we will begin processing the CSB from inside the > > submission path (underneath an irqsoff section, and even from inside > > interrupt handlers). This means that updating the

Re: [Intel-gfx] [PATCH 03/31] drm/i915/execlists: Pull submit after dequeue under timeline lock

On 25/06/2018 10:48, Chris Wilson wrote: In the next patch, we will begin processing the CSB from inside the submission path (underneath an irqsoff section, and even from inside interrupt handlers). This means that updating the execlists->port[] will no longer be serialised by the tasklet but

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task

== Series Details == Series: series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task URL : https://patchwork.freedesktop.org/series/45325/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Defer modeset cleanup to a secondary task Okay!

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Context objects can never be active when freed

On 25/06/2018 11:06, Chris Wilson wrote: Due to how we only release the pining on the context state on retirement and never track activity on the context vma itself, the object can never be active at the point of release. Replace the conditional transfer of ownership onto an active-reference

Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Check for ce->state before destroy

On 25/06/2018 11:06, Chris Wilson wrote: As we may cancel the ce->state allocation during context pinning (but crucially after we mark ce as operational), that means we may be asked to destroy a nonexistent ce->state. Given the choice in handing a complex error path on pinning, and just

Re: [Intel-gfx] [PATCH V2] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.

On Wed, Jun 13, 2018 at 02:48:49PM -0700, clinton.a.tay...@intel.com wrote: > From: Clint Taylor > > On GLK NUC platforms the HDMI retiming buffer needs additional disabled > time to correctly sync to a faster incoming signal. > > When measured on a scope the highspeed lines of the HDMI clock

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task

== Series Details == Series: series starting with [01/31] drm/i915: Defer modeset cleanup to a secondary task URL : https://patchwork.freedesktop.org/series/45325/ State : warning == Summary == $ dim checkpatch origin/drm-tip a3ac02da008c drm/i915: Defer modeset cleanup to a secondary task

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mm, oom: distinguish blockable mode for mmu notifiers (rev3)

== Series Details == Series: mm, oom: distinguish blockable mode for mmu notifiers (rev3) URL : https://patchwork.freedesktop.org/series/45263/ State : warning == Summary == $ dim checkpatch origin/drm-tip c36cf27f4057 mm, oom: distinguish blockable mode for mmu notifiers -:16:

Re: [Intel-gfx] [PATCH] drm/i915: Defer modeset cleanup to a secondary task

Quoting Chris Wilson (2018-06-23 11:39:51) > If we avoid cleaning up the old state immediately in > intel_atomic_commit_tail() and defer it to a second task, we can avoid > taking heavily contended locks when the caller is ready to procede. > Subsequent modesets will wait for the cleanup operation

[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Check for ce->state before destroy

As we may cancel the ce->state allocation during context pinning (but crucially after we mark ce as operational), that means we may be asked to destroy a nonexistent ce->state. Given the choice in handing a complex error path on pinning, and just ignoring the lack of state in destroy, choice the

[Intel-gfx] [PATCH 2/2] drm/i915: Context objects can never be active when freed

Due to how we only release the pining on the context state on retirement and never track activity on the context vma itself, the object can never be active at the point of release. Replace the conditional transfer of ownership onto an active-reference with an assert that the object is idle.

[Intel-gfx] [PATCH 31/31] drm/i915: Remove GPU reset dependence on struct_mutex

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

[Intel-gfx] [PATCH 30/31] drm/i915: Pull all the reset functionality together into i915_reset.c

Currently the code to reset the GPU and our state is spread widely across a few files. Pull the logic together into a common file. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile |3 +- drivers/gpu/drm/i915/i915_debugfs.c |2 +

[Intel-gfx] [PATCH 29/31] drm/i915: Tidy i915_gem_suspend()

In the next patch, we will make a fairly minor change to flush outstanding resets before suspend. In order to keep churn to a minimum in that functional patch, we fix up the comments and coding style now. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 50

[Intel-gfx] [PATCH 26/31] drm/i915: Introduce i915_address_space.mutex

Add a mutex into struct i915_address_space to be used while operating on the vma and their lists for a particular vm. As this may be called from the shrinker, we taint the mutex with fs_reclaim so that from the start lockdep warns us if we are caught holding the mutex across an allocation. (With

[Intel-gfx] [PATCH 28/31] drm/i915: Convert fences to use a GGTT lock rather than struct_mutex

Introduce a new mutex to guard all of the vma operations within a vm (as opposed to the BKL struct_mutex) and start by using it to guard the fence operations for a GGTT VMA. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 2 +- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 24/31] drm/i915: Track the last-active inside the i915_vma

Using a VMA on more than one timeline concurrently is the exception rather than the rule (using it concurrently on multiple engines). As we expect to only use one active tracker, store the most recently used tracker inside the i915_vma itself and only fallback to the radixtree if we need a second

[Intel-gfx] [PATCH 22/31] drm/i915: Start returning an error from i915_vma_move_to_active()

Handling such a late error in request construction is tricky, but to accommodate future patches which may allocate here, we potentially could err. To handle the error after already adjusting global state to track the new request, we must finish and submit the request. But we don't want to use the

[Intel-gfx] [PATCH 25/31] drm/i915: Stop tracking MRU activity on VMA

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

[Intel-gfx] [PATCH 07/31] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)

Back in commit 27af5eea54d1 ("drm/i915: Move execlists irq handler to a bottom half"), we came to the conclusion that running our CSB processing and ELSP submission from inside the irq handler was a bad idea. A really bad idea as we could impose nearly 1s latency on other users of the system, on

[Intel-gfx] [PATCH 14/31] drm/i915: Only signal from interrupt when requested

Avoid calling dma_fence_signal() from inside the interrupt if we haven't enabled signaling on the request. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 8 ++-- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 5 ++--- 3

[Intel-gfx] [PATCH 23/31] drm/i915: Track vma activity per fence.context, not per engine

In the next patch, we will want to be able to use more flexible request timelines that can hop between engines. From the vma pov, we can then not rely on the binding of this request to an engine and so can not ensure that different requests are ordered through a per-engine timeline, and so we must

[Intel-gfx] [PATCH 06/31] drm/i915/execlists: Unify CSB access pointers

Following the removal of the last workarounds, the only CSB mmio access is for the old vGPU interface. The mmio registers presented by vGPU do not require forcewake and can be treated as ordinary volatile memory, i.e. they behave just like the HWSP access just at a different location. We can

[Intel-gfx] [PATCH 27/31] drm/i915: Move fence register tracking to GGTT

As the fence registers define special regions of the mappable aperture inside the Global GTT, and we track those regions using GGTT VMA, it makes sense to pull that bookkeeping under i915_ggtt. The advantage is that we can then start using a local GGTT lock to handle the fence registers (in

[Intel-gfx] [PATCH 20/31] drm/i915: Refactor export_fence() after i915_vma_move_to_active()

Currently all callers are responsible for adding the vma to the active timeline and then exporting its fence. Combine the two operations into i915_vma_move_to_active() to move all the extra handling from the callers to the single site. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 21/31] drm/i915: Export i915_request_skip()

In the next patch, we will want to start skipping requests on failing to complete their payloads. So export the utility function current used to make requests inoperable following a failed gpu reset. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 25

[Intel-gfx] [PATCH 05/31] drm/i915/execlists: Process one CSB update at a time

In the next patch, we will process the CSB events directly from the submission path, rather than only after a CS interrupt. Hence, we will no longer have the need for a loop until the has-interrupt bit is clear, and in the meantime can remove that small optimisation. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 18/31] drm/i915: Priority boost for new clients

Taken from an idea used for FQ_CODEL, we give new request flows a priority boost. These flows are likely to correspond with interactive tasks and so be more latency sensitive than the long queues. As soon as the client has more than one request in the queue, further requests are not boosted and it

[Intel-gfx] [PATCH 12/31] drm/i915: Reduce spinlock hold time during notify_ring() interrupt

By taking advantage of the RCU protection of the task struct, we can find the appropriate signaler under the spinlock and then release the spinlock before waking the task and signaling the fence. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 33

[Intel-gfx] [PATCH 11/31] drm/i915: Hold request reference for submission until retirement

Currently the async submission backends (guc and execlists) hold a extra reference to the requests being processed as they are not serialised with request retirement. If we instead, prevent the request being dropped from the engine timeline until after submission has finished processing the

[Intel-gfx] [PATCH 17/31] drm/i915: Combine multiple internal plists into the same i915_priolist bucket

As we are about to allow ourselves to slightly bump the user priority into a few different sublevels, packthose internal priority lists into the same i915_priolist to keep the rbtree compact and avoid having to allocate the default user priority even after the internal bumping. The downside to

[Intel-gfx] [PATCH 19/31] drm/i915: Priority boost switching to an idle ring

In order to maximise concurrency between engines, if we queue a request to a current idle ring, reorder its dependencies to execute that request as early as possible and ideally improve occupancy of multiple engines simultaneously. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 10/31] drm/i915: Move engine request retirement to intel_engine_cs

In the next patch, we will move ownership of the fence reference to the submission backend and will want to drop its final reference when retiring it from the submission backend. We will also need a catch up when parking the engine to cleanup any residual entries in the engine timeline. In short,

[Intel-gfx] [PATCH 13/31] drm/i915: Move the irq_counter inside the spinlock

Rather than have multiple locked instructions inside the notify_ring() irq handler, move them inside the spinlock and reduce their intrinsic locking. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 4 ++-- drivers/gpu/drm/i915/i915_request.c | 4 ++--

[Intel-gfx] [PATCH 16/31] drm/i915: Reserve some priority bits for internal use

In the next few patches, we will want to give a small priority boost to some requests/queues but not so much that we perturb the user controlled order. As such we shift the user priority bits higher leaving ourselves a few low priority bits for our bumping. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 15/31] drm/i915/execlists: Switch to rb_root_cached

The kernel recently gained an augmented rbtree with the purpose of cacheing the leftmost element of the rbtree, a frequent optimisation to avoid calls to rb_first() which is also employed by the execlists->queue. Switch from our open-coded cache to the library. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 01/31] drm/i915: Defer modeset cleanup to a secondary task

If we avoid cleaning up the old state immediately in intel_atomic_commit_tail() and defer it to a second task, we can avoid taking heavily contended locks when the caller is ready to procede. Subsequent modesets will wait for the cleanup operation (either directly via the ordered modeset wq or

[Intel-gfx] [PATCH 08/31] drm/i915: Move rate-limiting request retire to after submission

Our long standing defense against a single client from flooding the system with requests (causing mempressure and stalls across the whole system) is to retire the old request on every allocation. (By retiring the oldest, we try to keep returning requests back to the system in a steady flow.) This

[Intel-gfx] [PATCH 04/31] drm/i915/execlists: Pull CSB reset under the timeline.lock

In the following patch, we will process the CSB events under the timeline.lock and not serailiased by the tasklet. This also means that we will need to protect access to common variables such as execlists->csb_head with the timeline.lock during reset. v2: Move sync_irq to avoid deadlocks between

[Intel-gfx] [PATCH 09/31] drm/i915: Wait for engines to idle before retiring

In the next patch, we will start to defer retiring the request from the engine list if it is still active on the submission backend. To preserve the semantics that after wait-for-idle completes the system is idle and fully retired, we need to therefore wait for the backends to idle before calling

[Intel-gfx] [PATCH 03/31] drm/i915/execlists: Pull submit after dequeue under timeline lock

In the next patch, we will begin processing the CSB from inside the submission path (underneath an irqsoff section, and even from inside interrupt handlers). This means that updating the execlists->port[] will no longer be serialised by the tasklet but needs to be locked by the

  1   2   >