[Intel-gfx] [PATCH v5] drm/i915/gvt: Deliver guest cursor hotspot info

Guest OS driver uses PV info registers to deliver cursor hotspot info to host. This patch is used to get cursor hotspot info from virtual registers and deliver it to host userspace. v4->v5: - remove CI warning. v3->v4: - return UINT_MAX when x_hot/y_hot is invalid. (Zhenyu) - correct version.

Re: [Intel-gfx] [PATCH] drm/i915/oa: Disable OA on Haswell

Quoting Lionel Landwerlin (2018-05-11 16:43:02) > On 11/05/18 15:18, Chris Wilson wrote: > > Quoting Lionel Landwerlin (2018-05-11 15:14:13) > >> My understanding of the virtual memory addressing from the GPU is > >> limited... > >> But how can the GPU poke at the kernel's allocated data? > >> I

[Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()

trigger_reset() imposes a tight time constraint (2s) so that we verify that the reset itself completes quickly. In the middle of this check, we call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to clear out the freed memory (DROP_FREED). Those barriers may have unbounded latency

[Intel-gfx] [PATCH i-g-t 3/6] igt/gem_ctx_thrash: Order writes between contexts

The test wrote to the same dwords from multiple contexts, assuming that the writes would be ordered by its submission. However, as it was using multiple contexts without a write hazard, those timelines are not coupled and the requests may be emitted to hw in any order. So emit a write hazard for

Re: [Intel-gfx] [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Mark up nested spinlocks

== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4175 -> Patchwork_8993 = == Summary - WARNING == Minor unknown changes coming

Re: [Intel-gfx] [PATCH] drm/i915/psr: Nuke PSR support for VLV and CHV

On Fri, 11 May 2018, Dhinakaran Pandiyan wrote: > PSR hardware and hence the driver code for VLV and CHV deviates a lot from > their DDI counterparts. While the feature has been disabled for a long time > now, retaining support for these platforms is a maintenance

Re: [Intel-gfx] [PATCH v3 24/40] drm/i915: Implement HDCP2.2 repeater authentication

>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/gmbus: Increase the Bytes per Rd/Wr Op

On Wed, 09 May 2018, Ramalingam C wrote: > GMBUS HW supports 511Bytes as Max Bytes per single RD/WR op. Instead of > enabling the 511Bytes per RD/WR cycle on legacy platforms for no > absolute ROIs, this change allows the max bytes per op upto 511Bytes > from Gen9 onwards.

Re: [Intel-gfx] [PATCH v2] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled

On Fri, 11 May 2018, "Kumar, Abhay" wrote: > On 5/11/2018 5:33 AM, Ville Syrjälä wrote: >> On Wed, May 09, 2018 at 06:25:32PM -0700, Abhay Kumar wrote: >>> From: Ville Syrjälä >>> >>> CDCLK has to be at least twice the BLCK regardless of

[Intel-gfx] [PATCH 03/10] drm/i915: Wrap tasklet_struct for abuse

In the next few patches, we want to abuse tasklet to avoid ksoftirqd latency along critical paths. To make that abuse easily to swallow, first coat the tasklet in a little syntactic sugar. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 06/10] drm/i915/execlists: Direct submission from irq handler

Continuing the theme of bypassing ksoftirqd latency, also first try to directly submit from the CS interrupt handler to clear the ELSP and queue the next. In the past, we have been hesitant to do this as the context switch processing has been quite heavy, requiring forcewaked mmio. However, as we

[Intel-gfx] [PATCH 05/10] drm/i915/execlists: Direct submit onto idle engines

Bypass using the tasklet to submit the first request to HW, as the tasklet may be deferred unto ksoftirqd and at a minimum will add in excess of 10us (and maybe tens of milliseconds) to our execution latency. This latency reduction is most notable when execution flows between engines. v2: Beware

[Intel-gfx] [PATCH 09/10] drm/i915: Speed up idle detection by kicking the tasklets

We rely on ksoftirqd to run in a timely fashion in order to drain the execlists queue. Quite frequently, it does not. In some cases we may see latencies of over 200ms triggering our idle timeouts and forcing us to declare the driver wedged! Thus we can speed up idle detection by bypassing

[Intel-gfx] [PATCH 02/10] drm/i915: Remove tasklet flush before disable

The idea was to try and let the existing tasklet run to completion before we began the reset, but it involves a racy check against anything else that tries to run the tasklet. Rather than acknowledge and ignore the race, let it be and don't try and be too clever. The tasklet will resume execution

[Intel-gfx] Direct execlists submission

Continuing the discussion with the latest refactorings, however I ran some tests to measure the impact on system (!i915) latency, using igt/benchmarks/gem_syslatency -t 120 drm-tip: latency mean=1.211us max=10us (no load) latency mean=2.611us max=83us (i915) latency

[Intel-gfx] [PATCH 07/10] drm/i915: Rearrange gen8_cs_irq_handler

After using direct submission from the irq handler, it is very likely that the ENGINE_IRQ_EXECLISTS bit is unset and so we do not need to test it first. It also follows that we then want to do a direct submission evertime the irq_posted bit is set, and can use that as our boolean rather than a

[Intel-gfx] [PATCH 04/10] drm/i915: Only sync tasklets once for recursive reset preparation

When setting up reset, we may need to recursively prepare an engine. In which case we should only synchronously flush the tasklets on the outer most call, the inner calls will then be inside an atomic section where the tasklet will never be run (and so the sync will never complete).

Re: [Intel-gfx] Direct execlists submission

On 14/05/2018 10:37, Chris Wilson wrote: Continuing the discussion with the latest refactorings, however I ran some tests to measure the impact on system (!i915) latency, using igt/benchmarks/gem_syslatency -t 120 drm-tip: latency mean=1.211us max=10us (no load) latency

[Intel-gfx] [PATCH i-g-t 6/6] tests/gem_exec_latency: New subtests for checking submission from RT tasks

From: Tvrtko Ursulin We want to make sure RT tasks which use a lot of CPU times can submit batch buffers with roughly the same latency (and certainly not worse) compared to normal tasks. v2: Add tests to run across all engines simultaneously to encourage ksoftirqd to

[Intel-gfx] [PATCH i-g-t 2/6] lib/audio: Replace sqrt(a*a + b*b) with hypot(a, b)

Signed-off-by: Chris Wilson --- lib/igt_audio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/lib/igt_audio.c b/lib/igt_audio.c index 2321d1c6e..229ce6c69 100644 --- a/lib/igt_audio.c +++ b/lib/igt_audio.c @@ -266,9 +266,7 @@ bool

[Intel-gfx] [PATCH i-g-t 1/6] overlay: Remove the miscalculation of window position

We already call x11_position() to calculate the position of the overlay, so do not need to manually recompute them inside x11_overlay_create(). This has the advantage that x11_position() understands the multi-monitor layout instructions. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH i-g-t 4/6] igt/gem_eio: Exercise banning

