[Intel-gfx] [PATCH v2 4/4] drm/i915/psr: Timestamps for PSR entry and exit interrupts.

Timestamps are useful for IGT tests that trigger PSR exit and/or wait for PSR entry. v2: Removed seqlock (Ville) Removed erroneous warning in irq loop (Chris) Cc: Ville Syrjälä Cc: Rodrigo Vivi Cc: Chris Wilson

[Intel-gfx] [PATCH v2 2/4] drm/i915: Enable edp psr error interrupts on bdw+

From: Ville Syrjälä Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on any transcoder in theory, though the we don't currenty enable PSR except on the EDP transcoder. v2: From DK * Rebased on drm-tip v3: Switched author to Ville based on IRC

[Intel-gfx] [PATCH v2 1/4] drm/i915: Enable edp psr error interrupts on hsw

From: Daniel Vetter The definitions for the error register should be valid on bdw/skl too, but there we haven't even enabled DE_MISC handling yet. Somewhat confusing the the moved register offset on bdw is only for the _CTL/_AUX register, and that _IIR/IMR stayed where

[Intel-gfx] [PATCH v2 3/4] drm/i915/psr: Control PSR interrupts via debugfs

Interrupts other than the one for AUX errors are required only for debug, so unmask them via debugfs when the user requests debug. User can make such a request with echo 1 > /dri/0/i915_edp_psr_debug v2: Unroll loops (Ville) Avoid resetting error mask bits. Cc: Rodrigo Vivi

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit

== Series Details == Series: series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit URL : https://patchwork.freedesktop.org/series/40702/ State : success == Summary == Known issues: Test kms_flip: Subgroup flip-vs-expired-vblank: pass -> FAIL

[Intel-gfx] [PATCH v2 04/10] drm/i915/psr: Tie PSR2 support to Y coordinate requirement

Although i915 don't implement aux sync frame through tests was findout that pannels can do selective update when the y-coordinate is also included in SDP, that is why it is required to run PSR2 in i915. So moving to only one place the sink requirements that the actual driver needs to enable PSR2.

[Intel-gfx] [PATCH v2 03/10] drm/i915/psr: Nuke aux frame sync

eDP spec states that aux frame is required to do PSR2 selective update but i915 don't fully implement it. It sends the aux frame sync messages but the value is always zero as the GTC is not enabled in driver. Through tests was findout that pannels can do selective update when the y-coordinate is

