0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

Ales Fiala

17 Sep 2009 17 Sep '09

17:35

Folks, 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)); 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. 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? 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. Thanks for any insight into this. Ales Fiala Hewlett Packard -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Show replies by date

Dave Airlie

18 Sep 18 Sep

03:54

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

On Fri, Sep 18, 2009 at 3:35 AM, Ales Fiala wrote:

...

Folks,

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));

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.

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?

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.

Thanks for any insight into this.

I've just been issues with something in a similiar area, have a look at VGA_RENDER_CONTROL 0x300 register, make sure bits 16,17 are cleared also, as the vga rendered may be accessing memory. Dave. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Ales Fiala

19:54

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

Dave Airlie wrote:

...

On Fri, Sep 18, 2009 at 3:35 AM, Ales Fiala wrote:

...
Folks,

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));

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.

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?

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.

Thanks for any insight into this.

I've just been issues with something in a similiar area, have a look at VGA_RENDER_CONTROL 0x300 register, make sure bits 16,17 are cleared also, as the vga rendered may be accessing memory.

Dave.

Thanks for the sugestion, Dave. I checked the VGA_RENDER_CONTROL register and bits 16,17 are both off. Any other ideas? Anyone? Ales -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Matthias Hopf

21 Sep 21 Sep

17:36

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

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().

...

...
...
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?

...

...
...
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 -- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

17:43

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

On Mon, Sep 21, 2009 at 1:36 PM, 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().

...
...
...
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?

...
...
...
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.

Likely the VGA engine is still doing something. Probably need to port something like: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=52279251fa... to rhd. The MC should be idle when all memory clients (displays, 2D, 3D, overlays, etc. are off). Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Ales Fiala

20:49

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

Alex Deucher wrote:

...

On Mon, Sep 21, 2009 at 1:36 PM, 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().

...
...
...
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?

...
...
...
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.

Likely the VGA engine is still doing something. Probably need to port something like: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=52279251fa... to rhd. The MC should be idle when all memory clients (displays, 2D, 3D, overlays, etc. are off).

Alex

Thanks Alex. Dave Airlie also suggested checking the VGA_RENDER_CONTROL register, which seems to be what is included in the fix you mention. I have verified it and the VGA is disabled in this register also. I do not use 3D or overlays and they should be disabled, but I will double-check that too. Could it be that the MC controller is performing the normal dynamic RAM refresh function? I seem to remember from long time ago that dynamic RAMS need to be refreshed regularly to keep them from losing their contents. Ales -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

20:54

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

On Mon, Sep 21, 2009 at 4:49 PM, Ales Fiala wrote:

...

Alex Deucher wrote:

...
On Mon, Sep 21, 2009 at 1:36 PM, 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().

...
...
...
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?

...
...
...
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.

Likely the VGA engine is still doing something. Probably need to port something like:

http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=52279251fa... to rhd. The MC should be idle when all memory clients (displays, 2D, 3D, overlays, etc. are off).

Alex

Thanks Alex. Dave Airlie also suggested checking the VGA_RENDER_CONTROL register, which seems to be what is included in the fix you mention. I have verified it and the VGA is disabled in this register also. I do not use 3D or overlays and they should be disabled, but I will double-check that too.

"2d" accel (EXA) also uses the 3D engine.

...

Could it be that the MC controller is performing the normal dynamic RAM refresh function? I seem to remember from long time ago that dynamic RAMS need to be refreshed regularly to keep them from losing their contents.

The MC idle bit refers to client blocks accessing video memory, so vram refresh doesn't apply here. You may want to check other status regs and see if any other blocks are active. Does the mc idle code in radeon (xf86-video-ati) also have trouble getting mc idle? If not, then you could compare reg states and see what might be different. Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Ales Fiala

20:39

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

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. Ales -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

20:44

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

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 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Ales Fiala

21:00

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

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. Ales Ales -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Alex Deucher

21:05

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

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 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

Ales Fiala

21:13

New subject: 0x719B:0x1002:0x0602: FireMV 2250 Problem with RHDMCIdle

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

5333

Age (days ago)

5337

Last active (days ago)

List overview

Download

11 comments

4 participants

participants (4)

Ales Fiala
Alex Deucher
Dave Airlie
Matthias Hopf