If we trigger "too many" resets, the context and even the file, will be banend and subsequent execbufs should fail with -EIO. Signed-off-by: Chris Wilson --- tests/gem_eio.c | 49 + 1 file changed, 49 insertions(+) diff

[Intel-gfx] [PATCH 08/10] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler

Store whether or not we need to kick the guc's execlists emulation on the engine itself to avoid chasing the device info. gen8_cs_irq_handler 512 428 -84 Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 2

[Intel-gfx] [PATCH 01/10] drm/i915: Mark up nested spinlocks

When we process the outstanding requests upon banning a context, we need to acquire both the engine and the client's timeline, nesting the locks. This requires explicit markup as the two timelines are now of the same class, since commit a89d1f921c15 ("drm/i915: Split i915_gem_timeline into

[Intel-gfx] [PATCH 10/10] drm/i915: Detect if we missed kicking the execlists tasklet

If inside hangcheck we see that the engine has paused, but there is an execlists interrupt still pending, we know that the tasklet did not fire. Dump the GEM trace along with the current engine state, and kick the tasklet to recovery without having to go through a GPU reset. Signed-off-by: Chris

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/10] drm/i915: Mark up nested spinlocks

== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Mark up nested spinlocks Okay! Commit: drm/i915: Remove tasklet flush

