From: Christian K. <dea...@vo...> - 2009-09-27 19:39:01
Attachments:
0001-drm-radeon-kms-HDMI-support-for-R600-KMS.patch
|
Hi everybody, since i didn't got so much todo in the last week than i thought i would, i finally sit down and ported the HDMI support for R600 and up chipsets from radeonhd to KMS. So the attached patch is based on Dave Airlies drm-next tree (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next). It's been a while since i last coded inside kernel space and the patch is not very well tested, so there are quite a bunch of "TODO"s inside the code, but at least it's a starting point and seems to work fine with the radeon driver+KMS. So any comments or test results would be very welcome. Bye, Christian. |
From: Rafał M. <za...@gm...> - 2009-09-28 14:28:25
|
2009/9/27 Christian König <dea...@vo...>: > since i didn't got so much todo in the last week than i thought i would, > i finally sit down and ported the HDMI support for R600 and up chipsets > from radeonhd to KMS. > > So the attached patch is based on Dave Airlies drm-next tree > (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next). > > It's been a while since i last coded inside kernel space and the patch > is not very well tested, so there are quite a bunch of "TODO"s inside > the code, but at least it's a starting point and seems to work fine with > the radeon driver+KMS. > > So any comments or test results would be very welcome. It doesn't work for me, and sorry but I'm too dumb to fix that :( Playback speed in mplayer is alright, but my AV doesn't get any audio signal. --- kms.playing.broken.dump.log 2009-09-28 16:06:00.000000000 +0200 +++ radeonhd.playing.dump.log 2009-09-28 14:21:51.000000000 +0200 @@ -5,8 +5,8 @@ 0x0518: 0x00E297D0 0x051C: 0x00000000 0x0520: 0x00000070 -0x0524: 0x00249F00 -0x0528: 0x008719F0 +0x0524: 0x00000000 +0x0528: 0x00000000 0x052C: 0x00000000 0x0530: 0x00000070 0x0534: 0x00000000 @@ -24,7 +24,7 @@ 0x7388: 0x00010001 0x738C: 0x00020002 0x7390: 0x00000001 -0x7394: 0x00020070 +0x7394: 0x00060040 0x7398: 0x00000001 0x739C: 0x00000009 0x73A0: 0x00000201 It seems KMS set also second pair of registers, probably for my LVDS (PANEL). No reason for that, but shouldn't hurt, right? I don't know meaning of R600_AUDIO_SUPPORTED_SIZE_RATE (0x7394) is this something important? I've tried rhd_dump -w 0524: 0x00000000 1:00.0 rhd_dump -w 0528: 0x00000000 1:00.0 rhd_dump -w 7394: 0x00060040 1:00.0 but it didn't help. It reminds me RV770 issue from radeonhd, where we don't get working audio. All registers are 100% alright, but no sound. Maybe order of setting registers matters? Do we set registers in different order than radeonhd does? Please, check attached log files. In both cases I've started playback *just once*. In case of radeonhd there is one RHDHdmiUpdateAudioSettings operation. However KMS prints 4*playing messages. -- Rafał |
From: Rafał M. <za...@gm...> - 2009-09-28 14:30:49
|
W dniu 28 września 2009 16:28 użytkownik Rafał Miłecki <za...@gm...> napisał: > It doesn't work for me, and sorry but I'm too dumb to fix that :( > > Playback speed in mplayer is alright, but my AV doesn't get any audio signal. Just to make it sure: I don't need to set any magic options, do I? audio param seems to be enabled by default, plus it seems to be respected as registers are being set and mplayer playback speed is correct. Also, my GPU is M82==RV620. -- Rafał |
From: Alex D. <ale...@gm...> - 2009-09-28 15:01:12
|
On Sun, Sep 27, 2009 at 3:38 PM, Christian König <dea...@vo...> wrote: > Hi everybody, > > since i didn't got so much todo in the last week than i thought i would, > i finally sit down and ported the HDMI support for R600 and up chipsets > from radeonhd to KMS. > > So the attached patch is based on Dave Airlies drm-next tree > (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next). > > It's been a while since i last coded inside kernel space and the patch > is not very well tested, so there are quite a bunch of "TODO"s inside > the code, but at least it's a starting point and seems to work fine with > the radeon driver+KMS. > > So any comments or test results would be very welcome. Thanks for doing this Christian, I'd been planning to start on this myself, but hadn't had time yet. When I get back from XDC, I should be able to help out a bit with this to fill in the gaps and get the proper register names and bitfields filled in. Alex |
From: Christian K. <dea...@vo...> - 2009-09-30 22:50:21
|
Am Montag, den 28.09.2009, 16:28 +0200 schrieb Rafał Miłecki: > It doesn't work for me, and sorry but I'm too dumb to fix that :( > > Playback speed in mplayer is alright, but my AV doesn't get any audio signal. > It seems KMS set also second pair of registers, probably for my LVDS > (PANEL). No reason for that, but shouldn't hurt, right? As long as register 0x0534 isn't changed that shouldn't hurt bit. > > I don't know meaning of > R600_AUDIO_SUPPORTED_SIZE_RATE (0x7394) > is this something important? No, that register only tells alsa which sampling rates and bits per sample are supported. As long as you don't want to use 24bit audio or sampling rates other than 48000 Hz we don't need to change a bit. > It reminds me RV770 issue from radeonhd, where we don't get working > audio. All registers are 100% alright, but no sound. Your script is missing something, the 0x7400, 0x7700 and 0x7800 are only bases. Try comparing the whole 0x7400-0x74ff, 0x7700-0x77ff and 0x7800-0x78ff ranges. For the RV770 i have the strong feeling that ATI have started to double buffer the HDMI registers, and there is a bit somewhere that tells the hardware to start using the new values on the next vertical or horizontal retrace. > Maybe order of setting registers matters? Do we set registers in > different order than radeonhd does? There are registers in the 0x7304-0x7340 range that can deadlock the audio codec if not written in the right order (i think they are for interrupt and dma control), but i really avoid touching those, the bios sets them up on boot pretty fine. > Please, check attached log files. In both cases I've started playback > *just once*. In case of radeonhd there is one > RHDHdmiUpdateAudioSettings operation. However KMS prints 4*playing > messages. Yeah that's another point that could go wrong. At the moment i enable hdmi on any digital interface i can find, even if it's an LVDS, the worst thing that could happen is that you don't get a picture on your panel. Bye, Christian. |
From: Rafał M. <za...@gm...> - 2009-10-01 19:20:00
|
W dniu 1 października 2009 00:50 użytkownik Christian König <dea...@vo...> napisał: > Am Montag, den 28.09.2009, 16:28 +0200 schrieb Rafał Miłecki: >> It reminds me RV770 issue from radeonhd, where we don't get working >> audio. All registers are 100% alright, but no sound. > Your script is missing something, the 0x7400, 0x7700 and 0x7800 are only > bases. Try comparing the whole 0x7400-0x74ff, 0x7700-0x77ff and > 0x7800-0x78ff ranges. How could I miss that? :/ > For the RV770 i have the strong feeling that ATI have started to double > buffer the HDMI registers, and there is a bit somewhere that tells the > hardware to start using the new values on the next vertical or > horizontal retrace. Did you try reseting base+R600_HDMI_ENABLE on RV770? Or setting it to some magic values? Maybe this register has some value that means for GPU "read settings again"? Can we somehow run fglrx in gdb and run in operation by operation? To track it's changes to registers? >> Please, check attached log files. In both cases I've started playback >> *just once*. In case of radeonhd there is one >> RHDHdmiUpdateAudioSettings operation. However KMS prints 4*playing >> messages. > Yeah that's another point that could go wrong. At the moment i enable > hdmi on any digital interface i can find, even if it's an LVDS, the > worst thing that could happen is that you don't get a picture on your > panel. I thought about that but I've LVDS, VGA and HDMI. That are 3 interfaces vs. 4 playing messages. Also I believe that on starting KMS I get two "stopped" messages (will verify that). -- Rafał |
From: Rafał M. <za...@gm...> - 2009-10-01 20:12:00
|
W dniu 1 października 2009 00:50 użytkownik Christian König <dea...@vo...> napisał: > Your script is missing something, the 0x7400, 0x7700 and 0x7800 are only > bases. Try comparing the whole 0x7400-0x74ff, 0x7700-0x77ff and > 0x7800-0x78ff ranges. OK, I've compared radeonhd and KMS with that registers. Logs attached (radeonhd.playing.dump.log, kms.playing.broken.dump.log). I've diffed them and used wrote radeonhd's values (potential.fix.sh). After executing potential.fix.sh nothing changed: no sound, no corruptions, playback speed correct. Then I dumped registers once more (kms.hacked.log). Comparing radeonhd.playing.dump.log with kms.hacked.log showed registers that didn't /accept/ new values. Tried overwriting again but didn't success on that (failed.changes.log). -- Rafał |
From: Christian K. <dea...@vo...> - 2009-10-04 18:23:14
|
Am Donnerstag, den 01.10.2009, 22:11 +0200 schrieb Rafał Miłecki: > OK, I've compared radeonhd and KMS with that registers. Logs attached > (radeonhd.playing.dump.log, kms.playing.broken.dump.log). > > I've diffed them and used wrote radeonhd's values (potential.fix.sh). > > After executing potential.fix.sh nothing changed: no sound, no > corruptions, playback speed correct. > > Then I dumped registers once more (kms.hacked.log). > > Comparing radeonhd.playing.dump.log with kms.hacked.log showed > registers that didn't /accept/ new values. > > Tried overwriting again but didn't success on that (failed.changes.log). That's ok, the register values you could overwrite are read only status registers, with the exception of the 0x7408 register, but this really doesn't matter much. But there is something else which is very interesting: 0x74C4: 0x00000000 That's the last transmitted CTS value which is used for clock recovery in your AV receiver. The setup which values should be transmitted for the different sampling rates is correct (register 0x74AC, 0x74B4, 0x74BC), but this register is still 0 could only mean one thing: we never transmitted a single value. Check the registers 0x75A0 and 0x79A0 (RV620_DIG[12]_CNTL), i suspect that the transmitter isn't running in HDMI mode, maybe because of failed auto detection, but i am not 100% sure. Bye, Christian. |
From: Rafał M. <za...@gm...> - 2009-10-05 00:10:34
|
W dniu 4 października 2009 20:22 użytkownik Christian König <dea...@vo...> napisał: > Check the registers 0x75A0 and 0x79A0 (RV620_DIG[12]_CNTL), i suspect > that the transmitter isn't running in HDMI mode, maybe because of failed > auto detection, but i am not 100% sure. Bingo! Manual: 0x75A0: 0x00000211 → 0x00000311 made the trick. It's 2am here and I'm leaving early tomorrow, so won't able to fix your patch. Should be able to try it next weekend, if you won't do it first of course :) -- Rafał |
From: Alex D. <ale...@gm...> - 2009-10-07 23:02:08
|
On Sun, Sep 27, 2009 at 3:38 PM, Christian König <dea...@vo...> wrote: > Hi everybody, > > since i didn't got so much todo in the last week than i thought i would, > i finally sit down and ported the HDMI support for R600 and up chipsets > from radeonhd to KMS. > > So the attached patch is based on Dave Airlies drm-next tree > (http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-next). > > It's been a while since i last coded inside kernel space and the patch > is not very well tested, so there are quite a bunch of "TODO"s inside > the code, but at least it's a starting point and seems to work fine with > the radeon driver+KMS. > > So any comments or test results would be very welcome. FYI, I've committed this patch to my local drm tree as well as several others to clean up and clarify things (and hopefully fix some bugs). Just waiting for approval to release it for testing. Thanks for your work on this. Alex |
From: Christian K. <dea...@vo...> - 2009-10-11 22:02:11
|
Am Mittwoch, den 07.10.2009, 19:01 -0400 schrieb Alex Deucher: > FYI, I've committed this patch to my local drm tree as well as several > others to clean up and clarify things (and hopefully fix some bugs). > Just waiting for approval to release it for testing. Thanks for your > work on this. Here is the next round of patches, in my previously patch i assumed that the HDMI auto detection code is working properly, which proved not to be the case. Attached are two patches, the first one is a bugfix to the current HDMI auto detection code, currently there are two ugly bugs in this code so i think this bugfix can go strait to mainline. The second is the known HDMI support patch, rebased to the state after applying the first one, and while at it fixing some more bugs/cleaning things up a bit. So please revert my previous patch and apply this one. I promise to make incremental patches in the future. Regards, Christian. |
From: Rafał M. <za...@gm...> - 2009-10-11 22:39:47
|
2009/10/12 Christian König <dea...@vo...>: > Attached are two patches, the first one is a bugfix to the current HDMI > auto detection code, currently there are two ugly bugs in this code so i > think this bugfix can go strait to mainline. Minor issue noticed on applying: # git am ../0001-drm-radeon-kms-fix-HDMI-auto-detection.patch Applying: drm/radeon/kms: fix HDMI auto detection /usr/src/drm-2.6/.git/rebase-apply/patch:76: trailing whitespace. DRM_INFO("encoder %d HDMI %sdetected\n", warning: 1 line adds whitespace errors. -- Rafał |
From: Alex D. <ale...@gm...> - 2009-10-14 04:30:58
|
On Sun, Oct 11, 2009 at 6:01 PM, Christian König <dea...@vo...> wrote: > Am Mittwoch, den 07.10.2009, 19:01 -0400 schrieb Alex Deucher: >> FYI, I've committed this patch to my local drm tree as well as several >> others to clean up and clarify things (and hopefully fix some bugs). >> Just waiting for approval to release it for testing. Thanks for your >> work on this. > Here is the next round of patches, in my previously patch i assumed that > the HDMI auto detection code is working properly, which proved not to be > the case. > > Attached are two patches, the first one is a bugfix to the current HDMI > auto detection code, currently there are two ugly bugs in this code so i > think this bugfix can go strait to mainline. I think this first patch will prevent the edid from getting updated when you switch monitors. We probably need to add a flag like we do for use_digital or better logic in radeon_ddc_get_modes(). Alex > > The second is the known HDMI support patch, rebased to the state after > applying the first one, and while at it fixing some more bugs/cleaning > things up a bit. > > So please revert my previous patch and apply this one. I promise to make > incremental patches in the future. > > Regards, > Christian. > |
From: Rafał M. <za...@gm...> - 2009-10-12 16:08:18
|
2009/10/12 Christian König <dea...@vo...>: > The second is the known HDMI support patch, rebased to the state after > applying the first one, and while at it fixing some more bugs/cleaning > things up a bit. > > So please revert my previous patch and apply this one. I promise to make > incremental patches in the future. Christian, thank you for your work. HDMI works charming now :) It still seems to be enabled on my PANEL, but not more issue with 0x75A0 register :) I can play normal audio, AC3 and DTS on my RV620. I feel KMS will be my main configuration soon :) -- Rafał |
From: Rafał M. <za...@gm...> - 2009-10-12 17:44:50
|
W dniu 12 października 2009 18:08 użytkownik Rafał Miłecki <za...@gm...> napisał: > 2009/10/12 Christian König <dea...@vo...>: >> The second is the known HDMI support patch, rebased to the state after >> applying the first one, and while at it fixing some more bugs/cleaning >> things up a bit. >> >> So please revert my previous patch and apply this one. I promise to make >> incremental patches in the future. > > Christian, thank you for your work. HDMI works charming now :) It > still seems to be enabled on my PANEL, but not more issue with 0x75A0 > register :) > > I can play normal audio, AC3 and DTS on my RV620. Earlier I ignored something weird in logs: [ 432.762808] [drm] Enabling audio support [ 432.762837] [drm] using HDMI engine at offset 0x0000 for encoder 0x15 [ 432.762926] [drm] using HDMI engine at offset 0x7800 for encoder 0x1f [ 432.762968] [drm] using HDMI engine at offset 0x7400 for encoder 0x1e I thought it's related to bug with connector: https://bugs.freedesktop.org/show_bug.cgi?id=24479 but after applying agd5f's patch I still see that. -- Rafał |