Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities. For panels that use this

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran: > On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote: >> Similar to enable_fbc, enable_psr was ignored at runtime if it was >> changed. The easiest fix is to pretend enable_psr is ignored at >> configure time, and never activate it for

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Move hdcp msg detection into shim

On Tuesday 27 February 2018 04:20 AM, Chris Wilson wrote: Quoting Ramalingam C (2018-02-26 17:12:39) DP and HDMI HDCP specifications are varying with respect to detecting the R0 and ksv_fifo availability. DP will produce CP_IRQ and set a bit for indicating the R0 and FIFO_READY status.

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/uc: Start preparing GuC/HuC for reset

On 3/5/2018 8:13 PM, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-03-05 14:29:16) Right after GPU reset there will be a small window of time during which some of GuC/HuC fields will still show state before reset. Let's start to fix that by sanitizing firmware status as we will use it

[Intel-gfx] ✓ Fi.CI.IGT: success for igt: Add gem_ctx_freq to exercise requesting freq on a ctx

== Series Details == Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx URL : https://patchwork.freedesktop.org/series/39571/ State : success == Summary == Known issues: Test gem_softpin: Subgroup noreloc-s3: skip -> PASS (shard-snb)

[Intel-gfx] [PULL] gvt-next for 4.17

Hi, Here's gvt-next update for 4.17. Biggest update is for huge code refactor of shadow ppgtt from Changbin which is the most obscured part, and with KBL context save/restore improvement from Weinan, with other fixes. Thanks. -- The following changes since commit

[Intel-gfx] ✓ Fi.CI.BAT: success for igt: Add gem_ctx_freq to exercise requesting freq on a ctx

== Series Details == Series: igt: Add gem_ctx_freq to exercise requesting freq on a ctx URL : https://patchwork.freedesktop.org/series/39571/ State : success == Summary == IGT patchset tested on top of latest successful build b4689dce36d0fbd9aec70d5a4b077c43a6b9c254 igt: Remove

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. Signed-off-by: Chris Wilson --- A few more test ideas. --- tests/Makefile.am | 1 + tests/Makefile.sources | 1 +

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Quoting Antonio Argenziano (2018-03-08 00:55:47) > > > On 07/03/18 14:49, Chris Wilson wrote: > > +static void single(int fd, const struct intel_execution_engine *e) > > +{ > > + const unsigned int engine = e->exec_id | e->flags; > > + uint32_t ctx = gem_context_create(fd); > > +

Re: [Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

On 07/03/18 14:49, Chris Wilson wrote: Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. Signed-off-by: Chris Wilson --- tests/Makefile.am | 2 +- tests/Makefile.sources | 1

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

Hi Matt, On Wed, Mar 07, 2018 at 04:28:51PM -0800, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/sun4i/sun4i_tcon.c between commit: e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit") from the drm-misc-fixes tree and commit: 34d698f6e349 ("drm/sun4i: Add has_channel_0 TCON

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

Hey Matt, Your patch doesn't build. Missing semicolon, dude. On Wed, Mar 07, 2018 at 04:13:58PM -0800, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Add Wa_2201832410 (rev2)

== Series Details == Series: drm/i915/cnl: Add Wa_2201832410 (rev2) URL : https://patchwork.freedesktop.org/series/39408/ State : success == Summary == Possible new issues: Test kms_vblank: Subgroup pipe-b-ts-continuation-suspend: incomplete -> PASS

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

On Wed, 2018-03-07 at 15:43 -0800, Rodrigo Vivi wrote: > On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote: > > On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote: > > > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote: > > > > Quoting Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 07, 2018 at 03:44:09PM -0800, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities.

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. Signed-off-by: Chris Wilson --- tests/Makefile.am | 1 + tests/Makefile.sources | 1 + tests/gem_ctx_freq.c | 338

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

On Wed, Mar 07, 2018 at 02:48:05PM -0800, Rafael Antognolli wrote: > Matches bspec. > > Reviewed-by: Rafael Antognolli pushed, thanks > > On Wed, Mar 07, 2018 at 02:09:12PM -0800, Rodrigo Vivi wrote: > > "Clock gating bug in GWL may not clear barrier state when an

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 7, 2018 at 6:44 PM, wrote: > From: Matt Atwood > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 > bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended > receiver capabilities. For panels

[Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

From: Matt Atwood DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8 bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended receiver capabilities. For panels that use this new feature wait interval would be increased by 512 ms, when

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

On Wed, Mar 07, 2018 at 03:23:13PM -0800, Rodrigo Vivi wrote: > On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote: > > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote: > > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19) > > > > DRM_IOCTL_MODE_CURSOR results in

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Add Wa_2201832410 (rev2)

== Series Details == Series: drm/i915/cnl: Add Wa_2201832410 (rev2) URL : https://patchwork.freedesktop.org/series/39408/ State : success == Summary == Series 39408v2 drm/i915/cnl: Add Wa_2201832410 https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/2/mbox/ Known issues:

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

On Wed, Mar 07, 2018 at 11:10:35PM +, Pandiyan, Dhinakaran wrote: > On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote: > > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19) > > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor > > > plane MMIOs are written to. But this

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

On Wed, Mar 07, 2018 at 10:54:28PM +, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2018-03-07 at 14:46 -0800, Rodrigo Vivi wrote: > > On Tue, Mar 06, 2018 at 07:34:18PM -0800, Dhinakaran Pandiyan wrote: > > > From: "Pandiyan, Dhinakaran" > > > > > >

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

On Wed, 2018-03-07 at 22:53 +, Chris Wilson wrote: > Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19) > > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor > > plane MMIOs are written to. But this flush should not be necessary for > > PSR as hardware tracking triggers PSR

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Add Wa_2201832410 (rev2)