Re: [Intel-gfx] [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Relax CSB force-mmio for VT-d

Chris Wilson writes: > Quoting Chris Wilson (2018-05-11 13:11:47) >> The original switch to use CSB from the HWSP was plagued by the effort >> of read ordering on VT-d; we would read the WRITE pointer from the HWSP >> before it had completed writing the CSB contents.

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Mark up nested spinlocks

On 14/05/2018 10:37, Chris Wilson wrote: When we process the outstanding requests upon banning a context, we need to acquire both the engine and the client's timeline, nesting the locks. This requires explicit markup as the two timelines are now of the same class, since commit a89d1f921c15

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: Deliver guest cursor hotspot info (rev3)

== Series Details == Series: drm/i915/gvt: Deliver guest cursor hotspot info (rev3) URL : https://patchwork.freedesktop.org/series/41727/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4172 -> Patchwork_8992 = == Summary - WARNING == Minor unknown changes coming with

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: Deliver guest cursor hotspot info (rev3)

== Series Details == Series: drm/i915/gvt: Deliver guest cursor hotspot info (rev3) URL : https://patchwork.freedesktop.org/series/41727/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4172_full -> Patchwork_8992_full = == Summary - WARNING == Minor unknown changes

Re: [Intel-gfx] [PULL] gvt-next for 4.18

On Mon, 14 May 2018, Zhi Wang wrote: > The following changes since commit 0c79f9cb77eae28d48a4f9fc1b3341aacbbd260c: > >drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (2018-05-13 > 10:29:44 +0100) > > are available in the git repository at: > >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/10] drm/i915: Mark up nested spinlocks

== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : warning == Summary == $ dim checkpatch origin/drm-tip c01ec3ff8d8e drm/i915: Mark up nested spinlocks 677445fc5fa2 drm/i915: Remove

Re: [Intel-gfx] [PATCH 3/3] drm/i915/execlists: Relax CSB force-mmio for VT-d

Quoting Mika Kuoppala (2018-05-14 09:33:23) > Chris Wilson writes: > > > Quoting Chris Wilson (2018-05-11 13:11:47) > >> The original switch to use CSB from the HWSP was plagued by the effort > >> of read ordering on VT-d; we would read the WRITE pointer from the HWSP >

Re: [Intel-gfx] [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Ramalingam C >Sent: Tuesday, April 3, 2018 7:28 PM >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >seanp...@chromium.org; dan...@ffwll.ch; ch...@chris-wilson.co.uk;

Re: [Intel-gfx] [PATCH i-g-t 3/6] igt/gem_ctx_thrash: Order writes between contexts

On 14/05/2018 09:02, Chris Wilson wrote: The test wrote to the same dwords from multiple contexts, assuming that the writes would be ordered by its submission. However, as it was using multiple contexts without a write hazard, those timelines are not coupled and the requests may be emitted to

Re: [Intel-gfx] [PATCH v12 07/17] drm/i915/guc/slpc: Send RESET event to restart/enable SLPC tasks

On Fri, 30 Mar 2018 10:31:52 +0200, Sagar Arun Kamble wrote: Host to GuC actions for SLPC receive additional data as output through scratch registers currently. intel_guc_send_and_receive handles this. We need to define SLPC specific Host to GuC send action

Re: [Intel-gfx] [PATCH v12 10/17] drm/i915/guc/slpc: Add parameter set/unset/get, task control/status functions

On Fri, 30 Mar 2018 10:31:55 +0200, Sagar Arun Kamble wrote: SLPC behavior can be changed through set of parameters. These parameters can be updated and queried from i915 though Host to GuC SLPC events. This patch adds parameter update events for

Re: [Intel-gfx] [PATCH i-g-t 2/6] lib/audio: Replace sqrt(a*a + b*b) with hypot(a, b)

On 14/05/2018 09:02, Chris Wilson wrote: Signed-off-by: Chris Wilson --- lib/igt_audio.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/lib/igt_audio.c b/lib/igt_audio.c index 2321d1c6e..229ce6c69 100644 --- a/lib/igt_audio.c +++

Re: [Intel-gfx] [PATCH] drm/i915: Mark up nested spinlocks

Quoting Chris Wilson (2018-05-14 11:43:44) > Quoting Chris Wilson (2018-05-12 09:49:57) > > When we process the outstanding requests upon banning a context, we need > > to acquire both the engine and the client's timeline, nesting the locks. > > This requires explicit markup as the two timelines

[Intel-gfx] [PATCH i-g-t] benchmarks/gem_syslatency: Pass a write hazard around

Extend the i915 load to (optionally) pass a write hazard between engines, causing us to wait on the interrupt between engines. Thus adding MI_USER_INTERRUPT irq handling to our list of sins. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin ---

Re: [Intel-gfx] [PATCH i-g-t 4/6] igt/gem_eio: Exercise banning

On 14/05/2018 09:02, Chris Wilson wrote: If we trigger "too many" resets, the context and even the file, will be banend and subsequent execbufs should fail with -EIO. banned Signed-off-by: Chris Wilson --- tests/gem_eio.c | 49

Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/gem_exec_latency: New subtests for checking submission from RT tasks

Quoting Tvrtko Ursulin (2018-05-14 12:13:10) > > On 14/05/2018 09:02, Chris Wilson wrote: > > From: Tvrtko Ursulin > > > > We want to make sure RT tasks which use a lot of CPU times can submit > > batch buffers with roughly the same latency (and certainly not worse) >

Re: [Intel-gfx] [PATCH] drm/i915: Wait for PSR exit before checking for vblank evasion for an atomic update

On Sun, 29 Apr 2018, Tarun Vyas wrote: > From: Tarun Please use your full name. This will appear in git logs. > 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

Re: [Intel-gfx] [PATCH] drm/i915: Mark up nested spinlocks

Quoting Chris Wilson (2018-05-12 09:49:57) > When we process the outstanding requests upon banning a context, we need > to acquire both the engine and the client's timeline, nesting the locks. > This requires explicit markup as the two timelines are now of the same > class, since commit

[Intel-gfx] ✓ Fi.CI.BAT: success for benchmarks/gem_syslatency: Pass a write hazard around

== Series Details == Series: benchmarks/gem_syslatency: Pass a write hazard around URL : https://patchwork.freedesktop.org/series/43126/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4176 -> IGTPW_1353 = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PULL] gvt-next for 4.18

Thanks for the reminder! :) Thanks, Zhi. -Original Message- From: Nikula, Jani Sent: Monday, May 14, 2018 11:36 AM To: Wang, Zhi A ; Zhenyu Wang ; Joonas Lahtinen ; Vivi, Rodrigo

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [01/10] drm/i915: Mark up nested spinlocks

