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

[bugzilla-daemon at freedesktop.org]

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


hvr at gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hvr at gnu.org




------- Comment #48 from hvr at gnu.org  2007-10-21 02:08 PST -------
(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


-- 
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.