Bug 28012

Summary: [[945GM][KMS,TV-out]] KMS sets wrong clocks for TV-out
Product: DRI Reporter: Peter Hjalmarsson <xake>
Component: DRM/IntelAssignee: Rodrigo Vivi <rodrigo.vivi>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: medium CC: ben, chris, daniel, forest, jbarnes
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg with debug=0x06
none
output from xrandr --verbose of a clean (no xorg.conf) X, no other X programs
none
output from intel reg dumper
none
xrandr-verbose-kms
none
xrandr-verbose-ums
none
diff -u intel_reg_dumper-kms intel_reg_dumper-ums > intel_reg_dumper-diff
none
intel_reg_dumper-diff
none
xrandr-verbose-kms none

Description Peter Hjalmarsson 2010-05-07 01:36:22 UTC
Created attachment 35481 [details]
dmesg with debug=0x06

Information about my system:

$ uname -a
Linux pyttis 2.6.33-gentoo-r2 #1 SMP PREEMPT Tue May 4 09:10:05 CEST 2010 i686 Intel(R) Core(TM) Duo CPU T2350 @ 1.86GHz GenuineIntel GNU/Linux
$ lspci -s 00:02 -nnvv
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA controller])
	Subsystem: AOPEN Inc. Device [a0a0:0632]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at fde80000 (32-bit, non-prefetchable) [size=512K]
	Region 1: I/O ports at ff00 [size=8]
	Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
	Region 3: Memory at fdf80000 (32-bit, non-prefetchable) [size=256K]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
	Subsystem: AOPEN Inc. Device [a0a0:0632]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Region 0: Memory at fdf00000 (32-bit, non-prefetchable) [size=512K]
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

x11-libs/libdrm-2.4.20 
media-libs/mesa-7.7.1 
x11-base/xorg-server-1.7.7 
x11-drivers/xf86-video-intel-2.9.1 

System Information
	Manufacturer: FUJITSU SIEMENS
	Product Name: ESPRIMO Q5010
Base Board Information
	Manufacturer: AOpen
	Product Name: D2544-B1


The connectors on the systen are 1 DVI and 1 S-Video

I am running Gentoo, but I can reproduce this just by booting a Fedora13-beta liveusb or a Ubuntu 10.04 liveusb and watch the corruption on the TV as the system boots. 

I have a computer which I only use to provide contents to a TV. It is only connected to that old TV trough S-Video. The IGP is a 945GM.
It currently runs kernel 2.6.32.2 and xf86-video-intel-2.9.1 and xorg-server-1.7.6
I have tried with kernels from linus git tree (up to at least 2.6.34-rc6), with and without drm-intel-next merged on top, and with newer xf86-video-intel (both 2.10 and 2.11).


When I start my computer using KMS, both before and when X has started I see the picture on my TV "jumping" horizontally. I can only reproduce it with KMS and it seems dependent on the workload of the computer, as preventing X from start when I boot (leaving you with an almost stable console), ssh into the box and start for example compiling a kernel you will notice the console jumping faster and faster as the computer starts to work harder, and almost stops again when the compilation ends.

However  if I created a new mode with a much higher Mhz, say instead of:
  640x480 (0x44)   11.3MHz +preferred
        h: width   640 start  641 end  704 total  736 skew    0 clock   15.4KHz
        v: height  480 start  481 end  512 total  513           clock   30.0Hz

I use:
  mine (0x106)   25.0MHz *current
        h: width   640 start  641 end  704 total  736 skew    0 clock   34.0KHz
        v: height  480 start  481 end  512 total  513           clock   66.2Hz

The picture becomes stable.

As I do not know how and why this hits me I turn to you for help on how to debug this further and maybe fix it.
Comment 1 Peter Hjalmarsson 2010-05-07 01:37:51 UTC
Created attachment 35482 [details]
output from xrandr --verbose of a clean (no xorg.conf) X, no other X programs
Comment 2 Peter Hjalmarsson 2010-05-07 01:38:47 UTC
Created attachment 35483 [details]
output from intel reg dumper

If there is anything more I can provide, please feel free to ask for it.
Comment 3 Peter Hjalmarsson 2010-06-20 11:20:02 UTC
This day I tried out TV-out on an Acer TravelMate 5310, smolt-profile: http://www.smolts.org/client/show/pub_3e4e08ab-39e6-44c3-8771-1aa97500b7b7 and this did not work on that machine either.

How to reproduce:
1. Install a clean Fedora13 on you machine or run a Fedora13 LiveCD/LiveUSB
2. connect a TV to an S-video out on you computer
3. run xrandr --output TV1 --auto
4. do anything (opening and closing a gnome-menu, run glxgears, as long as the picture out is a static picture the corruption is minimal)
5. watch the TV and watch the corruption

Changing clocks fixed the problems, however as I do not know what values the clock is supposed to have I am afraid to fry something, so I do not even consider that as a workaround until someone tells me otherwise.
Comment 4 Chris Wilson 2010-07-21 08:53:14 UTC
The registers look consistent with the modelines, so I am guessing it's a case of garbage-in, garbage-out.

Peter, do you still have 2.9.1+ums paths available to compare and contrast, in particular the xrandr verbose output and intel_reg_dumper?
Comment 5 Peter Hjalmarsson 2010-07-21 09:43:32 UTC
Created attachment 37266 [details]
xrandr-verbose-kms

All following are from the same system, a Gentoo machine running xorg-server-1.7.7, xf86-video-intel-2.9.1 and a 2.6.34-kernel:

on the kernelcmd: i915.modeset=0 vga=0x314 video=640x480

# cat /etc/X11/xorg.conf
Section "Monitor"
	Identifier	"TV"
	Option		"PreferredMode"	"640x480"
	Option		"TV_Connector"	"S-video"
EndSection

Section "Device"
	Identifier	"GFX"
	Driver		"intel"
	Option		"monitor-TV1"	"TV"
EndSection

Only differences between runs where if I had modeset=1 or modeset=0 on the kernelcmd
Comment 6 Peter Hjalmarsson 2010-07-21 09:44:15 UTC
Created attachment 37267 [details]
xrandr-verbose-ums

$ diff -u xrandr-verbose-kms xrandr-verbose-ums 
--- xrandr-verbose-kms	2010-07-21 18:35:51.816451592 +0200
+++ xrandr-verbose-ums	2010-07-21 18:35:51.817451698 +0200
@@ -1,7 +1,7 @@
-Screen 0: minimum 320 x 200, current 640 x 480, maximum 4096 x 4096
-VGA1 disconnected (normal left inverted right x axis y axis)
+Screen 0: minimum 320 x 200, current 640 x 480, maximum 2048 x 2048
+VGA disconnected (normal left inverted right x axis y axis)
 	Identifier: 0x41
-	Timestamp:  83614
+	Timestamp:  39086
 	Subpixel:   unknown
 	Clones:    
 	CRTCs:      0 1
@@ -9,9 +9,9 @@
 	            0.000000 1.000000 0.000000
 	            0.000000 0.000000 1.000000
 	           filter: 
-DVI1 disconnected (normal left inverted right x axis y axis)
+TMDS-1 disconnected (normal left inverted right x axis y axis)
 	Identifier: 0x42
-	Timestamp:  83614
+	Timestamp:  39086
 	Subpixel:   horizontal rgb
 	Clones:    
 	CRTCs:      0 1
@@ -19,9 +19,9 @@
 	            0.000000 1.000000 0.000000
 	            0.000000 0.000000 1.000000
 	           filter: 
-TV1 connected 640x480+0+0 (0x44) normal (normal left inverted right x axis y axis) 0mm x 0mm
+TV connected 640x480+0+0 (0x44) normal (normal left inverted right x axis y axis) 0mm x 0mm
 	Identifier: 0x43
-	Timestamp:  83614
+	Timestamp:  39086
 	Subpixel:   unknown
 	Clones:    
 	CRTC:       0
@@ -30,24 +30,26 @@
 	            0.000000 1.000000 0.000000
 	            0.000000 0.000000 1.000000
 	           filter: 
-	bottom margin: 37 (0x00000025)	range:  (0,100)
-	right margin: 46 (0x0000002e)	range:  (0,100)
-	top margin: 36 (0x00000024)	range:  (0,100)
-	left margin: 54 (0x00000036)	range:  (0,100)
-	mode:	NTSC-M
+	HUE: -1221836800 (0xb72c4000)	range:  (0,255)
+	SATURATION: -1221836704 (0xb72c4060)	range:  (0,255)
+	CONTRAST: -1221836704 (0xb72c4060)	range:  (0,255)
+	BRIGHTNESS: -1221836672 (0xb72c4080)	range:  (0,255)
+	BOTTOM: 37 (0x00000025)	range:  (0,100)
+	RIGHT: 46 (0x0000002e)	range:  (0,100)
+	TOP: 36 (0x00000024)	range:  (0,100)
+	LEFT: 54 (0x00000036)	range:  (0,100)
+	TV_FORMAT:	NTSC-M
 		supported: NTSC-M       NTSC-443     NTSC-J       PAL-M       