== Series Details == Series: series starting with [01/10] drm/i915: Mark up nested spinlocks URL : https://patchwork.freedesktop.org/series/43123/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4175_full -> Patchwork_8993_full = == Summary - WARNING == Minor unknown

Re: [Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()

On 14/05/2018 09:02, Chris Wilson wrote: trigger_reset() imposes a tight time constraint (2s) so that we verify that the reset itself completes quickly. In the middle of this check, we call gem_quiescent_gpu() which may invoke an rcu_barrier() or two to clear out the freed memory (DROP_FREED).

Re: [Intel-gfx] [PATCH v12 14/17] drm/i915/guc/slpc: Add debugfs support to read/write/revert the parameters

On Fri, 30 Mar 2018 10:31:59 +0200, Sagar Arun Kamble wrote: Add support to set/read parameters and unset the parameters which will revert them to default SLPC internal values. Explicit SLPC reset is needed on setting/unsetting some of the parameters. This patch

Re: [Intel-gfx] [PATCH v12 16/17] drm/i915/guc/slpc: Add SLPC banner to RPS debugfs interfaces

On Fri, 30 Mar 2018 10:32:01 +0200, Sagar Arun Kamble wrote: When SLPC is controlling frequency requests, RPS state related to autotuning is no longer valid. Make user aware through banner upfront. Value read from register RPNSWREQ likely has the frequency requested

Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/gem_exec_latency: New subtests for checking submission from RT tasks

On 14/05/2018 09:02, Chris Wilson wrote: From: Tvrtko Ursulin We want to make sure RT tasks which use a lot of CPU times can submit batch buffers with roughly the same latency (and certainly not worse) compared to normal tasks. v2: Add tests to run across all

Re: [Intel-gfx] [PATCH v12 12/17] drm/i915/guc/slpc: Add enable/disable controls for SLPC tasks

On Fri, 30 Mar 2018 10:31:57 +0200, Sagar Arun Kamble wrote: From: Tom O'Rourke Adds debugfs hooks for enabling/disabling each SLPC task. The enable/disable debugfs files are: i915_guc_slpc_gtperf, i915_guc_slpc_balancer, and

Re: [Intel-gfx] [PATCH i-g-t 1/6] overlay: Remove the miscalculation of window position

On 14/05/2018 09:02, Chris Wilson wrote: We already call x11_position() to calculate the position of the overlay, so do not need to manually recompute them inside x11_overlay_create(). This has the advantage that x11_position() understands the multi-monitor layout instructions. Signed-off-by:

Re: [Intel-gfx] Direct execlists submission

Quoting Tvrtko Ursulin (2018-05-14 11:11:54) > > On 14/05/2018 10:37, Chris Wilson wrote: > > Continuing the discussion with the latest refactorings, however I ran > > some tests to measure the impact on system (!i915) latency, > > using igt/benchmarks/gem_syslatency -t 120 > > > > drm-tip: > >

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler

Quoting Tvrtko Ursulin (2018-05-14 11:27:56) > > On 14/05/2018 10:37, Chris Wilson wrote: > > Store whether or not we need to kick the guc's execlists emulation on > > the engine itself to avoid chasing the device info. > > > > gen8_cs_irq_handler 512 428 -84 >

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/gem_eio: Exercise banning

On 12/05/18 02:03, Chris Wilson wrote: If we trigger "too many" resets, the context and even the file, will be banend and subsequent execbufs should fail with -EIO. Signed-off-by: Chris Wilson Does this replace gem_reset_stats@test_ban? Thanks, Antonio

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating (rev4)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev4) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim checkpatch origin/drm-tip d66d43edbd8d drm/i915: Program RPCS for Broadwell 61ad4a566887 drm/i915: Record the sseu

