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

Hi Dave, Here goes drm-intel-fixes-2018-03-21: One fix for DP MST and one fix for GPU reset on hang check. Thanks, Rodrigo. The following changes since commit c698ca5278934c0ae32297a8725ced2e27585d7f: Linux 4.16-rc6 (2018-03-18 17:48:42 -0700) are available in the git repository at:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm: Fix uabi regression by allowing garbage mode->type from userspace

== Series Details == Series: drm: Fix uabi regression by allowing garbage mode->type from userspace URL : https://patchwork.freedesktop.org/series/40416/ State : success == Summary == Known issues: Test kms_flip: Subgroup flip-vs-wf_vblank-interruptible: fail

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide URL : https://patchwork.freedesktop.org/series/40410/ State : warning == Summary == Possible new issues: Test kms_atomic_transition: Subgroup

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

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/gvt/scheduler.c between commit: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx") from Linus' tree and commit: b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted

== Series Details == Series: series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted URL : https://patchwork.freedesktop.org/series/40406/ State : warning == Summary == Possible new issues: Test gem_eio: Subgroup execbuf: pass

Re: [Intel-gfx] [PATCH] drm/i915: Allow control of PSR at runtime through debugfs.

On Thu, 2018-03-15 at 11:28 +0100, Maarten Lankhorst wrote: > Currently tests modify i915.enable_psr and then do a modeset cycle > to change PSR. We can write a value to i915_edp_psr_status to force > a certain value without a modeset. > > To retain compatibility with older userspace, we also

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use full serialisation around engine->irq_posted

== Series Details == Series: drm/i915: Use full serialisation around engine->irq_posted URL : https://patchwork.freedesktop.org/series/40403/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: incomplete -> PASS

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gvt: don't dereference 'workload' before null checking it

== Series Details == Series: drm/i915/gvt: don't dereference 'workload' before null checking it URL : https://patchwork.freedesktop.org/series/40401/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: incomplete ->

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Stress resets-vs-request-priority

== Series Details == Series: drm/i915/selftests: Stress resets-vs-request-priority URL : https://patchwork.freedesktop.org/series/40397/ State : failure == Summary == Possible new issues: Test drv_selftest: Subgroup live_hangcheck: pass -> DMESG-FAIL

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

On Wed, 2018-03-21 at 21:29 +0200, Ville Syrjälä wrote: > On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote: > > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote: > > > > From:

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

On Wed, 2018-03-21 at 21:48 +0200, Ville Syrjälä wrote: > On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote: > > Timestamps are useful for IGT tests that trigger PSR exit and/or wait for > > PSR entry. > > > > Cc: Ville Syrjälä > > Cc: Rodrigo

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

On Wed, 2018-03-21 at 21:45 +0200, Ville Syrjälä wrote: > On Tue, Mar 20, 2018 at 03:41:50PM -0700, Dhinakaran Pandiyan wrote: > > 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

[Intel-gfx] ✓ Fi.CI.BAT: success for cgroup private data and DRM/i915 integration (rev3)

== Series Details == Series: cgroup private data and DRM/i915 integration (rev3) URL : https://patchwork.freedesktop.org/series/40142/ State : success == Summary == Series 40142v3 cgroup private data and DRM/i915 integration

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for cgroup private data and DRM/i915 integration (rev3)

== Series Details == Series: cgroup private data and DRM/i915 integration (rev3) URL : https://patchwork.freedesktop.org/series/40142/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8c23fa59eef7 cgroup: Allow registration and lookup of cgroup private data (v3) 95f12a7ecd5d

[Intel-gfx] [PATCH v4.5 8/8] drm/i915: Add context priority & priority offset to debugfs (v2)

Update i915_context_status to include priority information. v2: - Clarify that the offset is based on cgroup (Chris) Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_debugfs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[Intel-gfx] [PATCH v4.5 4/8] drm/i915: Adjust internal priority definitions (v2)

In preparation for adding cgroup-based priority adjustments, let's define the driver's priority values a little more clearly. v2: - checkpatch warning fix (Intel CI) Cc: Chris Wilson Signed-off-by: Matt Roper ---