[Intel-gfx] [PATCH v2 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

In the 2 eDP1.4a pannels tested set or not set bit have no effect but is better set it and comply with specification. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi ---

[Intel-gfx] [PATCH v2 07/10] drm/i915/psr: Use PSR2 macro for PSR2

Cosmetic change. Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_reg.h | 3 ++- drivers/gpu/drm/i915/intel_psr.c | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw

== Series Details == Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw URL : https://patchwork.freedesktop.org/series/40704/ State : warning == Summary == $ dim checkpatch origin/drm-tip e0e155ae5044 drm/i915: Enable edp psr error interrupts on hsw -:109:

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support (rev4)

> -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Monday, March 26, 2018 7:19 PM > To: Patchwork ; Srinivas, Vidya > > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw

== Series Details == Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw URL : https://patchwork.freedesktop.org/series/40704/ State : success == Summary == Known issues: Test kms_flip: Subgroup blocking-wf_vblank: pass

[Intel-gfx] [PATCH v2 05/10] drm/i915/psr/cnl: Enable Y-coordinate support in source

From: "Souza, Jose" For Geminilake and Cannonlake+ the Y-coordinate support must be enabled in PSR2_CTL too. Spec: 7713 and 7720 Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza

[Intel-gfx] [PATCH v2 10/10] drm/i915/debugfs: Print sink PSR status

IGT tests could be improved with sink status, knowing for sure that hardware have activate or exit PSR. Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi Signed-off-by: José Roberto de Souza ---

[Intel-gfx] [PATCH v2 08/10] drm/i915/psr: Cache sink synchronization latency

This value do not change overtime so better cache it than fetch it every PSR enable. Cc: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_drv.h | 1 +

[Intel-gfx] [PATCH v2 06/10] drm/i915/psr: Do not override PSR2 sink support

Sink can support our PSR2 requirements but userspace can request a resolution that PSR2 hardware do not support, in this case it was overwritten the PSR2 sink support. Adding another flag here, this way if requested resolution changed to a value that PSR2 hardware can handle, PSR2 can be enabled.

[Intel-gfx] [PATCH v2 01/10] drm: Add DP PSR2 sink enable bit

To comply with eDP1.4a this bit should be set when enabling PSR2. Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi --- include/drm/drm_dp_helper.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_dp_helper.h

[Intel-gfx] [PATCH v2 02/10] drm: Add DP last received PSR SDP VSC register and bits

This is a register to help debug what is in the last SDP VSC packet revived by sink. Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi --- include/drm/drm_dp_helper.h | 9 + 1 file changed, 9 insertions(+) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit

== Series Details == Series: series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit URL : https://patchwork.freedesktop.org/series/40702/ State : success == Summary == Series 40702v1 series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit

== Series Details == Series: series starting with [v2,01/10] drm: Add DP PSR2 sink enable bit URL : https://patchwork.freedesktop.org/series/40702/ State : warning == Summary == $ dim checkpatch origin/drm-tip 38150dd0cc54 drm: Add DP PSR2 sink enable bit b58a3e8a7618 drm: Add DP last

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw

== Series Details == Series: series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw URL : https://patchwork.freedesktop.org/series/40704/ State : success == Summary == Series 40704v1 series starting with [v2,1/4] drm/i915: Enable edp psr error interrupts on hsw

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: optimize perf stream usage on Gen7.5

== Series Details == Series: drm/i915/perf: optimize perf stream usage on Gen7.5 URL : https://patchwork.freedesktop.org/series/40656/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9b2b2bce30f9 drm/i915/perf: pass stream to enable metric set vfuncs 2c159dc9b427 drm/i915/perf:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: optimize perf stream usage on Gen7.5

== Series Details == Series: drm/i915/perf: optimize perf stream usage on Gen7.5 URL : https://patchwork.freedesktop.org/series/40656/ State : success == Summary == Series 40656v1 drm/i915/perf: optimize perf stream usage on Gen7.5

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values

Quoting Yaodong Li (2018-03-23 19:33:15) > As I said, I agree that we would likely solve the enable_guc=1 then > enable_guc=3 case with these changes which I think this the the only benefit > that we can get from the starting from the top way. > But my point is just like the from the bottom way,

Re: [Intel-gfx] [PATCH v4 1/7] drm/i915: Correctly handle error path in i915_gem_init_hw

On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: In function gem_init_hw() we are calling uc_init_hw() but in case of error later in function, we missed to call matching uc_fini_hw() Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc:

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add NV12 support (rev4)

== Series Details == Series: Add NV12 support (rev4) URL : https://patchwork.freedesktop.org/series/39670/ State : failure == Summary == Possible new issues: Test kms_plane_scaling: Subgroup pipe-a-scaler-with-pixel-format: pass -> FAIL (shard-apl)

[Intel-gfx] [PATCH 01/11] drm/i915/perf: pass stream to enable metric set vfuncs

We want to use some of the properties of the perf stream to program the hardware in a later commit. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_perf.c | 10 ++ 2 files changed, 7 insertions(+), 5

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/perf: optimize perf stream usage on Gen7.5

== Series Details == Series: drm/i915/perf: optimize perf stream usage on Gen7.5 URL : https://patchwork.freedesktop.org/series/40656/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/perf: pass stream to enable metric set vfuncs Okay! Commit: drm/i915/perf: check

Re: [Intel-gfx] [RFC] splitting dri-devel to drm core and drivers lists?

On Mon, Mar 26, 2018 at 10:00 AM, Jani Nikula wrote: > On Mon, 26 Mar 2018, Daniel Vetter wrote: >> And as mentioned I think dri-drivers isn't big enough to be >> sustainable on its own. > > It certainly is big enough to be disruptive to my inbox, and I

[Intel-gfx] [PATCH 03/11] drm/i915/perf: simplify OA unit enabling on gen7

In commit d79651522e89c "drm/i915: Enable i915 perf stream for Haswell OA unit" the enable/disable vfunc hadn't appear yet and the same function would deal with enabling/disabling the OA unit. This was split later on for gen8 but the gen7 retained some code that isn't actually useful anymore.

[Intel-gfx] [PATCH 11/11] drm/i915/perf: remove redundant oa buffer initialization

We initialize the OA buffer everytime we enable the OA unit (first call in gen[78]_oa_enable), so we don't need to initialize when preparing the metric set. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_drv.h | 17 -

[Intel-gfx] [PATCH 05/11] drm/i915/perf: remove empty line

This was added by mistake in commit 28964cf25e "drm/i915/perf: disable NOA logic when not used". Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c

[Intel-gfx] [PATCH 04/11] drm/i915/perf: do not warn when OA buffer is already allocated

If 2 processes race to open the perf stream, it's possible that one of them will see that OA buffer has already been allocated, while a previous process is still finishing to reprogram the hardware (on gen8+). The opening sequence has been reworked a few times and we probably lost track of the

[Intel-gfx] [PATCH 10/11] drm/i915/perf: limit OA buffer size to minimum when unread

The way our hardware is designed doesn't seem to let us use the MI_RECORD_PERF_COUNT command without setting up a circular buffer. In the case where the user didn't request OA reports to be available through the i915 perf stream, we can set the OA buffer to the minimum size to avoid consuming

[Intel-gfx] [PATCH 07/11] drm/i915/perf: pass stream as argument to oa enable vfunc

This will allow use to program the hardware based on the stream's properties in a later commit. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_drv.h | 3 ++- drivers/gpu/drm/i915/i915_perf.c | 12 +++- 2 files changed, 9 insertions(+), 6

[Intel-gfx] [PATCH 09/11] drm/i915/perf: allowing opening the perf stream without sampling

We want to allow a user to configure the OA hardware so that MI_RECORD_PERF_COUNT is functional but without having to deal with the OA buffer. This is an interesting optimization we can apply on Gen7.5 has the OA unit perfectly clocks off if you've configured it to filter on a particular context

[Intel-gfx] [PATCH 06/11] drm/i915: rename PPGTT/GGTT fields OA registers

We had a generic field name used across 2 registers but it feels like it's clearer we make it obvious what register this field belongs to. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 7 --- drivers/gpu/drm/i915/i915_reg.h | 6

[Intel-gfx] [PATCH 00/11] drm/i915/perf: optimize perf stream usage on Gen7.5

Hi, This series is kind of an optimization we can make on Gen7.5 for dealing with the perf stream in the case where we measure workloads at boundaries of the command stream (much like what i965 INTEL_performance_query does in Mesa). Along the way to implement this, quite a few cleanups

[Intel-gfx] [PATCH 02/11] drm/i915/perf: check the value of PROP_SAMPLE_OA uapi parameter

We've been a bit loose about this opening parameter. We should only add the flag for writing OA reports when the value of this parameter is != 0. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 3 ++- 1 file changed, 2 insertions(+), 1

[Intel-gfx] [PATCH 08/11] drm/i915/perf: add more debug message on open perf open & configs

This will make it easier to spot issues related to config creation/usage. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c

Re: [Intel-gfx] [RFC] splitting dri-devel to drm core and drivers lists?

On Mon, Mar 26, 2018 at 09:42:52AM +0300, Joonas Lahtinen wrote: > Quoting Daniel Vetter (2018-03-23 18:39:04) > > On Fri, Mar 23, 2018 at 06:22:46PM +0200, Jani Nikula wrote: > > > There was some discussion on the dim-tools list about splitting the > > > dri-devel list to drm core and drivers

Re: [Intel-gfx] [RFC] splitting dri-devel to drm core and drivers lists?

On Mon, 26 Mar 2018, Daniel Vetter wrote: > And as mentioned I think dri-drivers isn't big enough to be > sustainable on its own. It certainly is big enough to be disruptive to my inbox, and I don't seem to be alone. BR, Jani. -- Jani Nikula, Intel Open Source Technology

Re: [Intel-gfx] [PATCH v4 2/7] drm/i915/uc: Disable GuC submission during sanitize

On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: We should not leave GuC submission enabled after sanitize, as we are going to reset all GuC/HuC hardware. Signed-off-by: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson

Re: [Intel-gfx] [RFC] splitting dri-devel to drm core and drivers lists?

Quoting Daniel Vetter (2018-03-23 18:39:04) > On Fri, Mar 23, 2018 at 06:22:46PM +0200, Jani Nikula wrote: > > There was some discussion on the dim-tools list about splitting the > > dri-devel list to drm core and drivers lists [1]. Moving the discussion > > to the list in question seems prudent.

Re: [Intel-gfx] [PATCH v4 0/8] cgroup private data and DRM/i915 integration

Quoting Matt Roper (2018-03-23 17:46:16) > On Fri, Mar 23, 2018 at 02:15:38PM +0200, Joonas Lahtinen wrote: > > Quoting Matt Roper (2018-03-17 02:08:57) > > > This is the fourth iteration of the work previously posted here: > > > (v1) > > >

Re: [Intel-gfx] [RFC v1] Data port coherency control for UMDs.

Here is pull request with patch usage: https://github.com/intel/compute-runtime/pull/29 This patch is required to control data port coherency depending on incoming workload into OpenCL API (fine-grain SVM requirement). -Original Message- From: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 5/8] drm/i915/guc: Use GuC FW size and HW restrictions to determine WOPCM partition

On Fri, Mar 23, 2018 at 01:00:35PM -0700, Yaodong Li wrote: > On 03/23/2018 05:34 AM, Michał Winiarski wrote: > > We need GuC to load HuC, but it's also possible for GuC to operate on > > its own. We don't know what the size of HuC FW may be, so, not wanting > > to make any platform-specific

Re: [Intel-gfx] [PATCH v2 13/23] drm/zte: Stop consulting plane->fb

On Thu, Mar 22, 2018 at 07:40:03PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb on atomic drivers. Stop looking at it. Would it be more precise to use "plane->crtc" in both subject and commit log? Other than that:

[Intel-gfx] [CI i-g-t] tests/perf_pmu: Avoid RT thread for accuracy test

From: Tvrtko Ursulin Realtime scheduling interferes with execlists submission (tasklet) so try to simplify the PWM loop in a few ways: * Drop RT. * Longer batches for smaller systematic error. * More truthful test duration calculation. * Less clock queries. * No

Re: [Intel-gfx] [PATCH v4 3/7] drm/i915/uc: Fully sanitize uC in uc_fini_hw

On 3/23/2018 8:44 PM, Michal Wajdeczko wrote: Today uc_fini_hw is subset of uc_sanitize, but remaining code in sanitize function is also desired for uc_fini_hw. Instead of duplicating the code, just call uc_sanitize, but leave as separate function to maintain symmetry with uc_init_hw.

[Intel-gfx] [PATCH v3 13/23] drm/zte: Stop consulting plane->crtc

From: Ville Syrjälä We want to get rid of plane->crtc on atomic drivers. Stop looking at it. v2: Use old_state->crtc (Maarten) v3: s/fb/crtc/ in commit message to actually match the patch (Shawn) Cc: Shawn Guo Cc: Maarten Lankhorst

Re: [Intel-gfx] [PATCH] drm/i915: protect macro parameters in SWING_SEL_{UPP, LO}WER

On Fri, 23 Mar 2018, Paulo Zanoni wrote: > Protect the macro parameters with parens in order to avoid priority > issues on macro evaluation when the macro argument is not a single > operand. > > This is not a problem today, but it could be in the future. I found > this

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/perf: enable perf support on ICL (rev2)

== Series Details == Series: drm/i915/perf: enable perf support on ICL (rev2) URL : https://patchwork.freedesktop.org/series/39689/ State : warning == Summary == $ dim checkpatch origin/drm-tip 778ddd601367 drm/i915/icl: read timestamp frequency information -:19: WARNING:LONG_LINE: line over

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)