Re: [Intel-gfx] [PATCH v3 02/40] drm: HDMI and DP specific HDCP2.2 defines

On Wednesday 09 May 2018 03:36 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:27 PM To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;

Re: [Intel-gfx] [PATCH v3 01/40] drm: hdcp2.2 authentication msg definitions

Thank you for the review comments Uma Shankar! On Wednesday 09 May 2018 03:31 PM, Shankar, Uma wrote: -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:27 PM To:

[Intel-gfx] [PATCH v5 5/7] drm/i915/perf: lock powergating configuration to default when active

If some of the contexts submitting workloads to the GPU have been configured to shutdown slices/subslices, we might loose the NOA configurations written in the NOA muxes. One possible solution to this problem is to reprogram the NOA muxes when we switch to a new context. We initially tried this

[Intel-gfx] [PATCH v5 1/7] drm/i915: Program RPCS for Broadwell

From: Chris Wilson Currently we only configure the power gating for Skylake and above, but the configuration should equally apply to Broadwell and Braswell. Even though, there is not as much variation as for later generations, we want to expose control over the

[Intel-gfx] [PATCH v5 2/7] drm/i915: Record the sseu configuration per-context & engine

From: Chris Wilson We want to expose the ability to reconfigure the slices, subslice and eu per context and per engine. To facilitate that, store the current configuration on the context for each engine, which is initially set to the device default upon creation. v2:

[Intel-gfx] [PATCH v5 3/7] drm/i915/perf: simplify configure all context function

We don't need any special treatment on error so just return as soon as possible. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c

[Intel-gfx] [PATCH v5 0/7] drm/i915: per context slice/subslice powergating

Hi, This is a different approach to the perf & powergating interaction problem. In this version we basically disable powergating when i915/perf is on. We do something similar already in that we disable RC6 for similar reasons. Cheers, Chris Wilson (3): drm/i915: Program RPCS for Broadwell

[Intel-gfx] [PATCH v5 7/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

From: Chris Wilson We want to allow userspace to reconfigure the subslice configuration for its own use case. To do so, we expose a context parameter to allow adjustment of the RPCS register stored within the context image (and currently not accessible via LRI). If the

[Intel-gfx] [PATCH v5 6/7] drm/i915: count powergating transitions per engine

This can be used to monitor the number of powergating transition changes for a particular workload. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++ drivers/gpu/drm/i915/intel_lrc.c| 16 +++-

[Intel-gfx] [PATCH v5 4/7] drm/i915/perf: reuse intel_lrc ctx regs macro

Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 34 +++- 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: per context slice/subslice powergating (rev4)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev4) URL : https://patchwork.freedesktop.org/series/42285/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4178 -> Patchwork_8994 = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] Direct execlists submission