-		           PAL-N        PAL          480p@59.94Hz 480p@60Hz   
-		           576p         720p@60Hz    720p@59.94Hz 720p@50Hz   
-		           1080i@50Hz   1080i@60Hz   1080i@59.94H
+		           PAL-N        PAL         
   640x480 (0x44)   11.3MHz *current +preferred
         h: width   640 start  641 end  704 total  736 skew    0 clock   15.4KHz
         v: height  480 start  481 end  512 total  513           clock   30.0Hz
-  848x480 (0x45)   14.5MHz +preferred
-        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
-  1024x768 (0x46)   26.9MHz
+  1024x768 (0x45)   26.9MHz
         h: width  1024 start 1025 end 1088 total 1120 skew    0 clock   24.0KHz
         v: height  768 start  769 end  800 total  801           clock   30.0Hz
-  800x600 (0x47)   17.0MHz
+  800x600 (0x46)   17.0MHz
         h: width   800 start  801 end  864 total  896 skew    0 clock   19.0KHz
         v: height  600 start  601 end  632 total  633           clock   30.0Hz
+  848x480 (0x47)   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
Comment 7 Peter Hjalmarsson 2010-07-21 09:47:00 UTC
Created attachment 37268 [details]
diff -u intel_reg_dumper-kms intel_reg_dumper-ums > intel_reg_dumper-diff

