[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/1] drm/i915: Move i915_gem_restore_fences to i915_gem_resume

== Series Details == Series: series starting with [1/1] drm/i915: Move i915_gem_restore_fences to i915_gem_resume URL : https://patchwork.freedesktop.org/series/31118/ State : warning == Summary == Series 31118v1 series starting with [1/1] drm/i915: Move i915_gem_restore_fences to

[Intel-gfx] [PATCH 1/1] drm/i915: Move i915_gem_restore_fences to i915_gem_resume

i915_gem_restore_fences is GEM resumption task hence it is moved to i915_gem_resume from i915_restore_state. Signed-off-by: Sagar Arun Kamble Cc: Michal Wajdeczko Cc: Michał Winiarski Cc: Chris Wilson

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Transform whitelisting WAs into a simple reg write

== Series Details == Series: drm/i915: Transform whitelisting WAs into a simple reg write URL : https://patchwork.freedesktop.org/series/31099/ State : success == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 fdo#99912

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: Do not prune the preferred mode on the panel

== Series Details == Series: drm/i915/dp: Do not prune the preferred mode on the panel URL : https://patchwork.freedesktop.org/series/31102/ State : warning == Summary == Series 31102v1 drm/i915/dp: Do not prune the preferred mode on the panel

[Intel-gfx] ✗ Fi.CI.IGT: failure for Introduce DVFS.

== Series Details == Series: Introduce DVFS. URL : https://patchwork.freedesktop.org/series/30922/ State : failure == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test gem_exec_schedule: Subgroup preempt-self-vebox:

[Intel-gfx] [PATCH] drm/i915/dp: Do not prune the preferred mode on the panel

During the mode validation, we should never prune the preferred mode that is the native mode of the eDP panel. This can result into no modes being available for the eDP connector. Cc: Jani Nikula Cc: Ville Syrjala Cc: Daniel Vetter

Re: [Intel-gfx] [PATCH] drm/i915: Transform whitelisting WAs into a simple reg write

On 28/09/17 15:40, Oscar Mateo wrote: RING_FORCE_TO_NONPRIV registers do not live in the logical context. They are simply global privileged MMIO registers that happen to be powercontext saved and restored (meaning only they can survive RC6). Therefore, there is absolutely no need to save them

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/guc : Removing enable_guc_loading module

On 09/28/2017 03:36 PM, Srivatsa, Anusha wrote: -Original Message- From: Sundaresan, Sujaritha Sent: Thursday, September 21, 2017 11:38 AM To: intel-gfx@lists.freedesktop.org Cc: Sundaresan, Sujaritha ; Wajdeczko, Michal ;

Re: [Intel-gfx] [PATCH v14 5/7] vfio: ABI for mdev display dma-buf operation

Thanks for the patch. Actually, I did the same thing in my local repo and also, I have a patch for the local Qemu repo to test it. I will send them out later. The reason why I want to propose the close IOCTL is because that the current lock (fb_obj_list_lock), cannot sync the intel_vgpu_fb_info

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/glk, cnl: Implement WaDisableScalarClockGating

== Series Details == Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating URL : https://patchwork.freedesktop.org/series/31094/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 fdo#102252

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Transform whitelisting WAs into a simple reg write

== Series Details == Series: drm/i915: Transform whitelisting WAs into a simple reg write URL : https://patchwork.freedesktop.org/series/31099/ State : success == Summary == Series 31099v1 drm/i915: Transform whitelisting WAs into a simple reg write

[Intel-gfx] [PATCH] drm/i915: Transform whitelisting WAs into a simple reg write

RING_FORCE_TO_NONPRIV registers do not live in the logical context. They are simply global privileged MMIO registers that happen to be powercontext saved and restored (meaning only they can survive RC6). Therefore, there is absolutely no need to save them so that they can be restored everytime

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/guc : Removing enable_guc_loading module

>-Original Message- >From: Sundaresan, Sujaritha >Sent: Thursday, September 21, 2017 11:38 AM >To: intel-gfx@lists.freedesktop.org >Cc: Sundaresan, Sujaritha ; Wajdeczko, Michal >; Srivatsa, Anusha ;

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