== Series Details == Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5) URL : https://patchwork.freedesktop.org/series/40478/ State : warning == Summary == $ dim checkpatch origin/drm-tip eec2e4920fa9 Revert "drm/atomic-helper: Fix leak in disable_all" 885b9185b11c

Re: [Intel-gfx] [igt-dev] [CI i-g-t] tests/perf_pmu: Avoid RT thread for accuracy test

Quoting Tvrtko Ursulin (2018-03-26 11:57:58) > * No self-adjust - instead just report the achieved cycle and let the >parent check against it. Sniff, I was rather proud of our achievement. I had it in mind as a template for future autocalibration routines. Is it really useless

Re: [Intel-gfx] [PATCH 04/11] drm/i915/perf: do not warn when OA buffer is already allocated

On 26/03/18 13:00, Matthew Auld wrote: On 26 March 2018 at 10:08, Lionel Landwerlin wrote: If 2 processes race to open the perf stream, it's possible that one of them will see that OA buffer has already been allocated, while a previous process is still finishing

Re: [Intel-gfx] [PATCH 03/11] drm/i915/perf: simplify OA unit enabling on gen7

On 26 March 2018 at 10:08, Lionel Landwerlin wrote: > In commit d79651522e89c "drm/i915: Enable i915 perf stream for Haswell > OA unit" the enable/disable vfunc hadn't appear yet and the same > function would deal with enabling/disabling the OA unit. > > This was

