[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
Christian König
deathsimple at vodafone.de
Thu Apr 26 02:11:12 PDT 2012
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.
More information about the dri-devel
mailing list