Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Introduce GEM proxy

Hi, As the "Dma-buf support for GVT-g" patch-set relys on this patch, can I collect the comments for this version? Do we all agree on it? Thanks. Comments of the previous version: https://lists.freedesktop.org/archives/intel-gvt-dev/2017-October/002278.html BR, Tina > -Original

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible

== Series Details == Series: series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible URL : https://patchwork.freedesktop.org/series/33649/ State : success == Summary == Test drv_module_reload: Subgroup basic-reload: pass ->

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Introduce GEM proxy

> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Joonas Lahtinen > Sent: Tuesday, November 7, 2017 9:06 PM > To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi > A ;

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

> -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Gerd Hoffmann > Sent: Friday, November 10, 2017 3:03 PM > To: Alex Williamson > Cc: Tian, Kevin ; Yuan, Hang

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser (rev2)

== Series Details == Series: drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser (rev2) URL : https://patchwork.freedesktop.org/series/33645/ State : success == Summary == Test kms_flip: Subgroup dpms-vs-vblank-race: pass -> FAIL

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

== Series Details == Series: series starting with [1/5] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser URL : https://patchwork.freedesktop.org/series/33650/ State : failure == Summary == Series 33650v1 series starting with [1/5] drm/i915/selftests: Yet another forgotten

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible

On 11/10/2017 5:15 PM, Chris Wilson wrote: Quoting Patchwork (2017-11-11 01:03:20) == Series Details == Series: series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible URL : https://patchwork.freedesktop.org/series/33649/ State : success BAT results

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible

Quoting Patchwork (2017-11-11 01:03:20) > == Series Details == > > Series: series starting with [1/2] drm/i915: Clear per-engine fault register > as early as possible > URL : https://patchwork.freedesktop.org/series/33649/ > State : success BAT results arrived before patches, yay! Patch 1

[Intel-gfx] ✗ Fi.CI.IGT: warning for HDMI 2.0 on CNL... not working... (rev2)

== Series Details == Series: HDMI 2.0 on CNL... not working... (rev2) URL : https://patchwork.freedesktop.org/series/33640/ State : warning == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 Test kms_frontbuffer_tracking:

Re: [Intel-gfx] [PATCH v9 1/8] drm/i915 : Unifying seq_puts messages for feature support

Quoting Sujaritha Sundaresan (2017-11-11 00:06:31) > Unifying the various seq_puts messages in debugfs to the simplest one for > feature support. i.e. -ENODEV. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible

== Series Details == Series: series starting with [1/2] drm/i915: Clear per-engine fault register as early as possible URL : https://patchwork.freedesktop.org/series/33649/ State : success == Summary == Series 33649v1 series starting with [1/2] drm/i915: Clear per-engine fault register as

Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

Quoting Matthew Auld (2017-11-10 23:40:07) > On 10 November 2017 at 23:24, Chris Wilson wrote: > > Move all of the i915->mm initialisation to a private function that can > > be reused by the mock i915 device to save forgetting any more steps. > > > > For example, > >

[Intel-gfx] [PATCH 5/5] drm/i915: Automatic i915_switch_context for legacy

During request construction, after pinning the context we know whether or not we have to emit a context switch. So move this common operation from every caller into i915_gem_request_alloc() itself. v2: Always submit the request if we emitted some commands during request construction, as typically

[Intel-gfx] [PATCH 2/5] drm/i915/selftests: Increase size for mock ringbuffer

We don't actually emit any commands into the ringbuffer, so we set it very small. However, an upcoming change centralises the wait-for-space into i915_gem_request_alloc() and that imposes a minimum size upon all ringbuffers (mock or real) of MIN_SPACE_FOR_ADD_REQUEST. Grow the mock ringbuffer such

[Intel-gfx] [PATCH 4/5] drm/i915: Make request's wait-for-space explicit

At the start of building a request, we would wait for roughly enough space to fit the average request (to reduce the likelihood of having to wait and abort partway through request construction). To achieve we would try to begin a 0-length command packet, this just adds extra confusion so make the

[Intel-gfx] [PATCH 1/5] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

Move all of the i915->mm initialisation to a private function that can be reused by the mock i915 device to save forgetting any more steps. For example, <7>[ 1542.046332] [IGT] drv_selftest: starting subtest mock_objects <4>[ 1542.123924] Setting dangerous option mock_selftests - tainting kernel

[Intel-gfx] [PATCH 3/5] drm/i915: Remove redundant intel_autoenable_gt_powersave()

Now that we always execute a context switch upon module load, there is no need to queue a delayed task for doing so. The purpose of the delayed task is to enable GT powersaving, for which we need the HW state to be valid (i.e. having loaded a context and initialised basic state). We used to defer

[Intel-gfx] [PATCH 2/2 v2] drm/i915: There is only one fault register from GEN8 onwards

Until Haswell/Baytrail, the hardware used to have a per engine fault register (e.g. 0x4094 - render fault register, 0x4194 - media fault register and so on). But since Broadwell, all these registers were combined into a singe one and the engine id stored in bits 14:12. Not only we should not been

[Intel-gfx] [PATCH 1/2] drm/i915: Clear per-engine fault register as early as possible

From gen6, the hardware tracks address lookup failures and we should clear those registers upon startup to prevent false positives. However, this was happening before we have the engines defined (intel_uncore_init()) and the for_each_engine loop was just a nop. The earliest we can call this is

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Remove redundant intel_autoenable_gt_powersave()

== Series Details == Series: drm/i915: Remove redundant intel_autoenable_gt_powersave() URL : https://patchwork.freedesktop.org/series/33641/ State : warning == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Subgroup

Re: [Intel-gfx] [PATCH i-g-t 0/5] Import drm UAPI headers.

Hey Eric, Like it did for Mesa I think this makes developers' lives easier. Not having to update libdrm and then compile against the right version just for the kernel headers you need is a win (in my opinion). Looking forward to get this merged! If most developers agree with the overall

Re: [Intel-gfx] [RFC 0/3] GuC functions name/prototype update

