Re: [Intel-gfx] [PATCH 12/13] drm/i915: fix DP get_hw_state return value

On Thu, Apr 4, 2013 at 2:12 AM, Jesse Barnes wrote: > On Thu, 4 Apr 2013 01:15:28 +0200 > Daniel Vetter wrote: > >> On Tue, Apr 02, 2013 at 08:11:05PM +0200, Daniel Vetter wrote: >> > On Tue, Apr 02, 2013 at 10:03:56AM -0700, Jesse Barnes wrote: >> > > If we couldn't find a pipe we shouldn't retu

Re: [Intel-gfx] [PATCH] drm/i915: GFDT support for SNB/IVB

On Wed, Mar 06, 2013 at 04:28:09PM +, Chris Wilson wrote: > From: Ville Syrjälä > > Currently all scanout buffers must be uncached because the > display controller doesn't snoop the LLC. SNB introduced another > method to guarantee coherency for the display controller. It's > called the GFDT

Re: [Intel-gfx] [PATCH] drm/i915: GFDT support for SNB/IVB

On Thu, Apr 04, 2013 at 11:01:02AM +0200, Daniel Vetter wrote: > On Wed, Mar 06, 2013 at 04:28:09PM +, Chris Wilson wrote: > > From: Ville Syrjälä > > > > Currently all scanout buffers must be uncached because the > > display controller doesn't snoop the LLC. SNB introduced another > > method

Re: [Intel-gfx] [PATCH] drm/i915: Don't override PPGTT cacheability on HSW

On Wed, Apr 03, 2013 at 10:08:26PM +0200, Daniel Vetter wrote: > On Wed, Apr 3, 2013 at 9:33 PM, Daniel Vetter wrote: > > So I've checked hsw bspec and the problem is that hw guys again > > changed the bits around a bit, and I think on HSW we actually want > > (0x8 << 3) instead of what's currentl

[Intel-gfx] [PATCH 1/3] drm/i915: Add ECOBITS_SNB_BIT

From: Ville Syrjälä GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add the define, and enable it on SNB. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++- drivers/gpu/drm/i915/i915_reg.h | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) dif

[Intel-gfx] [PATCH 3/3] drm/i915: Configure GAM_ECOCHK appropriatly for Gen7

From: Ville Syrjälä IVB and HSW use different encodings for the PPGTT cacheability bits in the GAM_ECOCHK register. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem_gtt.c | 11 +-- drivers/gpu/drm/i915/i915_reg.h | 5 + 2 files changed, 14 insertions(+), 2 deleti

[Intel-gfx] [PATCH 2/3] drm/i915: Set GAC_ECO_BITS register on Gen7+

From: Ville Syrjälä According to BSpec GAC_ECO_BITS register exists on Gen7 platforms as well. Configure it accordingly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_gem_gtt.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/

Re: [Intel-gfx] [PATCH] drm/i915: GFDT support for SNB/IVB

On Thu, Apr 04, 2013 at 02:27:12PM +0300, Ville Syrjälä wrote: > On Thu, Apr 04, 2013 at 11:01:02AM +0200, Daniel Vetter wrote: > > On Wed, Mar 06, 2013 at 04:28:09PM +, Chris Wilson wrote: > > > From: Ville Syrjälä > > > > > > Currently all scanout buffers must be uncached because the > > >

[Intel-gfx] [PATCH] drm/i915: revert eDP bpp clamping code changes

The behaviour around handling the eDP bpp value from vbt has been slightly changed in commit 3600836585e3fdef0a1410d63fe5ce4015007aac Author: Daniel Vetter Date: Wed Mar 27 00:44:59 2013 +0100 drm/i915: convert DP autodither code to new infrastructure The old behaviour was that we used th

[Intel-gfx] [PATCH v3 04/16] drm/i915: pass seqno to i915_hangcheck_ring_idle

In preparation for next commit, pass seqno as a parameter to i915_hangcheck_ring_idle as it will be used inside i915_hangcheck_elapsed. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_irq.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/d

[Intel-gfx] [PATCH v3 03/16] drm/i915: reference count for i915_hw_contexts

In preparation to do analysis of which context was guilty of gpu hung, store kreffed context pointer into request struct. This allows us to inspect contexts when gpu is reset even if those contexts would already be released by userspace. v2: track i915_hw_context pointers instead of using ctx_ids

[Intel-gfx] [PATCH v3 01/16] drm/i915: return context from i915_switch_context()

In preparation for the next commit, return context that was switched to from i915_switch_context(). v2: context in return value instead of param. (Ben Widawsky) Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h|5 +++-- drivers/gpu/drm/i915/i915_gem.c|

[Intel-gfx] [PATCH v3 08/16] drm/i915: remove i915_hangcheck_hung

Rework of per ring hangcheck made this obsolete. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h |1 - drivers/gpu/drm/i915/i915_irq.c | 21 - 2 files changed, 22 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv

[Intel-gfx] [PATCH v3 05/16] drm/i915: track ring progression using seqnos

Instead of relying in acthd, track ring seqno progression to detect if ring has hung. v2: put hangcheck stuff inside struct (Chris Wilson) Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h |2 -- drivers/gpu/drm/i915/i915_irq.c | 30 +

[Intel-gfx] [PATCH v3 10/16] drm/i915: add i915_gem_context_get_hang_stats()

To get context hang statistics for specified context, add i915_gem_context_get_hang_stats(). For arb-robustness, every context needs to have its own hang statistics tracking. Added function will return the user specified context statistics or in case of default context, statistics from drm_i915_fi

[Intel-gfx] [PATCH v3 07/16] drm/i915: detect hang using per ring hangcheck_score

Add per ring score of possible culprit for gpu hang. If ring is busy and not waiting, it will get the highest score across calls to i915_hangcheck_elapsed. This way we are most likely to find the ring that caused the hang among the waiting ones. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i

[Intel-gfx] [PATCH v3 15/16] drm/i915: add i915_reset_count

Use reset_counter to track how many actual resets have been done. Reset in progress is enough to increment the counter. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h |9 +++-- drivers/gpu/drm/i915/i915_irq.c |2 +- 2 files changed, 8 insertions(+), 3 deletions(-)

[Intel-gfx] [PATCH v3 12/16] drm/i915: mark rings which were waiting when hang happened

For guilty batchbuffer analysis later on on ring resets, mark all waiting rings so that we can skip them when trying to find a true culprit for the gpu hang. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_irq.c |3 ++- drivers/gpu/drm/i915/intel_ringbuffer.h |1 + 2 f

[Intel-gfx] [PATCH v3 13/16] drm/i915: find guilty batch buffer on ring resets

After hang check timer has declared gpu to be hang, rings are reset. In ring reset, when clearing request list, do post mortem analysis to find out the guilty batch buffer. Select requests for further analysis by inspecting the completed sequence number which has been updated into the HWS page. If

[Intel-gfx] [PATCH v3 14/16] drm/i915: refuse to submit more batchbuffers from guilty context

If context has recently submitted a faulty batchbuffers guilty of gpu hang and decides to keep submitting more crap, ban it permanently. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.c| 23 ++- drivers/gpu/drm/i915/i915_drv.h|7 +

[Intel-gfx] [PATCH v3 11/16] drm/i915: add batch object and context to i915_add_request()

In order to track down a batch buffer and context which caused the ring to hang, store reference to bo and context into the request struct. Request can also cause gpu to hang after the batch in the flush section in the ring. To detect this add start of the flush portion offset into the request. Si

[Intel-gfx] [PATCH v3 00/16] arb robustness enablers v3

Hi, I have addressed all the feedback I got from v2 series. Most notably the interface has changed. Now those users who don't care about the exact counts can use batch_pending and batch_active like they would be flags (see i-g-t testcase), assuming they destroy the context after hang is dealt wi

[Intel-gfx] [PATCH v3 06/16] drm/i915: introduce i915_hangcheck_ring_hung

