I've noticed on both Linus's mainline and the radeon testing branch that I have a green tinge to the screen after KMS is initialised I've done my best with git bisect however there are a few un-compilable commits I've narrowed it down too: There are only 'skip'ped commits left to test. The first bad commit could be any of: 4143e919ea999c9356ae4f71b5a3a80e075290d5 f92a8b6758bdc0f277c4f42aa7d736a205ac9ded 5801ead6bd6bddf5505d6eab55f84d8ee8106cd8 6a93cb250a60af1bb7b4070949f8546a2fdc52ef 1a66c95a64c9ae0bc8382254f544b24b23f498ec ffd09c648a76a1cf96872c033e98d4730f9b10a4 54d9cb47dd6a754e434e5adeccb3a1e2835594fd 746c1aa4d100f7441423050f34be79f401fbf7d4 5fbfce7fc906c4a9e3d5e0872e5d6affaca54761 d904ef9b00a4473af16766e99f17bdbb5f0fde65 58682f107ad5178e47a45af3af1851442d05d7fc We cannot bisect more! I hope this helps - for information each of these was compiled with radeon built in and the R600_rlc.bin and R700_rlc.bin compiled into the kernel too
Nothing different shows up in my dmesg compared to the earlier kernels that show the correct colours These are the commits details 4143e919ea999c9356ae4f71b5a3a80e075290d5 Author: Alex Deucher <alexdeucher <at> gmail.com> Date: Mon Nov 23 18:02:35 2009 -0500 drm/radeon/kms: store sink type in atom dig connector This will be used laster when the encoder and transmitters are set up. Signed-off-by: Alex Deucher <alexdeucher <at> gmail.com> Signed-off-by: Dave Airlie <airlied <at> redhat.com> f92a8b6758bdc0f277c4f42aa7d736a205ac9ded Author: Alex Deucher <alexdeucher <at> gmail.com> Date: Mon Nov 23 18:40:40 2009 -0500 drm/radeon/kms: handle dp sinks in atom encoder/transmitter tables Signed-off-by: Alex Deucher <alexdeucher <at> gmail.com> Signed-off-by: Dave Airlie <airlied <at> redhat.com> 5801ead6bd6bddf5505d6eab55f84d8ee8106cd8 Author: Alex Deucher <alexdeucher <at> gmail.com> Date: Tue Nov 24 13:32:59 2009 -0500 drm/radeon/kms: add support for DP modesetting Signed-off-by: Alex Deucher <alexdeucher <at> gmail.com> Signed-off-by: Dave Airlie <airlied <at> redhat.com> 6a93cb250a60af1bb7b4070949f8546a2fdc52ef Author: Alex Deucher <alexdeucher <at> gmail.com> Date: Mon Nov 23 17:39:28 2009 -0500 drm/radeon/kms: i2c reorg - keep the atom i2c id in the i2c rec - fix gpio regs for GPIO and MDGPIO on pre-avivo chips - track whether the i2c line is hw capable - track whether the i2c line uses the multimedia i2c block Signed-off-by: Alex Deucher <alexdeucher <at> gmail.com> Signed-off-by: Dave Airlie <airlied <at> redhat.com> 1a66c95a64c9ae0bc8382254f544b24b23f498ec Author: Alex Deucher <alexdeucher <at> gmail.com> Date: Fri Nov 20 19:40:13 2009 -0500 drm/radeon/kms: DP fixes and cleanup from the ddx - dpcp -> dpcd - fix up dig encoder routing - aux transaction table takes delay in 10 usec units Signed-off-by: Alex Deucher <alexdeucher <at> gmail.com> Signed-off-by: Dave Airlie <airlied <at> redhat.com> ffd09c648a76a1cf96872c033e98d4730f9b10a4 Author: Alex Deucher <alexdeucher <at> gmail.com> Date: Tue Nov 24 16:13:23 2009 -0500 drm/radeon/kms: free aux channel i2c adapter on destroy Signed-off-by: Alex Deucher <alexdeucher <at> gmail.com> Signed-off-by: Dave Airlie <airlied <at> redhat.com> 54d9cb47dd6a754e434e5adeccb3a1e2835594fd Author: Dave Airlie <airlied <at> redhat.com> Date: Thu Nov 26 08:49:17 2009 +1000 drm/radeon/kms/dp: fix return in dpcd retrival. Not returning here caused us to get a display port version of 0 for everything this caused power up to not get sent which ends up in a black screen. Signed-off-by: Dave Airlie <airlied <at> redhat.com> 746c1aa4d100f7441423050f34be79f401fbf7d4 Author: Dave Airlie <airlied <at> redhat.com> Date: Tue Dec 8 07:07:28 2009 +1000 drm/radeon/kms: initial radeon displayport porting This is enough to retrieve EDID and DPCP. Signed-off-by: Dave Airlie <airlied <at> redhat.com> 5fbfce7fc906c4a9e3d5e0872e5d6affaca54761 Author: Dave Airlie <airlied <at> redhat.com> Date: Thu Nov 26 08:55:18 2009 +1000 drm/radeon/kms: make displayport work by reorganising vsemph setup. This fix reorganises the initial DP link training slightly, and actually makes DP work under kms here. Signed-off-by: Dave Airlie <airlied <at> redhat.com> d904ef9b00a4473af16766e99f17bdbb5f0fde65 Author: Dave Airlie <airlied <at> redhat.com> Date: Tue Nov 17 06:29:46 2009 +1000 drm/radeon/kms: add support to atom parser for FB read/write FB read/write really doesn't need to access the actual VRAM, we can just use a scratch area. This is required for using atom displayport calls later. Signed-off-by: Dave Airlie <airlied <at> redhat.com> 58682f107ad5178e47a45af3af1851442d05d7fc Author: Dave Airlie <airlied <at> redhat.com> Date: Thu Nov 26 08:56:35 2009 +1000 drm/radeon/kms: do dp link training at dpms on time not mode set. This moves the radeon DP link training call to happen when we dpms on the encoder not when we set the mode. Signed-off-by: Dave Airlie <airlied <at> redhat.com>
Created attachment 32852 [details] Regs when working
Created attachment 32853 [details] Regs when green
If the kernel is booted with radeon.audio=0 it boots perfectly
(In reply to comment #4) > If the kernel is booted with radeon.audio=0 it boots perfectly If your GPU is RV730, you use all functions from rv770.c. This means you should never get r600_audio_init called. I really don't see way how changing radeon.audio could affect anything.
(In reply to comment #5) > (In reply to comment #4) > > If the kernel is booted with radeon.audio=0 it boots perfectly > > If your GPU is RV730, you use all functions from rv770.c. This means you should > never get r600_audio_init called. I really don't see way how changing > radeon.audio could affect anything. > audio was enabled for all chips >= r600 until Dave disabled it by default on r7xx cards until they are working properly. r7xx chips use a lot of the r6xx code since it's common to both asic families.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > If the kernel is booted with radeon.audio=0 it boots perfectly > > > > If your GPU is RV730, you use all functions from rv770.c. This means you should > > never get r600_audio_init called. I really don't see way how changing > > radeon.audio could affect anything. > > > > audio was enabled for all chips >= r600 until Dave disabled it by default on > r7xx cards until they are working properly. r7xx chips use a lot of the r6xx > code since it's common to both asic families. I can not agree. Please check Dave's commit: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=23fff28a9b0529869bffef8aab0d3f350dd3b5a4 He just modified r600_audio_chipset_supported which is called from: 1) r600_audio_init 2) r600_audio_fini But we do not call any of these functions from rv770.c. Ah, and we use rv770.c (functions from it) for rv770, rv730, rv710 and rv740.
r600_hdmi_init is called for all asics and the associated r600_hdmi* functions are called during modesetting, this is likely where the problem lies. But you are right; it looks like the audio option shouldn't make a difference in this case.
(In reply to comment #8) > r600_hdmi_init is called for all asics and the associated r600_hdmi* functions > are called during modesetting, this is likely where the problem lies. But you > are right; it looks like the audio option shouldn't make a difference in this > case. About HDMI I agree. Additionally I compared regs dumps and in both cases regiseter 0x7300 (R600_AUDIO_ENABLE) is 0x000000f0. So it really shows we didn't have r600_audio_init called in Michale's case. And so setting radeon_audio didn't matter. On the opposite in the case of "Regs when green" we have many 0x74xx registers set which responds to R600_HDMI_TMDS1 + x. That indeed could cause corruption (green screen) when programmed incorrectly. Michael: I have few ideas to solve this problems, are you still around? Can you test few patches for me?
Yes I'm still around and I'll happily test any patches or git trees you're willing to through at me to get audio working on my setup.
Created attachment 33584 [details] [review] fast debugging Please apply this patch, recompile, reboot and provide dmesg output. It just prints messages, does not fix anything.
Created attachment 33585 [details] [review] do not set hdmi mode After you test first patch and provide output, please apply this one. It can be applied on top of previous one or on clean branch, it does not matter. Does it workaround green screen problem? It is not supposed to fix audio, just check reason.
Created attachment 33623 [details] With Patch1
Created attachment 33624 [details] With Patch1 and 2 There was no green screen with either patch
Was this what you were after?
(In reply to comment #15) > Was this what you were after? Well, I'm afraid there is something wrong about your testing. I don't see any reason how my first (fast debugging) patch could change anything. It could be some really sensitive timing issue or compiler bug. I don't think any is the case. Anyway I'm reworking HDMI assigning right now, will publish patch this weekend. When we will have HDMI fixed (and hopefully working) we will can focus on green screen again. Meanwhile you can try again drm tree with and without my patch. As I said, I don't see reason how my first patch could fix anything. Can you double check this, please?
This was using the latest head of drm-radeon-testing which has been working fine for a while as per this bug Did you want me to go back to when I had issues or revert the disable HDMI audio commit?
Created attachment 34661 [details] Xorg log with radeon and green HDMI
I have also been experiencing this bug for some weeks using Fedora Rawhide kernels. It had been working fine. I tried the radeon.audio=0 trick mentioned here but it doesn't impact anything. I attached a log FWIW. Otherwise, radeon driver has been great for me, recently suspend starting working which I am very happy about. From reading the bug I guess it's already fixed in radeon HEAD and that will turn up in mainline and then Fedora.
I'm waiting for Linus to release 2.6.34-rc4 to request you for testing again. This release will contain all fixes I wanted to see. Eventually you can use Linus's git if you are comfortable with this. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
Can you try 2.6.34-rc4, please?
(In reply to comment #21) > Can you try 2.6.34-rc4, please? I can confirm this works brilliantly Kudos in getting it into the 2.6.34 release
(In reply to comment #22) > (In reply to comment #21) > > Can you try 2.6.34-rc4, please? > > I can confirm this works brilliantly > > Kudos in getting it into the 2.6.34 release That's great to hear that! Closing bug then :)
I can also confirm it's solved (and compiz!) well done. However now I get overscan on the HDMI where I had 1:1 pixels before. I guess it's a different bug if you don't have any hint.
(In reply to comment #24) > However now I get overscan on the HDMI where I had 1:1 pixels before. Did you change any settings on your TV? Some TV's overscan by default unless you disable it in the TV options.
Created attachment 34978 [details] Xorg log with overscanned HDMI out (no green cast!) on Aspire 8935 > Did you change any settings on your TV? No it's the same TV I used for some months; immediately before the kernel upgrade it was showing 1:1 pixel 1920 x 1080 and after it's overscanned. There's no setting for overscan in the TV's menu system either with HDMI input source. I attach the current /var/log/Xorg.0.log showing overscan, I previously attached one that shows 1:1 pixels on the same laptop and TV. I guess it can make sense to open a new bug, just wondering if there's a magic Option somewhere to guide it not to overscan.
(In reply to comment #26) > No it's the same TV I used for some months; immediately before the kernel > upgrade it was showing 1:1 pixel 1920 x 1080 and after it's overscanned. > > There's no setting for overscan in the TV's menu system either with HDMI input > source. > > I attach the current /var/log/Xorg.0.log showing overscan, I previously > attached one that shows 1:1 pixels on the same laptop and TV. > > I guess it can make sense to open a new bug, just wondering if there's a magic > Option somewhere to guide it not to overscan. Yes, file a new bug. Are you using hdmi audio or just video?
A patch referencing this bug report has been merged in Linux v3.0-rc3: commit 805c22168da76a65c978017d0fe0d59cd048e995 Author: Alex Deucher <alexdeucher@gmail.com> Date: Mon Jun 6 17:39:16 2011 -0400 drm/radeon/kms: disable hdmi audio by default
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.