[Intel-gfx] [PATCH] Add i915 register dumping debugfs file

Ben Gamari bgamari.foss at gmail.com
Thu Jun 11 05:06:14 CEST 2009


On Thu, Jun 11, 2009 at 09:10:04AM +0800, yakui_zhao wrote:
> On Thu, 2009-06-11 at 06:14 +0800, Ben Gamari wrote:
> Hi, Ben
>     thanks for your effort.
>     In fact the intel_reg_dump tool under the intel
> driver( src/reg_dumper/intel_reg_dump) still can be used in KMS mode.
> Is that enough for you?
Wow, I never noticed that before. Man, I'm an idiot. Luckily the patch
didn't take me too long.
> 
>     And I have three questions about this patch:
>     a. there is no register definition in some register ranges. And it
> is unnecessary to dump it. Even when there exists the register
> definitions, it is meaningless for some platforms.(For example: LVDS
> port for non-mobile platform)
Yeah, this is probably a shortcoming but I'm not sure it's practical to
work around it without introducing a large amount of logic into the
kernel. I'm operating under the assumption that reading reserved or
otherwise undefined registers won't crash the processor. So far this
assumption seems to hold true. Ultimately the primary application for
this patch would probably be to do a register dump on an end user
machine where intel_reg_dumper is not installed (it doesn't appear to be
present on my Ubuntu machine).

>     b. In this patch the reg index/value is exposed. I don't know
> whether it is appropriate for intel_gpu_tool
I'm not entirely sure I understand the question. What exactly might be
problematic here?

>     c. the memory allocation. In this patch it will dump more than 64K.
> Then the memory buffer related with seq_file will be freed/allocated
> several times.  And the function of i915_register_info is also called
> several times.
Yes, quite true. However, being debugging code, I'm not too concerned.
As long as it the code reliably works, I'm happy.

By the way, shouldn't intel_reg_dump be moved to intel_gpu_tools
(especially if this patch goes in)?

Thanks,

- Ben




More information about the Intel-gfx mailing list