Bug 10418

Summary: Powerbook DVI out only works when booted with monitor attached
Product: xorg Reporter: Sjoerd Simons <sjoerd>
Component: Driver/RadeonAssignee: xf86-video-ati maintainers <xorg-driver-ati>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium CC: alexdeucher, hvr, magnade, phil, sjoerd
Version: git   
Hardware: PowerPC   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
Xorg log when the monitor wasn't attached at bootup (thus non-working)
none
Xorg log of when the monitor was attached at bootup (Thus working dvi out)
none
Dump of all registers while in X with working dvi out
none
Dump of all register while in X with non-working dvi-out
none
Hack to program my tdms
none
Xorg log of 15" hr alu powerbook
none
diff of working and not working reg output none

Description Sjoerd Simons 2007-03-27 02:04:11 UTC
When playing with the latest git of the radeon driver, i suddenly got my 
DVI out to work! (which i never could get before).. 

Unfortunately it only works if the monitor was attached during bootup as openfirmware does some initialisation that xorg apparently doesn't.. When i start
X when the monitor is attached after bootup, X thinks it's there but the monitor doesn't detect any input :( 

This is on a Powerbook G4 (PowerBook5,2) with an ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] video card.

I'll attach the logs of both booting with working and non-working dvi output.
Comment 1 Sjoerd Simons 2007-03-27 02:05:19 UTC
Created attachment 9303 [details]
Xorg log when the monitor wasn't attached at bootup (thus non-working)
Comment 2 Sjoerd Simons 2007-03-27 02:05:51 UTC
Created attachment 9304 [details]
Xorg log of when the monitor was attached at bootup (Thus working dvi out)
Comment 3 Alex Deucher 2007-03-27 05:23:59 UTC
Can you use radeontool (http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary) to dump the regs in both instances?

radeontool regmatch '*'

Comment 4 Sjoerd Simons 2007-03-27 06:40:55 UTC
Created attachment 9308 [details]
Dump of all registers while in X with working dvi out
Comment 5 Sjoerd Simons 2007-03-27 06:41:36 UTC
Created attachment 9309 [details]
Dump of all register while in X with non-working dvi-out
Comment 6 Roland Scheidegger 2007-03-27 06:46:05 UTC
(In reply to comment #2)
> Xorg log of when the monitor was attached at bootup (Thus working dvi out)
A quick diff shows that there seems to be only one relevant difference, the P2PLL_CNTL pll reg has a different value. Not sure if that's critical or not, but only parts are different which are never touched by the driver and should be programmed by bios. (the reg dump may show more differences of course.)
Comment 7 Alex Deucher 2007-03-27 21:25:37 UTC
these are the relevant registers:
-FP_GEN_CNTL (0284)     0x00000100
-FP2_GEN_CNTL (0288)    0x0300000c
+FP_GEN_CNTL (0284)     0x00000000
+FP2_GEN_CNTL (0288)    0x1240040c

It looks like your Powerbook uses an external TMDS transmitter rather than the built in one.  This makes sense as I think the Powerbook can drive the big Apple monitor which requires dual link TMDS.  It works because the bios takes care of initializing and powering up the external chip.  Unfortunately, we don't have any working code yet for dealing with external TMDS chips.
Comment 8 Benjamin Herrenschmidt 2007-03-27 22:26:51 UTC
Some powerbooks do indeed (not all though and I don't know for sure how to detect... I suppose the best thing is to try to probe for the encoder on i2c).

The machine I have here always initializes the encoder though, wether a monitor is plugged or not. However, the encoder "state" is lost on sleep/wakeup.

I have started to hack something in radeonfb to save/restore the encoder state on sleep/resume but it's part of some major radeonfb work that is very unfinished and isn't quite working yet.

Another option would be to write a little program that uses the linux userland i2c APIs to access the radeon i2c busses (they are exposed, iirc, the encoder is on the "monid" bus). The encoder is a SiL164 or compatible. Just dumps it's registers when it's been setup by the firmware and then write a program to reconfigure it..
Comment 9 Sjoerd Simons 2007-03-28 04:51:09 UTC
I wrote a small quick program to access the i2c bus and dump the registers. Unfortunately i could only access the i2c bus after a suspend(?). If it try before 
i get EREMOTEIO when doing the I2C_SLAVE ioctl...

Anyway after some tinkering (based on the sil164 supprt in the intell driver), i can enable the dvi output but it's not quite right yet.. It's got a slight greenish haze and some other artifacts also the monitor reports it's using 1598x1200 instead of 
1600x1200 which is what X should be sending it.. 

Seems quite close though.. I'll probably try later this week to see if i can get the radeon i2c support to let me read the registers before suspend and thus know what the working setting should be :)

Comment 10 Benjamin Herrenschmidt 2007-03-28 05:09:43 UTC
I remember having that sort of problem though I'm not sure what's up. It could be some of the hackery radeonfb does after ddc probing, or it might be that you need to actually write to the SiL chip once (an address) before you can read back from it, not sure ...
Comment 11 Alex Deucher 2007-03-28 05:38:03 UTC
FWIW, airlied has some experimental support for sil164s here:
http://gitweb.freedesktop.org/?p=users/airlied/xf86-video-ati.git;a=shortlog;h=sil164-support
might be a good start.  Although I would have thought the Powerbook would have used an sil1178 or similar dual link chip so it could drive the big Apple monitor; depends on the model I guess.

I have a radeon with an sil1162, however I cannot seem to get any response from it via the bit-banging interface, so started work on full i2c support based on the gatos code:
http://gitweb.freedesktop.org/?p=users/agd5f/xf86-video-ati.git;a=summary

Comment 12 Benjamin Herrenschmidt 2007-03-28 15:00:48 UTC
I'm also thinking that your problem with the encoder not showing up might be radeonfb's ddc code screwing up the i2c lines enough to upset the chip.

Can you try hacking into radeonfb to make it not touch the i2c bus where the encoder is when doing ddc ?

Ben.
Comment 13 Alex Deucher 2007-03-28 15:12:54 UTC
(In reply to comment #12)
> I'm also thinking that your problem with the encoder not showing up might be
> radeonfb's ddc code screwing up the i2c lines enough to upset the chip.
> 
> Can you try hacking into radeonfb to make it not touch the i2c bus where the
> encoder is when doing ddc ?
> 

This is all from X.  I'm not running radeonfb.
Comment 14 Benjamin Herrenschmidt 2007-03-28 15:20:02 UTC
Oh sorry, I was asking Sjoerd to try that... he's on a mac so he's probably using radeonfb. X might cause a similar problem though if it whacks the i2c lines to the encoder too much
Comment 15 Sjoerd Simons 2007-06-05 09:45:24 UTC
Sorry for the late reply. I did look at the radeonfb code, but nothing i changed appeared to make a lot of difference.. Some handholding in what to change to 
would be appreciated :)
Comment 16 Sjoerd Simons 2007-09-01 11:04:44 UTC
I picked this up once again. Some more digging and trying to understand how things works i found out the following.

After boot the GPIO_MONID register is set to 0x00000303. Unsetting the VGA_DDC_DATA_OUTPUT and VGA_DDC_CLK_OUTPUT bits makes talking over the i2c bus work for me... 
Comment 17 Sjoerd Simons 2007-09-01 13:01:05 UTC
Now that i can get the correct registers settings from the tdms via i2c. I've been able to write a small program to reprogram it so i can also use DVI out when i didn't boot with a screen connected.

Apart from setting up the TDMS i also have to set the FP2_GEN_CNTL register to 0x1240040c, which is the value OFW sets it to when booting with a DVI screen attached. FWIW when not booting with a screen connected it's initialised by OFW
to 0x01000008.
Comment 18 Alex Deucher 2007-09-01 13:27:16 UTC
(In reply to comment #17)
> Now that i can get the correct registers settings from the tdms via i2c. I've
> been able to write a small program to reprogram it so i can also use DVI out
> when i didn't boot with a screen connected.
> 
> Apart from setting up the TDMS i also have to set the FP2_GEN_CNTL register to
> 0x1240040c, which is the value OFW sets it to when booting with a DVI screen
> attached. FWIW when not booting with a screen connected it's initialised by OFW
> to 0x01000008.
> 

Please post your program and I'll get it integrated.  Do you know what tmds chip is used in your powerbook?
Comment 19 Sjoerd Simons 2007-09-01 13:42:58 UTC
Created attachment 11380 [details]
Hack to program my tdms
Comment 20 Sjoerd Simons 2007-09-01 13:49:38 UTC
I'm not sure what TDMS i have. Benjamin said it was a Sil164 or compatible. So i looked into the intel driver code which has sil164 support and used the ``recommended programming sequence'' as commented in their sil164.c sil164_mode_set function.. With as only change setting register 0x8 to 0x3b as final write instead of 0x31 (as OFW programmed it that way too)

Airlied started a branch to get sil164 support into the ati driver somewhere last year, but the branch seems quite stale :(     
  http://cgit.freedesktop.org/~airlied/xf86-video-ati/log/?h=sil164-support
Comment 21 Alex Deucher 2007-09-17 22:35:07 UTC
I just made an initial commit to support external tmds in ati git master.  Can you test and let me know how it goes?
Comment 22 Sjoerd Simons 2007-09-18 01:02:28 UTC
<Insert sounds of joy and happiness here>

It works perfectly for me! If you want logs and/or more machine details please
 let me know :)

Comment 23 Alex Deucher 2007-09-30 10:24:51 UTC
I've implemented this slightly differently in the latest ati git.  Can you try that and confirm that it works?
Comment 24 Herbert Valerio Riedel 2007-10-03 02:32:27 UTC
jfyi, I got a 

machine         : PowerBook5,8
motherboard     : PowerBook5,8 MacRISC3 Power Macintosh 
detected as     : 287 (PowerBook G4 15")

0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] (prog-if 00 [VGA])

aka powerbook g4 15 hr (oct 2005)

which also has the problem of not being able to initialize the external TMDS from Xorg;

...and yesterdays git head was not able to initialize the TMDS either... :-(
Comment 25 Michel Dänzer 2007-10-03 02:41:54 UTC
(In reply to comment #24)
> ...and yesterdays git head was not able to initialize the TMDS either... :-(

If that's with Option "MacModel" "powerbook-duallink", please attach the full Xorg.0.log.
Comment 26 Herbert Valerio Riedel 2007-10-03 11:45:06 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > ...and yesterdays git head was not able to initialize the TMDS either... :-(
 
> If that's with Option "MacModel" "powerbook-duallink", please attach the full
> Xorg.0.log.

yes, it's with that option... will do asap; in the mean-time I played around looking at the i2c accessible registers (I really wish I had a data-sheet for the TDMS) and found out the following:

the columns 'setup' shows the values after booting up with DVI attached and the TDMS properly setup (i.e. working DVI output) by open firmware; whereas the 'reset' column shows the registers after powering up without any DVI monitor attached (or alternatively what they look like after waking up the powerbook from standby);

since fiddling with 0x8/0x9/0xa/0xc alone doesn't seem to be enough, I tried replicating all seven registers which finally got me a picture with the right resolution on DVI, alas with completely wrong colors, as if the data bitstream coming out the DVI port is slightly off and thus causes rgb-values to be messed up... :-(

reg | setup | reset |
0x8 |  0x33 | 0x34  |
0x9 |  0x34 | 0x20  |
0xa |  0x80 | 0x90  |
0xc |  0xc9 | 0x89  |
0xd |  0x70 | 0x60  |
0xe |  0x01 | 0x00  |
0xf |  0x4c | 0x0c  |
Comment 27 Herbert Valerio Riedel 2007-10-03 11:51:58 UTC
Created attachment 11891 [details]
Xorg log of 15" hr alu powerbook
Comment 28 Alex Deucher 2007-10-03 11:59:47 UTC
(In reply to comment #26)
> 
> yes, it's with that option... will do asap; in the mean-time I played around
> looking at the i2c accessible registers (I really wish I had a data-sheet for
> the TDMS) and found out the following:

most of the sil ones are available, although, you'd have to open up your laptop to figure out which one you had unless OSX tells you somewhere.

> 
> the columns 'setup' shows the values after booting up with DVI attached and the
> TDMS properly setup (i.e. working DVI output) by open firmware; whereas the
> 'reset' column shows the registers after powering up without any DVI monitor
> attached (or alternatively what they look like after waking up the powerbook
> from standby);
> 
> since fiddling with 0x8/0x9/0xa/0xc alone doesn't seem to be enough, I tried
> replicating all seven registers which finally got me a picture with the right
> resolution on DVI, alas with completely wrong colors, as if the data bitstream
> coming out the DVI port is slightly off and thus causes rgb-values to be messed
> up... :-(

You probably either have a different TMDS chip in your laptop that needs an alternate setup, or the chip needs different set up for single vs. dual link mode.  What size panel are you using?  Regarding the color issues, you probably need to tweak FP2_GEN_CNTL.  you might want to dump that reg before starting X to see what the firmware sets it too.  Also there is some commented out code in RADEONInitFP2Registers() that you probably need to enable for things to work properly on your chip.
Comment 29 Herbert Valerio Riedel 2007-10-04 00:22:08 UTC
(In reply to comment #28)
> You probably either have a different TMDS chip in your laptop that needs an
> alternate setup, or the chip needs different set up for single vs. dual link
> mode.  What size panel are you using? 

right now I'm using a 1600x1200 external panel, which afaik can be driven single link (as I've been using it on my single-link mac mini as well :-)

> Regarding the color issues, you 
> probably need to tweak FP2_GEN_CNTL. 

...I just tried with radeontool to make registers look the same as when colors are correct, but I couldn't get it to improve the situation; the following are the register values for a properly working dualhead setup:

RADEON_DAC_CNTL ff002102
RADEON_DAC_EXT_CNTL     00000000
RADEON_DAC_MACRO_CNTL   00000705
RADEON_DAC_CNTL2        00000020
RADEON_TV_DAC_CNTL      07760140
RADEON_DISP_OUTPUT_CNTL 00000000
RADEON_CONFIG_MEMSIZE   08000000
RADEON_AUX_SC_CNTL      00000000
RADEON_CRTC_EXT_CNTL    00000040
RADEON_CRTC_GEN_CNTL    03200600
RADEON_CRTC2_GEN_CNTL   02200600
RADEON_DEVICE_ID        00074e50
RADEON_DISP_MISC_CNTL   33300600
RADEON_GPIO_MONID       00000300
RADEON_GPIO_MONIDB      00000000
RADEON_GPIO_CRT2_DDC    00000000
RADEON_GPIO_DVI_DDC     00000300
RADEON_GPIO_VGA_DDC     00000300
RADEON_LVDS_GEN_CNTL    000dd9a5
RADEON_FP_GEN_CNTL      00034048
RADEON_FP2_GEN_CNTL     1240040c
RADEON_PIXCLKS_CNTL     30000000


> you might want to dump that reg before starting X
> to see what the firmware sets it too.  Also there is some commented out code in
> RADEONInitFP2Registers() that you probably need to enable for things to work
> properly on your chip.

...except that it doesn't compile (the #defined constants are missing) :-)

Comment 30 Alex Deucher 2007-10-04 06:06:54 UTC
(In reply to comment #29)
> (In reply to comment #28)
> > You probably either have a different TMDS chip in your laptop that needs an
> > alternate setup, or the chip needs different set up for single vs. dual link
> > mode.  What size panel are you using? 
> 
> right now I'm using a 1600x1200 external panel, which afaik can be driven
> single link (as I've been using it on my single-link mac mini as well :-)

Right.  I saw your log after I replied.  that should be single link.  It's probably a different TMDS chip.  If you have an sil chip, try reading back the values from 0x00 and 0x02.  Those are the vendor and device ids for the chip.  you can find links to a bunch of sil and other TMDS chip databooks here:
http://wiki.x.org/wiki/DataSheets
It also may be an ordering issue. The sil164, you need to set up the chip properly before setting the enable bit (bit 0 IIRC) in 0x08.

> 
> ...except that it doesn't compile (the #defined constants are missing) :-)
> 

Fixed now in git.
Comment 31 Herbert Valerio Riedel 2007-10-04 07:13:33 UTC
(In reply to comment #30)
> > right now I'm using a 1600x1200 external panel, which afaik can be driven
> > single link (as I've been using it on my single-link mac mini as well :-)
 
> Right.  I saw your log after I replied.  that should be single link.  It's
> probably a different TMDS chip.  If you have an sil chip, try reading back the
> values from 0x00 and 0x02.  Those are the vendor and device ids for the chip.

well, reading back those registers, I get what's expected for the vendor and device id according to the sil164 data-sheet:

(II) RADEON(0): HVR: reg 00 = 01
(II) RADEON(0): HVR: reg 01 = 00
(II) RADEON(0): HVR: reg 02 = 06
(II) RADEON(0): HVR: reg 03 = 00
(II) RADEON(0): HVR: reg 04 = 00
(II) RADEON(0): HVR: reg 05 = 00
(II) RADEON(0): HVR: reg 06 = 19
(II) RADEON(0): HVR: reg 07 = a5
(II) RADEON(0): HVR: reg 08 = 33
(II) RADEON(0): HVR: reg 09 = 34
(II) RADEON(0): HVR: reg 0a = 80
(II) RADEON(0): HVR: reg 0b = 00
(II) RADEON(0): HVR: reg 0c = c9
(II) RADEON(0): HVR: reg 0d = 70
(II) RADEON(0): HVR: reg 0e = 01
(II) RADEON(0): HVR: reg 0f = 4c

> you can find links to a bunch of sil and other TMDS chip databooks here:
> http://wiki.x.org/wiki/DataSheets

thx 4 the pointer

> It also may be an ordering issue. The sil164, you need to set up the chip
> properly before setting the enable bit (bit 0 IIRC) in 0x08.

right now I'm using the following intialization sequence, which does set the enable bit only after everything else as been set:

+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x08, 0x32);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x09, 0x34);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0a, 0x80);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0c, 0xc9);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0d, 0x70);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0e, 0x01);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0f, 0x4c);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x08, 0x33);

btw, I've noticed an interesting behaviour with the radeon driver using the code above when going to sleep by "pbbcmd sleep" (I need so switch to a text-vt before doing so, otherwise when doing this from within X11 the powerbook will perform some kind of power-off... I'm not sure yet, whether to file this against Xorg or rather against the linux kernel :-/); anyway there are two scenarios:

a) going to sleep with Xorg running -> ok
1. switching from DVI dual-head Xorg session to text VT
2. pbbcmd sleep
3. waking up again
4. switching back to Xorg session
-> external DVI output still fine 

b) going to sleep without Xorg running -> not ok
1. terminating working dual-head Xorg session and switch to text VT
2. pbbcmd sleep
3. waking up again
4. starting new Xorg session
-> external DVI output still fine

...seems as if Xorg is able to restore some setup/initialization it saved before going to sleep?

> > ...except that it doesn't compile (the #defined constants are missing) :-)
> Fixed now in git.

I'll try that soon
Comment 32 Alex Deucher 2007-10-04 07:38:45 UTC
(In reply to comment #31)
> right now I'm using the following intialization sequence, which does set the
> enable bit only after everything else as been set:
> 

does it work properly?

> 
> btw, I've noticed an interesting behaviour with the radeon driver using the
> code above when going to sleep by "pbbcmd sleep" (I need so switch to a text-vt
> before doing so, otherwise when doing this from within X11 the powerbook will
> perform some kind of power-off... I'm not sure yet, whether to file this
> against Xorg or rather against the linux kernel :-/); anyway there are two
> scenarios:
> 

I'm not familiar with "pbbcmd sleep" unfortunately.

> 
> ...seems as if Xorg is able to restore some setup/initialization it saved
> before going to sleep?

well, the driver saves all the regs it touches when it starts up and then restores those regs when you switch VTs or quit X.  We don't save/restore the ext TMDS regs yet (they get left as set by the driver), but I suppose we should.
Comment 33 Alex Deucher 2007-10-04 07:47:47 UTC
(In reply to comment #31)

> well, reading back those registers, I get what's expected for the vendor and
> device id according to the sil164 data-sheet:

you might also want to look at the sil1162 databook.  it has the same ids as the sil164, but may need a slightly different programming sequence.
Comment 34 Herbert Valerio Riedel 2007-10-04 08:51:50 UTC
(In reply to comment #33)
> > well, reading back those registers, I get what's expected for the vendor and
> > device id according to the sil164 data-sheet:
> 
> you might also want to look at the sil1162 databook.  it has the same ids as
> the sil164, but may need a slightly different programming sequence.

I'd love to, but the link seems to be broken :-/

on the other hand the sil1178 datasheet link worked which also has the same vendor/device/revision values (does sil use any other ids at all?), and judging from the FRQ_HIGH read-only reg, it looks definitely as if it's not a sil164 but some of its dual-link capable cousins...

it would be interesting to compare the sil1162 reset values for the registers, as those I get right now right after waking up again, match almost those of sil1178 but not exactly... (it's just a matter of two registers where one bit doesn't match the expected value...)

Comment 35 Herbert Valerio Riedel 2007-10-04 08:58:09 UTC
(In reply to comment #32)
> > right now I'm using the following intialization sequence, which does set the
> > enable bit only after everything else as been set:

> does it work properly?

yes... but only for the 'going-to-sleep-while-having-Xorg-on-other-VT' scenario :-/

> I'm not familiar with "pbbcmd sleep" unfortunately.

it's just a CLI operation for putting the powerbook into sleep/standby mode (i.e. suspend to ram)

> > ...seems as if Xorg is able to restore some setup/initialization it saved
> > before going to sleep?
 
> well, the driver saves all the regs it touches when it starts up and then
> restores those regs when you switch VTs or quit X.  We don't save/restore the
> ext TMDS regs yet (they get left as set by the driver), but I suppose we
> should.

...any theory what might cause DVI-output to be restored if going into suspend with Xorg still running on another VT?
Comment 36 Herbert Valerio Riedel 2007-10-04 09:04:01 UTC
(In reply to comment #31)
> a) going to sleep with Xorg running -> ok
> 1. switching from DVI dual-head Xorg session to text VT
> 2. pbbcmd sleep
> 3. waking up again
> 4. switching back to Xorg session
> -> external DVI output still fine 
> 
> b) going to sleep without Xorg running -> not ok
> 1. terminating working dual-head Xorg session and switch to text VT
> 2. pbbcmd sleep
> 3. waking up again
> 4. starting new Xorg session
> -> external DVI output still fine

I just tried a third variant, in order to verify the suspicion that the ati driver is able to restore some context necessary to enable proper DVI-out:

c) going to sleep with Xorg running...
1. switching from DVI dual-head Xorg session to text VT
2. inducing suspend-to-ram with "pbbcmd sleep"
3. waking up again
4. starting a new 2nd Xorg instance ("X :2")
5. switching back to the first Xorg session (-> colors ok)
6. switching to the 2nd Xorg instance (-> colors bad!)
7. switching back to the first Xorg session (-> colors still ok)

-> external DVI output still fine with Xorg instance kept over suspend, but off-color with Xorg instance started right after wakup from console...

...any ideas?
Comment 37 Herbert Valerio Riedel 2007-10-04 09:08:51 UTC
(In reply to comment #36)
> 4. starting a new 2nd Xorg instance ("X :2")
...I forgot to mention, that the colors are already broken at this point for this second instance...

thus, when switching VTs to the first instance, the radeon driver does something right with the hardware... if I only knew what it is exactly :-)
Comment 38 Herbert Valerio Riedel 2007-10-04 09:41:56 UTC
jfyi, since the sil1178 DS mentioned that the chip is used master/slave pairs if required for dual-link operation, I tried and also found a slave TDMS chip responding on i2c address 0x72 (or 0x39 if shifting away the r/w bit)

Comment 39 Alex Deucher 2007-10-04 10:55:11 UTC
> jfyi, since the sil1178 DS mentioned that the chip is used master/slave pairs
> if required for dual-link operation, I tried and also found a slave TDMS chip
> responding on i2c address 0x72 (or 0x39 if shifting away the r/w bit)
> 

you probably have a dual link tmds chip so it's probably the sil178.  

> it would be interesting to compare the sil1162 reset values for the registers,
> as those I get right now right after waking up again, match almost those of
> sil1178 but not exactly... (it's just a matter of two registers where one bit
> doesn't match the expected value...)

Despite what the databooks say for the default values, you may have to tweak them on a case by case basis.  Each oem may program them slightly differently depending on the application.
Comment 40 Alex Deucher 2007-10-04 11:02:52 UTC
(In reply to comment #37)
> thus, when switching VTs to the first instance, the radeon driver does
> something right with the hardware... if I only knew what it is exactly :-)
> 

It's probably an ordering thing.  Play around with the ordering of the radeon register restore.  You may have have to restore the ext tmds regs before enabling the crtc or the pll or the dvo/fp control regs.  For example in radeon_output.c::radeon_mode_set(), try swapping the order of
RADEONRestoreDVOChip() and RADEONRestoreFP2Registers().  If that doesn't work, you might try moving RADEONRestoreDVOChip() into radeon_crtc.c::radeon_crtc_mode_set() before you restore the crtc registers or pll registers, etc.

Comment 41 Herbert Valerio Riedel 2007-10-05 12:54:46 UTC
(In reply to comment #40)
> (In reply to comment #37)
> > thus, when switching VTs to the first instance, the radeon driver does
> > something right with the hardware... if I only knew what it is exactly :-)
 
> It's probably an ordering thing. 
> Play around with the ordering of the radeon
> register restore.  [...]

I'll try, but I don't understand how this is supposed to explain the behaviour I described with those two Xorg instances, each having its own saved radeon context which gets restored on VT-switch-backs; if it was an ordering thing, shouldn't both instances fail to restore DVI out to proper colors...  instead of one having the radeon state restored to a good state, while the second instance always sets up the DVI output bad...

to me it looks as if the "good" instance was able to remember some radeon registers which were originally set-up by the OF at boot-time before everything(?) was lost during the suspend-to-ram... while the "bad" instance had no chance to look at the radeon registers the way they looked at boot-time, and thus is doomed to restore the radeon state to something not properly working...

long story short...is there an easy way to dump what state information both instances have saved, and are about to restore on VT-switch-backs? I tried by printing out all stuff written by _every_ OUTREG()s but that's hard to compare...
Comment 42 Sjoerd Simons 2007-10-17 03:24:00 UTC
With current git DVI out works perfectly on my PowerBook5,2.. 

I've digged around google a bit. It seems that Powerbook5,1 to Powerbook5,5 have a single-link dvi output. Powerbook5,6 could be optionally build with dual-link dvi but had single-link by default.. And Powerbook5,7 to Powerbook5,9 are all dual-link dvi.

For the record the registers on my external tdms look like this:
SIL164_VID_LO (0x0):    0x01
SIL164_VID_HI (0x1):    0x00
SIL164_DID_LO (0x2):    0x06
SIL164_DID_HI (0x3):    0x00
SIL164_REV (0x4):       0x00
SIL164_RSVD (0x5):      0x00
SIL164_FREQ_LO (0x6):   0x14
SIL164_FREQ_HI (0x7):   0xc8
SIL164_REG8 (0x8):      0x3b
SIL164_REG9 (0x9):      0x00
SIL164_REGC (0xc):      0x89
Comment 43 Michel Dänzer 2007-10-17 03:31:15 UTC
(In reply to comment #42)
> Powerbook5,6 could be optionally build with dual-link dvi but had single-link by
> default..

Hrm, so we might need to change autodetection of Option "MacModel" for 5,6... Any pointers to the information you found?
Comment 44 Alex Deucher 2007-10-17 06:26:47 UTC
(In reply to comment #41)
> 
> I'll try, but I don't understand how this is supposed to explain the behaviour
> I described with those two Xorg instances, each having its own saved radeon
> context which gets restored on VT-switch-backs; if it was an ordering thing,
> shouldn't both instances fail to restore DVI out to proper colors...  instead
> of one having the radeon state restored to a good state, while the second
> instance always sets up the DVI output bad...

I think it's an ordering thing with the restoration of the external tmds regs.  We don't currently save them, so they are left as initialized by the driver on a VT switch.  So what I think is happening is that the first instance of the X server sets up the external tmds regs properly, but in the wrong order relative to the rest of the hw state (i.e., the external tmds regs may need to be restored before the crtc is enabled).  when you switch to the other VT, the external tmds regs are still set up from the first X server so when it restores the rest of the regs everything works.  So I think it's an issue with when the external tmds regs need to be written relative to the rest hw state.  You might also try forcing a screen blank (dpms off) and see if that fixes the colors as well.
Comment 45 Alex Deucher 2007-10-17 06:29:30 UTC
(In reply to comment #42)
> With current git DVI out works perfectly on my PowerBook5,2.. 
> 
> I've digged around google a bit. It seems that Powerbook5,1 to Powerbook5,5
> have a single-link dvi output. Powerbook5,6 could be optionally build with
> dual-link dvi but had single-link by default.. And Powerbook5,7 to Powerbook5,9
> are all dual-link dvi.

the question is, which ones use external tmds and which ones use internal tmds for single link dvi.  Unfortunately, "powerbook-duallink" is a bit of a misnomer.  I should have called it "powerbook-external".
Comment 46 Sjoerd Simons 2007-10-17 06:49:54 UTC
(In reply to comment #45)
> (In reply to comment #42)
> > With current git DVI out works perfectly on my PowerBook5,2.. 
> > 
> > I've digged around google a bit. It seems that Powerbook5,1 to Powerbook5,5
> > have a single-link dvi output. Powerbook5,6 could be optionally build with
> > dual-link dvi but had single-link by default.. And Powerbook5,7 to Powerbook5,9
> > are all dual-link dvi.
> 
> the question is, which ones use external tmds and which ones use internal tmds
> for single link dvi.  Unfortunately, "powerbook-duallink" is a bit of a
> misnomer.  I should have called it "powerbook-external".
> 

My powerbook5,2 definately uses an external tdms for single-link DVI.. A friend of mine has a PowerBook3,5 and that uses an internal TDMS (MacModel "powerbook" woks for him). So i'm pretty sure that all PowerBook5,X models have an external tdms (either single or dual link). And PowerBook3,4 and PowerBook3,5 models have an internal tdms (Older powerbooks didn't have dvi out at all).

See http://www.theapplemuseum.com/index.php for a list of all models. The info about the 5,6 having optional dual-link comes from http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/15inchPowerBookG4_Feb05/index.html?http://developer.apple.com/documentation/Hardware/Developer_Notes/Macintosh_CPUs-G4/15inchPowerBookG4_Feb05/1Overview/chapter_2_section_3.html
and http://www.macworld.com/news/2005/01/31/powerbook/index.php
Comment 47 Herbert Valerio Riedel 2007-10-21 01:49:26 UTC
(In reply to comment #42)
> For the record the registers on my external tdms look like this:

> SIL164_VID_LO (0x0):    0x01
> SIL164_VID_HI (0x1):    0x00
> SIL164_DID_LO (0x2):    0x06
> SIL164_DID_HI (0x3):    0x00
> SIL164_REV (0x4):       0x00
> SIL164_RSVD (0x5):      0x00

the regs above seem to be the same across multiple silicon image dvi transmitter chips... makes one wonder why they keep the use the same DID/REV for different devices...

> SIL164_FREQ_LO (0x6):   0x14
> SIL164_FREQ_HI (0x7):   0xc8

the 2 read-only registers above on the other hand seem to different on different  tdms chips... e.g.:

according to datasheets,
 
 a sil164 should have 0x19/0x64 for lo/hi (meaning 25MHz and 165MHz); 
 a sil1178 should have 0x19/0xa5 for lo/hi (meaning 25MHz and 165MHz again);

my tdms seems to be similiar to a sil1178

yours on the other hand looks neither like a sil164 nor a sil1178... (maybe someone has the missing sil-datasheets?), and it seems your tdms might support a pixelclock frequency range from 20MHz up to 200MHz...

> SIL164_REG8 (0x8):      0x3b
> SIL164_REG9 (0x9):      0x00
> SIL164_REGC (0xc):      0x89

well, that looks already initialized by OF or xorg... 
Comment 48 Herbert Valerio Riedel 2007-10-21 02:08:20 UTC
(In reply to comment #44)
> (In reply to comment #41)
> > I'll try, but I don't understand how this is supposed to explain the behaviour
> > I described with those two Xorg instances, each having its own saved radeon
> > context which gets restored on VT-switch-backs; if it was an ordering thing,
> > shouldn't both instances fail to restore DVI out to proper colors...  instead
> > of one having the radeon state restored to a good state, while the second
> > instance always sets up the DVI output bad...
> 
> I think it's an ordering thing with the restoration of the external tmds regs.

external tmds regs == i2c regs?
 
> We don't currently save them, so they are left as initialized by the driver on
> a VT switch.  So what I think is happening is that the first instance of the X
> server sets up the external tmds regs properly, but in the wrong order relative
> to the rest of the hw state (i.e., the external tmds regs may need to be
> restored before the crtc is enabled).



just for the record, right now I'm using the following sequence (as recommended in the sil1178 datasheet) for setting up single-link operation of my tmds:

+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0f, 0x44);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0f, 0x4c);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0e, 0x01); // auto zone
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0a, 0x80);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x09, 0x30); // 0x34
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0c, 0xc9);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x0d, 0x70);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x08, 0x32);
+               RADEONDVOWriteByte(radeon_output->DVOChip, 0x08, 0x33);

> when you switch to the other VT, the
> external tmds regs are still set up from the first X server so when it restores
> the rest of the regs everything works. 

yes, that would explain it, if once the colors are good, I could switch back and forth between both instances, and the colors would remain good;

but I have two instances, which if I switch to the first one which kept the good state, the colors are good, then I switch to the bad one which causes bad colors, then I switch back to the good one, and the colors are good again, and I could repeat that indefinitely... and since the tmds regs seem to be initialized to the same values for both switching operations, it shouldn't be the ordering of the tmds initialization wrt to the radeon-chip hardware state....

so I still think it's some state internal to the radeon gpu that's different

but I noticed that when trying to dump all register writes to the radeon gpu, the radeon states that get restored on vt-switches seemed to differ; amongst others, iirc, some kind of timing tables where completely different (one instance's was much shorter than the other), but the logfile was too noisy to me (and I know too little about the radeon gpu) in order to understand what was going on... and maybe it was unrelated

> So I think it's an issue with when the
> external tmds regs need to be written relative to the rest hw state.  You might
> also try forcing a screen blank (dpms off) and see if that fixes the colors as
> well.

I already tried moving around the initialization, but no effect so far;

will try the dpms off thing asap
Comment 49 Herbert Valerio Riedel 2007-10-21 02:15:03 UTC
(In reply to comment #48)
> You might also try forcing a screen blank (dpms off) and see if that fixes the colors as well.

didn't help at all; As an additional note, it's not only the colors that are slightly off, the display is a bit noisy as well, especially with the default x background pattern, thus the display mode timing is slightly off...

Comment 50 Alex Deucher 2007-11-12 15:29:13 UTC
*** Bug 8705 has been marked as a duplicate of this bug. ***
Comment 51 Alex Deucher 2007-11-27 14:05:50 UTC
*** Bug 13304 has been marked as a duplicate of this bug. ***
Comment 52 Bret Towe 2007-11-27 14:47:02 UTC
Created attachment 12750 [details] [review]
diff of working and not working reg output
Comment 53 Bret Towe 2007-11-27 15:02:02 UTC
the suggestion of commenting out RADEONRestoreDVOChip(pScrn, output);
in radeon_mode_set() in radeon_output.c
made no difference to how my system acted
Comment 54 Alex Deucher 2007-11-28 19:46:48 UTC
(In reply to comment #52)
> Created an attachment (id=12750) [details]
> diff of working and not working reg output
> 

<sigh> looks like apple uses internal tmds on some minis and external tmds on others...
try the following option in the device section of your config:
Option "ConnectorTable" "4,1,0,3,0,1,2,6"
Comment 55 Bret Towe 2007-11-29 09:33:47 UTC
the suggested line of
Option "ConnectorTable" "4,1,0,3,0,1,2,6"
worked
I've forgotten what it was like to logout and have x reappear without work :)
Comment 56 Bret Towe 2007-12-01 12:01:53 UTC
minor follow up
my issue got fixed in commit 9840a0fd4fc8c980533fcd4a02c55cd0d5634b6d
Comment 57 Ben Crocker 2018-01-30 23:30:41 UTC
Can anyone verify that Alex Deucher's commit
9840a0fd4fc8c980533fcd4a02c55cd0d5634b6d in
git://anongit.freedesktop.org/xorg/driver/xf86-video-ati
fixed the problem  as Bret asserted in comment 56?  Can we close this
as RESOLVED/FIXED?
Comment 58 Sjoerd Simons 2018-05-03 13:49:13 UTC
Fwiw my powerbook has been defunct for quite a few years so i won't be able to report back status on this

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.