Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Hi,
On Wed, Jul 04, 2012 at 10:39:49AM -0500, Jonathan Nieder wrote:
Hi again,
Peter Colberg wrote:
cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit
How about the attached patch --- does it work against the linux-3.2.y
branch?
Grateful,
Jonathan
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Thu, 21 Jun 2012 15:13:50 -0700
Subject: drm/i915: prefer wide slow to fast narrow in DP configs
commit 684aaa646f90f5ee07799d52d0735625756e607b upstream.
High frequency link configurations have the potential to cause trouble
with long and/or cheap cables, so prefer slow and wide configurations
instead. This patch has the potential to cause trouble for eDP
configurations that lie about available lanes, so if we run into that we
can make it conditional on eDP.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
Tested-by: pe...@colberg.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d4c4937067fb..fae2050324bc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -708,8 +708,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
bpp = adjusted_mode-private_flags INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
- for (lane_count = 1; lane_count = max_lane_count; lane_count = 1) {
- for (clock = 0; clock = max_clock; clock++) {
+ for (clock = 0; clock = max_clock; clock++) {
+ for (lane_count = 1; lane_count = max_lane_count; lane_count
= 1) {
int link_avail =
intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
if (intel_dp_link_required(mode-clock, bpp)
--
1.7.11.rc3
I tested upstream linux 3.2.23 with the above patch applied, and
the display is working fine, i.e. it comes up in maximum, native
resolution even after power-cycling the display.
Regards,
Peter
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
tags 658662 = upstream patch
quit
Peter Colberg wrote:
On Wed, Jul 04, 2012 at 10:39:49AM -0500, Jonathan Nieder wrote:
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Thu, 21 Jun 2012 15:13:50 -0700
Subject: drm/i915: prefer wide slow to fast narrow in DP configs
[...]
I tested upstream linux 3.2.23 with the above patch applied, and
the display is working fine, i.e. it comes up in maximum, native
resolution even after power-cycling the display.
Nice to hear.
The patch is in linux-next but still not in Linus's tree, so I guess
we'll have to wait before this can be applied to the 3.2.y tree.
Kernel team: please consider the attached patch for wheezy in the
meantime.
Thanks,
Jonathan
Index:
debian/patches/bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
===
---
debian/patches/bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
(revision 0)
+++
debian/patches/bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
(working copy)
@@ -0,0 +1,39 @@
+From: Jesse Barnes jbar...@virtuousgeek.org
+Date: Thu, 21 Jun 2012 15:13:50 -0700
+Subject: drm/i915: prefer wide slow to fast narrow in DP configs
+
+commit 2514bc510d0c3aadcc5204056bb440fa36845147 upstream.
+
+High frequency link configurations have the potential to cause trouble
+with long and/or cheap cables, so prefer slow and wide configurations
+instead. This patch has the potential to cause trouble for eDP
+configurations that lie about available lanes, so if we run into that we
+can make it conditional on eDP.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
+Tested-by: pe...@colberg.org
+Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
+Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
+Signed-off-by: Jonathan Nieder jrnie...@gmail.com
+---
+ drivers/gpu/drm/i915/intel_dp.c |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
+index d4c4937067fb..fae2050324bc 100644
+--- a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
+@@ -708,8 +708,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
+
+ bpp = adjusted_mode-private_flags INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
+
+- for (lane_count = 1; lane_count = max_lane_count; lane_count = 1) {
+- for (clock = 0; clock = max_clock; clock++) {
++ for (clock = 0; clock = max_clock; clock++) {
++ for (lane_count = 1; lane_count = max_lane_count; lane_count
= 1) {
+ int link_avail =
intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
+
+ if (intel_dp_link_required(mode-clock, bpp)
+--
+1.7.10.4
+
Index: debian/patches/series
===
--- debian/patches/series (revision 19261)
+++ debian/patches/series (working copy)
@@ -379,3 +379,5 @@
features/all/fermi-accel/drm-nouveau-oops-increase-channel-dispc_vma-to-4.patch
features/all/fermi-accel/drm-nvd0-disp-ignore-clock-set-if-no-pclk.patch
features/all/fermi-accel/drm-nouveau-bump-version-to-1.0.0.patch
+
+bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
Index: debian/changelog
===
--- debian/changelog(revision 19261)
+++ debian/changelog(working copy)
@@ -38,6 +38,10 @@
- Refactor sub-channel use
- Bump version to 1.0.0
+ [ Jonathan Nieder ]
+ * [x86] drm/i915: prefer wide slow to fast narrow in DP configs
+(Closes: #658662)
+
-- Ben Hutchings b...@decadent.org.uk Fri, 29 Jun 2012 15:01:22 +0100
linux (3.2.21-3) unstable; urgency=low
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
tags 658662 + upstream patch moreinfo
quit
Hi again,
Peter Colberg wrote:
cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit
How about the attached patch --- does it work against the linux-3.2.y
branch?
Grateful,
Jonathan
From: Jesse Barnes jbar...@virtuousgeek.org
Date: Thu, 21 Jun 2012 15:13:50 -0700
Subject: drm/i915: prefer wide slow to fast narrow in DP configs
commit 684aaa646f90f5ee07799d52d0735625756e607b upstream.
High frequency link configurations have the potential to cause trouble
with long and/or cheap cables, so prefer slow and wide configurations
instead. This patch has the potential to cause trouble for eDP
configurations that lie about available lanes, so if we run into that we
can make it conditional on eDP.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
Tested-by: pe...@colberg.org
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d4c4937067fb..fae2050324bc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -708,8 +708,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
bpp = adjusted_mode-private_flags INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
- for (lane_count = 1; lane_count = max_lane_count; lane_count = 1) {
- for (clock = 0; clock = max_clock; clock++) {
+ for (clock = 0; clock = max_clock; clock++) {
+ for (lane_count = 1; lane_count = max_lane_count; lane_count
= 1) {
int link_avail =
intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
if (intel_dp_link_required(mode-clock, bpp)
--
1.7.11.rc3
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
tags 658662 + patch fixed-upstream quit Hi, Peter Colberg wrote: Since upgrading to linux-image-3.2.0-1-amd64, an external display connected via DisplayPort to a Sandy Bridge onboard graphics card stopped working, and instead turns off reporting “DP no signal”. With linux-image-3.1.0-1-amd64, the same display connected via the DisplayPort works fine. Thanks again. This is said to be fixed by the patch drm/i915: properly compute dp dithering for user-created modes (2012-04-10) which has been queued for 3.2.16. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Wed, Apr 18, 2012 at 01:37:23PM -0500, Jonathan Nieder wrote: tags 658662 + patch fixed-upstream quit Hi, Peter Colberg wrote: Since upgrading to linux-image-3.2.0-1-amd64, an external display connected via DisplayPort to a Sandy Bridge onboard graphics card stopped working, and instead turns off reporting âDP no signalâ. With linux-image-3.1.0-1-amd64, the same display connected via the DisplayPort works fine. Thanks again. This is said to be fixed by the patch drm/i915: properly compute dp dithering for user-created modes (2012-04-10) which has been queued for 3.2.16. No luck, that patch does *not* fix this problem :-(. https://bugs.freedesktop.org/show_bug.cgi?id=45801#c16 Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
tags 658662 - patch fixed-upstream quit Peter Colberg wrote: No luck, that patch does *not* fix this problem :-(. Alas. Thanks for checking. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Sat, Feb 04, 2012 at 06:31:13PM -0500, Peter Colberg wrote: Since upgrading to linux-image-3.2.0-1-amd64, an external display connected via DisplayPort to a Sandy Bridge onboard graphics card stopped working, and instead turns off reporting “DP no signal”. Ok, I have finished the bisect, compiling and testing 17 kernels. It seems the math in the i915 DisplayPort code got worse… ;-) Peter cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit commit cd9dde44f47501394b9f0715b6a36a92aa74c0d0 Author: Adam Jackson a...@redhat.com Date: Fri Oct 14 12:43:49 2011 -0400 drm/i915/dp: Fix the math in intel_dp_link_required The previous code was confused about units, which is pretty reasonable given that the units themselves are confusing. Signed-off-by: Adam Jackson a...@redhat.com Signed-off-by: Keith Packard kei...@keithp.com :04 04 3c0a0f38fc6482a401340e03fa3fbd687d11eda4 294673b782b3ecc93540f46f7721d385bd30cfac M drivers # git bisect log # bad: [805a6af8dba5dfdd35ec35dc52ec0122400b2610] Linux 3.2 # good: [c3b92c8787367a8bb53d57d9789b558f1295cc96] Linux 3.1 git bisect start 'v3.2' 'v3.1' # bad: [68d99b2c8efcb6ed3807a55569300c53b5f88be5] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect bad 68d99b2c8efcb6ed3807a55569300c53b5f88be5 # good: [efb8d21b2c6db3497655cc6a033ae8a9883e4063] Merge branch 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect good efb8d21b2c6db3497655cc6a033ae8a9883e4063 # good: [8686a0e200419322654a75155e2e6f80346a1297] Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 8686a0e200419322654a75155e2e6f80346a1297 # bad: [f362f98e7c445643d27c610bb7a86b79727b592e] Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/hch/vfs-queue git bisect bad f362f98e7c445643d27c610bb7a86b79727b592e # good: [ca836a25435ef1b9914840ed0a310c9b6ac261d1] Merge branch 'x86-vdso-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good ca836a25435ef1b9914840ed0a310c9b6ac261d1 # good: [c5c42360bc1cb14c7da3186683e9525b33b72656] vmwgfx: Don't pass unused arguments to do_dirty functions git bisect good c5c42360bc1cb14c7da3186683e9525b33b72656 # bad: [5619a693965b291315685bdfe01a0246ebd7e41e] Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs git bisect bad 5619a693965b291315685bdfe01a0246ebd7e41e # bad: [82d165557ef094d4b4dfc05871aee618ec7102b0] drm/i915/dp: Fix eDP on PCH DP on CPT/PPT git bisect bad 82d165557ef094d4b4dfc05871aee618ec7102b0 # good: [a9e2641dee52cae2db7688a749344365642a5e79] drm/i915: close PM interrupt masking races in the rps work func git bisect good a9e2641dee52cae2db7688a749344365642a5e79 # good: [75770564c90c45618003267f4cdde4bbc090f1bd] drm/i915: use transcoder select bits on VGA and HDMI on CPT git bisect good 75770564c90c45618003267f4cdde4bbc090f1bd # good: [a487928908226df493a3ce145ecf4bb39296714e] drm/i915: remove transcoder PLL mashing from mode_set per specs git bisect good a487928908226df493a3ce145ecf4bb39296714e # bad: [a2006cf5a7ad3463e7c1e9da2c4bc90499427558] drm/i915: read full receiver capability field during DP hot plug git bisect bad a2006cf5a7ad3463e7c1e9da2c4bc90499427558 # good: [f52c619a590fa75276c07dfcaf380dee53e4ea4c] drm/i915/panel: Always record the backlight level again (but cleverly) git bisect good f52c619a590fa75276c07dfcaf380dee53e4ea4c # bad: [dc22ee6fc18ce0f15424e753e8473c306ece95c1] drm/i915/dp: Remove eDP special cases from bandwidth checks git bisect bad dc22ee6fc18ce0f15424e753e8473c306ece95c1 # bad: [cd9dde44f47501394b9f0715b6a36a92aa74c0d0] drm/i915/dp: Fix the math in intel_dp_link_required git bisect bad cd9dde44f47501394b9f0715b6a36a92aa74c0d0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
tags 658662 + upstream patch moreinfo
quit
Peter Colberg wrote:
cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit
Yay, thanks much for this. :)
Please test the attached patch against the linux-3.2.y branch.
git remote add -f stable \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git checkout stable/linux-3.2.y
git am -3sc thepatch
make silentoldconfig; # reuse configuration
make deb-pkg; # optionally with -jnum
dpkg -i ../name of package
reboot
From: Keith Packard kei...@keithp.com
Date: Wed, 25 Jan 2012 08:16:25 -0800
Subject: drm/i915: Force explicit bpp selection for intel_dp_link_required
commit c898261c0dad617f0f1080bedc02d507a2fcfb92 upstream.
It is never correct to use intel_crtc-bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be addressed separately from this bugfix.
intel_dp_link_required is called from intel_dp_mode_valid and
intel_dp_mode_fixup.
* intel_dp_mode_valid is called to list supported modes; in this case,
the current crtc values cannot be relevant as the modes in question
may never be selected. Thus, using intel_crtc-bpp is never right.
* intel_dp_mode_fixup is called during mode setting, but it is run
well before ironlake_crtc_mode_set is called to set intel_crtc-bpp,
so using intel_crtc-bpp in this path can only ever get a stale
value.
Cc: Lubos Kolouch lubos.kolo...@gmail.com
Cc: Adam Jackson a...@redhat.com
Cc: sta...@vger.kernel.org
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881
Tested-by: Dave Airlie airl...@redhat.com
Tested-by: cama...@picnicpark.org (Dell Latitude 6510)
Tested-by: Roland Dreier rol...@digitalvampire.org
Signed-off-by: Keith Packard kei...@keithp.com
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 20 +---
1 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 92b041b66e49..ac600910ffc6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -208,17 +208,8 @@ intel_dp_link_clock(uint8_t link_bw)
*/
static int
-intel_dp_link_required(struct intel_dp *intel_dp, int pixel_clock, int
check_bpp)
+intel_dp_link_required(int pixel_clock, int bpp)
{
- struct drm_crtc *crtc = intel_dp-base.base.crtc;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int bpp = 24;
-
- if (check_bpp)
- bpp = check_bpp;
- else if (intel_crtc)
- bpp = intel_crtc-bpp;
-
return (pixel_clock * bpp + 9) / 10;
}
@@ -245,12 +236,11 @@ intel_dp_mode_valid(struct drm_connector *connector,
return MODE_PANEL;
}
- mode_rate = intel_dp_link_required(intel_dp, mode-clock, 0);
+ mode_rate = intel_dp_link_required(mode-clock, 24);
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
if (mode_rate max_rate) {
- mode_rate = intel_dp_link_required(intel_dp,
- mode-clock, 18);
+ mode_rate = intel_dp_link_required(mode-clock, 18);
if (mode_rate max_rate)
return MODE_CLOCK_HIGH;
else
@@ -683,7 +673,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
int lane_count, clock;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
int max_clock = intel_dp_max_link_bw(intel_dp) == DP_LINK_BW_2_7 ? 1 :
0;
- int bpp = mode-private_flags INTEL_MODE_DP_FORCE_6BPC ? 18 : 0;
+ int bpp = mode-private_flags INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
static int bws[2] = { DP_LINK_BW_1_62, DP_LINK_BW_2_7 };
if (is_edp(intel_dp) intel_dp-panel_fixed_mode) {
@@ -701,7 +691,7 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct
drm_display_mode *mode,
for (clock = 0; clock = max_clock; clock++) {
int link_avail =
intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
- if (intel_dp_link_required(intel_dp, mode-clock, bpp)
+ if (intel_dp_link_required(mode-clock, bpp)
= link_avail) {
intel_dp-link_bw = bws[clock];
intel_dp-lane_count = lane_count;
--
1.7.9
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Wed, Feb 08, 2012 at 04:42:01PM -0600, Jonathan Nieder wrote: tags 658662 + upstream patch moreinfo quit Peter Colberg wrote: cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit Yay, thanks much for this. :) Please test the attached patch against the linux-3.2.y branch. git remote add -f stable \ git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git git checkout stable/linux-3.2.y git am -3sc thepatch make silentoldconfig; # reuse configuration make deb-pkg; # optionally with -jnum dpkg -i ../name of package reboot From: Keith Packard kei...@keithp.com Date: Wed, 25 Jan 2012 08:16:25 -0800 Subject: drm/i915: Force explicit bpp selection for intel_dp_link_required commit c898261c0dad617f0f1080bedc02d507a2fcfb92 upstream. Thanks, but I just tested this patch (again). It is included in drm-intel-fixes, and it does not fix the regression: https://bugs.freedesktop.org/show_bug.cgi?id=45801#c5 Given that the problem persists, at least my bisect was not in vain ;-). Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
tags 658662 - patch moreinfo quit Jonathan Nieder wrote: Please test the attached patch against the linux-3.2.y branch. Never mind --- I see you've confirmed upstream it doesn't fix things. Sorry for the noise. If I have further questions, I'll ask them on the upstream bugtracker. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Hi Jonathan, On Mon, Feb 06, 2012 at 01:15:44AM -0600, Jonathan Nieder wrote: Please report this upstream, following instructions from [1], and let us know the bug number so we can track it. The upstream developers may ask you to bisect to find the specific patch that introduced the problem. It works like this: … Thanks for the detailed walk-through. So far I tested vanilla Linux v3.2 as bad, v3.1 as good, and started the bisect (with the first half-way commit tested as bad). That means “roughly 12 steps” to go. I will report back when the upstream bug report is filed. Regards, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Hi, Peter Colberg wrote: To summarize: The external display connected via DisplayPort works fine with Linux 3.1, while, with Linux 3.2, it works with lower (non-native) resolutions and fails with the maximum (native) resolution. Please report this upstream, following instructions from [1], and let us know the bug number so we can track it. The upstream developers may ask you to bisect to find the specific patch that introduced the problem. It works like this: 0. Prerequisites: apt-get install git build-essential 1. Get a copy of the kernel source repository: git clone \ git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git cd linux Or if you already have a copy, update it: cd linux git fetch origin 2. Test v3.2: git checkout v3.2 cp /boot/config-$(uname -r) .config; # current configuration make localmodconfig; # optional: minimize configuration make deb-pkg; # optionally with -jn for parallel build dpkg -i ../name of package reboot ... test test test ... If it doesn't exhibit the problem, declare victory and we can try to figure out what Debian-specific patch (unlikely) or configuration change (more likely) caused it. Otherwise: 3. Test v3.1: git checkout v3.1 make silentoldconfig; # reuse configuration make deb-pkg; # maybe with -j4 dpkg -i ../name of package reboot ... test test test ... Hopefully it does not exhibit the problem. 4. Test a version halfway between: git bisect start v3.2 v3.1; # checks out a version halfway between to test make silentoldconfig; # reuse configuration make deb-pkg; # maybe with -j4 dpkg -i ../name of package reboot ... test test test ... git bisect bad; # if it exhibits the problem git bisect good; # if the external display works fine, after a # power-cycle and with the right resolution git bisect skip; # if some other problem makes it hard to test 5. Another version to test will be automatically checked out. So: make silentoldconfig make deb-pkg; # maybe with -j4 dpkg -i ../name of package reboot ... test ... git bisect good/bad/skip 6. Rinse and repeat until bored. 7. After sufficiently many iterations, git will indicate the first bad commit --- hoorah! If bored before then, you can run git bisect log to print information about the versions tested in a form that will allow someone else to pick up where you left off. At any step if the gitk package is installed, you can run git bisect visualize to watch the regression range narrowing. Hope that helps, Jonathan [1] http://intellinuxgraphics.org/how_to_report_bug.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Hi Peter, Peter Colberg wrote: Package: linux-2.6 Version: 3.2.2-1 Severity: important Tags: upstream Which upstream version did you test? Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
On Sun, Feb 05, 2012 at 02:44:53AM -0600, Jonathan Nieder wrote: Hi Peter, Peter Colberg wrote: Package: linux-2.6 Version: 3.2.2-1 Severity: important Tags: upstream Which upstream version did you test? Sorry, I must have misinterpreted the upstream tag. I tested the Debian package only, i.e. linux-image-3.2.0-1-amd64=3.2.2-1. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
found 658662 3.2.4-1 thanks Since the changelog of Linux 3.2.3 contains drm/i915-related fixes, I tested the newest Debian kernel: No change, the external display remains dark. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2
Package: linux-2.6 Version: 3.2.2-1 Severity: important Tags: upstream Dear Maintainer, Since upgrading to linux-image-3.2.0-1-amd64, an external display connected via DisplayPort to a Sandy Bridge onboard graphics card stopped working, and instead turns off reporting “DP no signal”. With linux-image-3.1.0-1-amd64, the same display connected via the DisplayPort works fine. After powering both the display and the machine, the display first turns on when the i915 kernel module is loaded upon boot. It shows the console with boot messages at the maximum display resolution (1920x1080). Then the X server starts, and the external display switches to a lower resolution (1024x768), which seems to be the default setting of the X server. After login, I manually switch to the maximum resolution (1920x1080) using the command “xrandr --output DP1 --auto”. With linux-image-3.2.0-1-amd64, after powering both the display and the machine, the display remains dark during boot, even when the i915 kernel module is loaded. The display first turns on only when the X server is loaded, with the default resolution 1024x768. After login, I manually switch to 1920x1080, but then the display reports “DP no signal” and turns *off*. To summarize: The external display connected via DisplayPort works fine with Linux 3.1, while, with Linux 3.2, it works with lower (non-native) resolutions and fails with the maximum (native) resolution. I noticed one peculiarity: It is possible to have a working external display by booting into Linux 3.1 first, and then rebooting into Linux 3.2 *without interrupting the power supply of the display*. However, as soon as I power-cycle the display while under Linux 3.2, it stops working again. There is a recent thread by Keith Packard with DisplayPort-related patches: https://lkml.org/lkml/2012/1/25/204 I tested both a kernel with only patch 1/2, as well as a kernel with both patches 1/2 and 2/2 applied, based on the Debian kernel source and using the test-patches script. Both kernels showed the same faulty behaviour, i.e. the external display remains dark at the native resolution. If there are other potential fixes I could test, please let me know. Thanks, Peter -- xrandr: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 277mm x 156mm 1366x768 60.0*+ 1360x768 59.8 60.0 1024x768 60.0 800x60060.3 56.2 640x48059.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1680x1050 60.0 1600x900 60.0 1280x1024 60.0 1280x800 59.8 1280x720 60.0 1024x768 60.0 800x60060.3 640x48060.0 HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) -- Package-specific info: ** Version: Linux version 3.2.0-1-amd64 (Debian 3.2.2-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-12) ) #1 SMP Wed Feb 1 08:56:58 UTC 2012 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-1-amd64 root=/dev/mapper/vg-root ro pcie_aspm=force i915.i915_enable_rc6=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 ** Not tainted ** Kernel log: [ 20.446802] [drm] Initialized drm 1.1.0 20060810 [ 20.910637] IBM TrackPoint firmware: 0x0e, buttons: 3/3 [ 20.928577] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/input/input4 [ 20.948229] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input5 [ 20.953169] HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0 [ 20.953416] HDMI status: Codec=3 Pin=6 Presence_Detect=0 ELD_Valid=0 [ 20.953667] HDMI status: Codec=3 Pin=7 Presence_Detect=0 ELD_Valid=0 [ 20.953878] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1b.0/sound/card0/input6 [ 20.954053] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1b.0/sound/card0/input7 [ 20.954225] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1b.0/sound/card0/input8 [ 20.955314] i915 :00:02.0: power state changed by ACPI to D0 [ 20.955380] i915 :00:02.0: power state changed by ACPI to D0 [ 20.955446] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 20.955510] i915 :00:02.0: setting latency timer to 64 [ 20.983994] mtrr: no more MTRRs available [ 20.984054] [drm] MTRR allocation failed. Graphics performance may suffer. [ 20.984497] i915 :00:02.0: irq 51 for MSI/MSI-X [ 20.984501] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 20.984562] [drm] Driver supports precise vblank timestamp
