On Fri, 05 Apr 2013, Ben Widawsky b...@bwidawsk.net wrote:
On Fri, Apr 05, 2013 at 10:09:58AM +0300, Jani Nikula wrote:
Same goes for the unlikely in patches 4/7. (Yes, patch_es_ 4/7 - there's
*two* patches 4/7 in the series! :o)
I don't see two, weird.
Hmm, it's not only my mail setup:
We need to clear out the error_state. While at it also make sure that
the hang was indeed detected.
Whoever writes the next test to race against gpu hangs should probably
extract these two functions into the drmtest library. Which just one
user that's not really worth it right now.
v2: Fill cpu
With this at least the y-tiled test reliably fails on my machines, but
x-tiled still passes on some. More ideas to tune this highly welcome.
v2: Fill cpu caches with data for each newly allocated bo. This seems
to do the trick on my snb here _really_ reliably. So apparently the
backsnoop for llc
On Sat, Apr 06, 2013 at 11:54:56PM +0200, Daniel Vetter wrote:
Userspace can easily hit this and does since Ville added a new evil
igt testcase in:
commit 069e35e0fc3785faa562adcfd2dd7bbed4cb1dea
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Mon Mar 4 15:34:06 2013 +0200
On Mon, Apr 08, 2013 at 09:23:55AM +0200, Daniel Vetter wrote:
With this at least the y-tiled test reliably fails on my machines, but
x-tiled still passes on some. More ideas to tune this highly welcome.
v2: Fill cpu caches with data for each newly allocated bo. This seems
to do the trick on
Bspec has been been updated and dropped these two changes for non-sdv
LPT PCHs.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c |7 ---
1 file changed, 7 deletions(-)
diff --git
On Fri, Apr 05, 2013 at 09:03:27AM -0700, Jesse Barnes wrote:
On Thu, 4 Apr 2013 21:31:03 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
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
On Sun, Apr 07, 2013 at 11:13:03AM +0200, Daniel Vetter wrote:
The first in wait_pipe_off is really just a delay loop to wait for the
scanline counter to settle (which takes about a frame worth of time).
So also shrink it a bit.
The other is in the ilk dprs code. If we need _exactly_ an 1ms
On Sat, Apr 06, 2013 at 04:08:38PM +0200, Daniel Vetter wrote:
Otherwise running igt will fill your dmesg with hang notices and it's
hard to judge from a quick look whether they're expected or not.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Is there not a mechanism for userspace to
On Sat, Apr 06, 2013 at 02:00:31AM +0200, Laurent Pinchart wrote:
Hi Ville,
Thanks for the patch.
On Friday 05 April 2013 16:19:36 ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
struct drm_rect represents a simple rectangle. The utility
Hi
2013/4/8 Chris Wilson ch...@chris-wilson.co.uk:
On Sun, Apr 07, 2013 at 11:13:03AM +0200, Daniel Vetter wrote:
The first in wait_pipe_off is really just a delay loop to wait for the
scanline counter to settle (which takes about a frame worth of time).
So also shrink it a bit.
The other
On Mon, Apr 8, 2013 at 1:49 PM, Paulo Zanoni przan...@gmail.com wrote:
2013/4/8 Chris Wilson ch...@chris-wilson.co.uk:
On Sun, Apr 07, 2013 at 11:13:03AM +0200, Daniel Vetter wrote:
The first in wait_pipe_off is really just a delay loop to wait for the
scanline counter to settle (which takes
On Sat, Apr 6, 2013 at 12:05 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
When inlining the actual hpd output probing in
commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Oct 23 18:23:34 2012 +
drm: run the hpd irq event code
On Mon, Apr 8, 2013 at 2:28 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Sat, Apr 6, 2013 at 12:05 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
When inlining the actual hpd output probing in
commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are not backed by any
particular cache (such as the sampler or render caches) our only option
is to select the
Hi
2013/4/8 Daniel Vetter daniel.vet...@ffwll.ch:
Bspec has been been updated and dropped these two changes for non-sdv
LPT PCHs.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
On 04/08/2013 06:28 AM, Chris Wilson wrote:
Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are not backed by any
particular cache (such as the sampler or render
On Mon, Apr 8, 2013 at 8:43 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Mon, Apr 8, 2013 at 2:28 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Sat, Apr 6, 2013 at 12:05 PM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
When inlining the actual hpd output probing in
commit
On Mon, Apr 08, 2013 at 11:42:21AM -0300, Paulo Zanoni wrote:
Hi
2013/4/8 Daniel Vetter daniel.vet...@ffwll.ch:
Bspec has been been updated and dropped these two changes for non-sdv
LPT PCHs.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Daniel Vetter
On Mon, Apr 08, 2013 at 07:57:40AM -0700, Kenneth Graunke wrote:
On 04/08/2013 06:28 AM, Chris Wilson wrote:
Enabling context support increases SwapBuffers latency by about 20%
(measured on an i7-3720qm). We can offset that loss slightly by enabling
faster caching for the contexts. As they are
On Sun, 7 Apr 2013 11:13:03 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
The first in wait_pipe_off is really just a delay loop to wait for the
scanline counter to settle (which takes about a frame worth of time).
So also shrink it a bit.
The other is in the ilk dprs code. If we need
On Tue, Feb 12, 2013 at 02:17:22PM +, Chris Wilson wrote:
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending
On Mon, Apr 08, 2013 at 07:18:11PM +0200, Daniel Vetter wrote:
On Tue, Feb 12, 2013 at 02:17:22PM +, Chris Wilson wrote:
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal
From: Paulo Zanoni paulo.r.zan...@intel.com
Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.
This should fix some machines that were showing black screens on all
outputs.
Cc:
From: Paulo Zanoni paulo.r.zan...@intel.com
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
On Sat, Apr 06, 2013 at 07:41:44PM +0200, Daniel Vetter wrote:
On Fri, Apr 05, 2013 at 01:12:42PM -0700, Ben Widawsky wrote:
More registers we can't write.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Fixed up a minor bug (at least I think it's one) in the irq uninstall
code. Note
Per the spec change.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Untested.
---
drivers/gpu/drm/i915/intel_display.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b884932..1dffaf7 100644
Hi
2013/4/8 Jani Nikula jani.nik...@intel.com:
Per the spec change.
Signed-off-by: Jani Nikula jani.nik...@intel.com
http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-next-queuedid=71bddd4d17cc59c666589c86ca06f0eecec3ad53
---
Untested.
---
On Mon, Apr 8, 2013 at 7:40 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Apr 08, 2013 at 07:18:11PM +0200, Daniel Vetter wrote:
On Tue, Feb 12, 2013 at 02:17:22PM +, Chris Wilson wrote:
By exporting the ability to map user address and inserting PTEs
representing their backing
On Mon, Apr 8, 2013 at 8:58 PM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
* Daniel Vetter | 2013-04-02 15:47:02 [+0200]:
On Tue, Apr 02, 2013 at 03:30:58PM +0200, Sebastian Andrzej Siewior wrote:
mutex_is_locked_by() checks the owner of the lock against current. This
is done by
Workaround to avoid intermittent aux channel failures, per spec change.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Untested.
---
drivers/gpu/drm/i915/intel_dp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
Hi
2013/3/28 Jesse Barnes jbar...@virtuousgeek.org:
The existing code was trying different vswing and preemphasis settings
in the wrong place, and wasn't trying them enough. So add a loop to
walk through them, properly disabling FDI TX and RX in between if a
failure is detected.
v2: remove
Hi
2013/4/8 Paulo Zanoni przan...@gmail.com:
From: Paulo Zanoni paulo.r.zan...@intel.com
Check the VBT to see if the machine has inverted FDI RX polarity on
CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2
registers.
This should fix some machines that were showing
On Mon, Apr 08, 2013 at 09:24:58PM +0200, Daniel Vetter wrote:
On Mon, Apr 8, 2013 at 7:40 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Apr 08, 2013 at 07:18:11PM +0200, Daniel Vetter wrote:
On Tue, Feb 12, 2013 at 02:17:22PM +, Chris Wilson wrote:
By exporting the ability
Hi all, this small series enable Frame Buffer Compression at HSW.
I decided to create a new function haswell_enable_fbc to avoid getting old
function messed with many IS_HASWELL checks.
Also I decided to split the 2 needed workarounds in separated pathces to be
easy to revert at any time if
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
Display register 420B0h bit 22 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 7 +++
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 11 insertions(+)
diff
Display register 46500h bit 23 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 2 ++
2 files changed, 5 insertions(+)
diff --git
Daniel Vetter dan...@ffwll.ch writes:
On Mon, Apr 8, 2013 at 7:40 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Apr 08, 2013 at 07:18:11PM +0200, Daniel Vetter wrote:
On Tue, Feb 12, 2013 at 02:17:22PM +, Chris Wilson wrote:
By exporting the ability to map user address and
All gen6+ parts so far have 1 BAR which holds both the register space
and the GTT PTEs. Up until now, that was a 4MB BAR with half allocated
to each.
I have a strong hunch (wink, nod, wink) that future gens will also keep
a similar 50-50 split though the sizes may change. To help this along
From: Ben Widawsky benjamin.widaw...@intel.com
We can assume that the PTE layout, and size changes for future
generations. To avoid confusion with the existing GEN6 PTE typedef, give
it a GEN6_ prefix.
v2: Fixup checkpatch warning and bikeshed commit message slightly.
v3: Rebase on top of
This will allow us to read/write registers in GTT init.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c | 48 -
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
There used to be other fixes in this patch but they've slowly disappeared as
other parts have been fixed.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
The PPGTT scratch page is used for all gens, and doing it in the global
part of our PPGTT setup makes the code a bit nicer.
This was in a patch submitted earlier as part of the PPGTT cleanups.
Grumpy maintainer must have missed it, and I didn't yell when
appropriate. Apologies for everyone :-)
It only works that way on GEN6 and GEN7. Let's not assume GENn will be
the same.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
From: Ben Widawsky benjamin.widaw...@intel.com
This rework will help if future platforms choose to be a bit different.
Should have no functional impact.
v2: Don't move around the vtable setup (Daniel)
v3: Squash in the disable-by-default patch.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
From: Ben Widawsky benjamin.widaw...@intel.com
Since we've already set up a nice vtable to abstract other PPGTT
functions, also abstract the actual register programming to enable
things.
This function will probably need to change a bit as we implement real
processes.
v2: Resolve conflicts due
From: Ben Widawsky benjamin.widaw...@intel.com
I'm really not happy that we have to support this, but this will be the
simplest way to handle cases where PPGTT init can fail, which I promise
will be coming in the future.
v2: Resolve conflicts due to patch series reordering.
Signed-off-by: Ben
Workaround to avoid intermittent aux channel failures, per spec change.
v2: Don't mess with cpu dp aux divider (Paulo Zanoni)
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Untested.
---
drivers/gpu/drm/i915/intel_dp.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
49 matches
Mail list logo
