Re: [Intel-gfx] [PATCH v2 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

On 3/8/2018 9:16 PM, Michał Winiarski wrote: Currently, we're treating relay and mapping of GuC log as a separate concepts. We're also using inconsistent locking, sometimes using relay_lock, sometimes using struct mutex. Let's correct that. Anything touching the runtime is now serialized using

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Do not set the eDP link rate/lane count to max

== Series Details == Series: drm/i915/dp: Do not set the eDP link rate/lane count to max URL : https://patchwork.freedesktop.org/series/39662/ State : success == Summary == Series 39662v1 drm/i915/dp: Do not set the eDP link rate/lane count to max

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

On Thu, Mar 08, 2018 at 06:41:22PM -0500, Lyude Paul wrote: > While having the modeset_retry_work in intel_connector makes sense with > SST, this paradigm doesn't make a whole ton of sense when it comes to > MST since we have to deal with multiple connectors. In most cases, it's > more useful to

Re: [Intel-gfx] [PATCH v2 03/15] drm/i915/guc: Move GuC notification handling to separate function

On 3/8/2018 9:16 PM, Michał Winiarski wrote: From: Michal Wajdeczko To allow future code reuse. While here, fix comment style. v2: Notifications are a separate thing - rename the handler (Sagar) Suggested-by: Oscar Mateo Signed-off-by:

[Intel-gfx] [PATCH] drm/i915/dp: Do not set the eDP link rate/lane count to max

The panels are generally designed to support only a single clock and lane configuration, and typically these values correspond to the native resolution of the panel. But some panels advertise the MAX_LINK_RATE in DPCD higher than what is required to support the native resolution. So optimize and

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

== Series Details == Series: series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39651/ State : warning == Summary == Possible new issues: Test kms_vblank: Subgroup

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

On Thu, Mar 08, 2018 at 06:24:15PM -0500, Lyude Paul wrote: > Signed-off-by: Lyude Paul > Cc: Manasi Navare > Cc: Ville Syrjälä Reviewed-by: Manasi Navare > --- >

Re: [Intel-gfx] [PATCH v2 02/15] drm/i915/guc: Create common entry points for log register/unregister

On 3/8/2018 9:16 PM, Michał Winiarski wrote: We have many functions responsible for allocating different parts of GuC log runtime called from multiple places. Let's stick with keeping everything in guc_log_register instead. v2: Use more generic intel_uc_register name, keep using "misc" suffix

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: make edp optimize config

== Series Details == Series: drm/i915: make edp optimize config URL : https://patchwork.freedesktop.org/series/39652/ State : warning == Summary == Possible new issues: Test kms_busy: Subgroup extended-pageflip-hang-oldfb-render-a: pass -> SKIP

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-external: pass -> INCOMPLETE

Re: [Intel-gfx] [PATCH v2 01/15] drm/i915/guc: Tidy guc_log_control

On 3/8/2018 9:16 PM, Michał Winiarski wrote: We plan to decouple log runtime (mapping + relay) from verbosity control. Let's tidy the code now to reduce the churn in the following patches. v2: Tidy macros, keep debug messages, use helper var for enable, correct typo (Michał) Fix

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

== Series Details == Series: drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. URL : https://patchwork.freedesktop.org/series/39648/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE

Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

Hi Matt, Minor commit message nits. On Thu, Mar 08, 2018 at 05:17:38PM -0800, matthew.s.atw...@intel.com wrote: > From: Matt Atwood > > Previously it was assumed that eDP panels would advertise the lowest link > rate required for their singular mode to function.

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines

== Series Details == Series: series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39644/ State : success == Summary == Known issues: Test gem_eio: Subgroup in-flight-contexts: pass ->

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

== Series Details == Series: series starting with [1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39651/ State : success == Summary == Series 39651v2 series starting with [1/2] drm/i915: Push irq_shift from

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make edp optimize config

== Series Details == Series: drm/i915: make edp optimize config URL : https://patchwork.freedesktop.org/series/39652/ State : success == Summary == Series 39652v1 drm/i915: make edp optimize config https://patchwork.freedesktop.org/api/1.0/series/39652/revisions/1/mbox/ Known issues:

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uc: Sanitize uC

== Series Details == Series: drm/i915/uc: Sanitize uC URL : https://patchwork.freedesktop.org/series/39634/ State : failure == Summary == Possible new issues: Test drv_missed_irq: pass -> SKIP (shard-apl) Test kms_vblank: Subgroup

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Kill scheduled work for Core platforms.

== Series Details == Series: drm/i915/psr: Kill scheduled work for Core platforms. URL : https://patchwork.freedesktop.org/series/39650/ State : failure == Summary == Applying: drm/i915/psr: Kill scheduled work for Core platforms. error: sha1 information is lacking or useless

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2)

== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller (rev2) URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Series 39647v2 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

Re: [Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

Quoting Chris Wilson (2018-03-09 01:33:08) > gen11_gt_engine_intr(struct drm_i915_private * const i915, > const unsigned int bank, const unsigned int bit) > @@ -2836,10 +2798,23 @@ static void > gen11_gt_irq_handler(struct drm_i915_private * const i915, >

[Intel-gfx] [PATCH v2] drm/i915: Trim gen11_gt_irq_handler

Give the compiler a helping hand in mapping (bank,bit) to our struct intel_engine_cs by trading object code size for data cache: add/remove: 2/0 grow/shrink: 0/1 up/down: 48/-135 (-87) Function old new delta bank1_map

[Intel-gfx] [PATCH] drm/i915: make edp optimize config

From: Matt Atwood Previously it was assumed that eDP panels would advertise the lowest link rate required for their singular mode to function. With the introduction of more advanced features there are advantages to a panel advertising a higher rate then it needs for a

[Intel-gfx] [PATCH 2/2] drm/i915: Trim gen11_gt_irq_handler

Give the compiler a helping hand in mapping (bank,bit) to our struct intel_engine_cs by trading object code size for data cache: add/remove: 2/0 grow/shrink: 0/1 up/down: 192/-135 (57) Function old new delta bank1_map

[Intel-gfx] [PATCH 1/2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

== Series Details == Series: drm/i915/psr: Display WA 0884 applied broadly for more HW tracking. URL : https://patchwork.freedesktop.org/series/39648/ State : success == Summary == Series 39648v1 drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

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

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

[Intel-gfx] [PATCH] drm/i915/psr: Kill scheduled work for Core platforms.

The immediate enabling is actually not an issue for the HW perspective for core platforms that have HW tracking. HW will wait few identical idle frames before transitioning to actual psr active anyways. Note that this patch also remove the delayed activation on HSW and BDW introduced by commit

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 04:21:53PM -0800, Pandiyan, Dhinakaran wrote: > 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

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:34 -0800, Dhinakaran Pandiyan 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

[Intel-gfx] [PATCH v2] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into

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

Quoting Antonio Argenziano (2018-03-09 00:45:42) > > > On 08/03/18 09:13, Chris Wilson wrote: > > Exercise some new API that allows applications to request that > > individual contexts are executed within a desired frequency range. > > > > v2: Split single/continuous set_freq subtests > > > >

[Intel-gfx] [PATCH] drm/i915/psr: Display WA 0884 applied broadly for more HW tracking.

WA 0884:bxt:all,cnl:*:A - "When FBC is enabled with eDP PSR, the CPU host modify writes may not get updated on the Display as expected. WA: Write 0x to CUR_SURFLIVE_A with every CPU host modify write to trigger PSR exit." We can also find on spec other cases where they describe bogus

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: add a selftest for the mmio_bases table

Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:28) > Check that the entries are in reverse gen order and that the first entry > and all the following entries with gen > 0 have an mmio base set. > > Suggested-by: Chris Wilson > Cc: Chris Wilson

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

On 08/03/18 09:13, Chris Wilson wrote: Exercise some new API that allows applications to request that individual contexts are executed within a desired frequency range. v2: Split single/continuous set_freq subtests Signed-off-by: Chris Wilson Cc: Paneri, Praveen

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

== Series Details == Series: drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller URL : https://patchwork.freedesktop.org/series/39647/ State : success == Summary == Series 39647v1 drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: store all mmio bases in intel_engines

Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:27) > 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

Re: [Intel-gfx] [PATCH] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

On 08/03/18 16:16, Chris Wilson wrote: Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: move gen8 irq shifts to intel_lrc.c

Quoting Daniele Ceraolo Spurio (2018-03-08 23:46:29) > The only usage outside the intel_lrc.c file is in the ringbuffer > init, but the irq mask calculated there is then overwritten for > all engines that have a non-zero shift, so we can drop it. > > This change is not aimed at code saving but at

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines

== Series Details == Series: series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39644/ State : success == Summary == Series 39644v1 series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines

[Intel-gfx] [PATCH] drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller

Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines

== Series Details == Series: series starting with [v2,1/3] drm/i915: store all mmio bases in intel_engines URL : https://patchwork.freedesktop.org/series/39644/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: store all mmio bases in intel_engines Okay! Commit:

[Intel-gfx] [PATCH v2 2/3] drm/i915: add a selftest for the mmio_bases table

Check that the entries are in reverse gen order and that the first entry and all the following entries with gen > 0 have an mmio base set. Suggested-by: Chris Wilson Cc: Chris Wilson Signed-off-by: Daniele Ceraolo Spurio

[Intel-gfx] [PATCH v2 3/3] drm/i915: move gen8 irq shifts to intel_lrc.c

The only usage outside the intel_lrc.c file is in the ringbuffer init, but the irq mask calculated there is then overwritten for all engines that have a non-zero shift, so we can drop it. This change is not aimed at code saving but at removing from intel_engines information that does not apply to

[Intel-gfx] [PATCH v2 1/3] 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 v2 2/6] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[Intel-gfx] [PATCH 3/6] drm/i915: Only use one link bw config for MST topologies

When a DP MST link needs retraining, sometimes the hub will detect that the current link bw config is impossible and will update it's RX caps in the DPCD to reflect the new maximum link rate. Currently, we make the assumption that the RX caps in the dpcd will never change like this. This means if

[Intel-gfx] [PATCH 5/6] drm/dp_mst: Add drm_atomic_dp_mst_retrain_topology()

Retraining MST is rather difficult. In order to do it properly while guaranteeing that we'll never run into a spot where we commit a physically impossible configuration, we have to do a lot of checks on atomic commits which affect MST topologies. All of this work is going to need to be repeated

[Intel-gfx] [PATCH 4/6] drm/dp_mst: Add drm_dp_mst_topology_mgr_lower_link_rate()

Unlike SST, MST can have far more then a single display hooked up on a single port. What this also means however, is that if the DisplayPort link to the top-level MST branch device becomes unstable then every single branch device also has an unstable link. Additionally, MST has a few more steps

[Intel-gfx] [PATCH 0/6] Implement proper MST fallback retraining in i915

This is the first version of my patch series to implement MST fallback retraining in i915, along with improving the stability of i915's mst retraining in general. Additionally, it also introduces helpers into DRM to help with correctly handling MST fallback retraining so that other drivers may

[Intel-gfx] [PATCH 2/6] drm/i915: Move DP modeset retry work into intel_dp

While having the modeset_retry_work in intel_connector makes sense with SST, this paradigm doesn't make a whole ton of sense when it comes to MST since we have to deal with multiple connectors. In most cases, it's more useful to just use the intel_dp struct since it indicates whether or not we're

[Intel-gfx] [PATCH 6/6] drm/i915: Implement proper fallback training for MST

For a while we actually haven't had any way of retraining MST links with fallback link parameters like we do with SST. While uncommon, certain setups such as my Caldigit TS3 + EVGA MST hub require this since otherwise, they end up getting stuck in an infinite MST retraining loop. MST retraining

[Intel-gfx] [PATCH 1/6] drm/i915: Remove unused DP_LINK_CHECK_TIMEOUT

Signed-off-by: Lyude Paul Cc: Manasi Navare Cc: Ville Syrjälä --- drivers/gpu/drm/i915/intel_dp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c

Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

On 08/03/18 13:00, Michal Wajdeczko wrote: Instead of dancing around uC on reset/suspend/resume scenarios, explicitly sanitize uC when we sanitize GEM to force uC reload and start from known beginning. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uc: Sanitize uC

== Series Details == Series: drm/i915/uc: Sanitize uC URL : https://patchwork.freedesktop.org/series/39634/ State : success == Summary == Series 39634v1 drm/i915/uc: Sanitize uC https://patchwork.freedesktop.org/api/1.0/series/39634/revisions/1/mbox/ Known issues: Test

Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

Quoting Michal Wajdeczko (2018-03-08 21:00:35) > Instead of dancing around uC on reset/suspend/resume scenarios, > explicitly sanitize uC when we sanitize GEM to force uC reload > and start from known beginning. > > Signed-off-by: Michal Wajdeczko > Cc: Daniele

Re: [Intel-gfx] [PATCH 1/3] drm/i915/uc: Sanitize uC options early

Quoting Michal Wajdeczko (2018-03-08 21:00:34) > We are sanitizing uC related modparams together with other driver > modparams in intel_sanitize_options called from i915_driver_init_hw, > but this is too late for us as we will want to use USES_GUC/USES_HUC > macros at earlier stage. Since our

[Intel-gfx] [PATCH 1/3] drm/i915/uc: Sanitize uC options early

We are sanitizing uC related modparams together with other driver modparams in intel_sanitize_options called from i915_driver_init_hw, but this is too late for us as we will want to use USES_GUC/USES_HUC macros at earlier stage. Since our sanitizing does not require any MMIO access, we can do it

[Intel-gfx] [PATCH 2/3] drm/i915/uc: Sanitize uC together with GEM

Instead of dancing around uC on reset/suspend/resume scenarios, explicitly sanitize uC when we sanitize GEM to force uC reload and start from known beginning. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Sagar Arun

[Intel-gfx] [PATCH 0/3] drm/i915/uc: Sanitize uC

Attempt to sanitize uC for better alignment with rest of GEM driver. Michal Wajdeczko (3): drm/i915/uc: Sanitize uC options early drm/i915/uc: Sanitize uC together with GEM HAX: Enable GuC for CI drivers/gpu/drm/i915/i915_drv.c| 2 -- drivers/gpu/drm/i915/i915_gem.c| 2 ++

[Intel-gfx] [PATCH 3/3] HAX: Enable GuC for CI

v2: except running with HYPERVISOR Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- drivers/gpu/drm/i915/intel_uc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h

Re: [Intel-gfx] [patch 1/1] drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union initializer issue

On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula wrote: > On Wed, 07 Mar 2018, a...@linux-foundation.org wrote: > > From: Andrew Morton > > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union > > initializer issue >

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control

== Series Details == Series: series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39614/ State : failure == Summary == Possible new issues: Test drv_missed_irq: pass -> SKIP (shard-apl) Test

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

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

[Intel-gfx] [PATCH v2] 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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency

Quoting Patchwork (2018-03-08 19:32:29) > == Series Details == > > Series: series starting with [CI,1/2] drm/i915: Kick the rps worker when > changing the boost frequency > URL : https://patchwork.freedesktop.org/series/39607/ > State : success > > == Summary == > > Possible new issues:

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency

== Series Details == Series: series starting with [CI,1/2] drm/i915: Kick the rps worker when changing the boost frequency URL : https://patchwork.freedesktop.org/series/39607/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

On Thu, Mar 08, 2018 at 06:55:34PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 18:48:51) > > Quoting Matt Roper (2018-03-08 18:22:06) > > > * Option 2: Allow priority offset to be set in a much larger range > > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to

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

On Thu, Mar 08, 2018 at 10:07:05AM -0800, Pandiyan, Dhinakaran wrote: > > > > On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote: > > Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran: > > > > > > > > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: > > >> Op 07-03-18 om

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Remove support for legacy debugfs crc interface (rev2)

== Series Details == Series: drm/i915: Remove support for legacy debugfs crc interface (rev2) URL : https://patchwork.freedesktop.org/series/33053/ State : warning == Summary == Series 33053v2 drm/i915: Remove support for legacy debugfs crc interface

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling

== Series Details == Series: drm/i915: Remove the impedance mismatch around intel_engine_enable_signaling URL : https://patchwork.freedesktop.org/series/39605/ State : success == Summary == Possible new issues: Test kms_frontbuffer_tracking: Subgroup

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

Quoting Chris Wilson (2018-03-08 18:48:51) > Quoting Matt Roper (2018-03-08 18:22:06) > > * Option 2: Allow priority offset to be set in a much larger range > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have > >effective priority ranges that don't overlap. cgroup

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

Quoting Matt Roper (2018-03-08 18:22:06) > On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-08 11:32:04) > > > Quoting Matt Roper (2018-03-06 23:46:59) > > > > There are cases where a system integrator may wish to raise/lower the > > > > priority of

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