On 11/10/2017 01:59 AM, Sagar Arun Kamble wrote: We want to have consistent function/structure/file naming and function parameter semantics. Suggestion from Michal Wajdeczko about using "genx_" prefix (or better _genx" suffix for all hw related structures types, offsets), "i915_" prefix for

Re: [Intel-gfx] [RFC PATCH v6 0/6] Refactor HW workaround code

On 11/09/2017 05:43 AM, Ville Syrjälä wrote: On Wed, Nov 08, 2017 at 03:59:43PM -0800, Oscar Mateo wrote: Until we agree on a design, I have removed all new code to save the actual list of WAs and dump it in debugfs. For the moment, only shuffle things arounds until most WAs are in the same

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk (rev4)

== Series Details == Series: drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk (rev4) URL : https://patchwork.freedesktop.org/series/33463/ State : warning == Summary == Series 33463v4 drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

Re: [Intel-gfx] [PATCH i-g-t 2/5] tests: Convert to using the imported drm-uapi headers.

On 10/11/17 21:26, Eric Anholt wrote: Tested by dropping garbage in my libdrm's headers and rebuilding. Signed-off-by: Eric Anholt --- lib/Makefile.am | 5 - meson.build | 2 +- tests/Makefile.am | 1 + 3 files changed, 6 insertions(+), 2 deletions(-) diff

Re: [Intel-gfx] [PATCH] drm/i915: There is only one fault register from GEN8 onwards

On 11/10/2017 3:50 PM, Chris Wilson wrote: Quoting Michel Thierry (2017-11-10 23:42:31) On 11/10/2017 12:51 PM, Chris Wilson wrote: Quoting Michel Thierry (2017-11-10 19:01:16) Until Haswell/Baytrail, the hardware used to have a per engine fault register (e.g. 0x4094 - render fault register,

[Intel-gfx] [PATCH v9 8/8] drm/i915/guc : Calling intel_guc_init in i915_gem_init

Placing the call to intel_guc_init after i915_gem_contexts_init, based on the dependency within i915_gem_init. Will move the function if required, depending on the review comments. Suggested by: Sagar Arun Kamble Signed-off-by: Sujaritha Sundaresan

[Intel-gfx] [PATCH v9 5/8] drm/i915/guc : GEM_BUG_ON for GuC reset function

Including GEM_BUG_ON for GuC reset function in intel_uncore. Signed-off-by: Sujaritha Sundaresan Cc: Michal Wajdeczko Cc: Oscar Mateo Cc: Sagar Arun Kamble ---

[Intel-gfx] [PATCH v9 2/8] drm/i915/guc : Removing i915_modparams.enable_guc_loading module parameter

We currently have two module parameters that control GuC: "enable_guc_loading" and "enable_guc_submission". Whenever we need submission=1, we also need loading=1.We also need loading=1 when we want to want to verify the HuC, which is every time we have a HuC (but all platforms with HuC have a GuC

[Intel-gfx] [PATCH v9 6/8] drm/i915/guc : Introducing enable_guc module parameter

Replacing enable_guc_submission with enable_guc modparam. In effect enable_guc is replacing enable_guc_loading and enable_guc_submission. Suggested by : Michal Wajdeczko Signed-off-by: Sujaritha Sundaresan Cc: Chris Wilson

[Intel-gfx] [PATCH v9 7/8] drm/i915/guc : Decouple logs and ADS from submission

The Additional Data Struct (ADS) contains objects that are required by guc post FW load and are not necessarily submission-only (although that's our current only use-case). If in the future we load GuC with submission disabled to use some other GuC feature we might still end up requiring something

[Intel-gfx] [PATCH v9 0/8] drm/i915/guc : Removing enable_guc_loading module and Decoupling logs and ADS from submission

The first patch simply unifies different seq_puts messages found in debugfs. Patch 2 and 3 involve replacing te enable_guc_loading module. Patches 4 and 5 deal with removing dependancies on enable_guc_submission. Patch 6 introduces the enable_guc parameter. Patches 7 and 8 deal with decoupling

[Intel-gfx] [PATCH v9 4/8] drm/i915/guc : Updating GuC logs to remove enable_guc_submission parameter

Replacing conditions to remove dependance on enable_guc_submission v9: Including guc_log_level in the condition (Sagar) Signed-off-by: Sujaritha Sundaresan Cc: Michal Wajdeczko Cc: Oscar Mateo Cc: Sagar Arun

[Intel-gfx] [PATCH v9 3/8] drm/i915/guc : Updating GuC and HuC firmware select function

Updating GuC and HuC firmware select function to support removing i915_modparams.enable_guc_loading module parameter. v2: Clarifying the commit message (Anusha) v3: Unify seq_puts messages, Re-factoring code as per review (Michal) v4: Rebase v5: Separating message unification into a separate

[Intel-gfx] [PATCH v9 1/8] drm/i915 : Unifying seq_puts messages for feature support

Unifying the various seq_puts messages in debugfs to the simplest one for feature support. v2: Clarifying the commit message (Anusha) v3: Re-factoring code as per review (Michal) v4: Rebase v5: Split from following patch v6: Re-factoring code (Michal, Sagar) Clarifying commit message

Re: [Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

On Fri, Nov 10, 2017 at 11:50:21PM +, Manasi Navare wrote: > Looks good. > But are these the only places that need change to support 2.0? > Dont we need any changes in voltage swing programming or DDI clocks? not that I'm aware of... but that would explain the blank screens... > > Manasi` >

[Intel-gfx] [PATCH] drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

Display is not sending a PMRsp when a PMReq is received at the same time that all planes are turned off. State machine in the dcprunit is stuck in the WAIT4DONE state which means that there is no fill_done. WA: disable arbiter clock gating, set bit [27] of 0x46530 v2: As Ville pointed out, based

Re: [Intel-gfx] [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

Sorry this took so long. The vmwgfx part: Reviewed-by: Sinclair Yeh I've done some testing and the vmwgfx part looks good. Has Daniel already taken these or should I put them in my next request? Sinclair On Wed, Nov 01, 2017 at 08:29:15PM +0200, Ville Syrjala wrote: > From:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser (rev2)

== Series Details == Series: drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser (rev2) URL : https://patchwork.freedesktop.org/series/33645/ State : success == Summary == Series 33645v2 drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

Re: [Intel-gfx] [PATCH] drm/i915: There is only one fault register from GEN8 onwards

Quoting Michel Thierry (2017-11-10 23:42:31) > On 11/10/2017 12:51 PM, Chris Wilson wrote: > > Quoting Michel Thierry (2017-11-10 19:01:16) > >> Until Haswell/Baytrail, the hardware used to have a per engine fault > >> register (e.g. 0x4094 - render fault register, 0x4194 - media fault > >>

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Make request's wait-for-space explicit

== Series Details == Series: series starting with [1/2] drm/i915: Make request's wait-for-space explicit URL : https://patchwork.freedesktop.org/series/33639/ State : success == Summary == Test kms_flip: Subgroup plain-flip-fb-recreate: pass -> FAIL

Re: [Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

Looks good. But are these the only places that need change to support 2.0? Dont we need any changes in voltage swing programming or DDI clocks? Manasi` On Fri, Nov 10, 2017 at 02:26:26PM -0800, Rodrigo Vivi wrote: > Starting on GLK we support HDMI 2.0. So this patch only > extend the work

Re: [Intel-gfx] [PATCH] drm/i915: There is only one fault register from GEN8 onwards

On 11/10/2017 12:51 PM, Chris Wilson wrote: Quoting Michel Thierry (2017-11-10 19:01:16) Until Haswell/Baytrail, the hardware used to have a per engine fault register (e.g. 0x4094 - render fault register, 0x4194 - media fault register and so on). But since Broadwell, all these registers were

Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

On 10 November 2017 at 23:24, Chris Wilson wrote: > Move all of the i915->mm initialisation to a private function that can > be reused by the mock i915 device to save forgetting any more steps. > > For example, > <7>[ 1542.046332] [IGT] drv_selftest: starting subtest

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Make request's wait-for-space explicit

== Series Details == Series: series starting with [1/3] drm/i915: Make request's wait-for-space explicit URL : https://patchwork.freedesktop.org/series/33644/ State : failure == Summary == Series 33644v1 series starting with [1/3] drm/i915: Make request's wait-for-space explicit

[Intel-gfx] [PATCH v2] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

Move all of the i915->mm initialisation to a private function that can be reused by the mock i915 device to save forgetting any more steps. For example, <7>[ 1542.046332] [IGT] drv_selftest: starting subtest mock_objects <4>[ 1542.123924] Setting dangerous option mock_selftests - tainting kernel

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

Quoting Matthew Auld (2017-11-10 23:18:41) > On 10 November 2017 at 22:58, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > index d2bf2729c331..2df47239e8a0 100644 > > ---

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

On 10 November 2017 at 22:58, Chris Wilson wrote: > Move all of the i915->mm initialisation to a private function that can > be reused by the mock i915 device to save forgetting any more steps. > > For example, > <7>[ 1542.046332] [IGT] drv_selftest: starting subtest

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI 2.0 on CNL... not working... (rev2)

== Series Details == Series: HDMI 2.0 on CNL... not working... (rev2) URL : https://patchwork.freedesktop.org/series/33640/ State : success == Summary == Series 33640v2 HDMI 2.0 on CNL... not working... https://patchwork.freedesktop.org/api/1.0/series/33640/revisions/2/mbox/ Test

[Intel-gfx] ✗ Fi.CI.IGT: warning for Import drm UAPI headers.

== Series Details == Series: Import drm UAPI headers. URL : https://patchwork.freedesktop.org/series/33635/ State : warning == Summary == Test gem_softpin: Subgroup noreloc-s4: dmesg-fail -> FAIL (shard-hsw) fdo#103375 Test drv_module_reload: Subgroup

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove redundant intel_autoenable_gt_powersave()

== Series Details == Series: drm/i915: Remove redundant intel_autoenable_gt_powersave() URL : https://patchwork.freedesktop.org/series/33641/ State : success == Summary == Series 33641v1 drm/i915: Remove redundant intel_autoenable_gt_powersave()

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk (rev3)

== Series Details == Series: drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk (rev3) URL : https://patchwork.freedesktop.org/series/33463/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912

[Intel-gfx] [PATCH] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

Move all of the i915->mm initialisation to a private function that can be reused by the mock i915 device to save forgetting any more steps. For example, <7>[ 1542.046332] [IGT] drv_selftest: starting subtest mock_objects <4>[ 1542.123924] Setting dangerous option mock_selftests - tainting kernel

[Intel-gfx] [PATCH 3/3] drm/i915: Remove redundant intel_autoenable_gt_powersave()

Now that we always execute a context switch upon module load, there is no need to queue a delayed task for doing so. The purpose of the delayed task is to enable GT powersaving, for which we need the HW state to be valid (i.e. having loaded a context and initialised basic state). We used to defer

[Intel-gfx] [PATCH 2/3] drm/i915: Automatic i915_switch_context for legacy

During request construction, after pinning the context we know whether or not we have to emit a context switch. So move this common operation from every caller into i915_gem_request_alloc() itself. v2: Always submit the request if we emitted some commands during request construction, as typically

[Intel-gfx] [PATCH 1/3] drm/i915: Make request's wait-for-space explicit

At the start of building a request, we would wait for roughly enough space to fit the average request (to reduce the likelihood of having to wait and abort partway through request construction). To achieve we would try to begin a 0-length command packet, this just adds extra confusion so make the

[Intel-gfx] [PATCH] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

Starting on GLK we support HDMI 2.0. So this patch only extend the work Shashank has made to GLK to CNL. v2: The version that compiles :/ Cc: Paulo Zanoni Cc: Shashank Sharma Cc: Manasi Navare Signed-off-by:

[Intel-gfx] ✗ Fi.CI.BAT: failure for HDMI 2.0 on CNL... not working...

== Series Details == Series: HDMI 2.0 on CNL... not working... URL : https://patchwork.freedesktop.org/series/33640/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Make request's wait-for-space explicit

== Series Details == Series: series starting with [1/2] drm/i915: Make request's wait-for-space explicit URL : https://patchwork.freedesktop.org/series/33639/ State : success == Summary == Series 33639v1 series starting with [1/2] drm/i915: Make request's wait-for-space explicit

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Automatic i915_switch_context for legacy

Quoting Chris Wilson (2017-11-10 22:09:53) > During request construction, after pinning the context we know whether > or not we have to emit a context switch. So move this common operation > from every caller into i915_gem_request_alloc() itself. > > Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Remove redundant intel_autoenable_gt_powersave()

Now that we always execute a context switch upon module load, there is no need to queue a delayed task for doing so. The purpose of the delayed task is to enable GT powersaving, for which we need the HW state to be valid (i.e. having loaded a context and initialised basic state). We used to defer

[Intel-gfx] [PATCH 1/1] drm/i915/cnl: Extend HDMI 2.0 support to CNL.

Starting on GLK we support HDMI 2.0. So this patch only extend the work Shashank has made to GLK to CNL. Cc: Paulo Zanoni Cc: Shashank Sharma Cc: Manasi Navare Signed-off-by: Rodrigo Vivi

[Intel-gfx] [PATCH 0/1] HDMI 2.0 on CNL... not working...

I'm just sending this patch for reference here since this is the patch that I believe it is the correct one to get HDMI 2.0 working on CNL. However I'm just getting a blank screen when trying to use HDMI at 4k@60Hz here... Maybe it is just my bad old cable here... maybe I'm missing something...

[Intel-gfx] [PATCH 2/2] drm/i915: Automatic i915_switch_context for legacy

During request construction, after pinning the context we know whether or not we have to emit a context switch. So move this common operation from every caller into i915_gem_request_alloc() itself. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 1/2] drm/i915: Make request's wait-for-space explicit

At the start of building a request, we would wait for roughly enough space to fit the average request (to reduce the likelihood of having to wait and abort partway through request construction). To achieve we would try to begin a 0-length command packet, this just adds extra confusion so make the

Re: [Intel-gfx] [PATCH v2] drm/i915: Implement ReadHitWriteOnlyDisable.

On Fri, Nov 10, 2017 at 09:21:51PM +, Chris Wilson wrote: > Quoting Rafael Antognolli (2017-11-03 18:30:27) > > The workaround for this is described as: > > > > "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if > > RenderSurfaceState.Num_Multisamples == 1, set

[Intel-gfx] ✓ Fi.CI.BAT: success for Import drm UAPI headers.

== Series Details == Series: Import drm UAPI headers. URL : https://patchwork.freedesktop.org/series/33635/ State : success == Summary == IGT patchset tested on top of latest successful build 7d75119b7f23fb49af52463da9bcd62e64fe6a6f lib: Always enable ftrace-dump-on-oops with latest DRM-Tip

Re: [Intel-gfx] [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote: > Sorry this took so long. No worries. > > The vmwgfx part: Reviewed-by: Sinclair Yeh > > I've done some testing and the vmwgfx part looks good. Has Daniel > already taken these or should I put them in my next

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Perf updates

== Series Details == Series: drm/i915: Perf updates URL : https://patchwork.freedesktop.org/series/33631/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-c: pass -> DMESG-WARN (shard-hsw) fdo#102249 Test

[Intel-gfx] [PATCH i-g-t 2/5] tests: Convert to using the imported drm-uapi headers.

Tested by dropping garbage in my libdrm's headers and rebuilding. Signed-off-by: Eric Anholt --- lib/Makefile.am | 5 - meson.build | 2 +- tests/Makefile.am | 1 + 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/lib/Makefile.am b/lib/Makefile.am

[Intel-gfx] [PATCH v4] drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

Since GLK, some plane configuration settings have moved to the PLANE_COLOR_CTL register. Refactor handling of the register to work like PLANE_CTL. This also allows us to fix the set/read of the plane Alpha Mode for GLK+. v2: Adjust ordering of platform checks to be newest->oldest, drop redundant

[Intel-gfx] [PATCH i-g-t 5/5] lib: Use drm-uapi/i915_drm.h instead of local defines.

The MMAP_V2 is replaced by just using MMAP, since the official header has the updated struct. The gem_create_v2 and gem_get_aperture are left as is, because they seem to not be reflected in the UABI header! Signed-off-by: Eric Anholt --- benchmarks/Makefile.am | 6 -

[Intel-gfx] [PATCH i-g-t 4/5] lib: Use the imported uapi's addfb2 defines.

Signed-off-by: Eric Anholt --- lib/ioctl_wrappers.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c index 7ad2b7b007c4..d98e7660a96f 100644 --- a/lib/ioctl_wrappers.c +++ b/lib/ioctl_wrappers.c @@ -1663,7

[Intel-gfx] [PATCH i-g-t 3/5] tests: Remove libdrm_vc4 dependency.

The autotools build retains the configure.ac option, while meson folds vc4 into the default build since we don't have any meson_options.txt to control parts of the build. Signed-off-by: Eric Anholt --- configure.ac | 12 lib/Makefile.am | 2 +-

[Intel-gfx] [PATCH i-g-t 0/5] Import drm UAPI headers.

This series imports the UAPI headers from Linux, like we've been doing in Mesa for vc4 and i965. The advantage is that it lets you build new kernel UAPI and testcases together, without needing libdrm releases, and has a simple rule for producing header updates (avoiding the need for the LOCAL_*

Re: [Intel-gfx] [PATCH v2] drm/i915: Implement ReadHitWriteOnlyDisable.

Quoting Rafael Antognolli (2017-11-03 18:30:27) > The workaround for this is described as: > > "if RenderSurfaceState.Num_Multisamples > 1, disable RCC clock gating if > RenderSurfaceState.Num_Multisamples == 1, set 0x7010[14] = 1" > > Further documentation in the internal bug referenced by the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk (rev3)

== Series Details == Series: drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk (rev3) URL : https://patchwork.freedesktop.org/series/33463/ State : success == Summary == Series 33463v3 drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

Re: [Intel-gfx] [PATCH] drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

On Fri, Nov 10, 2017 at 09:11:01PM +, Ville Syrjälä wrote: > On Fri, Nov 10, 2017 at 12:58:50PM -0800, Rodrigo Vivi wrote: > > Display is not sending a PMRsp when a PMReq is received > > at the same time that all planes are turned off. > > State machine in the dcprunit is stuck in the

Re: [Intel-gfx] [PATCH] drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

On Fri, Nov 10, 2017 at 12:58:50PM -0800, Rodrigo Vivi wrote: > Display is not sending a PMRsp when a PMReq is received > at the same time that all planes are turned off. > State machine in the dcprunit is stuck in the WAIT4DONE > state which means that there is no fill_done. > > WA: disable

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Add a GuC doorbells selftest (rev3)

== Series Details == Series: drm/i915/selftests: Add a GuC doorbells selftest (rev3) URL : https://patchwork.freedesktop.org/series/32655/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-farfromfence: skip -> PASS (shard-hsw) Test

Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: reuse timestamp frequency from device info

Quoting Lionel Landwerlin (2017-11-10 19:08:45) > @@ -3528,7 +3502,7 @@ void i915_perf_init(struct drm_i915_private *dev_priv) > spin_lock_init(_priv->perf.oa.oa_buffer.ptr_lock); > > oa_sample_rate_hard_limit = > -

[Intel-gfx] [PATCH] drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

Display is not sending a PMRsp when a PMReq is received at the same time that all planes are turned off. State machine in the dcprunit is stuck in the WAIT4DONE state which means that there is no fill_done. WA: disable arbiter clock gating, set bit [27] of 0x46530 v2: As Ville pointed out, based

Re: [Intel-gfx] [PATCH 6/7] drm/i915: expose command stream timestamp frequency to userspace

Quoting Lionel Landwerlin (2017-11-10 19:08:44) > +static u64 read_timestamp_frequency(struct drm_i915_private *dev_priv) > +{ > + u64 f12_5_mhz = 1250; > + u64 f19_2_mhz = 1920; > + u64 f24_mhz = 2400; > + > + if (INTEL_GEN(dev_priv) <= 4) { > +

Re: [Intel-gfx] [PATCH] drm/i915: There is only one fault register from GEN8 onwards

Quoting Michel Thierry (2017-11-10 19:01:16) > Until Haswell/Baytrail, the hardware used to have a per engine fault > register (e.g. 0x4094 - render fault register, 0x4194 - media fault > register and so on). But since Broadwell, all these registers were > combined into a singe one and the engine

Re: [Intel-gfx] [PATCH] drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

On Fri, Nov 10, 2017 at 12:24:24PM -0800, Rodrigo Vivi wrote: > On Fri, Nov 10, 2017 at 08:13:44PM +, Ville Syrjälä wrote: > > On Thu, Nov 09, 2017 at 02:26:32PM -0800, Rodrigo Vivi wrote: > > > Display is not sending a PMRsp when a PMReq is received > > > at the same time that all planes are

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: There is only one fault register from Gen8 onwards (rev3)

== Series Details == Series: drm/i915: There is only one fault register from Gen8 onwards (rev3) URL : https://patchwork.freedesktop.org/series/26317/ State : success == Summary == Test kms_flip: Subgroup modeset-vs-vblank-race-interruptible: fail -> PASS

Re: [Intel-gfx] [PATCH] drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

On Fri, Nov 10, 2017 at 08:13:44PM +, Ville Syrjälä wrote: > On Thu, Nov 09, 2017 at 02:26:32PM -0800, Rodrigo Vivi wrote: > > Display is not sending a PMRsp when a PMReq is received > > at the same time that all planes are turned off. > > State machine in the dcprunit is stuck in the

Re: [Intel-gfx] [PATCH] drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

On Thu, Nov 09, 2017 at 02:26:32PM -0800, Rodrigo Vivi wrote: > Display is not sending a PMRsp when a PMReq is received > at the same time that all planes are turned off. > State machine in the dcprunit is stuck in the WAIT4DONE > state which means that there is no fill_done. > > WA: disable

Re: [Intel-gfx] [PATCH v3 09/11] drm/i915: Handle ips_enabled in fastset, v2.

On Fri, Nov 10, 2017 at 02:15:04PM +0100, Daniel Vetter wrote: > On Fri, Nov 10, 2017 at 12:35:01PM +0100, Maarten Lankhorst wrote: > > pre_plane_disable and post_plane_enable handle set ips correctly, > > but if there is no modeset and the ips_enabled value changes > > because of force disabling

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Perf updates

== Series Details == Series: drm/i915: Perf updates URL : https://patchwork.freedesktop.org/series/33631/ State : success == Summary == Series 33631v1 drm/i915: Perf updates https://patchwork.freedesktop.org/api/1.0/series/33631/revisions/1/mbox/ Test gem_exec_suspend: Subgroup

Re: [Intel-gfx] [PATCH] drm/i915: Don't use GEN6_RC_VIDEO_FREQ on gen10+

On Fri, Nov 10, 2017 at 02:29:29PM +, David Weinehall wrote: > GEN6_RC_VIDEO_FREQ is deprecated for >= gen10; > don't try to program it. > > Signed-off-by: David Weinehall > --- > drivers/gpu/drm/i915/intel_pm.c | 11 +++ > 1 file changed, 7

Re: [Intel-gfx] [PATCH v3 10/11] drm/i915: Enable FIFO underrun reporting after initial fastset, v3.

On Fri, Nov 10, 2017 at 12:35:02PM +0100, Maarten Lankhorst wrote: > The firmware may have set up the pipe correctly, but the FIFO > underrun and CRC interrupts are likely not enabled. > > This resulted in debugfs_test.read_all_entries failing on haswell, > because of a timeout when reading the

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Use snprintf to avoid line-break when pretty-printing engines

== Series Details == Series: drm/i915: Use snprintf to avoid line-break when pretty-printing engines URL : https://patchwork.freedesktop.org/series/33617/ State : warning == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 Test

Re: [Intel-gfx] [RESEND v2 1/2] drm/i915: Add connector property to limit max bpc

> -Original Message- > From: Vivi, Rodrigo > Sent: Thursday, November 9, 2017 1:25 PM > To: Sripada, Radhakrishna > Cc: intel-gfx@lists.freedesktop.org; Zanoni, Paulo R > > Subject: Re: [Intel-gfx] [RESEND v2 1/2] drm/i915: Add

Re: [Intel-gfx] [PATCH 4/7] drm/i915: fix register naming

On 10 November 2017 at 19:08, Lionel Landwerlin wrote: > This name was added with the whitelisting of registers for building up OA > configs. It is contained in a range gen8 whitelist : > >addr >= RPM_CONFIG0.reg && addr <= NOA_CONFIG(8).reg > > Hence why the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Add a GuC doorbells selftest (rev3)

== Series Details == Series: drm/i915/selftests: Add a GuC doorbells selftest (rev3) URL : https://patchwork.freedesktop.org/series/32655/ State : success == Summary == Series 32655v3 drm/i915/selftests: Add a GuC doorbells selftest

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: There is only one fault register from Gen8 onwards (rev3)

== Series Details == Series: drm/i915: There is only one fault register from Gen8 onwards (rev3) URL : https://patchwork.freedesktop.org/series/26317/ State : success == Summary == Series 26317v3 drm/i915: There is only one fault register from Gen8 onwards

Re: [Intel-gfx] [PATCH v3] drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

On Fri, Nov 03, 2017 at 01:43:54PM -0700, James Ausmus wrote: > Since GLK, some plane configuration settings have moved to the > PLANE_COLOR_CTL register. Refactor handling of the register to work like > PLANE_CTL. This also allows us to fix the set/read of the plane Alpha > Mode for GLK+. > >

[Intel-gfx] [PATCH 5/7] drm/i915/perf: enable perf support on CNL

This adds new registers to the whitelist to configs emitted from userspace. Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/i915_oa_cnl.c | 121

[Intel-gfx] [PATCH 7/7] drm/i915/perf: reuse timestamp frequency from device info

Now that we have this stored in the device info, we can drop it from perf part of the driver. Note that this requires to init perf after we've computed the frequency, hence why we move i915_perf_init() from i915_driver_init_early() to after intel_device_info_runtime_init(). Signed-off-by: Lionel

  1   2   3   >