This is a diff between intel_reg_dumper for kms vs. ums, the files themselves where to big to attach. If you want me to attach them zipped just tell me.
Comment 8 Chris Wilson 2010-07-21 10:05:27 UTC
(In reply to comment #7)
> Created an attachment (id=37268) [details]
> diff -u intel_reg_dumper-kms intel_reg_dumper-ums > intel_reg_dumper-diff

Looks more like a intel_gpu_dump output, can you double check.

From the xrandr output it appears that the modelines are the same so we have not regressed in parsing the EDID. So presumably we are programming the output differently and now incompatibly with your display.
Comment 9 Peter Hjalmarsson 2010-07-21 10:25:40 UTC
Created attachment 37269 [details]
intel_reg_dumper-diff

I was certain I used intel_reg_dumper, but seems I was wrong for some reason... Here is the correct diff, if you want the full files I ca attach them too.
Comment 10 Chris Wilson 2010-07-21 10:39:43 UTC
Just to check, you used two different modes right? 800x600 in the first dump and 640x480 in the second? And the dual output was disabled in the second run.

The only other thing of real significance is that FrameBuffer Compression is only enabled in the second pass, that is for ums and not for kms. Weird.

Peter, can you confirm the sequence of ums vs kms and check that you are capturing the registers for the troublesome modes? Thanks.
Comment 11 Peter Hjalmarsson 2010-07-21 11:01:55 UTC
Created attachment 37275 [details]
xrandr-verbose-kms

My brain apparently does not work well when I am too warm, here I had attached the wrong file, but the diff in my comment above still stands.

In both tests I dumped while running X in 640x480 (as far as I know, and xrandr confirms it, defined in kernelcmd and xorg.conf as stated above).

In a clean X glxgears rolls clearly during kms but not during ums with this resolution.

The test system itself does only have one output currently, one S-Video cable. Nothing connected to the DVI port and no other connector/screen.
No dual output at all, and according to xrandr everything but TV is disconnected in both cases.

fbcompression may come from vesafb being used with ums, but not with kms?
Comment 12 Peter Hjalmarsson 2010-07-21 11:23:11 UTC
Ok, read you comment again, realized some stuff and took some other tests:

(In reply to comment #10)
> Just to check, you used two different modes right? 800x600 in the first dump
> and 640x480 in the second? And the dual output was disabled in the second run.
> 

Both are running X in 640x480.
The 800x600 seems to come from vga=0x314. If I change that to 0x311 that part of the output from intel_reg_dumper for kms changes too 640x480 too.
No dual displays any of the runs, only a S-video TV connected to the computer.

> Peter, can you confirm the sequence of ums vs kms and check that you are
> capturing the registers for the troublesome modes? Thanks.

It is the right sequence, the one I named kms seems to show kms, and the one named ums seems to show ums (ran intel_reg_dumper again and confirmed the output).
Comment 13 Chris Wilson 2010-07-21 11:25:25 UTC
Ah, the TV out swapped pipes between kms and ums, that was confusing me.

So the PLL timings for kms are:
  FPA0: 0x00020e08 (n = 2, m1 = 14, m2 = 8)
and for ums:
  FPA1: 0x00031108 (n = 3, m1 = 17, m2 = 8)

which says that we were allocating more lanes and more bandwidth to drive the TV under ums than now under kms. That correlates well with the observation that increasing the pixel clock improves the output.

As a test do you mind grabbing an intel_reg_dumper with the forced mode? If I am  on the right track, we should see a similar change in FPA0.
Comment 14 Peter Hjalmarsson 2010-07-21 12:55:25 UTC
Actually no.

I had to change machine and distribution because for some reason xrandr --addmode did not add the mode on the Gentoo machine.

This time around it is a laptop running Fedora 13.
Same chipset, same problem.
I did four testes with LVDS1 turned off on that machine so only TV1 was active.

I did about four test and evey time the output from intel_reg_dumper between "640x480" and "mine" (as I named my displaymode) did differ but newer ever on the same location.
I also really confirmed that with "640x480" the screen rolled and with "mine" it became stable.
Comment 15 Peter Hjalmarsson 2010-07-22 04:35:26 UTC
Got xrandr --newmode to work on the Gentoo machine.
Same result there. Every time I change the clock the picture goes stable, but the differences in the output from intel_reg_dumper is random.
Comment 16 Peter Hjalmarsson 2010-07-22 07:00:20 UTC
Looked at the Gentoo dumps ad they where less random then the Fedora13 ones.
These are not clean X sessions (having only xbmc running), if you want dumps with clean X I can create those later today.
In between the dumps where done, nothing was changed except shifting between 640x480 and "mine" (which I called my mode with the doubled Mhz).
the one with 640 in the name is the original mode, these with "mine" in the name is the working ones.


pyttis ~ # diff -u regs-640-2 regs-mine-2
--- regs-640-2	2010-07-22 13:37:44.548133195 +0200
+++ regs-mine-2	2010-07-22 13:37:37.852291496 +0200
@@ -3,8 +3,8 @@
                           EXCC: 0x00000000
                        HWS_PGA: 0x370d6000
                          IPEIR: 0x00000000
-                         IPEHR: 0x01800002
-                     INST_DONE: 0x7fffffc1
+                         IPEHR: 0x7d880000
+                     INST_DONE: 0x7f800081
                          NOPID: 0x00000000
                         HWSTAM: 0xfffceffe
                          SCPD0: 0x00000000
@@ -74,7 +74,7 @@
          DSPATILEOFF: 0x00000000
            PIPEACONF: 0x80000000 (enabled, single-wide)
             PIPEASRC: 0x027f01df (640, 480)
-           PIPEASTAT: 0x00000100 (status: DLINE_COMPARE_STATUS)
+           PIPEASTAT: 0x00000000 (status:)
    PIPEA_GMCH_DATA_M: 0x00000000
    PIPEA_GMCH_DATA_N: 0x00000000
      PIPEA_DP_LINK_M: 0x00000000
pyttis ~ # diff -u regs-640-3 regs-mine-3
--- regs-640-3	2010-07-22 13:39:11.904792973 +0200
+++ regs-mine-3	2010-07-22 13:39:05.141438457 +0200
@@ -3,8 +3,8 @@
                           EXCC: 0x00000000
                        HWS_PGA: 0x370d6000
                          IPEIR: 0x00000000
-                         IPEHR: 0x01800002
-                     INST_DONE: 0x7fffffc1
+                         IPEHR: 0x7f80000c
+                     INST_DONE: 0x7f000081
                          NOPID: 0x00000000
                         HWSTAM: 0xfffceffe
                          SCPD0: 0x00000000
@@ -74,7 +74,7 @@
          DSPATILEOFF: 0x00000000
            PIPEACONF: 0x80000000 (enabled, single-wide)
             PIPEASRC: 0x027f01df (640, 480)
-           PIPEASTAT: 0x00000100 (status: DLINE_COMPARE_STATUS)
+           PIPEASTAT: 0x00000000 (status:)
    PIPEA_GMCH_DATA_M: 0x00000000
    PIPEA_GMCH_DATA_N: 0x00000000
      PIPEA_DP_LINK_M: 0x00000000
Comment 17 Chris Wilson 2010-07-22 11:37:04 UTC
See also bug 23899.
Comment 18 Daniel Vetter 2012-02-24 07:44:22 UTC
Please retest with at least v3.3-rc4 kernel (or newer). That one contains fixes for the TV-out timings and clocks.
Comment 19 Daniel Vetter 2012-03-31 08:14:52 UTC
Reporter seems to have disappeared and the bug is presumably fixed by the TV clock fixes in 3.3. Closing, please reopen if this is not the case.
Comment 20 Peter Hjalmarsson 2012-04-01 02:43:48 UTC
(In reply to comment #19)
> Reporter seems to have disappeared and the bug is presumably fixed by the TV
> clock fixes in 3.3. Closing, please reopen if this is not the case.

Yeah, sorry about that. RL got me again.
I had to repurpose that machine, since it became too much work getting things working. So I currently have no easy access to a machine with which I can test this. If I get the chance to test this I will report back then.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.