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

Hi, Joonas Here's gvt-next-fixes update for 4.17. One regression that caused guest VM gpu hang has been fixed and with other changes as details below. Thanks -- The following changes since commit 22de4e7a531b623962e62ee6d3a39a7e51bdf90e: drm/i915/pmu: Work around compiler warnings on some

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: enable guc interrupts unconditionally in uc_resume

== Series Details == Series: drm/i915/guc: enable guc interrupts unconditionally in uc_resume URL : https://patchwork.freedesktop.org/series/40242/ State : failure == Summary == Series 40242v1 drm/i915/guc: enable guc interrupts unconditionally in uc_resume

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Add control flags to i915_handle_error()

== Series Details == Series: series starting with [1/5] drm/i915: Add control flags to i915_handle_error() URL : https://patchwork.freedesktop.org/series/40240/ State : success == Summary == Series 40240v1 series starting with [1/5] drm/i915: Add control flags to i915_handle_error()

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

Hi Matt, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180319] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/matthew

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/5] drm/i915: Add control flags to i915_handle_error()

== Series Details == Series: series starting with [1/5] drm/i915: Add control flags to i915_handle_error() URL : https://patchwork.freedesktop.org/series/40240/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Add control flags to i915_handle_error()

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/5] drm/i915: Add control flags to i915_handle_error()

== Series Details == Series: series starting with [1/5] drm/i915: Add control flags to i915_handle_error() URL : https://patchwork.freedesktop.org/series/40240/ State : warning == Summary == $ dim checkpatch origin/drm-tip b279af513a73 drm/i915: Add control flags to i915_handle_error()

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

== Series Details == Series: drm/i915/guc: Don't try to enable GuC logging when we're not using GuC URL : https://patchwork.freedesktop.org/series/40239/ State : success == Summary == Series 40239v1 drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add control flags to i915_handle_error()

Quoting Michel Thierry (2018-03-20 00:56:04) > On 3/19/2018 5:44 PM, Chris Wilson wrote: > > Quoting Michel Thierry (2018-03-20 00:39:35) > >> On 3/19/2018 5:18 PM, Chris Wilson wrote: > >>> Not all callers want the GPU error to handled in the same way, so expose > >>> a control parameter. In the

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

Hi all, Today's linux-next merge of the drm-misc tree got a conflict in: drivers/gpu/drm/sun4i/sun4i_tcon.h between commit: e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit") from Linus' tree and commit: 6664e9dc5383 ("drm/sun4i: Add support for A80 TCONs")

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

Hi Matt, Thank you for the patch! Yet something to improve: [auto build test ERROR on v4.16-rc4] [also build test ERROR on next-20180319] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/matthew

[Intel-gfx] [PATCH] drm/i915/guc: enable guc interrupts unconditionally in uc_resume

Probably lost while rebasing commit eacd8391f977 ("drm/i915/guc: Keep GuC interrupts enabled when using GuC"). Not really needed since i915_gem_init_hw is called before uc_resume, but it brings symmetry to uc_suspend. Signed-off-by: Michel Thierry Cc: Michał Winiarski

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add control flags to i915_handle_error()

On 3/19/2018 5:44 PM, Chris Wilson wrote: Quoting Michel Thierry (2018-03-20 00:39:35) On 3/19/2018 5:18 PM, Chris Wilson wrote: Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add control flags to i915_handle_error()

Quoting Michel Thierry (2018-03-20 00:39:35) > On 3/19/2018 5:18 PM, Chris Wilson wrote: > > Not all callers want the GPU error to handled in the same way, so expose > > a control parameter. In the first instance, some callers do not want the > > heavyweight error capture so add a bit to request

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add control flags to i915_handle_error()

On 3/19/2018 5:18 PM, Chris Wilson wrote: Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to

[Intel-gfx] [PATCH 2/5] 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 1/5] drm/i915: Add control flags to i915_handle_error()

Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to i915_reset/i915_reset_engine so that we

[Intel-gfx] [PATCH 3/5] 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] [PATCH 4/5] 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 5/5] 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

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

