Created attachment 19586 [details] After commands I switched to VT1 and used export DISPLAY=:0 && xrandr --verbose I connect my TV using HDMI and command xrandr --output DVI-D_1 --auto After that I usually want to turn off PANEL so DVI-D_1 will be the only display. For that I type: xrandr --output PANEL --off This results in two black screens. Of course I expected TV (DVI-D_1) to work.
As usual please attach a log file generated with the -logverbose 7 command line option so we know what hardware you are using.
*** This bug has been marked as a duplicate of bug 16892 ***
Created attachment 20006 [details] Xorg.0.log generated with startx -- -logverbose 7
Egbert Eich: if bug #16892 was really fixed, then this is not duplicate for bug 16892. I tried current git (commit f29a3d2f) and it still happens.
Created attachment 20007 [details] Registers dump after starting X without TV connected to HDMI
Created attachment 20008 [details] Registers dump after "xrandr --output DVI-D_1 --auto"
Created attachment 20009 [details] Registers dump after "xrandr --output PANEL --off"
0x75A0: 0x00000311 0x75A4: 0x00000100 0x79A0: 0x00000110 0x79A4: 0x00000100 This shows that DIG1 gets disabled which should be associated to UNIPHYB, not the LVTMA which drives the panel. I have no idea why this is happening. I've committed some additional debug code. Please fetch again and provide a '-logverbose 7' logfile.
Rafał: Please perform exactly the same steps you have performed to generate the dumps when you generate the verbose log file.
Reassigning to reporter for feedback.
My access to HDMI TV is limited, so I'll need a few days to get is and test current git.
Created attachment 20321 [details] Xorg.0.log after starting X without TV connected to HDMI X started using startx -- -logverbose 7
Created attachment 20322 [details] Xorg.0.log after "xrandr --output DVI-D_1 --auto" X started using startx -- -logverbose 7
Created attachment 20323 [details] Xorg.0.log after "xrandr --output PANEL --off" X started using startx -- -logverbose 7. I switched to VT2 to get copy of Xorg.0.log.
Created attachment 20324 [details] Xorg.0.log after starting X without TV connected to HDMI This time I used current git (53dd35cb76613...)
Created attachment 20325 [details] Xorg.0.log after "xrandr --output DVI-D_1 --auto" This time I used current git (53dd35cb76613...), sorry for mistake.
Created attachment 20326 [details] Xorg.0.log after "xrandr --output PANEL --off" This time I used current git (53dd35cb76613...)
Comment on attachment 20323 [details] Xorg.0.log after "xrandr --output PANEL --off" This is obsolete, uploaded corrent one generated with current git radeonhd version.
Thanks! Still no luck. The dumps in comment #6 and #7 coincide exactly with the description of the bug. The logs in comments #17 and #18 don't. It doesn't explain why DIG1 gets powered down instead of DIG2. I'm about to commit debug code upstream to track down exactly this issue. Please start X with -logverbose 7 and perform the same steps as before and post the log. You only have to provide the final log as it should contain everything I need to know. Thanks :)
(In reply to comment #11) > My access to HDMI TV is limited, so I'll need a few days to get is and test > current git. > Rafał, there is no need to attach a HDMI TV. If you have access to an DVI monitor it would do just as well if you have an adaptor DVI->HDMI.
Created attachment 20497 [details] Xorg.0.log after 3 steps [078842c7ab9e33...] My 3 steps: 1) Start X without TV connected to HDMI 2) xrandr --output DVI-D_1 --auto 3) xrandr --output PANEL --off Egbert: thanks for info from comment #20. I have access to my Sony TV only every 2 weeks, but this weekend I was able to use other, Samsung TV (with the same result).
Rafał, thanks for the new log file! The register values all look ok, so I think I was barking up the wrong tree. I suspect something else here. a. Does the PANEL also power off when you do: xrandr --output PANEL --off b. Does the situation improve, when you add the line: Option "AtomBIOS" "pll=on" to the device section of the config file?
Rafał, do you think you can get an answer to comment #22 this weekend still? I'd like to get a resolution to this problem as soon as possible.
Yes, I promise to provide full info today :) First a situation from comment #22: 1) If I do cold boot into init 5 with HDMI *disconnected* and then type xrandr --output PANEL --off PANEL just disables. 2) If I do cold boot into init 5, then connect HDMI (TV), then xrandr --output DVI-D_1 --auto and after moment xrandr --output PANEL --off I get PANEL disabled and my TV picture freezes for something about 500ms. Then TV picture disables. I think this freeze time may be TV-specified. The result is two disabled screens instead only only (only PANEL should be disabled). 3) If I do cold boot into init 5, with HDMI (TV) connected result is just like in case of 2). I just don't have to enable DVI-D_1, that's the only difference.
(In reply to comment #22) > b. Does the situation improve, when you add the line: > Option "AtomBIOS" "pll=on" > to the device section of the config file? Yes! Using this option let me disable PANEL! I can disable it (PANEL) and TV still displays the picture :) That works great :) Can I provide some info for you to help make it work out of box? Without this AtomBIOS option?
If you wish me to test some patch, I'll happy to do so (you don't have to put changes directly to git). I've access to TV until today (Monday) morning and then again on Friday.
I didn't notice this yesterday, but using Option "AtomBIOS" "pll=on" introduces one new problem. While using this option fixes disabling PANEL, I can not switch to console anymore (after starting X). If I try to switch from VT7 (X) to VT1 I get white-blanking screen just like in case of bug #17043 (attachment #18628 [details]). However if I switch to VT7 (X) from white-blanked VT1, then I get nice picture again.
Rafał, thanks for testing! The blanking of the DVI output you get when you disable the PANEL is most likely identical to the problem I traced down to the PLL code and described to Luc in an email. He promised to look into it but hasn't had time to do so, yet. I will reassign this bug to him. About the white screen problem you are seeing: PLL restoration using AtomBIOS is tricky. I'm sure this problem also happens when you are not using the DVI panel (could you verify this for me, please?).
Libv, this bug is related to the PLL setting problem with DCE3.x hardware I mentioned to you before. I'll dig out my analysis of this problem and how it can be reproduced on hardware which you have easy access to.
Here is the description I've written about this: I've run into issues with PLL programming on RV620/635. When I disable outputs individually and in a certain order and subsequently reenable them again one by one there are cases where the output that was enabled first comes on only when the second output has been enabled. I've been able to trace this down to the PLL code: The first output came on when RHDPLLSet() was called for the CRTC associated with the output that came on last. Here is how you can reproduce this easily: - Plug in the RV620 card, connect a monitor to each connector. - Run X, make sure both outputs are lit initially. - run xrandr --output VGA_1 --off xrandr --output DVI-I_1/digital --off xrandr --output DVI-I_1/digital --auto xrandr --output VGA_1 --auto on the server. You will see that DVI-I_1/digital only comes on after the last command line has been issued. As a verification that this really is a PLL code issue I replaced the hard coded PLL programming by the AtomBIOS one: 'Option "AtomBIOS" "pll=on"' lets you do this very easily. Using the AtomBIOS code path for PLL programming I wasn't able to trigger this problem.
(In reply to comment #28) > About the white screen problem you are seeing: > PLL restoration using AtomBIOS is tricky. I'm sure this problem also happens > when you are not using the DVI panel (could you verify this for me, please?). Huh, I often forget to mention some important testing-environment information. This white blanking problem affects PANEL only. It doesn't happen on TV (HDMI). If I switch to VT1 using PANEL only, I get white-blanking on PANEL. If I switch to VT1 with TV HDMI connected, I get white-blanking on PANEL and nice, normal, clear picture on TV (HDMI). In both situations switching to VT7 (X) restores nice picture on PANEL. (This whole comment is about using Option "AtomBIOS" "pll=on", I also use "HDMI" as "DVI-D_1" in whole bug report)
Luc: some chance you will find time for checking this bug, please? I have to add "pll=on" every time I need to disable PANEL and remove it every time I need to swich to VT :|
I wish to put here some irc logs about this issue: libv: Zajec: it's an issue with the pll setting code is what we thought, beyond that, i have no idea yet without reproducing it and touching pll code/registers and related things directly. Zajec: ok, thanks libv: ah, rv620/635. libv: this is where the beautifully separated hw blocks got mucked together on the pll side. [many days later] Zajec: libv: is this possible that powering down PLL1 stops PLL2? Zajec: (and as result we should not power down PLL1)? libv: Zajec: no, but it is possible that powering down pll1 breaks the pll2 input to some output Zajec: if that really happens, do you have any idea how we could workaround this? Zajec: does reseting PPL2 afer powering down pll1 sound good? libv: yes, fix the rv620 pll setting routine. libv: Zajec: no, it'll be a logical error of sorts.
Created attachment 25242 [details] [review] Hackish workaround: keep PLL1 always on I noticed that something bad happens right after powering down PLL1. If I don't power it down, then disabling PANEL doesn't affect DVI-D_1.
Created attachment 25243 [details] Parts of Xorg.0.log: enabling 2nd output and disabling PANEL I noticed already earlier that VGA_1 doesn't cause problems like DVI-D_1 does. xrandr --output VGA_1 --auto && xrandr --output PANEL --off keeps my VGA_1 working xrandr --output DVI-D_1 --auto && xrandr --output PANEL --off disables my DVI-D_1 I tried to compare what happens in case of VGA_1 and in case of DVI-D_1. Not sure if this will provide anything interesting.
Created attachment 25245 [details] Parts of Xorg.0.log: enabling 2nd output and disabling PANEL A little better formated second table (better rows-splitting and grey hightlighting matching cells).
Created attachment 26164 [details] [review] Huge hack to let switch off PANEL - good for debugging. I've done some additional (interesting?) research. I enabled AtomBIOS pll usage and traced function rhdAtomSetPixelClock. I dumped all arguments it uses to call RHDAtomBiosFunc(int, atomBiosHandlePtrx, ATOMBIOS_EXEC, AtomBiosArgPtr) to disable my PANEL. Then I created new function rhdPanelPowerDown with hard coded these arguments. Using this new function (without enabling AtomBIOS in any other place) I get PANEL disabling working. So now it's enought to use AtomDis to check what SetPixelClock command performs with these specified arguments. Unfrotunately code of SetPixelClock is quite long... but with more of less time spent on it, should be possible.
Created attachment 26495 [details] [review] Patch that helps following registers writes made by AtomBIOS
Using attached patch I traced AtomBIOS registers operations for disabling PLL1: [AtomBIOS]: CailWriteATIRegister(6080,1400310) [AtomBIOS]: CailWriteATIRegister(538,1) [AtomBIOS]: CailWriteATIRegister(384,0) [AtomBIOS]: CailWriteATIRegister(38c,0) [AtomBIOS]: CailWriteATIRegister(394,0) [AtomBIOS]: CailWriteATIRegister(438,0) [AtomBIOS]: CailWriteATIRegister(468,202) [AtomBIOS]: CailWriteATIRegister(470,200b) [AtomBIOS]: CailWriteATIRegister(450,6c310001) [AtomBIOS]: CailWriteATIRegister(450,6c012001) Disabling PLL1 using SetPixelClock AtomBIOS command includes disabling CRTC1. That explains touching 6080 register. Next I found code in disassembled AtomBIOS responsible for these operations: /* 0538 == DCCG_DISP_CLK_SRCSEL */ → 00bc: 01254e0101 MOVE reg[0538] [...X] <- 01 00c1: 43c900 JUMP 00c9 00c4: 01254e0103 MOVE reg[0538] [...X] <- 03 → 00c9: 5420e100 CLEAR reg[0384] [...X] → 00cd: 5420e300 CLEAR reg[038c] [...X] → 00d1: 5420e500 CLEAR reg[0394] [...X] 00d5: 3d250200 COMP param[02] [...X] <- 00 00d9: 49e300 JUMP_NotEqual 00e3 /* 0438 == EXT1_PPLL_POST_DIV_SRC */ → 00dc: 54200e01 CLEAR reg[0438] [...X] 00e0: 43ea00 JUMP 00ea 00e3: 54201001 CLEAR reg[0440] [...X] 00e7: 3a0100 SET_REG_BLOCK 0001 /* 0468 == P1PLL_DISP_CLK_CNTL */ → 00ea: 01651a0102 MOVE reg[0468] [..X.] <- 02 /* 0470 == EXT1_SYM_PPLL_POST_DIV */ → 00ef: 07651c01fe AND reg[0470] [..X.] <- fe /* 0450 == P1PLL_CNTL */ → 00f4: 0d25140101 OR reg[0450] [...X] <- 01 → 00f9: 5102 DELAY_MicroSec 02 00fb: 3d0d000000 COMP param[00] [..XX] <- 0000 0100: 491001 JUMP_NotEqual 0110 0103: 4a65080101 TEST reg[0420] [..X.] <- 01 0108: 491001 JUMP_NotEqual 0110 010b: 0d25140102 OR reg[0450] [...X] <- 02 → 0110: 51c8 DELAY_MicroSec c8 /* 0450 == P1PLL_CNTL */ → 0112: 0d65140120 OR reg[0450] [..X.] <- 20
I made some more research to understand when this 420/450 magic is used: Bug #19943 contains BIOS of HD2400Pro (rv610). It doesn't use 0420, writes 02 to 0450 without condition. Bug #21767 contains BIOS of HD3470 (m82/rv620). It checks 0420 for writing 02 to 0450: 010d: 4a65080101 TEST reg[0420] [..X.] <- 01 0112: 491a01 JUMP_NotEqual 011a 0115: 0d25140102 OR reg[0450] [...X] <- 02 011a: 51c8 DELAY_MicroSec c8 011c: 0d65140120 OR reg[0450] [..X.] <- 20 Bug #18564 contains BIOS of HD2600 (m76/rv630). It doesn't use 0420, writes 02 to 0450 without condition. Bug #16263 contains BIOS of HD3470 (m82/rv620). It checks 0420 for writing 02 to 0450: 0132: 4a65080101 TEST reg[0420] [..X.] <- 01 0137: 493f01 JUMP_NotEqual 013f 013a: 0d25140102 OR reg[0450] [...X] <- 02 013f: 51c8 DELAY_MicroSec c8 0141: 0d65140120 OR reg[0450] [..X.] <- 20 Bug #13605 contains BIOS of HD2600 (rv630). It doesn't use 0420, writes 02 to 0450 without condition. Bug #15478 contains BIOS of HD2600 (m76/rv630). It doesn't use 0420, writes 02 to 0450 without condition. Bug #16673 contains BIOS of HD2400Pro (m72/rv610). It doesn't use 0420, writes 02 to 0450 without condition. Bug #16892 contains BIOS of HD3650 (m86/rv635). It checks 0420 for writing 02 to 0450: 013a: 4a65080101 TEST reg[0420] [..X.] <- 01 013f: 494701 JUMP_NotEqual 0147 0142: 0d25140102 OR reg[0450] [...X] <- 02 0147: 51c8 DELAY_MicroSec c8 0149: 0d65140120 OR reg[0450] [..X.] <- 20 So it seems we need fix for rv620 and rv635 only (just like libv said).
More research today... Bug #13605 has attachment #18640 [details]: it shows we use R500PLL* for M76 (rv630) Bug #16673 has attachment #17780 [details]: it shows we use R500PLL* for M72 (rv610) Bug #17039 has attachment #18186 [details]: it shows we use R500PLL* for M76 (rv630) Bug #17136 has attachment #18282 [details]: it shows we use R500PLL* for M76 (rv630) Bug #17708 has attachment #18246 [details]: it shows we use R500PLL* for M76 (rv630) Bug #16929 has attachment #18071 [details]: it shows we use RV620PLL* for rv620 Bug #18393 has attachment #20080 [details]: it shows we use RV620PLL* for RS780 (rv610) Bug #19700 has attachment #22176 [details]: it shows we use RV620PLL* for rv620 Bug #21493 has attachment #25334 [details]: it shows we use RV620PLL* for RS780 (rv610) I wasn't able to find out if we use RV620PLL* for rv635 (we should). I noticed something new for me: RV620PLL* is used also by RS780. I checked if it's alright to use 420 condition for RS780. For that I used ROM attached to bug #18393: 013a: 4a65080101 TEST reg[0420] [..X.] <- 01 013f: 494701 JUMP_NotEqual 0147 0142: 0d25140102 OR reg[0450] [...X] <- 02 0147: 51c8 DELAY_MicroSec c8 0149: 0d65140120 OR reg[0450] [..X.] <- 20 So this should be safe to modify RV620PLL1Power and RV620PLL2Power without adding RV620/RV635/RS780 detecting condition in modified code.
(In reply to comment #38) > Created an attachment (id=26495) [details] > Patch that helps following registers writes made by AtomBIOS Rafal, the function already logs register writes with -logverbose 7... The function call one line above your added xf86Msg :-]
(In reply to comment #42) > Rafal, the function already logs register writes with -logverbose 7... The > function call one line above your added xf86Msg :-] Uhm. I thought it didn't work for me, but I was mistaken. File rhd_pll.c shows us that we use RV620PLL* for RHD_RV620 and newer. However rhd_id.c shows we use AtomBIOS for PLL on RV770 and newer (check RHDUseAtom(...) for prove). So after all RV620PLL* is used for chipsets RHD_RV620 (including) and RHD_RV770 (excluding). According to rhd.h that means: RHD_RV620, RHD_M82, RHD_RV635, RHD_M86, RHD_RS780, RHD_RS880, We can be sure my patch is alright for RHD_RV620, RHD_M82, RHD_M86 and RHD_RS780. Two unsure chipsets are: RHD_RV635 and RHD_RS880. As M86 is almost RV635, we can be quite sure patch should be applied for RV635. The one exception still may be RS880, but I can't find any BIOS of this chipset.
There are basically 3 families of display controllers on current r6xx/r7xx hardware. The mobile chips are just variants of the main types. 1. R5xx style (very similar to R5xx/RS690/RS740/RS600): R600 RV610 RV630 RV670 2. DCE 3.0/3.1: RV620 RV635 RS780 RS880 RV770/RV790 3. DCE 3.2: RV710 RV730 RV740
(In reply to comment #43) > So after all RV620PLL* is used for chipsets RHD_RV620 (including) and RHD_RV770 > (excluding). > > According to rhd.h that means: > RHD_RV620, > RHD_M82, > RHD_RV635, > RHD_M86, > RHD_RS780, > RHD_RS880, > > We can be sure my patch is alright for RHD_RV620, RHD_M82, RHD_M86 and > RHD_RS780. > > Two unsure chipsets are: RHD_RV635 and RHD_RS880. > > As M86 is almost RV635, we can be quite sure patch should be applied for RV635. > > The one exception still may be RS880, but I can't find any BIOS of this > chipset. According to Alex' comment RS880 should have the same display blocks. Rafal, which patch are you exactly referring to? This bug has way too many attachments :-]
Just found the patch on the mailing list. Rafal, if you're confident this patch is correct, I will happily apply it. I'd just ask for a comment in the file that refers to this bug report because the change is nontrivial and can only be understood in the context of this bug. Please attach the updated patch to the bug.
Does being in one DCE group mean one way of PLL setting? Because currently we don't use RV620PLL* for RV770 (which is in the same group with RV620, RV635, RS780, RS880). For RV770 we use AtomBIOS PLL management. That confused me. Matthias Hopf: sorry, I cause mess posting patch on ML[1] and keeping this bug alive. Will attach patch in minutes. [1] http://lists.opensuse.org/radeonhd/2009-06/msg00110.html
Created attachment 26591 [details] [review] PLL: RV620 PLL shutdowning fix Tested with number of xrandr operations for enabling/disabling additional monitors (both: DVI-D_1 tested for fix, VGA_1 tested for refressions). Works fine.
Thanks, pushed as fc31eb65edf6ffac969eb33a7c588dad7c93b7f4 This should be thoroughly tested on other hardware, for now it looks conclusive enough.
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.