[Intel-gfx] [PATCH 11/11] drm/i915: Allow user control over preempt timeout on the important context

EGL_NV_realtime_priority? Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 22 ++ drivers/gpu/drm/i915/i915_gem_context.h | 13 + drivers/gpu/drm/i915/i915_request.c | 8 ++--

[Intel-gfx] [PATCH 04/11] drm/i915/execlists: Refactor out complete_preempt_context()

As a complement to inject_preempt_context(), follow up with the function to handle its completion. This will be useful should we wish to extend the duties of the preempt-context for execlists. Signed-off-by: Chris Wilson Cc: Jeff McGee Cc: Michał

[Intel-gfx] [PATCH 01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

If the request is still waiting on external fences, it has not yet been submitted to the HW queue and so we can forgo kicking the submission tasklet when re-evaluating its priority. This should have no impact other than reducing the number of tasklet wakeups under signal heavy workloads (e.g.

[Intel-gfx] [PATCH 05/11] drm/i915: Move engine reset prepare/finish to backends

In preparation to more carefully handling incomplete preemption during reset by execlists, we move the existing code wholesale to the backends under a couple of new reset vfuncs. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel

[Intel-gfx] Forced preemption gedankenexperiment

Following the discussion of how should the timer be controlled, I wired up one option which ended up with passing control to the caller letting us use the forced-preemption for interactive uses (delay by more than a frame and you get a fast reset!) as well whatever userspace desires. -Chris

Re: [Intel-gfx] [PATCH 05/11] drm/i915/perf: remove empty line

On 26 March 2018 at 10:08, Lionel Landwerlin wrote: > This was added by mistake in commit 28964cf25e "drm/i915/perf: disable NOA > logic when not used". > > Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

== Series Details == Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling URL : https://patchwork.freedesktop.org/series/40665/ State : success == Summary == Series 40665v1 series starting with [01/11] drm/i915/execlists: Avoid

Re: [Intel-gfx] [PATCH 10/11] drm/i915/perf: limit OA buffer size to minimum when unread

On 26/03/18 10:08, Lionel Landwerlin wrote: The way our hardware is designed doesn't seem to let us use the MI_RECORD_PERF_COUNT command without setting up a circular buffer. In the case where the user didn't request OA reports to be available through the i915 perf stream, we can set the OA

[Intel-gfx] [PATCH 10/11] drm/i915: Use a preemption timeout to enforce interactivity

Use a liberal timeout of 20ms to ensure that the rendering for an interactive pageflip is started in a timely fashion, and that user interaction is not blocked by GPU, or CPU, hogs. This is at the cost of resetting whoever was blocking the preemption, likely leading to that context/process being

[Intel-gfx] [PATCH 09/11] drm/i915/preemption: Select timeout when scheduling

The choice of preemption timeout is determined by the context from which we trigger the preemption, as such allow the caller to specify the desired timeout. Effectively the other choice would be to use the shortest timeout along the dependency chain. However, given that we would have already

[Intel-gfx] [PATCH 02/11] drm/i915/execlists: Clear user-active flag on preemption completion

When cancelling the requests and clearing out the ports following a successful preemption completion, also clear the active flag. I had assumed that all preemptions would be followed by an immediate dequeue (preserving the active user flag), but under rare circumstances we may be triggering a

[Intel-gfx] [PATCH 06/11] drm/i915: Split execlists/guc reset prepartions

In the next patch, we will make the execlists reset prepare callback take into account preemption by flushing the context-switch handler. This is not applicable to the GuC submission backend, so split the two into their own backend callbacks. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 08/11] drm/i915/execlists: Force preemption via reset on timeout

Install a timer when trying to preempt on behalf of an important context such that if the active context does not honour the preemption request within the desired timeout, then we reset the GPU to allow the important context to run. (Open: should not the timer be started from receiving the high

[Intel-gfx] [PATCH 07/11] drm/i915/execlists: Flush pending preemption events during reset

Catch up with the inflight CSB events, after disabling the tasklet before deciding which request was truly guilty of hanging the GPU. Signed-off-by: Chris Wilson Cc: Michał Winiarski CC: Michel Thierry Cc: Jeff

[Intel-gfx] [PATCH 03/11] drm/i915: Include submission tasklet state in engine dump

For the off-chance we have an interrupt posted and haven't processed the CSB. v2: Include tasklet enable/disable state for good measure. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_engine_cs.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-)

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

== Series Details == Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling URL : https://patchwork.freedesktop.org/series/40665/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6cd6e46a6275 drm/i915/execlists: Avoid

Re: [Intel-gfx] [igt-dev] [CI i-g-t] tests/perf_pmu: Avoid RT thread for accuracy test

On 26/03/2018 12:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-26 11:57:58) * No self-adjust - instead just report the achieved cycle and let the parent check against it. Sniff, I was rather proud of our achievement. I had it in mind as a template for future autocalibration

[Intel-gfx] [PATCH v2 2/3] drm/i915/perf: enable perf support on ICL

No significant changes from either context offsets, nor report formats, nor register whitelist. v2: Also drop slice/unslice clock ratio changes (Matt) Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH v2 3/3] drm/i915/perf: use IS_GEN() instead an or condition

