First I reported bug #24781 but that was invalid report, there was not bug in code where I thought.

However there are for sure some issues in current ring info debugfs.

**********

1) We count buffer's elements in following way:
r600.c::r600_debugfs_cp_ring_info
count = (rdp + rdev->cp.ring_size - wdp) & rdev->cp.ptr_mask;

a) We don't divide cp.ring_size by 4 but fortunately this doesn't cause problems as we use bit multiplication by mask. However maybe we should do so for code readability?

b) What we count is actually amount of *free* dwords in buffer. This is the same what gets done in radeon_ring_free_size. You can see results of this mistake in bug #24535 comment #6 - amount of free and used dwords is the same which is incorrect. The only exception when this work is empty ring situation. In radeon_ring.c::radeon_ring_free_size we treat 0 as (rdev->cp.ring_size / 4) so we get nice (correct):
> 262128 free dwords in ring
> 0 dwords in ring
then.

Ideally this probably should be:
count = (wdp + rdev->cp.ring_size - rdp) & rdev->cp.ptr_mask;

**********

2) We have inconsistent in reading CP_RB_WPTR and CP_RB_RPTR. This leads to situations like:
> 262127 free dwords in ring
> 0 dwords in ring
where 262127 + 0 != 262144 (and 262144 is buffer size ofc).

That happens because we call radeon_ring_free_size where we calculate amount of free dwords using rdev->cp.rptr and rdev->cp.wptr. Then we read CP_RB_RPTR and CP_RB_WPTR and calculate used dwords. As ring changes often this causes mentioned inconsistency.

I belive we should use rdev->cp.rptr and rdev->cp.wptr in r600_debugfs_cp_ring_info and eventually consider updating rdev->cp.wptr in radeon_ring_free_size.

**********

3) Finally we don't detect ring end in printing ring's content in r600_debugfs_cp_ring_info.