[Intel-gfx] [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
Jesse Barnes
jbarnes at virtuousgeek.org
Wed Jun 10 00:35:59 CEST 2009
On Tue, 09 Jun 2009 15:16:53 -0700
Eric Anholt <eric at anholt.net> wrote:
> On Mon, 2009-06-08 at 08:52 +0800, yakui_zhao wrote:
> > On Fri, 2009-06-05 at 19:11 +0800, Eric Anholt wrote:
> > > On Fri, 2009-06-05 at 15:45 +0800, yakui_zhao wrote:
> > > > It is useful to get the register snapshot.
> > > > Add a debugfs I/F named "i915_reg" to dump the I915 register
> > > > snapshot. And this is created under the dri/0/ of debugfs.
> > > > The output format is similar to what we have done in UMS mode.
> > >
> > > I don't think that all the decode and formatting of these
> > > registers should be in the kernel. Every time I've had to mess
> > > with register decode stuff for investigation, I've needed to
> > > extend the decode. Instead, we should expose the raw register
> > > values and make intel_reg_dumper in intel-gpu-tools that does the
> > > decode of actual meaning.
> > Sometimes we can see the register snapshot without using the
> > intel-gpu-tools. For example: in UMS mode we often get the register
> > snapshot several times in starting X.
> >
> > It will be good that we expose the raw register values and then
> > they are parsed by intel-gpu-tools if we need to extend the decode.
> >
> > How about adding two debugfs I/F? One is to dump the raw register
> > snapshot(without decode and format). Another is what I have done in
> > the patch.
>
> No, I won't pull something that puts the decode in the kernel without
> a really good argument. Expose the register names and values.
>
Yakui, have you experimented with just dumping the whole mmio range?
If that works ok we could just make intel-gpu-tools programs to
interpret the data in a chipset specific way...
Jesse
More information about the Intel-gfx
mailing list