On Wed, Mar 07, 2018 at 10:59:12PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/cnl: Add Wa_2201832410 (rev2) > URL : https://patchwork.freedesktop.org/series/39408/ > State : failure > > == Summary == > > Series 39408v2 drm/i915/cnl: Add Wa_2201832410 >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Add Wa_2201832410 (rev2)

== Series Details == Series: drm/i915/cnl: Add Wa_2201832410 (rev2) URL : https://patchwork.freedesktop.org/series/39408/ State : failure == Summary == Series 39408v2 drm/i915/cnl: Add Wa_2201832410 https://patchwork.freedesktop.org/api/1.0/series/39408/revisions/2/mbox/ Possible new

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

On Wed, 2018-03-07 at 14:46 -0800, Rodrigo Vivi wrote: > On Tue, Mar 06, 2018 at 07:34:18PM -0800, Dhinakaran Pandiyan wrote: > > From: "Pandiyan, Dhinakaran" > > > > i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to > > DIRTYFB. The

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/frontbuffer: HW tracking for cursor moves to fix PSR lags.

Quoting Dhinakaran Pandiyan (2018-03-07 03:34:19) > DRM_IOCTL_MODE_CURSOR results in frontbuffer flush before the cursor > plane MMIOs are written to. But this flush should not be necessary for > PSR as hardware tracking triggers PSR exit when MMIOs are written. As > for FBC, the spec says "Flips

[Intel-gfx] [PATCH igt] igt: Add gem_ctx_freq to exercise requesting freq on a ctx

Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. Signed-off-by: Chris Wilson --- tests/Makefile.am | 2 +- tests/Makefile.sources | 1 + tests/gem_ctx_freq.c | 190

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

Matches bspec. Reviewed-by: Rafael Antognolli On Wed, Mar 07, 2018 at 02:09:12PM -0800, Rodrigo Vivi wrote: > "Clock gating bug in GWL may not clear barrier state when an EOT > is received, causing a hang the next time that barrier is used." > > HSDES: 2201832410 >

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/frontbuffer: Pull frontbuffer_flush out of gem_obj_pin_to_display

