Hello, Christian König wrote:
Hi Christiaan,
i have some questions about your RS690 HDMI patch. First of all could you send me an XOrg log created with -logverbose 7 ?
Second some questions about individual stuff in the patch:
rhd_audio.c:268 } else { /* * RS600, RS690, RS730? */ RHDRegWrite(Audio, AUDIO_PLL1_MUL, Rate * 50); RHDRegWrite(Audio, AUDIO_PLL1_DIV, Clock * 100); }
Why do you miss initializing of AUDIO_CLK_SRCSEL and AUDIO_TIMING ? I think the missing write to AUDIO_TIMING is the problem behind AC3 pass through not working.
The part you mention does not seem to apply for (at least) the RS690. I just tried the combinations again to see if there is any effect on AC3/DTS passthrough: * RHDRegMask(Audio, AUDIO_TIMING, 0, 0x301); No effect, audio works, AC3 pass through fails. * RHDRegMask(Audio, AUDIO_TIMING, 0x100, 0x301); No effect, audio works, AC3 pass through fails. * RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 0); No effect, audio works, AC3 pass through fails. * RHDRegWrite(Audio, AUDIO_CLK_SRCSEL, 1); No effect, audio works, AC3 pass through fails. No effect what so ever. I'm not sure where the problem lies with the AC3/DTS pass through. When using mplayer it reports the right output format: 48000Hz 2ch ac3 (1 byte per sample). The switch from 16 bits to 8 bits per sample should be detected by AudioUpdateHdmi but is not and audio playback is not started. Right now I'm looking at the ALSA kernel driver part to see how the AC3 settings are being passed, this however seems to be supported although the code contains a lot of fixme's ... Has playback of AC3/DTS been verified on other chipsets????
rhd_audio.c:306 } else { /* * RS600, RS690, RS730? */ if(clear) RHDRegWrite(Audio, AUDIO_SUPPORTED_CODEC, codec); else RHDRegMask(Audio, AUDIO_SUPPORTED_CODEC, codec, codec); }
Why not setting AUDIO_SUPPORTED_SIZE_RATE ? It's unimportant ATM, but if somebody tries to load alsa after the radeonhd driver we would ran into problems.
Just rechecked this one. I had some problems with getting any audio at all and thought it was related to this part; but it's not :-), this part should be identical for all chipsets.
rhd_hdmi.c:475 case RHD_OUTPUT_UNIPHYA: case RHD_OUTPUT_UNIPHYB: case RHD_OUTPUT_KLDSKP_LVTMA: /* This part is doubtfull in my opinion */ RHDRegWrite(hdmi, hdmi->Offset+HDMI_ENABLE, Enable ? 0x110 : 0x0); break;
mhm? Why is this doubtful? 0x110 is the value which gets written on M86, and that also seems to work on anything else.
I ran into some parts where different values seem to be used for R600. Did not take a very detailed look at it and just commented it as an attention point. If there are no problems it's probably not critical.
That's it for the moment, but i think i will have more questions when i figure out how those additional debug registers you've found works.
These new debug registers are not very clear to me. They only seem to apply to RS chips but I did not really play around with any detailed debugging.
Bye, Christian.
I also had one question mark in rhd_hdmi.c around line 448: /* is this OK? Not 0x4000000 ?? */ RHDRegMask(hdmi, hdmi->Offset+HDMI_CNTL, 0x400000, 0x400000); } else { I really have no clue on what this does and I did no testing with different sampling frequencies yet. The 5 instead of 6 zeros could be a simple typo, or you have a lot more insight in what this bit does and had a very good reason for doing it this way :-). Still have to make the Xorg.0.log, system is recording right now so will be a bit later. Great to get some feedback on this patch, hopefully the AC3/DTS will also be solved. System is coming closer and closer to a usable media center :-). Regds, Christiaan van Dijk. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org