In preparation to track per ring progress in hangcheck, add i915_hangcheck_ring_hung. v2: omit dev parameter (Ben Widawsky) Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_irq.c | 29 + 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/driv

[Intel-gfx] [PATCH v3 16/16] drm/i915: add i915_get_reset_stats_ioctl

This ioctl returns reset stats for specified context. The struct returned contains context loss counters. reset_count:all resets across all contexts batch_active: active batches lost on resets batch_pending: pending batches lost on resets v2: get rid of state tracking completely and deliv

[Intel-gfx] [PATCH v3 09/16] drm/i915: add struct i915_ctx_hang_stats

To count context losses, add struct i915_ctx_hang_stats for both i915_hw_context and drm_i915_file_private. drm_i915_file_private is used when there is no context. v2: renamed and cleaned up the struct (Chris Wilson, Ian Romanick) Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_dma.c

[Intel-gfx] [PATCH v3 02/16] drm/i915: cleanup i915_add_request

Only execbuffer needs all the parameters. Cleanup everything else behind macro. v2: _i915_add_request as function name (Chris Wilson) Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h|8 +--- drivers/gpu/drm/i915/i915_gem.c| 11 +-- drive

[Intel-gfx] [PATCH] drm/i915: tune down Y tiling scanout warning

Userspace can easily hit this and does since Ville added a new evil igt testcase in: commit 069e35e0fc3785faa562adcfd2dd7bbed4cb1dea Author: Ville Syrjälä Date: Mon Mar 4 15:34:06 2013 +0200 kms_flip: Add flip-vs-bad-tiling test Cc: Ville Syrjälä Signed-off-by: Daniel Vetter --- driver

Re: [Intel-gfx] GPU Hang in Intel Driver

Will try mesa 8.0 or newer and report back. I had already bumped up libdrm and xf86-video-intel to the latest available (2.4.43 and 2.21.5 respectively). Thanks, Dihan On Wed, Apr 3, 2013 at 12:21 PM, Daniel Vetter wrote: > On Wed, Apr 3, 2013 at 5:58 PM, Dihan Wickremasuriya < > dwickremasur..