On 09/28/2017 08:00 AM, Mika Kuoppala wrote: We have no means to check write only registers as this would need access through context image. For now we know that cnl has a one such register, 0xe5f0 which is used to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting the context image

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce DVFS.

== Series Details == Series: Introduce DVFS. URL : https://patchwork.freedesktop.org/series/30922/ State : success == Summary == Series 30922v1 Introduce DVFS. https://patchwork.freedesktop.org/api/1.0/series/30922/revisions/1/mbox/ Test chamelium: Subgroup dp-crc-fast:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Add has_psr-flag to gen9lp

== Series Details == Series: drm/i915: Add has_psr-flag to gen9lp URL : https://patchwork.freedesktop.org/series/28488/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 +1 fdo#102252

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

On 09/28/2017 01:56 PM, Oscar Mateo wrote: On 09/28/2017 02:46 AM, Chris Wilson wrote: Stealing the thread for another gem_workarounds conundrum. After a reset, we lose the RING_FORCE_TO_NONPRIV registers. If they where in the context image as we presumed, the values would be retained and

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk, cnl: Implement WaDisableScalarClockGating

== Series Details == Series: drm/i915/glk, cnl: Implement WaDisableScalarClockGating URL : https://patchwork.freedesktop.org/series/31094/ State : success == Summary == Series 31094v1 drm/i915/glk, cnl: Implement WaDisableScalarClockGating

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,01/13] drm/i915: Inherit Kabylake platform features from Skylake

== Series Details == Series: series starting with [v3,01/13] drm/i915: Inherit Kabylake platform features from Skylake URL : https://patchwork.freedesktop.org/series/31092/ State : failure == Summary == Series 31092v1 series starting with [v3,01/13] drm/i915: Inherit Kabylake platform

Re: [Intel-gfx] [PATCH] drm/i915/cnl: Allow 2 pixel per clock on Cannonlake.

Em Ter, 2017-09-26 às 12:43 -0700, Rodrigo Vivi escreveu: > This is heavily based on a initial patch provided by Ville > plus all changes provided later by Ander. > > As Geminilake, Cannonlake also supports 2 pixels per clock. > > Different from Geminilake we are not implementing the 99% Wa. >

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

On 09/28/2017 02:46 AM, Chris Wilson wrote: Stealing the thread for another gem_workarounds conundrum. After a reset, we lose the RING_FORCE_TO_NONPRIV registers. If they where in the context image as we presumed, the values would be retained and they can be read back from before reset, so

[Intel-gfx] ✗ Fi.CI.IGT: failure for 2-in-1: Organize feature inheritance and disable IPC.

== Series Details == Series: 2-in-1: Organize feature inheritance and disable IPC. URL : https://patchwork.freedesktop.org/series/31090/ State : failure == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add has_psr-flag to gen9lp

== Series Details == Series: drm/i915: Add has_psr-flag to gen9lp URL : https://patchwork.freedesktop.org/series/28488/ State : success == Summary == Series 28488v1 drm/i915: Add has_psr-flag to gen9lp https://patchwork.freedesktop.org/api/1.0/series/28488/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/glk, cnl: Implement WaDisableScalarClockGating

On Thu, Sep 28, 2017 at 07:54:36PM +, Imre Deak wrote: > On GLK and CNL enabling a pipe with its pipe scaler enabled will result > in a FIFO underrun. This happens only once after driver loading or > system/runtime resume, more specifically after power well 1 gets > enabled; subsequent

Re: [Intel-gfx] [PATCH v3 01/13] drm/i915: Inherit Kabylake platform features from Skylake

Quoting Rodrigo Vivi (2017-09-28 20:58:31) > On Thu, Sep 28, 2017 at 07:38:58PM +, Chris Wilson wrote: > > I recently tried to update the gen9 feature matrix and to my unpleasant > > surprise found that Kabylake still acted like Broadwell and didn't > > enable the feature. This is because

Re: [Intel-gfx] [PATCH] drm/i915: Use memset64() to prefill the GTT page

Quoting Tvrtko Ursulin (2017-09-26 11:30:50) > > On 26/09/2017 10:53, Chris Wilson wrote: > > Take advantage of optimised memset64() instead of open coding it to > > prefill the GTT pages. > > > > Signed-off-by: Chris Wilson > > --- > > Needs backmerge from 4.14-rc1,

[Intel-gfx] ✓ Fi.CI.BAT: success for 2-in-1: Organize feature inheritance and disable IPC.

== Series Details == Series: 2-in-1: Organize feature inheritance and disable IPC. URL : https://patchwork.freedesktop.org/series/31090/ State : success == Summary == Series 31090v1 2-in-1: Organize feature inheritance and disable IPC.

Re: [Intel-gfx] [PATCH v3 01/13] drm/i915: Inherit Kabylake platform features from Skylake

On Thu, Sep 28, 2017 at 07:38:58PM +, Chris Wilson wrote: > I recently tried to update the gen9 feature matrix and to my unpleasant > surprise found that Kabylake still acted like Broadwell and didn't > enable the feature. This is because kbl/cfl are inheriting their > defaults from Broadwell

[Intel-gfx] [PATCH] drm/i915/glk, cnl: Implement WaDisableScalarClockGating

On GLK and CNL enabling a pipe with its pipe scaler enabled will result in a FIFO underrun. This happens only once after driver loading or system/runtime resume, more specifically after power well 1 gets enabled; subsequent modesets seem to be free of underruns. The BSpec workaround for this is to

[Intel-gfx] [PATCH v3 11/13] drm/i915: Expand I915_PARAM_HAS_SCHEDULER into a capability bitmask

In the next few patches, we wish to enable different features for the scheduler, some which may subtlety change ABI (e.g. allow requests to be reordered under different circumstances). So we need to make sure userspace is cognizant of the changes (if they care), by which we employ the usual method

[Intel-gfx] [PATCH v3 03/13] drm/i915: Give the invalid priority a magic name

We use INT_MIN to denote the priority of a request that has not been submitted to the scheduler; we treat INT_MIN as an invalid priority and initialise the request to it. Give the value a name so it stands out. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v3 01/13] drm/i915: Inherit Kabylake platform features from Skylake

I recently tried to update the gen9 feature matrix and to my unpleasant surprise found that Kabylake still acted like Broadwell and didn't enable the feature. This is because kbl/cfl are inheriting their defaults from Broadwell and not Skylake. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v3 10/13] drm/i915/execlists: Keep request->priority for its lifetime

With preemption, we will want to "unsubmit" a request, taking it back from the hw and returning it to the priority sorted execution list. In order to know where to insert it into that list, we need to remember its adjust priority (which may change even as it was being executed). This also affects

[Intel-gfx] [PATCH v3 06/13] drm/i915/preempt: Default to disabled mid-command preemption levels

From: Michał Winiarski Supporting fine-granularity preemption levels may require changes in userspace batch buffer programming. Therefore, we need to fallback to safe default values, rather that use hardware defaults. Userspace is still able to enable

[Intel-gfx] [PATCH v3 12/13] drm/i915/execlists: Preemption!

When we write to ELSP, it triggers a context preemption at the earliest arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other operations and the explicit MI_ARB_CHECK). If this is to the same context, it triggers a LITE_RESTORE where the RING_TAIL is merely updated (used currently to

[Intel-gfx] [PATCH v3 13/13] drm/i915/scheduler: Support user-defined priorities

Use a priority stored in the context as the initial value when submitting a request. This allows us to change the default priority on a per-context basis, allowing different contexts to be favoured with GPU time at the expense of lower importance work. The user can adjust the context's priority

[Intel-gfx] [PATCH v3 05/13] drm/i915/preempt: Fix WaEnablePreemptionGranularityControlByUMD

From: Jeff McGee The WA applies to all production Gen9 and requires both enabling and whitelisting of the per-context preemption control register. v2: Extend to Cannonlake. Signed-off-by: Jeff McGee Signed-off-by: Michał Winiarski

[Intel-gfx] [PATCH v3 07/13] drm/i915/execlists: Distinguish the incomplete context notifies

Let the listener know that the context we just scheduled out was not complete, and will be scheduled back in at a later point. v2: Handle CONTEXT_STATUS_PREEMPTED in gvt by aliasing it to CONTEXT_STATUS_OUT for the moment, gvt can expand upon the difference later. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v3 08/13] drm/i915: Introduce a preempt context

Add another perma-pinned context for using for preemption at any time. We cannot just reuse the existing kernel context, as first and foremost we need to ensure that we can preempt the kernel context itself, so require a distinct context id. Similar to the kernel context, we may want to interrupt

[Intel-gfx] [PATCH v3 04/13] drm/i915/execlists: Cache the last priolist lookup

From: Michał Winiarski Avoid the repeated rbtree lookup for each request as we unwind them by tracking the last priolist. v2: Fix up my unhelpful suggestion of using default_priolist. Signed-off-by: Michał Winiarski Signed-off-by: Chris

[Intel-gfx] [PATCH v3 09/13] drm/i915/execlists: Move bdw GPGPU w/a to emit_bb

Move the re-enabling of MI arbitration from a per-bb w/a buffer to the emission of the batch buffer itself. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_lrc.c | 24 1

[Intel-gfx] [PATCH v3 02/13] drm/i915/execlists: Move request unwinding to a separate function

In the future, we will want to unwind requests following a preemption point. This requires the same steps as for unwinding upon a reset, so extract the existing code to a separate function for later use. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

Quoting Rodrigo Vivi (2017-09-28 20:12:14) > On Thu, Sep 28, 2017 at 07:02:59PM +, Chris Wilson wrote: > > Quoting Rodrigo Vivi (2017-09-28 19:51:48) > > > Although Bspec state this Workaround is only relevant for SKL:All. > > > > > > The wa_database state this is needed for All platforms

[Intel-gfx] ✗ Fi.CI.BAT: failure for 2-in-1: Organize feature inheritance and disable IPC.

== Series Details == Series: 2-in-1: Organize feature inheritance and disable IPC. URL : https://patchwork.freedesktop.org/series/31090/ State : failure == Summary == Series 31090v1 2-in-1: Organize feature inheritance and disable IPC.

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

On Thu, Sep 28, 2017 at 07:02:59PM +, Chris Wilson wrote: > Quoting Rodrigo Vivi (2017-09-28 19:51:48) > > Although Bspec state this Workaround is only relevant for SKL:All. > > > > The wa_database state this is needed for All platforms from SKL to CNL. > > > > So let's pick the safest case.

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Organize GEN features inheritance.

On Thu, Sep 28, 2017 at 07:03:36PM +, Chris Wilson wrote: > Quoting Rodrigo Vivi (2017-09-28 19:51:46) > > As Chris noticed the current organization is confusing > > and inheritance is not clear. > > > > So, let's split it in GEN_FEATURES _PLATFORM > > where new GEN inherit features from

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.

Quoting Rodrigo Vivi (2017-09-28 19:51:47) > Let's organize this in a way that it gets more obvious > when looking to the platform colors and in a easier > way to get inherited. > > Signed-off-by: Rodrigo Vivi Lgtm, Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Organize GEN features inheritance.

Quoting Rodrigo Vivi (2017-09-28 19:51:46) > As Chris noticed the current organization is confusing > and inheritance is not clear. > > So, let's split it in GEN_FEATURES _PLATFORM > where new GEN inherit features from previous gens and > Platforms only use gen features plus what ever is specific

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

Quoting Rodrigo Vivi (2017-09-28 19:51:48) > Although Bspec state this Workaround is only relevant for SKL:All. > > The wa_database state this is needed for All platforms from SKL to CNL. > > So let's pick the safest case. > > Cc: Mahesh Kumar > Cc: Chris Wilson

[Intel-gfx] [PATCH 0/4] 2-in-1: Organize feature inheritance and disable IPC.

I had a chicken and egg problem here. Specially because I want CI to test everything and patches had interdependency. On the platform/features organization side we can go further and organize gen7_lp and gen8_lp inheriting g75_features and gen8_features respectively. But let's at least start this

[Intel-gfx] [PATCH 2/4] drm/i915: Organize GEN features inheritance.

As Chris noticed the current organization is confusing and inheritance is not clear. So, let's split it in GEN_FEATURES _PLATFORM where new GEN inherit features from previous gens and Platforms only use gen features plus what ever is specific for that platform and shouldn't be passed on. Cc:

[Intel-gfx] [PATCH 3/4] drm/i915: Organize GLK_COLORS.

Let's organize this in a way that it gets more obvious when looking to the platform colors and in a easier way to get inherited. Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH 1/4] drm/i915/skl: Fix has_ipc on skl and document WaDisableIPC.

According to Spec for SKL+: "Isochronous Priority Control. If enabled, Display sends demoted requests once the transition watermark is reached. If transition watermark is not enabled, Display sends demoted requests when the display buffer is full." The commit 'e57f1c02155f ("drm/i915/gen9+: Add

[Intel-gfx] [PATCH 4/4] drm/i915: Extend WaDisableIPC to all platforms.

Although Bspec state this Workaround is only relevant for SKL:All. The wa_database state this is needed for All platforms from SKL to CNL. So let's pick the safest case. Cc: Mahesh Kumar Cc: Chris Wilson Cc: Maarten Lankhorst

Re: [Intel-gfx] [PATCH v2 10/11] drm/i915/execlists: Preemption!

Quoting Joonas Lahtinen (2017-09-28 15:10:03) > On Wed, 2017-09-27 at 17:44 +0100, Chris Wilson wrote: > > When we write to ELSP, it triggers a context preemption at the earliest > > arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other > > operations and the explicit MI_ARB_CHECK). If

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] meson.sh: Invoke meson correctly

== Series Details == Series: series starting with [1/2] meson.sh: Invoke meson correctly URL : https://patchwork.freedesktop.org/series/31082/ State : warning == Summary == Test gem_eio: Subgroup throttle: pass -> DMESG-WARN (shard-hsw) fdo#102886 +3 Test

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] igt/gem_sync: Add a preemption test

== Series Details == Series: series starting with [1/2] igt/gem_sync: Add a preemption test URL : https://patchwork.freedesktop.org/series/31088/ State : success == Summary == IGT patchset tested on top of latest successful build 3df22e0d2f8934311c62e4fd84bee24b32addb58

[Intel-gfx] ✗ Fi.CI.IGT: failure for tests/gem_workarounds: Skip write only registers (rev2)

== Series Details == Series: tests/gem_workarounds: Skip write only registers (rev2) URL : https://patchwork.freedesktop.org/series/31073/ State : failure == Summary == Test prime_mmap: Subgroup test_userptr: pass -> DMESG-WARN (shard-hsw) fdo#102939 Test

[Intel-gfx] [PATCH igt 1/2] igt/gem_sync: Add a preemption test

Check and measure how well we can submit a second high priority task when the engine is already busy with a low priority task and see how long it takes to complete (and wake up the client). Signed-off-by: Chris Wilson --- tests/gem_sync.c | 158

[Intel-gfx] [PATCH igt 2/2] igt/gem_exec_nop: Measure high-priority throughput over a bg load

Measure how many high priority batches we can execute whilst running a bg spinner. Signed-off-by: Chris Wilson --- tests/gem_exec_nop.c | 118 +++ 1 file changed, 118 insertions(+) diff --git a/tests/gem_exec_nop.c

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

Quoting Rodrigo Vivi (2017-09-28 18:13:27) > On Thu, Sep 28, 2017 at 05:00:53PM +, Chris Wilson wrote: > > Quoting Rodrigo Vivi (2017-09-28 17:33:48) > > > On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote: > > > > I recently tried to update the gen9 feature matrix and to my

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

On Thu, Sep 28, 2017 at 05:00:53PM +, Chris Wilson wrote: > Quoting Rodrigo Vivi (2017-09-28 17:33:48) > > On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote: > > > I recently tried to update the gen9 feature matrix and to my unpleasant > > > surprise found that Kabylake still acted

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

Quoting Rodrigo Vivi (2017-09-28 17:33:48) > On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote: > > I recently tried to update the gen9 feature matrix and to my unpleasant > > surprise found that Kabylake still acted like Broadwell and didn't > > enable the feature. This is because

Re: [Intel-gfx] [PATCH] drm/i915: Also discard second CRC on gen8+ platforms.

On Thu, Sep 28, 2017 at 08:09:43AM +, Mika Kahola wrote: > This fixes my issue with GLK+MIPI/DSI when running IGT test > > kms_frontbuffer_tracking --r basic > > Tested-by: Mika Kahola Thanks for spotting the problem, for reviews and testings. Patch merged to dinq.

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Set frames before SU entry for psr2

