On Wed, 10 Jun 2009 09:06:47 +0800 yakui_zhao <[email protected]> wrote:
> On Wed, 2009-06-10 at 06:35 +0800, Jesse Barnes wrote: > > On Tue, 09 Jun 2009 15:16:53 -0700 > > Eric Anholt <[email protected]> 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... > It seems that this is a good point. > In this patch only the registers related with modesetting are dumped. > > Is it ok that the whole mmio range is divided into several parts? > a. memory interface, instruction and interrupt control registers > b. 3d debug registers > c. modeset registers(display,pipe, etc). Yeah that would be ok too... Jesse ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
