Am 19.11.2013 17:41, schrieb Daniel Vetter:
On Tue, Nov 19, 2013 at 05:15:09PM +0100, Thomas Richter wrote:
Hi Daniel, dear intel experts,
please find a patch attached that finally addresses the display
flicker on i830 chipsets. This
patch adds a lower watermark setting in
If valgrind is not available, current VG_CLEAR() would just ignore
memory clear operation which might make invalid ioctl argument. So
make sure VG_CLEAR() will always clear memory.
---
intel/intel_bufmgr_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, Nov 20, 2013 at 10:18 AM, Thomas Richter t...@math.tu-berlin.de wrote:
I think we ned to split out the gen2/3 single/dual pipe watermark code a
bit better from everything else. A bugfix for i830M shouldn't really
affect snb ;-)
Actually, the fun part is that it does not because all
Am 20.11.2013 10:27, schrieb Daniel Vetter:
What I've meant to say is that I want to split up the watermark code
more anyway, so that there's no need to fill in the 0 all over the
place where we don't care one bit. I.e. all the gen4+ platforms.
Ok - well, I guess I cannot judge whether that's
On Tue, Nov 19, 2013 at 09:37:16AM -0800, Rodrigo Vivi wrote:
On Tue, Nov 19, 2013 at 5:52 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote:
From: Daniel Vetter daniel.vet...@ffwll.ch
This is useful when we only have aliasing
On Wed, Nov 20, 2013 at 05:22:48PM +0800, Zhenyu Wang wrote:
If valgrind is not available, current VG_CLEAR() would just ignore
memory clear operation which might make invalid ioctl argument. So
make sure VG_CLEAR() will always clear memory.
---
intel/intel_bufmgr_gem.c | 2 +-
1 file
Daniel Vetter dan...@ffwll.ch writes:
Hi Daniel,
On Mon, Nov 18, 2013 at 04:34:44PM +0200, Mika Kuoppala wrote:
Large parts of hw initialization is behind per gen
clock gating functions. Including workarounds.
Call intel_modeset_init_hw after reset so that we
set these up correctly.
On Wed, Nov 20, 2013 at 12:47 PM, Mika Kuoppala
mika.kuopp...@linux.intel.com wrote:
FAIL WaDisableEarlyCull:ivb
OK WaDisableBackToBackFlipFix:ivb
FAIL WaDisablePSDDualDispatchEnable:ivb
FAIL WaDisableRHWOptimizationForRenderHang:ivb
FAIL
On Wed, Nov 13, 2013 at 10:20:45AM -0800, Jesse Barnes wrote:
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
This regression has been introduced in
commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Sep 4 18:25:22 2013 +0300
drm/i915: Use adjusted_mode appropriately when computing watermarks
I guess we should renable the enabled local
On Wed, Nov 20, 2013 at 03:02:10PM +0100, Daniel Vetter wrote:
This regression has been introduced in
commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Sep 4 18:25:22 2013 +0300
drm/i915: Use adjusted_mode appropriately
On Wed, Nov 20, 2013 at 04:47:14PM +0200, Ville Syrjälä wrote:
On Wed, Nov 20, 2013 at 03:02:10PM +0100, Daniel Vetter wrote:
This regression has been introduced in
commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date: Wed Sep 4
Getting global reset count needs to be tested with root and
non root access.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tests/gem_reset_stats.c | 70 +--
1 file changed, 61 insertions(+), 9 deletions(-)
diff --git
To make driver report a simulated hang in dmesg.
Suggested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tests/gem_reset_stats.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tests/gem_reset_stats.c
For BDW+, there BATCH_BUFFER_START is 3 * 32bits in length and
length needs to be encoded into the opcode.
Suggested-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
tests/gem_reset_stats.c | 12 +---
1 file changed, 9 insertions(+),
Hi Dave,
Just a small pile of fixes for bugs and a few regressions. I'm still
trying to track down a driver load hang on my g33 (which infuriatingly
doesn't happen when loading the module manually after boot), somehow
bisecting loves to go astray on this one :( And there's a (harmless)
locking
On 2013.11.20 11:36:20 +, Damien Lespiau wrote:
On Wed, Nov 20, 2013 at 05:22:48PM +0800, Zhenyu Wang wrote:
If valgrind is not available, current VG_CLEAR() would just ignore
memory clear operation which might make invalid ioctl argument. So
make sure VG_CLEAR() will always clear
On Wed, Nov 20, 2013 at 7:00 AM, S, Deepak deepa...@intel.com wrote:
- have you done measurements on this? given how infrequently we
ought to be waking the wells when they're idle, and how long we
generally keep them awake, is this a real power win?
[Deepak] By Individually controlling
Thanks Jesse, I wil split the patches and send it for review.
Thanks
Deepak
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Wednesday, November 20, 2013 9:35 PM
To: S, Deepak
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv:
From: Ian Romanick ian.d.roman...@intel.com
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Reported-by: Zhenyu Wang zhen...@linux.intel.com
Cc: Damien
On Wed, Nov 20, 2013 at 08:38:38AM -0800, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick
On Wed, Nov 20, 2013 at 3:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Nov 19, 2013 at 09:37:16AM -0800, Rodrigo Vivi wrote:
On Tue, Nov 19, 2013 at 5:52 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Mon, Nov 18, 2013 at 06:32:34PM -0800, Rodrigo Vivi wrote:
From:
On Wed, Nov 20, 2013 at 08:38:38AM -0800, Ian Romanick wrote:
From: Ian Romanick ian.d.roman...@intel.com
The ioctl expects that certain fields will be zeroed, so we should allow
the helper function to actually work in non-Valgrind builds.
Signed-off-by: Ian Romanick
On Wed, Nov 20, 2013 at 11:53:54PM +0800, Zhenyu Wang wrote:
VG_CLEAR() is really just for valgrind. If you need to set some specific
variable/field to 0 then you need to set it to 0 and not rely on
VG_CLEAR() to do it for you.
ok, in valgrind case it does memory clear for ioctl args
On Mon, Nov 18, 2013 at 05:13:19PM +0200, Ville Syrjälä wrote:
On Thu, Nov 14, 2013 at 07:09:48PM +0200, Ville Syrjälä wrote:
On Thu, Nov 14, 2013 at 02:54:10PM +0200, Mika Kuoppala wrote:
ville.syrj...@linux.intel.com writes:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Hi Stephen,
On Tue, 19 November 2013 Stephen Clark sclar...@earthlink.net wrote:
Thanks for the response. I have subscribed to the intel-gfx list. I didn't
post
the error_state file since it huge.
It's best to submit a but report on bugs.freedesktop.org and attach the
error_state there
Hi Bruno,
I have tested the latest kernel and X, mesa etc, but am still using wine-1.3.24.
I am working on upgrading that. If I still
have the error I will file a bug report at bugs.freedesktop.org. I already have
a login because of the same problem
happening with Myst 5, but it was never
On Wed, Nov 20, 2013 at 04:58:17PM +0200, Mika Kuoppala wrote:
Getting global reset count needs to be tested with root and
non root access.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
All merged to igt, thanks for the patches.
-Daniel
---
tests/gem_reset_stats.c | 70
Here's a series of patches which provide DRI3 and Present support in
the Intel 2D driver. The first two patches pave the way by
synthesizing 64-bit vblank counters and extending the DRM event
handling to allow for both DRI2 and DRI3 events. Then there's a patch
to add DRI2 and miSyncShm support
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac| 15 ++
src/uxa/Makefile.am | 6 +
src/uxa/intel.h | 15 ++
src/uxa/intel_driver.c | 4 +
src/uxa/intel_present.c | 406
5 files changed, 446
This refactors the drm interrupt handling logic quite a bit, both to
allow for either DRI2 or Present handlers, but also to eliminate
passing pointers through the kernel. Passing pointers left the kernel
holding the only reference to some internal X server data structures.
After a server reset,
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac | 14
src/uxa/Makefile.am| 7 ++
src/uxa/intel.h| 17 +
src/uxa/intel_dri3.c | 184 +
src/uxa/intel_driver.c | 13
src/uxa/intel_sync.c |
The kernel sometimes reports bogus MSC values, especially when
suspending and resuming the machine. Deal with this by tracking an
offset to ensure that the MSC seen by applications increases
monotonically, and at a reasonable pace.
Also, provide a full 64 bits of MSC value by noticing wrapping
Hi Stephen,
On Wed, 20 November 2013 Stephen Clark sclar...@earthlink.net wrote:
Hi Bruno,
I have tested the latest kernel and X, mesa etc, but am still using
wine-1.3.24.
I am working on upgrading that. If I still have the error I will file
a bug report at bugs.freedesktop.org. I already
Folks,
A newbie question - When filling in an HDMI AVI infoframe, how does one
correctly determine the default picture aspect ratio (and VIC) for CEA modes
that support multiple (4:3 and 16:9) aspect ratios. 720x576p for example,
corresponds to VIC 17 or 18:
/* 17 - 720x576@50Hz */
On Wed, Nov 20, 2013 at 10:11:55PM +, Damien Lespiau wrote:
On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
Folks,
A newbie question - When filling in an HDMI AVI infoframe, how does
one correctly determine the default picture aspect ratio (and VIC)
for CEA modes
On Wed, Nov 06, 2013 at 11:02:16PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We need some protection for the FBC state, and since struct_mutex
is it currently in most places, make sure all FBC update/disable
calles are protected by it.
Why
On Wed, Nov 06, 2013 at 11:02:19PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Don't issue the FBC nuke/cache clean command when invalidate_domains!=0.
Double negative almost confused me, but all right here.
Reviewed-by: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 06, 2013 at 11:02:20PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The spec tells us that we need to emit an SRM after the LRI
to MSG_FBC_REND_STATE.
Signed-off-by: Ville
On Wed, Nov 06, 2013 at 11:02:21PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only during batches targetting the front buffer.
You improved things a lot here, but
On Wed, Nov 06, 2013 at 11:02:23PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We use LRIs to enable/disable the render tracking as needed. So leave
ILK_FBC_RT_BASE alone when enabling FBC on SNB.
Shouldn't this be part of patch 6
While at
On Wed, Nov 06, 2013 at 11:02:22PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
No longer needed since the LRIs do the work.
Shouldn't this be part of previous patch?
v2: Rebased due to hunk getting dropped from an ealier patch
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Wed, Nov 06, 2013 at 11:02:25PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
All the other .enable_fbc() funcs use plane_name(). Make
gen7_enable_fbc() do the same.
Signed-off-by: Ville
On Wed, Nov 20, 2013 at 02:55:57PM -0800, Rodrigo Vivi wrote:
On Wed, Nov 06, 2013 at 11:02:21PM +0200, ville.syrj...@linux.intel.com wrote:
static void
+i915_gem_execbuffer_mark_fbc_dirty(struct intel_ring_buffer *ring,
+ struct list_head *vmas)
+{
+
On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
Folks,
When filling in an HDMI AVI infoframe, how does
one correctly determine the default picture aspect ratio (and VIC)
for CEA modes that support multiple (4:3 and 16:9) aspect ratios.
720x576p for example,
ops, I just noticed that by mistake I replied the v1-series
but I actually looked to v2 seires... Sorry about that
On Wed, Nov 20, 2013 at 3:17 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Wed, Nov 20, 2013 at 02:55:57PM -0800, Rodrigo Vivi wrote:
On Wed, Nov 06, 2013 at 11:02:21PM
actually just ignore my last msg... alternate between gmail and mutt
confused me...
On Wed, Nov 6, 2013 at 1:02 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
As per the SNB and HSW PM guides, we should enable FBC render/blitter
tracking only
On Wed, Nov 20, 2013 at 11:45:03PM +, Gohad, Tushar wrote:
On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
Folks,
When filling in an HDMI AVI infoframe, how does
one correctly determine the default picture aspect ratio (and VIC)
for CEA modes that support
On 2013.11.20 16:59:22 +, Damien Lespiau wrote:
Right, so the fix is (was) to zero the fields checked by the kernel
explicitely, not change the VG() macro, which is just used in testing
(and it should this way).
That's fine. Thanks.
--
Open Source Technology Center, Intel ltd.
$gpg
On Wed, Nov 20, 2013 at 11:45:03PM +, Gohad, Tushar wrote:
On Wed, Nov 20, 2013 at 09:48:26PM +, Gohad, Tushar wrote:
Folks,
When filling in an HDMI AVI infoframe, how does one correctly
determine the default picture aspect ratio (and VIC) for CEA
modes that
On 11/21/2013 04:56 AM, Igor Gnatenko wrote:
Any news here? If no - I think we need re-send patch as new..
Since the v2 patch can't apply cleanly on top of pm's -next tree, I
think it's worth a re-send, so here it comes.
---
Subject: [PATCH] ACPI / video: Add systems that should favor native
51 matches
Mail list logo