Quoting Michał Winiarski (2018-03-20 00:13:37) > When changing the default values for guc_log_level, we accidentally left > the log enabled on non-guc platforms. Let's fix that. > > Fixes: 9605d1ce7c6b ("drm/i915/guc: Default to non-verbose GuC logging") > Reported-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915/guc: Don't try to enable GuC logging when we're not using GuC

When changing the default values for guc_log_level, we accidentally left the log enabled on non-guc platforms. Let's fix that. Fixes: 9605d1ce7c6b ("drm/i915/guc: Default to non-verbose GuC logging") Reported-by: Chris Wilson Signed-off-by: Michał Winiarski

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Disable some extra clang warnings (rev2)

== Series Details == Series: drm/i915: Disable some extra clang warnings (rev2) URL : https://patchwork.freedesktop.org/series/40145/ State : warning == Summary == Possible new issues: Test drv_suspend: Subgroup forcewake: pass -> SKIP (shard-snb)

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads

== Series Details == Series: series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads URL : https://patchwork.freedesktop.org/series/40233/ State : warning == Summary == Series 40233v1 series starting with [1/2] drm/i915/cnl: Implement

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

== Series Details == Series: series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads URL : https://patchwork.freedesktop.org/series/40233/ State : warning == Summary == $ dim checkpatch origin/drm-tip e6a22b973125 drm/i915/cnl: Implement

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: make GEM_WARN_ON less terrible

== Series Details == Series: drm/i915: make GEM_WARN_ON less terrible URL : https://patchwork.freedesktop.org/series/40215/ State : success == Summary == Known issues: Test kms_flip: Subgroup flip-vs-absolute-wf_vblank-interruptible: fail -> PASS

Re: [Intel-gfx] [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

On 03/19/2018 04:23 PM, Chris Wilson wrote: Quoting Gustavo A. R. Silva (2018-03-19 20:50:12) Hi Chris, On 03/19/2018 03:38 PM, Chris Wilson wrote: Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) _workload_ is being dereferenced before it is null checked, hence there is a potential null

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

Quoting Yunwei Zhang (2018-03-19 21:50:08) > + /* If more than one slice are enabled, L3Banks should be all enabled > */ > + if (hweight8(sseu->slice_mask) == 1) { if (is_power_of_two(sseu->slice_mask)) -Chris ___ Intel-gfx mailing list

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

Quoting Yunwei Zhang (2018-03-19 21:50:07) > 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

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

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

Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reword warning for missing cases (rev2)

CCing checkpatch maintainers On Mon, Mar 19, 2018 at 06:36:16PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Reword warning for missing cases (rev2) > URL : https://patchwork.freedesktop.org/series/39821/ > State : warning > > == Summary == > > $ dim checkpatch

Re: [Intel-gfx] [PATCH v2] drm/i915: Reword warning for missing cases

Quoting Lucas De Marchi (2018-03-19 17:37:20) > In some places we end up converting switch statements to a series of > if/else, particularly when introducing helper functions to handle a > group of cases. It's tempting to either leave a wrong warning (since now > we don't have a switch case

Re: [Intel-gfx] [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

Hi Chris, On 03/19/2018 03:38 PM, Chris Wilson wrote: Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) _workload_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _workload_ has been null

Re: [Intel-gfx] [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

Quoting Gustavo A. R. Silva (2018-03-19 20:50:12) > Hi Chris, > > On 03/19/2018 03:38 PM, Chris Wilson wrote: > > Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) > >> _workload_ is being dereferenced before it is null checked, hence > >> there is a potential null pointer dereference. > >> > >>

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Promote .format_mod_supported() to the lead role

On Mon, Mar 19, 2018 at 09:17:16PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Promote .format_mod_supported() to the lead role > URL : https://patchwork.freedesktop.org/series/40207/ > State : warning > > == Summary == > > Possible new issues: > > Test

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Promote .format_mod_supported() to the lead role

== Series Details == Series: drm/i915: Promote .format_mod_supported() to the lead role URL : https://patchwork.freedesktop.org/series/40207/ State : warning == Summary == Possible new issues: Test kms_vblank: Subgroup pipe-a-ts-continuation-suspend: pass

Re: [Intel-gfx] [PATCH i-g-t 4/5] tests/perf_pmu: Add tests for engine queued/runnable/running stats

Quoting Tvrtko Ursulin (2018-03-19 18:22:04) > From: Tvrtko Ursulin > > Simple tests to check reported queue depths are correct. > > Signed-off-by: Tvrtko Ursulin > --- > tests/perf_pmu.c | 224 >

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v3,1/3] drm/i915/guc: Unify naming of private GuC action functions

