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] [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] 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 --

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] 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

[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] 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

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] [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] ✓ 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

[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] [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 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 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 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] ✓ 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

[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.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: 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

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

[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

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 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

[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

[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

[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:

[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

[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/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 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

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] [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] [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

[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

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 >

[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 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] 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

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.

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

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

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 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" > > > > > >

[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

[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

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: > > > > > >

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: 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

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 >

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 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

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] 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

[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.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] [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 +

[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

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

[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] ✓ 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:

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.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

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

Hi Dave, Only a few sun4i fixes this week. Please pull. Regards, Gustavo drm-misc-fixes-2018-03-07: sun4i fixes on clk, division by zero and LVDS. The following changes since commit 9a191b114906457c4b2494c474f58ae4142d4e67: virtio-gpu: fix ioctl and expose the fixed status to userspace.

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

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

Re: [Intel-gfx] [PATCH 2/6] drm/i915/icl: Correctly initialize the Gen11 engines

On 06/03/2018 22:07, Daniele Ceraolo Spurio wrote: On 02/03/18 08:14, Mika Kuoppala wrote: From: Oscar Mateo Gen11 has up to 4 VCS and up to 2 VECS engines, this patch adds mmio base definitions for all of them. Bspec: 20944 Bspec: 7021 v2: Set the correct mmio_base

Re: [Intel-gfx] [PULL] drm-misc-next

On Tue, Mar 6, 2018 at 8:20 PM, Sean Paul wrote: > On Tue, Mar 06, 2018 at 09:07:52PM +0200, Ville Syrjälä wrote: >> On Tue, Mar 06, 2018 at 02:01:21PM -0500, Sean Paul wrote: >> > On Tue, Mar 06, 2018 at 07:42:53AM +0100, Daniel Vetter wrote: >> > > On Tue, Mar 6, 2018 at

[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.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: 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] [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 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 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 |

[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

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] ✓ 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 3/4] drm/i915: Include i915_reg.h in intel_ringbuffer.h

On Wed, 07 Mar 2018 08:58:30 +0100, Tvrtko Ursulin wrote: On 06/03/2018 17:33, Chris Wilson wrote: Quoting Michal Wajdeczko (2018-03-06 16:15:26) Header intel_ringbuffer.h is using definitions from i915_reg.h but forget to include it. Remove this hidden

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Handle pipe CRC around enabling/disabling pipe.

== Series Details == Series: drm/i915: Handle pipe CRC around enabling/disabling pipe. URL : https://patchwork.freedesktop.org/series/39508/ State : failure == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-a-128x128-bottom-edge: pass

Re: [Intel-gfx] [PATCH 13/16] drm/i915: Add NV12 as supported format for primary plane

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, March 6, 2018 12:30 AM > To: Srinivas, Vidya > Cc: juhapekka.heikk...@gmail.com; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 13/16]

[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 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.

[Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Use absolute tolerance in accuracy tests

From: Tvrtko Ursulin We need to use absolute tolerance when asserting on percentages. Relative tolerance in this case is unfair and inaccurate since it's strictness varies with relative target busyness. Signed-off-by: Tvrtko Ursulin Cc: Chris

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

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:

Re: [Intel-gfx] [PATCH i-g-t] tests/perf_pmu: Use absolute tolerance in accuracy tests

Quoting Tvrtko Ursulin (2018-03-07 11:11:19) > From: Tvrtko Ursulin > > We need to use absolute tolerance when asserting on percentages. Relative > tolerance in this case is unfair and inaccurate since it's strictness > varies with relative target busyness. > >

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

Quoting Michal Wajdeczko (2018-03-07 11:24:06) > On Wed, 07 Mar 2018 08:58:30 +0100, Tvrtko Ursulin > wrote: > > > > > On 06/03/2018 17:33, Chris Wilson wrote: > >> Quoting Michal Wajdeczko (2018-03-06 16:15:26) > >>> Header intel_ringbuffer.h is using

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

Quoting Chris Wilson (2018-03-07 11:47:15) > Quoting Michal Wajdeczko (2018-03-07 11:24:06) > > On Wed, 07 Mar 2018 08:58:30 +0100, Tvrtko Ursulin > > wrote: > > > > > > > > On 06/03/2018 17:33, Chris Wilson wrote: > > >> Quoting Michal Wajdeczko (2018-03-06

[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 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 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] 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. > >>> > >>>

[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

  1   2   >