| Summary: | Powerbook DVI out only works when booted with monitor attached | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Sjoerd Simons <sjoerd> |
| Component: | Driver/Radeon | Assignee: | 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
Sjoerd Simons
2007-03-27 02:04:11 UTC
Created attachment 9303 [details]
Xorg log when the monitor wasn't attached at bootup (thus non-working)
Created attachment 9304 [details]
Xorg log of when the monitor was attached at bootup (Thus working dvi out)
Can you use radeontool (http://gitweb.freedesktop.org/?p=users/airlied/radeontool.git;a=summary) to dump the regs in both instances? radeontool regmatch '*' Created attachment 9308 [details]
Dump of all registers while in X with working dvi out
Created attachment 9309 [details]
Dump of all register while in X with non-working dvi-out
(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.) 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. 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.. 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 :) 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 ... 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 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. (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. 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 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 :) 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... 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. (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? Created attachment 11380 [details]
Hack to program my tdms
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 I just made an initial commit to support external tmds in ati git master. Can you test and let me know how it goes? <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 :) I've implemented this slightly differently in the latest ati git. Can you try that and confirm that it works? 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... :-( (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. (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 | Created attachment 11891 [details]
Xorg log of 15" hr alu powerbook
(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. (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) :-) (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. (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 (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. (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. (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...) (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? (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? (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 :-) 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) > 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. (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. (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... 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 (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? (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. (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". (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 (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... (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 (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... *** Bug 8705 has been marked as a duplicate of this bug. *** *** Bug 13304 has been marked as a duplicate of this bug. *** Created attachment 12750 [details] [review] diff of working and not working reg output the suggestion of commenting out RADEONRestoreDVOChip(pScrn, output); in radeon_mode_set() in radeon_output.c made no difference to how my system acted (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" 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 :) minor follow up my issue got fixed in commit 9840a0fd4fc8c980533fcd4a02c55cd0d5634b6d 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? 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.