On Fri, Sep 22, 2017 at 03:58:36PM +, vathsala nagaraju wrote: > Set frames before SU entry value for max resync frame count of > dpcd register 2009, bit field 0:3. > > v2 : > - add macro EDP_PSR2_FRAME_BEFORE_SU (Rodrigo) > - remove EDP_FRAMES_BEFORE_SU_ENTRY (Rodrigo) > - add check ==1

Re: [Intel-gfx] [PATCH] drm/i915: Add has_psr-flag to gen9lp

On Thu, Sep 28, 2017 at 10:51:42AM +, David Weinehall wrote: > On Thu, Sep 28, 2017 at 04:20:29AM +, Rodrigo Vivi wrote: > > On Wed, Sep 27, 2017 at 5:14 AM David Weinehall < > > david.weineh...@linux.intel.com> wrote: > > > > > On Tue, Aug 08, 2017 at 12:50:51PM -0700, Rodrigo Vivi

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Inherit Kabylake platform features from Skylake

== Series Details == Series: drm/i915: Inherit Kabylake platform features from Skylake URL : https://patchwork.freedesktop.org/series/31081/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test kms_setmode:

Re: [Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

On Thu, Sep 28, 2017 at 02:59:13PM +, Chris Wilson wrote: > I recently tried to update the gen9 feature matrix and to my unpleasant > surprise found that Kabylake still acted like Broadwell and didn't > enable the feature. This is because kbl/cfl are inheriting their > defaults from Broadwell

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] meson.sh: Invoke meson correctly

== Series Details == Series: series starting with [1/2] meson.sh: Invoke meson correctly URL : https://patchwork.freedesktop.org/series/31082/ State : success == Summary == IGT patchset tested on top of latest successful build 3df22e0d2f8934311c62e4fd84bee24b32addb58

[Intel-gfx] ✗ Fi.CI.IGT: warning for tests/gem_workarounds: Skip write only registers

== Series Details == Series: tests/gem_workarounds: Skip write only registers URL : https://patchwork.freedesktop.org/series/31073/ State : warning == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test gem_eio:

[Intel-gfx] ✗ Fi.CI.IGT: failure for igt: Add a testsuite to validate VC4 MADV ioctl

== Series Details == Series: igt: Add a testsuite to validate VC4 MADV ioctl URL : https://patchwork.freedesktop.org/series/30959/ State : failure == Summary == Test prime_mmap: Subgroup test_userptr: pass -> DMESG-WARN (shard-hsw) fdo#102939 Test

[Intel-gfx] ✗ Fi.CI.IGT: failure for benchmarks: Actually build LIBDRM_INTEL_BENCHMARKS

== Series Details == Series: benchmarks: Actually build LIBDRM_INTEL_BENCHMARKS URL : https://patchwork.freedesktop.org/series/30970/ State : failure == Summary == Test kms_flip: Subgroup dpms-vs-vblank-race: pass -> FAIL (shard-hsw) Subgroup

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_workarounds: Skip write only registers (rev2)

== Series Details == Series: tests/gem_workarounds: Skip write only registers (rev2) URL : https://patchwork.freedesktop.org/series/31073/ State : success == Summary == IGT patchset tested on top of latest successful build 3df22e0d2f8934311c62e4fd84bee24b32addb58 benchmarks/gem_exec_fault:

[Intel-gfx] ✓ Fi.CI.IGT: success for configure.ac: Install and distribute kabylake registers

== Series Details == Series: configure.ac: Install and distribute kabylake registers URL : https://patchwork.freedesktop.org/series/30973/ State : success == Summary == Test gem_eio: Subgroup in-flight-external: dmesg-warn -> PASS (shard-hsw) fdo#102886 +2 Test

[Intel-gfx] ✗ Fi.CI.IGT: failure for lib/igt_kms: Convert properties to be more atomic-like. (rev2)

== Series Details == Series: lib/igt_kms: Convert properties to be more atomic-like. (rev2) URL : https://patchwork.freedesktop.org/series/30903/ State : failure == Summary == Test kms_atomic_interruptible: Subgroup legacy-cursor: pass -> FAIL (shard-hsw)

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v4,1/6] tests/kms_ccs: Test pipes other than pipe A

