While in init3, resolution is native, KMS works fine, no problems at
all. As soon as gdm starts it seems that TV1 output is recognized as
connected even if it isn't so resolution on VGA output is degraded from
native 1280x1024 to 1024x768 on startup.
I've disabled LVDS output with video=LVDS-1:d because the cable looses
connection in certain lid positions.
2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
it came down to this commit:
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
Author: Jesse Barnes <[email protected]>
Date: Wed Aug 18 13:20:54 2010 -0700
drm/i915: wait for actual vblank, not just 20ms
Waiting for a hard coded 20ms isn't always enough to make sure a vblank
period has actually occurred, so add code to make sure we really have
passed through a vblank period (or that the pipe is off when disabling).
This prevents problems with mode setting and link training, and seems to
fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
on an HP 8440p instead. Hopefully also fixes
https://bugs.freedesktop.org/show_bug.cgi?id=29141.
Signed-off-by: Jesse Barnes <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
:040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b
2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
DELL Vostro 1310 is in question. Thanks,
Ivan
On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic <[email protected]> wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
Interesting. I am chasing a spurious TV connection on SDVO that has been
present since time immemorial. How certain are you that you've never have a
false detection in earlier kernels? It may not have affected the choice of
outputs, except sporadically, but it should be recorded in the debug logs
with drm.debug=0x6.
Does this make any difference?
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo
index ea2f4ab..e7ff378 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1454,7 +1454,7 @@ intel_sdvo_detect(struct drm_connector *connector,
return connector_status_unknown;
if (intel_sdvo->is_tv) {
/* add 30ms delay when the output type is SDVO-TV */
- mdelay(30);
+ mdelay(100);
}
if (!intel_sdvo_read_response(intel_sdvo, &response, 2))
return connector_status_unknown;
Or (more likely):
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo
index ea2f4ab..77c455b 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1216,8 +1216,8 @@ static int intel_sdvo_dpms(struct drm_encoder
*encoder, in
temp = I915_READ(intel_sdvo->sdvo_reg);
if ((temp & SDVO_ENABLE) == 0)
intel_sdvo_write_sdvox(intel_sdvo, temp |
SDVO_ENABLE);
- for (i = 0; i < 2; i++)
- intel_wait_for_vblank(dev, intel_crtc->pipe);
+
+ msleep(100);
status = intel_sdvo_get_trained_inputs(intel_sdvo,
&input1, &input2);
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, 2010-08-24 at 08:49 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 03:00:55 +0200, Ivan Bulatovic <[email protected]> wrote:
> > While in init3, resolution is native, KMS works fine, no problems at
> > all. As soon as gdm starts it seems that TV1 output is recognized as
> > connected even if it isn't so resolution on VGA output is degraded from
> > native 1280x1024 to 1024x768 on startup.
>
> Interesting. I am chasing a spurious TV connection on SDVO that has been
> present since time immemorial. How certain are you that you've never have a
> false detection in earlier kernels? It may not have affected the choice of
> outputs, except sporadically, but it should be recorded in the debug logs
> with drm.debug=0x6.
>
> Does this make any difference?
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo
> index ea2f4ab..e7ff378 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1454,7 +1454,7 @@ intel_sdvo_detect(struct drm_connector *connector,
> return connector_status_unknown;
> if (intel_sdvo->is_tv) {
> /* add 30ms delay when the output type is SDVO-TV */
> - mdelay(30);
> + mdelay(100);
> }
> if (!intel_sdvo_read_response(intel_sdvo, &response, 2))
> return connector_status_unknown;
>
> Or (more likely):
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> b/drivers/gpu/drm/i915/intel_sdvo
> index ea2f4ab..77c455b 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1216,8 +1216,8 @@ static int intel_sdvo_dpms(struct drm_encoder
> *encoder, in
> temp = I915_READ(intel_sdvo->sdvo_reg);
> if ((temp & SDVO_ENABLE) == 0)
> intel_sdvo_write_sdvox(intel_sdvo, temp |
> SDVO_ENABLE);
> - for (i = 0; i < 2; i++)
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> +
> + msleep(100);
>
> status = intel_sdvo_get_trained_inputs(intel_sdvo,
> &input1, &input2);
>
> --
> Chris Wilson, Intel Open Source Technology Centre
Hi Chris. Well, I think that I had these problems before, around
2.6.28/2.6.29 but all I remember is that it was fixed relatively fast.
Everything worked well untill 2.6.36-rc2 popped up. Not even sporadical
events like these. What was strange about this that I wasn't able to
kill TV connection with xrandr, so I was stuck with 1024x768 and all of
a sudden upon subsequent restarts it somehow remembered that tv is
disconnected and VGA resolution is native.
xrandr -q
TV1 disconnected (normal left inverted right x axis y axis)
848x480 (0x55) 14.5MHz
h: width 848 start 849 end 912 total 944 skew 0 clock
15.4KHz
v: height 480 start 481 end 512 total 513 clock
30.0Hz
cat /var/log/Xorg.0.log | grep TV
[ 27.733] (II) intel(0): Output TV1 has no monitor section
[ 27.988] (II) intel(0): EDID for output TV1
[ 27.991] (II) intel(0): Printing probed modes for output TV1
[ 27.991] (II) intel(0): Output TV1 connected
[ 27.991] (II) intel(0): Output TV1 using initial mode 1024x768
Above patches didn't help when applied to 2.6.36-rc2.
I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with
drm.debug=0x6. Thanks,
Ivan
On Tue, 24 Aug 2010 10:35:12 +0200, Ivan Bulatovic <[email protected]> wrote:
> Above patches didn't help when applied to 2.6.36-rc2.
Would be useful to double check reverting the bad commit helps.
> I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with
> drm.debug=0x6. Thanks,
Aye that would be a useful check.
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic <[email protected]> wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
>
> I've disabled LVDS output with video=LVDS-1:d because the cable looses
> connection in certain lid positions.
>
> 2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
> it came down to this commit:
>
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes <[email protected]>
> Date: ? Wed Aug 18 13:20:54 2010 -0700
>
> ? ?drm/i915: wait for actual vblank, not just 20ms
>
> Waiting for a hard coded 20ms isn't always enough to make sure a vblank
> period has actually occurred, so add code to make sure we really have
> passed through a vblank period (or that the pipe is off when disabling).
>
> This prevents problems with mode setting and link training, and seems to
> fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
> on an HP 8440p instead. ?Hopefully also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=29141.
>
> ? ?Signed-off-by: Jesse Barnes <[email protected]>
> ? ?Signed-off-by: Eric Anholt <[email protected]>
>
> :040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b
> 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
>
> I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
> DELL Vostro 1310 is in question. Thanks,
On Tue, Aug 24, 2010 at 4:00 AM, Ivan Bulatovic <[email protected]> wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
>
> I've disabled LVDS output with video=LVDS-1:d because the cable looses
> connection in certain lid positions.
>
> 2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
> it came down to this commit:
>
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes <[email protected]>
> Date: ? Wed Aug 18 13:20:54 2010 -0700
>
> ? ?drm/i915: wait for actual vblank, not just 20ms
>
> Waiting for a hard coded 20ms isn't always enough to make sure a vblank
> period has actually occurred, so add code to make sure we really have
> passed through a vblank period (or that the pipe is off when disabling).
>
> This prevents problems with mode setting and link training, and seems to
> fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
> on an HP 8440p instead. ?Hopefully also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=29141.
>
> ? ?Signed-off-by: Jesse Barnes <[email protected]>
> ? ?Signed-off-by: Eric Anholt <[email protected]>
>
> :040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b
> 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
>
> I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
> DELL Vostro 1310 is in question. Thanks,
FWIW, I saw this on my MacBook as well. I was debugging a boot time
oops at the time so I just changed screen resolution in Gnome to fix
it.
On Tue, 2010-08-24 at 09:50 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 10:35:12 +0200, Ivan Bulatovic <[email protected]> wrote:
> > Above patches didn't help when applied to 2.6.36-rc2.
>
> Would be useful to double check reverting the bad commit helps.
>
> > I'm going to compare dmesg between 2.6.35.3 and 2.6.36-rc2 with
> > drm.debug=0x6. Thanks,
>
> Aye that would be a useful check.
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Here are both dmesg outputs with drm.debug=0x6 in the attachements
cat dmesg.drm.35 | grep TV
[ 1.006007] [drm:intel_tv_detect_type], No TV connection detected
[ 26.391167] [drm:intel_tv_detect_type], No TV connection detected
[ 26.539169] [drm:intel_tv_detect_type], No TV connection detected
[ 26.805170] [drm:intel_tv_detect_type], No TV connection detected
[ 26.953169] [drm:intel_tv_detect_type], No TV connection detected
[ 31.935291] [drm:intel_tv_detect_type], No TV connection detected
[ 32.083153] [drm:intel_tv_detect_type], No TV connection detected
[ 32.352162] [drm:intel_tv_detect_type], No TV connection detected
[ 32.500166] [drm:intel_tv_detect_type], No TV connection detected
[ 32.819162] [drm:intel_tv_detect_type], No TV connection detected
[ 32.967161] [drm:intel_tv_detect_type], No TV connection detected
[ 42.666163] [drm:intel_tv_detect_type], No TV connection detected
[ 42.814164] [drm:intel_tv_detect_type], No TV connection detected
[ 43.083165] [drm:intel_tv_detect_type], No TV connection detected
[ 43.231164] [drm:intel_tv_detect_type], No TV connection detected
[ 43.500165] [drm:intel_tv_detect_type], No TV connection detected
[ 43.648165] [drm:intel_tv_detect_type], No TV connection detected
[ 47.134054] [drm:intel_tv_detect_type], No TV connection detected
[ 47.281076] [drm:intel_tv_detect_type], No TV connection detected
cat dmesg.drm.36 | grep TV
[ 1.487022] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 1.691016] [drm:intel_tv_detect_type], No TV connection detected
[ 25.939358] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 26.143015] [drm:intel_tv_detect_type], No TV connection detected
[ 26.264155] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 26.269980] [drm:intel_tv_detect_type], Detected S-Video TV
connection
[ 26.406164] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 26.419933] [drm:intel_tv_detect_type], Detected Composite TV
connection
[ 26.657428] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 26.670054] [drm:intel_tv_detect_type], Detected S-Video TV
connection
[ 27.171031] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:54:1024x768]
[ 32.772020] [drm:intel_tv_detect_type], No TV connection detected
[ 32.874039] [drm:intel_tv_detect_type], No TV connection detected
[ 33.090015] [drm:intel_tv_detect_type], No TV connection detected
[ 33.192015] [drm:intel_tv_detect_type], No TV connection detected
[ 33.473017] [drm:intel_tv_detect_type], No TV connection detected
[ 33.575016] [drm:intel_tv_detect_type], No TV connection detected
[ 42.800550] [drm:intel_tv_detect_type], Detected Component TV
connection
[ 42.916789] [drm:intel_tv_detect_type], Detected Component TV
connection
[ 43.034997] [drm:intel_tv_detect_type], Detected Component TV
connection
[ 46.486754] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 46.690019] [drm:intel_tv_detect_type], No TV connection detected
[ 46.821272] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 46.833086] [drm:intel_tv_detect_type], Detected S-Video TV
connection
[ 46.964281] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:0:NTSC 480i]
[ 46.967099] [drm:intel_tv_detect_type], Detected Composite TV
connection
[ 47.132794] [drm:drm_crtc_helper_set_mode], [ENCODER:15:TV-15] set
[MODE:57:]
I'll try to revert 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 and see if
that helps.
Thanks for the confirmation Pekka. I've managed to change the resolution
but gdm always starts with 1024x768 and upon login it gets 1280x1024,
and sometimes the mouse pointer go out of bounds to the right edge of
the screen but when I maximize windows it sticks to 1280x1024. When I
start gnome-display-properties that invisible right portion of the
screen dissapears.
Ivan, can you try this patch?
Linus is going to make some more snide comments if he sees just how many
of these trivial-ish patches that I have pending...
---
If we need to wait until the next vblank for the register to be updated
and to take effect, make sure the write is actually flushed to the register
prior to sleeping.
Signed-off-by: Chris Wilson <[email protected]>
---
drivers/gpu/drm/i915/intel_tv.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index d2029ef..19b9739 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1157,10 +1157,13 @@ intel_tv_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode,
I915_WRITE(dspbase_reg, I915_READ(dspbase_reg));
/* Wait for vblank for the disable to take effect */
- if (!IS_I9XX(dev))
+ if (!IS_I9XX(dev)) {
+ POSTING_READ(dspbase_reg);
intel_wait_for_vblank(dev, intel_crtc->pipe);
+ }
I915_WRITE(pipeconf_reg, pipeconf & ~PIPEACONF_ENABLE);
+ POSTING_READ(pipeconf_reg);
/* Wait for vblank for the disable to take effect. */
intel_wait_for_vblank(dev, intel_crtc->pipe);
@@ -1268,11 +1271,15 @@ intel_tv_detect_type (struct intel_tv *intel_tv)
DAC_C_0_7_V);
I915_WRITE(TV_CTL, tv_ctl);
I915_WRITE(TV_DAC, tv_dac);
+ POSTING_READ(TV_DAC);
intel_wait_for_vblank(dev, intel_crtc->pipe);
+
tv_dac = I915_READ(TV_DAC);
I915_WRITE(TV_DAC, save_tv_dac);
I915_WRITE(TV_CTL, save_tv_ctl);
+ POSTING_READ(TV_CTL);
intel_wait_for_vblank(dev, intel_crtc->pipe);
+
/*
* A B C
* 0 1 1 Composite
--
1.7.1
On Tue, 2010-08-24 at 10:21 +0100, Chris Wilson wrote:
> Ivan, can you try this patch?
>
I've patched it, unfortunately it doesn't help. :( Dmesg is in
attachement. Symptoms are the same.
> Linus is going to make some more snide comments if he sees just how many
> of these trivial-ish patches that I have pending...
>
I don't think so, this is fun, I haven't had problems with intel drivers
in months :D
> ---
>
> If we need to wait until the next vblank for the register to be updated
> and to take effect, make sure the write is actually flushed to the register
> prior to sleeping.
>
> Signed-off-by: Chris Wilson <[email protected]>
Hopefully this is a contributing factor to the spurious TV detection
repoted by Ivan Bulatovic and others.
References:
Bug 16871 - "TV1 connected" with no tv
https://bugzilla.kernel.org/show_bug.cgi?id=16871
Signed-off-by: Chris Wilson <[email protected]>
Reported-by: Ivan Bulatovic <[email protected]>
Cc: Jesse Barnes <[email protected]>
---
drivers/gpu/drm/i915/intel_tv.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index f70bc76..f96289d 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1171,7 +1171,7 @@ intel_tv_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode,
I915_WRITE(pipeconf_reg, pipeconf & ~PIPEACONF_ENABLE);
POSTING_READ(pipeconf_reg);
/* Wait for vblank for the disable to take effect. */
- intel_wait_for_vblank(dev, intel_crtc->pipe);
+ intel_wait_for_vblank_off(dev, intel_crtc->pipe);
/* Filter ctl must be set before TV_WIN_SIZE */
I915_WRITE(TV_FILTER_CTL_1, TV_AUTO_SCALE);
--
1.7.1
On Tue, 2010-08-24 at 16:11 +0100, Chris Wilson wrote:
> Hopefully this is a contributing factor to the spurious TV detection
> repoted by Ivan Bulatovic and others.
>
> References:
>
> Bug 16871 - "TV1 connected" with no tv
> https://bugzilla.kernel.org/show_bug.cgi?id=16871
>
> Signed-off-by: Chris Wilson <[email protected]>
> Reported-by: Ivan Bulatovic <[email protected]>
> Cc: Jesse Barnes <[email protected]>
> ---
> drivers/gpu/drm/i915/intel_tv.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index f70bc76..f96289d 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1171,7 +1171,7 @@ intel_tv_mode_set(struct drm_encoder *encoder, struct drm_display_mode *mode,
> I915_WRITE(pipeconf_reg, pipeconf & ~PIPEACONF_ENABLE);
> POSTING_READ(pipeconf_reg);
> /* Wait for vblank for the disable to take effect. */
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> + intel_wait_for_vblank_off(dev, intel_crtc->pipe);
>
> /* Filter ctl must be set before TV_WIN_SIZE */
> I915_WRITE(TV_FILTER_CTL_1, TV_AUTO_SCALE);
Unfotunately I still get TV connection detected :(
On Tue, 24 Aug 2010 23:08:50 +0200, Ivan Bulatovic <[email protected]> wrote:
> Unfotunately I still get TV connection detected :(
Jesse spotted the root cause and Linus has now pushed that fix for
intel_wait_for_vblank() out. This is just a very minor bug in comparison.
Can you please test against linus/master and check that resolves the
spurious TV detection for you?
Thanks.
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, 2010-08-24 at 22:52 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 23:08:50 +0200, Ivan Bulatovic <[email protected]> wrote:
> > Unfotunately I still get TV connection detected :(
>
> Jesse spotted the root cause and Linus has now pushed that fix for
> intel_wait_for_vblank() out. This is just a very minor bug in comparison.
> Can you please test against linus/master and check that resolves the
> spurious TV detection for you?
> Thanks.
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Spurious TV detection is still here and + I have a new problem with
resolution in init3 when KMS fires up, it occupies only 1/3rd of the
screen when booting.
I've tried patching the kernel I used for testing so far with that one
liner and I've tried without patches we tried so far (git pull on a
clean linux-git) and the symptoms are the same on both of them.
So
- PIPE_VBLANK_INTERRUPT_STATUS) == 0,
+ PIPE_VBLANK_INTERRUPT_STATUS),
in intel_display.c doesn't fix the issue, plus it brings a new one in my
case.
On Tue, 2010-08-24 at 22:52 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 23:08:50 +0200, Ivan Bulatovic <[email protected]> wrote:
> > Unfotunately I still get TV connection detected :(
>
> Jesse spotted the root cause and Linus has now pushed that fix for
> intel_wait_for_vblank() out. This is just a very minor bug in comparison.
> Can you please test against linus/master and check that resolves the
> spurious TV detection for you?
> Thanks.
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Spurious TV detection is still here and + I have a new problem with
resolution in init3 when KMS fires up, it occupies only 1/3rd of the
screen when booting.
I've tried patching the kernel I used for testing so far with that one
liner and I've tried without patches we tried so far (git pull on a
clean linux-git) and the symptoms are the same on both of them.
So
- PIPE_VBLANK_INTERRUPT_STATUS) == 0,
+ PIPE_VBLANK_INTERRUPT_STATUS),
in intel_display.c doesn't fix the issue, plus it brings a new one in my
case.
On Wed, 25 Aug 2010 01:04:31 +0200
Ivan Bulatovic <[email protected]> wrote:
> On Tue, 2010-08-24 at 22:52 +0100, Chris Wilson wrote:
> > On Tue, 24 Aug 2010 23:08:50 +0200, Ivan Bulatovic <[email protected]> wrote:
> > > Unfotunately I still get TV connection detected :(
> >
> > Jesse spotted the root cause and Linus has now pushed that fix for
> > intel_wait_for_vblank() out. This is just a very minor bug in comparison.
> > Can you please test against linus/master and check that resolves the
> > spurious TV detection for you?
> > Thanks.
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> Spurious TV detection is still here and + I have a new problem with
> resolution in init3 when KMS fires up, it occupies only 1/3rd of the
> screen when booting.
>
> I've tried patching the kernel I used for testing so far with that one
> liner and I've tried without patches we tried so far (git pull on a
> clean linux-git) and the symptoms are the same on both of them.
>
> So
> - PIPE_VBLANK_INTERRUPT_STATUS) == 0,
> + PIPE_VBLANK_INTERRUPT_STATUS),
> in intel_display.c doesn't fix the issue, plus it brings a new one in my
> case.
Ugg, one step forward, two steps back. Working on it.
--
Jesse Barnes, Intel Open Source Technology Center
On Tue, 2010-08-24 at 22:52 +0100, Chris Wilson wrote:
> On Tue, 24 Aug 2010 23:08:50 +0200, Ivan Bulatovic <[email protected]> wrote:
> > Unfotunately I still get TV connection detected :(
>
> Jesse spotted the root cause and Linus has now pushed that fix for
> intel_wait_for_vblank() out. This is just a very minor bug in comparison.
> Can you please test against linus/master and check that resolves the
> spurious TV detection for you?
> Thanks.
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Spurious TV detection is still here and + I have a new problem with
resolution in init3 when KMS fires up, it occupies only 1/3rd of the
screen when booting.
I've tried patching the kernel I used for testing so far with that one
liner and I've tried without patches we tried so far (git pull on a
clean linux-git) and the symptoms are the same on both of them.
So
- PIPE_VBLANK_INTERRUPT_STATUS) == 0,
+ PIPE_VBLANK_INTERRUPT_STATUS),
in intel_display.c doesn't fix the issue, plus it brings a new one in my
case.
/edit: had to remove linux-gfx from cc or mail wouldn't send otherwise
On Wed, Aug 25, 2010 at 01:06:36AM +0200, Ivan Bulatovic wrote:
>
> Spurious TV detection is still here and + I have a new problem with
> resolution in init3 when KMS fires up, it occupies only 1/3rd of the
> screen when booting.
Does the patch in http://lkml.org/lkml/2010/8/24/280 change anything for
you? If so I'm guessing we are seeing the same issue...
--
Sitsofe | http://sucs.org/~sits/
On Wed, 2010-08-25 at 09:15 +0100, Sitsofe Wheeler wrote:
> On Wed, Aug 25, 2010 at 01:06:36AM +0200, Ivan Bulatovic wrote:
> >
> > Spurious TV detection is still here and + I have a new problem with
> > resolution in init3 when KMS fires up, it occupies only 1/3rd of the
> > screen when booting.
>
> Does the patch in http://lkml.org/lkml/2010/8/24/280 change anything for
> you? If so I'm guessing we are seeing the same issue...
>
> --
> Sitsofe | http://sucs.org/~sits/
Ok, gonna try it out now. As for Jesse's question about whether there
are timeouts on the wait_for_vblank function, I can see at least 30
[drm_intel_wait_for_vblank], vblank wait timed out printks all over my
dmesg.
On Wed, 2010-08-25 at 09:15 +0100, Sitsofe Wheeler wrote:
> Does the patch in http://lkml.org/lkml/2010/8/24/280 change anything for
> you? If so I'm guessing we are seeing the same issue...
>
> --
> Sitsofe | http://sucs.org/~sits/
No, that doesn't help, I still get TV connection detected. But the wait
for vblank timeout printks are gone as expected.
On Wed, 25 Aug 2010 01:06:36 +0200, Ivan Bulatovic <[email protected]> wrote:
> On Tue, 2010-08-24 at 22:52 +0100, Chris Wilson wrote:
> > On Tue, 24 Aug 2010 23:08:50 +0200, Ivan Bulatovic <[email protected]> wrote:
> > > Unfotunately I still get TV connection detected :(
> >
> > Jesse spotted the root cause and Linus has now pushed that fix for
> > intel_wait_for_vblank() out. This is just a very minor bug in comparison.
> > Can you please test against linus/master and check that resolves the
> > spurious TV detection for you?
> > Thanks.
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> Spurious TV detection is still here and + I have a new problem with
> resolution in init3 when KMS fires up, it occupies only 1/3rd of the
> screen when booting.
Same here with my Acer 3810T, Intel GM45, the kernel was built from git pulled today.
v2.6.36-rc2-203-g502adf5
TV1 connected (normal left inverted right x axis y axis)
848x480 30.0 +
640x480 30.0 +
1024x768 30.0
800x600 30.0
and the fb only occupies 1/3rd of the screen, the fbset output
mode "848x480"
geometry 848 480 1366 768 32
timings 0 0 0 0 0 0 0
rgba 8/16,8/8,8/0,0/0
endmode
-Kanru
>
> I've tried patching the kernel I used for testing so far with that one
> liner and I've tried without patches we tried so far (git pull on a
> clean linux-git) and the symptoms are the same on both of them.
>
> So
> - PIPE_VBLANK_INTERRUPT_STATUS) == 0,
> + PIPE_VBLANK_INTERRUPT_STATUS),
> in intel_display.c doesn't fix the issue, plus it brings a new one in my
> case.
>
> /edit: had to remove linux-gfx from cc or mail wouldn't send otherwise
Hi all,
On Tue, Aug 24, 2010 at 12:12 PM, Ivan Bulatovic <[email protected]> wrote:
> Thanks for the confirmation Pekka. I've managed to change the resolution
> but gdm always starts with 1024x768 and upon login it gets 1280x1024,
> and sometimes the mouse pointer go out of bounds to the right edge of
> the screen but when I maximize windows it sticks to 1280x1024. When I
> start gnome-display-properties that invisible right portion of the
> screen dissapears.
I'm still seeing wrong resolution with my i915 Macbook with latest
Linus' git. Is there a fix in the pipeline or should we start looking
for a commit to revert? As a slab maintainer, I'm supposed to be able
to work with -rc kernels and this particular bug is pretty damn
annoying.
Pekka
On wtorek, 24 sierpnia 2010 o 03:00:55 Ivan Bulatovic wrote:
> While in init3, resolution is native, KMS works fine, no problems at
> all. As soon as gdm starts it seems that TV1 output is recognized as
> connected even if it isn't so resolution on VGA output is degraded from
> native 1280x1024 to 1024x768 on startup.
>
> I've disabled LVDS output with video=LVDS-1:d because the cable looses
> connection in certain lid positions.
>
> 2.6.36-rc1 didn't have this issue, 2.6.36-rc2 did so I've bisected and
> it came down to this commit:
>
> 9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the first bad commit
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes <[email protected]>
> Date: Wed Aug 18 13:20:54 2010 -0700
>
> drm/i915: wait for actual vblank, not just 20ms
>
> Waiting for a hard coded 20ms isn't always enough to make sure a vblank
> period has actually occurred, so add code to make sure we really have
> passed through a vblank period (or that the pipe is off when disabling).
>
> This prevents problems with mode setting and link training, and seems to
> fix a bug like https://bugs.freedesktop.org/show_bug.cgi?id=29278, but
> on an HP 8440p instead. Hopefully also fixes
> https://bugs.freedesktop.org/show_bug.cgi?id=29141.
>
> Signed-off-by: Jesse Barnes <[email protected]>
> Signed-off-by: Eric Anholt <[email protected]>
>
> :040000 040000 9941813d0f0bc4e141a87696d34f1d1b9087711b
>
> 2e407ad1d03b60f0e5b020313a8a63bd176b4005 M drivers
>
> I'm sending you dmesg, xorg and xrandr logs as attachements. GM965 on
> DELL Vostro 1310 is in question. Thanks,
>
> Ivan
I created a Bugzilla entry at
https://bugzilla.kernel.org/show_bug.cgi?id=17301
for your bug report, please add your address to the CC list in there, thanks!
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Sun, Aug 29, 2010 at 02:29:32PM +0300, Pekka Enberg wrote:
>
> I'm still seeing wrong resolution with my i915 Macbook with latest
> Linus' git. Is there a fix in the pipeline or should we start looking
> for a commit to revert? As a slab maintainer, I'm supposed to be able
> to work with -rc kernels and this particular bug is pretty damn
> annoying.
I've been seeing a variety of strange behaviour since
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 too (I found I could narrow it
down in http://lkml.org/lkml/2010/8/24/280 but the change mentioned
there doesn't seem to help others). I've filed
https://bugs.freedesktop.org/show_bug.cgi?id=29857 which summarises the
different strange behaviour that I've seen generated and the steps I've
used to reproduce them. Unfortunately this week I'm not going to have
much time for the tests I was able to do last week.
--
Sitsofe | http://sucs.org/~sits/