On 08/03/18 01:31, Tvrtko Ursulin wrote: On 07/03/2018 19:45, Daniele Ceraolo Spurio wrote: 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

[Intel-gfx] [PATCH] drm/i915: Remove support for legacy debugfs crc interface

This interface is deprecated, and has been replaced by the upstream drm crc interface. Signed-off-by: Maarten Lankhorst Cc: Tomi Sarvela Cc: Petri Latvala Cc: Jani Nikula Cc: Ville

Re: [Intel-gfx] [PATCH v3 5/6] drm/i915: Introduce 'priority offset' for GPU contexts (v2)

On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote: > Quoting Chris Wilson (2018-03-08 11:32:04) > > Quoting Matt Roper (2018-03-06 23:46:59) > > > There are cases where a system integrator may wish to raise/lower the > > > priority of GPU workloads being submitted by specific OS

Re: [Intel-gfx] [PATCH igt] igt/drv_hangman: Check that the error state does hold the expected state

Quoting Antonio Argenziano (2018-03-05 19:10:37) > > > On 05/03/18 02:09, Chris Wilson wrote: > > Actually check the error state exists (!"No error state captured") and > > that it contains the expected engine dump. > > > > v2: Throw in some debug clues. > > > > Signed-off-by: Chris Wilson

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