== Series Details == Series: series starting with [v4,1/6] tests/kms_ccs: Test pipes other than pipe A URL : https://patchwork.freedesktop.org/series/30991/ State : failure == Summary == Test kms_cursor_legacy: Subgroup cursorA-vs-flipA-atomic-transitions: pass

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] Fix rlim_cur compiler warnings when building on ARM.

== Series Details == Series: series starting with [1/3] Fix rlim_cur compiler warnings when building on ARM. URL : https://patchwork.freedesktop.org/series/30992/ State : failure == Summary == Test prime_mmap: Subgroup test_userptr: pass -> DMESG-WARN

Re: [Intel-gfx] [PATCH v10 9/9] drm/i915/guc: Fix GuC cleanup in unload path

On 9/28/2017 6:45 PM, Sagar Arun Kamble wrote: On 9/28/2017 5:25 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-09-27 10:30:39) -void intel_uc_fini_hw(struct drm_i915_private *dev_priv) +void intel_uc_cleanup(struct drm_i915_private *dev_priv)   {

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION (rev3)

== Series Details == Series: igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION (rev3) URL : https://patchwork.freedesktop.org/series/30860/ State : success == Summary == Test gem_eio: Subgroup in-flight-contexts: dmesg-warn -> PASS (shard-hsw)

[Intel-gfx] ✗ Fi.CI.IGT: warning for Fix compilation on some distros

== Series Details == Series: Fix compilation on some distros URL : https://patchwork.freedesktop.org/series/31012/ State : warning == Summary == Test gem_eio: Subgroup execbuf: dmesg-warn -> PASS (shard-hsw) fdo#102886 +1 Test kms_busy: Subgroup

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Inherit Kabylake platform features from Skylake

== Series Details == Series: drm/i915: Inherit Kabylake platform features from Skylake URL : https://patchwork.freedesktop.org/series/31081/ State : success == Summary == Series 31081v1 drm/i915: Inherit Kabylake platform features from Skylake

[Intel-gfx] [PATCH i-g-t 1/2] meson.sh: Invoke meson correctly

Either source or build directory is required as a command line parameter. Also use mkdir -p when creating the build directory to avoid errors when it already exists. Signed-off-by: Petri Latvala --- meson.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [Intel-gfx] [PATCH i-g-t 2/2] meson: Also build kms_atomic_interruptible

On Thu, Sep 28, 2017 at 06:10:48PM +0300, Petri Latvala wrote: > Signed-off-by: Petri Latvala > --- > tests/meson.build | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tests/meson.build b/tests/meson.build > index 1c619179..53d02d13 100644 > ---

[Intel-gfx] [PATCH i-g-t 2/2] meson: Also build kms_atomic_interruptible

Signed-off-by: Petri Latvala --- tests/meson.build | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/meson.build b/tests/meson.build index 1c619179..53d02d13 100644 --- a/tests/meson.build +++ b/tests/meson.build @@ -152,6 +152,7 @@ test_progs = [

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

On Thu, Sep 28, 2017 at 06:00:03PM +0300, Mika Kuoppala wrote: > We have no means to check write only registers as > this would need access through context image. For now we > know that cnl has a one such register, 0xe5f0 which is used > to set WaForceContextSaveRestoreNonCoherent:cnl. By

[Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

We have no means to check write only registers as this would need access through context image. For now we know that cnl has a one such register, 0xe5f0 which is used to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting the context image without and with workaround applied: 0xa840:

[Intel-gfx] [PATCH] drm/i915: Inherit Kabylake platform features from Skylake

I recently tried to update the gen9 feature matrix and to my unpleasant surprise found that Kabylake still acted like Broadwell and didn't enable the feature. This is because kbl/cfl are inheriting their defaults from Broadwell and not Skylake. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH igt v3] igt/gem_exec_scheduler: HAS_SCHEDULER no longer means HAS_PREEMPTION

On Wed, 2017-09-27 at 19:47 +0100, Chris Wilson wrote: > Michal wants to limit machines that can do preemption, which means that > we no longer can assume that if we have a scheduler for execbuf, that > implies we have preemption. > > v2: Try a capability mask instead > v3: Pretty print the caps.

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/gem_workarounds: Skip write only registers

== Series Details == Series: tests/gem_workarounds: Skip write only registers URL : https://patchwork.freedesktop.org/series/31073/ State : success == Summary == IGT patchset tested on top of latest successful build 2885b10f99b4beeb046e75af8b8488c229f629d3 igt/gem_exec_schedule: Ignore

Re: [Intel-gfx] [PATCH v1] drm/i915: Enhanced for initialize partially filled pagetables

On Thu, 2017-09-28 at 10:09 +0800, Xiaolin Zhang wrote: > if vgpu active, the page table entry should be initialized after > allocation and then the hypersivor can ping pages succesuffly, > otherwise hypervisor will ping pages failed and the host will print > a lot of annoying errors such as

Re: [Intel-gfx] [PATCH v2 11/11] drm/i915/scheduler: Support user-defined priorities

On Wed, 2017-09-27 at 17:44 +0100, Chris Wilson wrote: > Use a priority stored in the context as the initial value when > submitting a request. This allows us to change the default priority on a > per-context basis, allowing different contexts to be favoured with GPU > time at the expense of lower

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

On Thu, Sep 28, 2017 at 04:45:06PM +0300, Mika Kuoppala wrote: > We have no means to check write only registers as > this would need access through context image. For now we > know that cnl has a one such register, 0xe5f0 which is used > to set WaForceContextSaveRestoreNonCoherent:cnl. By

Re: [Intel-gfx] [PATCH v2 10/11] drm/i915/execlists: Preemption!

On Wed, 2017-09-27 at 17:44 +0100, Chris Wilson wrote: > When we write to ELSP, it triggers a context preemption at the earliest > arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other > operations and the explicit MI_ARB_CHECK). If this is to the same > context, it triggers a

Re: [Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

Quoting Mika Kuoppala (2017-09-28 14:45:06) > We have no means to check write only registers as > this would need access through context image. For now we > know that cnl has a one such register, 0xe5f0 which is used > to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting > the context

[Intel-gfx] [PATCH igt] tests/gem_workarounds: Skip write only registers

We have no means to check write only registers as this would need access through context image. For now we know that cnl has a one such register, 0xe5f0 which is used to set WaForceContextSaveRestoreNonCoherent:cnl. By inspecting the context image without and with workaround applied: 0xa840:

Re: [Intel-gfx] [PATCH v10 1/9] drm/i915: Create GEM runtime resume helper and handle GEM suspend/resume errors

On 9/28/2017 5:07 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-09-27 10:30:31) These changes are preparation to handle GuC suspend/resume. Prepared helper i915_gem_runtime_resume to reinitialize suspended gem setup. Returning status from i915_gem_runtime_suspend and

Re: [Intel-gfx] [PATCH v2 08/11] drm/i915/execlists: Keep request->priority for its lifetime

On Thu, Sep 28, 2017 at 11:09:14AM +, Chris Wilson wrote: > Quoting Chris Wilson (2017-09-27 17:44:37) > > With preemption, we will want to "unsubmit" a request, taking it back > > from the hw and returning it to the priority sorted execution list. In > > order to know where to insert it into

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/gem_exec_schedule: Detect too slow setup in deep-*

== Series Details == Series: igt/gem_exec_schedule: Detect too slow setup in deep-* URL : https://patchwork.freedesktop.org/series/31061/ State : success == Summary == Test gem_eio: Subgroup in-flight: pass -> DMESG-WARN (shard-hsw) fdo#102886 +2 Test

Re: [Intel-gfx] [PATCH v10 2/9] drm/i915: Update GEM suspend/resume flows considering GuC and GEM fences

On 9/28/2017 5:10 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-09-27 10:30:32) @@ -4607,13 +4611,14 @@ int i915_gem_resume(struct drm_i915_private *dev_priv) mutex_lock(>struct_mutex); i915_gem_restore_gtt_mappings(dev_priv); +

Re: [Intel-gfx] [PATCH v10 6/9] drm/i915/guc: Check execbuf client to disable submission and don't depend on enable_guc_submission

On 9/28/2017 5:17 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-09-27 10:30:36) We should check dependent state setup by enable path to run disable path and not depend on the user parameters. i915_guc_submission_disable now checks if execbuf client is setup and then goes ahead with

  1   2   >