Quoting Chris Wilson (2018-05-14 11:25:45) > Quoting Tvrtko Ursulin (2018-05-14 11:11:54) > > > > On 14/05/2018 10:37, Chris Wilson wrote: > > > Continuing the discussion with the latest refactorings, however I ran > > > some tests to measure the impact on system (!i915) latency, > > > using

Re: [Intel-gfx] [PATCH i-g-t 3/6] igt/gem_ctx_thrash: Order writes between contexts

Quoting Tvrtko Ursulin (2018-05-14 11:59:09) > > On 14/05/2018 09:02, Chris Wilson wrote: > > The test wrote to the same dwords from multiple contexts, assuming that > > the writes would be ordered by its submission. However, as it was using > > multiple contexts without a write hazard, those

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/gem_eio: Exercise banning

Quoting Antonio Argenziano (2018-05-14 15:51:04) > > > On 12/05/18 02:03, Chris Wilson wrote: > > If we trigger "too many" resets, the context and even the file, will be > > banend and subsequent execbufs should fail with -EIO. > > > > Signed-off-by: Chris Wilson > >

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: per context slice/subslice powergating (rev4)

== Series Details == Series: drm/i915: per context slice/subslice powergating (rev4) URL : https://patchwork.freedesktop.org/series/42285/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Program RPCS for Broadwell Okay! Commit: drm/i915: Record the sseu

Re: [Intel-gfx] [PATCH v12 08/17] drm/i915/guc/slpc: Send SHUTDOWN event to stop SLPC tasks

On Fri, 30 Mar 2018 10:31:53 +0200, Sagar Arun Kamble wrote: From: Tom O'Rourke Send SLPC shutdown event during uc_fini_hw or prior to enabling SLPC done while communicating updated parameters in shared data. v1: Return void instead of

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Remove USES_GUC_SUBMISSION() pointer chasing from gen8_cs_irq_handler

On 14/05/2018 10:37, Chris Wilson wrote: Store whether or not we need to kick the guc's execlists emulation on the engine itself to avoid chasing the device info. gen8_cs_irq_handler 512 428 -84 Impressive, or not, depends whether you look at the saving or

Re: [Intel-gfx] [PATCH i-g-t 5/6] tests/gem_eio: Only wait-for-idle inside trigger_reset()

Quoting Tvrtko Ursulin (2018-05-14 12:03:58) > > On 14/05/2018 09:02, Chris Wilson wrote: > > trigger_reset() imposes a tight time constraint (2s) so that we verify > > that the reset itself completes quickly. In the middle of this check, we > > call gem_quiescent_gpu() which may invoke an

[Intel-gfx] Updated drm-intel-testing

Hi all, The following changes tagged drm-intel-testing-2018-05-14: drm-intel-next-2018-05-14: Last drm/i915 changes for v4.18: - NV12 enabling (Chandra, Maarten) - ICL workarounds (Oscar) - ICL basic DPLL enabling (Paulo) - GVT updates - DP link config refactoring (Jani) - Module parameter to

[Intel-gfx] [PATCH v2] 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] [PATCH 2/2] drm/i915: Un-statify psr_wait_for_idle

We have new users (follow up patch). So, un-statify it Cc: Chris Wilson Signed-off-by: Tarun Vyas --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_psr.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 3/3] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0

[Intel-gfx] [PATCH 1/3] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each

[Intel-gfx] [PATCH 2/3] drm/i915/icl: Enable WaProgramMgsrForCorrectSliceSpecificMmioReads

WaProgramMgsrForCorrectSliceSpecificMmioReads applies for Icelake as well. References: HSD#1405586840, BSID#0575 Cc: Oscar Mateo Cc: Michel Thierry Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Allow i915_gem_reset_prepare_engine to recurse