[Intel-gfx] [v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

Hi Daniel, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found the following was the first bad commit: commit c2fb7916927e989ea424e61ce5fe617e54878827 Merge: 29de6ce 6f0c058 Author: Daniel Vetter Date: Mon Oct 22 14:34:51 2012 +0200 Merge tag 'v3.7-rc2'

Re: [Intel-gfx] [v3.8 Regression] Merge tag 'v3.7-rc2' into drm-intel-next-queued

On 04/03/2013 03:16 PM, Daniel Vetter wrote: On Wed, Apr 3, 2013 at 9:08 PM, Joseph Salisbury > wrote: Hi Daniel, A bug was opened against the Ubuntu kernel[0]. After a kernel bisect, it was found the following was the first bad commit:

Re: [Intel-gfx] GPU Hang in Intel Driver

mesa 8.0.4-r1, libdrm 2.4.43 and xf86-video-intel 2.21.5 on top of kernel 3.8.5 seems to work well. No hangs or crashes so far. Thank you very much for your help with this! Would you also happen to know where I can get a patch of the i915 kernel fix that has been backported to version 3.2? Best

Re: [Intel-gfx] GPU Hang in Intel Driver

Will take a look. Thanks again! On Wed, Apr 3, 2013 at 5:02 PM, Daniel Vetter wrote: > On Wed, Apr 03, 2013 at 04:54:31PM -0400, Dihan Wickremasuriya wrote: > > mesa 8.0.4-r1, libdrm 2.4.43 and xf86-video-intel 2.21.5 on top of kernel > > 3.8.5 seems to work well. No hangs or crashes so far.

Re: [Intel-gfx] [PATCH] drm/i915: tune down Y tiling scanout warning

On Thu, Apr 04, 2013 at 06:13:08PM +0200, Daniel Vetter wrote: > Userspace can easily hit this and does since Ville added a new evil > igt testcase in: Scre? :-p -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Int

Re: [Intel-gfx] [PATCH 12/13] drm/i915: fix DP get_hw_state return value

On Thu, 4 Apr 2013 09:56:07 +0200 Daniel Vetter wrote: > On Thu, Apr 4, 2013 at 2:12 AM, Jesse Barnes wrote: > > On Thu, 4 Apr 2013 01:15:28 +0200 > > Daniel Vetter wrote: > > > >> On Tue, Apr 02, 2013 at 08:11:05PM +0200, Daniel Vetter wrote: > >> > On Tue, Apr 02, 2013 at 10:03:56AM -0700, Je

Re: [Intel-gfx] [PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

Hi Ville, Thanks for the patch. On Wednesday 27 March 2013 17:46:22 ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > struct drm_rect represents a simple rectangle. The utility > functions are there to help driver writers. > > v2: Moved the region stuff into its own file, made the

Re: [Intel-gfx] [PATCH] drm/i915: revert eDP bpp clamping code changes

Hi 2013/4/4 Daniel Vetter > > The behaviour around handling the eDP bpp value from vbt has been > slightly changed in > > commit 3600836585e3fdef0a1410d63fe5ce4015007aac > Author: Daniel Vetter > Date: Wed Mar 27 00:44:59 2013 +0100 > > drm/i915: convert DP autodither code to new infrastru

Re: [Intel-gfx] [PATCH] drm/i915: revert eDP bpp clamping code changes

On Thu, Apr 04, 2013 at 03:44:01PM -0300, Paulo Zanoni wrote: > Hi > > 2013/4/4 Daniel Vetter > > > > The behaviour around handling the eDP bpp value from vbt has been > > slightly changed in > > > > commit 3600836585e3fdef0a1410d63fe5ce4015007aac > > Author: Daniel Vetter > > Date: Wed Mar 27

Re: [Intel-gfx] [PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

On Thu, Apr 04, 2013 at 06:38:15PM +0200, Laurent Pinchart wrote: > Hi Ville, > > Thanks for the patch. > > On Wednesday 27 March 2013 17:46:22 ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > struct drm_rect represents a simple rectangle. The utility > > functions are there

[Intel-gfx] [PATCH] drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and write the fence from each cpu taking care to serialise memory accesses on each. The usual mb(), or even a mb() on each CPU is not enough to ensure that access

[Intel-gfx] [PATCH] drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and write the fence from each cpu taking care to serialise memory accesses on each. The usual mb(), or even a mb() on each CPU is not enough to ensure that access

[Intel-gfx] [PATCH 1/3] drm/i915: fix lost FP_CB_TUNE setting for pch plls

commit de13a2e3f88a4da8e85063b6de37096795079e41 Author: Paulo Zanoni Date: Thu Sep 20 18:36:05 2012 -0300 drm/i915: extract compute_dpll from ironlake_crtc_mode_set missed the subtle adjustment of the FP1 register. Fix this up by passing a pointer around instead of the value. Cc: Paulo Za

[Intel-gfx] [PATCH 2/3] drm/i915: fix FP CB tuning limits for lvds

Only on IBX should we set the limiting factor to 25 unconditionally for dual-channel mode, on CPT/PPT 25 only applies when the lvds refclock is 100MHz. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dri

[Intel-gfx] [PATCH 3/3] drm/i915: set CB tuning also for the reduce clock

Since the ratio is different, we also need to pass in the parameters for the reduced clock. Might or might not reduce flicker for the auto-downclocking on lvds/eDP. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletion

[Intel-gfx] [PATCH] drm/i915: Fix SDVO connector and encoder get_hw_state functions

From: Egbert Eich The connector associated with the encoder is considered active when the output associtated with this connector is active on the encoder. The encoder itself is considered active when either there is an active output on it or the respective SDVO channel is active. Having active

[Intel-gfx] [PATCH] drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and write the fence from each cpu taking care to serialise memory accesses on each. The usual mb(), or even a mb() on each CPU is not enough to ensure that access

[Intel-gfx] [PATCH] drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and manually flush writes to memory prior to writing the fence register in conjunction with the memory barriers placed around the register write. Fixes i-g-t/gem_f

Re: [Intel-gfx] BUG: kworker hangs the GPU on drm and i915 since 3.8.x under X11

Two things: - Please always cc relevant mailing lists when reporting a bug. - With lockdep enabled (CONFIG_PROVE_LOCKING) you should get detailed backtraces and lists of held lock when the kworker gets stuck. Can you please reproduce with that option enabled and then attach the dmesg? Thanks, Dani

[Intel-gfx] [PATCH 1/7] drm/i915: Mark context switch likely

Only the very first switch doesn't take the path. Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 94d873a..aa080ea

[Intel-gfx] [PATCH 0/7] [RFC] Context reference counting

These patches implement full context reference counting. In the patch that actually adds the reference counting, I explain why I think Mika's reference counting isn't sufficient for me. Please see/respond to that patch if you disagree. Almost all of the actual work occurs in: "drm/i915: Store last

[Intel-gfx] [PATCH 2/7] drm/i915: Move context special case to get()

This allows us to make upcoming refcounting code a bit simpler, and cleaner. In addition, I think it makes the interface a bit nicer if the caller doesn't need to figure out default contexts and such. The interface works very similarly to the gem object ref counting, and I believe it makes sense t

[Intel-gfx] [PATCH 4/7] drm/i915: Better context messages

Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_gem_context.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 8e218ad..8b2e73a 100644 --- a/drivers/gpu/drm/i915/i915_g

[Intel-gfx] [PATCH 4/7] drm/i915: A bit better messaging for contexts

Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_gem_context.c | 24 +++- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 8e218ad..5ac93f4 100644 --- a/drivers/gpu/

[Intel-gfx] [PATCH 3/7] drm/i915: Make object aware that it backs a context

It's really simple to keep track of objects which back the context. Doing so allows will be really helpful in properly refcounting contexts Daniel: please see the last patch in the series before commenting on this patch. I'm open to other ideas, but this seems like the simplest way to do it, and s

[Intel-gfx] [PATCH 7/7] drm/i915: Print all contexts in debugfs

Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/i915_debugfs.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 375c36a..eef2575 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/dri

[Intel-gfx] [PATCH 5/7] drm/i915: Track context status

Instead of using just an is_initialized flag, it will be helpful to have a bit more information about the context's actual status primarily for the case when the file is closed before the context has actually be destroyed. Could also be useful for debugging. Signed-off-by: Ben Widawsky --- driv

[Intel-gfx] [PATCH 6/7] drm/i915: Store last context instead of the obj

Storing the last context requires refcounting. Mika recently submitted some refcounting patches which leverages our request mechanism. This is insufficient for my needs because we want to know the last context even if the request has ended, ie. doing the kref_put when a request is finished isn't ok

Re: [Intel-gfx] [PATCH 0/7] [RFC] Context reference counting

On Thu, Apr 04, 2013 at 04:41:46PM -0700, Ben Widawsky wrote: > These patches implement full context reference counting. In the patch that > actually adds the reference counting, I explain why I think Mika's reference > counting isn't sufficient for me. Please see/respond to that patch if you > dis

Re: [Intel-gfx] [PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

Hi Ville, On Thursday 04 April 2013 22:52:37 Ville Syrjälä wrote: > On Thu, Apr 04, 2013 at 06:38:15PM +0200, Laurent Pinchart wrote: > > On Wednesday 27 March 2013 17:46:22 ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > struct drm_rect represents a simple rectangle.

Re: [Intel-gfx] [PATCH 0/7] [RFC] Context reference counting

On Thu, Apr 04, 2013 at 04:41:58PM -0700, Ben Widawsky wrote: > On Thu, Apr 04, 2013 at 04:41:46PM -0700, Ben Widawsky wrote: > > These patches implement full context reference counting. In the patch that > > actually adds the reference counting, I explain why I think Mika's reference > > counting