[Intel-gfx] [PATCH v4.5 7/8] drm/i915: Introduce per-cgroup display boost setting

Usually display-boosted contexts get treated as I915_CONTEXT_MAX_USER_PRIORITY+1, which prioritizes them above regular GPU contexts. Now that we allow a much larger range of effective priority values via per-cgroup priority offsets, a system administrator may want more detailed control over how

[Intel-gfx] [PATCH v4.5 1/8] cgroup: Allow registration and lookup of cgroup private data (v3)

There are cases where other parts of the kernel may wish to store data associated with individual cgroups without building a full cgroup controller. Let's add interfaces to allow them to register and lookup this private data for individual cgroups. A kernel system (e.g., a driver) that wishes to

[Intel-gfx] [PATCH v4.5 6/8] drm/i915: Introduce 'priority offset' for GPU contexts (v4)

There are cases where a system integrator may wish to raise/lower the priority of GPU workloads being submitted by specific OS process(es), independently of how the software self-classifies its own priority. Exposing "priority offset" as an i915-specific cgroup parameter will enable such

[Intel-gfx] [PATCH v4.5 5/8] drm/i915: cgroup integration (v4)

Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow userspace to set i915-specific parameters for individual cgroups. i915 cgroup data will be registered and later looked up via the new cgroup_priv infrastructure. v2: - Large rebase/rewrite for new cgroup_priv interface v3: -

[Intel-gfx] [PATCH v4.5 3/8] cgroup: Introduce cgroup_priv_get_current

Getting cgroup private data for the current process' cgroup is such a common pattern that we should add a convenience wrapper for it. Signed-off-by: Matt Roper --- include/linux/cgroup.h | 1 + kernel/cgroup/cgroup.c | 23 +++ 2 files changed, 24

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

This version of the patch series just contains some minor updates to address checkpatch and sparse warnings. There are no serious design or implementation changes since v4. You can find the previous versions of this series (and more detailed cover letters) here: (v1)

[Intel-gfx] [PATCH v4.5 2/8] cgroup: Introduce task_get_dfl_cgroup() (v2)

Wraps task_dfl_cgroup() to also take a reference to the cgroup. v2: - Eliminate cgroup_mutex and make lighter-weight (Tejun) Cc: Tejun Heo Cc: cgro...@vger.kernel.org Signed-off-by: Matt Roper --- include/linux/cgroup.h | 29

Re: [Intel-gfx] [PATCH v3] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams

Thanks Sagar and Joonas! I probably need reconfigure my email client. I will add these docs to i915.rst. Since we've already had a GuC chapter defined in i915.rst, so I will include these doc like: WOPCM         WOPCM Layout doc GuC             GuC Address Space doc Please let me

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix uabi regression by allowing garbage mode->type from userspace

== Series Details == Series: drm: Fix uabi regression by allowing garbage mode->type from userspace URL : https://patchwork.freedesktop.org/series/40416/ State : success == Summary == Series 40416v1 drm: Fix uabi regression by allowing garbage mode->type from userspace

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: Fix uabi regression by allowing garbage mode->type from userspace

== Series Details == Series: drm: Fix uabi regression by allowing garbage mode->type from userspace URL : https://patchwork.freedesktop.org/series/40416/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1ace93ec3e0c drm: Fix uabi regression by allowing garbage mode->type from

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide URL : https://patchwork.freedesktop.org/series/40410/ State : success == Summary == Series 40410v1 series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide

Re: [Intel-gfx] [PATCH 01/17] drm/i915/icl: add definitions for the ICL PLL registers

Em Ter, 2018-02-27 às 14:22 -0800, James Ausmus escreveu: > On Thu, Feb 22, 2018 at 12:55:03AM -0300, Paulo Zanoni wrote: > > There's a lot of code for the PLL enabling, so let's first only > > introduce the register definitions in order to make patch reviewing > > a > > little easier. > > > >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Include the trace as a debug aide URL : https://patchwork.freedesktop.org/series/40410/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5775fcc92769 drm/i915/selftests: Include the trace as a debug aide

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Flush pending interrupt following a GPU reset

