Alex Deucher wrote:
On Mon, Sep 21, 2009 at 5:00 PM, Ales Fiala
wrote: Alex Deucher wrote:
On Mon, Sep 21, 2009 at 4:39 PM, Ales Fiala
wrote: Matthias Hopf wrote:
On Sep 18, 09 13:54:16 -0600, Ales Fiala wrote:
>> What is the meaning of the RV515_MC_STATUS:MC_IDLE bit? >> >> The RV515/516 spec says it "Indicates that there are no pending or >> in-process requests in the MC." >> >> There is code in RHDMCSetup() and RHDRestoreMC() that does the >> following: >> ASSERT((RHDRegRead(rhdPtr, D1VGA_CONTROL) & D1VGA_MODE_ENABLE) != >> D1VGA_MODE_ENABLE); >> ASSERT((RHDRegRead(rhdPtr, D2VGA_CONTROL) & D2VGA_MODE_ENABLE) != >> D2VGA_MODE_ENABLE); >> ASSERT((RHDRegRead(rhdPtr, D1CRTC_CONTROL) & 0x1) != 0x1); >> ASSERT((RHDRegRead(rhdPtr, D2CRTC_CONTROL) & 0x1) != 0x1); >> ASSERT(RHDMCIdle(rhdPtr, 1)); >> >> >> Hm. The code doesn't exist in the way you wrote it here. Either you are using pseudocode, or you're running on an old git version. If the later is the case, please try again with latest git.
If the former is the case, I assume you're talking about RV515MCWaitIdle().
You are right. I do have an old 1.2.4 version. Unfortunately updating at this point in my project would be difficult. I did look at the latest git, however, and the test in RV515MCWaitIdle() looks the same as what I am doing. And I did verify that D1CRTC_CONTROL and D2CRTC_CONTROL are disabled, and D1VGA_CONTROL and D2VGA_CONTROL are also disabled, and VGA_RENDER_CONTROL is disabled.
>> I am getting infrequent failures in the last assertion, indicating >> that >> the >> MC is not idle. I verified that both the VGA anc CRTC controllers >> are >> indeed disabled, Yet the MC_IDLE bit is still wiggling. I wrote a >> little >> piece of code that reads it in a tight loop and indeed it comes on >> every >> 10-20 reads and then immediately goes off. >> >> >> I assume you waited long enough so that there are definitely no acceleration commands left in the queue?
Yes, the Idle bit hasn't settled even after many minutes of waiting.
>> So if the CRTC and VGA controllers are not reading the memory, why is >> the MC >> not idle? >> Could it be that even if the screen is not being refreshed, the >> dynamic >> RAM >> still needs to be refreshed to keep it from losing its contents? >> >> >> Sounds reasonable to me - but I guess only Alex can confirm or deny.
>> If this is the case, I think that this code is flawed. It shouldn't >> assume >> that the MC is idle when the CRTC and VGA controllers are disabled. >> >> >> Actually, e.g. for changing the memory access speed you *have* to wait for the MC to be idle. That said, we don't change the speed yet :-/
One possibility for the meantime would be to use a short loop in order to test whether the MC would get idle at all. Dunno, but Luc probably has a different look on the whole thing.
Matthias
Thanks, and sorry for bothering everyone with old code. But I don't think the MC will ever go idle in the state that it is in. I tried a long enough wait to let it settle and it didn't.
If accel is active, you need to wait for the GUI engine (2D, 3D, CP) to be idle as well. Does it go idle with accel disabled?
Alex
I have checked the RBBM_STATUS register, and it has a value of 0x10000140. That means the only thing that is not idle is the bit 8, HIRQ_ON RBB, request from host interface on the backbone. This is in my experience caused by the act of reading this register itself. Is that what you meant by having accel disabled? I do not use 3D or the DRM, just simple programmed IO. And the X server is otherwise idle during my test.
Should be idle. I'm not sure what's causing the problem in your case. Maybe check the overlays, although I doubt they are active.
Alex
I doubt it's the overlays also, but I will check. And I'll take a look at the radeon driver to see if it does anything different. If I can't figure out anything better I will just disable the MC idle check. I am not programming the memory clock. The only thing I am changing in the MC is the FB location at init time. I don't think it will hurt anything even if it did get changed on the fly. Thanks for your help. Ales -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org