Bug 14792

Summary:	Misdetection of the TV output
Product:	Drivers	Reporter:	Santi (santi)
Component:	Video(DRI - Intel)	Assignee:	Wang, Zhenyu Z (zhenyu.z.wang)
Status:	RESOLVED PATCH_ALREADY_AVAILABLE
Severity:	normal	CC:	ajax, chris, daniel, jbarnes, meijer.o, pcjc2, riccardo.magliocchetti, rjw, tiwai, yakui.zhao, zhenyuw
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	v2.6.32-rc6-285-g27dfaf4	Subsystem:
Regression:	Yes	Bisected commit-id:
Bug Depends on:
Bug Blocks:	14885
Attachments:	dmesg output with a normal console remove tv hotplug status check 2.6.33-rc2 dmesg output with "drm.debug=0x06" 2.6.33-rc2+revert(27dfaf4f582) dmesg output with "drm.debug=0x06" 2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a good console 24627: 2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a "bad" console try the debug patch that uses the bios mechanism to detect TV try the updated patch the updated patch that Clear the TV sense state bits on cantiga to make TV detection reliable

Description Santi 2009-12-12 13:28:32 UTC

Created attachment 24162 [details]
dmesg output with a normal console

Hello,

  I've tested the lastes drm-2.6/drm-linus tree (v2.6.32-207-gd1ede14) now included in linus' tree (what will be 2.6.33-rc1) and found that it misdetects the TV output and I get a much smaller console. The first bad commit is:

v2.6.32-rc6-285-g27dfaf4

commit 27dfaf4f5825a119305db1bc63bef30ed400e376
Author: Adam Jackson <ajax@redhat.com>
Date:   Fri Nov 20 06:22:44 2009

    drm/i915: disable the interrupt hotplug for integrated TV output
    
    Otherwise, I'd get stuck in a loop where (afaict) output scan would
    trigger a TV interrupt, which would trigger a scan, etc.  TV load
    detection not being the fastest thing in the world, X would process
    requests very slowly.
    
    https://bugs.freedesktop.org/show_bug.cgi?id=24404
    
    Signed-off-by: Adam Jackson <ajax@redhat.com>
    Acked-by: Zhao Yakui <yakui.zhao@intel.com>
    Signed-off-by: Eric Anholt <eric@anholt.net>

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 120c77d..6b59602 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -877,7 +877,6 @@
 			 HDMID_HOTPLUG_INT_EN |	  \
 			 SDVOB_HOTPLUG_INT_EN |	  \
 			 SDVOC_HOTPLUG_INT_EN |	  \
-			 TV_HOTPLUG_INT_EN |	  \
 			 CRT_HOTPLUG_INT_EN)
 
 
-------------------------

and here you can find the dmesg (drm) differences between before and after that patch:

diff --git a/2.6.32-rc6-00284-g28cf798_20091212_1351/dmesg b/2.6.32-rc6-00285-g27dfaf4_20091212_1348/dmesg
--- a/2.6.32-rc6-00284-g28cf798_20091212_1351/dmesg
+++ b/2.6.32-rc6-00285-g27dfaf4_20091212_1348/dmesg
@@ -466,8 +466,9 @@ ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected String at index 1
 ACPI Warning for \_SB_.BAT0._BIF: Converted Buffer to expected String at index 12 (20090903/nsrepair-132)
 ACPI: Battery Slot [BAT0] (battery present)
 [drm] TV-21: set mode NTSC 480i 0
-[drm] LVDS-8: set mode 1440x900 c
-Console: switching to colour frame buffer device 180x56
+[drm] TV-21: set mode 848x480 2b
+[drm] LVDS-8: set mode 1440x900 2c
+Console: switching to colour frame buffer device 106x30
 fb0: inteldrmfb frame buffer device
 registered panic notifier
 acpi device:3b: registered as cooling_device2
@@ -747,13 +748,9 @@ EXT3-fs: mounted filesystem with ordered data mode.
 tg3 0000:09:00.0: irq 30 for MSI/MSI-X
 ADDRCONF(NETDEV_UP): eth0: link is not ready
 iwlagn 0000:0c:00.0: firmware: requesting iwlwifi-5000-2.ucode