On Tue, Mar 06, 2018 at 07:34:18PM -0800, Dhinakaran Pandiyan wrote: > From: "Pandiyan, Dhinakaran" > > i915_gem_obj_pin_to_display() calls frontbuffer_flush with origin set to > DIRTYFB. The callers however are at a vantage point to decide if hardware >

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

On Wed, 2018-03-07 at 17:39 +0100, Maarten Lankhorst wrote: > Similar to enable_fbc, enable_psr was ignored at runtime if it was > changed. The easiest fix is to pretend enable_psr is ignored at > configure time, and never activate it for !enable_psr, so both cases > are handled without modesets.

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 07, 2018 at 02:06:08PM -0800, Rodrigo Vivi wrote: > On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote: > > > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote: > > > > > >

[Intel-gfx] [PATCH] drm/i915/cnl: Add Wa_2201832410

"Clock gating bug in GWL may not clear barrier state when an EOT is received, causing a hang the next time that barrier is used." HSDES: 2201832410 Cc: Rafael Antognolli Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_reg.h | 3

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

On Wed, Mar 07, 2018 at 02:13:21AM +, Pandiyan, Dhinakaran wrote: > > > > On Tue, 2018-03-06 at 17:36 -0800, Manasi Navare wrote: > > On Wed, Mar 07, 2018 at 12:24:46AM +, Pandiyan, Dhinakaran wrote: > > > > > > > > > > > > On Tue, 2018-03-06 at 15:24 -0800, Rodrigo Vivi wrote: > > >

Re: [Intel-gfx] [PATCH] drm/i915: Kill the remaining CHV HBR2 leftovers

On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > AFAIK CHV was supposed to have HBR2 originally, but in the end the feature > was dropped. We still have some code leftovers from those early days. > Eliminate them. > Not much in

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/cnl: Add Wa_2201832410

== Series Details == Series: drm/i915/cnl: Add Wa_2201832410 URL : https://patchwork.freedesktop.org/series/39408/ State : failure == Summary == Applying: drm/i915/cnl: Add Wa_2201832410 error: sha1 information is lacking or useless (drivers/gpu/drm/i915/i915_reg.h). error: could not build

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: store all mmio bases in intel_engines

== Series Details == Series: drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39556/ State : success == Summary == Known issues: Test kms_chv_cursor_fail: Subgroup pipe-b-64x64-bottom-edge: dmesg-warn -> PASS

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband

== Series Details == Series: series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband URL : https://patchwork.freedesktop.org/series/39555/ State : warning == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup

Re: [Intel-gfx] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

On Wed, 2018-03-07 at 07:46 -0800, Rodrigo Vivi wrote: > Copied from Mesa with no modifications. > > Gives us Geminilake and Kaby Lake platform names updates and > sync on Coffee Lake PCI IDs. > > Cc: Timo Aaltonen > Signed-off-by: Rodrigo Vivi

Re: [Intel-gfx] vlv punit and sideband tidy

On Wed, 2018-03-07 at 19:41 +, Chris Wilson wrote: > Mika > believes that if we keep the cpu in C0 whilst the gpu is busy, then > it > behaves much better -- but that is a very tough sell Chris, Mika, I wonder does i915 driver tries to keep CPU in C0 at the moment already or you just consider

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: store all mmio bases in intel_engines

== Series Details == Series: drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39556/ State : success == Summary == Series 39556v1 drm/i915: store all mmio bases in intel_engines

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband

== Series Details == Series: series starting with [01/10] drm/i915: Disable preemption and sleeping while using the punit sideband URL : https://patchwork.freedesktop.org/series/39555/ State : success == Summary == Series 39555v1 series starting with [01/10] drm/i915: Disable preemption and

