On Tue, Sep 08, 2009 at 11:41:02AM -0400, Alex Deucher wrote:
It's not just a simple counter. The code in the drm calls udelay for each iteration of the loop. From radeon_cp.c:
for (i = 0; i < dev_priv->usec_timeout; i++) { if (!(RADEON_READ(RADEON_RBBM_STATUS) & RADEON_RBBM_ACTIVE)) { radeon_do_pixcache_flush(dev_priv); return 0; } DRM_UDELAY(1); }
Alex
Alex, It seems that you are right, there does seem to have always been a DRM_UDELAY there. I wonder how i missed this then. I had to massively bump the usec_delay in rhd_dri.c (up to the limit) and then noticed that this still wasn't enough, and therefor massively increased the counterlimit in DRMCPIdle in rhd_cs.c for it to succeed and to not drop into an engine reset. Now, what i also remember noticing then is that the code behind DRM_RADEON_CP_IDLE did a whole lot more than just checking whether the CP was idle. The bit you pasted here is a clear example of that. We are talking about the DRM_RADEON_CP_IDLE ioctl, but you paste code that deals solely with the RB, a completely different part of the engine, one that gets just some of the register writes that the CP outputs queued into it. And one that might become empty when the CP itself is still chewing on P3 commands. Actually, looking over the same code again now, i am unable to find anything where we wait for the actual CP to go idle. We put some cache flushing commands and such in the the cp ringbuffer and then flush the ringbuffer out. And then we go and wait for the RBBM to go idle. We never wait for the RPTR to catch up with the WPTR, we never wait for the CP to claim that it is idle. All we do is wait for the RBBM to become idle, and the thing is, it might already become idle while the CP is still busy working off something else. So with that knowledge, it now seems quite clear that the DRM_RADEON_CP_IDLE command is broken. But. It has been this kind of broken for ages, and its behaviour is probably depended upon in many places. If this is to be put straight, then another ioctl has to be created to fix this. Luc Verhaegen. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org