On Tue, 2009-06-09 at 18:46 -0700, Jesse Barnes wrote: > On Wed, 10 Jun 2009 09:06:47 +0800 > yakui_zhao <yakui.z...@intel.com> wrote: > > > On Wed, 2009-06-10 at 06:35 +0800, Jesse Barnes wrote: > > > On Tue, 09 Jun 2009 15:16:53 -0700 > > > Eric Anholt <e...@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... > > 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...
At this point, bgamari's patch for debugfs register dumping looks good to me. -- Eric Anholt e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel