Re: [Intel-gfx] [PATCH v2] drm/i915: Generalize transcoder looping

On Wed, 2017-11-08 at 21:54 +0200, Ville Syrjälä wrote: > On Mon, Nov 06, 2017 at 03:29:45PM +0200, Mika Kahola wrote: > > > > To make looping through transcoders in intel_ddi.c more generic, > > let's switch > > to use 'for_each_pipe()' macro to do this. > > > > v2: Add a notion that we are

Re: [Intel-gfx] [PATCH] drm/i915/: Initialise trans_min for skl_compute_transition_wm()

Hi, On Thursday 09 November 2017 01:30 AM, Ville Syrjälä wrote: On Wed, Nov 08, 2017 at 10:39:59AM +0530, Mahesh Kumar wrote: Hi, On Tuesday 07 November 2017 11:57 PM, Chris Wilson wrote: clang spots drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is used

Re: [Intel-gfx] [PATCH 00/10] drm/i915: Nuke dig_port->port and assorted cleanups

On Wed, 2017-11-01 at 11:55 +0200, Jani Nikula wrote: > On Tue, 31 Oct 2017, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > The main attraction of this series is removal of > > intel_digital_port->port. Ever since the

Re: [Intel-gfx] [PATCH 10/10] drm/i915: Clean up DP code local variables and calling conventions

nits below. On Tue, 2017-10-31 at 22:51 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Eliminate a ton of pointless 'dev' variables in the DP code, and pass > around 'dev_priv' instead of 'dev'. > > Signed-off-by: Ville Syrjälä

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [RESEND,v2,1/2] drm/i915: Add connector property to limit max bpc

== Series Details == Series: series starting with [RESEND,v2,1/2] drm/i915: Add connector property to limit max bpc URL : https://patchwork.freedesktop.org/series/33466/ State : failure == Summary == Test kms_cursor_legacy: Subgroup flip-vs-cursor-varying-size: pass

Re: [Intel-gfx] [PATCH 08/10] drm/i915: Nuke intel_digital_port->port

On Tue, 2017-10-31 at 22:51 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Remove intel_digital_port->port and replace its users with > intel_encoder->port. intel_encoder->port is a superset of > intel_digital_port->port, and it works correctly even for >

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Eliminate some encoder->crtc usage from DSI code

On Tue, 2017-10-31 at 22:51 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Extract the current crtc from the crtc state rather than via > the legacy encoder->crtc pointer whenever possible. > > Signed-off-by: Ville Syrjälä >

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Eliminate some encoder->crtc usage from DP code

On Tue, 2017-10-31 at 22:51 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Extract the current crtc from the crtc state rather than via > the legacy encoder->crtc pointer whenever possible. > There are still some encoder->crtc remaining. How much of a

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

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

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

Hi Dave, I know it is time to wrap-up, but we have 2 fixes still that seems important for a stable 4.14. drm-intel-fixes-2017-11-08: - Fix possible NULL dereference (Chris). - Avoid miss usage of syncobj by rejecting unknown flags (Tvrtko). Thanks, Rodrigo. The following changes since commit

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RESEND,v2,1/2] drm/i915: Add connector property to limit max bpc

== Series Details == Series: series starting with [RESEND,v2,1/2] drm/i915: Add connector property to limit max bpc URL : https://patchwork.freedesktop.org/series/33466/ State : success == Summary == Series 33466v1 series starting with [RESEND,v2,1/2] drm/i915: Add connector property to

[Intel-gfx] ✓ Fi.CI.IGT: success for Refactor HW workaround code (rev7)

== Series Details == Series: Refactor HW workaround code (rev7) URL : https://patchwork.freedesktop.org/series/31611/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-oldfb-with-reset-render-a: pass -> DMESG-WARN (shard-hsw) fdo#102249

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

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

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk

== Series Details == Series: drm/i915: Display WA #1185 WaDisableDARBFClkGating:cnl, glk URL : https://patchwork.freedesktop.org/series/33463/ State : failure == Summary == Test kms_cursor_crc: Subgroup cursor-256x256-suspend: pass -> FAIL (shard-hsw) Test

[Intel-gfx] [RESEND v2 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp

From: "Sripada, Radhakrishna" Use the newly added "max bpc" connector property to limit pipe bpp. Cc: Ville Syrjälä Cc: Paulo Zanoni Cc: Manasi Navare Signed-off-by:

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

From: "Sripada, Radhakrishna" At times 12bpc HDMI cannot be driven due to faulty cables, dongles level shifters etc. To workaround them we may need to drive the output at a lower bpc. Currently the user space does not have a way to limit the bpc. The default bpc

[Intel-gfx] ✓ Fi.CI.BAT: success for Refactor HW workaround code (rev7)

== Series Details == Series: Refactor HW workaround code (rev7) URL : https://patchwork.freedesktop.org/series/31611/ State : success == Summary == Series 31611v7 Refactor HW workaround code https://patchwork.freedesktop.org/api/1.0/series/31611/revisions/7/mbox/ Test chamelium:

[Intel-gfx] [RFC PATCH 4/6] drm/i915: Move WA BB stuff to the workarounds file as well

Since we are trying to put all WA stuff together, do not forget about the BB WAs. v2: s/intel_bb_workarounds_init/intel_engine_init_bb_workarounds (Chris) v3: Rebased to before the WAs are stored Signed-off-by: Oscar Mateo Cc: Mika Kuoppala

[Intel-gfx] [RFC PATCH 5/6] drm/i915: Create a new category of display WAs

Display workarounds do not need to be re-applied on a GPU reset (this is, in Ville's words: "at the very least wasted effort [...] and could even be actively harmful in case we end up clobbering something the current display configuration depends on"). Therefore, they have to be applied in a

[Intel-gfx] [RFC PATCH 3/6] drm/i915: Split out functions for different kinds of workarounds

There are different kind of workarounds (those that modify registers that live in the context image, those that modify global registers, those that whitelist registers, etc...) and they have different requirements in terms of where they are applied and how. Also, by splitting them apart, it should

[Intel-gfx] [RFC PATCH 1/6] drm/i915: Remove Gen9 WAs with no effect

GEN8_CONFIG0 (0xD00) is a protected by a lock (bit 31) which is set by the BIOS, so there is no way we can enable the three chicken bits mandated by the WA (the BIOS should be doing it instead). v2: Rebased v3: Standalone patch Signed-off-by: Oscar Mateo Cc: Chris Wilson

[Intel-gfx] [RFC PATCH 6/6] drm/i915: Classify GT & Display WAs correctly

Move GT WAs appropiately from the current xxx_disp_workarounds_apply function to the corresponding xxx_gt_workarounds_apply one. FIXME: It looks like Chris has found some WAs that actually live in the context image. We need to move these to their rightful xxx_workarounds_init function.

[Intel-gfx] [RFC PATCH 2/6] drm/i915: Move a bunch of workaround-related code to its own file

This has grown to be a sizable amount of code, so move it to its own file before we try to refactor anything. For the moment, we are leaving behind the WA BB code and the WAs that get applied (incorrectly) in init_clock_gating, but we will deal with it later. v2: Use intel_ prefix for code that

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

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 file (and classified correctly according to the type of WA). From previous versions of these series:

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

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

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

PM Rsp is not sent when plane is turned off at around the time that a PM fill Req is received by display WA: disable arbiter clock gating, set bit [27] of 0x46530 Cc: Radhakrishna Sripada Cc: Imre Deak Signed-off-by: Rodrigo Vivi

[Intel-gfx] ✗ Fi.CI.IGT: warning for Revert "tests/kms_flip: Make flip-vs-panning-vs-hang change DSPSURF"

== Series Details == Series: Revert "tests/kms_flip: Make flip-vs-panning-vs-hang change DSPSURF" URL : https://patchwork.freedesktop.org/series/33451/ State : warning == Summary == Test drv_module_reload: Subgroup basic-reload-inject: pass -> DMESG-WARN

Re: [Intel-gfx] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

Ville Syrjälä writes: > On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: >> Ville Syrjala writes: >> >> > From: Ville Syrjälä >> > >> > Apparently some sinks look at the YQ bits even when

[Intel-gfx] ✓ Fi.CI.IGT: success for igt/gem_userptr: Exercise new PROBE | POPULATE flags

== Series Details == Series: igt/gem_userptr: Exercise new PROBE | POPULATE flags URL : https://patchwork.freedesktop.org/series/33448/ State : success == Summary == Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-a: dmesg-warn -> PASS

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/5] drm/i915/guc: Split GuC firmware xfer function into clear steps

Quoting Patchwork (2017-11-03 15:52:24) > == Series Details == > > Series: series starting with [v4,1/5] drm/i915/guc: Split GuC firmware xfer > function into clear steps > URL : https://patchwork.freedesktop.org/series/33135/ > State : success > > == Summary == > > Series 33135v1 series

Re: [Intel-gfx] [PATCH v4 2/5] drm/i915/guc: Wait for ucode DMA transfer completion

Quoting Michal Wajdeczko (2017-11-08 21:17:35) > On Wed, 08 Nov 2017 21:36:25 +0100, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2017-11-03 15:18:13) > >> We silently assumed that DMA transfer will be completed > >> within assumed timeout and thus we were

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

On Wed, 08 Nov 2017 09:25:49 +0100 Gerd Hoffmann wrote: > Hi, > > > Should we then specify the error code for "head doesn't exist" vs > > "head > > doesn't support dmabuf", with the former taking precedence?  Perhaps > > -ENODEV vs -EINVAL. > > NODEV for "head doesn't

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

== Series Details == Series: drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks URL : https://patchwork.freedesktop.org/series/33432/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 +1 Test

Re: [Intel-gfx] [PATCH v4 2/5] drm/i915/guc: Wait for ucode DMA transfer completion

On Wed, 08 Nov 2017 21:36:25 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2017-11-03 15:18:13) We silently assumed that DMA transfer will be completed within assumed timeout and thus we were waiting only at last step for GuC to become ready. Add

[Intel-gfx] ✗ Fi.CI.BAT: failure for kms_atomic_transition: Split out modeset tests on internal panels (rev3)

== Series Details == Series: kms_atomic_transition: Split out modeset tests on internal panels (rev3) URL : https://patchwork.freedesktop.org/series/33052/ State : failure == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836

Re: [Intel-gfx] [PATCH] drm/i915: sync dp link status checks against atomic commmits

On Wed, Nov 08, 2017 at 10:09:32AM -0800, Manasi Navare wrote: > On Wed, Nov 08, 2017 at 02:28:23PM +0100, Daniel Vetter wrote: > > On Wed, Nov 08, 2017 at 03:26:15PM +0200, Ville Syrjälä wrote: > > > On Wed, Nov 08, 2017 at 02:11:46PM +0100, Daniel Vetter wrote: > > > > On Wed, Nov 08, 2017 at

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/userptr: Probe existence of backing struct pages upon creation

== Series Details == Series: series starting with [1/2] drm/i915/userptr: Probe existence of backing struct pages upon creation URL : https://patchwork.freedesktop.org/series/33449/ State : success == Summary == Test perf: Subgroup polling: fail -> PASS

[Intel-gfx] [PATCH] drm/i915/intel_sdvo: mark expected switch fall-throughs

In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 141432 Addresses-Coverity-ID: 141433 Addresses-Coverity-ID: 141434 Addresses-Coverity-ID: 141435 Addresses-Coverity-ID: 141436 Signed-off-by: Gustavo A. R. Silva

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

On Fri, Nov 03, 2017 at 06:30:27PM +, Rafael Antognolli wrote: > 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

Re: [Intel-gfx] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: > Ville Syrjala writes: > > > From: Ville Syrjälä > > > > Apparently some sinks look at the YQ bits even when receiving RGB, > > and they get somehow confused when they see

Re: [Intel-gfx] [PATCH v4 2/5] drm/i915/guc: Wait for ucode DMA transfer completion

Quoting Michal Wajdeczko (2017-11-03 15:18:13) > We silently assumed that DMA transfer will be completed > within assumed timeout and thus we were waiting only at > last step for GuC to become ready. Add intermediate wait > to catch unexpected delays in DMA transfer. > > Signed-off-by: Michal

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "tests/kms_flip: Make flip-vs-panning-vs-hang change DSPSURF"

== Series Details == Series: Revert "tests/kms_flip: Make flip-vs-panning-vs-hang change DSPSURF" URL : https://patchwork.freedesktop.org/series/33451/ State : success == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836

Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Add Guc/HuC firmware details to error state

On Wed, 08 Nov 2017 13:20:16 +0100, Michal Wajdeczko wrote: On Wed, 08 Nov 2017 12:27:20 +0100, Joonas Lahtinen wrote: On Mon, 2017-11-06 at 14:15 +, Chris Wilson wrote: Quoting Michal Wajdeczko (2017-10-26 18:36:55) >

Re: [Intel-gfx] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

Ville Syrjala writes: > From: Ville Syrjälä > > Apparently some sinks look at the YQ bits even when receiving RGB, > and they get somehow confused when they see a non-zero YQ value. > So we can't just blindly follow CEA-861-F and set

[Intel-gfx] ✓ Fi.CI.IGT: success for tests: add query information tests

== Series Details == Series: tests: add query information tests URL : https://patchwork.freedesktop.org/series/33437/ State : success == Summary == Test kms_vblank: Subgroup accuracy-idle: pass -> FAIL (shard-hsw) fdo#102583 Test drv_module_reload:

[Intel-gfx] ✗ Fi.CI.IGT: warning for intel_gvtg_test: Handle system(3) return value.

== Series Details == Series: intel_gvtg_test: Handle system(3) return value. URL : https://patchwork.freedesktop.org/series/33422/ State : warning == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 +1 Test kms_busy:

[Intel-gfx] ✓ Fi.CI.IGT: success for lib: Always enable ftrace-dump-on-oops (rev2)

== Series Details == Series: lib: Always enable ftrace-dump-on-oops (rev2) URL : https://patchwork.freedesktop.org/series/33418/ State : success == Summary == Test perf: Subgroup polling: fail -> PASS (shard-hsw) fdo#102252 +1 Test kms_busy:

[Intel-gfx] ✗ Fi.CI.IGT: failure for tests: remove gem_ctx_param

== Series Details == Series: tests: remove gem_ctx_param URL : https://patchwork.freedesktop.org/series/33394/ State : failure == Summary == Test drv_module_reload: Subgroup basic-no-display: pass -> DMESG-WARN (shard-hsw) fdo#102707 Test kms_busy:

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

On Fri, Nov 03, 2017 at 06:30:27PM +, Rafael Antognolli wrote: > 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

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: introduce query information

== Series Details == Series: drm/i915: introduce query information URL : https://patchwork.freedesktop.org/series/33436/ State : success == Summary == Test perf: Subgroup blocking: fail -> PASS (shard-hsw) fdo#102252 +1 fdo#102252

Re: [Intel-gfx] [PATCH 1/2] drm/atomic-helper: always track connector commits, too

On Wed, Nov 08, 2017 at 05:21:04PM +0200, Ville Syrjälä wrote: > On Wed, Nov 08, 2017 at 11:54:49AM +0100, Daniel Vetter wrote: > > It's useful for syncing async connector work like link retraining. > > > > Cc: Manasi Navare > > Cc: Maarten Lankhorst

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_userptr: Exercise new PROBE | POPULATE flags

== Series Details == Series: igt/gem_userptr: Exercise new PROBE | POPULATE flags URL : https://patchwork.freedesktop.org/series/33448/ State : success == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836 tests/kms_fbcon_fbt: Report

Re: [Intel-gfx] [PATCH] drm/i915/: Initialise trans_min for skl_compute_transition_wm()

On Wed, Nov 08, 2017 at 10:39:59AM +0530, Mahesh Kumar wrote: > Hi, > > > On Tuesday 07 November 2017 11:57 PM, Chris Wilson wrote: > > clang spots > > > > drivers/gpu/drm/i915/intel_pm.c:4655:6: warning: variable 'trans_min' is > > used uninitialized whenever 'if' condition is false > >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Move init_clock_gating() back to where it was (rev2)

== Series Details == Series: drm/i915: Move init_clock_gating() back to where it was (rev2) URL : https://patchwork.freedesktop.org/series/33124/ State : success == Summary == Test kms_flip: Subgroup plain-flip-fb-recreate-interruptible: pass -> SKIP

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5,1/9] drm/i915: Include engine state on detecting a missed breadcrumb/seqno

Quoting Patchwork (2017-11-08 19:45:20) > == Series Details == > > Series: series starting with [v5,1/9] drm/i915: Include engine state on > detecting a missed breadcrumb/seqno > URL : https://patchwork.freedesktop.org/series/33452/ > State : failure > > == Summary == > > CHK

Re: [Intel-gfx] [PATCH v2] drm/i915: Generalize transcoder looping

On Mon, Nov 06, 2017 at 03:29:45PM +0200, Mika Kahola wrote: > To make looping through transcoders in intel_ddi.c more generic, let's switch > to use 'for_each_pipe()' macro to do this. > > v2: Add a notion that we are dealing with transcoders instead of pipes (Jani) > > Signed-off-by: Mika

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5,1/9] drm/i915: Include engine state on detecting a missed breadcrumb/seqno

== Series Details == Series: series starting with [v5,1/9] drm/i915: Include engine state on detecting a missed breadcrumb/seqno URL : https://patchwork.freedesktop.org/series/33452/ State : failure == Summary == CHK include/config/kernel.release CHK

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

== Series Details == Series: drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks URL : https://patchwork.freedesktop.org/series/33432/ State : success == Summary == Series 33432v1 drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

Re: [Intel-gfx] [PATCH v5 5/9] drm/i915: Move intel_init_clock_gating() to i915_gem_init()

On Wed, Nov 08, 2017 at 07:33:05PM +, Chris Wilson wrote: > Quoting Ville Syrjälä (2017-11-08 19:27:41) > > On Wed, Nov 08, 2017 at 07:14:58PM +, Chris Wilson wrote: > > > +out_unlock: > > > if (ret == -EIO) { > > > /* Allow engine initialisation to fail by marking the

Re: [Intel-gfx] [PATCH v5 5/9] drm/i915: Move intel_init_clock_gating() to i915_gem_init()

Quoting Ville Syrjälä (2017-11-08 19:27:41) > On Wed, Nov 08, 2017 at 07:14:58PM +, Chris Wilson wrote: > > +out_unlock: > > if (ret == -EIO) { > > /* Allow engine initialisation to fail by marking the GPU as > >* wedged. But we only want to do this where

[Intel-gfx] [PATCH i-g-t v3] kms_atomic_transition: Split out modeset tests on internal panels

Doing modeset on internal panels may have a considerable overhead due to the panel specific power sequencing delays. To avoid long test runtimes in CI split out the testing of internal panels from the plane modeset subtests and test only a reduced number of plane combinations on these: where only

Re: [Intel-gfx] [PATCH v5 5/9] drm/i915: Move intel_init_clock_gating() to i915_gem_init()

On Wed, Nov 08, 2017 at 07:14:58PM +, Chris Wilson wrote: > Despite its name intel_init_clock_gating applies both display clock gating > workarounds; GT mmio workarounds and the occasional GT power context > workaround. Worse, sometimes it includes a context register workaround > which we need

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/userptr: Probe existence of backing struct pages upon creation

== Series Details == Series: series starting with [1/2] drm/i915/userptr: Probe existence of backing struct pages upon creation URL : https://patchwork.freedesktop.org/series/33449/ State : success == Summary == Series 33449v1 series starting with [1/2] drm/i915/userptr: Probe existence of

[Intel-gfx] [PATCH v5 8/9] drm/i915: Record the default hw state after reset upon load

Take a copy of the HW state after a reset upon module loading by executing a context switch from a blank context to the kernel context, thus saving the default hw state over the blank context image. We can then use the default hw state to initialise any future context, ensuring that each starts

[Intel-gfx] [PATCH v5 7/9] drm/i915: Mark the context state as dirty/written

In the next few patches, we will want to both copy out of the context image and write a valid image into a new context. To be completely safe, we should then couple in our domain tracking to ensure that we don't have any issues with stale data remaining in unwanted cachelines. Historically, we

[Intel-gfx] [PATCH v5 5/9] drm/i915: Move intel_init_clock_gating() to i915_gem_init()

Despite its name intel_init_clock_gating applies both display clock gating workarounds; GT mmio workarounds and the occasional GT power context workaround. Worse, sometimes it includes a context register workaround which we need to apply before we record the default HW state for all contexts.

[Intel-gfx] [PATCH v5 9/9] drm/i915: Stop caching the "golden" renderstate

As we now record the default HW state and so only emit the "golden" renderstate once to prepare the HW, there is no advantage in keeping the renderstate batch around as it will never be used again. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v5 6/9] drm/i915: Inline intel_modeset_gem_init()

intel_modeset_gem_init() now only sets up the legacy overlay, so let's remove the function and call the setup directly during driver load. This should help us find a better point in the initialisation sequence for it later. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH v5 1/9] drm/i915: Include engine state on detecting a missed breadcrumb/seqno

Now that we have a common engine state pretty printer, we can use that instead of the adhoc information printed when we miss a breadcrumb. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Tvrtko Ursulin ---

[Intel-gfx] [PATCH v5 3/9] drm/i915: Force the switch to the i915->kernel_context

In the next few patches, we will have a hard requirement that we emit a context-switch to the perma-pinned i915->kernel_context (so that we can save the HW state using that context-switch). As the first context itself may be classed as a kernel context, we want to be explicit in our comparison.

[Intel-gfx] [PATCH v5 4/9] drm/i915: Move GT powersaving init to i915_gem_init()

GT powersaving is tightly coupled to the request infrastructure. To avoid complications with the order of initialisation in the next patch (where we want to send requests to hw during GEM init) move the powersaving initialisation into the purview of i915_gem_init(). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v5 2/9] drm/i915: Define an engine class enum for the uABI

From: Tvrtko Ursulin We want to be able to report back to userspace details about an engine's class, and in return for userspace to be able to request actions regarding certain classes of engines. To isolate the uABI from any variations between hw generations, we define

[Intel-gfx] Context isolation

Rebase and resend and mmio workarounds moved (see patch 5/9), and they are very sensitive to init-ordering... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] Revert "tests/kms_flip: Make flip-vs-panning-vs-hang change DSPSURF"

From: Maarten Lankhorst This reverts commit 7296e09ee7f17e6d564e52cf64ee900670849429. This commit was accidentally applied twice, the first time in commit e4ba3b75e6de35483b2edea21ceda145ef0b3311. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [PATCH 2/2] drm/i915/userptr: Add a flag to populate the userptr on creation

Both of these patches need I915_PARAM_HAS_USERPTR_WHATEVER queries. On Wed, Nov 8, 2017 at 10:51 AM, Chris Wilson wrote: > Acquiring the backing struct pages for the userptr range is not free; > the first client for userptr would insist on frequently creating userptr >

[Intel-gfx] [PATCH 1/2] drm/i915/userptr: Probe existence of backing struct pages upon creation

Jason Ekstrand requested a more efficient method than userptr+set-domain to determine if the userptr object was backed by a complete set of pages upon creation. To be more efficient than simply populating the userptr using get_user_pages() (as done by the call to set-domain or execbuf), we can

[Intel-gfx] [PATCH 2/2] drm/i915/userptr: Add a flag to populate the userptr on creation

Acquiring the backing struct pages for the userptr range is not free; the first client for userptr would insist on frequently creating userptr objects ahead of time and not use them. For that first client, deferring the cost of populating the userptr (calling get_user_pages()) to the actual

[Intel-gfx] [PATCH igt] igt/gem_userptr: Exercise new PROBE | POPULATE flags

Exercise new API to probe that the userptr range is valid (backed by struct pages and not pfn) or to populate the userptr upon creation (by calling get_user_pages() on the range). Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Michał

[Intel-gfx] ✗ Fi.CI.BAT: warning for tests: add query information tests

== Series Details == Series: tests: add query information tests URL : https://patchwork.freedesktop.org/series/33437/ State : warning == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836 tests/kms_fbcon_fbt: Report fbc_status on error

[Intel-gfx] ✗ Fi.CI.BAT: warning for intel_gvtg_test: Handle system(3) return value.

== Series Details == Series: intel_gvtg_test: Handle system(3) return value. URL : https://patchwork.freedesktop.org/series/33422/ State : warning == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836 tests/kms_fbcon_fbt: Report

Re: [Intel-gfx] [PATCH] drm/i915: sync dp link status checks against atomic commmits

On Wed, Nov 08, 2017 at 02:28:23PM +0100, Daniel Vetter wrote: > On Wed, Nov 08, 2017 at 03:26:15PM +0200, Ville Syrjälä wrote: > > On Wed, Nov 08, 2017 at 02:11:46PM +0100, Daniel Vetter wrote: > > > On Wed, Nov 08, 2017 at 03:04:58PM +0200, Ville Syrjälä wrote: > > > > On Wed, Nov 08, 2017 at

[Intel-gfx] ✓ Fi.CI.BAT: success for lib: Always enable ftrace-dump-on-oops (rev2)

== Series Details == Series: lib: Always enable ftrace-dump-on-oops (rev2) URL : https://patchwork.freedesktop.org/series/33418/ State : success == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836 tests/kms_fbcon_fbt: Report fbc_status

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Enable FIFO underrun reporting after initial fastset

Op 08-11-17 om 16:38 schreef Daniel Vetter: > On Wed, Nov 08, 2017 at 10:29:21AM +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

Re: [Intel-gfx] [PATCH v2] drm/i915: Move init_clock_gating() back to where it was

On Wed, Nov 08, 2017 at 04:18:27PM +, Chris Wilson wrote: > Quoting Ville Syrjala (2017-11-08 13:35:55) > > From: Ville Syrjälä > > > > Apparently setting up a bunch of GT registers before we've properly > > initialized the rest of the GT hardware leads to

[Intel-gfx] ✗ Fi.CI.BAT: failure for Assorted compile warnings fixes

== Series Details == Series: Assorted compile warnings fixes URL : https://patchwork.freedesktop.org/series/33417/ State : failure == Summary == IGT patchset build failed on latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836 tests/kms_fbcon_fbt: Report fbc_status on error make

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

Is there anyone with spare time to review this patch? It's kind of required for userspace to make sense of timestamps on CNL. Thanks a lot, - Lionel On 02/11/17 16:29, Lionel Landwerlin wrote: We use to have this fixed per generation, but starting with CNL userspace cannot tell just off the

[Intel-gfx] ✗ Fi.CI.BAT: failure for gem_ctx_param: Update for context priorities

== Series Details == Series: gem_ctx_param: Update for context priorities URL : https://patchwork.freedesktop.org/series/33408/ State : failure == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836 tests/kms_fbcon_fbt: Report fbc_status

[Intel-gfx] ✓ Fi.CI.BAT: success for tests: remove gem_ctx_param

== Series Details == Series: tests: remove gem_ctx_param URL : https://patchwork.freedesktop.org/series/33394/ State : success == Summary == IGT patchset tested on top of latest successful build 9fe5a9a3de9e2ce345d5967a1e10a9a586b19836 tests/kms_fbcon_fbt: Report fbc_status on error with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: introduce query information

== Series Details == Series: drm/i915: introduce query information URL : https://patchwork.freedesktop.org/series/33436/ State : success == Summary == Series 33436v1 drm/i915: introduce query information https://patchwork.freedesktop.org/api/1.0/series/33436/revisions/1/mbox/ Test gem_sync:

Re: [Intel-gfx] [PATCH v2] drm/i915: Move init_clock_gating() back to where it was

Quoting Chris Wilson (2017-11-08 16:18:27) > Quoting Ville Syrjala (2017-11-08 13:35:55) > > From: Ville Syrjälä > > > > Apparently setting up a bunch of GT registers before we've properly > > initialized the rest of the GT hardware leads to these setting being > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move init_clock_gating() back to where it was (rev2)

== Series Details == Series: drm/i915: Move init_clock_gating() back to where it was (rev2) URL : https://patchwork.freedesktop.org/series/33124/ State : success == Summary == Series 33124v2 drm/i915: Move init_clock_gating() back to where it was

[Intel-gfx] [PATCH i-g-t 3/3] tests/query_info: add topology query tests

We can verify that topology is consistent with previous getparam like EU_TOTAL. We also verify that CS timestamp frequency is always filled. v2: Use v2 of kernel uapi (Lionel) Fix Gen < 8 issue v3: Use query info uAPI (Lionel) Signed-off-by: Lionel Landwerlin

[Intel-gfx] [PATCH i-g-t 2/3] tests/query_info: tests sending commands to queried engines

From: Tvrtko Ursulin Submit a few valid and invalid no-op batches using the new class- instance execbuf interface. Signed-off-by: Tvrtko Ursulin --- tests/query_info.c | 67 ++ 1 file

[Intel-gfx] [PATCH i-g-t 0/3] tests: add query information tests

Hi, These are the tests related to the query information uAPI we would like to expose. Cheers, Lionel Landwerlin (1): tests/query_info: add topology query tests Tvrtko Ursulin (2): tests: Test the new query info uAPI tests/query_info: tests sending commands to queried engines

[Intel-gfx] [PATCH i-g-t 1/3] tests: Test the new query info uAPI

From: Tvrtko Ursulin Test that the new query info uAPI. Signed-off-by: Tvrtko Ursulin Signed-off-by: Lionel Landwerlin --- tests/Makefile.sources | 1 + tests/meson.build | 1 + tests/query_info.c

[Intel-gfx] [PATCH 4/4] drm/i915: expose rcs topology through discovery uAPI

With the introduction of asymetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts of the GPU with the OA unit, because counters

[Intel-gfx] [PATCH 0/4] drm/i915: introduce query information

Hi, This series is based off work that Tvrtko started, initially for exposing the engines available to userspace. I've added the topology information I would like to expose for normalizing the performance counters. Cheers, Lionel Landwerlin (3): drm/i915: store all subslice masks

[Intel-gfx] [PATCH 3/4] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

Now that we have that information in topology fields, let's just reused it. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_debugfs.c | 26 ++ 1 file changed, 10 insertions(+), 16 deletions(-) diff --git

[Intel-gfx] [PATCH 1/4] drm/i915: introduce query info uAPI

From: Tvrtko Ursulin Query info uAPI allows userspace to probe for a number of properties of the GPU. This partially removes the need for userspace to maintain the internal PCI id based database (as well as code duplication across userspace components). This first

[Intel-gfx] [PATCH 2/4] drm/i915: store all subslice masks

Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all

  1   2   3   >