-[drm] TV-21: set mode NTSC 480i 0
 iwlagn 0000:0c:00.0: loaded firmware version 8.24.2.12
-[drm] TV-21: set mode NTSC 480i 0
 Registered led device: iwl-phy0::radio
 Registered led device: iwl-phy0::assoc
 Registered led device: iwl-phy0::RX
 Registered led device: iwl-phy0::TX
 ADDRCONF(NETDEV_UP): wlan0: link is not ready
-[drm] TV-21: set mode NTSC 480i 0
-[drm] TV-21: set mode NTSC 480i 0

I have a Dell Latitude E5400 with an intel card:

with an intel card:

00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)

This bug is very similar to another fixed one that I also reported:

http://bugzilla.kernel.org/show_bug.cgi?id=13462

Just tell me if you need more info or you want me to try a patch.

Thanks,
Santi

Comment 1 zhenyuw 2009-12-28 03:28:13 UTC

Created attachment 24323 [details]
remove tv hotplug status check

Not sure if this is related, but we should remove tv status check after removing tv hotplug.

Comment 2 Santi 2009-12-29 00:17:21 UTC

There is no change with the patch from Comment #1.

One more thing I've noticed is that it works ok if the i915 driver is a module, not builtin (at least with your additional patch, I'll check also with a clean mainline linux).

Comment 3 Santi 2010-01-01 11:43:05 UTC

It also happens (works ok if built as a module, but not if builtin) with a clean mainline linux, 2.6.33-rc2.

And following Rafael's request I confirm that the bug still happens with the lastest release candidate, namely 2.6.33-rc2.

Santi

Comment 4 ykzhao 2010-01-05 01:15:18 UTC

Hi, Santi
    Will you please add the boot option of "drm.debug=0x06" on 2.6.33-rc2 and attach the output of dmesg?
    
    Thanks.

Comment 5 Santi 2010-01-05 09:00:32 UTC

Created attachment 24440 [details]
2.6.33-rc2 dmesg output with "drm.debug=0x06"

Comment 6 ykzhao 2010-01-15 08:31:23 UTC

HI, Santi
    Will you please revert the commit(27dfaf4f5825a119305db1bc63bef30ed400e376) on the 2.6.33-rc2 and attach the output of dmesg? Please also add the boot option of "drm.debug=0x06".

thanks.

Comment 7 Santi 2010-01-15 17:04:44 UTC

Created attachment 24574 [details]
2.6.33-rc2+revert(27dfaf4f582) dmesg output with "drm.debug=0x06"

Hi ykzhao,

  here you have the requested output, 2.6.33-rc2+revert(27dfaf4f582) dmesg output with "drm.debug=0x06".

Thanks,
Santi

Comment 8 Santi 2010-01-19 08:56:21 UTC

Created attachment 24627 [details]
2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a good console

Hi,

  occasionally the console boots OK. I'll send two dmesg outputs with the same kernel image (2.6.33-rc4-00189-g6ccf80e), one with a good console and the other with a "bad" console.

HTH,
Santi

Comment 9 Santi 2010-01-19 08:58:05 UTC

Created attachment 24628 [details]
 24627: 2.6.33-rc4-00189-g6ccf80e dmesg output with "drm.debug=0x06" and a "bad" console

Comment 10 Rafael J. Wysocki 2010-01-26 12:10:49 UTC

Handled-By : Zhao Yakui <yakui.zhao@intel.com>
First-Bad-Commit : 27dfaf4f5825a119305db1bc63bef30ed400e376

Does everything work correctly if you revert commit 27dfaf4f5825a119305db1bc63bef30ed400e376?

Comment 11 Santi 2010-01-26 12:59:01 UTC

