[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

xserver-xorg-video-intel: Changes to 'ubuntu-precise'



 debian/changelog                                                  |    8 
 debian/patches/106-uxa-only-consider-attached-outputs-valid.patch |  106 ++++++++++
 debian/patches/series                                             |    1 
 3 files changed, 115 insertions(+)

New commits:
commit a18a37edf4312048151e94837c72532be5e2644d
Author: Timo Aaltonen <tjaalton@ubuntu.com>
Date:   Fri Aug 24 13:10:54 2012 +0300

    Add 106-uxa-only-consider-attached-outputs-valid.patch
    
    two upstream commits merged together that fix GPU hangs on resume, due
    to outputs getting marked valid before the kernel reports them
    attached.

diff --git a/debian/changelog b/debian/changelog
index aaf3196..cb3b106 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+xserver-xorg-video-intel (2:2.17.0-1ubuntu4.1.1) UNRELEASED; urgency=low
+
+  * Add 106-uxa-only-consider-attached-outputs-valid.patch, two upstream
+    commits merged together that fix GPU hangs on resume, due to outputs
+    getting marked valid before the kernel reports them attached.
+
+ -- Timo Aaltonen <tjaalton@ubuntu.com>  Fri, 24 Aug 2012 13:07:41 +0300
+
 xserver-xorg-video-intel (2:2.17.0-1ubuntu4.1) precise-proposed; urgency=low
 
   * Add 105_reduce_ivb_gt1_max_thread_count.patch, backported commit
diff --git a/debian/patches/106-uxa-only-consider-attached-outputs-valid.patch b/debian/patches/106-uxa-only-consider-attached-outputs-valid.patch
new file mode 100644
index 0000000..bf92a24
--- /dev/null
+++ b/debian/patches/106-uxa-only-consider-attached-outputs-valid.patch
@@ -0,0 +1,106 @@
+commit 3f3bde4f0c72f6f31aae322bcdc20b95eade6631
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date:   Thu May 24 11:58:46 2012 +0100
+
+    uxa: Only consider an output valid if the kernel reports it attached
+    
+    Reported-by: Kyle Hill <kyle.hill@tacomafia.net>
+    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50078
+    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+
+commit c4eb5528a456b65c673f7c984d14a622ac67cdca
+Author: Chris Wilson <chris@chris-wilson.co.uk>
+Date:   Tue Jun 5 16:04:16 2012 +0100
+
+    uxa: Check for DPMS off before scheduling a WAIT_ON_EVENT
+    
+    Regression from commit 3f3bde4f0c72f6f31aae322bcdc20b95eade6631
+    Author: Chris Wilson <chris@chris-wilson.co.uk>
+    Date:   Thu May 24 11:58:46 2012 +0100
+    
+        uxa: Only consider an output valid if the kernel reports it attached
+    
+    When backporting from SNA, a key difference that UXA does not track DPMS
+    state in its enabled flag and that a DPMS off CRTC is still bound to the
+    fb. So we do need to rescan the outputs and check that we have a
+    connector enabled *and* the pipe is running prior to emitting a scanline
+    wait.
+    
+    References: https://bugs.freedesktop.org/show_bug.cgi?id=50668
+    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
+
+--- a/src/intel_display.c
++++ b/src/intel_display.c
+@@ -1716,6 +1716,43 @@
+ 	return intel_crtc->pipe;
+ }
+ 
++Bool intel_crtc_on(xf86CrtcPtr crtc)
++{
++       ScrnInfoPtr scrn = crtc->scrn;
++       xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(crtc->scrn);
++       struct intel_crtc *intel_crtc = crtc->driver_private;
++       drmModeCrtcPtr drm_crtc;
++       Bool ret;
++       int i;
++
++       if (!crtc->enabled)
++               return FALSE;
++
++       /* Kernel manages CRTC status based on output config */
++       ret = FALSE;
++       for (i = 0; i < xf86_config->num_output; i++) {
++               xf86OutputPtr output = xf86_config->output[i];
++               if (output->crtc == crtc &&
++                   intel_output_dpms_status(output) == DPMSModeOn) {
++                       ret = TRUE;
++                       break;
++               }
++       }
++       if (!ret)
++               return FALSE;
++
++       /* And finally check with the kernel that the fb is bound */
++       drm_crtc = drmModeGetCrtc(intel_crtc->mode->fd, crtc_id(intel_crtc));
++       if (drm_crtc == NULL)
++               return FALSE;
++
++       ret = (drm_crtc->mode_valid &&
++              intel_crtc->mode->fb_id == drm_crtc->buffer_id);
++       free(drm_crtc);
++
++       return ret;
++}
++
+ static PixmapPtr
+ intel_create_pixmap_for_fbcon(ScrnInfoPtr scrn)
+ {
+--- a/src/intel_driver.c
++++ b/src/intel_driver.c
+@@ -789,26 +789,6 @@
+ 	return TRUE;
+ }
+ 
+-Bool intel_crtc_on(xf86CrtcPtr crtc)
+-{
+-	ScrnInfoPtr scrn = crtc->scrn;
+-	xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
+-	int i;
+-
+-	if (!crtc->enabled)
+-		return FALSE;
+-
+-	/* Kernel manages CRTC status based out output config */
+-	for (i = 0; i < xf86_config->num_output; i++) {
+-		xf86OutputPtr output = xf86_config->output[i];
+-		if (output->crtc == crtc &&
+-		    intel_output_dpms_status(output) == DPMSModeOn)
+-			return TRUE;
+-	}
+-
+-	return FALSE;
+-}
+-
+ static void
+ intel_flush_callback(CallbackListPtr *list,
+ 		     pointer user_data, pointer call_data)
diff --git a/debian/patches/series b/debian/patches/series
index e591a7f..45470d9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
 103_fix_uxa_fill_spans.patch
 104_uxa_fix_gtt_mapping_limits.patch
 105_reduce_ivb_gt1_max_thread_count.patch
+106-uxa-only-consider-attached-outputs-valid.patch


Reply to: