[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread Christian König 
Hi Jerome,

I totally agree that we can remove the following debugfs files, since 
everything that just prints out or modifies register informations 
doesn't belongs into the kernel driver and should be moved to radeontool 
instead.
> static int r100_debugfs_rbbm_info(struct seq_file *m, void *data)
> static int r100_debugfs_cp_ring_info(struct seq_file *m, void *data)
> static int r100_debugfs_cp_csq_fifo(struct seq_file *m, void *data)
> static int r100_debugfs_mc_info(struct seq_file *m, void *data)
> static int rv370_debugfs_pcie_gart_info(struct seq_file *m, void *data)
> static int r420_debugfs_pipes_info(struct seq_file *m, void *data)
> static int r600_debugfs_mc_info(struct seq_file *m, void *data)
> static int rs400_debugfs_gart_info(struct seq_file *m, void *data)
> static int rv515_debugfs_pipes_info(struct seq_file *m, void *data)
> static int rv515_debugfs_ga_info(struct seq_file *m, void *data)

But I disagree that we should remove the following two, cause they print 
out driver internal data structures and it isn't easy to gain access to 
those, at least without a debugger and allot of patience.
> static int radeon_debugfs_fence_info(struct seq_file *m, void *data)
> static int radeon_debugfs_sa_info(struct seq_file *m, void *data)

Also I think I should mention that your patch doesn't touches the 
following two debugfs files, probably because of the same reason as the 
two above.
> static int radeon_mm_dump_table(struct seq_file *m, void *data)
> static int radeon_debugfs_pm_info(struct seq_file *m, void *data)

I also think that we should keep the ring debugfs file but of course not 
with the IB dumping facility, since otherwise we pretty much lose any 
possibility to look into multi ring lockups, which is something I 
currently spend most of my time on.
> static int radeon_debugfs_ring_info(struct seq_file *m, void *data)

Additionally I have some comments on the dumping patch itself, but going 
to write that in a separate mail.

Cheers,
Christian.

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread Alex Deucher 
On Thu, Apr 26, 2012 at 9:36 AM, Jerome Glisse  wrote:
> 2012/4/26 David Airlie :
>>
>>
>> - Original Message -
>>> From: "Christian K?nig" 
>>> To: "j glisse" 
>>> Cc: "Jerome Glisse" , dri-devel at 
>>> lists.freedesktop.org
>>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>>> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>>>
>>> Hi Jerome,
>>>
>>> I totally agree that we can remove the following debugfs files, since
>>> everything that just prints out or modifies register informations
>>> doesn't belongs into the kernel driver and should be moved to
>>> radeontool
>>> instead.
>>
>> In the future with secure boot we will need a better mechanism to diagnose 
>> things
>> than a userspace tool mapping pci bars, which we can't allow to happen in a 
>> secure
>> boot environment, so dropping all the files might not be a good idea unless 
>> we
>> provide a mechanism for radeontool to use. We can't allow userspace to 
>> read/write
>> arbitrary registers and stay secure.
>>
>> Dave.
>
> Well those files are useless, each time i debug a lockup and try to
> use them i loose
> time on them as they never helped me so far and i seriously doubt they
> would help
> me in the future or anyone else.
>
> For secure boot my guess is that radeontool will become obsolete and
> by that time
> we might need to add some reg dumping. But none of the current files
> seems usefull
> to me.

We can always expose the mmio bar (and vbios for that matter) via
ioctl or sysfs for radeontool.  We should try and write a better
unified tool suite.

Alex

>
> The fence and sa files might make sense to debug the associated code
> as it's nice
> to be able to dump associated kernel struct.
>
> Cheers,
> Jerome
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread Jerome Glisse 
2012/4/26 David Airlie :
>
>
> - Original Message -
>> From: "Christian K?nig" 
>> To: "j glisse" 
>> Cc: "Jerome Glisse" , dri-devel at 
>> lists.freedesktop.org
>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>>
>> Hi Jerome,
>>
>> I totally agree that we can remove the following debugfs files, since
>> everything that just prints out or modifies register informations
>> doesn't belongs into the kernel driver and should be moved to
>> radeontool
>> instead.
>
> In the future with secure boot we will need a better mechanism to diagnose 
> things
> than a userspace tool mapping pci bars, which we can't allow to happen in a 
> secure
> boot environment, so dropping all the files might not be a good idea unless we
> provide a mechanism for radeontool to use. We can't allow userspace to 
> read/write
> arbitrary registers and stay secure.
>
> Dave.

Well those files are useless, each time i debug a lockup and try to
use them i loose
time on them as they never helped me so far and i seriously doubt they
would help
me in the future or anyone else.

For secure boot my guess is that radeontool will become obsolete and
by that time
we might need to add some reg dumping. But none of the current files
seems usefull
to me.

The fence and sa files might make sense to debug the associated code
as it's nice
to be able to dump associated kernel struct.

Cheers,
Jerome

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread Alex Deucher 
On Thu, Apr 26, 2012 at 9:36 AM, Jerome Glisse  wrote:
> 2012/4/26 David Airlie :
>>
>>
>> - Original Message -
>>> From: "Christian König" 
>>> To: "j glisse" 
>>> Cc: "Jerome Glisse" , dri-devel@lists.freedesktop.org
>>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>>> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>>>
>>> Hi Jerome,
>>>
>>> I totally agree that we can remove the following debugfs files, since
>>> everything that just prints out or modifies register informations
>>> doesn't belongs into the kernel driver and should be moved to
>>> radeontool
>>> instead.
>>
>> In the future with secure boot we will need a better mechanism to diagnose 
>> things
>> than a userspace tool mapping pci bars, which we can't allow to happen in a 
>> secure
>> boot environment, so dropping all the files might not be a good idea unless 
>> we
>> provide a mechanism for radeontool to use. We can't allow userspace to 
>> read/write
>> arbitrary registers and stay secure.
>>
>> Dave.
>
> Well those files are useless, each time i debug a lockup and try to
> use them i loose
> time on them as they never helped me so far and i seriously doubt they
> would help
> me in the future or anyone else.
>
> For secure boot my guess is that radeontool will become obsolete and
> by that time
> we might need to add some reg dumping. But none of the current files
> seems usefull
> to me.

We can always expose the mmio bar (and vbios for that matter) via
ioctl or sysfs for radeontool.  We should try and write a better
unified tool suite.

Alex

>
> The fence and sa files might make sense to debug the associated code
> as it's nice
> to be able to dump associated kernel struct.
>
> Cheers,
> Jerome
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread Jerome Glisse 
2012/4/26 David Airlie :
>
>
> - Original Message -
>> From: "Christian König" 
>> To: "j glisse" 
>> Cc: "Jerome Glisse" , dri-devel@lists.freedesktop.org
>> Sent: Thursday, 26 April, 2012 10:11:12 AM
>> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
>>
>> Hi Jerome,
>>
>> I totally agree that we can remove the following debugfs files, since
>> everything that just prints out or modifies register informations
>> doesn't belongs into the kernel driver and should be moved to
>> radeontool
>> instead.
>
> In the future with secure boot we will need a better mechanism to diagnose 
> things
> than a userspace tool mapping pci bars, which we can't allow to happen in a 
> secure
> boot environment, so dropping all the files might not be a good idea unless we
> provide a mechanism for radeontool to use. We can't allow userspace to 
> read/write
> arbitrary registers and stay secure.
>
> Dave.

Well those files are useless, each time i debug a lockup and try to
use them i loose
time on them as they never helped me so far and i seriously doubt they
would help
me in the future or anyone else.

For secure boot my guess is that radeontool will become obsolete and
by that time
we might need to add some reg dumping. But none of the current files
seems usefull
to me.

The fence and sa files might make sense to debug the associated code
as it's nice
to be able to dump associated kernel struct.

Cheers,
Jerome
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread David Airlie 


- Original Message -
> From: "Christian K?nig" 
> To: "j glisse" 
> Cc: "Jerome Glisse" , dri-devel at 
> lists.freedesktop.org
> Sent: Thursday, 26 April, 2012 10:11:12 AM
> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
> 
> Hi Jerome,
> 
> I totally agree that we can remove the following debugfs files, since
> everything that just prints out or modifies register informations
> doesn't belongs into the kernel driver and should be moved to
> radeontool
> instead.

In the future with secure boot we will need a better mechanism to diagnose 
things
than a userspace tool mapping pci bars, which we can't allow to happen in a 
secure
boot environment, so dropping all the files might not be a good idea unless we
provide a mechanism for radeontool to use. We can't allow userspace to 
read/write
arbitrary registers and stay secure.

Dave.

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread David Airlie 


- Original Message -
> From: "Christian König" 
> To: "j glisse" 
> Cc: "Jerome Glisse" , dri-devel@lists.freedesktop.org
> Sent: Thursday, 26 April, 2012 10:11:12 AM
> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
> 
> Hi Jerome,
> 
> I totally agree that we can remove the following debugfs files, since
> everything that just prints out or modifies register informations
> doesn't belongs into the kernel driver and should be moved to
> radeontool
> instead.

In the future with secure boot we will need a better mechanism to diagnose 
things
than a userspace tool mapping pci bars, which we can't allow to happen in a 
secure
boot environment, so dropping all the files might not be a good idea unless we
provide a mechanism for radeontool to use. We can't allow userspace to 
read/write
arbitrary registers and stay secure.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-26 Thread Christian König 

Hi Jerome,

I totally agree that we can remove the following debugfs files, since 
everything that just prints out or modifies register informations 
doesn't belongs into the kernel driver and should be moved to radeontool 
instead.

static int r100_debugfs_rbbm_info(struct seq_file *m, void *data)
static int r100_debugfs_cp_ring_info(struct seq_file *m, void *data)
static int r100_debugfs_cp_csq_fifo(struct seq_file *m, void *data)
static int r100_debugfs_mc_info(struct seq_file *m, void *data)
static int rv370_debugfs_pcie_gart_info(struct seq_file *m, void *data)
static int r420_debugfs_pipes_info(struct seq_file *m, void *data)
static int r600_debugfs_mc_info(struct seq_file *m, void *data)
static int rs400_debugfs_gart_info(struct seq_file *m, void *data)
static int rv515_debugfs_pipes_info(struct seq_file *m, void *data)
static int rv515_debugfs_ga_info(struct seq_file *m, void *data)


But I disagree that we should remove the following two, cause they print 
out driver internal data structures and it isn't easy to gain access to 
those, at least without a debugger and allot of patience.

static int radeon_debugfs_fence_info(struct seq_file *m, void *data)
static int radeon_debugfs_sa_info(struct seq_file *m, void *data)


Also I think I should mention that your patch doesn't touches the 
following two debugfs files, probably because of the same reason as the 
two above.

static int radeon_mm_dump_table(struct seq_file *m, void *data)
static int radeon_debugfs_pm_info(struct seq_file *m, void *data)


I also think that we should keep the ring debugfs file but of course not 
with the IB dumping facility, since otherwise we pretty much lose any 
possibility to look into multi ring lockups, which is something I 
currently spend most of my time on.

static int radeon_debugfs_ring_info(struct seq_file *m, void *data)


Additionally I have some comments on the dumping patch itself, but going 
to write that in a separate mail.


Cheers,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-25 Thread j.gli...@gmail.com 
From: Jerome Glisse 

Those file never were really helpfull in debuging.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r100.c |  186 -
 drivers/gpu/drm/radeon/r300.c |   50 -
 drivers/gpu/drm/radeon/r420.c |   45 
 drivers/gpu/drm/radeon/r520.c |1 -
 drivers/gpu/drm/radeon/r600.c |   35 --
 drivers/gpu/drm/radeon/radeon_asic.h  |5 -
 drivers/gpu/drm/radeon/radeon_fence.c |   47 
 drivers/gpu/drm/radeon/radeon_ring.c  |  107 ---
 drivers/gpu/drm/radeon/rs400.c|   88 
 drivers/gpu/drm/radeon/rs600.c|7 --
 drivers/gpu/drm/radeon/rs690.c|1 -
 drivers/gpu/drm/radeon/rv515.c|   77 --
 12 files changed, 0 insertions(+), 649 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index fe33d35..9e69a95 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1094,9 +1094,6 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
uint32_t tmp;
int r;

-   if (r100_debugfs_cp_init(rdev)) {
-   DRM_ERROR("Failed to register debugfs file for CP !\n");
-   }
if (!rdev->me_fw) {
r = r100_cp_init_microcode(rdev);
if (r) {
@@ -2604,178 +2601,6 @@ void r100_set_safe_registers(struct radeon_device *rdev)
}
 }

-/*
- * Debugfs info
- */
-#if defined(CONFIG_DEBUG_FS)
-static int r100_debugfs_rbbm_info(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct radeon_device *rdev = dev->dev_private;
-   uint32_t reg, value;
-   unsigned i;
-
-   seq_printf(m, "RBBM_STATUS 0x%08x\n", RREG32(RADEON_RBBM_STATUS));
-   seq_printf(m, "RBBM_CMDFIFO_STAT 0x%08x\n", RREG32(0xE7C));
-   seq_printf(m, "CP_STAT 0x%08x\n", RREG32(RADEON_CP_STAT));
-   for (i = 0; i < 64; i++) {
-   WREG32(RADEON_RBBM_CMDFIFO_ADDR, i | 0x100);
-   reg = (RREG32(RADEON_RBBM_CMDFIFO_DATA) - 1) >> 2;
-   WREG32(RADEON_RBBM_CMDFIFO_ADDR, i);
-   value = RREG32(RADEON_RBBM_CMDFIFO_DATA);
-   seq_printf(m, "[0x%03X] 0x%04X=0x%08X\n", i, reg, value);
-   }
-   return 0;
-}
-
-static int r100_debugfs_cp_ring_info(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct radeon_device *rdev = dev->dev_private;
-   struct radeon_ring *ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
-   uint32_t rdp, wdp;
-   unsigned count, i, j;
-
-   radeon_ring_free_size(rdev, ring);
-   rdp = RREG32(RADEON_CP_RB_RPTR);
-   wdp = RREG32(RADEON_CP_RB_WPTR);
-   count = (rdp + ring->ring_size - wdp) & ring->ptr_mask;
-   seq_printf(m, "CP_STAT 0x%08x\n", RREG32(RADEON_CP_STAT));
-   seq_printf(m, "CP_RB_WPTR 0x%08x\n", wdp);
-   seq_printf(m, "CP_RB_RPTR 0x%08x\n", rdp);
-   seq_printf(m, "%u free dwords in ring\n", ring->ring_free_dw);
-   seq_printf(m, "%u dwords in ring\n", count);
-   for (j = 0; j <= count; j++) {
-   i = (rdp + j) & ring->ptr_mask;
-   seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
-   }
-   return 0;
-}
-
-
-static int r100_debugfs_cp_csq_fifo(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct radeon_device *rdev = dev->dev_private;
-   uint32_t csq_stat, csq2_stat, tmp;
-   unsigned r_rptr, r_wptr, ib1_rptr, ib1_wptr, ib2_rptr, ib2_wptr;
-   unsigned i;
-
-   seq_printf(m, "CP_STAT 0x%08x\n", RREG32(RADEON_CP_STAT));
-   seq_printf(m, "CP_CSQ_MODE 0x%08x\n", RREG32(RADEON_CP_CSQ_MODE));
-   csq_stat = RREG32(RADEON_CP_CSQ_STAT);
-   csq2_stat = RREG32(RADEON_CP_CSQ2_STAT);
-   r_rptr = (csq_stat >> 0) & 0x3ff;
-   r_wptr = (csq_stat >> 10) & 0x3ff;
-   ib1_rptr = (csq_stat >> 20) & 0x3ff;
-   ib1_wptr = (csq2_stat >> 0) & 0x3ff;
-   ib2_rptr = (csq2_stat >> 10) & 0x3ff;
-   ib2_wptr = (csq2_stat >> 20) & 0x3ff;
-   seq_printf(m, "CP_CSQ_STAT 0x%08x\n", csq_stat);
-   seq_printf(m, "CP_CSQ2_STAT 0x%08x\n", csq2_stat);
-   seq_printf(m, "Ring rptr %u\n", r_rptr);
-   seq_printf(m, "Ring wptr %u\n", r_wptr);
-   seq_printf(m, "Indirect1 rptr %u\n", ib1_rptr);
-   seq_printf(m, "Indirect1 wptr %u\n", ib1_wptr);
-   seq_printf(m, "Indirect2 rptr %u\n", ib2_rptr);
-   seq_printf(m, "Indirect2 wptr %u\n", ib2_wptr);
-   /* FIXME: 0, 128, 640 depends on fifo setup see cp_init_kms
-* 128 = indirect1_start * 8 & 640 = indirect2_start * 8 */
-   seq_printf(m, "Ring fifo:\n");
-   for

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

2012-04-25 Thread j . glisse 
From: Jerome Glisse 

Those file never were really helpfull in debuging.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r100.c |  186 -
 drivers/gpu/drm/radeon/r300.c |   50 -
 drivers/gpu/drm/radeon/r420.c |   45 
 drivers/gpu/drm/radeon/r520.c |1 -
 drivers/gpu/drm/radeon/r600.c |   35 --
 drivers/gpu/drm/radeon/radeon_asic.h  |5 -
 drivers/gpu/drm/radeon/radeon_fence.c |   47 
 drivers/gpu/drm/radeon/radeon_ring.c  |  107 ---
 drivers/gpu/drm/radeon/rs400.c|   88 
 drivers/gpu/drm/radeon/rs600.c|7 --
 drivers/gpu/drm/radeon/rs690.c|1 -
 drivers/gpu/drm/radeon/rv515.c|   77 --
 12 files changed, 0 insertions(+), 649 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index fe33d35..9e69a95 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1094,9 +1094,6 @@ int r100_cp_init(struct radeon_device *rdev, unsigned 
ring_size)
uint32_t tmp;
int r;
 
-   if (r100_debugfs_cp_init(rdev)) {
-   DRM_ERROR("Failed to register debugfs file for CP !\n");
-   }
if (!rdev->me_fw) {
r = r100_cp_init_microcode(rdev);
if (r) {
@@ -2604,178 +2601,6 @@ void r100_set_safe_registers(struct radeon_device *rdev)
}
 }
 
-/*
- * Debugfs info
- */
-#if defined(CONFIG_DEBUG_FS)
-static int r100_debugfs_rbbm_info(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct radeon_device *rdev = dev->dev_private;
-   uint32_t reg, value;
-   unsigned i;
-
-   seq_printf(m, "RBBM_STATUS 0x%08x\n", RREG32(RADEON_RBBM_STATUS));
-   seq_printf(m, "RBBM_CMDFIFO_STAT 0x%08x\n", RREG32(0xE7C));
-   seq_printf(m, "CP_STAT 0x%08x\n", RREG32(RADEON_CP_STAT));
-   for (i = 0; i < 64; i++) {
-   WREG32(RADEON_RBBM_CMDFIFO_ADDR, i | 0x100);
-   reg = (RREG32(RADEON_RBBM_CMDFIFO_DATA) - 1) >> 2;
-   WREG32(RADEON_RBBM_CMDFIFO_ADDR, i);
-   value = RREG32(RADEON_RBBM_CMDFIFO_DATA);
-   seq_printf(m, "[0x%03X] 0x%04X=0x%08X\n", i, reg, value);
-   }
-   return 0;
-}
-
-static int r100_debugfs_cp_ring_info(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct radeon_device *rdev = dev->dev_private;
-   struct radeon_ring *ring = &rdev->ring[RADEON_RING_TYPE_GFX_INDEX];
-   uint32_t rdp, wdp;
-   unsigned count, i, j;
-
-   radeon_ring_free_size(rdev, ring);
-   rdp = RREG32(RADEON_CP_RB_RPTR);
-   wdp = RREG32(RADEON_CP_RB_WPTR);
-   count = (rdp + ring->ring_size - wdp) & ring->ptr_mask;
-   seq_printf(m, "CP_STAT 0x%08x\n", RREG32(RADEON_CP_STAT));
-   seq_printf(m, "CP_RB_WPTR 0x%08x\n", wdp);
-   seq_printf(m, "CP_RB_RPTR 0x%08x\n", rdp);
-   seq_printf(m, "%u free dwords in ring\n", ring->ring_free_dw);
-   seq_printf(m, "%u dwords in ring\n", count);
-   for (j = 0; j <= count; j++) {
-   i = (rdp + j) & ring->ptr_mask;
-   seq_printf(m, "r[%04d]=0x%08x\n", i, ring->ring[i]);
-   }
-   return 0;
-}
-
-
-static int r100_debugfs_cp_csq_fifo(struct seq_file *m, void *data)
-{
-   struct drm_info_node *node = (struct drm_info_node *) m->private;
-   struct drm_device *dev = node->minor->dev;
-   struct radeon_device *rdev = dev->dev_private;
-   uint32_t csq_stat, csq2_stat, tmp;
-   unsigned r_rptr, r_wptr, ib1_rptr, ib1_wptr, ib2_rptr, ib2_wptr;
-   unsigned i;
-
-   seq_printf(m, "CP_STAT 0x%08x\n", RREG32(RADEON_CP_STAT));
-   seq_printf(m, "CP_CSQ_MODE 0x%08x\n", RREG32(RADEON_CP_CSQ_MODE));
-   csq_stat = RREG32(RADEON_CP_CSQ_STAT);
-   csq2_stat = RREG32(RADEON_CP_CSQ2_STAT);
-   r_rptr = (csq_stat >> 0) & 0x3ff;
-   r_wptr = (csq_stat >> 10) & 0x3ff;
-   ib1_rptr = (csq_stat >> 20) & 0x3ff;
-   ib1_wptr = (csq2_stat >> 0) & 0x3ff;
-   ib2_rptr = (csq2_stat >> 10) & 0x3ff;
-   ib2_wptr = (csq2_stat >> 20) & 0x3ff;
-   seq_printf(m, "CP_CSQ_STAT 0x%08x\n", csq_stat);
-   seq_printf(m, "CP_CSQ2_STAT 0x%08x\n", csq2_stat);
-   seq_printf(m, "Ring rptr %u\n", r_rptr);
-   seq_printf(m, "Ring wptr %u\n", r_wptr);
-   seq_printf(m, "Indirect1 rptr %u\n", ib1_rptr);
-   seq_printf(m, "Indirect1 wptr %u\n", ib1_wptr);
-   seq_printf(m, "Indirect2 rptr %u\n", ib2_rptr);
-   seq_printf(m, "Indirect2 wptr %u\n", ib2_wptr);
-   /* FIXME: 0, 128, 640 depends on fifo setup see cp_init_kms
-* 128 = indirect1_start * 8 & 640 = indirect2_start * 8 */
-   seq_printf(m, "Ring fifo:\n");
-   fo