We call i915_gem_reset_prepare_engine() during reset and then upon wedging if the reset fails. Unfortunately, kthread_park and similar do not support being called recursively and so we must count the number of times we prepare for reset and only actually prepare on the outermost layer. (Similarly

Re: [Intel-gfx] [PATCH v6 09/14] drm/i915/gvt: Add 64K huge gtt support

On 8 May 2018 at 10:05, wrote: > From: Changbin Du > > Finally, this add the first huge gtt support for GVTg - 64K pages. Since > 64K page and 4K page cannot be mixed on the same page table, so we always > split a 64K entry into small 4K page. And

[Intel-gfx] [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused.

intel_pipe_update_start also needs to wait for PSR to idle out. Need some minor modifications in psr_wait_for_idle in order to reuse it. Cc: Chris Wilson Signed-off-by: Tarun Vyas --- drivers/gpu/drm/i915/intel_psr.c | 29

[Intel-gfx] [PATCH 6/8] drm/i915: Split execlists/guc reset preparations

In the next patch, we will make the execlists reset prepare callback take into account preemption by flushing the context-switch handler. This is not applicable to the GuC submission backend, so split the two into their own backend callbacks. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 5/8] drm/i915: Move engine reset prepare/finish to backends

In preparation to more carefully handling incomplete preemption during reset by execlists, we move the existing code wholesale to the backends under a couple of new reset vfuncs. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel

[Intel-gfx] [PATCH 4/8] drm/i915/execlists: Refactor out complete_preempt_context()

As a complement to inject_preempt_context(), follow up with the function to handle its completion. This will be useful should we wish to extend the duties of the preempt-context for execlists. v2: And do the same for the guc. Signed-off-by: Chris Wilson Cc: Jeff McGee

[Intel-gfx] [PATCH 2/8] drm/i915: Wrap tasklet_struct for abuse

In the next few patches, we want to abuse tasklet to avoid ksoftirqd latency along critical paths. To make that abuse easily to swallow, first coat the tasklet in a little syntactic sugar. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 3/8] drm/i915: Only sync tasklets once for recursive reset preparation

When setting up reset, we may need to recursively prepare an engine. In which case we should only synchronously flush the tasklets on the outer most call, the inner calls will then be inside an atomic section where the tasklet will never be run (and so the sync will never complete).

[Intel-gfx] [PATCH 1/8] drm/i915: Remove tasklet flush before disable

The idea was to try and let the existing tasklet run to completion before we began the reset, but it involves a racy check against anything else that tries to run the tasklet. Rather than acknowledge and ignore the race, let it be and don't try and be too clever. The tasklet will resume execution

[Intel-gfx] [PATCH 7/8] drm/i915/execlists: Flush pending preemption events during reset

Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. v2: Restore checking of use_csb_mmio on every loop, don't forget old vgpu. Signed-off-by: Chris Wilson Cc: Michał Winiarski

[Intel-gfx] [PATCH 8/8] drm/i915: Stop parking the signaler around reset

We cannot call kthread_park() from softirq context, so let's avoid it entirely during the reset. We wanted to suspend the signaler so that it would not mark a request as complete at the same time as we marked it as being in error. Instead of parking the signaling, stop the engine from advancing so

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/gem_eio: Exercise banning

On 14/05/18 08:02, Chris Wilson wrote: Quoting Antonio Argenziano (2018-05-14 15:51:04) On 12/05/18 02:03, Chris Wilson wrote: If we trigger "too many" resets, the context and even the file, will be banend and subsequent execbufs should fail with -EIO. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH] drm/i915: Allow i915_gem_reset_prepare_engine to recurse

Quoting Chris Wilson (2018-05-14 21:52:13) > We call i915_gem_reset_prepare_engine() during reset and then upon > wedging if the reset fails. Unfortunately, kthread_park and similar do > not support being called recursively and so we must count the number of > times we prepare for reset and only

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

Quoting Tarun Vyas (2018-05-14 21:49:22) > 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] [PATCH 1/2] drm/i915: Modify psr_wait_for_idle to be reused.

Quoting Tarun Vyas (2018-05-14 21:49:20) > intel_pipe_update_start also needs to wait for PSR to idle > out. Need some minor modifications in psr_wait_for_idle in > order to reuse it. > > Cc: Chris Wilson > Signed-off-by: Tarun Vyas > --- >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (rev2)

== Series Details == Series: drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk (rev2) URL : https://patchwork.freedesktop.org/series/43024/ State : failure == Summary == Applying: drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk error: Failed to merge in the changes. Using

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Clean up ADPA pipe select bits

== Series Details == Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits URL : https://patchwork.freedesktop.org/series/43151/ State : warning == Summary == $ dim checkpatch origin/drm-tip afd2d93c4687 drm/i915: Clean up ADPA pipe select bits -:32: CHECK:SPACING:

  1   2   >