[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Do not overwrite the request with zero on reallocation (rev3)

== Series Details == Series: drm/i915: Do not overwrite the request with zero on reallocation (rev3) URL : https://patchwork.freedesktop.org/series/10719/ State : failure == Summary == Series 10719v3 drm/i915: Do not overwrite the request with zero on reallocation

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Update comment before i915_spin_request

== Series Details == Series: drm/i915: Update comment before i915_spin_request URL : https://patchwork.freedesktop.org/series/10722/ State : failure == Summary == Applying: drm/i915: Update comment before i915_spin_request Using index info to reconstruct a base tree... M

[Intel-gfx] [PATCH v8 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state

If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org

[Intel-gfx] [PATCH v8 1/6] drm/i915/skl: Add support for the SAGV, fix underrun hangs

Since the watermark calculations for Skylake are still broken, we're apt to hitting underruns very easily under multi-monitor configurations. While it would be lovely if this was fixed, it's not. Another problem that's been coming from this however, is the mysterious issue of underruns causing

[Intel-gfx] [PATCH v8 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates

Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are

[Intel-gfx] [PATCH v8 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

From: Matt Roper When we write watermark values to the hardware, those values are stored in dev_priv->wm.skl_hw. However with recent watermark changes, the results structure we're copying from only contains valid watermark and DDB values for the pipes that are

[Intel-gfx] [PATCH v8 0/6] Finally fix watermarks

Latest version of https://patchwork.freedesktop.org/series/10276/ All patches are being resent to keep them in one place. Most of the changes are very minor, with the exception of patch 6. The patches that actually changed: - drm/i915/skl: Add support for the SAGV, fix underrun hangs -

[Intel-gfx] [PATCH v8 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook

Since we have to write ddb allocations at the same time as we do other plane updates, we're going to need to be able to control the order in which we execute modesets on each pipe. The easiest way to do this is to just factor this section of intel_atomic_commit_tail() (intel_atomic_commit() for

[Intel-gfx] [PATCH v8 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs

Now that we can hook into update_crtcs and control the order in which we update CRTCs at each modeset, we can finish the final step of fixing Skylake's watermark handling by performing DDB updates at the same time as plane updates and watermark updates. The first major change in this patch is

Re: [Intel-gfx] [isg-gms] [PATCH] drm/i915/bxt: Bring MIPI out of reset

On Fri, 5 Aug 2016 15:23:23 -0700 "Xiong, James" wrote: > Reviewed-by James Xiong Merged to gold. Thanks for the review. Bob > > -Original Message- > From: isg-gms-requ...@eclists.intel.com > [mailto:isg-gms-requ...@eclists.intel.com]

Re: [Intel-gfx] [PATCH] drm/i915: Shut down displays gracefully on reboot

On 08/03/2016 06:36 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Dell UP2414Q doesn't like it when we're driving it in MST mode, and then reboot the machine. After reboot, the monitor is somehow confused and refuses to do the payload allocation:

Re: [Intel-gfx] [isg-gms] [PATCH] drm/i915/bxt: Bring MIPI out of reset

Reviewed-by James Xiong -Original Message- From: isg-gms-requ...@eclists.intel.com [mailto:isg-gms-requ...@eclists.intel.com] On Behalf Of Paauwe, Bob J Sent: Thursday, August 4, 2016 11:16 AM To: isg-gms ; intel-gfx

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Check PSR setup time vs. vblank length

This patch is blocking PSR on panels that we know that our hardware support. I wonder if: 1. This restrictions was for older platforms and spec is out dated 2. Or Spec is not documenting the restriction properly 3. Or we have some issue with out setup time calculation. On Tue, May 31, 2016 at

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Fix the return value of pipe crc read function.

On Wed, 2016-08-03 at 14:44 +, Vivi, Rodrigo wrote: > On Wed, 2016-08-03 at 10:31 +0300, Ville Syrjälä wrote: > > On Tue, Aug 02, 2016 at 09:42:07PM -0700, Rodrigo Vivi wrote: > > > > > > A read(fd, buf, len) function should return the number > > > of bytes read. In our case we need to return

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Sanitize drm crtc vblank counter after DC reset frame count.

On Thu, Aug 4, 2016 at 1:26 AM, Daniel Vetter wrote: > On Wed, Aug 03, 2016 at 02:33:39PM -0700, Rodrigo Vivi wrote: >> DC state reset the frame counter that is a read-only register. >> >> So, besides blocking DC state on vblank let's restore the >> drm crtc vblank counter to a

[Intel-gfx] [PATCH 2/2] drm/i915: Do not overwrite the request with zero on reallocation

When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915: Enable lockless lookup of request tracking via RCU"), we acknowledge that we may race with another thread that could have reallocated the request. In order for the first thread not to blow up, the second thread must not clear

[Intel-gfx] [PATCH 1/2] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

In the debate as to whether the second read of active->request is ordered after the dependent reads of the first read of active->request, just give in and throw a smp_rmb() in there so that ordering of loads is assured. v2: Explain the manual smp_rmb() Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Use RCU to annotate and enforce protection for breadcrumb's bh

The bottom-half we use for processing the breadcrumb interrupt is a task, which is an RCU protected struct. When accessing this struct, we need to be holding the RCU read lock to prevent it disappearing beneath us. We can use the RCU annotation to mark our irq_seqno_bh pointer as being under RCU

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Use the g4x+ approach on gen2 for handling display stuff around GPU reset

On Fri, Aug 05, 2016 at 11:28:30PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We don't have GPU reset support for gen2, which means the display > hardware is unaffected when a GPU hang is handled. However as the ring > has in fact

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Introduce gpu_reset_clobbers_display()

On Fri, Aug 05, 2016 at 11:28:29PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Factor out the "does the GPU reset clobber the display?" check into a > small helper. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915: fix aliasing_ppgtt leak

On Fri, Aug 05, 2016 at 07:18:13PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 07:04:40PM +0100, Matthew Auld wrote: > > In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This > > fixes the following kmemleak message: > > > > unreferenced object 0x880213cca000 (size

[Intel-gfx] [PATCH 4/4] drm/i915: Use the g4x+ approach on gen2 for handling display stuff around GPU reset

From: Ville Syrjälä We don't have GPU reset support for gen2, which means the display hardware is unaffected when a GPU hang is handled. However as the ring has in fact stopped, any flips still in the ring will never complete, and thus the display base address

[Intel-gfx] [PATCH 0/4] drm/i915: Maarten's pre-g4x GPU reset regression fix + other reset stuff

From: Ville Syrjälä I got annoyed at the pre-g4x gpu reset regression again, so I picked up the latest (I think it was the latest anyway) version of Maarten's locking fix from the list and rebased it. I also changed one comment in there about mode_config.mutex as

[Intel-gfx] [PATCH 3/4] drm/i915: Introduce gpu_reset_clobbers_display()

From: Ville Syrjälä Factor out the "does the GPU reset clobber the display?" check into a small helper. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 9 +++-- 1 file changed, 7 insertions(+), 2

Re: [Intel-gfx] [PATCH] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

On Fri, Aug 05, 2016 at 09:11:14PM +0100, Chris Wilson wrote: > In the debate as to whether the second read of active->request is > ordered after the dependent reads of the first read of active->request, > just give in and throw a smp_rmb() in there so that ordering of loads is > assured. > >

[Intel-gfx] [PATCH v5 1/4] drm/i915: Fix modeset handling during gpu reset, v5.

From: Maarten Lankhorst This function would call drm_modeset_lock_all, while the suspend/resume functions already have their own locking. Fix this by factoring out __intel_display_resume, and calling the atomic helpers for duplicating atomic state and disabling

[Intel-gfx] [PATCH v2 2/4] drm/i915: Add a way to test the modeset done during gpu reset, v3.

From: Maarten Lankhorst Add force_reset_modeset_test as a parameter to force the modeset path during gpu reset. This allows a IGT test to set the knob and trigger a hang to force the gpu reset, even on platforms that wouldn't otherwise require it. Changes

Re: [Intel-gfx] [PATCH] drm/i915: Don't mark PCH underrun reporting as diasabled for transcoder B/C on LPT-H

On Fri, Aug 05, 2016 at 08:00:17PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Marking PCH transcoder FIFO underrun reporting as disabled for > transcoder B/C on LPT-H will block us from enabling the south error > interrupt. So let's only

Re: [Intel-gfx] [CI 13/19] drm/i915: Remove (struct_mutex) locking for busy-ioctl

On Fri, Aug 05, 2016 at 08:30:42PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 09:08:34PM +0200, Daniel Vetter wrote: > > On Fri, Aug 05, 2016 at 10:14:18AM +0100, Chris Wilson wrote: > > > By applying the same logic as for wait-ioctl, we can query whether a > > > request has completed

[Intel-gfx] [PATCH] drm/i915: Add smp_rmb() to busy ioctl's RCU dance

In the debate as to whether the second read of active->request is ordered after the dependent reads of the first read of active->request, just give in and throw a smp_rmb() in there so that ordering of loads is assured. Signed-off-by: Chris Wilson Cc: Daniel Vetter

Re: [Intel-gfx] [PATCH 13/13] drm/i915: Compress GPU objects in error state

On Fri, Aug 05, 2016 at 08:15:42PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 08:56:57PM +0200, Daniel Vetter wrote: > > On Fri, Aug 05, 2016 at 10:06:04AM +0100, Chris Wilson wrote: > > > Our error states are quickly growing, pinning kernel memory with them. > > > The majority of the

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Stop the machine whilst capturing the GPU crash dump

On Fri, Aug 05, 2016 at 08:01:58PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 08:50:11PM +0200, Daniel Vetter wrote: > > On Fri, Aug 05, 2016 at 10:05:53AM +0100, Chris Wilson wrote: > > > The error state is purposefully racy as we expect it to be called at any > > > time and so have

Re: [Intel-gfx] [CI 13/19] drm/i915: Remove (struct_mutex) locking for busy-ioctl

On Fri, Aug 05, 2016 at 09:08:34PM +0200, Daniel Vetter wrote: > On Fri, Aug 05, 2016 at 10:14:18AM +0100, Chris Wilson wrote: > > By applying the same logic as for wait-ioctl, we can query whether a > > request has completed without holding struct_mutex. The biggest impact > > system-wide is

Re: [Intel-gfx] [PATCH] drm/i915: Prevent oops on req->engine in rcu-protected peeking

On Fri, Aug 05, 2016 at 06:38:13PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 06:37:00PM +0200, Daniel Vetter wrote: > > When only rcu-protected we might peek at a reinitializing request. > > Prevent carnage by making sure we don't accidentally chase a NULL > > pointer. > > > > The

Re: [Intel-gfx] [PATCH 13/13] drm/i915: Compress GPU objects in error state

On Fri, Aug 05, 2016 at 08:56:57PM +0200, Daniel Vetter wrote: > On Fri, Aug 05, 2016 at 10:06:04AM +0100, Chris Wilson wrote: > > Our error states are quickly growing, pinning kernel memory with them. > > The majority of the space is taken up by the error objects. These > > compress well using

Re: [Intel-gfx] [CI 15/19] drm/i915: Remove pinned check from madvise ioctl

On Fri, Aug 05, 2016 at 10:14:20AM +0100, Chris Wilson wrote: > We don't need to incur the overhead of checking whether the object is > pinned prior to changing its madvise. If the object is pinned, the > madvise will not take effect until it is unpinned and so we cannot free > the pages being

Re: [Intel-gfx] [CI 13/19] drm/i915: Remove (struct_mutex) locking for busy-ioctl

On Fri, Aug 05, 2016 at 10:14:18AM +0100, Chris Wilson wrote: > By applying the same logic as for wait-ioctl, we can query whether a > request has completed without holding struct_mutex. The biggest impact > system-wide is removing the flush_active and the contention that causes. > > Testcase:

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Stop the machine whilst capturing the GPU crash dump

On Fri, Aug 05, 2016 at 08:50:11PM +0200, Daniel Vetter wrote: > On Fri, Aug 05, 2016 at 10:05:53AM +0100, Chris Wilson wrote: > > The error state is purposefully racy as we expect it to be called at any > > time and so have avoided any locking whilst capturing the crash dump. > > However, with

Re: [Intel-gfx] [PATCH 13/13] drm/i915: Compress GPU objects in error state

On Fri, Aug 05, 2016 at 10:06:04AM +0100, Chris Wilson wrote: > Our error states are quickly growing, pinning kernel memory with them. > The majority of the space is taken up by the error objects. These > compress well using zlib and without decode are mostly meaningless, so > encoding them does

Re: [Intel-gfx] [PATCH 02/13] drm/i915: Stop the machine whilst capturing the GPU crash dump

On Fri, Aug 05, 2016 at 10:05:53AM +0100, Chris Wilson wrote: > The error state is purposefully racy as we expect it to be called at any > time and so have avoided any locking whilst capturing the crash dump. > However, with multi-engine GPUs and multiple CPUs, those races can > manifest into

Re: [Intel-gfx] [PATCH] drm/i915: fix aliasing_ppgtt leak

On Fri, Aug 05, 2016 at 07:04:40PM +0100, Matthew Auld wrote: > In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This > fixes the following kmemleak message: > > unreferenced object 0x880213cca000 (size 8192): > comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s)

[Intel-gfx] [PATCH] drm/i915/bxt: Bring MIPI out of reset (v2)

and power up the DSI regulator when initializing a MIPI display. v2: rebase on current drm-intel-nightly Signed-off-by: Bob Paauwe --- drivers/gpu/drm/i915/i915_reg.h | 8 drivers/gpu/drm/i915/intel_dsi.c | 15 +++ 2 files changed, 23 insertions(+)

[Intel-gfx] [PATCH] drm/i915: fix aliasing_ppgtt leak

In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This fixes the following kmemleak message: unreferenced object 0x880213cca000 (size 8192): comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00

Re: [Intel-gfx] [PATCH] drm/i915: Add some curly braces

On Fri, 2016-08-05 at 18:49 +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 08:41:34PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > intel_enable_pipe() looks rather confusing when one side doesn't have > > the curly braces, and

Re: [Intel-gfx] [PATCH] drm/i915: Add some curly braces

On Fri, Aug 05, 2016 at 08:41:34PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > intel_enable_pipe() looks rather confusing when one side doesn't have > the curly braces, and the other one does. And what's even worse, > there's another

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix enc_to_dig_port for MST encoders

On Thu, 2016-08-04 at 19:51 -0400, Lyude wrote: > There was some discussion that happened on the original version of this > patch: > > https://patchwork.kernel.org/patch/8960831/ > > The general consensus was while this fixed the issue, it probably isn't > the way we want to fix it. It would be

[Intel-gfx] [PATCH] drm/i915: Add some curly braces

From: Ville Syrjälä intel_enable_pipe() looks rather confusing when one side doesn't have the curly braces, and the other one does. And what's even worse, there's another if-else inside the braceless side. Let's put braces around it to make it clear which branch

Re: [Intel-gfx] [PATCH] drm/i915: Prevent oops on req->engine in rcu-protected peeking

On Fri, Aug 05, 2016 at 06:37:00PM +0200, Daniel Vetter wrote: > When only rcu-protected we might peek at a reinitializing request. > Prevent carnage by making sure we don't accidentally chase a NULL > pointer. > > The proper fix for this is to drop the memset (with kzalloc) in the > request

Re: [Intel-gfx] [PATCH 1/3] drm/i915: start adding dp mst audio

Thanks Lyude. I realized that after sending the patches, will fix that. On Thu, 2016-08-04 at 19:42 -0400, Lyude wrote: > This should be added after patch #3, since that's the one that fixes > enc_to_mst(). Otherwise: > > Reviewed-by: Lyude > > On Tue, 2016-08-02 at 18:46

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Dump DP link status when link training stages fail

On Fri, 2016-08-05 at 10:35 +0100, Chris Wilson wrote: > On Thu, Aug 04, 2016 at 01:48:36PM -0700, Dhinakaran Pandiyan wrote: > > A full dump of link status can be handy in debugging link training > > failures. Let's add that to the debug messages when link training fails. > > > > v2: Removing

[Intel-gfx] [PATCH] drm/i915: Don't mark PCH underrun reporting as diasabled for transcoder B/C on LPT-H

From: Ville Syrjälä Marking PCH transcoder FIFO underrun reporting as disabled for transcoder B/C on LPT-H will block us from enabling the south error interrupt. So let's only mark transcoder A underrun reporting as disabled initially. This is a little tricky to

Re: [Intel-gfx] [PATCH] drm/i915: Update comment before i915_spin_request

On Fri, Aug 05, 2016 at 06:33:38PM +0200, Daniel Vetter wrote: > On Fri, Aug 05, 2016 at 05:31:25PM +0100, Chris Wilson wrote: > > On Fri, Aug 05, 2016 at 06:11:24PM +0200, Daniel Vetter wrote: > > > ~jiffie and a few usecs is 3 orders of magnitude different. A bit > > > much. This was changed in

[Intel-gfx] ✗ Ro.CI.BAT: failure for Revert "drm/i915: Track active streams also for DP SST"

== Series Details == Series: Revert "drm/i915: Track active streams also for DP SST" URL : https://patchwork.freedesktop.org/series/10721/ State : failure == Summary == Series 10721v1 Revert "drm/i915: Track active streams also for DP SST"

[Intel-gfx] [PATCH] drm/i915: Prevent oops on req->engine in rcu-protected peeking

When only rcu-protected we might peek at a reinitializing request. Prevent carnage by making sure we don't accidentally chase a NULL pointer. The proper fix for this is to drop the memset (with kzalloc) in the request allocation function, since that avoids both the NULL check in these fastpaths

Re: [Intel-gfx] [PATCH] drm/i915: Update comment before i915_spin_request

On Fri, Aug 05, 2016 at 05:31:25PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 06:11:24PM +0200, Daniel Vetter wrote: > > ~jiffie and a few usecs is 3 orders of magnitude different. A bit > > much. This was changed in > > > > commit ca5b721e238226af1d767103ac852aeb8e4c0764 > > Author:

Re: [Intel-gfx] [PATCH] drm/i915: Update comment before i915_spin_request

On Fri, Aug 05, 2016 at 06:11:24PM +0200, Daniel Vetter wrote: > ~jiffie and a few usecs is 3 orders of magnitude different. A bit > much. This was changed in > > commit ca5b721e238226af1d767103ac852aeb8e4c0764 > Author: Chris Wilson > Date: Fri Dec 11 11:32:58 2015

[Intel-gfx] [PATCH v2 08/11] drm/i915: Skip reset request if there is one already

From: Mika Kuoppala To perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues

[Intel-gfx] [PATCH v2 09/11] drm/i915/tdr: Add engine reset count to error state

Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. Signed-off-by: Arun Siluvery ---

[Intel-gfx] [PATCH v2 06/11] drm/i915/tdr: Modify error handler for per engine hang recovery

This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails at this point because

[Intel-gfx] [PATCH v2 11/11] drm/i915/tdr: Enable Engine reset and recovery support

This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. Signed-off-by: Tomas Elf Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+),

[Intel-gfx] [PATCH v2 05/11] drm/i915: Separate out reset flags from the reset counter

From: Chris Wilson In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this

[Intel-gfx] [PATCH v2 10/11] drm/i915/tdr: Export reset count info to debugfs

A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they areexpected to trigger reset; these counts are checked before and after the test to ensure the same. Signed-off-by: Arun Siluvery

[Intel-gfx] [PATCH v2 01/11] drm/i915: Record the position of the start of the request

From: Chris Wilson Not only does it make for good documentation and debugging aide, but it is also vital for when we want to unwind requests - such as when throwing away an incomplete request. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Track active streams also for DP SST"

On Fri, Aug 05, 2016 at 05:14:23PM +0100, Chris Wilson wrote: > On Fri, Aug 05, 2016 at 07:05:42PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > This reverts commit f64425a82bdb5c3d7e09ba765716da88a9b00eec. > > > > active_streams will

[Intel-gfx] [PATCH v2 02/11] drm/i915: Simplify ELSP queue request tracking

From: Chris Wilson Emulate HW to track and manage ELSP queue. A set of SW ports are defined and requests are assigned to these ports before submitting them to HW. This helps in cleaning up incomplete requests during reset recovery easier especially after engine reset by

[Intel-gfx] [PATCH v2 07/11] drm/i915/tdr: Add support for per engine reset recovery

This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards. Hangchecker determines which engines are hung and invokes

[Intel-gfx] [PATCH v2 00/11] Execlist based Engine reset patches

These patches are to add engine reset feature from Gen8. This is also referred to as Timeout detection and recovery (TDR). This complements to the full gpu reset feature available in i915 but it only allows to reset a particular engine instead of all engines thus providing a light weight engine

[Intel-gfx] [PATCH v2 03/11] drm/i915: Update reset path to fix incomplete requests

From: Chris Wilson Update reset path in preparation for engine reset which requires identification of incomplete requests and associated context and fixing their state so that engine can resume correctly after reset. The request that caused the hang will be skipped and

[Intel-gfx] [PATCH v2] drm/i915: Do not overwrite the request with zero on reallocation

When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915: Enable lockless lookup of request tracking via RCU"), we acknowledge that we may race with another thread that could have reallocated the request. In order for the first thread not to blow up, the second thread must not clear

Re: [Intel-gfx] [PATCH] drm/i915: Do not overwrite the request with zero on reallocation

On Fri, Aug 05, 2016 at 04:13:28PM +0100, Chris Wilson wrote: > When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915: > Enable lockless lookup of request tracking via RCU"), we acknowledge that > we may race with another thread that could have reallocated the request. > In order

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Track active streams also for DP SST"

On Fri, Aug 05, 2016 at 07:05:42PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > This reverts commit f64425a82bdb5c3d7e09ba765716da88a9b00eec. > > active_streams will get totally out of whack with SST unless we > sync up with the hw state

[Intel-gfx] [PATCH] drm/i915: Update comment before i915_spin_request

~jiffie and a few usecs is 3 orders of magnitude different. A bit much. This was changed in commit ca5b721e238226af1d767103ac852aeb8e4c0764 Author: Chris Wilson Date: Fri Dec 11 11:32:58 2015 + drm/i915: Limit the busy wait on requests to 5us not 10ms! But

[Intel-gfx] [PATCH] Revert "drm/i915: Track active streams also for DP SST"

From: Ville Syrjälä This reverts commit f64425a82bdb5c3d7e09ba765716da88a9b00eec. active_streams will get totally out of whack with SST unless we sync up with the hw state at readout, obviously! We don't yet do that, so now the WARNs fire all the time. Let's

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Do not overwrite the request with zero on reallocation

== Series Details == Series: drm/i915: Do not overwrite the request with zero on reallocation URL : https://patchwork.freedesktop.org/series/10719/ State : failure == Summary == Series 10719v1 drm/i915: Do not overwrite the request with zero on reallocation

[Intel-gfx] [PATCH] drm/i915: Do not overwrite the request with zero on reallocation

When using RCU lookup for the request, commit 0eafec6d3244 ("drm/i915: Enable lockless lookup of request tracking via RCU"), we acknowledge that we may race with another thread that could have reallocated the request. In order for the first thread not to blow up, the second thread must not clear

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

Hi Dave, a few more fixes for the merge window. I know the timing probably isn't good, apologies. I see the PSR fixes in Linus' tree, and then there's the lockdep fix we'd like you to pick up directly [1]. BR, Jani. [1]

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs (rev2)

== Series Details == Series: drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs (rev2) URL : https://patchwork.freedesktop.org/series/10711/ State : failure == Summary == Series 10711v2 drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs

Re: [Intel-gfx] [PATCH i-g-t 1/3] tools/intel_reg: Don't reuse stale decoded results for later registers

On Fri, Aug 05, 2016 at 11:54:19AM +0300, Jani Nikula wrote: > On Fri, 05 Aug 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > In case the ->debug_output() function skips decoding the register it > > just returns, which means the caller

[Intel-gfx] [PATCH v2] drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs

In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from idle-worker") the racy detection of missed interrupts was removed when we went idle. This however opened up the issue that the stuck waiters were not being reported, causing a test case failure. If we move the stuck waiter

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Friday, August 5, 2016 6:54 PM > To: Yang, Libin > Cc: libin.y...@linux.intel.com; intel-gfx@lists.freedesktop.org; > jani.nik...@linux.intel.com; Vetter, Daniel

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs

== Series Details == Series: drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs URL : https://patchwork.freedesktop.org/series/10711/ State : failure == Summary == Series 10711v1 drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs

[Intel-gfx] [PATCH] drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs

In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from idle-worker") the racy detection of missed interrupts was removed when we went idle. This however opened up the issue that the stuck waiters were not being reported, causing a test case failure. If we move the stuck waiter

Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: set proper N/M in modeset

On Fri, Aug 05, 2016 at 08:55:27AM +, Yang, Libin wrote: > > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > Sent: Friday, August 5, 2016 4:45 PM > > To: Yang, Libin > > Cc: libin.y...@linux.intel.com;

[Intel-gfx] [PATCH v4 3/4] drm/i915: Use new CRC debugfs API

The core provides now an ABI to userspace for generation of frame CRCs, so implement the ->set_crc_source() callback and reuse as much code as possible with the previous ABI implementation. v2: - Leave the legacy implementation in place as the ABI implementation in the core is

[Intel-gfx] [PATCH v4 0/4] New debugfs API for capturing CRC of frames

Hi, this series basically takes the facility for continuously capturing CRCs of frames from the i915 driver and into the DRM core. The idea is that test suites such as IGT use this information to check that frames that are exected to be identical, also have identical CRC values. Other drivers

[Intel-gfx] [PATCH v4 1/4] drm/i915/debugfs: Move out pipe CRC code

In preparation to using a generic API in the DRM core for continuous CRC generation, move the related code out of i915_debugfs.c into a new file. Eventually, only the Intel-specific code will remain in this new file. v2: Rebased. Signed-off-by: Tomeu Vizoso ---

[Intel-gfx] [PATCH v4 4/4] drm/i915: Put "cooked" vlank counters in frame CRC lines

Use drm_accurate_vblank_count so we have the full 32 bit to represent the frame counter and userspace has a simpler way of knowing when the counter wraps around. Signed-off-by: Tomeu Vizoso --- drivers/gpu/drm/i915/i915_irq.c | 6 +++--- 1 file changed, 3

Re: [Intel-gfx] [PATCH] kernel/cpu: Distinct name for cpu_hotplug.dep_map

On Thu, Jun 09, 2016 at 02:48:39PM +0300, Joonas Lahtinen wrote: > Use distinctive name for cpu_hotplug.dep_map to avoid the actual > cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats. > > Cc: Ingo Molnar > Cc: Peter Zijlstra > Cc:

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: fix WaInsertDummyPushConstPs

On pe, 2016-08-05 at 10:56 +0100, Matthew Auld wrote: > > > > Test kms_cursor_legacy: > > Subgroup basic-cursor-vs-flip-legacy: > > fail   -> PASS   (ro-ilk1-i5-650) > > Subgroup basic-flip-vs-cursor-legacy: > > pass   -> FAIL   

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: fix WaInsertDummyPushConstPs

> Test kms_cursor_legacy: > Subgroup basic-cursor-vs-flip-legacy: > fail -> PASS (ro-ilk1-i5-650) > Subgroup basic-flip-vs-cursor-legacy: > pass -> FAIL (ro-snb-i7-2620M) > pass -> FAIL

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,01/19] drm/i915: Introduce i915_gem_active_wait_unlocked()

== Series Details == Series: series starting with [CI,01/19] drm/i915: Introduce i915_gem_active_wait_unlocked() URL : https://patchwork.freedesktop.org/series/10706/ State : failure == Summary == Series 10706v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Minor clean up related to link training function declarations

On Thu, Aug 04, 2016 at 01:57:18PM -0700, Dhinakaran Pandiyan wrote: > No functional change. Organizing the declarations for functions > implemented in intel_dp_link_training.c > > Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/dp: Dump DP link status when link training stages fail

On Thu, Aug 04, 2016 at 01:48:36PM -0700, Dhinakaran Pandiyan wrote: > A full dump of link status can be handy in debugging link training > failures. Let's add that to the debug messages when link training fails. > > v2: Removing unrelated clean up (Jani) > Signed-off-by: Dhinakaran Pandiyan

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/dp: Add debug messages to print DP link training pattern

On Thu, Aug 04, 2016 at 01:48:35PM -0700, Dhinakaran Pandiyan wrote: > Currently we do not print the training pattern used in any of the DP link > training stages. Including this piece of information in debug messages will > help debugging. > > Also, use the wrapper

Re: [Intel-gfx] [PATCH] drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2

On Fri, Aug 05, 2016 at 09:43:59AM +0300, Ville Syrjälä wrote: > On Tue, Aug 02, 2016 at 03:37:27PM +0300, Jani Nikula wrote: > > On Tue, 02 Aug 2016, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > The spec was recently fixed to have the

Re: [Intel-gfx] [PATCH] drm: Paper over locking inversion after registration rework

On Fri, Aug 05, 2016 at 10:57:58AM +0200, Jiri Kosina wrote: > On Thu, 4 Aug 2016, Daniel Vetter wrote: > > > drm_connector_register_all requires a few too many locks because our > > connector_list locking is busted. Add another FIXME+hack to work > > around this. This should address the below

[Intel-gfx] [CI 09/19] drm/i915: Tidy generation of the GTT mmap offset

If we make the observation that mmap-offsets are only released when we free an object, we can then deduce that the shrinker only creates free space in the mmap arena indirectly by flushing the request list and freeing expired objects. If we combine this with the lockless vma-manager and lockless

[Intel-gfx] [CI 05/19] drm/i915: Remove forced stop ring on suspend/unload

Before suspending (or unloading), we would first wait upon all rendering to be completed and then disable the rings. This later step is a remanent from DRI1 days when we did not use request tracking for all operations upon the ring. Now that we are sure we are waiting upon the very last operation

[Intel-gfx] [CI 15/19] drm/i915: Remove pinned check from madvise ioctl

We don't need to incur the overhead of checking whether the object is pinned prior to changing its madvise. If the object is pinned, the madvise will not take effect until it is unpinned and so we cannot free the pages being pointed at by hardware. Marking a pinned object with allocated pages as

[Intel-gfx] [CI 16/19] drm/i915: Remove locking for get_tiling

Since we are not concerned with userspace racing itself with set-tiling (the order is indeterminant even if we take a lock), then we can safely read back the single obj->tiling_mode and do the static lookup of swizzle mode without having to take a lock. get-tiling is reasonably frequent due to

  1   2   >