Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
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
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
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. -- 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
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
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... 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
On Wed, 2009-06-10 at 06:16 +0800, Eric Anholt 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. Ok. If so, I will only expose the register names and values in the debugfs I/F. And then the data will be interpreted by intel-gpu-tool. Thanks. -- 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
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
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). 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
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. What format should be used when dumping the raw register values? register name: register value Thanks. -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
yakui_zhao wrote: 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. Why not just expose the raw register values in debugfs, and copy them to one side for intel-gpu-tools to deal with whenever you get to an interesting point? Should be as simple (in userspace) as cp /sys/kernel/debug/dri/0/registers ~/dump at interesting points. -- Simon Farnsworth -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
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. Signed-off-by: Zhao Yakui yakui.z...@intel.com --- drivers/gpu/drm/i915/Makefile |1 drivers/gpu/drm/i915/i915_dma.c |6 drivers/gpu/drm/i915/i915_drv.h |3 drivers/gpu/drm/i915/i915_reg.h | 87 ++ drivers/gpu/drm/i915/i915_reg_debugfs.c | 1114 5 files changed, 1208 insertions(+), 3 deletions(-) Index: linux-2.6/drivers/gpu/drm/i915/Makefile === --- linux-2.6.orig/drivers/gpu/drm/i915/Makefile2009-06-05 11:42:12.0 +0800 +++ linux-2.6/drivers/gpu/drm/i915/Makefile 2009-06-05 11:42:43.0 +0800 @@ -8,6 +8,7 @@ i915_gem.o \ i915_gem_debug.o \ i915_gem_debugfs.o \ + i915_reg_debugfs.o \ i915_gem_tiling.o \ intel_display.o \ intel_crt.o \ Index: linux-2.6/drivers/gpu/drm/i915/i915_drv.h === --- linux-2.6.orig/drivers/gpu/drm/i915/i915_drv.h 2009-06-05 11:42:12.0 +0800 +++ linux-2.6/drivers/gpu/drm/i915/i915_drv.h 2009-06-05 11:42:43.0 +0800 @@ -689,7 +689,8 @@ /* modesetting */ extern void intel_modeset_init(struct drm_device *dev); extern void intel_modeset_cleanup(struct drm_device *dev); - +extern void i915_reg_debugfs_init(struct drm_device *dev); +extern void i915_reg_debugfs_cleanup(struct drm_device *dev); /** * Lock test for when it's just for synchronization of ring access. * Index: linux-2.6/drivers/gpu/drm/i915/i915_reg.h === --- linux-2.6.orig/drivers/gpu/drm/i915/i915_reg.h 2009-06-05 11:42:12.0 +0800 +++ linux-2.6/drivers/gpu/drm/i915/i915_reg.h 2009-06-05 11:42:43.0 +0800 @@ -202,7 +202,9 @@ #define I965_FENCE_TILING_Y_SHIFT1 #define I965_FENCE_REG_VALID (10) #define I965_FENCE_MAX_PITCH_VAL 0x0400 +#define I965_FENCE_Y_MAJOR0x0002 +#define PGETBL_CTL 0x2020 /* * Instruction and interrupt control regs */ @@ -263,7 +265,9 @@ #define FW_BLC 0x020d8 #define FW_BLC_SELF0x020e0 /* 915+ only */ #define MI_ARB_STATE 0x020e4 /* 915+ only */ +#define MI_RDRET_STATE 0x020fc #define CACHE_MODE_0 0x02120 /* 915+ only */ +#define MI_MODE 0x0209c #define CM0_MASK_SHIFT 16 #define CM0_IZ_OPT_DISABLE (16) #define CM0_ZR_OPT_DISABLE (15) @@ -272,8 +276,7 @@ #define CM0_DEPTH_WRITE_DISABLE (11) #define CM0_RC_OP_FLUSH_DISABLE (10) #define GFX_FLSH_CNTL 0x02170 /* 915+ only */ - - +#define ECOSKPD0x021d0 /* * Framebuffer compression (915+ only) */ @@ -304,6 +307,7 @@ #define FBC_CTL_PLANEA (00) #define FBC_CTL_PLANEB (10) #define FBC_FENCE_OFF 0x0321b +#define FBC_MOD_NUM0x03220 #define FBC_LL_SIZE(1536) @@ -529,6 +533,41 @@ #define CG_2D_DIS 0x6200 #define DPCUNIT_CLOCK_GATE_DISABLE (1 24) #define CG_3D_DIS 0x6204 +#define RENCLK_GATE_D2 0x6208 + +#define DPUNIT_B_CLOCK_GATE_DISABLE(1 30) /* 965 */ +#define VSUNIT_CLOCK_GATE_DISABLE (1 29) /* 965 */ +#define VRHUNIT_CLOCK_GATE_DISABLE (1 28) /* 965 */ +#define VRDUNIT_CLOCK_GATE_DISABLE (1 27) /* 965 */ +#define AUDUNIT_CLOCK_GATE_DISABLE (1 26) /* 965 */ +#define DPUNIT_A_CLOCK_GATE_DISABLE(1 25) /* 965 */ +#define DPCUNIT_CLOCK_GATE_DISABLE (1 24) /* 965 */ +#define TVRUNIT_CLOCK_GATE_DISABLE (1 23) /* 915-945 */ +#define TVCUNIT_CLOCK_GATE_DISABLE (1 22) /* 915-945 */ +#define TVFUNIT_CLOCK_GATE_DISABLE (1 21) /* 915-945 */ +#define TVEUNIT_CLOCK_GATE_DISABLE (1 20) /* 915-945 */ +#define DVSUNIT_CLOCK_GATE_DISABLE (1 19) /* 915-945 */ +#define DSSUNIT_CLOCK_GATE_DISABLE (1 18) /* 915-945 */ +#define DDBUNIT_CLOCK_GATE_DISABLE (1 17) /* 915-945 */ +#define DPRUNIT_CLOCK_GATE_DISABLE (1 16) /* 915-945 */ +#define DPFUNIT_CLOCK_GATE_DISABLE (1 15) /* 915-945 */ +#define DPBMUNIT_CLOCK_GATE_DISABLE(1 14) /* 915-945 */ +#define DPLSUNIT_CLOCK_GATE_DISABLE(1 13) /* 915-945 */ +#define DPLUNIT_CLOCK_GATE_DISABLE (1 12) /* 915-945 */ +#define DPOUNIT_CLOCK_GATE_DISABLE (1 11) +#define DPBUNIT_CLOCK_GATE_DISABLE (1 10) +#define DCUNIT_CLOCK_GATE_DISABLE (1 9) +#define DPUNIT_CLOCK_GATE_DISABLE (1 8) +#define VRUNIT_CLOCK_GATE_DISABLE (1 7) /* 915+: reserved */ +#define OVHUNIT_CLOCK_GATE_DISABLE
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
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. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