Make the code a bit more concise. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index

[Intel-gfx] [PATCH v2 0/3] drm/i915/perf: enable perf support on ICL

Hi, Adding a patch to the previous series to read the timestamp frequency on ICL which is required for the perf support. I'm sure I saw this patch written by somebody before but I can't find it back :( Please manifest yourself if you did write that patch, it should be attributed to its rightful

[Intel-gfx] [PATCH v2 1/3] drm/i915/icl: read timestamp frequency information

We're missing this value which is needed for i915/perf support. Signed-off-by: Lionel Landwerlin --- drivers/gpu/drm/i915/i915_reg.h | 6 drivers/gpu/drm/i915/intel_device_info.c | 48 2 files changed, 43

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/perf: optimize perf stream usage on Gen7.5

== Series Details == Series: drm/i915/perf: optimize perf stream usage on Gen7.5 URL : https://patchwork.freedesktop.org/series/40656/ State : failure == Summary == Possible new issues: Test perf: Subgroup missing-sample-flags: pass -> FAIL

Re: [Intel-gfx] [PATCH 04/11] drm/i915/perf: do not warn when OA buffer is already allocated

On 26 March 2018 at 10:08, Lionel Landwerlin wrote: > If 2 processes race to open the perf stream, it's possible that one of them > will see that OA buffer has already been allocated, while a previous process > is still finishing to reprogram the hardware (on

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add NV12 support (rev4)

On Mon, 26 Mar 2018, Patchwork wrote: > == Series Details == > > Series: Add NV12 support (rev4) > URL : https://patchwork.freedesktop.org/series/39670/ > State : warning > > == Summary == > > $ dim checkpatch origin/drm-tip > 0503b1db737a drm/i915/skl+: rename

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/perf: enable perf support on ICL (rev2)

== Series Details == Series: drm/i915/perf: enable perf support on ICL (rev2) URL : https://patchwork.freedesktop.org/series/39689/ State : warning == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup short-flip-before-cursor-toggle: pass ->

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

On Mon, 26 Mar 2018 17:35:00 +0200, Jani Nikula wrote: On Mon, 26 Mar 2018, Michał Winiarski wrote: On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote: Instead of returning small data in response status dword, GuC may

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

== Series Details == Series: drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore URL : https://patchwork.freedesktop.org/series/40676/ State : failure == Summary == Possible new issues: Test drv_module_reload: Subgroup basic-no-display: pass ->

Re: [Intel-gfx] [PATCH v4 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

On 26/03/2018 17:12, Yunwei Zhang wrote: WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3)

== Series Details == Series: series starting with [v4,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3) URL : https://patchwork.freedesktop.org/series/40503/ State : success == Summary == Series 40503v3 series starting with [v4,1/2] drm/i915/cnl: Implement

Re: [Intel-gfx] [PATCH 5/5] drm/i915/execlists: Flush pending preemption events during reset

Quoting Jeff McGee (2018-03-22 15:14:01) > On Tue, Mar 20, 2018 at 05:17:34PM -0700, Jeff McGee wrote: > > On Tue, Mar 20, 2018 at 12:18:48AM +, Chris Wilson wrote: > > > Catch up with the inflight CSB events, after disabling the tasklet > > > before deciding which request was truly guilty of

Re: [Intel-gfx] [PATCH 06/11] drm/i915: rename PPGTT/GGTT fields OA registers

On 26 March 2018 at 10:08, Lionel Landwerlin wrote: > We had a generic field name used across 2 registers but it feels like > it's clearer we make it obvious what register this field belongs to. > > Signed-off-by: Lionel Landwerlin

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)