On Thu, 2018-03-08 at 18:52 +0100, Maarten Lankhorst wrote: > Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran: > > > > > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: > >> Op 07-03-18 om 23:22 schreef Pandiyan, Dhinakaran: > >>> On Wed, 2018-03-07 at 17:39 +0100, Maarten

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

Quoting Matthew Auld (2018-03-08 17:48:48) > On 7 March 2018 at 17:13, Chris Wilson wrote: > > 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

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

Op 08-03-18 om 18:43 schreef Pandiyan, Dhinakaran: > > > On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: >> 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

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

On 7 March 2018 at 17:13, Chris Wilson wrote: > 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

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

On Thu, 2018-03-08 at 08:07 +0100, Maarten Lankhorst wrote: > 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

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

Quoting Antonio Argenziano (2018-03-08 17:33:11) > > > On 07/03/18 17:18, Chris Wilson wrote: > > Quoting Antonio Argenziano (2018-03-08 00:55:47) > >> > >> > >> On 07/03/18 14:49, Chris Wilson wrote: > >>> + gem_quiescent_gpu(fd); > >> > >> Check frequency has gone back to ~min. > > > >

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

On Thu, 2018-03-08 at 14:58 +0200, Ville Syrjälä wrote: > On Wed, Mar 07, 2018 at 09:41:06PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Fri, 2018-03-02 at 11:56 +0200, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > AFAIK CHV was supposed

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

On 07/03/18 17:18, Chris Wilson wrote: 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 =

[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. v2: Split single/continuous set_freq subtests Signed-off-by: Chris Wilson Cc: Paneri, Praveen Cc: Kamble, Sagar

Re: [Intel-gfx] [RFC v3 09/12] drm: Add API for in-kernel clients

Den 06.03.2018 09.56, skrev Daniel Vetter: On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Trønnes wrote: This adds an API for writing in-kernel clients. TODO: - Flesh out and complete documentation. - Cloned displays is not tested. - Complete tiled display support and test it. - Test

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

Quoting Rogozhkin, Dmitry V (2018-03-07 20:39:16) > 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

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

Op 08-03-18 om 17:21 schreef Ville Syrjälä: > On Thu, Mar 08, 2018 at 05:02:38PM +0100, Maarten Lankhorst wrote: >> Op 08-03-18 om 16:22 schreef Ville Syrjälä: >>> On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote: This will get rid of the following error: [ 74.730271]

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control

== Series Details == Series: series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control URL : https://patchwork.freedesktop.org/series/39614/ State : success == Summary == Series 39614v1 series starting with [v2,01/15] drm/i915/guc: Tidy guc_log_control

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

On Thu, Mar 08, 2018 at 05:02:38PM +0100, Maarten Lankhorst wrote: > Op 08-03-18 om 16:22 schreef Ville Syrjälä: > > On Thu, Mar 08, 2018 at 01:02:02PM +0100, Maarten Lankhorst wrote: > >> This will get rid of the following error: > >> [ 74.730271] WARNING: CPU: 4 PID: 0 at

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

Op 08-03-18 om 16:22 schreef Ville Syrjälä: > On Thu, Mar 08, 2018 at 01:02:02PM +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 v2 13/15] drm/i915/guc: Allow user to control default GuC logging