Re: [Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

Quoting Daniele Ceraolo Spurio (2018-03-07 19:45:15) > The mmio bases we're currently storing in the intel_engines array are > only valid for a subset of gens, so we need to ignore them and use > different values in some cases. Instead of doing that, we can have a > table of [starting gen, mmio

[Intel-gfx] [RFC] drm/i915: store all mmio bases in intel_engines

The mmio bases we're currently storing in the intel_engines array are only valid for a subset of gens, so we need to ignore them and use different values in some cases. Instead of doing that, we can have a table of [starting gen, mmio base] pairs for each engine in intel_engines and select the

[Intel-gfx] [PATCH 07/10] drm/i915: Separate sideband declarations to intel_sideband.h

Split the sideback declarations out of the ginormous i915_drv.h Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 62 drivers/gpu/drm/i915/i915_sysfs.c | 2 +

[Intel-gfx] [PATCH 09/10] drm/i915: Merge sandybridge_pcode_(read|write)

These routines are identical except in the nature of the value parameter. For writes it is a pure in-param, but for a read, we need an out-param. Since they differ in a single line, merge the two routines into one. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 10/10] drm/i915: Move sandybride pcode access to intel_sideband.c

sandybride_pcode is another sideband, so move it to their new home. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 10 -- drivers/gpu/drm/i915/intel_hdcp.c | 3 +- drivers/gpu/drm/i915/intel_pm.c | 194

[Intel-gfx] [PATCH 06/10] drm/i915: Replace pcu_lock with sb_lock

We now have two locks for sideband access. The general one covering sideband access across all generation, sb_lock, and a specific one covering sideband access via the punit on vlv/chv. After lifting the sb_lock around the punit into the callers, the pcu_lock is now redudant and can be separated

[Intel-gfx] [PATCH 04/10] drm/i915: Reduce RPS update frequency on Valleyview/Cherryview

Valleyview and Cherryview update the GPU frequency via the punit, which is very expensive as we have to ensure the cores do not sleep during the comms. If we perform frequent RPS evaluations, the frequent punit requests cause measurable system overhead for little benefit, so increase the

[Intel-gfx] [PATCH 02/10] drm/i915: Lift acquiring the vlv punit magic to a common sb-get

As we now employ a very heavy pm_qos around the punit access, we want to minimise the number of synchronous requests by performing one for the whole punit sequence rather than around individual accesses. The sideband lock is used for this, so push the pm_qos into the sideband lock acquisition and

[Intel-gfx] [PATCH 01/10] drm/i915: Disable preemption and sleeping while using the punit sideband

While we talk to the punit over its sideband, we need to prevent the cpu from sleeping in order to prevent a potential machine hang. Note that by itself, it appears that pm_qos_update_request (via intel_idle) doesn't provide a sufficient barrier to ensure that all core are indeed awake (out of

[Intel-gfx] [PATCH 05/10] Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3"

With the vlv sideband fixed to avoid sleeping while we talk to the punit, the system should be much more stable and be able to utilise the punit without risk. This reverts commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3") References: 6067a27d1f01 ("drm/i915:

[Intel-gfx] [PATCH 08/10] drm/i915: Merge sbi read/write into a single accessor

Since intel_sideband_read and intel_sideband_write differ by only a couple of lines (depending on whether we feed the value in or out), merge the two into a single common accessor. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_sideband.c | 93

[Intel-gfx] [PATCH 03/10] drm/i915: Lift sideband locking for vlv_punit_(read|write)

Lift the sideband acquisition for vlv_punit_read and vlv_punit_write into their callers, so that we can lock the sideband once for a sequence of operations, rather than perform the heavyweight acquisition on each request. Signed-off-by: Chris Wilson ---

[Intel-gfx] vlv punit and sideband tidy

While we continue to observe hangs even with this w/a in place, I do believe we are in a better position (although that may just be my confirmation bias). I certainly don't think it's all happy yet. Mika believes that if we keep the cpu in C0 whilst the gpu is busy, then it behaves much better --

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Only prune fences after wait-for-all (rev2)

== Series Details == Series: drm/i915: Only prune fences after wait-for-all (rev2) URL : https://patchwork.freedesktop.org/series/39547/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: incomplete -> PASS (shard-apl)

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle changing enable_psr parameter at runtime better

== Series Details == Series: drm/i915: Handle changing enable_psr parameter at runtime better URL : https://patchwork.freedesktop.org/series/39545/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: incomplete -> PASS

Re: [Intel-gfx] [PATCH 6/6] drm: Reject bad property flag combinations

On Tue, Mar 06, 2018 at 07:22:51PM +0100, Daniel Vetter wrote: > On Tue, Mar 06, 2018 at 06:48:49PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Pimp drm_property_type_valid() to check for more fails with the > > property flags. Also make the check

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

Quoting Michal Wajdeczko (2018-03-07 12:47:01) > Header intel_ringbuffer.h is using definitions from i915_reg.h > but forget to include it. Remove this hidden dependency by > explicitly include missing header. > > v2: add reminder (Chris) > > Signed-off-by: Michal Wajdeczko

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only prune fences after wait-for-all (rev2)

== Series Details == Series: drm/i915: Only prune fences after wait-for-all (rev2) URL : https://patchwork.freedesktop.org/series/39547/ State : success == Summary == Series 39547v2 drm/i915: Only prune fences after wait-for-all

Re: [Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all

Quoting Chris Wilson (2018-03-07 17:13:03) > Currently, we only allow ourselves to prune the fences so long as > all the waits completed (i.e. all the fences we checked were signaled), > and that the reservation snapshot did not change across the wait. > However, if we only waited for a subset of

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3)

== Series Details == Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3) URL : https://patchwork.freedesktop.org/series/39508/ State : success == Summary == Possible new issues: Test kms_busy: Subgroup extended-pageflip-hang-oldfb-render-a:

[Intel-gfx] [PATCH v2] drm/i915: Only prune fences after wait-for-all

Currently, we only allow ourselves to prune the fences so long as all the waits completed (i.e. all the fences we checked were signaled), and that the reservation snapshot did not change across the wait. However, if we only waited for a subset of the reservation object, i.e. just waiting for the

[Intel-gfx] [PATCH] drm/i915: Only prune fences after wait-for-all

Currently, we only allow ourselves to prune the fences so long as all the waits completed (i.e. all the fences we checked were signaled), and that the reservation snapshot did not change across the wait. However, if we only waited for a subset of the reservation object, i.e. just waiting for the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle changing enable_psr parameter at runtime better

== Series Details == Series: drm/i915: Handle changing enable_psr parameter at runtime better URL : https://patchwork.freedesktop.org/series/39545/ State : success == Summary == Series 39545v1 drm/i915: Handle changing enable_psr parameter at runtime better

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: Move i915_gpu_error into its own header

Quoting Michal Wajdeczko (2018-03-07 12:47:04) > Error state management code was moved into separate .c unit > but we didn't move related definitions into own header. > > v2: move also intel_display_error_state forward decl > fix ("Prefer 'unsigned int' to bare use of 'unsigned'") >

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