== Series Details == Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5) URL : https://patchwork.freedesktop.org/series/40478/ State : success == Summary == Series 40478v5 drm: Eliminate plane->fb/crtc usage for atomic drivers

[Intel-gfx] [PATCH v4 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a MMIO read into L3Bank range will return 0

[Intel-gfx] [PATCH v4 1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

WaProgramMgsrForCorrectSliceSpecificMmioReads dictate that before any MMIO read into Slice/Subslice specific registers, MCR packet control register(0xFDC) needs to be programmed to point to any enabled slice/subslice pair. Otherwise, incorrect value will be returned. However, that means each

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Wrap mmu_notifier inside its own rw_semaphore

Quoting Tvrtko Ursulin (2018-03-26 16:59:20) > > On 26/03/2018 15:59, Chris Wilson wrote: > > We've always been blatantly ignoring mmu_notifier.h: > > > > * Invalidation of multiple concurrent ranges may be > > * optionally permitted by the driver. Either way the > > * establishment of

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

On Mon, 26 Mar 2018 17:29:32 +0200, Michał Winiarski wrote: On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote: Instead of returning small data in response status dword, GuC may append longer data as response message payload. If caller provides

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Allow user control over preempt timeout on the important context

On 26/03/2018 12:50, Chris Wilson wrote: EGL_NV_realtime_priority? Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 22 ++ drivers/gpu/drm/i915/i915_gem_context.h | 13 + drivers/gpu/drm/i915/i915_request.c

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3)

== Series Details == Series: series starting with [v4,1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads (rev3) URL : https://patchwork.freedesktop.org/series/40503/ State : warning == Summary == $ dim checkpatch origin/drm-tip 530daf66ff2f drm/i915/cnl: Implement

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads

On 26/03/2018 17:12, Yunwei Zhang wrote: L3Bank could be fused off in hardware for debug purpose, and it is possible that subslice is enabled while its corresponding L3Bank pairs are disabled. In such case, if MCR packet control register(0xFDC) is programed to point to a disabled bank pair, a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: enable perf support on ICL (rev2)

== Series Details == Series: drm/i915/perf: enable perf support on ICL (rev2) URL : https://patchwork.freedesktop.org/series/39689/ State : success == Summary == Series 39689v2 drm/i915/perf: enable perf support on ICL https://patchwork.freedesktop.org/api/1.0/series/39689/revisions/2/mbox/

Re: [Intel-gfx] [PATCH v4 08/13] drm/i915/guc: Implement response handling in send_ct()

On Mon, 26 Mar 2018, Michał Winiarski wrote: > On Fri, Mar 23, 2018 at 02:47:23PM +, Michal Wajdeczko wrote: >> Instead of returning small data in response status dword, >> GuC may append longer data as response message payload. >> If caller provides response

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5)

== Series Details == Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev5) URL : https://patchwork.freedesktop.org/series/40478/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-dpms-vs-vblank-race: fail -> PASS

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling

== Series Details == Series: series starting with [01/11] drm/i915/execlists: Avoid kicking the submission too early for rescheduling URL : https://patchwork.freedesktop.org/series/40665/ State : failure == Summary == Possible new issues: Test gem_ctx_param: Subgroup

  1   2   >