While both naming and actual log enable logic in GuC interface are confusing, we can simply expose the default log as yet another log level. GuC logic aside, from i915 point of view we now have the following GuC log levels: 0 Log disabled 1 Non-verbose log 2-5 Verbose log

[Intel-gfx] [PATCH v2 14/15] drm/i915/guc: Default to non-verbose GuC logging

Now that we've decoupled logging from relay, GuC log level is only controlling the GuC behavior - there shouldn't be any impact on i915 behaviour. We're only going to see a single extra interrupt when log will get half full. That, and the fact that we're seeing igt/gem_exec_nop/basic-series

[Intel-gfx] [PATCH 15/15] HAX enable guc for CI

--- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c96360398072..53037b5eff22 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++

[Intel-gfx] [PATCH v2 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter and tidy the debugfs formatting. v2: Correct stats accounting (Sagar) Signed-off-by: Michał Winiarski Cc: Chris

[Intel-gfx] [PATCH 11/15] drm/i915/guc: Always print log stats in i915_guc_info when using GuC

While some of the content in this file is related to GuC submission only, that's not the case with log related statistics. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio Cc:

[Intel-gfx] [PATCH v2 10/15] drm/i915/guc: Get rid of GuC log runtime

Runtime is not a very good name. Let's also move counting relay overflows inside relay struct. v2: Rename things rather than remove the struct (Chris) Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Daniele Ceraolo Spurio

[Intel-gfx] [PATCH v2 07/15] drm/i915/guc: Flush directly in log unregister

Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation is quite simple. Let's get rid of it and move its content to unregister. v2: s/dev_priv/i915 (Sagar) Signed-off-by: Michał Winiarski

[Intel-gfx] [PATCH v2 08/15] drm/i915/guc: Split relay control and GuC log level

Those two concepts are really separate. Since GuC is writing data into its own buffer and we even provide a way for userspace to read directly from it using i915_guc_log_dump debugfs, there's no real reason to tie log level with relay creation. Let's create a separate debugfs, giving userspace a

  1   2   3   >