== Series Details == Series: series starting with [v3,1/3] drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/40204/ State : warning == Summary == Possible new issues: Test drv_suspend: Subgroup forcewake:

Re: [Intel-gfx] [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

Quoting Gustavo A. R. Silva (2018-03-19 19:30:53) > _workload_ is being dereferenced before it is null checked, hence > there is a potential null pointer dereference. > > Fix this by moving the pointer dereference after _workload_ has > been null checked. The checks are misleading and not

Re: [Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

On Mon, 19 Mar 2018, Matthew Auld wrote: > On 19 March 2018 at 18:17, Chris Wilson wrote: >> Quoting Matthew Auld (2018-03-19 18:08:54) >>> GEM_WARN_ON() was originally intended to be used only as: >>> >>>if (GEM_WARN_ON(expr)) >>>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Disable some extra clang warnings (rev2)

== Series Details == Series: drm/i915: Disable some extra clang warnings (rev2) URL : https://patchwork.freedesktop.org/series/40145/ State : success == Summary == Series 40145v2 drm/i915: Disable some extra clang warnings

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Disable some extra clang warnings (rev2)

== Series Details == Series: drm/i915: Disable some extra clang warnings (rev2) URL : https://patchwork.freedesktop.org/series/40145/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Disable some extra clang warnings - +drivers/gpu/drm/i915/gvt/gtt.c:661:9:

[Intel-gfx] ✗ Fi.CI.BAT: failure for Queued/runnable/running engine stats (rev3)

== Series Details == Series: Queued/runnable/running engine stats (rev3) URL : https://patchwork.freedesktop.org/series/36926/ State : failure == Summary == Series 36926v3 Queued/runnable/running engine stats https://patchwork.freedesktop.org/api/1.0/series/36926/revisions/3/mbox/

[Intel-gfx] [PATCH] drm/i915/gvt/scheduler: fix potential NULL pointer dereference

_workload_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _workload_ has been null checked. Addresses-Coverity-ID: 1430136 ("Dereference before null check") Fixes: fa3dd623e559 ("drm/i915/gvt:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: make GEM_WARN_ON less terrible

== Series Details == Series: drm/i915: make GEM_WARN_ON less terrible URL : https://patchwork.freedesktop.org/series/40215/ State : success == Summary == Series 40215v1 drm/i915: make GEM_WARN_ON less terrible https://patchwork.freedesktop.org/api/1.0/series/40215/revisions/1/mbox/

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2,1/3] drm/i915/guc: Unify naming of private GuC action functions

== Series Details == Series: series starting with [v2,1/3] drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/40190/ State : success == Summary == Possible new issues: Test pm_rc6_residency: Subgroup rc6-accuracy:

Re: [Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

On 19 March 2018 at 18:17, Chris Wilson wrote: > Quoting Matthew Auld (2018-03-19 18:08:54) >> GEM_WARN_ON() was originally intended to be used only as: >> >>if (GEM_WARN_ON(expr)) >> ... >> >> but it just so happens to also work as simply: >> >>

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: make GEM_WARN_ON less terrible

== Series Details == Series: drm/i915: make GEM_WARN_ON less terrible URL : https://patchwork.freedesktop.org/series/40215/ State : warning == Summary == $ dim checkpatch origin/drm-tip 09aaab021f8c drm/i915: make GEM_WARN_ON less terrible -:32: ERROR:SPACING: space required after that ';'

[Intel-gfx] [PATCH v2] drm/i915: Disable some extra clang warnings

Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set warnings to full") enabled extra warnings for i915 to spot possible bugs in new code, and then disabled a subset of these warnings to keep the current code building without warnings (with gcc). Enabling the extra warnings also

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

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

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

On Fri, 16 Mar 2018, 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. With the introduction > of more advanced features there are

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Reword warning for missing cases (rev2)

== Series Details == Series: drm/i915: Reword warning for missing cases (rev2) URL : https://patchwork.freedesktop.org/series/39821/ State : failure == Summary == Series 39821v2 drm/i915: Reword warning for missing cases https://patchwork.freedesktop.org/api/1.0/series/39821/revisions/2/mbox/

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

== Series Details == Series: drm/i915/gvt: fix spelling mistake: "registeration" -> "registration" URL : https://patchwork.freedesktop.org/series/40185/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-flip-vs-expired-vblank-interruptible:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Reword warning for missing cases (rev2)

== Series Details == Series: drm/i915: Reword warning for missing cases (rev2) URL : https://patchwork.freedesktop.org/series/39821/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7cb94d2c3c47 drm/i915: Reword warning for missing cases -:40: CHECK:MACRO_ARG_REUSE: Macro

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Promote .format_mod_supported() to the lead role

== Series Details == Series: drm/i915: Promote .format_mod_supported() to the lead role URL : https://patchwork.freedesktop.org/series/40207/ State : success == Summary == Series 40207v1 drm/i915: Promote .format_mod_supported() to the lead role

[Intel-gfx] [PATCH i-g-t 5/5] tests/i915_query: Engine queues tests

From: Tvrtko Ursulin ... Signed-off-by: Tvrtko Ursulin --- tests/i915_query.c | 381 + 1 file changed, 381 insertions(+) diff --git a/tests/i915_query.c b/tests/i915_query.c index

[Intel-gfx] [PATCH i-g-t 2/5] intel-gpu-overlay: Add engine queue stats

From: Tvrtko Ursulin Use new PMU engine queue stats (queued, runnable and running) and display them per engine. v2: * Compact per engine stats. (Chris Wilson) Signed-off-by: Tvrtko Ursulin --- overlay/gpu-top.c | 42

[Intel-gfx] [PATCH i-g-t 3/5] intel-gpu-overlay: Show 1s, 30s and 15m GPU load

From: Tvrtko Ursulin Show total GPU loads in the window banner. Engine load is defined as total of runnable and running requests on an engine. Total, non-normalized, load is display. In other words if N engines are busy with exactly one request, the load will be shown

[Intel-gfx] [PATCH i-g-t 1/5] include: i915 uAPI headers

From: Tvrtko Ursulin Temporary up to date uAPI headers. Signed-off-by: Tvrtko Ursulin --- include/drm-uapi/i915_drm.h | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/include/drm-uapi/i915_drm.h

[Intel-gfx] [PATCH i-g-t 0/5] Queued/runnable/running engine stats

From: Tvrtko Ursulin IGT patches for the identicaly named i915 series, including: * Engine queue depths for intel-gpu-overlay (including load average). * Tests for new PMU counters. * Tests for the query API. Tests have been tested (!) only on Skylake so YMMV. Also

[Intel-gfx] [PATCH i-g-t 4/5] tests/perf_pmu: Add tests for engine queued/runnable/running stats

From: Tvrtko Ursulin Simple tests to check reported queue depths are correct. Signed-off-by: Tvrtko Ursulin --- tests/perf_pmu.c | 224 +++ 1 file changed, 224 insertions(+) diff --git

Re: [Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

Quoting Matthew Auld (2018-03-19 18:08:54) > GEM_WARN_ON() was originally intended to be used only as: > >if (GEM_WARN_ON(expr)) > ... > > but it just so happens to also work as simply: > >GEM_WARN_ON(expr); > > since it just wraps WARN_ON, which is a little misleading since

[Intel-gfx] [PATCH 4/7] drm/i915/pmu: Add queued counter

From: Tvrtko Ursulin We add a PMU counter to expose the number of requests which have been submitted from userspace but are not yet runnable due dependencies and unsignaled fences. This is useful to analyze the overall load of the system. v2: * Rebase for name change

[Intel-gfx] [PATCH 3/7] drm/i915: Keep a count of requests submitted from userspace

From: Tvrtko Ursulin Keep a count of requests submitted from userspace and not yet runnable due unresolved dependencies. v2: Rename and move under the container struct. (Chris Wilson) v3: Rebase. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 7/7] drm/i915: Engine queues query

From: Tvrtko Ursulin As well as exposing active requests on engines via PMU, we can also export the current raw values (as tracked by i915 command submission) via a dedicated query. This is to satisfy customers who have userspace load balancing solutions implemented on

[Intel-gfx] [PATCH 6/7] drm/i915/pmu: Add running counter

From: Tvrtko Ursulin We add a PMU counter to expose the number of requests currently executing on the GPU. This is useful to analyze the overall load of the system. v2: * Rebase. * Drop floating point constant. (Chris Wilson) v3: * Change scale to 1024 for faster

[Intel-gfx] [PATCH 5/7] drm/i915/pmu: Add runnable counter

From: Tvrtko Ursulin We add a PMU counter to expose the number of requests with resolved dependencies waiting for a slot on the GPU to run. This is useful to analyze the overall load of the system. v2: Don't limit to gen8+. v3: * Rebase for dynamic sysfs. * Drop

[Intel-gfx] [PATCH 2/7] drm/i915: Keep a count of requests waiting for a slot on GPU

From: Tvrtko Ursulin Keep a per-engine number of runnable (waiting for GPU time) requests. v2: * Move queued increment from insert_request to execlist_submit_request to avoid bumping when re-ordering for priority. * Support the counter on the ringbuffer submission

[Intel-gfx] [PATCH 1/7] drm/i915/pmu: Fix enable count array size and bounds checking

From: Tvrtko Ursulin Enable count array is supposed to have one counter for each possible engine sampler. As such array sizing and bounds checking is not correct when more engine samplers are added. At the same time tidy the assert for readability and robustness.

[Intel-gfx] [PATCH v4 0/7] Queued/runnable/running engine stats

From: Tvrtko Ursulin Per-engine queue depths are an interesting metric for analyzing the system load and also for users who wish to use it to load balance their submissions based on it. In this version I have split the metrics into three separate counters: 1. QUEUED -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Promote .format_mod_supported() to the lead role

== Series Details == Series: drm/i915: Promote .format_mod_supported() to the lead role URL : https://patchwork.freedesktop.org/series/40207/ State : warning == Summary == $ dim checkpatch origin/drm-tip bd9ae7d6edf8 drm/i915: Promote .format_mod_supported() to the lead role -:19:

[Intel-gfx] [PATCH] drm/i915: make GEM_WARN_ON less terrible

GEM_WARN_ON() was originally intended to be used only as: if (GEM_WARN_ON(expr)) ... but it just so happens to also work as simply: GEM_WARN_ON(expr); since it just wraps WARN_ON, which is a little misleading since for !DRM_I915_DEBUG_GEM builds the second case will actually

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/3] drm/i915/guc: Unify naming of private GuC action functions

== Series Details == Series: series starting with [v3,1/3] drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/40204/ State : success == Summary == Series 40204v1 series starting with [v3,1/3] drm/i915/guc: Unify naming of private GuC

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/guc: Handle GuC log flush event in dedicated function

== Series Details == Series: drm/i915/guc: Handle GuC log flush event in dedicated function URL : https://patchwork.freedesktop.org/series/40183/ State : warning == Summary == Possible new issues: Test kms_atomic_transition: Subgroup plane-all-modeset-transition:

[Intel-gfx] [PATCH v2] drm/i915: Reword warning for missing cases

In some places we end up converting switch statements to a series of if/else, particularly when introducing helper functions to handle a group of cases. It's tempting to either leave a wrong warning (since now we don't have a switch case anymore) or to convert to WARN(1, ...), but we can just

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Restore planes after load detection

== Series Details == Series: drm: Restore planes after load detection URL : https://patchwork.freedesktop.org/series/40201/ State : warning == Summary == Series 40201v1 drm: Restore planes after load detection https://patchwork.freedesktop.org/api/1.0/series/40201/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm: Restore planes after load detection

Op 19-03-18 om 16:39 schreef Ville Syrjala: > From: Ville Syrjälä > > Actually turn the planes back on after were done with > the load detection. > > Fixes: 20bdc112bbe4 ("drm/i915: Disable all planes for load detection, v2.") > Cc: Maarten Lankhorst

Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Drop union guc_log_control

On Mon, Mar 19, 2018 at 04:20:02PM +, Michal Wajdeczko wrote: > Usually we use shift/mask macros for bit field definitions. > Union guc_log_control was not following that pattern. > > Additional bonus: > > add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) > Function

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Trim error mask to known engines

