On Wed, May 02, 2012 at 05:22:19PM -0700, Jesse Barnes wrote:
On Wed, 2 May 2012 13:18:56 -0700
Ben Widawsky b...@bwidawsk.net wrote:
On Wed, 2 May 2012 11:55:48 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 2 May 2012 08:44:27 -0700
Ben Widawsky b...@bwidawsk.net
On Wed, May 02, 2012 at 10:55:43PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
While testing with the intel_infoframes tool on gen4, I see that when
video DIP is disabled, what we write to the DATA memory is not exactly
what we read back later. This should fix some
---
drivers/gpu/drm/i915/i915_gem.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1fadb02..4f270e8 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3599,6
Whilst marking the device as active is protect by struct_mutex, we would
mark the individual components as not-busy without any locking, leading
to potential confusion and missed powersaving (or even performance
loss). Move the softirq accesses to an atomic and defer the actual
update until we
The principle of intel_mark_busy() is that we want to spot the
transition of when the display engine is being used in order to bump
powersaving modes and increase display clocks. As such it is only
important when the display is changing, i.e. when rendering to the
scanout or other sprite/plane,
Whilst marking the device as active is protect by struct_mutex, we would
mark the individual components as not-busy without any locking, leading
to potential confusion and missed powersaving (or even performance
loss). Move the softirq accesses to an atomic and defer the actual
update until we
Ignore these, wrong pair of patches.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, 2 May 2012 22:55:44 -0300, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Gen3+ is 13 bits (12:0).
Gen3+ is 13 bits (12:0), and on gen2 only (11:0). For both the high bits
are marked reserved, read-only so continue to mask them.
Signed-off-by:
On Wed, 2 May 2012 22:55:45 -0300, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
intel_wait_for_vblank uses PIPESTAT, which does not exist on Ironlake
and newer.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
Hello everyone,
I'm writing to this list, hoping not to be in the wrong place. The subject is a
GMA 3600 graphic controller which I have on a D2500CC Mini-ITX Intel board. My
operating system is Debian Wheezy with latest stable 3.3.4 kernel (GMA3600
option compiled in).
According to Intel's
At suspend time on 3.4-rc5 with SNB, we see a i915 register read
transaction aborted, presumably as the GT is powered down:
WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
gen6_gt_check_fifodbg.isra.6+0x3b/0x50 [i915]()
Hardware name: Latitude E5420
MMIO read or write has been dropped
On Thu, May 03, 2012 at 09:07:03PM +0800, Daniel J Blueman wrote:
At suspend time on 3.4-rc5 with SNB, we see a i915 register read
transaction aborted, presumably as the GT is powered down:
WARNING: at drivers/gpu/drm/i915/i915_drv.c:398
gen6_gt_check_fifodbg.isra.6+0x3b/0x50 [i915]()
On Wed, May 2, 2012 at 10:55 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
While testing with the intel_infoframes tool on gen4, I see that when
video DIP is disabled, what we write to the DATA memory is not exactly
what we read back later. This
gpu reset is a very important piece of our infrastructure.
Unfortunately we only really it test by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one of the rather complicated pieces of code we
have, consisting of
- hang
On Tue, 24 Apr 2012 17:37:56 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Apr 24, 2012 at 04:11:43PM +0100, Chris Wilson wrote:
On Tue, 24 Apr 2012 15:41:37 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
the only places we actually need the crtc timings is in the mode_set
On Thu, May 03, 2012 at 12:35:21PM +0100, Chris Wilson wrote:
The principle of intel_mark_busy() is that we want to spot the
transition of when the display engine is being used in order to bump
powersaving modes and increase display clocks. As such it is only
important when the display is
The principle of intel_mark_busy() is that we want to spot the
transition of when the display engine is being used in order to bump
powersaving modes and increase display clocks. As such it is only
important when the display is changing, i.e. when rendering to the
scanout or other sprite/plane,
Our handling of the crtc timing computation has been nicely
cargo-culted with calls to drm_mode_set_crtcinfo sprinkled all over
the place. But with
commit f9bef081c3c3f77bec54454872e98d3ec635756f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sun Apr 15 19:53:19 2012 +0200
drm/i915:
On Thu, Apr 26, 2012 at 11:28:42AM +0100, Chris Wilson wrote:
Every time we use the device after a period of idleness, check that the
power management setup is still sane. This is to workaround a bug
whereby it seems that we begin suppressing power management interrupts,
preventing
Hi Dave,
One more regression fix and a 3 small patches:
- Paulo fixed the hdmi infoframe regression on gm45 introduced in 3.2 by
Jesse.
- snb/ilk has a nice debug register where the hw can tell us when it
dropped writes and we've added a WARN in 3.4 when this happens. This
caught code which
Hi,
the tearing video issue with XV output seemed to be fixed on my old
computer with i945 graphics at some point. Last year I upgraded to a
box with i5-2400, and got bitten again by tearing video. Currently I
use kernel 3.4-rc5, Xserver 1.12 and xorg-intel 2.18. I use gnome3 and
gnome-shell on
On Thu, May 03, 2012 at 08:09:09PM +0200, tino.keitel+x...@tikei.de wrote:
Hi,
the tearing video issue with XV output seemed to be fixed on my old
computer with i945 graphics at some point. Last year I upgraded to a
box with i5-2400, and got bitten again by tearing video. Currently I
use
On Thu, May 3, 2012 at 9:48 AM, Daniel Vetter daniel.vet...@ffwll.chwrote:
gpu reset is a very important piece of our infrastructure.
Unfortunately we only really it test by actually hanging the gpu,
which often has bad side-effects for the entire system. And the gpu
hang handling code is one
On Thu, May 03, 2012 at 20:43:01 +0200, Daniel Vetter wrote:
[...]
The only way to get tear-free screen updates on snb is with pageflips,
which requires a opengl compositor
Thanks. What do you mean with opengl compositor? Isn't the Gnome3
desktop providing this?
Regards,
Tino
On Thu, May 03, 2012 at 09:34:28PM +0200, Tino Keitel wrote:
On Thu, May 03, 2012 at 20:43:01 +0200, Daniel Vetter wrote:
[...]
The only way to get tear-free screen updates on snb is with pageflips,
which requires a opengl compositor
Thanks. What do you mean with opengl compositor?
On Thu, May 03, 2012 at 21:46:37 +0200, Daniel Vetter wrote:
On Thu, May 03, 2012 at 09:34:28PM +0200, Tino Keitel wrote:
On Thu, May 03, 2012 at 20:43:01 +0200, Daniel Vetter wrote:
[...]
The only way to get tear-free screen updates on snb is with pageflips,
which requires a
On Wed, May 2, 2012 at 10:55 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
On Wed, May 2, 2012 at 10:55 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
That's what the VIDEO_DIP_CTL documentation says we need to do. Except
when it's the AVI InfoFrame and we're ironlake_write_infoframe.
Signed-off-by: Paulo Zanoni
On Wed, May 2, 2012 at 10:55 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
--
Eugeni Dodonov
http://eugeni.dodonov.net/
On Wed, May 2, 2012 at 10:55 PM, Paulo Zanoni przan...@gmail.com wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
This will allow us to disable an infoframe without changing its
frequency.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
I think the subject should be 'Break
On 05/03/2012 03:51 PM, tino.keitel+x...@tikei.de wrote:
On Thu, May 03, 2012 at 21:46:37 +0200, Daniel Vetter wrote:
On Thu, May 03, 2012 at 09:34:28PM +0200, Tino Keitel wrote:
On Thu, May 03, 2012 at 20:43:01 +0200, Daniel Vetter wrote:
[...]
The only way to get tear-free screen updates
I have a DG33TL motherboard with G33 chipset. I have two LCD monitors with
native
resolutions of 1280x1024 (connected to analog output) and 1650x1050 (connected
to
DVI/SDVO output). I am running Fedora 16 (x86_64, KDE Desktop) on this
hardware.
Monitors are configured to appear side by side
On Thu, 03 May 2012 17:23:09 -0400, Adam Jackson a...@redhat.com wrote:
On 5/3/12 1:11 PM, Andriy Gapon wrote:
Can the problem be related to some 2048x2048 limitation in G33?
Yes, the problem is exactly that limitation.
Except that even UXA on gen3 has workarounds for that limit, so
On Thu, May 03, 2012 at 16:32:47 -0400, Chun-Yu Shei wrote:
On 05/03/2012 03:51 PM, tino.keitel+x...@tikei.de wrote:
On Thu, May 03, 2012 at 21:46:37 +0200, Daniel Vetter wrote:
On Thu, May 03, 2012 at 09:34:28PM +0200, Tino Keitel wrote:
On Thu, May 03, 2012 at 20:43:01 +0200, Daniel Vetter
34 matches
Mail list logo
