|
Description
Tyson Whitehead
2008-11-16 21:23:55 UTC
Created attachment 20354 [details]
capture of xorg stdout/stderr (log level 9)
Created attachment 20355 [details] [review] xorg log file (log level 9) Created attachment 20356 [details]
dump of video rom (as described in 11320)
Created attachment 20357 [details]
xorg config file (for completeness)
I wonder if this can be related to bug #18016? In my case (bug #18016) disabling HDMI disabled PANEL. I've tried the latest git again last week (979ad04d) and this still doesn't work. Even worse, if the external DVI display is attached via the HDMI connector on Xorg startup, the local display now goes blank as well. On the postivie side, I discovered by accident that if I close the lid of my laptop on boot up the BIOS will enables the external DVI display plugged into the HDMI port (which lasts until Xorg loads, at which point they both go black). Anyway, I would love to do a registers dump from the console (using rhd_dump) for you guys in this state (i.e., after this BIOS has successfully enabled the external DVI display plugged into the HDMI). Are there any registers in particular it would be good to know the state of? Thanks! -Tyson PS: With regard to comment #5, I've tried every combination of enabling and disabling combinations options via xrandr (VGA, DVI, and HDMI) and have never managed to get any display on any external display other than one plugged into the VGA port. By comparing dumps of the register file over many reboots with different configurations, I've managed to figure out that I can enable my external DVI display plugged into the HDMI port on my laptop by either doing xrandr --output DVI-0 --auto rhd_dump -w 0x7880 0x10001001 01:00.0 rhd_dump -w 0x7904 0x00001F00 01:00.0 (i.e., enable it and then write 0x10001001 to the TMDSA_CNTL register followed by 0x00001F00 to the TMDSA_TRANSMITTER_ENABLE register) or xrandr --output HDMI-0 --auto rhd_dump -w 0x7880 0x10001001 01:00.0 rhd_dump -w 0x7904 0x00001F00 01:00.0 rhd_dump -w 0x7910 0x00000031 01:00.0 rhd_dump -w 0x7884 0x00000001 01:00.0 (i.e., also write 0x10001001 to the TMDSA_TRANSMITTER_CONTROL register followed by 0x00000001 to the TMDSA_SOURCE_SELECT register). I'll attach my register file analysis. Hope this helps! -Tyson Created attachment 21623 [details]
comparison of static registers under different situations (changing ones assumed to be status)
I looked at the rv630 register specifications and it seems the difference in registers I discovered seems to be all tied up with whether link 0 or link 1 is used on TMDSA. Specifically, 0x7880: 0x00001001 -> 0x10001001 swaps TMDSA upper and lower data channels and 0x7904: 0x0000001F -> 0x00001F00 enables TMDSA link 1 instead of link 0 I spend the day digging around in the code and discovered that the "TMDS1EncoderControl" atom bios command used to enable to output in the "atombios_output_digital_setup" routine in "atombios_output.c" can take a "PANEL_ENCODER_MISC_TMDS_LINKB" option in the ucMisc field, which, specifying, I pleased to report, makes everything just work for me. : ) I'll attach a patch for completeness (not that it should be applied as I imagine it would be a very bad idea to just blindly set this option for everyone like I've done). Cheers! -Tyson Created attachment 21644 [details] [review] hack patch that forces TMDSA to always use the second link Created attachment 21694 [details] [review] lookup link number Does this patch help? Thanks for the patch Alex. Unfortunately, it seems the object id enum is one for that connector, so it didn't do the trick. Here's the output in the xorg log file from the relevant debug lines you added (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=64800 max=120000; xclk=40000 object id 0005 01 enum 1 src object id 2115 21 record type 1 record type 4 object id 000e 01 enum 1 src object id 210f 15 record type 1 record type 4 object id 0004 02 enum 1 src object id 4101 1 src object id 2113 19 record type 1 record type 2 record type 4 object id 000c 01 enum 1 src object id 4101 1 record type 1 record type 2 record type 4 object id 000f 01 enum 1 src object id 2116 22 record type 4 Cheers! -Tyson can you test the atom-rework branch of my personal repo? http://cgit.freedesktop.org/~agd5f/xf86-video-ati/?h=atom-rework Thanks Alex, I gave your atom-rework branch a try yesterday (last commit was c3fb8bb2... on Tue Jan 6th) and am sorry to report that it didn't work. It seems like the enum for the encoder must be one as well. I'll attach the xorg log file for starting up and shutting down the xserver with it (xrandr claimed both LVDS and DVI-0 where enabled, but, as before, only LVDS displayed any thing). Cheers! -Tyson Created attachment 21810 [details]
xorg log file from running Alex's atom-rework branch
*** Bug 22744 has been marked as a duplicate of this bug. *** Created attachment 27629 [details] dump of a HD2600m bios As requested in bug 22744 a dump of my video bios. *** Bug 22764 has been marked as a duplicate of this bug. *** Does this work any better with xf86-video-ati from git master? Created attachment 31945 [details]
xorg log file from latest git (DVI-0 is turned on instead of HDMI-0)
Hi Alex, First of all, thank you very much for your continued work on this. I'm pleased to report that I have some good news. I just tried the latest git (46630d) and it now mostly works. While it does come on at startup despite being plugged in, I can now get it to turn on using xrandr. Full details are as follows. To reiterate a bit, my laptop has a VGA and an HDMI port on it. I plug my DVI monitor into it the HDMI one via a HDMI -> DVI cable. I also understand that the docking bay has a DVI port, however, I don't have this piece of equipment. The XOrg log file and XRandR show that four ports are detected. (II) RADEON(0): Port0: XRANDR name: VGA-0 Connector: VGA CRT1: INTERNAL_KLDSCP_DAC1 DDC reg: 0x7e40 (II) RADEON(0): DispPath index = 0: usConnObjectId = 3105 (id=05,num=1,type=3) (II) RADEON(0): GraphicObjIds index = 0: usConnObjectId = 2115 (id=15,num=1,type=2) (II) RADEON(0): Port1: XRANDR name: HDMI-0 Connector: HDMI-A DFP1: INTERNAL_KLDSCP_TMDS1 DDC reg: 0x7e50 (II) RADEON(0): DispPath index = 1: usConnObjectId = 310c (id=0c,num=1,type=3) (II) RADEON(0): GraphicObjIds index = 0: usConnObjectId = 2213 (id=13,num=2,type=2) (II) RADEON(0): GraphicObjIds index = 1: usConnObjectId = 4101 (id=01,num=1,type=4) (II) RADEON(0): Port2: XRANDR name: DVI-0 Connector: DVI-D DFP2: INTERNAL_KLDSCP_TMDS1 DDC reg: 0x7e50 (II) RADEON(0): DispPath index = 2: usConnObjectId = 3104 (id=04,num=1,type=3) (II) RADEON(0): GraphicObjIds index = 0: usConnObjectId = 2113 (id=13,num=1,type=2) (II) RADEON(0): GraphicObjIds index = 1: usConnObjectId = 4101 (id=01,num=1,type=4) (II) RADEON(0): Port3: XRANDR name: LVDS Connector: LVDS LCD1: INTERNAL_LVTM1 DDC reg: 0xac0 (II) RADEON(0): DispPath index = 3: usConnObjectId = 310e (id=0e,num=1,type=3) (II) RADEON(0): GraphicObjIds index = 0: usConnObjectId = 210f (id=0f,num=1,type=2) I added some debugging code to dump the object ids, and we can see the HDMI-0 port is the only one being detected as a linkb port (the encoder has num=2). Indeed, as long as DVI-0 is turned off, running "xrandr --output HDMI-0 --auto" and "xrandr --output HDMI-0 --off" turns on and off the display as it should. The strange thing now is, if I plug in the display before starting up, XOrg chooses to begin with DVI-0 enabled and HDMI-0 disabled. As XRandR shows XOrg.Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 1920 VGA-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected (normal left inverted right x axis y axis) 1920x1200 60.0 + ... (and a bunch more modes) ... DVI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0*+ ... (and a bunch more modes) ... LVDS connected 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1680x1050 60.1*+ 60.0 ... (and a bunch more modes) ... So I then always have to manually turn on off DVI-0 using "xrandr --output DVI-0 --off" and then turn on HDMI-0 using "xrandr --output HDMI-0 --auto" in order to get my display to come on. If I don't first turn off DVI-0, then I get the the error message "xrandr: cannot find crtc for output HDMI-0". I've attached a full XOrg log file of just starting up XOrg and then shutting it back down in case this will shed some light on this situation. Again, thanks again for your continued work on this. I'm pretty excited to have it mostly working now. Cheers! -Tyson I see I made a typo in my first paragraph on my last comment. I meant "While it does [not] come on at startup despite being plugged in, I can now get it to turn on using xrandr." Cheers! -Tyson PS: Also, the log file got attached first due to the order I did things in. This is fixed in KMS as of 2.6.35. Hi Alex, Thanks for all the work on this. I've actually been using 2.6.32 (Debian x86_64) for awhile and it has been working okay minus some flaky suspend issues. If the display is plugged in at boot time, it turns on my external monitor part way through booting the kernel and continues to work fine as Xorg starts. I haven't tried 2.6.35 because Debian didn't release a kernel for it, but they just released one for 2.6.36 this weekend. I've upgraded and now it is not working at all. That is, the display remains off through the entire boot process and even once Xorg has started. Running xrandr at this point says Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 8192 x 8192 VGA-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 519mm x 324mm 1920x1200 60.0*+ ... DVI-0 disconnected (normal left inverted right x axis y axis) LVDS connected 1680x1050+0+0 (normal left inverted right x axis y axis) 331mm x 207mm 1680x1050 60.1*+ ... DIN disconnected (normal left inverted right x axis y axis) and "xrandr --output HDMI-0 --off" followed by "xrandr --output HDMI-0 --auto" does not turn it back on. Cheers! -Tyson PS: It likely doesn't matter as this shows up before xorg even starts, but I'm currently running xorg 7.5 and xorg radeon driver 6.13.1. Can you attach your dmesg, xorg log, and xrandr --verbose output with kms and 2.6.36? Created attachment 39925 [details] [review] Diff of 2.6.32 and 2.6.36 constant registers Result of diffing the output of - booting up debian kernel 2.6.36 (where it doesn't works) with display attached, - doing 100 dumps of the registers between 0x6000-0x8000 after Xorg starts, - filtering out any registers that do not remain constant and - booting up debian kernel 2.6.32 (where it works) with display attached, - doing 100 dumps of the registers between 0x6000-0x8000 after Xorg starts, - filtering out any registers that do not remain constant attached. I looked the variable ones up in AMDs register guide, and the only non-memory region register differences seem to be all centered on TMDSA. They are (not working vs working) 7880 - 10001000 vs 10001001 (TMDSA_ENABLE off vs on) 7894 - 02000000 vs 00000000 (TMDSA_TEMPORAL_DITHER_RESET on vs off) 78dc - 00000000 vs 00000001 (TMDSA_DSYNSEL off vs on) 7904 - 00000000 vs 00001f00 (TMDSA_{TX1_ENABLE,LNKC1EN,LNKD10EN,LNKD11EN,LNKD12EN} off vs on) 7910 - 00000032 vs 00000031 (TMDSA_PPL_{ENABLE,RESET} off and on vs on and off) I then booted up under 2.6.36 (the newer not working kernel) and checked that - writing the 2.6.32 values out to these registers turns on my display, - writing any of 7880, 7904 and 7910 back to their 2.6.36 values turns it off again, and - writing either 7894 or 78dc back to their 2.6.36 values has no effect. Cheers! -Tyson Created attachment 39927 [details] [review] Requested 2.6.36 dmesg dump (as soon as xorg starts up) Created attachment 39928 [details] [review] Requested 2.6.36 xorg log (as soon as xorg starts up) Created attachment 39929 [details]
Requested 2.6.36 xrandr --verbose dump (as soon as xorg starts up)
Created attachment 39931 [details] [review] fix The A/B links aren't independently usable on these blocks so when we disable the encoders, make sure to only disable the encoder when there is no connector using it. Hi Alex, That was an amazingly quick patch post. I just finished compiled the 2.6.36 kernel and am pleased to report that it works too! Thanks again for all the hard work on this bug. -Tyson Sent to Dave. |
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.