Quoting Michel Thierry (2018-03-19 16:31:05) > On 19/03/18 06:12, Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-16 21:49:59) > >> For the convenience of userspace passing in an arbitrary reset mask, > >> remove unknown engines from the set of engines that are to be reset. > >> This means

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add control flags to i915_handle_error()

Quoting Michel Thierry (2018-03-19 16:48:01) > On 16/03/18 14:50, Chris Wilson wrote: > > Not all callers want the GPU error to handled in the same way, so expose > > a control parameter. In the first instance, some callers do not want the > > heavyweight error capture so add a bit to request the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Unify parameters of public CT functions

== Series Details == Series: drm/i915/guc: Unify parameters of public CT functions URL : https://patchwork.freedesktop.org/series/40197/ State : failure == Summary == Series 40197v1 drm/i915/guc: Unify parameters of public CT functions

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Trim error mask to known engines

Quoting Michel Thierry (2018-03-19 16:31:05) > On 19/03/18 06:12, Chris Wilson wrote: > > Quoting Chris Wilson (2018-03-16 21:49:59) > >> For the convenience of userspace passing in an arbitrary reset mask, > >> remove unknown engines from the set of engines that are to be reset. > >> This means

[Intel-gfx] [PATCH i-g-t v8] tests/perf_pmu: Improve accuracy by waiting on spinner to start

From: Tvrtko Ursulin More than one test assumes that the spinner is running pretty much immediately after we have create or submitted it. In actuality there is a variable delay, especially on execlists platforms, between submission and spin batch starting to run on the

[Intel-gfx] [PATCH libdrm 1/1] intel: allocate the requested size when reuse is disabled

From: "Xiong, James" 1) fixed a bug: a bucket size instead of the requested was allocated even when reuse is disabled. 2) set bo_reuse explicitly Signed-off-by: Xiong, James --- intel/intel_bufmgr_gem.c | 6 +- 1 file changed, 5 insertions(+),

[Intel-gfx] [PATCH] drm/i915: Promote .format_mod_supported() to the lead role

From: Ville Syrjälä Up to now we've used the plane's modifier list as the primary source of information for which modifiers are supported by a given plane. In order to allow auxiliary metadata to be embedded within the bits of the modifier we need to stop doing

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add Exec param to control data port coherency.

== Series Details == Series: drm/i915: Add Exec param to control data port coherency. URL : https://patchwork.freedesktop.org/series/40181/ State : failure == Summary == Possible new issues: Test gem_exec_params: Subgroup invalid-flag: pass -> FAIL

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Add control flags to i915_handle_error()

On 16/03/18 14:50, Chris Wilson wrote: Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. Signed-off-by: Chris

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Some plane init cleanups (rev2)

== Series Details == Series: drm/i915: Some plane init cleanups (rev2) URL : https://patchwork.freedesktop.org/series/39390/ State : failure == Summary == Series 39390v2 drm/i915: Some plane init cleanups https://patchwork.freedesktop.org/api/1.0/series/39390/revisions/2/mbox/ Possible

Re: [Intel-gfx] [PATCH igt 0/8] Non-Intel test suite fixes

On Fri, Mar 16, 2018 at 9:55 AM, Daniel Vetter wrote: > On Thu, Mar 15, 2018 at 03:45:36PM +0100, Ulrich Hecht wrote: >> Hi! >> >> I have run the tests on a Renesas R-Car M3-W's DU device, and have found a >> number of false negatives that mostly stem from use of Intel-specifics

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Trim error mask to known engines

On 19/03/18 06:12, Chris Wilson wrote: Quoting Chris Wilson (2018-03-16 21:49:59) For the convenience of userspace passing in an arbitrary reset mask, remove unknown engines from the set of engines that are to be reset. This means that we always follow a per-engine reset with a full-device

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915/guc: Unify naming of private GuC action functions

== Series Details == Series: series starting with [v2,1/3] drm/i915/guc: Unify naming of private GuC action functions URL : https://patchwork.freedesktop.org/series/40190/ State : success == Summary == Series 40190v1 series starting with [v2,1/3] drm/i915/guc: Unify naming of private GuC

[Intel-gfx] [PATCH v3 2/3] drm/i915/guc: Drop union guc_log_control

Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) Function old new delta intel_guc_log_level_set

[Intel-gfx] [PATCH v3 3/3] drm/i915/guc: Move enable/disable msg functions to GuC header

While today we are modifying GuC enabled msg mask only in GuC log, this code should be defined as generic GuC to allow future code reuse. Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski Cc: Sagar Arun Kamble

[Intel-gfx] [PATCH v3 1/3] drm/i915/guc: Unify naming of private GuC action functions

We should avoid using guc_log prefix for functions that don't operate on GuC log, but rather request action from the GuC. Better to use guc_action prefix. v2: rebase + naming compromise Signed-off-by: Michal Wajdeczko Cc: Michal Winiarski

Re: [Intel-gfx] [PATCH] drm/i915: Split GPU commands definitions into separate header

On Tue, 13 Mar 2018, Chris Wilson wrote: > Quoting Michal Wajdeczko (2018-03-13 11:21:21) >> We should not mix MMIO with MI_INSTR definitions. >> >> Suggested-by: Chris Wilson >> Signed-off-by: Michal Wajdeczko >>

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

On 2018-03-19 14:53, Joonas Lahtinen wrote: + Dave, as FYI Quoting Tomasz Lis (2018-03-19 14:37:34) The OpenCL driver develpers requested a functionality to control cache coherency at data port level. Keeping the coherency at that level is disabled by default due to its performance costs.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

== Series Details == Series: drm/i915/gvt: fix spelling mistake: "registeration" -> "registration" URL : https://patchwork.freedesktop.org/series/40185/ State : success == Summary == Series 40185v1 drm/i915/gvt: fix spelling mistake: "registeration" -> "registration"

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Drop union guc_log_control

On Mon, 19 Mar 2018 16:32:05 +0100, Michał Winiarski wrote: On Mon, Mar 19, 2018 at 01:49:23PM +, Michal Wajdeczko wrote: Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus:

[Intel-gfx] [PATCH] drm: Restore planes after load detection

From: Ville Syrjälä Actually turn the planes back on after were done with the load detection. Fixes: 20bdc112bbe4 ("drm/i915: Disable all planes for load detection, v2.") Cc: Maarten Lankhorst Cc: Daniel Vetter

Re: [Intel-gfx] [PATCH i-g-t v7] tests/perf_pmu: Improve accuracy by waiting on spinner to start

Quoting Chris Wilson (2018-03-19 15:29:21) > Quoting Tvrtko Ursulin (2018-03-19 13:56:05) > > @@ -443,15 +501,12 @@ most_busy_check_all(int gem_fd, const struct > > intel_execution_engine2 *e, > > if (!gem_has_engine(gem_fd, e_->class, e_->instance)) > >

  1   2   >