[Bug 10418] Powerbook DVI out only works when booted with monitor attached

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Oct 4 07:11:25 PDT 2007


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





------- Comment #31 from hvr at gnu.org  2007-10-04 07:13 PST -------
(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


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the xorg-driver-ati mailing list