(In reply to comment #10)
> Handled-By : Zhao Yakui <yakui.zhao@intel.com>
> First-Bad-Commit : 27dfaf4f5825a119305db1bc63bef30ed400e376
> 
> Does everything work correctly if you revert commit
> 27dfaf4f5825a119305db1bc63bef30ed400e376?

The problem is that it is no longer possible to revert this commit, as the HOTPLUG_EN_MASK macro was removed in commit b01f2c3a4a37d09a47ad73ccbb46d554d21cfeb0.

Thanks,
Santi

P.D.: The bug still exists in v2.6.33-rc5.

Comment 12 Jesse Barnes 2010-02-05 18:25:17 UTC

I'm confused by comment #3.  Do things work well if you build i915 modular?  Or do you still get the lower resolution in that case?  Also, can you set a higher resolution later on after the kernel has started up?  Or does the kernel or xrandr report fewer modes on the TV output than before?

Comment 13 Santi 2010-02-05 23:05:22 UTC

(In reply to comment #12)
> I'm confused by comment #3.  Do things work well if you build i915 modular?

Yes.

>  Or
> do you still get the lower resolution in that case?

No, I get the maximum resolution. But I would not call it lower resolution, as I think the resolution is the same, only that there is empty space on the right and below the text.

>  Also, can you set a higher
> resolution later on after the kernel has started up?

X always uses the maximum resolution, even when the console is using the lower resolution.

I don't know how to change the console mode at runtime. It seems I only have one console mode, either

$ cat /sys/class/graphics/fb0/modes
U:848x480p-0

or

$ cat /sys/class/graphics/fb0/modes
U:1440x900p-0


>  Or does the kernel or
> xrandr report fewer modes on the TV output than before?

I have nothing in attached on the TV output, so I don't know.

But now without connecting the TV output I get this:

$ xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
LVDS1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm x 190mm
   1440x900       60.0*+   59.9     40.0  
   1360x768       59.8  
   1152x864      100.0     85.1     85.0     75.0     75.0     70.0     60.0  
   1024x768       85.0     75.0     70.1     60.0  
   832x624        74.6  
   800x600        85.1     72.2     75.0     60.3     56.2  
   640x480        85.0     72.8     75.0     59.9  
   720x400        85.0  
   640x400        85.1  
   640x350        85.1  
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 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)
TV1 connected (normal left inverted right x axis y axis)
   848x480        30.0 +
   640x480        30.0 +
   1024x768       30.0  
   800x600        30.0  

while I don't get TV1 modes when the console is OK.

HTH,
Santi

Comment 14 Jesse Barnes 2010-02-05 23:30:16 UTC

Wow it's interesting that the TV would report different modes when modular vs. builtin.

But this really sounds like a TV detect bug.  Maybe the patch in https://bugs.freedesktop.org/show_bug.cgi?id=25913 helps?

Comment 15 Santi 2010-02-06 10:36:03 UTC

(In reply to comment #14)
> Wow it's interesting that the TV would report different modes when modular
> vs.
> builtin.
> 
> But this really sounds like a TV detect bug.

Yes, this is why the title is "Misdetection of the TV output" ;-)

>  Maybe the patch in
> https://bugs.freedesktop.org/show_bug.cgi?id=25913 helps?

Yes, thanks. I've restarted the machine five times in a row and the console (and xrandr output) are OK.

Thanks,
Santi

Comment 16 Jesse Barnes 2010-02-19 20:28:35 UTC

Zhenyu, since you're our TV out expert, can you take a look?

Thanks,
Jesse

Comment 17 Rafael J. Wysocki 2010-03-21 12:35:32 UTC

Zhenyu?

Comment 18 ykzhao 2010-03-25 03:18:46 UTC

Sorry for the late response.
   I also get one Dell e5400 laptop and reproduce this issue on this box. I will look at the TV detection.

thanks.

Comment 19 ykzhao 2010-03-26 09:47:00 UTC

Created attachment 25722 [details]
try the debug patch that uses the bios mechanism to detect TV

Hi, Santi
    Will you please try the attached patch and see whether the issue can be fixed?

Thanks.

Comment 20 Santi 2010-03-28 21:23:13 UTC

Hi,

  I can confirm that I no longer have this bug (testing on top of 2.6.33 and latest v2.6.34-rc2-219-ge1ee65d). But I cannot test if the TVout actually works.

Thanks,
Santi

Comment 21 ykzhao 2010-03-31 05:31:16 UTC

thanks for the testing.

It is good news that the issue of TV misdetection is gone after applying the patch in comment #19. 

I will try to push the patch in comment #19.

Thanks.
   Yakui

Comment 22 ykzhao 2010-04-02 07:01:25 UTC

Created attachment 25815 [details]
try the updated patch 

Hi, Santi
    Will you please try the updated patch and see whether the issue can be fixed?
    

Thanks.

Comment 23 Santi 2010-04-02 22:45:25 UTC

Hi Yakui,

  I've tried the update patch on top of v2.6.34-rc2-219-ge1ee65d and it works.

Thanks,
Santi

Comment 24 ykzhao 2010-04-07 00:30:00 UTC

Created attachment 25887 [details]
the updated patch that Clear the TV sense state bits on cantiga to make TV detection reliable

Hi, Santi
    thanks for the testing.
    The attached is the updated patch. There is no functional change. It will look clearer.

thanks.

Comment 25 Takashi Iwai 2010-04-21 14:09:14 UTC

The patch in comment 24 also fixes a problem on an HP laptop with GM45 here, too.

Tested-by: Takashi Iwai <tiwai@suse.de>

Comment 26 Rafael J. Wysocki 2010-04-21 15:46:56 UTC

Patch : https://bugzilla.kernel.org/attachment.cgi?id=25887
Handled-By : Zhao Yakui <yakui.zhao@intel.com>

Comment 27 Santi 2010-09-03 16:42:28 UTC

Hello,

  I've tested latest mainline kernel 2.6.36-rc3 and it is fixed. I've bisected it and found that the following patch fixes the problem:

commit 9d0498 (v2.6.35-5842-g9d0498a)
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Wed Aug 18 22:20:54 2010

    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 <jbarnes@virtuousgeek.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>

Thanks,
Santi

Comment 28 Santi 2010-09-08 22:17:29 UTC

Hi *,

  unfortunately it is no longer fixed. I've tested:

v2.6.36-rc3-185-gd56557a (Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6, 2010-09-07)

  and all the symptoms reappeared. It was fixed in v2.6.36-rc3.

I think it is because there is a partial revert:

commit 4f233eff6f32745f8894eb513bc59851213c7833
Author: Pekka Enberg <penberg@kernel.org>
Date:   Sat Sep 4 18:24:04 2010

    i915: Fix spurious TV detection after 9d0498a2bf + 9559fcdbff
    
    Partial revert of 9d0498a2bf.
    
    Signed-off-by: Pekka Enberg <penberg@kernel.org>
    Tested-by: Hugh Dickins <hughd@google.com>
    Tested-by: Sven Joachim <svenjoac@gmx.de>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Santi

Comment 29 Chris Wilson 2010-09-11 09:11:04 UTC

That's ok, it just means the code is still just as broken as it always was and no longer hidden by an even bigger bug.

Comment 30 Peter Clifton 2010-11-25 01:00:21 UTC

The patch in comment 24 has always fixed the problem for me, and I routinely re-patch it on top of drm-intel-next.

Can somone at intel get at the non-public HW docs and confirm Zhao Yakui's comments relating to buggy hardware?

Tested-by: Peter Clifton <pcjc2@cam.ac.uk>

Comment 31 o. meijer 2010-12-11 11:56:44 UTC

I encounter the same (sort of) bug with the same hardware. I can confirm that the patch in comment 24 always fixes the problem for me. (kernel 2.6.36.2 still contains the bug) My bug report can be found here.

https://bugzilla.kernel.org/show_bug.cgi?id=16236 (I am fairly sure that this is caused by the same bug, as the same patch fixes it)

I hope that this bug can be solved soon.

best regards,

otto meijer

Comment 32 Takashi Iwai 2012-03-02 08:35:30 UTC

FWIW, I've still seen this problem even on 3.0, 3.1 and 3.2 kernels with multiple machines (HP and Acer).  The bug rate is fairly rare, less than 1/20, though.

Comment 33 Daniel Vetter 2012-03-27 14:06:32 UTC

*** Bug 16236 has been marked as a duplicate of this bug. ***

Comment 34 Daniel Vetter 2012-03-27 14:07:42 UTC

Patch is on track for 3.5, already merged into drm-intel-next-queued as

commit d42c9e2c24f7e7897405b85816bdf4ac924881c0                                                                                      
Author: Daniel Vetter <daniel.vetter@ffwll.ch>                                                                                       
Date:   Sun Mar 25 22:56:14 2012 +0200                                                                                               
                                                                                                                                     
    drm/i915: reinstate GM45 TV detection fix