Re: [Intel-gfx] [PATCH 0/2] Haswell intel_audio_dump support
Hi all, Any comments about this version patch series? I wonder if it's helpful for you...:) Any suggestions are highly appreciated. Thanks --xingchao -Original Message- From: Wang, Xingchao Sent: Tuesday, August 07, 2012 4:53 PM To: intel-gfx@lists.freedesktop.org Cc: dan...@ffwll.ch; Fu, Michael; Wu, Fengguang; zhen...@linux.intel.com; Wang, Xingchao Subject: [PATCH 0/2] Haswell intel_audio_dump support This patch enabled intel_audio_dump to support Haswell platform. Haswell has some registers differences comprared with previous platforms. Changes since V1: - fix compile warnings - remove HBR bits show, it doesnot exist under Haswell Wang Xingchao (2): intel_audio_dump: fix wrong port definition intel_audio_dump: add Haswell audio dump support tools/intel_audio_dump.c | 588 +- 1 file changed, 585 insertions(+), 3 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 1/2] intel_audio_dump: fix wrong port definition
Thanks for catching this!
Acked-by: Fengguang Wu fengguang...@intel.com
On Tue, Aug 07, 2012 at 04:52:49PM +0800, Wang Xingchao wrote:
There're three Ports B/C/D used for selection by each transcoder A/B/C.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
tools/intel_audio_dump.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 077e096..8a0f6ee 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -126,9 +126,9 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = no port,
[1] = Digital Port B,
- [2] = Digital Port B,
- [3] = Digital Port B,
- [4] = Digital Port B,
+ [2] = Digital Port C,
+ [3] = Digital Port D,
+ [4] = reserved,
[5] = reserved,
[6] = reserved,
[7] = reserved,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 2/2] intel_audio_dump: add Haswell audio dump support
Xingchao, Have you tested the patch in haswell as well as in older hardwares? In general it would be better if you have run this tool for some time on several hardwares -- that's the best way to smooth out possible bugs. +/*Haswell registers*/ Please fix the style to (ditto for lots of other comments) +/* Haswell registers */ Thanks, Fengguang ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 2/2] intel_audio_dump: add Haswell audio dump support
Hi Fengguang, -Original Message- From: Wu, Fengguang Sent: Wednesday, August 15, 2012 4:01 PM To: Wang, Xingchao Cc: intel-gfx@lists.freedesktop.org; dan...@ffwll.ch; Fu, Michael; zhen...@linux.intel.com Subject: Re: [PATCH V2 2/2] intel_audio_dump: add Haswell audio dump support Xingchao, Have you tested the patch in haswell as well as in older hardwares? I tested this patch on Haswell platform platform several times. It helped me much during debug. And this patch has no impact for older hardwares(such as ivybridge), as it only works for Haswell. In general it would be better if you have run this tool for some time on several hardwares -- that's the best way to smooth out possible bugs. +/*Haswell registers*/ Please fix the style to (ditto for lots of other comments) +/* Haswell registers */ Thanks, will clean up that. --xingchao ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] intel_audio_dump: add Haswell audio dump support
Add Haswell audio registers definition and dump support.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
tools/intel_audio_dump.c | 584 ++
1 file changed, 584 insertions(+)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 8a0f6ee..8b9da30 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -94,6 +94,11 @@ static const char *dip_port[] = {
[3] = Digital Port D,
};
+static const char *dip_type[] = {
+[0] = Audio DIP Disabled,
+[1] = Audio DIP Enabled,
+};
+
static const char *dip_index[] = {
[0] = Audio DIP,
[1] = ACP DIP,
@@ -134,6 +139,17 @@ static const char *trans_to_port_sel[] = {
[7] = reserved,
};
+static const char *ddi_mode[] = {
+ [0] = HDMI mode,
+ [1] = DVI mode,
+ [2] = DP SST mode,
+ [3] = DP MST mode,
+ [4] = DP FDI mode,
+ [5] = reserved,
+ [6] = reserved,
+ [7] = reserved,
+};
+
static const char *transcoder_select[] = {
[0] = Transcoder A,
[1] = Transcoder B,
@@ -1354,6 +1370,569 @@ static void dump_cpt(void)
}
+#undef AUD_CONFIG_A
+#undef AUD_MISC_CTRL_A
+#undef AUD_VID_DID
+#undef AUD_RID
+#undef AUD_CTS_ENABLE_A
+#undef AUD_PWRST
+#undef AUD_HDMIW_HDMIEDID_A
+#undef AUD_HDMIW_INFOFR_A
+#undef AUD_PORT_EN_HD_CFG
+#undef AUD_OUT_DIG_CNVT_A
+#undef AUD_OUT_STR_DESC_A
+#undef AUD_OUT_CH_STR
+#undef AUD_PINW_CONNLNG_LIST
+#undef AUD_CNTL_ST_A
+#undef AUD_HDMIW_STATUS
+#undef AUD_CONFIG_B
+#undef AUD_MISC_CTRL_B
+#undef AUD_CTS_ENABLE_B
+#undef AUD_HDMIW_HDMIEDID_B
+#undef AUD_HDMIW_INFOFR_B
+#undef AUD_OUT_DIG_CNVT_B
+#undef AUD_OUT_STR_DESC_B
+#undef AUD_CNTL_ST_B
+#undef AUD_CONFIG_C
+#undef AUD_MISC_CTRL_C
+#undef AUD_CTS_ENABLE_C
+#undef AUD_HDMIW_HDMIEDID_C
+#undef AUD_HDMIW_INFOFR_C
+#undef AUD_OUT_DIG_CNVT_C
+#undef AUD_OUT_STR_DESC_C
+
+#undef VIDEO_DIP_CTL_A
+#undef VIDEO_DIP_CTL_B
+#undef VIDEO_DIP_CTL_C
+#undef VIDEO_DIP_CTL_D
+#undef VIDEO_DIP_DATA
+
+/*
+ * Haswell registers
+ */
+
+/* DisplayPort Transport Control */
+#define DP_TP_CTL_A0x64040
+#define DP_TP_CTL_B0x64140
+#define DP_TP_CTL_C0x64240
+#define DP_TP_CTL_D0x64340
+#define DP_TP_CTL_E0x64440
+
+/* DisplayPort Transport Status */
+#define DP_TP_ST_A 0x64044
+#define DP_TP_ST_B 0x64144
+#define DP_TP_ST_C 0x64244
+#define DP_TP_ST_D 0x64344
+#define DP_TP_ST_E 0x6
+
+/* Transcoder configuration */
+#define TRANS_CONF_A 0xF0008
+#define TRANS_CONF_B 0xF1008
+#define TRANS_CONF_C 0xF2008
+
+/* DDI Buffer Control */
+#define DDI_BUF_CTL_A0x64000
+#define DDI_BUF_CTL_B0x64100
+#define DDI_BUF_CTL_C0x64200
+#define DDI_BUF_CTL_D0x64300
+#define DDI_BUF_CTL_E0x64400
+
+/* DDI Buffer Translation */
+#define DDI_BUF_TRANS_A0x64e00
+#define DDI_BUF_TRANS_B0x64e60
+#define DDI_BUF_TRANS_C0x64ec0
+#define DDI_BUF_TRANS_D0x64f20
+#define DDI_BUF_TRANS_E0x64f80
+
+/* DDI Aux Channel */
+#define DDI_AUX_CHANNEL_CTRL 0x64010
+#define DDI_AUX_DATA 0x64014
+#define DDI_AUX_TST0x64028
+
+/* DDI CRC Control */
+#define DDI_CRC_CTL_A 0x64050
+#define DDI_CRC_CTL_B 0x64150
+#define DDI_CRC_CTL_C 0x64250
+#define DDI_CRC_CTL_D 0x64350
+#define DDI_CRC_CTL_E 0x64450
+
+/* Pipe DDI Function Control */
+#define PIPE_DDI_FUNC_CTL_A 0x60400
+#define PIPE_DDI_FUNC_CTL_B 0x61400
+#define PIPE_DDI_FUNC_CTL_C 0x62400
+#define PIPE_DDI_FUNC_CTL_EDP 0x6F400
+
+/* Pipe Configuration */
+#define PIPE_CONF_A0x70008
+#define PIPE_CONF_B0x71008
+#define PIPE_CONF_C0x72008
+#define PIPE_CONF_EDP 0x7F008
+
+/* Audio registers */
+#define AUD_CONFIG_A 0x65000
+#define AUD_MISC_CTRL_A 0x65010
+#define AUD_VID_DID 0x65020
+#define AUD_RID 0x65024
+#define AUD_CTS_ENABLE_A 0x65028
+#define AUD_PWRST 0x6504C
+#define AUD_HDMIW_HDMIEDID_A 0x65050
+#define AUD_HDMIW_INFOFR_A0x65054
+#define AUD_PORT_EN_HD_CFG0x6507C
+#define AUD_OUT_DIG_CNVT_A0x65080
+#define AUD_OUT_STR_DESC_A0x65084
+#define AUD_OUT_CHAN_MAP 0x65088
+#define AUD_PINW_CONNLNG_LIST_A 0x650A8
+#define AUD_PINW_CONNLNG_LIST_B 0x651A8
+#define AUD_PINW_CONNLNG_LIST_C 0x652A8
+#define AUD_PIPE_CONN_SEL_CTRL 0x650AC
+#define AUD_PIN_ELD_CP_VLD0x650C0
+#define AUD_HDMIW_STATUS 0x650D4
+#define AUD_CONFIG_B 0x65100
+#define AUD_MISC_CTRL_B 0x65110
+#define AUD_CTS_ENABLE_B 0x65128
+#define AUD_HDMIW_HDMIEDID_B 0x65150
+#define AUD_HDMIW_INFOFR_B0x65154
+#define AUD_OUT_DIG_CNVT_B0x65180
+#define AUD_OUT_STR_DESC_B0x65184
+#define AUD_CONFIG_C 0x65200
+#define AUD_MISC_CTRL_C 0x65210
+#define AUD_CTS_ENABLE_C 0x65228
[Intel-gfx] [PATCH v3 1/2] intel_audio_dump: fix wrong port definition
there're three Ports B/C/D used for selection by each transcoder A/B/C.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
tools/intel_audio_dump.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 077e096..8a0f6ee 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -126,9 +126,9 @@ static const char *video_dip_trans[] = {
static const char *trans_to_port_sel[] = {
[0] = no port,
[1] = Digital Port B,
- [2] = Digital Port B,
- [3] = Digital Port B,
- [4] = Digital Port B,
+ [2] = Digital Port C,
+ [3] = Digital Port D,
+ [4] = reserved,
[5] = reserved,
[6] = reserved,
[7] = reserved,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/2] Haswell intel_audio_dump support
This patch enabled intel_audio_dump to support Haswell platform. Haswell has some registers differences comprared with previous platforms. Changes since V1: - fix compile warnings - remove HBR bits show, it doesnot exist under Haswell Changes since V2: - fix comments style This is output of intel_audio_dump under one Haswell machine: DDI_BUF_CTL_A 0x0080 DDI Buffer Controler A DDI_BUF_CTL_B 0x DDI Buffer Controler B DDI_BUF_CTL_C 0x0080 DDI Buffer Controler C DDI_BUF_CTL_D 0x DDI Buffer Controler D DDI_BUF_CTL_E 0x8002 DDI Buffer Controler E PIPE_CONF_A 0xc000 PIPE Configuration A PIPE_CONF_B 0x PIPE Configuration B PIPE_CONF_C 0x PIPE Configuration C PIPE_CONF_EDP 0x PIPE Configuration EDP PIPE_DDI_FUNC_CTL_A 0xc4034002 PIPE DDI Function Control A PIPE_DDI_FUNC_CTL_B 0xa0035000 PIPE DDI Function Control B PIPE_DDI_FUNC_CTL_C 0x0003 PIPE DDI Function Control C PIPE_DDI_FUNC_CTL_EDP 0x0003 PIPE DDI Function Control EDP DP_TP_CTL_A 0x DisplayPort Transport A Control DP_TP_CTL_B 0x DisplayPort Transport B Control DP_TP_CTL_C 0x DisplayPort Transport C Control DP_TP_CTL_D 0x DisplayPort Transport D Control DP_TP_CTL_E 0x80048300 DisplayPort Transport E Control DP_TP_ST_A0x DisplayPort Transport A Status DP_TP_ST_B0x DisplayPort Transport B Status DP_TP_ST_C0x DisplayPort Transport C Status DP_TP_ST_D0x DisplayPort Transport D Status DP_TP_ST_E0x1000 DisplayPort Transport E Status TRANS_CONF_A 0xc000 Transcoder A Configuration TRANS_CONF_B 0xc000 Transcoder B Configuration TRANS_CONF_C 0xc000 Transcoder C Configuration AUD_CONFIG_A 0x0070fa60 Audio Configuration - Transcoder A AUD_CONFIG_B 0x0070fa60 Audio Configuration - Transcoder B AUD_CONFIG_C 0x0070fa60 Audio Configuration - Transcoder C AUD_MISC_CTRL_A 0x0044 Audio MISC Control for Transcoder A AUD_MISC_CTRL_B 0x0044 Audio MISC Control for Transcoder B AUD_MISC_CTRL_C 0x0044 Audio MISC Control for Transcoder C AUD_VID_DID 0x80862807 Audio Vendor ID / Device ID AUD_RID 0x0010 Audio Revision ID AUD_CTS_ENABLE_A 0x Audio CTS Programming Enable - Transcoder A AUD_CTS_ENABLE_B 0x Audio CTS Programming Enable - Transcoder B AUD_CTS_ENABLE_C 0x Audio CTS Programming Enable - Transcoder C AUD_PWRST 0x0fff Audio Power State (Function Group, Convertor, Pin Widget) AUD_HDMIW_HDMIEDID_A 0x HDMI Data EDID Block - Transcoder A AUD_HDMIW_HDMIEDID_B 0x4c4c4544 HDMI Data EDID Block - Transcoder B AUD_HDMIW_HDMIEDID_C 0x HDMI Data EDID Block - Transcoder C AUD_HDMIW_INFOFR_A0x Audio Widget Data Island Packet - Transcoder A AUD_HDMIW_INFOFR_B0x Audio Widget Data Island Packet - Transcoder B AUD_HDMIW_INFOFR_C0x Audio Widget Data Island Packet - Transcoder C AUD_PORT_EN_HD_CFG0x00770207 Audio Pipe and Convert Configs AUD_OUT_DIG_CNVT_A0x0280 Audio Digital Converter - Conv A AUD_OUT_DIG_CNVT_B0x00200280 Audio Digital Converter - Conv B AUD_OUT_DIG_CNVT_C0x0280 Audio Digital Converter - Conv C AUD_OUT_CHAN_MAP 0x0077f777 Audio Output Channel Mapping AUD_OUT_STR_DESC_A0x0005 Audio Stream Descriptor Format - Conv A AUD_OUT_STR_DESC_B0x00014011 Audio Stream Descriptor Format - Conv B AUD_OUT_STR_DESC_C0x0005 Audio Stream Descriptor Format - Conv C AUD_PINW_CONNLNG_LIST_A 0x0001 Audio Connection List entry and Length - Transcoder A AUD_PINW_CONNLNG_LIST_B 0x0301 Audio Connection List entry and Length - Transcoder B AUD_PINW_CONNLNG_LIST_C 0x0001 Audio Connection List entry and Length - Transcoder C AUD_PIPE_CONN_SEL_CTRL 0x00030003 Audio Pipe Connection Select Control AUD_DIP_ELD_CTRL_ST_A 0x54c9 Audio DIP and ELD control state - Transcoder A AUD_DIP_ELD_CTRL_ST_B 0x002354c9 Audio DIP and ELD control state - Transcoder B AUD_DIP_ELD_CTRL_ST_C 0x54c9 Audio DIP and ELD control state - Transcoder C AUD_PIN_ELD_CP_VLD0x0555 audio pin eld valid status AUD_HDMIW_STATUS 0x Audio HDMI FIFO Status Details: AUD_VID_DID vendor id 0x8086 AUD_VID_DID device id 0x2807 AUD_RID Major_Revision 0x1 AUD_RID Minor_Revision 0x0 AUD_RID Revision_Id 0x0 AUD_RID Stepping_Id 0x0 Audio DIP and ELD control state for TranscoderA Audio DIP port select [0x0] Reserved
[Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to entre rc6 with semaphores enabled.
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to work.
Reference[1]:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]:
http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky b...@bwidawsk.net
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d64dffb..cf10a1d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2482,17 +2482,10 @@ static void gen6_enable_rps(struct drm_device *dev)
dev_priv-rps.max_delay 24 |
dev_priv-rps.min_delay 16);
- if (IS_HASWELL(dev)) {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
- I915_WRITE(GEN6_RP_UP_EI, 66000);
- I915_WRITE(GEN6_RP_DOWN_EI, 35);
- } else {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 1);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100);
- I915_WRITE(GEN6_RP_UP_EI, 10);
- I915_WRITE(GEN6_RP_DOWN_EI, 500);
- }
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 35);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/2] Haswell intel_audio_dump support
On Wed, Aug 15, 2012 at 04:13:36PM +0800, Wang Xingchao wrote: This patch enabled intel_audio_dump to support Haswell platform. Haswell has some registers differences comprared with previous platforms. Changes since V1: - fix compile warnings - remove HBR bits show, it doesnot exist under Haswell Changes since V2: - fix comments style Applied both to i-g-t. Note that there's some trailing whitespace in patch 2, but I don't care _that_ much ;-) -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Cleanup instdone state
On Tue, 14 Aug 2012 14:35:13 -0700, Ben Widawsky b...@bwidawsk.net wrote: Clear the cached instdone state to match what we expect from hardware and prevent us from comparing stale values. Actually, clearing the state is not the same as setting idle state. There would be a known state of idle (ie. all units are done), but since it differs for every platform, we can just set 0, and let the hangcheck progress as normal. By putting the clear into add_request we are essentially initializing the cached instdone to a known state before we start the hangcheck timer. v2: clear instdone in more place (Chris) Rewrote the commit message References: https://bugs.freedesktop.org/show_bug.cgi?id=52429 Tested-by: Guang A Yang guang.a.y...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net So if hangcheck is already running and we add a new request, we still clear the stale state. This means that we may take an extra tick after a new request for hangcheck to raise an error. Not a big deal and it keeps the code clean. Though possibly deserves a comment? Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915/contexts: Switch to default on resume
On Tue, 14 Aug 2012 14:35:15 -0700, Ben Widawsky b...@bwidawsk.net wrote: In order to make the HW state CCID match with what we think it should be, we must order a switch to the default context. The really sad thing here is that the switch can potentially fail, and as such we have to assume contexts no longer work. There is likely room for improvement but until we actually start seeing the case occur, I think it should be fine. This was accidentally left this out of the first series, noticed by Chris Wilson. However that do_switch() is a no-op as it spots that the ring-last_ctx_obj is the DEFAULT_CONTEXT (saved across sr) and we exit early. The only clean way I could see was to extract the actual set_switch portion of do_switch() (i.e. discard the initial checks and pre-/post-op pinning). Which brings you nicely into the next few patches... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] black screen if sna TearFree
I'm using a Dell XPS 13 laptop on Gentoo and if I use: Option AccelMethod sna Option TearFree true my video tearing problem disappears, but if I close my laptop lid for a few minutes, it comes back up with a black screen, although I can get my session back if I switch to VT1 and then back to VT7. I can't find anything in the logs. I've tried xf86-video-intel-2.20.3 as well as the latest from git. The problem doesn't occur without the above two directives. Does anyone know how to diagnose or fix this? - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
Am Mittwoch, den 15.08.2012, 10:41 +0200 schrieb Daniel Vetter:
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to entre rc6 with semaphores enabled.
s,entre,enter,
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
Never heard that Toshiba name.
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to work.
Reference[1]:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]:
http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky b...@bwidawsk.net
Did James already confirm, that this fixes his problem?
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d64dffb..cf10a1d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2482,17 +2482,10 @@ static void gen6_enable_rps(struct drm_device *dev)
dev_priv-rps.max_delay 24 |
dev_priv-rps.min_delay 16);
- if (IS_HASWELL(dev)) {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
- I915_WRITE(GEN6_RP_UP_EI, 66000);
- I915_WRITE(GEN6_RP_DOWN_EI, 35);
- } else {
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 1);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 100);
- I915_WRITE(GEN6_RP_UP_EI, 10);
- I915_WRITE(GEN6_RP_DOWN_EI, 500);
- }
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 35);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/fb-helper: don't clobber output routing in setup_crtcs
On Sun, Aug 12, 2012 at 06:15:48PM +0200, Daniel Vetter wrote: Yet again the too close relationship between the fb helper and the crtc helper code strikes. This time around the fb helper resets all encoder-crtc pointers to NULL before starting to set up it's own mode. Which is total bullocks, because this will clobber the existing output routing, which the new drm/i915 code depends upon to be absolutely correct. The crtc helper itself doesn't really care about that, since it disables unused encoders in a rather roundabout way anyway. Two places call drm_setup_crts: - For the initial fb config. I've auditted all current drivers, and they all allocate their encoders with kzalloc. So there's no need to clear encoder-crtc once more. - When processing hotplug events while showing the fb console. This one is a bit more tricky, but both the crtc helper code and the new drm/i915 modeset code disable encoders if their crtc is changed and that encoder isn't part of the new config. Also, both disable any disconnected outputs, too. Which only leaves encoders that are on, connected, but for some odd reason the fb helper code doesn't want to use. That would be a bug in the fb configuration selector, since it tries to light up as many outputs as possible. v2: Kill the now unused encoders variable. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- Hi Dave, This patch here is blocking the modeset-rework series, and I'd like to merge that as soon as possible. You've merged the other two prep patches already for 3.6, but this one here popped up later on in testing. Can you please merge this into drm-next for 3.7 so that I can backmerge it, or smash your maintainer-ack onto it for merging through the intel tree? Merged to drm-intel-next with Dave's irc-ack. Should show up in drm-next in about 2 weeks ... -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] black screen if sna TearFree
I'm using a Dell XPS 13 laptop on Gentoo and if I use: Option AccelMethod sna Option TearFree true my video tearing problem disappears, but if I close my laptop lid for a few minutes, it comes back up with a black screen, although I can get my session back if I switch to VT1 and then back to VT7. I can't find anything in the logs. I've tried xf86-video-intel-2.20.3 as well as the latest from git. The problem doesn't occur without the above two directives. Does anyone know how to diagnose or fix this? - Grant I can prevent this if I issue 'xset -dpms' before closing the laptop lid, but xlockmore automatically re-enables dpms unfortunately. BTW, this does not prevent the problem: DPMS (Energy Star): Standby: 0Suspend: 0Off: 0 DPMS is Enabled Monitor is On It has to be this: DPMS (Energy Star): Standby: 0Suspend: 0Off: 0 DPMS is Disabled I've tried different kernel versions as well as different versions of xf86-video-intel and xorg-server with the same result. - Grant ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915/contexts: Switch to default on resume
On 2012-08-15 02:18, Chris Wilson wrote: On Tue, 14 Aug 2012 14:35:15 -0700, Ben Widawsky b...@bwidawsk.net wrote: In order to make the HW state CCID match with what we think it should be, we must order a switch to the default context. The really sad thing here is that the switch can potentially fail, and as such we have to assume contexts no longer work. There is likely room for improvement but until we actually start seeing the case occur, I think it should be fine. This was accidentally left this out of the first series, noticed by Chris Wilson. However that do_switch() is a no-op as it spots that the ring-last_ctx_obj is the DEFAULT_CONTEXT (saved across sr) and we exit early. The only clean way I could see was to extract the actual set_switch portion of do_switch() (i.e. discard the initial checks and pre-/post-op pinning). Which brings you nicely into the next few patches... -Chris Agreed, I was thinking re-ordering the series would just magically solve all such issues :-) -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't hardcode the number of pipes in the error state dump
From: Damien Lespiau damien.lesp...@intel.com
New-ish devices have 3 pipes, so let's not just hardcode 2 but use the
for_each_pipe() macro and make struct intel_display_error_state is big
enough.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1d24d55..d4cfb31 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7470,7 +7470,7 @@ struct intel_display_error_state {
u32 position;
u32 base;
u32 size;
- } cursor[2];
+ } cursor[I915_MAX_PIPES];
struct intel_pipe_error_state {
u32 conf;
@@ -7482,7 +7482,7 @@ struct intel_display_error_state {
u32 vtotal;
u32 vblank;
u32 vsync;
- } pipe[2];
+ } pipe[I915_MAX_PIPES];
struct intel_plane_error_state {
u32 control;
@@ -7492,7 +7492,7 @@ struct intel_display_error_state {
u32 addr;
u32 surface;
u32 tile_offset;
- } plane[2];
+ } plane[I915_MAX_PIPES];
};
struct intel_display_error_state *
@@ -7506,7 +7506,7 @@ intel_display_capture_error_state(struct drm_device *dev)
if (error == NULL)
return NULL;
- for (i = 0; i 2; i++) {
+ for_each_pipe(i) {
error-cursor[i].control = I915_READ(CURCNTR(i));
error-cursor[i].position = I915_READ(CURPOS(i));
error-cursor[i].base = I915_READ(CURBASE(i));
@@ -7539,9 +7539,10 @@ intel_display_print_error_state(struct seq_file *m,
struct drm_device *dev,
struct intel_display_error_state *error)
{
+ drm_i915_private_t *dev_priv = dev-dev_private;
int i;
- for (i = 0; i 2; i++) {
+ for_each_pipe(i) {
seq_printf(m, Pipe [%d]:\n, i);
seq_printf(m, CONF: %08x\n, error-pipe[i].conf);
seq_printf(m, SRC: %08x\n, error-pipe[i].source);
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/4] drm/i915: Haswell HDMI audio initialization
On Wed, Aug 15, 2012 at 6:27 AM, Wang, Xingchao xingchao.w...@intel.com wrote:
Hi Daniel/Imre,
This revised version changelog:
- add Wait for 1 vertical blank after enable audio output port
- configure pipe related transcoder instead of operate all transcoders
blindly
Thanks for the explanation. I'd have still a couple of questions inlined:
Thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Wednesday, August 15, 2012 11:11 AM
To: dan...@ffwll.ch; imre.d...@gmail.com
Cc: intel-gfx@lists.freedesktop.org; przan...@gmail.com; Wang, Xingchao
Subject: [PATCH v7 3/4] drm/i915: Haswell HDMI audio initialization
Added new haswell_write_eld() to initialize Haswell HDMI audio registers to
generate an unsolicited response to the audio controller driver to indicate
that
the controller sequence should start.
Signed-off-by: Wang Xingchao xingchao.w...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 98
+-
2 files changed, 98 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h index 55aa10e..08f8b65 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4294,6 +4294,7 @@
#define AUD_DIG_CNVT(pipe) _PIPE(pipe, \
HSW_AUD_DIG_CNVT_1, \
HSW_AUD_DIG_CNVT_2)
+#define DIP_PORT_SEL_MASK 0x3
#define HSW_AUD_EDID_DATA_A0x65050
#define HSW_AUD_EDID_DATA_B0x65150
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 70d30fc..aad0a1b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5067,6 +5067,102 @@ static void g4x_write_eld(struct drm_connector
*connector,
I915_WRITE(G4X_AUD_CNTL_ST, i);
}
+static void haswell_write_eld(struct drm_connector *connector,
+ struct drm_crtc *crtc)
+{
+ struct drm_i915_private *dev_priv = connector-dev-dev_private;
+ uint8_t *eld = connector-eld;
+ struct drm_device *dev = crtc-dev;
+ uint32_t eldv;
+ uint32_t i;
+ int len;
+ int pipe = to_intel_crtc(crtc)-pipe;
+ int tmp;
+
+ int hdmiw_hdmiedid = HSW_AUD_EDID_DATA(pipe);
+ int aud_cntl_st = HSW_AUD_DIP_ELD_CTRL(pipe);
+ int aud_config = HSW_AUD_CFG(pipe);
+ int aud_cntrl_st2 = HSW_AUD_PIN_ELD_CP_VLD;
+
+
+ DRM_DEBUG_DRIVER(HDMI: Haswell Audio initialize\n);
+
+ /* Audio output enable */
+ DRM_DEBUG_DRIVER(HDMI audio: enable codec\n);
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= (AUDIO_OUTPUT_ENABLE_A | AUDIO_OUTPUT_ENABLE_B |
AUDIO_OUTPUT_ENABLE_C);
The output bits are also transcoder specific, so why don't we enable
only the required output?
I.e. similarly as you do below tmp |= AUDIO_OUTPUT_ENABLE_A (pipe *
4);. Otherwise
this function will leave also unrelated outputs enabled which is not
that nice power
management-wise.
+ I915_WRITE(aud_cntrl_st2, tmp);
+
+ /* Wait for 1 vertical blank */
+ intel_wait_for_vblank(dev, pipe);
+
+ /* Set ELD valid state */
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: pin eld vld status=0x%8x\n, tmp);
+ tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: eld vld status=0x%8x\n, tmp);
+
+ /* Enable HDMI mode */
+ tmp = I915_READ(aud_config);
+ DRM_DEBUG_DRIVER(HDMI audio: audio conf: 0x%8x\n, tmp);
+ /* clear N_programing_enable and N_value_index */
+ tmp = ~(AUD_CONFIG_N_VALUE_INDEX |
AUD_CONFIG_N_PROG_ENABLE);
+ I915_WRITE(aud_config, tmp);
+
+ DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
+
+ i = I915_READ(aud_cntl_st);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select,
0x1 =
PortB */
+ if (!i) {
+ DRM_DEBUG_DRIVER(Audio directed to unknown port\n);
+ /* operate blindly on all ports */
+ eldv = AUDIO_ELD_VALID_A;
+ eldv |= AUDIO_ELD_VALID_B;
+ eldv |= AUDIO_ELD_VALID_C;
+ } else {
+ DRM_DEBUG_DRIVER(ELD on port %c\n, 'A' + i);
+ eldv = AUDIO_ELD_VALID_A ((i - 1) * 4);
+ }
Again, if we handle the ELD_VALID bits on a transcoder basis, as above
when enabling and
disabling it, why are we doing it here differently, on a port basis?
This should read then just
as above eldv = AUDIO_ELD_VALID_A (pipe * 4);
As a sidenote I guess at the moment due to the bug you mentioned
DIP_PORT_SEL will
always read 0, hence the else branch never runs and we just enable
blindly all valid bits.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH] drm/i915: Don't hardcode the number of pipes in the error state dump
From: Damien Lespiau damien.lesp...@intel.com
New-ish devices have 3 pipes, so let's not just hardcode 2 but use the
for_each_pipe() macro and make struct intel_display_error_state is big
enough.
V2: Also add the number of pipes emitted (Chris Wilson)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1d24d55..28e463e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7470,7 +7470,7 @@ struct intel_display_error_state {
u32 position;
u32 base;
u32 size;
- } cursor[2];
+ } cursor[I915_MAX_PIPES];
struct intel_pipe_error_state {
u32 conf;
@@ -7482,7 +7482,7 @@ struct intel_display_error_state {
u32 vtotal;
u32 vblank;
u32 vsync;
- } pipe[2];
+ } pipe[I915_MAX_PIPES];
struct intel_plane_error_state {
u32 control;
@@ -7492,7 +7492,7 @@ struct intel_display_error_state {
u32 addr;
u32 surface;
u32 tile_offset;
- } plane[2];
+ } plane[I915_MAX_PIPES];
};
struct intel_display_error_state *
@@ -7506,7 +7506,7 @@ intel_display_capture_error_state(struct drm_device *dev)
if (error == NULL)
return NULL;
- for (i = 0; i 2; i++) {
+ for_each_pipe(i) {
error-cursor[i].control = I915_READ(CURCNTR(i));
error-cursor[i].position = I915_READ(CURPOS(i));
error-cursor[i].base = I915_READ(CURBASE(i));
@@ -7539,9 +7539,11 @@ intel_display_print_error_state(struct seq_file *m,
struct drm_device *dev,
struct intel_display_error_state *error)
{
+ drm_i915_private_t *dev_priv = dev-dev_private;
int i;
- for (i = 0; i 2; i++) {
+ seq_printf(m, Num Pipes: %d\n, dev_priv-num_pipe);
+ for_each_pipe(i) {
seq_printf(m, Pipe [%d]:\n, i);
seq_printf(m, CONF: %08x\n, error-pipe[i].conf);
seq_printf(m, SRC: %08x\n, error-pipe[i].source);
--
1.7.7.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't hardcode the number of pipes in the error state dump
On Wed, 15 Aug 2012 19:23:25 +0100, Damien Lespiau damien.lesp...@gmail.com wrote: From: Damien Lespiau damien.lesp...@intel.com New-ish devices have 3 pipes, so let's not just hardcode 2 but use the for_each_pipe() macro and make struct intel_display_error_state is big enough. V2: Also add the number of pipes emitted (Chris Wilson) Signed-off-by: Damien Lespiau damien.lesp...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk I guess next on your list will be adding some of the PCH register states, along with a list of active encoders / connectors etc. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] black screen if sna TearFree
On Wed, 15 Aug 2012 08:09:47 -0700, Grant emailgr...@gmail.com wrote: I'm using a Dell XPS 13 laptop on Gentoo and if I use: Option AccelMethod sna Option TearFree true my video tearing problem disappears, but if I close my laptop lid for a few minutes, it comes back up with a black screen, although I can get my session back if I switch to VT1 and then back to VT7. I can't find anything in the logs. I've tried xf86-video-intel-2.20.3 as well as the latest from git. The problem doesn't occur without the above two directives. Does anyone know how to diagnose or fix this? - Grant I can prevent this if I issue 'xset -dpms' before closing the laptop lid, but xlockmore automatically re-enables dpms unfortunately. BTW, this does not prevent the problem: The implication would seem to be that an action during dpms is going wrong. Does a simple 'xset dpms force off; sleep 1; xset dpms force on' trigger the error? If so can you please attach your Xorg.0.log and if you could compile with --enable-debug=full and send me the log reproducing the error that would be very helpful. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Ajdust down threshold in intel_pm.
On Mon, Jul 16, 2012 at 12:50 PM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jul 04, 2012 at 09:52:11AM +0200, Daniel Vetter wrote: On Tue, Jul 03, 2012 at 02:16:42PM -0700, Stéphane Marchesin wrote: The up and down thresholds are very asymetric, so it is possible to have a case where a spike of rendering increases the GPU clock to the max (because the up threshold is low) and then a simple blinking cursor is enough to keep the clock at the maximum speed forever (because the down threshold is high). Lowering the down threshold allows the GPU clock to go back down even when there is a blinking cursor on the screen. Signed-off-by: Stéphane Marchesin marc...@chromium.org I've just merged Eugeni's hsw rc6 patches - those contain newly tuning variables. Can you maybe try out whether these would have the same effect? I'd prefer to simple enable these, presuming that the hw guys we've got them from did some decent tuning ... Ping. 3.6 merge window is approach fast and I think I'd be good to get this in ... Or something similar, based on the hsw ratio between downclock and upclock limit, but with the slightly bigger thresholds used by ivb/snb for upclocks maybe? So now that the dust settled, and that we better understand what's going on, I am sure that those values are not adequate for us (neither the default SNB/IVB, nor the Haswell ones). For the record, here is what we set differently for Chrome OS to solve our issues (we didn't see a performance regression, but we do get a major power consumption reduction for lighter GPU loads like playing a video and that blinking cursor): GEN6_RP_DOWN_TIMEOUT 1 GEN6_RP_UP_THRESHOLD 0x4000 GEN6_RP_DOWN_THRESHOLD 0x4000 Stéphane ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: use hsw rps tuning values everywhere on gen6+
On Wed, Aug 15, 2012 at 03:36:34PM +0100, James Bottomley wrote: On Wed, 2012-08-15 at 16:05 +0200, Paul Menzel wrote: Am Mittwoch, den 15.08.2012, 10:41 +0200 schrieb Daniel Vetter: between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the current setting seems to be highly timing dependent and not robust at all. - The behaviour James reported wrt semaphores seems to be a freak timing thing that only happens on his specific machine, confirming that enabling semaphores shouldn't reduce rc6 residency. Now furthermore the Google ChromeOS guys reported [2] a while ago that at least on some machines a simply a blinking cursor can keep the gpu turbo at the highest frequency. This is because the current rps limits used on snb/ivb are highly asymmetric. On the theory that gpu turbo and rc6 tuning values are related, we've tried whether the much saner looking (since much less asymmetric) rps tuning values used for hsw would also help entering rc6 more robustly. And it seems to work. Reference[1]: http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html Reference[2]: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393 Tested-by: Ben Widawsky b...@bwidawsk.net Did James already confirm, that this fixes his problem? Well, no ... I think no-one cc'd me on anything after the initial bug report, but the patch won't apply to 3.5, so cc stable isn't really going to work ... it will need backporting. I can test either the backport or 3.6-rc1 with the patch if there's interest. Sorry, the cc: you got lost, testing feedback highly welcome. The ChromeOS guys just reported back that for them fully symmetric values actually lead to the least power consumption for light gpu loads (which these are not yet), so maybe we need to tune things some more even. Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't hardcode the number of pipes in the error state dump
On Wed, Aug 15, 2012 at 07:42:15PM +0100, Chris Wilson wrote: On Wed, 15 Aug 2012 19:23:25 +0100, Damien Lespiau damien.lesp...@gmail.com wrote: From: Damien Lespiau damien.lesp...@intel.com New-ish devices have 3 pipes, so let's not just hardcode 2 but use the for_each_pipe() macro and make struct intel_display_error_state is big enough. V2: Also add the number of pipes emitted (Chris Wilson) Signed-off-by: Damien Lespiau damien.lesp...@intel.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. I guess next on your list will be adding some of the PCH register states, along with a list of active encoders / connectors etc. I'm not sure that's worth it, at least usually the gt doesn't fall over when we anger the pch ... Simply grabbing a register dump for interesting configurations and comparing them worksforme. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Allow VGA on CRTC 2
On Mon, Aug 13, 2012 at 09:34:45PM -0700, Keith Packard wrote: This is left over from the old PLL sharing code and isn't useful now that PLLs are shared when possible. Signed-off-by: Keith Packard kei...@keithp.com Queued for -next, thanks for the patch. I'll hold off a bit on the others until it's a bit clearer what's going on/wrong. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Problems w/Sandy Bridge 27 monitor
Hi, I recently upgraded to a 27 monitor (2560x1440) from a 23 one (1920x1080), and had to switch to Windows because the new monitor is unusable in Linux. Today, about a month later, I decided to give Linux another try, since there have been several updates to the Intel graphics driver since then. Unfortunately, it seems that it's still unusable with xf86-video-intel 2.20.3 -- after a little while, the video signal to the 27 monitor completely stops, and it goes into power saving mode. I'm running dual monitors with the old 23, and that one continues running fine when this happens. This happens on my ThinkPad X220 (i5-2540M). The 27 is connected via DisplayPort, and the 23 via DVI. SNA is enabled, if it makes any difference (I haven't tried turning it off, but I probably should). This is the biggest problem I'm facing when it comes to Linux support. I also gave the new TearFree option a try, and while it does a great job of eliminating tearing, it makes the two monitors become mirrors of each other for some reason. If I take a screenshot with the GNOME tool, the screenshot comes out as expected (unmirrored), but the video output on the two monitors is mirrored in reality. Disabling TearFree fixes this. Also, when I'm using the ThinkPad's built-in display, it sometimes turns off for no apparent reason, although it's not too big of a deal since a suspend/resume cycle seems to fix things (and I haven't used 2.20.3 long enough to experience this yet). Any ideas/things I can do to help track these issues down? Thanks, Chun-Yu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Problems w/Sandy Bridge 27 monitor
On Wed, Aug 15, 2012 at 06:38:10PM -0400, Chun-Yu Shei wrote: Hi, I recently upgraded to a 27 monitor (2560x1440) from a 23 one (1920x1080), and had to switch to Windows because the new monitor is unusable in Linux. Today, about a month later, I decided to give Linux another try, since there have been several updates to the Intel graphics driver since then. Unfortunately, it seems that it's still unusable with xf86-video-intel 2.20.3 -- after a little while, the video signal to the 27 monitor completely stops, and it goes into power saving mode. I'm running dual monitors with the old 23, and that one continues running fine when this happens. This happens on my ThinkPad X220 (i5-2540M). The 27 is connected via DisplayPort, and the 23 via DVI. SNA is enabled, if it makes any difference (I haven't tried turning it off, but I probably should). This is the biggest problem I'm facing when it comes to Linux support. I also gave the new TearFree option a try, and while it does a great job of eliminating tearing, it makes the two monitors become mirrors of each other for some reason. If I take a screenshot with the GNOME tool, the screenshot comes out as expected (unmirrored), but the video output on the two monitors is mirrored in reality. Disabling TearFree fixes this. Also, when I'm using the ThinkPad's built-in display, it sometimes turns off for no apparent reason, although it's not too big of a deal since a suspend/resume cycle seems to fix things (and I haven't used 2.20.3 long enough to experience this yet). Any ideas/things I can do to help track these issues down? For the screen blanking issues, the kernel is the important part. Please boot with drm.debug=0xe added to your kernel bootline and grab the full dmesg. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/contexts: fix list corruption
On Tue, Aug 14, 2012 at 02:35:14PM -0700, Ben Widawsky wrote: After reset we unconditionally reinitialize lists. If the context switch hasn't yet completed before the suspend, the default context object will end up on lists that are going to go away when we resume. The patch forces the context switch to be synchronous before suspend assuring that the active/inactive tracking is correct at the time of resume. References: https://bugs.freedesktop.org/show_bug.cgi?id=52429 Tested-by: Guang A Yang guang.a.y...@intel.com Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Picked up for -fixes (with a minor conflict resolved), thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 3/4] drm/i915: Haswell HDMI audio initialization
On Wed, Aug 15, 2012 at 08:05:14PM +0300, Imre Deak wrote:
On Wed, Aug 15, 2012 at 6:27 AM, Wang, Xingchao xingchao.w...@intel.com
wrote:
Hi Daniel/Imre,
This revised version changelog:
- add Wait for 1 vertical blank after enable audio output port
- configure pipe related transcoder instead of operate all transcoders
blindly
Thanks for the explanation. I'd have still a couple of questions inlined:
+
+ /* Audio output enable */
+ DRM_DEBUG_DRIVER(HDMI audio: enable codec\n);
+ tmp = I915_READ(aud_cntrl_st2);
+ tmp |= (AUDIO_OUTPUT_ENABLE_A | AUDIO_OUTPUT_ENABLE_B |
AUDIO_OUTPUT_ENABLE_C);
The output bits are also transcoder specific, so why don't we enable
only the required output?
I.e. similarly as you do below tmp |= AUDIO_OUTPUT_ENABLE_A (pipe *
4);. Otherwise
this function will leave also unrelated outputs enabled which is not
that nice power
management-wise.
Thanks, makes sense. :)
I left the code without change because as the Audio enable sequence
description, there's no particular requirement to set the bit based on which
transcoder would be used. So i just enable *ALL* transcoders. Anyway your
suggestion makes sense, i should only enable the related transcoder. Wil make
that change in next version.
+ I915_WRITE(aud_cntrl_st2, tmp);
+
+ /* Wait for 1 vertical blank */
+ intel_wait_for_vblank(dev, pipe);
+
+ /* Set ELD valid state */
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: pin eld vld status=0x%8x\n, tmp);
+ tmp |= (AUDIO_ELD_VALID_A (pipe * 4));
+ I915_WRITE(aud_cntrl_st2, tmp);
+ tmp = I915_READ(aud_cntrl_st2);
+ DRM_DEBUG_DRIVER(HDMI audio: eld vld status=0x%8x\n, tmp);
+
+ /* Enable HDMI mode */
+ tmp = I915_READ(aud_config);
+ DRM_DEBUG_DRIVER(HDMI audio: audio conf: 0x%8x\n, tmp);
+ /* clear N_programing_enable and N_value_index */
+ tmp = ~(AUD_CONFIG_N_VALUE_INDEX |
AUD_CONFIG_N_PROG_ENABLE);
+ I915_WRITE(aud_config, tmp);
+
+ DRM_DEBUG_DRIVER(ELD on pipe %c\n, pipe_name(pipe));
+
+ i = I915_READ(aud_cntl_st);
+ i = (i 29) DIP_PORT_SEL_MASK; /* DIP_Port_Select,
0x1 =
PortB */
+ if (!i) {
+ DRM_DEBUG_DRIVER(Audio directed to unknown port\n);
+ /* operate blindly on all ports */
+ eldv = AUDIO_ELD_VALID_A;
+ eldv |= AUDIO_ELD_VALID_B;
+ eldv |= AUDIO_ELD_VALID_C;
+ } else {
+ DRM_DEBUG_DRIVER(ELD on port %c\n, 'A' + i);
+ eldv = AUDIO_ELD_VALID_A ((i - 1) * 4);
+ }
Again, if we handle the ELD_VALID bits on a transcoder basis, as above
when enabling and
disabling it, why are we doing it here differently, on a port basis?
A bit different. These bits[30:29] reflects which port is used to transmit DIP
data. It's configured in other register, see PIPE_DDI_FUNC_CTL, that
determines which DDI port would be combined with current pipe. I think it's
also transcoder basis. please note aud_cntl_st is also pipe based.
This should read then just
as above eldv = AUDIO_ELD_VALID_A (pipe * 4);
As a sidenote I guess at the moment due to the bug you mentioned
DIP_PORT_SEL will
always read 0, hence the else branch never runs and we just enable
blindly all valid bits.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Extract reading INSTDONE
INSTDONE is used in many places, and it varies from generation to
generation. This provides a good reason for us to extract the logic to
read the relevant information.
The patch has no functional change. It's prep for some new stuff.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_irq.c | 49 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0c37101..0bf2f92 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1071,6 +1071,20 @@ i915_error_first_batchbuffer(struct drm_i915_private
*dev_priv,
return NULL;
}
+static void i915_get_extra_instdone(struct drm_device *dev,
+ uint32_t instdone[I915_NUM_INSTDONE_REG])
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ if (INTEL_INFO(dev)-gen 4) {
+ instdone[0] = I915_READ(INSTDONE);
+ instdone[1] = 0;
+ } else {
+ instdone[0] = I915_READ(INSTDONE_I965);
+ instdone[1] = I915_READ(INSTDONE1);
+ }
+}
+
+
static void i915_record_ring_state(struct drm_device *dev,
struct drm_i915_error_state *error,
struct intel_ring_buffer *ring)
@@ -1286,6 +1300,7 @@ void i915_destroy_error_state(struct drm_device *dev)
static void i915_report_and_clear_eir(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t instdone[I915_NUM_INSTDONE_REG];
u32 eir = I915_READ(EIR);
int pipe;
@@ -1294,16 +1309,18 @@ static void i915_report_and_clear_eir(struct drm_device
*dev)
pr_err(render error detected, EIR: 0x%08x\n, eir);
+ memset(instdone, 0, sizeof(instdone));
+ i915_get_extra_instdone(dev, instdone);
+
if (IS_G4X(dev)) {
if (eir (GM45_ERROR_MEM_PRIV | GM45_ERROR_CP_PRIV)) {
u32 ipeir = I915_READ(IPEIR_I965);
pr_err( IPEIR: 0x%08x\n, I915_READ(IPEIR_I965));
pr_err( IPEHR: 0x%08x\n, I915_READ(IPEHR_I965));
- pr_err( INSTDONE: 0x%08x\n,
- I915_READ(INSTDONE_I965));
+ pr_err( INSTDONE: 0x%08x\n, instdone[0]);
pr_err( INSTPS: 0x%08x\n, I915_READ(INSTPS));
- pr_err( INSTDONE1: 0x%08x\n, I915_READ(INSTDONE1));
+ pr_err( INSTDONE1: 0x%08x\n, instdone[1]);
pr_err( ACTHD: 0x%08x\n, I915_READ(ACTHD_I965));
I915_WRITE(IPEIR_I965, ipeir);
POSTING_READ(IPEIR_I965);
@@ -1342,7 +1359,7 @@ static void i915_report_and_clear_eir(struct drm_device
*dev)
pr_err( IPEIR: 0x%08x\n, I915_READ(IPEIR));
pr_err( IPEHR: 0x%08x\n, I915_READ(IPEHR));
- pr_err( INSTDONE: 0x%08x\n, I915_READ(INSTDONE));
+ pr_err( INSTDONE: 0x%08x\n, instdone[0]);
pr_err( ACTHD: 0x%08x\n, I915_READ(ACTHD));
I915_WRITE(IPEIR, ipeir);
POSTING_READ(IPEIR);
@@ -1351,10 +1368,9 @@ static void i915_report_and_clear_eir(struct drm_device
*dev)
pr_err( IPEIR: 0x%08x\n, I915_READ(IPEIR_I965));
pr_err( IPEHR: 0x%08x\n, I915_READ(IPEHR_I965));
- pr_err( INSTDONE: 0x%08x\n,
- I915_READ(INSTDONE_I965));
+ pr_err( INSTDONE: 0x%08x\n, instdone[0]);
pr_err( INSTPS: 0x%08x\n, I915_READ(INSTPS));
- pr_err( INSTDONE1: 0x%08x\n, I915_READ(INSTDONE1));
+ pr_err( INSTDONE1: 0x%08x\n, instdone[1]);
pr_err( ACTHD: 0x%08x\n, I915_READ(ACTHD_I965));
I915_WRITE(IPEIR_I965, ipeir);
POSTING_READ(IPEIR_I965);
@@ -1669,7 +1685,7 @@ void i915_hangcheck_elapsed(unsigned long data)
{
struct drm_device *dev = (struct drm_device *)data;
drm_i915_private_t *dev_priv = dev-dev_private;
- uint32_t acthd[I915_NUM_RINGS], instdone, instdone1;
+ uint32_t acthd[I915_NUM_RINGS], instdone[I915_NUM_INSTDONE_REG];
struct intel_ring_buffer *ring;
bool err = false, idle;
int i;
@@ -1697,25 +1713,20 @@ void i915_hangcheck_elapsed(unsigned long data)
return;
}
- if (INTEL_INFO(dev)-gen 4) {
- instdone = I915_READ(INSTDONE);
- instdone1 = 0;
- } else {
- instdone = I915_READ(INSTDONE_I965);
- instdone1 = I915_READ(INSTDONE1);
- }
+ memset(instdone, 0,
[Intel-gfx] [PATCH 2/3] drm/i915: Add new INSTDONE registers
Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_reg.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 948ede9..b290221 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -485,7 +485,11 @@ #define IPEIR_I965 0x02064 #define IPEHR_I965 0x02068 #define INSTDONE_I965 0x0206c -#define I915_NUM_INSTDONE_REG 2 +#define GEN7_INSTDONE_10x0206c +#define GEN7_SC_INSTDONE 0x07100 +#define GEN7_SAMPLER_INSTDONE 0x0e160 +#define GEN7_ROW_INSTDONE 0x0e164 +#define I915_NUM_INSTDONE_REG 4 #define RING_IPEIR(base) ((base)+0x64) #define RING_IPEHR(base) ((base)+0x68) #define RING_INSTDONE(base)((base)+0x6c) -- 1.7.11.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Use new INSTDONE registers
Using the extracted INSTDONE reading, and our new register definitions,
update our hangcheck and error collection to use it.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 ---
drivers/gpu/drm/i915/i915_drv.h | 5 ++--
drivers/gpu/drm/i915/i915_irq.c | 47 +++--
3 files changed, 37 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e8f14d..c1474fb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -645,10 +645,9 @@ static void i915_ring_error_state(struct seq_file *m,
seq_printf(m, IPEIR: 0x%08x\n, error-ipeir[ring]);
seq_printf(m, IPEHR: 0x%08x\n, error-ipehr[ring]);
seq_printf(m, INSTDONE: 0x%08x\n, error-instdone[ring]);
- if (ring == RCS INTEL_INFO(dev)-gen = 4) {
- seq_printf(m, INSTDONE1: 0x%08x\n, error-instdone1);
+ if (ring == RCS INTEL_INFO(dev)-gen = 4)
seq_printf(m, BBADDR: 0x%08llx\n, error-bbaddr);
- }
+
if (INTEL_INFO(dev)-gen = 4)
seq_printf(m, INSTPS: 0x%08x\n, error-instps[ring]);
seq_printf(m, INSTPM: 0x%08x\n, error-instpm[ring]);
@@ -697,6 +696,9 @@ static int i915_error_state(struct seq_file *m, void
*unused)
for (i = 0; i dev_priv-num_fence_regs; i++)
seq_printf(m, fence[%d] = %08llx\n, i, error-fence[i]);
+ for (i = 0; i I915_NUM_INSTDONE_REG; i++)
+ seq_printf(m, INSTDONE_%d: 0x%08x\n, i,
error-extra_instdone[i]);
+
if (INTEL_INFO(dev)-gen = 6) {
seq_printf(m, ERROR: 0x%08x\n, error-error);
seq_printf(m, DONE_REG: 0x%08x\n, error-done_reg);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b69be6..cd2ee29 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -198,7 +198,7 @@ struct drm_i915_error_state {
u32 error; /* gen6+ */
u32 instpm[I915_NUM_RINGS];
u32 instps[I915_NUM_RINGS];
- u32 instdone1;
+ u32 extra_instdone[I915_NUM_INSTDONE_REG];
u32 seqno[I915_NUM_RINGS];
u64 bbaddr;
u32 fault_reg[I915_NUM_RINGS];
@@ -460,8 +460,7 @@ typedef struct drm_i915_private {
struct timer_list hangcheck_timer;
int hangcheck_count;
uint32_t last_acthd[I915_NUM_RINGS];
- uint32_t last_instdone;
- uint32_t last_instdone1;
+ uint32_t prev_instdone[I915_NUM_INSTDONE_REG];
unsigned int stop_rings;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0bf2f92..668bc70 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1075,12 +1075,26 @@ static void i915_get_extra_instdone(struct drm_device
*dev,
uint32_t instdone[I915_NUM_INSTDONE_REG])
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (INTEL_INFO(dev)-gen 4) {
+
+ switch(INTEL_INFO(dev)-gen) {
+ case 2:
+ case 3:
instdone[0] = I915_READ(INSTDONE);
- instdone[1] = 0;
- } else {
+ break;
+ case 4:
+ case 5:
+ case 6:
instdone[0] = I915_READ(INSTDONE_I965);
instdone[1] = I915_READ(INSTDONE1);
+ break;
+ default:
+ WARN_ONCE(1, Unsupported platform\n);
+ case 7:
+ instdone[0] = I915_READ(GEN7_INSTDONE_1);
+ instdone[1] = I915_READ(GEN7_SC_INSTDONE);
+ instdone[2] = I915_READ(GEN7_SAMPLER_INSTDONE);
+ instdone[3] = I915_READ(GEN7_ROW_INSTDONE);
+ break;
}
}
@@ -1106,10 +1120,8 @@ static void i915_record_ring_state(struct drm_device
*dev,
error-ipehr[ring-id] = I915_READ(RING_IPEHR(ring-mmio_base));
error-instdone[ring-id] =
I915_READ(RING_INSTDONE(ring-mmio_base));
error-instps[ring-id] =
I915_READ(RING_INSTPS(ring-mmio_base));
- if (ring-id == RCS) {
- error-instdone1 = I915_READ(INSTDONE1);
+ if (ring-id == RCS)
error-bbaddr = I915_READ64(BB_ADDR);
- }
} else {
error-faddr[ring-id] = I915_READ(DMA_FADD_I8XX);
error-ipeir[ring-id] = I915_READ(IPEIR);
@@ -1184,6 +1196,7 @@ static void i915_capture_error_state(struct drm_device
*dev)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object *obj;
struct drm_i915_error_state *error;
+ uint32_t instdone[I915_NUM_INSTDONE_REG];
unsigned long flags;
int i, pipe;
@@ -1225,6 +1238,10 @@ static void i915_capture_error_state(struct drm_device
*dev)
error-done_reg = I915_READ(DONE_REG);
