Re: [Intel-gfx] [PATCH] drm/i915: rip out intel_dpio_write again
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 wrote: On Wed, 2 May 2012 11:06:23 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Unfortunately it looks like further vlv patches are still stalled due to fried hw, and too many people are a bit annoyed about the unused function warning. It is my preference that you never merge code which you know will produce a warning. I still stand by adding a __used for intermediate patches. Well he could have just merged the other patches too, but nooo... Twasn't a shot at you... shot was fired at Daniel (although if you *did* but in __used I wouldn't have had to shoot at Daniel). Meh ok you can kill this function. Vijay will be re-posting the code that uses it (and adds it again) once he gets his hardware, unless I beat him to it (still waiting on a new CPU). I guess that counts as an ack ... patch merged for -next. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/12] drm/i915: enable dip before writing data on gen4
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 problems that can be bisected to drm/i915: fix ILK+ infoframe support. That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Fixes fd.o bug 43947. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Cc: sta...@kernel.org Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Picked up for -fixes, thanks for the patch. I've changed the commit message a bit to make it clearer that this fixes a regression and to make the offending commit stand out more. For consistency when citing a commit that introduced a regression, please paste the output of git show up to the headline of the commit. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] seqno
---
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 +3599,8 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
*/
args-busy = obj-active;
if (args-busy) {
+ u32 seqno;
+
/* Unconditionally flush objects, even when the gpu still uses
this
* object. Userspace calling this function indicates that it
wants to
* use this buffer rather sooner than later, so issuing the
required
@@ -3617,7 +3619,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
* timer or when irqs are actually unmasked, and our
* working set ends up being larger than required.
*/
- i915_gem_retire_requests_ring(obj-ring, 0);
+ seqno = obj-last_rendering_seqno;
+ if (!i915_seqno_passed(obj-ring-last_seqno, seqno))
+ seqno = 0;
+ i915_gem_retire_requests_ring(obj-ring, seqno);
args-busy = obj-active;
}
--
1.7.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Avoid concurrent access when marking the device as idle/busy
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 acquire the struct_mutex in the worker.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |3 +-
drivers/gpu/drm/i915/intel_display.c | 86 +++---
drivers/gpu/drm/i915/intel_drv.h |1 -
4 files changed, 42 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ee25584..ee402c5 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1701,7 +1701,7 @@ bool i915_gpu_busy(void)
goto out_unlock;
dev_priv = i915_mch_dev;
- ret = dev_priv-busy;
+ ret = !!(dev_priv-busy (1 31));
out_unlock:
spin_unlock(mchdev_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3815d9a..47e5722 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -778,7 +778,8 @@ typedef struct drm_i915_private {
int lvds_downclock;
struct work_struct idle_work;
struct timer_list idle_timer;
- bool busy;
+ unsigned busy;
+ atomic_t idle;
u16 orig_clock;
int child_dev_num;
struct child_device_config *child_dev;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d5aa2d2..1428e6e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5519,14 +5519,7 @@ static void intel_gpu_idle_timer(unsigned long arg)
struct drm_device *dev = (struct drm_device *)arg;
drm_i915_private_t *dev_priv = dev-dev_private;
- if (!list_empty(dev_priv-mm.active_list)) {
- /* Still processing requests, so just re-arm the timer. */
- mod_timer(dev_priv-idle_timer, jiffies +
- msecs_to_jiffies(GPU_IDLE_TIMEOUT));
- return;
- }
-
- dev_priv-busy = false;
+ atomic_set_mask(1 31, dev_priv-idle);
queue_work(dev_priv-wq, dev_priv-idle_work);
}
@@ -5535,19 +5528,9 @@ static void intel_gpu_idle_timer(unsigned long arg)
static void intel_crtc_idle_timer(unsigned long arg)
{
struct intel_crtc *intel_crtc = (struct intel_crtc *)arg;
- struct drm_crtc *crtc = intel_crtc-base;
- drm_i915_private_t *dev_priv = crtc-dev-dev_private;
- struct intel_framebuffer *intel_fb;
+ drm_i915_private_t *dev_priv = intel_crtc-base.dev-dev_private;
- intel_fb = to_intel_framebuffer(crtc-fb);
- if (intel_fb intel_fb-obj-active) {
- /* The framebuffer is still being accessed by the GPU. */
- mod_timer(intel_crtc-idle_timer, jiffies +
- msecs_to_jiffies(CRTC_IDLE_TIMEOUT));
- return;
- }
-
- intel_crtc-busy = false;
+ atomic_set_mask(1 intel_crtc-pipe, dev_priv-idle);
queue_work(dev_priv-wq, dev_priv-idle_work);
}
@@ -5651,26 +5634,32 @@ static void intel_idle_update(struct work_struct *work)
idle_work);
struct drm_device *dev = dev_priv-dev;
struct drm_crtc *crtc;
- struct intel_crtc *intel_crtc;
-
- if (!i915_powersave)
- return;
+ unsigned idle;
mutex_lock(dev-struct_mutex);
- i915_update_gfx_val(dev_priv);
+ idle = atomic_xchg(dev_priv-idle, 0);
+ if (idle (1 31))
+ intel_sanitize_pm(dev);
+ if (!i915_powersave)
+ goto unlock;
+
+ i915_update_gfx_val(dev_priv);
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
+ struct intel_crtc *intel_crtc;
+
/* Skip inactive CRTCs */
if (!crtc-fb)
continue;
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc-busy)
+ if (idle (1 intel_crtc-pipe))
intel_decrease_pllclock(crtc);
}
-
+unlock:
+ dev_priv-busy = ~idle;
mutex_unlock(dev-struct_mutex);
}
@@ -5687,38 +5676,42 @@ static void intel_idle_update(struct work_struct *work)
void intel_mark_busy(struct drm_device *dev, struct drm_i915_gem_object *obj)
{
drm_i915_private_t *dev_priv = dev-dev_private;
- struct drm_crtc *crtc = NULL;
- struct intel_framebuffer *intel_fb;
- struct intel_crtc *intel_crtc;
-
- if (!drm_core_check_feature(dev, DRIVER_MODESET))
- return;
+ struct drm_crtc *crtc;
+ unsigned busy = 0;
- if (!dev_priv-busy) {
+ if
[Intel-gfx] [PATCH 2/2] drm/i915: Limit calling mark-busy only for potential scanouts
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, and these are characterised by being pinned. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- drivers/gpu/drm/i915/i915_gem_execbuffer.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 451efa3..10bb075 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -979,7 +979,8 @@ i915_gem_execbuffer_move_to_active(struct list_head *objects, obj-pending_gpu_write = true; list_move_tail(obj-gpu_write_list, ring-gpu_write_list); - intel_mark_busy(ring-dev, obj); + if (obj-pin_count) /* check for potential scanout */ + intel_mark_busy(ring-dev, obj); } trace_i915_gem_object_change_domain(obj, old_read, old_write); -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Avoid concurrent access when marking the device as idle/busy
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 acquire the struct_mutex in the worker.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/i915/i915_drv.h |3 +-
drivers/gpu/drm/i915/intel_display.c | 86 +++---
drivers/gpu/drm/i915/intel_drv.h |1 -
4 files changed, 42 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index ee25584..ee402c5 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1701,7 +1701,7 @@ bool i915_gpu_busy(void)
goto out_unlock;
dev_priv = i915_mch_dev;
- ret = dev_priv-busy;
+ ret = !!(dev_priv-busy (1 31));
out_unlock:
spin_unlock(mchdev_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3815d9a..47e5722 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -778,7 +778,8 @@ typedef struct drm_i915_private {
int lvds_downclock;
struct work_struct idle_work;
struct timer_list idle_timer;
- bool busy;
+ unsigned busy;
+ atomic_t idle;
u16 orig_clock;
int child_dev_num;
struct child_device_config *child_dev;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d5aa2d2..1428e6e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5519,14 +5519,7 @@ static void intel_gpu_idle_timer(unsigned long arg)
struct drm_device *dev = (struct drm_device *)arg;
drm_i915_private_t *dev_priv = dev-dev_private;
- if (!list_empty(dev_priv-mm.active_list)) {
- /* Still processing requests, so just re-arm the timer. */
- mod_timer(dev_priv-idle_timer, jiffies +
- msecs_to_jiffies(GPU_IDLE_TIMEOUT));
- return;
- }
-
- dev_priv-busy = false;
+ atomic_set_mask(1 31, dev_priv-idle);
queue_work(dev_priv-wq, dev_priv-idle_work);
}
@@ -5535,19 +5528,9 @@ static void intel_gpu_idle_timer(unsigned long arg)
static void intel_crtc_idle_timer(unsigned long arg)
{
struct intel_crtc *intel_crtc = (struct intel_crtc *)arg;
- struct drm_crtc *crtc = intel_crtc-base;
- drm_i915_private_t *dev_priv = crtc-dev-dev_private;
- struct intel_framebuffer *intel_fb;
+ drm_i915_private_t *dev_priv = intel_crtc-base.dev-dev_private;
- intel_fb = to_intel_framebuffer(crtc-fb);
- if (intel_fb intel_fb-obj-active) {
- /* The framebuffer is still being accessed by the GPU. */
- mod_timer(intel_crtc-idle_timer, jiffies +
- msecs_to_jiffies(CRTC_IDLE_TIMEOUT));
- return;
- }
-
- intel_crtc-busy = false;
+ atomic_set_mask(1 intel_crtc-pipe, dev_priv-idle);
queue_work(dev_priv-wq, dev_priv-idle_work);
}
@@ -5651,26 +5634,32 @@ static void intel_idle_update(struct work_struct *work)
idle_work);
struct drm_device *dev = dev_priv-dev;
struct drm_crtc *crtc;
- struct intel_crtc *intel_crtc;
-
- if (!i915_powersave)
- return;
+ unsigned idle;
mutex_lock(dev-struct_mutex);
- i915_update_gfx_val(dev_priv);
+ idle = atomic_xchg(dev_priv-idle, 0);
+ if (idle (1 31))
+ intel_sanitize_pm(dev);
+ if (!i915_powersave)
+ goto unlock;
+
+ i915_update_gfx_val(dev_priv);
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
+ struct intel_crtc *intel_crtc;
+
/* Skip inactive CRTCs */
if (!crtc-fb)
continue;
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc-busy)
+ if (idle (1 intel_crtc-pipe))
intel_decrease_pllclock(crtc);
}
-
+unlock:
+ dev_priv-busy = ~idle;
mutex_unlock(dev-struct_mutex);
}
@@ -5687,38 +5676,42 @@ static void intel_idle_update(struct work_struct *work)
void intel_mark_busy(struct drm_device *dev, struct drm_i915_gem_object *obj)
{
drm_i915_private_t *dev_priv = dev-dev_private;
- struct drm_crtc *crtc = NULL;
- struct intel_framebuffer *intel_fb;
- struct intel_crtc *intel_crtc;
-
- if (!drm_core_check_feature(dev, DRIVER_MODESET))
- return;
+ struct drm_crtc *crtc;
+ unsigned busy = 0;
- if (!dev_priv-busy) {
+ if
Re: [Intel-gfx] [PATCH 1/2] seqno
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
Re: [Intel-gfx] [PATCH 02/12] drm/i915: DSL_LINEMASK is 12 bits only on gen2
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: Paulo Zanoni paulo.r.zan...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -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
Re: [Intel-gfx] [PATCH 03/12] drm/i915: implement ironlake_wait_for_vblank
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
---
drivers/gpu/drm/i915/intel_display.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 613f871..a2617b2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -806,6 +806,32 @@ intel_find_pll_g4x_dp(const intel_limit_t *limit, struct
drm_crtc *crtc,
return true;
}
+static void ironlake_wait_for_vblank(struct drm_device *dev, int pipe)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 vblank_start, line;
+ u32 dsl_reg = PIPEDSL(pipe);
+ u32 pipeconf = I915_READ(PIPECONF(pipe));
+
+ if (!((pipeconf PIPECONF_ENABLE)
+ (pipeconf I965_PIPECONF_ACTIVE)))
+ return;
+
+ vblank_start = I915_READ(VBLANK(pipe)) 0x1FFF;
+
+ if (pipeconf PIPECONF_INTERLACE_MASK)
+ vblank_start = 1;
+
+ line = I915_READ(dsl_reg) DSL_LINEMASK_GEN3;
+
+ if (line = vblank_start)
+ return;
The caller expects for at least 1 frame to have passed, the
documentation tends to refer to the registers being latched until the
next vblank. As we don't know precisely when those registers are copied,
we need to wait one complete cycle to be sure that we don't return too
early.
Or maybe I'm being too paranoid. Actually, with modesetting one can
never be too paranoid.
-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
[Intel-gfx] NM10 chipset with GMA3600
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 positive reputation for supporting open source drivers, I admit I didn't do a thorough research on this specific chipset *before* buying the mainboard (and that's my fault). Only later, being stuck to a Vesa driver with wrong screen ratio and resolution, I discovered that GMA3600 isn't supported (yet). My question is: will it ever be, as GMA3150 is? Or I'd better switch to an H67 chipset with HD controller? Many, many thanks. Best regards, Andrew ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [3.4-rc5, SNB] transaction abort when suspending
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 Modules linked in: brd dm_crypt dm_mod kvm_intel kvm coretemp microcode uvcvideo videobuf2_core videodev videobuf2_vmalloc videobuf2_memops iwlwifi binfmt_misc btrfs i915 cfbcopyarea video cfbimgblt cfbfillrect Pid: 23468, comm: kworker/u:13 Tainted: GW3.4.0-rc5-debug #10 Call Trace: [8103da3a] warn_slowpath_common+0x7a/0xb0 [8103db11] warn_slowpath_fmt+0x41/0x50 [a0020cd5] ? i915_read32+0x65/0xb0 [i915] [a002055b] gen6_gt_check_fifodbg.isra.6+0x3b/0x50 [i915] [a00209e9] __gen6_gt_force_wake_put+0x19/0x20 [i915] [a0020d09] i915_read32+0x99/0xb0 [i915] [a0024275] i915_update_gfx_val+0x85/0xe0 [i915] [a0041c4b] intel_idle_update+0x4b/0xb0 [i915] [81058e96] process_one_work+0x1b6/0x460 [81058e38] ? process_one_work+0x158/0x460 [a0041c00] ? intel_decrease_pllclock+0x130/0x130 [i915] [81059db4] worker_thread+0x124/0x2d0 [81059c90] ? manage_workers.isra.25+0x120/0x120 [8105ee3e] kthread+0x8e/0xa0 [815b6314] kernel_thread_helper+0x4/0x10 [81069977] ? finish_task_switch+0x77/0x100 [815b455b] ? _raw_spin_unlock_irq+0x2b/0x50 [815b49d9] ? retint_restore_args+0xe/0xe [8105edb0] ? __init_kthread_worker+0x70/0x70 [815b6310] ? gs_change+0xb/0xb Thanks, Daniel -- Daniel J Blueman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [3.4-rc5, SNB] transaction abort when suspending
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]() Hardware name: Latitude E5420 MMIO read or write has been dropped Modules linked in: brd dm_crypt dm_mod kvm_intel kvm coretemp microcode uvcvideo videobuf2_core videodev videobuf2_vmalloc videobuf2_memops iwlwifi binfmt_misc btrfs i915 cfbcopyarea video cfbimgblt cfbfillrect Pid: 23468, comm: kworker/u:13 Tainted: GW3.4.0-rc5-debug #10 Call Trace: [8103da3a] warn_slowpath_common+0x7a/0xb0 [8103db11] warn_slowpath_fmt+0x41/0x50 [a0020cd5] ? i915_read32+0x65/0xb0 [i915] [a002055b] gen6_gt_check_fifodbg.isra.6+0x3b/0x50 [i915] [a00209e9] __gen6_gt_force_wake_put+0x19/0x20 [i915] [a0020d09] i915_read32+0x99/0xb0 [i915] [a0024275] i915_update_gfx_val+0x85/0xe0 [i915] [a0041c4b] intel_idle_update+0x4b/0xb0 [i915] [81058e96] process_one_work+0x1b6/0x460 [81058e38] ? process_one_work+0x158/0x460 [a0041c00] ? intel_decrease_pllclock+0x130/0x130 [i915] [81059db4] worker_thread+0x124/0x2d0 [81059c90] ? manage_workers.isra.25+0x120/0x120 [8105ee3e] kthread+0x8e/0xa0 [815b6314] kernel_thread_helper+0x4/0x10 [81069977] ? finish_task_switch+0x77/0x100 [815b455b] ? _raw_spin_unlock_irq+0x2b/0x50 [815b49d9] ? retint_restore_args+0xe/0xe [8105edb0] ? __init_kthread_worker+0x70/0x70 [815b6310] ? gs_change+0xb/0xb This is just ironlake code running on snb that shouldn't run on snb. Otherwise no harmful side-effects known - the warning is newly added to 3.4. Patch to fix this is on track to get merged into 3.4-rc and already landed in drm-intel-fixes as: commit e90f3b61f4432e3c5bb6b57f4b3e8d8cba747541 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Mon Apr 30 19:35:02 2012 +0100 drm/i915: Only enable IPS polling for gen5 Thanks for the report. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/12] drm/i915: enable dip before writing data on gen4
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 should fix some problems that can be bisected to drm/i915: fix ILK+ infoframe support. That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Fixes fd.o bug 43947. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Cc: sta...@kernel.org Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: add interface to simulate gpu hangs
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 detection
- error capture
- actual gpu reset
- reset of all the gem bookkeeping
- reinitialition of the entire gpu
This patch adds a debugfs to selectively stopping rings by ceasing to
update the hw tail pointer, which will result in the gpu no longer
updating it's head pointer and eventually to the hangcheck firing.
This way we can exercise the gpu hang code under controlled conditions
without a dying gpu taking down the entire systems.
Patch motivated by me forgetting to properly reinitialize ppgtt after
a gpu reset.
Usage:
echo $((1 $ringnum)) i915_ring_stop # stops one ring
echo 0x i915_ring_stop # stops all, future-proof version
then run whatever testload is desired. i915_ring_stop automatically
resets after a gpu hang is detected to avoid hanging the gpu to fast
and declaring it wedged.
v2: Incorporate feedback from Chris Wilson.
v3: Add the missing cleanup.
v4: Fix up inconsistent size of ring_stop_read vs _write, noticed by
Eugeni Dodonov.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 65 +++
drivers/gpu/drm/i915/i915_drv.c |2 +
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_ringbuffer.c |4 ++
4 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 120db46..602e100 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1585,6 +1585,64 @@ static const struct file_operations i915_wedged_fops = {
};
static ssize_t
+i915_ring_stop_read(struct file *filp,
+ char __user *ubuf,
+ size_t max,
+ loff_t *ppos)
+{
+ struct drm_device *dev = filp-private_data;
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ char buf[20];
+ int len;
+
+ len = snprintf(buf, sizeof(buf),
+ 0x%08x\n, dev_priv-stop_rings);
+
+ if (len sizeof(buf))
+ len = sizeof(buf);
+
+ return simple_read_from_buffer(ubuf, max, ppos, buf, len);
+}
+
+static ssize_t
+i915_ring_stop_write(struct file *filp,
+const char __user *ubuf,
+size_t cnt,
+loff_t *ppos)
+{
+ struct drm_device *dev = filp-private_data;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ char buf[20];
+ int val = 0;
+
+ if (cnt 0) {
+ if (cnt sizeof(buf) - 1)
+ return -EINVAL;
+
+ if (copy_from_user(buf, ubuf, cnt))
+ return -EFAULT;
+ buf[cnt] = 0;
+
+ val = simple_strtoul(buf, NULL, 0);
+ }
+
+ DRM_DEBUG_DRIVER(Stopping rings 0x%08x\n, val);
+
+ mutex_lock(dev-struct_mutex);
+ dev_priv-stop_rings = val;
+ mutex_unlock(dev-struct_mutex);
+
+ return cnt;
+}
+
+static const struct file_operations i915_ring_stop_fops = {
+ .owner = THIS_MODULE,
+ .open = simple_open,
+ .read = i915_ring_stop_read,
+ .write = i915_ring_stop_write,
+ .llseek = default_llseek,
+};
+static ssize_t
i915_max_freq_read(struct file *filp,
char __user *ubuf,
size_t max,
@@ -1884,6 +1942,11 @@ int i915_debugfs_init(struct drm_minor *minor)
i915_cache_sharing_fops);
if (ret)
return ret;
+ ret = i915_debugfs_create(minor-debugfs_root, minor,
+ i915_ring_stop,
+ i915_ring_stop_fops);
+ if (ret)
+ return ret;
return drm_debugfs_create_files(i915_debugfs_list,
I915_DEBUGFS_ENTRIES,
@@ -1902,6 +1965,8 @@ void i915_debugfs_cleanup(struct drm_minor *minor)
1, minor);
drm_debugfs_remove_files((struct drm_info_list *)
i915_cache_sharing_fops,
1, minor);
+ drm_debugfs_remove_files((struct drm_info_list *) i915_ring_stop_fops,
+1, minor);
}
#endif /* CONFIG_DEBUG_FS */
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8a98f9a..90a84f9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -800,6 +800,8 @@ int i915_reset(struct drm_device *dev, u8 flags)
if (!mutex_trylock(dev-struct_mutex))
return -EBUSY;
+ dev_priv-stop_rings = 0;
+
i915_gem_reset(dev);
Re: [Intel-gfx] [PATCH] drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo
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 function. So we can now safely rip out all the remaining calls to set_crtcinfo left in the driver and clean up this confusion. I have a little flicker of doubt because these tend to end up being passed into the core drm as well as used during modeset. Even looking through the instances of drm_mode_set_crtcinfo() in the core, I'm left no the wiser as to which functions expect crtc_* to be filled in. As far I can see the only place where set_crtcinfo() must be called is prior to the final modeset, and so the crtc_* values are only ever used on the adjusted_mode. Hence why the drm usage leaves me slightly puzzled. I guess the idea of the drm core is that every time it creates a drm mode, it also sets the timings. But afaics it never uses them, safe for the precise vblank timestamp code (but that can only run on active modes, i.e. after our mode_fixup functions have been called). The problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the timings are pretty much bogus for us anyway (at least with interlaced support). So I guess it's the drivers job that every active modes needs to have crtc timings that suits it, and with these patches we should have that. drm core doesn't seem to care about modes that just get passed around. So just capture that explanation in the commit message and get QA's seal of approval and job done. The patch itself looks good and complete afaict, so r-b with the above. -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
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Limit calling mark-busy only for potential scanouts
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 changing, i.e. when rendering to the scanout or other sprite/plane, and these are characterised by being pinned. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- drivers/gpu/drm/i915/i915_gem_execbuffer.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index 451efa3..10bb075 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -979,7 +979,8 @@ i915_gem_execbuffer_move_to_active(struct list_head *objects, obj-pending_gpu_write = true; list_move_tail(obj-gpu_write_list, ring-gpu_write_list); - intel_mark_busy(ring-dev, obj); + if (obj-pin_count) /* check for potential scanout */ + intel_mark_busy(ring-dev, obj); intel_mark_busy also controls ips power sharing on ilk, so if we have loads of batchbuffers not rendering to the a framebuffer, this might hurt performance. Another thing I've noticed is that we fail to call intel_mark_busy on pageflips, and I presume running the display at a low refresh rate instead of the expected high when e.g. displaying videos could decently confuse userspace. Care to throw in that fix, too? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Limit calling mark-busy only for potential scanouts
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, and these are characterised by being
pinned.
v2: Mark the whole device as busy on execbuffer and pageflips as well
and rebase against dinq for the minor bug fix to be immediately
applicable.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |5 -
drivers/gpu/drm/i915/intel_display.c |4
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a46ed26..60d2d75 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -967,11 +967,14 @@ i915_gem_execbuffer_move_to_active(struct list_head
*objects,
obj-pending_gpu_write = true;
list_move_tail(obj-gpu_write_list,
ring-gpu_write_list);
- intel_mark_busy(ring-dev, obj);
+ if (obj-pin_count) /* check for potential scanout */
+ intel_mark_busy(ring-dev, obj);
}
trace_i915_gem_object_change_domain(obj, old_read, old_write);
}
+
+ intel_mark_busy(ring-dev, NULL);
}
static void
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ddeb794..8a4cf37 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5537,6 +5537,9 @@ void intel_mark_busy(struct drm_device *dev, struct
drm_i915_gem_object *obj)
mod_timer(dev_priv-idle_timer, jiffies +
msecs_to_jiffies(GPU_IDLE_TIMEOUT));
+ if (obj == NULL)
+ return;
+
list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
if (!crtc-fb)
continue;
@@ -5980,6 +5983,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
goto cleanup_pending;
intel_disable_fbc(dev);
+ intel_mark_busy(ring-dev, obj);
mutex_unlock(dev-struct_mutex);
trace_i915_flip_request(intel_crtc-plane, obj);
--
1.7.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: rip out unnecessary calls to drm_mode_set_crtcinfo
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: don't clobber the special upscaling lvds timings
and
commit ca9bfa7eed20ea34e862804e62aae10eb159edbb
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sat Jan 28 14:49:20 2012 +0100
drm/i915: fixup interlaced vertical timings confusion, part 1
we now only set the crtc timing fields in the encoder-mode_fixup
(lvds only) and in crtc-mode_fixup (for everyone else). And since
commit 75c13993db592343bda1fd62f2555fea037d56bd
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sat Jan 28 23:48:46 2012 +0100
drm/i915: fixup overlay checks for interlaced modes
the only places we actually need the crtc timings is in the mode_set
function.
I guess the idea of the drm core is that every time it creates a drm
mode, it also sets the timings. But afaics it never uses them, safe
for the precise vblank timestamp code (but that can only run on active
modes, i.e. after our mode_fixup functions have been called). The
problem is that drm core always sets CRTC_INTERLACE_HALVE_V, so the
timings are pretty much bogus for us anyway (at least with interlaced
support).
So I guess it's the drivers job that every active modes needs to have
crtc timings that suits it, and with these patches we should have
that. drm core doesn't seem to care about modes that just get passed
around. Hence we can now safely rip out all the remaining calls to
set_crtcinfo left in the driver and clean up this confusion.
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c |1 -
drivers/gpu/drm/i915/intel_overlay.c |2 +-
drivers/gpu/drm/i915/intel_sdvo.c|3 ---
drivers/gpu/drm/i915/intel_tv.c |1 -
4 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0eeaa83..f2d2a5a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5281,7 +5281,6 @@ struct drm_display_mode *intel_crtc_mode_get(struct
drm_device *dev,
mode-vsync_end = ((vsync 0x) 16) + 1;
drm_mode_set_name(mode);
- drm_mode_set_crtcinfo(mode, 0);
return mode;
}
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index dab185e..d05bfe7 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -263,7 +263,7 @@ i830_activate_pipe_a(struct drm_device *dev)
DRM_DEBUG_DRIVER(Enabling pipe A in order to enable overlay\n);
mode = drm_mode_duplicate(dev, vesa_640x480);
- drm_mode_set_crtcinfo(mode, 0);
+
if (!drm_crtc_helper_set_mode(crtc-base, mode,
crtc-base.x, crtc-base.y,
crtc-base.fb))
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index c330efd..a3ccdcc 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1576,9 +1576,6 @@ end:
intel_sdvo-sdvo_lvds_fixed_mode =
drm_mode_duplicate(connector-dev, newmode);
- drm_mode_set_crtcinfo(intel_sdvo-sdvo_lvds_fixed_mode,
- 0);
-
intel_sdvo-is_lvds = true;
break;
}
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 2e626b8..3346612 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1249,7 +1249,6 @@ intel_tv_detect(struct drm_connector *connector, bool
force)
int type;
mode = reported_modes[0];
- drm_mode_set_crtcinfo(mode, 0);
if (force) {
struct intel_load_detect_pipe tmp;
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Periodically sanity check power management
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 SandyBridge+ from going into turbo mode.
This patch does have a side-effect. It removes the mark-busy for just
moving the cursor - we don't want to increase the render clock just for
the sprite, though we may want to bump the display frequency. I'd argue
that we do not, and certainly don't want to take the struct_mutex here
due to the large latencies that introduces.
References: https://bugs.freedesktop.org/show_bug.cgi?id=44006
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c |8 +++-
drivers/gpu/drm/i915/intel_drv.h |2 ++
drivers/gpu/drm/i915/intel_pm.c | 37
++
4 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6b6eb49..bf34316 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -240,6 +240,7 @@ struct drm_i915_display_funcs {
void (*update_wm)(struct drm_device *dev);
void (*update_sprite_wm)(struct drm_device *dev, int pipe,
uint32_t sprite_width, int pixel_size);
+ void (*sanitize_pm)(struct drm_device *dev);
int (*crtc_mode_set)(struct drm_crtc *crtc,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 05c6e66..40fac16 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4982,9 +4982,6 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
else
i9xx_update_cursor(crtc, base);
}
-
- if (visible)
- intel_mark_busy(dev, to_intel_framebuffer(crtc-fb)-obj);
Hm, what's the reason to drop this one here?
-Daniel
}
static int intel_crtc_cursor_set(struct drm_crtc *crtc,
@@ -5697,9 +5694,10 @@ void intel_mark_busy(struct drm_device *dev, struct
drm_i915_gem_object *obj)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return;
- if (!dev_priv-busy)
+ if (!dev_priv-busy) {
+ intel_sanitize_pm(dev);
dev_priv-busy = true;
- else
+ } else
mod_timer(dev_priv-idle_timer, jiffies +
msecs_to_jiffies(GPU_IDLE_TIMEOUT));
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index b4d39f2..a57f0fb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -351,6 +351,8 @@ void intel_plane_cleanup(struct intel_plane *plane);
extern void intel_flush_display_plane(struct drm_i915_private *dev_priv,
enum plane plane);
+void intel_sanitize_pm(struct drm_device *dev);
+
/* intel_panel.c */
extern void intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3b05ba3..1b7cc51 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2938,6 +2938,41 @@ void intel_init_clock_gating(struct drm_device *dev)
dev_priv-display.init_pch_clock_gating(dev);
}
+static void gen6_sanitize_pm(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 limits, delay, old;
+
+ gen6_gt_force_wake_get(dev_priv);
+
+ old = limits = I915_READ(GEN6_RP_INTERRUPT_LIMITS);
+ /* Make sure we continue to get interrupts
+ * until we hit the minimum or maximum frequencies.
+ */
+ limits = ~(0x3f 16 | 0x3f 24);
+ delay = dev_priv-cur_delay;
+ if (delay dev_priv-max_delay)
+ limits |= (dev_priv-max_delay 0x3f) 24;
+ if (delay dev_priv-min_delay)
+ limits |= (dev_priv-min_delay 0x3f) 16;
+
+ if (old != limits) {
+ DRM_ERROR(Power management discrepancy:
GEN6_RP_INTERRUPT_LIMITS expected %08x, was %08x\n,
+ limits, old);
+ I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
+ }
+
+ gen6_gt_force_wake_put(dev_priv);
+}
+
+void intel_sanitize_pm(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-display.sanitize_pm)
+ dev_priv-display.sanitize_pm(dev);
+}
+
/* Set up chip specific power management-related functions */
void
[Intel-gfx] [PULL] drm-intel-fixes
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 shouldn't run on gen6+, the two patches by Chris fix this. No known bad side-effects besides the WARN backtrace (and in a way, not really a regression fix, but still). - Fix up 2 broken no-lvds quirks added in 3.4 - I've figured shipping with broken quirk entries is pointless, and these are easily revertable. Yours, Daniel The following changes since commit 69964ea4c7b68c9399f7977aa5b9aa6539a6a98a: Linux 3.4-rc5 (2012-04-29 15:19:10 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes for you to fetch changes up to c1230df7e19e0f27655c0eb9d966c7e03be7cc50: drm/i915: enable dip before writing data on gen4 (2012-05-03 15:55:38 +0200) Chris Wilson (2): drm/i915: Do not read non-existent DPLL registers on PCH hardware drm/i915: Only enable IPS polling for gen5 Marc Gariepy (1): fixing dmi match for hp t5745 and hp st5747 thin client Paulo Zanoni (1): drm/i915: enable dip before writing data on gen4 drivers/gpu/drm/i915/i915_debugfs.c |3 +++ drivers/gpu/drm/i915/i915_dma.c | 15 ++- drivers/gpu/drm/i915/intel_display.c |9 + drivers/gpu/drm/i915/intel_hdmi.c|2 +- drivers/gpu/drm/i915/intel_lvds.c|4 ++-- 5 files changed, 21 insertions(+), 12 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Tearing video on Sandy Bridge
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 my desktop, and tried several players (mplayer, vlc, mythtv). Am I just doing something wrong, or is smooth video playback not the scope of the Sandy Bridge development? Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tearing video on Sandy Bridge
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 kernel 3.4-rc5, Xserver 1.12 and xorg-intel 2.18. I use gnome3 and gnome-shell on my desktop, and tried several players (mplayer, vlc, mythtv). Am I just doing something wrong, or is smooth video playback not the scope of the Sandy Bridge development? We used scanline waits embedded in the gpu command stream to achieve tear-free video. On snb hw designers killed that feature :( The only way to get tear-free screen updates on snb is with pageflips, which requires a opengl compositor (and wayland if you have more than one screen). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: add interface to simulate gpu hangs
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 of the rather complicated pieces of code we have, consisting of - hang detection - error capture - actual gpu reset - reset of all the gem bookkeeping - reinitialition of the entire gpu This patch adds a debugfs to selectively stopping rings by ceasing to update the hw tail pointer, which will result in the gpu no longer updating it's head pointer and eventually to the hangcheck firing. This way we can exercise the gpu hang code under controlled conditions without a dying gpu taking down the entire systems. Patch motivated by me forgetting to properly reinitialize ppgtt after a gpu reset. Usage: echo $((1 $ringnum)) i915_ring_stop # stops one ring echo 0x i915_ring_stop # stops all, future-proof version then run whatever testload is desired. i915_ring_stop automatically resets after a gpu hang is detected to avoid hanging the gpu to fast and declaring it wedged. v2: Incorporate feedback from Chris Wilson. v3: Add the missing cleanup. v4: Fix up inconsistent size of ring_stop_read vs _write, noticed by Eugeni Dodonov. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tearing video on Sandy Bridge
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 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tearing video on Sandy Bridge
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? Isn't the Gnome3 desktop providing this? Well, it needs to do vsync'ed updates, and to work correctly, the client also needs to do dri2 buffer swaps. Dunno where to set the former in gnome 3, for the later try a opengl output plugin (or libva). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tearing video on Sandy Bridge
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 opengl compositor Thanks. What do you mean with opengl compositor? Isn't the Gnome3 desktop providing this? Well, it needs to do vsync'ed updates, and to work correctly, the client Is this in the dri config file? Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/12] drm/i915: mask the video DIP port select
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/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: disable the infoframe before changing it
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 paulo.r.zan...@intel.com Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com val = ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */ val |= intel_infoframe_index(frame); + if (frame-type == DIP_TYPE_AVI) + val |= VIDEO_DIP_ENABLE_AVI; + else + val = ~intel_infoframe_enable(frame); + Maybe adding a comment here saying why we have this on Ironlake as well? -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915: mask the video DIP frequency when changing it
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/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/12] drm/i915: break intel_infoframe_flags into _enable and _index
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 intel_infoframe_flags into _enable and _frequency', no? And by looking at what this does, perhaps the 2nd function could be named intel_infoframe_freq_vsync or intel_infoframe_vsync instead? But besides that: Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tearing video on Sandy Bridge
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 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? Well, it needs to do vsync'ed updates, and to work correctly, the client Is this in the dri config file? I've had tear-free video (finally!) in GNOME 3 for a while now, using the following in my ~/.xsession (and launching that from GDM instead of GNOME directly): CLUTTER_PAINT=disable-clipped-redraws:disable-culling /etc/X11/Sessions/Gnome You may have to adjust the /etc/X11/Sessions/Gnome depending on your distribution (I'm on Gentoo). Hope that helps, Chun-Yu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] g33 + dual head = problems
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 (for a total of 2960x1050), virtual size is (auto-)configured to 4096 x 4096. The setup works OK as long as I do not enable any form of KDE desktop effects. If I enable either OpenGL or XRender effects, then I start to get massive screen corruptions. In addition, in OpenGL mode the desktop becomes painfully slow. Is there any hope to get the effects working via some configuration tweaks or through updating the software? Can the problem be related to some 2048x2048 limitation in G33? Xorg.log is here: http://paste.lisp.org/display/129287 I can provide any additional information required. Thank you. -- Andriy Gapon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] g33 + dual head = problems
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 XRender based desktop effects should, in theory, work. -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
Re: [Intel-gfx] Tearing video on Sandy Bridge
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 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? Well, it needs to do vsync'ed updates, and to work correctly, the client Is this in the dri config file? I've had tear-free video (finally!) in GNOME 3 for a while now, using the following in my ~/.xsession (and launching that from GDM instead of GNOME directly): CLUTTER_PAINT=disable-clipped-redraws:disable-culling /etc/X11/Sessions/Gnome Thanks, I'll try that. When I goggled for that, I also found people using CLUTTER_VBLANK=True. Regards, Tino ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
