Bug 26582

Created attachment 33322 [details]
Output of dmesg

from provided dmesg: 

[drm] 2: conflicting encoders switching off 9-pin DIN-1
[drm] in favor of DVI-I-1


and many lines like this ..... so TV-out simply not working. Try to force-off DVI-I-1 ?

If, by "force-off DVI-I-1" you mean execute xrandr with an appropriate --off option, this is done prior to both setting the 'tv standard' property and enabling the DIN output.

Is this what you mean by "force-off DVI-I-1"?

(In reply to comment #3)
> If, by "force-off DVI-I-1" you mean execute xrandr with an appropriate --off
> option, this is done prior to both setting the 'tv standard' property and
> enabling the DIN output.
> 
> Is this what you mean by "force-off DVI-I-1"?
> 

Yes. Guess you also tried to boot with only two output (screen + TV) connected?

(In reply to comment #4)
> Guess you also tried to boot with only two output (screen + TV) connected?

I hadn't, no.  When booting without the VGA display plugged in, the TV output is enabled from boot and is in NTSC format.  Setting the 'tv standard' property using xrandr does nothing at all; the display continues, it does not flicker and the output format does not change.

The Xorg.0.log for this instance is attached below.

Created attachment 33351 [details]
X log without VGA connector plugged in

When booting with the VGA display plugged in, setting the 'tv standard' property 'pal' after the DIN output has been enabled causes the display to go blank.  X and the driver believe that the output is active but the television displays no signal.

The Xorg.0.log for this instance is attached below.

Created attachment 33352 [details]
X log while setting the 'tv standard' property to kill TV output

Using an empty xorg.conf makes no difference whatsoever to the behavior of the 'tv standard' property.

I don't understand what exactly connected to this videocard ...


looking at radeon_encoders.c (gpu/drm/radeon) i found in func
atombios_dac_setup strange case switch:

else {
<------><------>switch (tv_std) {
<------><------>case TV_STD_PAL:
<------><------>case TV_STD_PAL_M:
<------><------>case TV_STD_SCART_PAL:
<------><------>case TV_STD_SECAM:
<------><------>case TV_STD_PAL_CN:
<------><------><------>args.ucDacStandard = ATOM_DAC1_PAL;
<------><------><------>break;
<------><------>case TV_STD_NTSC:
<------><------>case TV_STD_NTSC_J:
<------><------>case TV_STD_PAL_60:
<------><------>default:
<------><------><------>args.ucDacStandard = ATOM_DAC1_NTSC;
<------><------><------>break;

so, it will set NTSC even for PAL-60? Can you try change this or tv_std = line in the same function? (hardcoding ....)

Another pal/ntsc bug, but  this one seems to resolved?



http://bugs.freedesktop.org/show_bug.cgi?id=24150

(In reply to comment #10)
> I don't understand what exactly connected to this videocard ...

Ordinarily, a VGA monitor (HP L1909, 1280x1024); a DVI monitor (Dell 2408WFP, 1920x1200); and a PAL TV connected through the DIN->composite adapter.

> looking at radeon_encoders.c (gpu/drm/radeon) i found in func
> atombios_dac_setup strange case switch:

> so, it will set NTSC even for PAL-60? Can you try change this or tv_std = line
> in the same function? (hardcoding ....)

I have never set the 'tv standard' property to 'pal-60' so this will never have occurred.  Just to make the point, though, I have modified atombios_dac_setup like so:

        else {
          /*
                switch (tv_std) {
                case TV_STD_PAL:
                case TV_STD_PAL_M:
                case TV_STD_SCART_PAL:
                case TV_STD_SECAM:
                case TV_STD_PAL_CN:
                        args.ucDacStandard = ATOM_DAC1_PAL;
                        break;
                case TV_STD_NTSC:
                case TV_STD_NTSC_J:
                case TV_STD_PAL_60:
                default:
                        args.ucDacStandard = ATOM_DAC1_NTSC;
                        break;
                }
          */
          args.ucDacStandard = ATOM_DAC1_PAL;
        }

I tested this without the VGA monitor connected.  As expected, it made no difference.

(In reply to comment #11)
> Another pal/ntsc bug, but  this one seems to resolved?
> 
> http://bugs.freedesktop.org/show_bug.cgi?id=24150

The problem in that bug seems to be that the 'tv standard' property didn't exist.  I came across this bug as well.  That bug was fixed; the property does now exist.

The problem in this bug is that the 'tv standard' property does not work.

Ok, radeon_connectors.c has  radeon_connector_set_property function. It can exit due to few things ..try to add some DRM_INFO(); and find where exactly it aborts ....

<------>if (property == rdev->mode_info.tv_std_property) {
<------><------>encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_TVDAC);
<------><------>if (!encoder) {
<------><------><------>encoder = radeon_find_encoder(connector, DRM_MODE_ENCODER_DAC);
<------><------>}

<------><------>if (!encoder)
<------><------><------>return 0;

<------><------>radeon_encoder = to_radeon_encoder(encoder);
<------><------>if (!radeon_encoder->enc_priv)
<------><------><------>return 0;

sorry for <------> - copy/paste from MC (midnight commander) produces this ....

Having added DRM_INFO() calls throughout the function, I can say that it always returns from the final return statement; ie, it always completes and never aborts prematurely.

Did pal ever work properly for you?  Did pal work with UMS?

(In reply to comment #16)
> Did pal ever work properly for you?  Did pal work with UMS?

Yes, I can switch to PAL with UMS.  This is a regression.

(In reply to comment #17)
> (In reply to comment #16)
> > Did pal ever work properly for you?  Did pal work with UMS?
> 
> Yes, I can switch to PAL with UMS.  This is a regression.
> 

Can you dump the registers with the working UMS config and the non-working KMS config?  Use avivotool (available here: http://cgit.freedesktop.org/~airlied/radeontool or as a package for most distros) as root:

avivotool regs all > working.regs
avivotool regs all > broken.regs

and attach the output here.

(In reply to comment #18)

> Can you dump the registers with the working UMS config and the non-working KMS
> config?

Unfortunately no, I can't.  After cloning and building the radeontool tree, the avivotool program won't run with either UMS or KMS.  When executed as root, it hard-locks the machine.  When run as a user, it segfaults like so:

(gdb) run regs all
Starting program: /usr/local/src/radeontool/avivotool regs all
mapping ctrl region

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7bdc4be in pci_device_map_range () from /usr/lib/libpciaccess.so.0
(gdb) bt
#0  0x00007ffff7bdc4be in pci_device_map_range () from /usr/lib/libpciaccess.so.0
#1  0x00000000004063c8 in map_radeon_mem (argc=3, argv=0x7fffffffe310) at avivotool.c:1621
#2  main (argc=3, argv=0x7fffffffe310) at avivotool.c:2085
(gdb) l avivotool.c:1621
1616          
1617        if (pci_device_map_region(avivo_device, ctrl_region, 1) != 0)
1618            fatal("mapping ctrl region\n");
1619        ctrl_mem = avivo_device->regions[ctrl_region].memory;
1620
1621        if (pci_device_map_region(avivo_device, fb_region, 1) != 0)
1622            fatal("mapping fb region\n");
1623        fb_mem = avivo_device->regions[fb_region].memory;
1624
1625        pci_iterator_destroy(iter);
(gdb) 

Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the drm atom parser that may have fixed this.

(In reply to comment #20)
> Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the
> drm atom parser that may have fixed this.

Sorry, I'm a little confused here.  The kernel I'm using for KMS is from the drm-radeon-testing tree; would that not contain fixes from 2.6.34rc1?

(In reply to comment #21)
> (In reply to comment #20)
> > Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the
> > drm atom parser that may have fixed this.
> 
> Sorry, I'm a little confused here.  The kernel I'm using for KMS is from the
> drm-radeon-testing tree; would that not contain fixes from 2.6.34rc1?
> 

looks like that branch hasn't been updated in a while.  You're probably better off with drm-linus until Dave updates the drm-radeon-testing branch.
2.6.34rc1 should be the same as drm-linus from the drm's perspective.

(In reply to comment #20)
> Have you tried a newer drm?  2.6.33 or 2.6.34rc1?  There were some fixes to the
> drm atom parser that may have fixed this.

Alas, 2.6.34rc1 makes no difference.  The 'tv standard' property still does not work and avivotool still hard-locks the machine.

Created attachment 34763 [details] [review]
avivotool patch

Can you apply this patch to avivotool?  then dump the regs as before:
avivotool regs all

Created attachment 34767 [details]
Register dump of working state

Created attachment 34768 [details]
Register dump of broken state

(In reply to comment #24)

> Can you apply this patch to avivotool?  then dump the regs as before:
> avivotool regs all

Yes, this allows avivotool to run.  Register dumps are attached.

Created attachment 34805 [details]
Another register dump of broken state

I looked at the differences between the working dump and the two broken dumps and came up with a list of registers that are different to both broken dumps:

0000609c
00006120
00006134
00006408
00006410
00006548
0000654c
00006920
00006934
00006b6c
00006c08
00006d48
00006d4c
00006d50
00006d58
00006d78
00006d7c

I used avivotool to set each register in that list to the value in the working dump.  One, and only one register, 0x6120, had any effect on the TV output:

rah@myrtle:/usr/local/src/radeontool$ sudo ./avivotool regset 0x00006120 0x00000d00
OLD: 0x00006120 (6120)  0x00000b80 (2944)
NEW: 0x00006120 (6120)  0x00000d00 (3328)
rah@myrtle:/usr/local/src/radeontool$

Unfortunately, it didn't set it to PAL.  It simply made the TV output appear as a CRT monitor with bad signal timings.

(In reply to comment #29)

> rah@myrtle:/usr/local/src/radeontool$ sudo ./avivotool regset 0x00006120
> 0x00000d00
> OLD: 0x00006120 (6120)  0x00000b80 (2944)
> NEW: 0x00006120 (6120)  0x00000d00 (3328)
> rah@myrtle:/usr/local/src/radeontool$
> 
> Unfortunately, it didn't set it to PAL.  It simply made the TV output appear as
> a CRT monitor with bad signal timings.  


that register is the crtc pitch.  It will vary based on the size of your desktop surface.

Created attachment 34810 [details] [review]
another avivotool patch

Hopefully this one won't hang.  dump some more info.

Created attachment 34813 [details]
New patch register dump of working state

Created attachment 34814 [details]
New patch register dump of broken state #1

Created attachment 34815 [details]
New patch register dump of broken state #2

Created attachment 34816 [details]
List of common registers differing between working/broken states

Register dumps attached.

While in the broken state, I attempted to poke each register with the value from the working state.  The following registers did bad things to either the non-TV output or TV output or both: 0x6920, 0x6120, 0x6910, 0x6110, 0x444.

The following registers did bad things to the TV output: 0x43c, 0x430, 0x404.  Specifically, they made the TV output appear as a CRT with bad signal timings.

Of particular interest is register 0x430.  In the working configuration, this has the value 0x620030.  Setting the register with this value in the broken configuration made the TV output appear as a CRT with bad signal timings, as noted.  However, setting it with the value 0x6a0000 made the TV output appear almost like a correct PAL output, as shown in this photograph:

  http://pkl.net/~node/misc/radeon-almost-pal.jpg

Does changing the following regs help?

avivotool regset 0x404 0x0000800b
avivotool regset 0x430 0x00620030
avivotool regset 0x43c 0x00000006

Created attachment 34818 [details] [review]
possible fix

Does this drm patch help?  It looks like the tv is rather picky about it's clock. using the fractional fb div should get us much more exact.

(In reply to comment #37)
> Does changing the following regs help?
> 
> avivotool regset 0x404 0x0000800b
> avivotool regset 0x430 0x00620030
> avivotool regset 0x43c 0x00000006

Yes, this (finally) sets the TV output to correct, stable PAL output.


(In reply to comment #38)
> Created an attachment (id=34818) [details]
> possible fix
> 
> Does this drm patch help?  It looks like the tv is rather picky about it's
> clock. using the fractional fb div should get us much more exact.

Strangely, no.  After applying this patch, the output is closer to PAL than the previous close-to-PAL effort:

  http://pkl.net/~node/misc/radeon-almost-pal-2.jpg


When setting the registers as above, the output is a proper PAL signal.  However, it is unstable.  Specifically, after displaying a full-screen video on a different monitor, the TV output will start flickering with what looks like a black box coming out of the noise in between frames.

Created attachment 34851 [details] [review]
possible fix

Does this patch work any better?

(In reply to comment #40)
> Created an attachment (id=34851) [details]
> possible fix
> 
> Does this patch work any better?

Yes, the output is proper PAL with this patch.


Unfortunately, the VGA output is still broken, as in bug 25520 :

  https://bugs.freedesktop.org/show_bug.cgi?id=25520

Fix sent to Dave.