== Series Details == Series: series starting with [1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests URL : https://patchwork.freedesktop.org/series/39532/ State : success == Summary == Possible new issues: Test kms_busy: Subgroup

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Change parameters order in i915_gem_batch_pool_init

Quoting Michal Wajdeczko (2018-03-07 12:47:02) > Function i915_gem_batch_pool_init() failed to follow obj-verb > naming schema. Fix that by swapping function parameters. > While here, change license text to SPDX format. > > v2: use intel_engine_init_batch_pool (Chris) as proxy (Michal) > >

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

Op 07-03-18 om 16:21 schreef Ville Syrjälä: > On Wed, Mar 07, 2018 at 04:04:32PM +0100, Maarten Lankhorst wrote: >> This will get rid of the following error: >> [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 >> drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 >> [

[Intel-gfx] [PATCH] drm/i915: Handle changing enable_psr parameter at runtime better

Similar to enable_fbc, enable_psr was ignored at runtime if it was changed. The easiest fix is to pretend enable_psr is ignored at configure time, and never activate it for !enable_psr, so both cases are handled without modesets. Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

On Tue, Mar 06, 2018 at 01:32:21PM -0500, Harry Wentland wrote: > > > On 2018-03-06 12:13 PM, Daniel Vetter wrote: > > On Tue, Mar 06, 2018 at 11:23:23AM -0500, Harry Wentland wrote: > >> On 2018-03-06 07:18 AM, Ville Syrj??l?? wrote: > >>> On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/6] drm: Reject replacing property enum values

On Tue, Mar 06, 2018 at 09:49:29PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/6] drm: Reject replacing property enum values > URL : https://patchwork.freedesktop.org/series/39465/ > State : warning > > == Summary == > > Possible new issues: > >

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

Hi Dave, Fixes for 2 regressions that got captured by CI. Here goes drm-intel-fixes-2018-03-07: - 2 fixes: 1 for perf and 1 execlist submission race. Thanks, Rodrigo. The following changes since commit 661e50bc853209e41a5c14a290ca4decc43cbfd1: Linux 4.16-rc4 (2018-03-04 14:54:11 -0800)

[Intel-gfx] [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

Copied from Mesa with no modifications. Gives us Geminilake and Kaby Lake platform names updates and sync on Coffee Lake PCI IDs. Cc: Timo Aaltonen Signed-off-by: Rodrigo Vivi --- hw/xfree86/dri2/pci_ids/i965_pci_ids.h | 26

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3)

== Series Details == Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev3) URL : https://patchwork.freedesktop.org/series/39508/ State : success == Summary == Series 39508v3 drm/i915: Handle pipe CRC around enabling/disabling pipe.

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