== Series Details == Series: drm/i915: Flush pending interrupt following a GPU reset URL : https://patchwork.freedesktop.org/series/40383/ State : success == Summary == Known issues: Test kms_cursor_crc: Subgroup cursor-64x64-suspend: incomplete -> PASS

[Intel-gfx] [PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace

From: Ville Syrjälä Apparently xf86-video-vmware leaves the mode->type uninitialized when feeding the mode to the kernel. Thus we have no choice but to accept the garbage in. We'll just ignore any of the bits we don't want. The mode type is just a hint anyway, and

Re: [Intel-gfx] drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type

On 03/21/2018 09:51 PM, Ville Syrjälä wrote: On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote: Hi, Ville, On 11/14/2017 07:32 PM, Ville Syrjala wrote: From: Ville Syrjälä Currently userspace is allowed to feed in any king of garbage in the high

[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Stress resets-vs-request-priority

Watch what happens if we try to reset with a queue of requests with varying priorities -- that may need reordering or preemption across the reset. v2: Tweak priorities to avoid starving the hanging thread. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Include the trace as a debug aide

If we fail to reset the GPU in a timely fashion, dump the GEM trace so that we can see what operations were in flight when the GPU got stuck. v2: There's more than one timeout that deserves tracing! Signed-off-by: Chris Wilson ---

[Intel-gfx] drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type

Hi, Ville, On 11/14/2017 07:32 PM, Ville Syrjala wrote: From: Ville Syrjälä Currently userspace is allowed to feed in any king of garbage in the high bits of the mode flags/type, as are drivers when probing modes. Reject any mode with bogus flags/type.

Re: [Intel-gfx] drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type

On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote: > Hi, Ville, > > On 11/14/2017 07:32 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Currently userspace is allowed to feed in any king of garbage in the > > high bits of the mode

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted

== Series Details == Series: series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted URL : https://patchwork.freedesktop.org/series/40406/ State : success == Summary == Series 40406v1 series starting with [1/2] drm/i915: Use full serialisation around

Re: [Intel-gfx] [PATCH 2/2] drm/i915/psr: Remove open-coded PSR AUX transactions for SKL+

On Tue, Mar 13, 2018 at 08:46:56PM +, Souza, Jose wrote: > On Mon, 2018-03-12 at 20:46 -0700, Dhinakaran Pandiyan wrote: > > HSW and BDW have SRD_AUX_{CTL, STATUS} registers that the driver > > needs to > > setup for the HW to use whenever exiting PSR. SKL+ hardware use > > hardcoded > >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted

== Series Details == Series: series starting with [1/2] drm/i915: Use full serialisation around engine->irq_posted URL : https://patchwork.freedesktop.org/series/40406/ State : warning == Summary == $ dim checkpatch origin/drm-tip ffea28ec97fb drm/i915: Use full serialisation around

Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Move PSR aux setup to it's own function.

On Mon, Mar 12, 2018 at 08:46:45PM -0700, Dhinakaran Pandiyan wrote: > Non-functional change useful for the following patch. > > Cc: Rodrigo Vivi > Cc: José Roberto de Souza > Signed-off-by: Dhinakaran Pandiyan

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use full serialisation around engine->irq_posted

== Series Details == Series: drm/i915: Use full serialisation around engine->irq_posted URL : https://patchwork.freedesktop.org/series/40403/ State : success == Summary == Series 40403v1 drm/i915: Use full serialisation around engine->irq_posted

[Intel-gfx] [PATCH 1/2] drm/i915: Use full serialisation around engine->irq_posted

Using engine->irq_posted for execlists, we are not always serialised by the tasklet as we supposed. On the reset paths, the tasklet is disabled and ignored. Instead, we manipulate the engine->irq_posted directly to account for the reset, but if an interrupt fired before the reset and so wrote to

[Intel-gfx] [PATCH 2/2] drm/i915: Flush pending interrupt following a GPU reset

After resetting the GPU (or subset of engines), call synchronize_irq() to flush any pending irq before proceeding with the cleanup. For a device level reset, we disable the interupts around the reset, but when resetting just one engine, we have to avoid such global disabling. This leaves us open

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: don't dereference 'workload' before null checking it

== Series Details == Series: drm/i915/gvt: don't dereference 'workload' before null checking it URL : https://patchwork.freedesktop.org/series/40401/ State : success == Summary == Series 40401v1 drm/i915/gvt: don't dereference 'workload' before null checking it

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

On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote: > Timestamps are useful for IGT tests that trigger PSR exit and/or wait for > PSR entry. > > Cc: Ville Syrjälä > Cc: Rodrigo Vivi > Cc: Daniel Vetter

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

On Tue, Mar 20, 2018 at 03:41:50PM -0700, Dhinakaran Pandiyan wrote: > 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 > > Cc: Rodrigo

Re: [Intel-gfx] [RFC v1] drm/i915: Add Exec param to control data port coherency.

On 3/21/2018 3:16 AM, Chris Wilson wrote: Quoting Oscar Mateo (2018-03-20 18:43:45) On 3/19/2018 7:14 AM, Lis, Tomasz wrote: On 2018-03-19 13:43, Chris Wilson wrote: Quoting Tomasz Lis (2018-03-19 12:37:35) The patch adds a parameter to control the data port coherency functionality on a

Re: [Intel-gfx] [PATCH] drm/i915: Rework FBC schedule locking

Em Sex, 2018-03-16 às 16:01 +0100, Maarten Lankhorst escreveu: > Instead of taking fbc->lock inside the worker, don't take any lock > and cancel the work synchronously to prevent races. Since the worker > waits for a vblank before activating, wake up all vblank waiters > after > signalling the

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

On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote: > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote: > > > From: Daniel Vetter > > > > > > The definitions for the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Stress resets-vs-request-priority

== Series Details == Series: drm/i915/selftests: Stress resets-vs-request-priority URL : https://patchwork.freedesktop.org/series/40397/ State : success == Summary == Series 40397v1 drm/i915/selftests: Stress resets-vs-request-priority

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

On 21/03/18 19:23, Chris Wilson wrote: > Quoting Colin Ian King (2018-03-21 19:18:28) >> On 21/03/18 19:09, Joe Perches wrote: >>> On Wed, 2018-03-21 at 19:06 +, Colin King wrote: From: Colin Ian King The pointer workload is dereferenced before it is

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

On Wed, 2018-03-21 at 19:18 +, Colin Ian King wrote: > On 21/03/18 19:09, Joe Perches wrote: > > On Wed, 2018-03-21 at 19:06 +, Colin King wrote: > > > From: Colin Ian King > > > > > > The pointer workload is dereferenced before it is null checked, hence > > >

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

Quoting Colin Ian King (2018-03-21 19:18:28) > On 21/03/18 19:09, Joe Perches wrote: > > On Wed, 2018-03-21 at 19:06 +, Colin King wrote: > >> From: Colin Ian King > >> > >> The pointer workload is dereferenced before it is null checked, hence > >> there is a

Re: [Intel-gfx] [PATCH 1/7] drm/i915: move dpll_info to header

On Wed, Mar 21, 2018 at 12:25:40PM +0200, Ville Syrjälä wrote: > > > This structure seems to be poorly organized for 64bit machines. > > > > > > Yes, there's a 4-bytes right there. Fixing this unfortunately > > involves changing > > all tables inside dpll_mgr.c. > > Those aren't using named

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

On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote: > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote: > > From: Daniel Vetter > > > > The definitions for the error register should be valid on bdw/skl too, > > but there we haven't even enabled

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

On 21/03/18 19:09, Joe Perches wrote: > On Wed, 2018-03-21 at 19:06 +, Colin King wrote: >> From: Colin Ian King >> >> The pointer workload is dereferenced before it is null checked, hence >> there is a potential for a null pointer dereference on workload. Fix >>

[Intel-gfx] [PATCH] drm/i915: Use full serialisation around engine->irq_posted

Using engine->irq_posted for execlists, we are not always serialised by the tasklet as we supposed. On the reset paths, the tasklet is disabled and ignored. Instead, we manipulate the engine->irq_posted directly to account for the reset, but if an interrupt fired before the reset and so wrote to

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Stress resets-vs-request-priority

== Series Details == Series: drm/i915/selftests: Stress resets-vs-request-priority URL : https://patchwork.freedesktop.org/series/40397/ State : warning == Summary == $ dim checkpatch origin/drm-tip db8550b31cc9 drm/i915/selftests: Stress resets-vs-request-priority -:272: CHECK:SPACING:

Re: [Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

On Wed, 2018-03-21 at 19:06 +, Colin King wrote: > From: Colin Ian King > > The pointer workload is dereferenced before it is null checked, hence > there is a potential for a null pointer dereference on workload. Fix > this by only dereferencing workload after it is

[Intel-gfx] [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it

From: Colin Ian King The pointer workload is dereferenced before it is null checked, hence there is a potential for a null pointer dereference on workload. Fix this by only dereferencing workload after it is null checked. Detected by CoverityScan, CID#1466017

Re: [Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

Quoting Chris Wilson (2018-03-21 18:12:51) > Quoting Jeff McGee (2018-03-21 17:31:45) > > On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote: > > > From: Jeff McGee > > > > > > Engine reset is fast. A context switch interrupt may be generated just > > >

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

Quoting Jeff McGee (2018-03-21 18:29:46) > On Wed, Mar 21, 2018 at 06:06:44PM +, Chris Wilson wrote: > > Quoting Jeff McGee (2018-03-21 17:33:04) > > > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote: > > > > From: Jeff McGee > > > > > > > >

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

On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote: > 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

[Intel-gfx] [PATCH] drm/i915/selftests: Stress resets-vs-request-priority

Watch what happens if we try to reset with a queue of requests with varying priorities -- that may need reordering or preemption across the reset. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 154 +++ 1 file

[Intel-gfx] ✗ Fi.CI.BAT: failure for Force preemption (rev2)

== Series Details == Series: Force preemption (rev2) URL : https://patchwork.freedesktop.org/series/40120/ State : failure == Summary == Applying: drm/i915/execlists: Refactor out complete_preempt_context() Applying: drm/i915: Add control flags to i915_handle_error() error: Failed to merge in

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

On Wed, Mar 21, 2018 at 06:06:44PM +, Chris Wilson wrote: > Quoting Jeff McGee (2018-03-21 17:33:04) > > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote: > > > From: Jeff McGee > > > > > > Signed-off-by: Jeff McGee > > > --- >

[Intel-gfx] ✓ Fi.CI.IGT: success for lib/gpgpu_fill: Adding missing configuration parameters for gpgpu_fill function

== Series Details == Series: lib/gpgpu_fill: Adding missing configuration parameters for gpgpu_fill function URL : https://patchwork.freedesktop.org/series/40378/ State : success == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup

Re: [Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

Quoting Jeff McGee (2018-03-21 17:31:45) > On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote: > > From: Jeff McGee > > > > Engine reset is fast. A context switch interrupt may be generated just > > prior to the reset such that the top half handler is

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

Quoting Jeff McGee (2018-03-21 17:33:04) > On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote: > > From: Jeff McGee > > > > Signed-off-by: Jeff McGee > > --- > > drivers/gpu/drm/i915/intel_lrc.c | 2 +- > > 1 file changed, 1

Re: [Intel-gfx] [PATCH] drm/i915: Rework FBC schedule locking

On Fri, Mar 16, 2018 at 04:01:21PM +0100, Maarten Lankhorst wrote: > Instead of taking fbc->lock inside the worker, don't take any lock > and cancel the work synchronously to prevent races. Since the worker > waits for a vblank before activating, wake up all vblank waiters after > signalling the

Re: [Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

On Wed, Mar 21, 2018 at 10:26:23AM -0700, jeff.mc...@intel.com wrote: > From: Jeff McGee > > Signed-off-by: Jeff McGee > --- > drivers/gpu/drm/i915/intel_lrc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

On Wed, Mar 21, 2018 at 10:26:24AM -0700, jeff.mc...@intel.com wrote: > From: Jeff McGee > > Engine reset is fast. A context switch interrupt may be generated just > prior to the reset such that the top half handler is racing with reset > post-processing. The handler may

[Intel-gfx] [RFC 4/8] drm/i915: Split execlists/guc reset prepartions

From: Chris Wilson 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.

[Intel-gfx] [RFC 0/8] Force preemption

From: Jeff McGee Force preemption uses engine reset to enforce a limit on the time that a request targeted for preemption can block. This feature is a requirement in automotive systems where the GPU may be shared by clients of critically high priority and clients of low

[Intel-gfx] [RFC 8/8] drm/i915: Force preemption to complete via engine reset

From: Jeff McGee The hardware can complete the requested preemption at only certain points in execution. Thus an uncooperative request that avoids those points can block a preemption indefinitely. Our only option to bound the preemption latency is to trigger reset and

[Intel-gfx] [RFC 2/8] drm/i915: Add control flags to i915_handle_error()

From: Chris Wilson 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

[Intel-gfx] [RFC 1/8] drm/i915/execlists: Refactor out complete_preempt_context()

From: Chris Wilson 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

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

From: Chris Wilson 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

[Intel-gfx] [RFC 7/8] drm/i915: Skip CSB processing on invalid CSB tail

From: Jeff McGee Engine reset is fast. A context switch interrupt may be generated just prior to the reset such that the top half handler is racing with reset post-processing. The handler may set the irq_posted bit again after the reset code has cleared it to start fresh.

[Intel-gfx] [RFC 6/8] drm/i915: Fix loop on CSB processing

From: Jeff McGee Signed-off-by: Jeff McGee --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index beb81f13a3cc..cec4e1653daf

[Intel-gfx] [RFC 3/8] drm/i915: Move engine reset prepare/finish to backends

From: Chris Wilson 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ł

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Include the trace as a debug aide (rev2)

== Series Details == Series: drm/i915/selftests: Include the trace as a debug aide (rev2) URL : https://patchwork.freedesktop.org/series/40362/ State : success == Summary == Known issues: Test kms_flip: Subgroup flip-vs-absolute-wf_vblank: pass -> FAIL

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

On Wed, Mar 21, 2018 at 04:42:32PM +, Chris Wilson wrote: > Quoting Jeff McGee (2018-03-21 15:55:16) > > On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote: > > > After resetting the GPU (or subset of engines), call synchronize_irq() > > > to flush any pending irq before proceeding

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush pending interrupt following a GPU reset

== Series Details == Series: drm/i915: Flush pending interrupt following a GPU reset URL : https://patchwork.freedesktop.org/series/40383/ State : success == Summary == Series 40383v1 drm/i915: Flush pending interrupt following a GPU reset

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

Quoting Michel Thierry (2018-03-21 17:01:12) > On 3/21/2018 3:46 AM, Mika Kuoppala wrote: > > Chris Wilson writes: > > > >> We were relying on the uncached reads when processing the CSB to provide > >> ourselves with the serialisation with the interrupt handler (so we

Re: [Intel-gfx] [RFC PATCH i-g-t 0/3] Test the plane formats on the Chamelium

Maxime Ripard writes: > [ Unknown signature status ] > Hi, > > On Mon, Mar 05, 2018 at 03:21:26PM +0100, Maxime Ripard wrote: >> Here is an RFC at starting to test the plane formats using the >> Chamelium over the HDMI. This was tested using the vc4 DRM driver >> found

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

Quoting Chris Wilson (2018-03-21 17:05:06) > Quoting Michel Thierry (2018-03-21 17:01:12) > > On 3/21/2018 3:46 AM, Mika Kuoppala wrote: > > > Chris Wilson writes: > > > > > >> We were relying on the uncached reads when processing the CSB to provide > > >> ourselves

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

Quoting Michel Thierry (2018-03-21 17:01:12) > On 3/21/2018 3:46 AM, Mika Kuoppala wrote: > > Chris Wilson writes: > > > >> We were relying on the uncached reads when processing the CSB to provide > >> ourselves with the serialisation with the interrupt handler (so we

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Use a locked clear_bit() for synchronisation with interrupt

On 3/21/2018 3:46 AM, Mika Kuoppala wrote: Chris Wilson writes: We were relying on the uncached reads when processing the CSB to provide ourselves with the serialisation with the interrupt handler (so we could detect new interrupts in the middle of processing the old

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Flush pending interrupt following a GPU reset

== Series Details == Series: drm/i915: Flush pending interrupt following a GPU reset URL : https://patchwork.freedesktop.org/series/40383/ State : warning == Summary == $ dim checkpatch origin/drm-tip c3bbd56f3b68 drm/i915: Flush pending interrupt following a GPU reset -:23:

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

Quoting Jeff McGee (2018-03-21 15:55:16) > On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote: > > After resetting the GPU (or subset of engines), call synchronize_irq() > > to flush any pending irq before proceeding with the cleanup. For a > > device level reset, we disable the

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

Quoting Jeff McGee (2018-03-21 15:55:16) > On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote: > > After resetting the GPU (or subset of engines), call synchronize_irq() > > to flush any pending irq before proceeding with the cleanup. For a > > device level reset, we disable the

Re: [Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

On Wed, Mar 21, 2018 at 03:00:23PM +, Chris Wilson wrote: > After resetting the GPU (or subset of engines), call synchronize_irq() > to flush any pending irq before proceeding with the cleanup. For a > device level reset, we disable the interupts around the reset, but when > resetting just one

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

Quoting Zhenyu Wang (2018-03-20 04:41:08) > > 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. Pulled, thanks. Regards, Joonas ___ Intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Handle GuC log flush event in dedicated function

Quoting Michał Winiarski (2018-03-20 18:56:59) > On Mon, Mar 19, 2018 at 12:50:49PM +, Michal Wajdeczko wrote: > > We already try to keep all GuC log related code in separate file, > > handling flush event should be placed there too. This will also > > allow future code reuse. > > > > v2:

Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Unify parameters of public CT functions

Quoting Michal Wajdeczko (2018-03-20 16:20:20) > There is no need to mix parameter types in public CT functions > as we can always accept intel_guc_ct. > > v2: fix 'Return' doc, s/dev_priv/i915 (Sagar) > > Signed-off-by: Michal Wajdeczko > Cc: Sagar Arun Kamble

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

Quoting Patchwork (2018-03-20 19:04:24) > == Series Details == > > Series: series starting with [CI,1/3] drm/i915/guc: Unify naming of private > GuC action functions > URL : https://patchwork.freedesktop.org/series/40311/ > State : success > > == Summary == > > Series 40311v1 series starting

Re: [Intel-gfx] [PATCH] drm/i915/huc: Check HuC status in dedicated function

Quoting Michel Thierry (2018-03-14 23:34:33) > On 14/03/18 15:23, Michal Wajdeczko wrote: > > On Wed, 14 Mar 2018 21:17:29 +0100, Michel Thierry > > wrote: > > > >> On 14/03/18 13:04, Michal Wajdeczko wrote: > >>> We try to keep all HuC related code in dedicated file.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/i915: prefer INTEL_GEN() over INTEL_INFO()->gen

On Wed, 21 Mar 2018, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,1/2] drm/i915: prefer INTEL_GEN() over > INTEL_INFO()->gen > URL : https://patchwork.freedesktop.org/series/40380/ > State : failure > > == Summary == > > CHK

[Intel-gfx] [PATCH] drm/i915: Flush pending interrupt following a GPU reset

After resetting the GPU (or subset of engines), call synchronize_irq() to flush any pending irq before proceeding with the cleanup. For a device level reset, we disable the interupts around the reset, but when resetting just one engine, we have to avoid such global disabling. This leaves us open

  1   2   >