Bug 16871 - i915: bisected - "TV1 connected" with no tv
Summary: i915: bisected - "TV1 connected" with no tv
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri-intel@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-24 12:04 UTC by Luca
Modified: 2011-01-23 16:25 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.36-rc2
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments

Description Luca 2010-08-24 12:04:00 UTC
After commit 3fdef0205e69b80c4219f14b834cb85eb719039f xrandr find a connected TV when no tv is connected.

3fdef0205e69b80c4219f14b834cb85eb719039f is the first bad commit
commit 3fdef0205e69b80c4219f14b834cb85eb719039f
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Thu Aug 19 09:46:15 2010 +0800

    drm/i915: fix render pipe control notify on sandybridge
    
    This one is missed in last pipe control fix for sandybridge,
    that really unmask interrupt bit for notify in render engine IMR.
    
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Eric Anholt <eric@anholt.net>

:040000 040000 c36d296bc15536a651e8d12e0133d5c729d1f225 12ae3425ce19c905da747818d9bcb7e5673e4cc5 M      drivers

============================================================
Linux paolaws2 2.6.35-05848-g3fdef02 #63 PREEMPT Tue Aug 24 10:40:45 CEST 2010 i686 GNU/Linux
 
Gnu C                  4.4.5
Gnu make               3.81
binutils               2.20.1
util-linux             scripts/ver_linux: 23: fdformat: not found
mount                  support
module-init-tools      found
Linux C Library        2.11.2
Dynamic linker (ldd)   2.11.2
Procps                 3.2.8
Kbd                    [opzione...]
Console-tools          0.2.3
Sh-utils               8.5
Modules Loaded         mperf cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative uinput fuse nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss sunrpc loop arc4 ecb snd_hda_codec_realtek snd_hda_intel snd_hda_codec ath5k snd_hwdep snd_pcm_oss snd_mixer_oss mac80211 snd_pcm uvcvideo snd_seq_midi ath videodev snd_rawmidi joydev snd_seq_midi_event i915 v4l1_compat snd_seq cfg80211 drm_kms_helper snd_timer drm snd_seq_device rfkill snd psmouse i2c_i801 i2c_algo_bit soundcore intel_agp tpm_tis i2c_core tpm video agpgart ac output snd_page_alloc tpm_bios led_class wmi serio_raw pcspkr button evdev battery processor ext3 jbd mbcache dm_mod sd_mod crc_t10dif ata_generic pata_acpi uhci_hcd ahci libahci ata_piix libata ehci_hcd tg3 thermal scsi_mod usbcore libphy thermal_sys nls_base
=====================================================================
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 331mm x 207mm
   1280x800       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  
VGA1 disconnected (normal left inverted right x axis y axis)
TV1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   848x480        30.0 +
   640x480        30.0 +
   1024x768       30.0* 
   800x600        30.0  
==========================================================================
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Acer Incorporated [ALI] Device 0136
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at 54000000 (64-bit, non-prefetchable) [size=1M]
	Memory at 40000000 (64-bit, prefetchable) [size=256M]
	I/O ports at 5110 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
	Capabilities: [d0] Power Management version 3
	Kernel driver in use: i915
Comment 1 Chris Wilson 2010-08-24 12:42:51 UTC
You might want to double check your bisection. That code isn't even touched for your chipset. Sporadic TV misdetection has been around for a long time, and other bisection results indicate that the problem has been exacerbated by:

commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
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 <jbarnes@virtuousgeek.org>
    Signed-off-by: Eric Anholt <eric@anholt.net>
Comment 2 Luca 2010-08-25 13:42:57 UTC
I double check my bisection, I can confirm you that
9d0498a2bf7455159b317f19531a3e5db2ecc9c4 is the bad commit.

Thanks,
Luca

On Tue, Aug 24, 2010 at 2:43 PM,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=16871
>
>
> Chris Wilson <chris@chris-wilson.co.uk> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |chris@chris-wilson.co.uk
>
>
>
>
> --- Comment #1 from Chris Wilson <chris@chris-wilson.co.uk>  2010-08-24
> 12:42:51 ---
> You might want to double check your bisection. That code isn't even touched
> for
> your chipset. Sporadic TV misdetection has been around for a long time, and
> other bisection results indicate that the problem has been exacerbated by:
>
> commit 9d0498a2bf7455159b317f19531a3e5db2ecc9c4
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> 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 <jbarnes@virtuousgeek.org>
>    Signed-off-by: Eric Anholt <eric@anholt.net>
>
> --
> Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
>
Comment 3 Florian Mickler 2011-01-23 16:25:58 UTC
fixed in .37-rc1:
commit b7ac36dadafa69214faa75a34844d56bd0c14e89
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Aug 24 16:07:16 2010 +0100

    drm/i915/tv: After disabling the pipe, use wait_for_vblank_off()

Note You need to log in before you can comment on or make changes to this bug.