On Wed, Mar 07, 2018 at 04:04:32PM +0100, Maarten Lankhorst wrote: > This will get rid of the following error: > [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 > drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 > [ 74.730311] Modules linked in: vgem

[Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

This will get rid of the following error: [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

== Series Details == Series: series starting with [1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests URL : https://patchwork.freedesktop.org/series/39532/ State : success == Summary == Series 39532v1 series starting with [1/6] drm/i915: Finish the wait-for-wedge

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

On Wed, Mar 07, 2018 at 03:23:12PM +0200, Ville Syrjälä wrote: > On Wed, Mar 07, 2018 at 01:10:26PM +0100, Maarten Lankhorst wrote: > > This will get rid of the following error: > > [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 > >

[Intel-gfx] [PATCH 2/6] drm/i915: Reset ring space estimate after unwinding the request

With a series of unusual events (a sequence of interrupted request allocations), we could gradually leak the ring->space estimate by unwinding the ring back to the start of the request, but not return the used space back to the ring. Eventually and with great misfortune, it would be possible to

[Intel-gfx] [PATCH 3/6] drm/i915: Update ring position from request on retiring

When wedged, we do not update the ring->tail as we submit the requests causing us to leak the ring->space upon cleaning up the wedged driver. We can just use the value stored in rq->tail, and keep the submission backend details away from set-wedge. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 6/6] drm/i915: Only call tasklet_kill() on the first prepare_reset

tasklet_kill() will spin waiting for the current tasklet to be executed. However, if tasklet_disable() has been called, then the tasklet is never executed but permanently put back onto the runlist until tasklet_enable() is called. Ergo, we cannot use tasklet_kill() inside a disable/enable pair.

[Intel-gfx] [PATCH 5/6] drm/i915: Wrap engine->schedule in RCU locks for set-wedge protection

Similar to the staging around handling of engine->submit_request, we need to stop adding to the execlists->queue prior to calling engine->cancel_requests. cancel_requests will move requests from the queue onto the timeline, so if we add a request onto the queue after that point, it will be lost.

[Intel-gfx] [PATCH 1/6] drm/i915: Finish the wait-for-wedge by retiring all the inflight requests

Before we reset the GPU after marking the device as wedged, we wait for all the remaining requests to be completed (and marked as EIO). Afterwards, we should flush the request lists so the next batch start with the driver in an idle start. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 4/6] drm/i915: Include ring->emit in debugging

Include ring->emit and ring->space alongside ring->(head,tail) when printing debug information. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c| 4 ++-- drivers/gpu/drm/i915/intel_engine_cs.c |

Re: [Intel-gfx] [PATCH] drm/i915: Handle pipe CRC around enabling/disabling pipe.

On Wed, Mar 07, 2018 at 01:10:26PM +0100, Maarten Lankhorst wrote: > This will get rid of the following error: > [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 > drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 > [ 74.730311] Modules linked in: vgem

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2)

== Series Details == Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2) URL : https://patchwork.freedesktop.org/series/39508/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE

Re: [Intel-gfx] [PATCH] drm/i915: Assert that the request is indeed complete when signaled from irq

Quoting Tvrtko Ursulin (2018-03-05 12:25:21) > > On 05/03/2018 11:21, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-03-05 11:12:45) > >> > >> On 05/03/2018 10:41, Chris Wilson wrote: > >>> After we call dma_fence_signal(), confirm that the request was indeed > >>> complete. > >>> > >>>

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915: Make header i915_pmu.h more robust

On 07/03/2018 12:47, Michal Wajdeczko wrote: Definitions in i915_pmu.h header depend on other types and declarations that were not explicitly included. Fix that by adding related headers and forward declarations. While here, change license text to SPDX format. v2: don't drop

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

On 07/03/2018 12:47, Michal Wajdeczko wrote: Header intel_ringbuffer.h is using definitions from i915_reg.h but forget to include it. Remove this hidden dependency by explicitly include missing header. v2: add reminder (Chris) Signed-off-by: Michal Wajdeczko Cc:

[Intel-gfx] [PATCH v2 1/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

Header intel_ringbuffer.h is using definitions from i915_reg.h but forget to include it. Remove this hidden dependency by explicitly include missing header. v2: add reminder (Chris) Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc:

[Intel-gfx] [PATCH v2 2/4] drm/i915: Change parameters order in i915_gem_batch_pool_init

Function i915_gem_batch_pool_init() failed to follow obj-verb naming schema. Fix that by swapping function parameters. While here, change license text to SPDX format. v2: use intel_engine_init_batch_pool (Chris) as proxy (Michal) Signed-off-by: Michal Wajdeczko Cc:

[Intel-gfx] [PATCH v2 4/4] drm/i915: Move i915_gpu_error into its own header

Error state management code was moved into separate .c unit but we didn't move related definitions into own header. v2: move also intel_display_error_state forward decl fix ("Prefer 'unsigned int' to bare use of 'unsigned'") warnings detected by checkpatch in moved code (Michal)

[Intel-gfx] [PATCH v2 3/4] drm/i915: Make header i915_pmu.h more robust

Definitions in i915_pmu.h header depend on other types and declarations that were not explicitly included. Fix that by adding related headers and forward declarations. While here, change license text to SPDX format. v2: don't drop "intel_ringbuffer.h" (Tvrtko) Signed-off-by: Michal Wajdeczko

Re: [Intel-gfx] [PATCH 4/6] drm/i915/icl: Enhanced execution list support

Quoting Mika Kuoppala (2018-03-02 16:14:59) > From: Thomas Daniel > > Enhanced Execlists is an upgraded version of execlists which supports > up to 8 ports. The lrcs to be submitted are written to a submit queue > (the ExecLists Submission Queue - ELSQ), which is then

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2)

== Series Details == Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. (rev2) URL : https://patchwork.freedesktop.org/series/39508/ State : success == Summary == Series 39508v2 drm/i915: Handle pipe CRC around enabling/disabling pipe.

  1   2   >