Bug 36997

Right, this is the fallout that we expected from

commit a03357d971b03cf5303d2cdf226ad24de0a044d8
Author: Zhao Yakui <yakui.zhao@intel.com>
Date:   Sun Apr 17 09:04:54 2011 +0100

    drm/i915/tv: Clear state sense detection for Cantiga

Can you please confirm by reverting a03357d9?

(In reply to comment #1)
> Right, this is the fallout that we expected from
> 
> commit a03357d971b03cf5303d2cdf226ad24de0a044d8
> Author: Zhao Yakui <yakui.zhao@intel.com>
> Date:   Sun Apr 17 09:04:54 2011 +0100
> 
>     drm/i915/tv: Clear state sense detection for Cantiga
> 
> Can you please confirm by reverting a03357d9?

Hello Chris. I have tested commit a03357d9?  and there is the same issue

Do you mean you did:
 
  git checkout a03357d9

or

  git checkout a03357d9^

?

It's the latter that I want tested (actually both ;) as that will confirm a03357d9 introduces the regression.

(In reply to comment #3)
> Do you mean you did:
> 
>   git checkout a03357d9
> 
> or
> 
>   git checkout a03357d9^
> 
> ?
> 
> It's the latter that I want tested (actually both ;) as that will confirm
> a03357d9 introduces the regression.

Hello Chris, I have tested a03357d9 and a03357d9^(31acbcc408f412d1ba73765b846c38642be553c3), and there is the same issue

(In reply to comment #3)
> Do you mean you did:
> 
>   git checkout a03357d9
> 
> or
> 
>   git checkout a03357d9^
> 
> ?
> 
> It's the latter that I want tested (actually both ;) as that will confirm
> a03357d9 introduces the regression.
(In reply to comment #1)
> Right, this is the fallout that we expected from
> 
> commit a03357d971b03cf5303d2cdf226ad24de0a044d8
> Author: Zhao Yakui <yakui.zhao@intel.com>
> Date:   Sun Apr 17 09:04:54 2011 +0100
> 
>     drm/i915/tv: Clear state sense detection for Cantiga
> 
> Can you please confirm by reverting a03357d9?

git revert a03357d9 failed

Ok, so the bug is unrelated to the TV-state sense detection disabling commit.

Do we have a clue as to what timeframe the bug was introduced? Just check 2.6.38, 2.6.37, 2.6.36 and so on, until the TV out detection works (if ever!)

(In reply to comment #6)
> Ok, so the bug is unrelated to the TV-state sense detection disabling commit.
> 
> Do we have a clue as to what timeframe the bug was introduced? Just check
> 2.6.38, 2.6.37, 2.6.36 and so on, until the TV out detection works (if ever!)

Hello Chris: Today I borrow another SDVO_S-vedio card and try it.It works well. But How weird that the first SDVO S-vedio card can't work only after loading DRM ?

Oh, of course it would be SDVO... Hmm, we don't have too much control over whether the add-in card detects successfully or not. Can you repeat the experiment (replace the original ADD2 card, then retry with the working ADD2) and see if the behaviour remains the same? If you can find another card, try that as well.

In the meantime a drm.debug=0x6 dmesg with the non-working card would be useful just in case the hardware is reporting something peculiar.

(In reply to comment #8)
> Oh, of course it would be SDVO... Hmm, we don't have too much control over
> whether the add-in card detects successfully or not. Can you repeat the
> experiment (replace the original ADD2 card, then retry with the working ADD2)
> and see if the behaviour remains the same? If you can find another card, try
> that as well.
> 
> In the meantime a drm.debug=0x6 dmesg with the non-working card would be useful
> just in case the hardware is reporting something peculiar.

Hello Chris. Do you mean that hotplug original ADD2 card with working ADD2 card?

I wouldn't hotplug it... ;-) But yes, swap back the original and recheck if it fails again.

I'm hoping we can write this off to misbehaving hardware...

Created attachment 46666 [details]
good card's drm.debug=0x6  dmesg info

this is working card's dmesg

Created attachment 46667 [details]
bad card (no working) drm.debug=0x6 dmesg info

this is bad(no working) card dmesg info with drm.debug=0x6

Looks like the "misbehaving" card is reporting the TV as a different output type [16, YPRPB?] and the working card reports it as an S-Video output[8].

Created attachment 46672 [details] [review]
Treat YRPB as a TV

(In reply to comment #14)
> Created an attachment (id=46672) [details]
> Treat YRPB as a TV
hello, this issue doesn't exists in this patch. Test-by: Wang Bo bo.b.wang@intel.com

Patch is merged to drm-intel-next-queued as

commit 076d0f0f554f6f9c41248f097c31fe86454c5616
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Sep 30 22:56:41 2011 +0100

    drm/i915/sdvo: Include YRPB as an additional TV output type

(In reply to comment #16)
> Patch is merged to drm-intel-next-queued as
> 

Strange, I didn't find this patch in -queued branch. Did you push it?

> commit 076d0f0f554f6f9c41248f097c31fe86454c5616
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Sep 30 22:56:41 2011 +0100
> 
>     drm/i915/sdvo: Include YRPB as an additional TV output type

> --- Comment #17 from sunyi <yi.sun@intel.com> 2012-03-31 18:11:48 PDT ---
> (In reply to comment #16)
> > Patch is merged to drm-intel-next-queued as
> > 
> 
> Strange, I didn't find this patch in -queued branch. Did you push it?

Oops, I've forgotten to do that. Pushed.

Created attachment 59508 [details]
dmesg of G45B with S-VIDEO

   I try with 
Kernel: (drm-intel-next-queue)d9c33f85cf3cc3f8717e56d42fd678573ed1727d3 
which include the patch ,the bug still occurs,when I boot the machine with S-VIDEO ,the TV screen will trun to be black after loading drm driver.
    but I try the 
Kernel: (drm-intel-fixes)b250da79a0c972ef7f6d58ebd1083cab066e6c82
the issue don't occur.
    BTW,the tile of this bug's platform is G45,but in the describe of the enviroment is piketon,I'm puzzled with this, and I test with G45.

> --- Comment #19 from yangguang <guang.a.yang@intel.com> 2012-04-05 01:41:23 PDT ---
> Created attachment 59508 [details]
>  --> https://bugs.freedesktop.org/attachment.cgi?id=59508
> dmesg of G45B with S-VIDEO
>
>   I try with
> Kernel: (drm-intel-next-queue)d9c33f85cf3cc3f8717e56d42fd678573ed1727d3
> which include the patch ,the bug still occurs,when I boot the machine with
> S-VIDEO ,the TV screen will trun to be black after loading drm driver.
>    but I try the
> Kernel: (drm-intel-fixes)b250da79a0c972ef7f6d58ebd1083cab066e6c82
> the issue don't occur.
>    BTW,the tile of this bug's platform is G45,but in the describe of the
> enviroment is piketon,I'm puzzled with this, and I test with G45.

This is really confusing because neither of these two trees contains
the patch. I'll push out a new -testing branch today anyway for the
next QA cycle, please retest on that on.

Ok, I've confused the issue with another one. Can you please double-check this issue? I don't have the -next-queued commit sha1 you've referred to.

And if the issue really still exist, _please_ reopen the bug report.

(In reply to comment #21)
> Ok, I've confused the issue with another one. Can you please double-check this
> issue? I don't have the -next-queued commit sha1 you've referred to.
> And if the issue really still exist, _please_ reopen the bug report.
   Sorry,daniel, here is a mistake about the -next-queued commit I test with,the commit should be:
Kernel: (drm-intel-next-queued)9c33f85cf3cc3f8717e56d42fd678573ed1727d3
I print a wrong brace. 
   BTW,I will try this bug with the next QA cycle.

Created attachment 59668 [details]
dmesg after booting WITH S-VIEDO

 On new round of QA cycle,I try with 
Kernel: (drm-intel-testing)295633246f8922f550971f810f09244a450b4ca6
the bug still occurs,

fatal: bad object 295633246f8922f550971f810f09244a450b4ca6
So what exactly did you test?

(In reply to comment #24)
> fatal: bad object 295633246f8922f550971f810f09244a450b4ca6
> So what exactly did you test?
   I'm sure the kernel commit I test with is like this,
Kernel: (drm-intel-testing)295633246f8922f550971f810f09244a450b4ca6
Some additional commit info:
Merge: 9c33f85 b4db1e3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Apr 5 11:32:57 2012 +0200

   like daniel do a revert after that,I try again with the newest -testing branch: Kernel: (drm-intel-testing)9d0b5b5468650e0ac72a7786cf6625963f926d4d 
the bug still occurs.

Yuang, can you please attach a new dmesg with drm.debug=0xe when running this on the next QA testing cycle? If the patch I've merged does not fix the bug, it's likely that something slightly changed.

Created attachment 61259 [details]
booting with S-Viedo drm.debug=0xe dmesg info

I try the new QA testing cycle with 
Kernel: (drm-intel-testing)25fcc53b96dd4801907d9b1cc4b76258ab0f3d65
the TV screen will trun to be black after loading drm driver.
 And I attach a dmesg with drm.debug=0xe

A patch referencing this bug report has been merged in Linux v3.5-rc1:

commit a0b1c7a5197293d6206b245b45edc3f508aadab6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Sep 30 22:56:41 2011 +0100

    drm/i915/sdvo: Include YRPB as an additional TV output type

Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks.

reopening. I don't know why this closed.

(In reply to comment #30)
> reopening. I don't know why this closed.

Because it was left in the NEEDINFO state for almost 6 months.

[  173.740078] [drm:output_poll_execute], [CONNECTOR:5:VGA-1] status updated from 2 to 2
[  173.740082] [drm:intel_sdvo_debug_write], SDVOC: W: 0B                         (SDVO_CMD_GET_ATTACHED_DISPLAYS)
[  173.771594] [drm:intel_sdvo_read_response], SDVOC: R: (Pending)... failed
[  173.776925] [drm:output_poll_execute], [CONNECTOR:61:VGA-2] status updated from 3 to 3

It looks like we need to learn how to flush the SDVO comms, or maybe try harder to read after a Pending.

First thought is something as silly as:

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c
index 0007a4d..ac1a8a8 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -523,13 +523,22 @@ static bool intel_sdvo_read_response(struct intel_sdvo *intel_sdvo,
 				  &status))
 		goto log_fail;
 
-	while (status == SDVO_CMD_STATUS_PENDING && retry--) {
-		udelay(15);
-		if (!intel_sdvo_read_byte(intel_sdvo,
-					  SDVO_I2C_CMD_STATUS,
-					  &status))
-			goto log_fail;
-	}
+	do {
+		int quick = 5;
+
+		while (status == SDVO_CMD_STATUS_PENDING && quick--) {
+			udelay(15);
+			if (!intel_sdvo_read_byte(intel_sdvo,
+						  SDVO_I2C_CMD_STATUS,
+						  &status))
+				goto log_fail;
+		}
+
+		if (status != SDVO_CMD_STATUS_PENDING || --loop == 0)
+			break;
+
+		msleep(15);
+	} while (1);
 
 	if (status <= SDVO_CMD_STATUS_SCALING_NOT_SUPP)
 		DRM_LOG_KMS("(%s)", cmd_status_names[status]);

But rumour has it, Daniel has the actual SDVO specs...

Please retest with latest dinq, specifically

commit 420a2882dd57653d305b801a5137935d46ef28f9
Author: Damien Lespiau <damien.lespiau@intel.com>
Date:   Mon Oct 29 15:25:35 2012 +0000

    drm/i915/tv: Use intel_flush_display_plane() to flush the primary plane

Created attachment 69285 [details]
dmesg info with patch

(In reply to comment #34)
> Please retest with latest dinq, specifically
> 
> commit 420a2882dd57653d305b801a5137935d46ef28f9
> Author: Damien Lespiau <damien.lespiau@intel.com>
> Date:   Mon Oct 29 15:25:35 2012 +0000
> 
>     drm/i915/tv: Use intel_flush_display_plane() to flush the primary plane
I try with the newest -queued kernel including this patch :
Kernel: (drm-intel-next-queued)806865d4fe74cda9ac19a09138a54b11fb220007
the issue still occurs and I attach the dmesg.

For a really simple test, just replace the udelay(15) there with a mdelay(15).

Created attachment 70357 [details] [review]
Increase the delay between SDVO response polling

It is not clear whether you ever tested the attached patch. Please do so.

Created attachment 70467 [details]
dmesg info with chris's patch

(In reply to comment #37)
> Created attachment 70357 [details] [review] [review]
> Increase the delay between SDVO response polling
> 
> It is not clear whether you ever tested the attached patch. Please do so.
I try the patch with newest -queued branch, the issue still occurs and I attach the dmesg

Well, the good news, Daniel, is that the patch works - it allows us to read back SDVO responses from the TV. The bad news is that the EDID turns out to be garbage - but all the other SDVO commands appear to be working, so probably a similar timing issue inside the DCC probe.

(In reply to comment #38)
> Created attachment 70467 [details]
> dmesg info with chris's patch
> 
> (In reply to comment #37)
> > Created attachment 70357 [details] [review] [review] [review]
> > Increase the delay between SDVO response polling
> > 
> > It is not clear whether you ever tested the attached patch. Please do so.
> I try the patch with newest -queued branch, the issue still occurs and I
> attach the dmesg

What issue occurs? The TV is detected now on S-VIDEO1 and we have modes. (It appears the garbage is being returned for SDVO/LVDS and that appears to be incorrect error handling within drm_edid.c). So can you please enlighten us on how the system now behaves?

(In reply to comment #40)
> (In reply to comment #38)
> > Created attachment 70467 [details]
> > dmesg info with chris's patch
> > 
> > (In reply to comment #37)
> > > Created attachment 70357 [details] [review] [review] [review] [review]
> > > Increase the delay between SDVO response polling
> > > 
> > > It is not clear whether you ever tested the attached patch. Please do so.
> > I try the patch with newest -queued branch, the issue still occurs and I
> > attach the dmesg
> 
> What issue occurs? The TV is detected now on S-VIDEO1 and we have modes. (It
> appears the garbage is being returned for SDVO/LVDS and that appears to be
> incorrect error handling within drm_edid.c). So can you please enlighten us
> on how the system now behaves?
when I boot the machine with S-VIDEO ,the TV screen will trun to be black after loading drm driver.

As we now appear to be talking to the TV, have you checked whether any of the reported modes work?

(In reply to comment #42)
> As we now appear to be talking to the TV, have you checked whether any of
> the reported modes work?
I fail to let any modes work.

Ok, looks like we have a deeper problem controlling this device -- though we are now at least successfully communicating.

A patch referencing this bug report has been merged in Linux v3.8-rc1:

commit fc37381cc8ae2c24b8ece33659e69a0605ca074c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Nov 23 11:57:56 2012 +0000

    drm/i915: Increase the response time for slow SDVO devices

(In reply to comment #45)
> A patch referencing this bug report has been merged in Linux v3.8-rc1:
> 
> commit fc37381cc8ae2c24b8ece33659e69a0605ca074c
> Author: Chris Wilson <chris@chris-wilson.co.uk>
> Date:   Fri Nov 23 11:57:56 2012 +0000
> 
>     drm/i915: Increase the response time for slow SDVO devices

Although a quite similar patch has been tried already, please re-test with v3.8-rc1 anyway to confirm this is still an issue.

(In reply to comment #46)
> (In reply to comment #45)
> > A patch referencing this bug report has been merged in Linux v3.8-rc1:
> > 
> > commit fc37381cc8ae2c24b8ece33659e69a0605ca074c
> > Author: Chris Wilson <chris@chris-wilson.co.uk>
> > Date:   Fri Nov 23 11:57:56 2012 +0000
> > 
> >     drm/i915: Increase the response time for slow SDVO devices
> 
> Although a quite similar patch has been tried already, please re-test with
> v3.8-rc1 anyway to confirm this is still an issue.

I try with the newest 3.8-rc2 kernel, the issue still occurs.The testing kernel is:
Kernel: (drm-intel-nightly)84814cd0d035c0da5a5d55c07309a85a1e524d4f

Can you please retest with the G45 cursor plane w/a -- try drm-intel-nightly?

Created attachment 76734 [details]
screenshot of login

(In reply to comment #48)
> Can you please retest with the G45 cursor plane w/a -- try drm-intel-nightly?

Hi, I try drm-intel-nightly, and found that the issue still there but some different. After bios phase, screen start to flicker. I attached screenshot in the attachment.

Kernel info as follows:
----------------------------
Kernel: (drm-intel-nightly)1c00d801aed3f4712209835d67a5a37d980433e7
Some additional commit info:
Merge: 03b5c6c 8698080
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 13 21:52:37 2013 +0100

By the way, can you please tell me if HDMI can work well with S-DVI card plugged in? Because HDMI display nothing with S-DVI card plugged in, I don't know if this is normal or just my wrong operation...

(In reply to comment #50)
> (In reply to comment #48)
> > Can you please retest with the G45 cursor plane w/a -- try drm-intel-nightly?
> 
> Hi, I try drm-intel-nightly, and found that the issue still there but some
> different. After bios phase, screen start to flicker. I attached screenshot
> in the attachment.
> 
> Kernel info as follows:
> ----------------------------
> Kernel: (drm-intel-nightly)1c00d801aed3f4712209835d67a5a37d980433e7
> Some additional commit info:
> Merge: 03b5c6c 8698080
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Wed Mar 13 21:52:37 2013 +0100
> 
> By the way, can you please tell me if HDMI can work well with S-DVI card

I'm sorry, it's SDVO not S-DVI, my spelling mistake

> plugged in? Because HDMI display nothing with S-DVI card plugged in, I don't
> know if this is normal or just my wrong operation...

Shot in the dark: Can you please try the below patch?

http://cgit.freedesktop.org/~danvet/drm/commit/?h=pll-limits-mess&id=e249fd0e4aacff8d7294b118763d504ab9f4e0d5

(In reply to comment #52)
> Shot in the dark: Can you please try the below patch?
> http://cgit.freedesktop.org/~danvet/drm/commit/?h=pll-limits-
> mess&id=e249fd0e4aacff8d7294b118763d504ab9f4e0d5

Hi, Daniel, with this patch the issue still there and seem more flicker.:'(

Can you please test the fdi-dither branch from my private git repo at:

http://cgit.freedesktop.org/~danvet/drm

(In reply to comment #54)
> Can you please test the fdi-dither branch from my private git repo at:
> 
> http://cgit.freedesktop.org/~danvet/drm

I have tested fdi-dither branch, this issue fixed on this branch. So, we can close this bug.

I think that has landed upstream.

(In reply to comment #56)
> I think that has landed upstream.

I have tested latest -next-queued kernel, the sdvo port worked well. I verified it here.

Closing old verified.