Re: [Intel-gfx] [PATCH 1/2] drm/i915: gtfifodbg in error state
On Tue, 7 Feb 2012 10:28:30 +0100, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Feb 03, 2012 at 02:31:40PM -0800, Ben Widawsky wrote:
- Add register definitions for GTFIFODBG.
- Capture it at error time.
- Print it from debugfs (with whitespace fix).
This register tells us if either a read, or a write occured while the
fifo was full.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c |3 ++-
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |1 +
drivers/gpu/drm/i915/i915_reg.h |6 ++
drivers/gpu/drm/i915/intel_display.c |3 +++
5 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6c3be86..f91a5d4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -760,7 +760,8 @@ static int i915_error_state(struct seq_file *m, void
*unused)
seq_printf(m, EIR: 0x%08x\n, error-eir);
seq_printf(m, PGTBL_ER: 0x%08x\n, error-pgtbl_er);
if (INTEL_INFO(dev)-gen = 6) {
- seq_printf(m, ERROR: 0x%08x\n, error-error);
+ seq_printf(m, ERROR: 0x%08x\n, error-error);
+ seq_printf(m, FIFODBG: 0x%08x\n, error-gtfifodbg);
seq_printf(m, Blitter command stream:\n);
seq_printf(m, ACTHD:0x%08x\n, error-bcs_acthd);
seq_printf(m, IPEIR:0x%08x\n, error-bcs_ipeir);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index f02a5f5..f02a57d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -173,6 +173,7 @@ struct drm_i915_error_state {
u32 seqno;
u64 bbaddr;
u64 fence[I915_MAX_NUM_FENCES];
+ u32 gtfifodbg;
struct timeval time;
struct drm_i915_error_object {
int page_count;
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 5d433fc..d99592c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -918,6 +918,7 @@ static void i915_capture_error_state(struct drm_device
*dev)
error-error = 0;
if (INTEL_INFO(dev)-gen = 6) {
error-error = I915_READ(ERROR_GEN6);
+ error-gtfifodbg = I915_READ(GTFIFODBG);
error-bcs_acthd = I915_READ(BCS_ACTHD);
error-bcs_ipehr = I915_READ(BCS_IPEHR);
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index c3afb78..1231c8e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3614,6 +3614,12 @@
#define ECOBUS0xa180
#defineFORCEWAKE_MT_ENABLE (15)
+#define GTFIFODBG 0x12
+#defineGT_FIFO_OVFERR (12)
+#defineGT_FIFO_CPU_ERROR_MASK 3
Reading configdb it sounds like bit 2 is set when either bit 1 or bit 0 is
set, but I might be wrong so imo it's better to check for all three bits.
+#defineGT_FIFO_IAWRERR (11)
+#defineGT_FIFO_IARDERR (10)
+
#define GT_FIFO_FREE_ENTRIES 0x120008
#defineGT_FIFO_NUM_RESERVED_ENTRIES20
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ebe71ed..537f029 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8215,6 +8215,9 @@ void gen6_enable_rps(struct drm_i915_private
*dev_priv)
*/
I915_WRITE(GEN6_RC_STATE, 0);
mutex_lock(dev_priv-dev-struct_mutex);
+ /* Clear the DBG now so we don't confuse earlier errors */
+ I915_WRITE(GTFIFODBG, GT_FIFO_CPU_ERROR_MASK);
I think we shouldn't silently clear errors here. Simplest might be a small
inline helper to WARN_ON dirt in the gt fifo db reg - could be used in the
later patches.
This reminds me, we have a few other error registers we should scrub upon init,
along with the warning that something bad happened earlier.
-Chris
+
gen6_gt_force_wake_get(dev_priv);
/* disable the counters and set deterministic thresholds */
--
1.7.9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
--
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 2/2 v2] drm/i915: catch gtfifo errors on forcewake_put
On Sat, Feb 04, 2012 at 11:48:43AM -0800, Ben Widawsky wrote: This is similar to a patch I wrote several months ago. It's been updated for the new FORCEWAKE_MT, and it also no longer clears the debug register as it may be helpful to get that for the error state. Also recommended by Chris Wilson, use WARN() instead of DRM_ERROR, so we can get a backtrace. v2: replace POSTING_READ with I915_READ_NOTRACE(GTFIFODBG). Recommended by Chris Wilson Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Ben Widawsky b...@bwidawsk.net Looks good and because we can drop the posting read it shouldn't have any perf impact. But we're not checking anything on the write side, which is actually used the most under normal gem loads (tail updates). Because the write path is rather perf critical, I think we should only check for errors in the gt fifo reg if the wait_for_fifo times out. Can you whip up that patch, too? 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
[Intel-gfx] The Latest Status of Kernel Testing
We finished a new round of Kernel testing. Sorry for the late report sending, since we just come from vacation. We run through the testing with the latest commit(60f1358afca2d7778138c6dc187a3198f1a2425f) on Daniel's drm-intel-testing branch. In this round testing, we cover platform IvyBridge, SandyBridge and IronLake. Generally, 2 new bugs are filed (bug 45576, 45729). And the old ones which could be produced now are: 41140, 44305, 41977, 42194, 41976 and 44250. BTW, because of the vacation the nightly testing is unstable, so the intel-gpu-tools case failure will be summarized one or two days later. Thanks --Yi,Sun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/3] GTFIFODBG
The GTFIFODBG registers gives us some info regarding the state of the GT FIFO. In the following patches we therefore add a few things: 1. Add the register definition, and clear previous errors. 2. Check if any failures occurred when doing a forcewake_put. 3. Check if any failures occurred after reaching the low watermark of the write threshold. This differs from #2 slightly in that there is an extra error bit which seems to indicate a read error in the register. It is my suspicion though that #2, and #3 will often be redundant, but since the clearing of the register occurs during the check, you will only see one message. I've only done some basic checks for performance regressions, and found none. Ben Widawsky (3): drm/i915: use gtfifodbg drm/i915: catch gtfifo errors on forcewake_put drm/i915: check gtfifodbg after possibly failed writes drivers/gpu/drm/i915/i915_drv.c | 30 +- drivers/gpu/drm/i915/i915_drv.h |2 +- drivers/gpu/drm/i915/i915_reg.h |6 ++ drivers/gpu/drm/i915/intel_display.c |8 4 files changed, 40 insertions(+), 6 deletions(-) -- 1.7.9 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3 v2] drm/i915: use gtfifodbg
Add register definitions for GTFIFODBG, and clear it during init time to
make sure state is correct.
This register tells us if either a read, or a write occurred while the
fifo was full.
v2: Check all 3 mask bits, and DRM_ERROR when we see one of the fifodbg
bits set on init. Remove error state portion as it's redundant with
later patches.
Reviewed-by (v1): Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by (v1): Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_reg.h |6 ++
drivers/gpu/drm/i915/intel_display.c |8
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c3afb78..1410fc4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3614,6 +3614,12 @@
#define ECOBUS0xa180
#defineFORCEWAKE_MT_ENABLE (15)
+#define GTFIFODBG 0x12
+#defineGT_FIFO_CPU_ERROR_MASK 7
+#defineGT_FIFO_OVFERR (12)
+#defineGT_FIFO_IAWRERR (11)
+#defineGT_FIFO_IARDERR (10)
+
#define GT_FIFO_FREE_ENTRIES 0x120008
#defineGT_FIFO_NUM_RESERVED_ENTRIES20
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ebe71ed..4f1205e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8204,6 +8204,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
u32 rp_state_cap = I915_READ(GEN6_RP_STATE_CAP);
u32 gt_perf_status = I915_READ(GEN6_GT_PERF_STATUS);
u32 pcu_mbox, rc6_mask = 0;
+ u32 gtfifodbg;
int cur_freq, min_freq, max_freq;
int i;
@@ -8215,6 +8216,13 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
*/
I915_WRITE(GEN6_RC_STATE, 0);
mutex_lock(dev_priv-dev-struct_mutex);
+
+ /* Clear the DBG now so we don't confuse earlier errors */
+ if ((gtfifodbg = I915_READ(GTFIFODBG))) {
+ DRM_ERROR(GT fifo had a previous error %x\n, gtfifodbg);
+ I915_WRITE(GTFIFODBG, gtfifodbg);
+ }
+
gen6_gt_force_wake_get(dev_priv);
/* disable the counters and set deterministic thresholds */
--
1.7.9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3 v3] drm/i915: catch gtfifo errors on forcewake_put
This is similar to a patch I wrote several months ago. It's been updated
for the new FORCEWAKE_MT, and it also no longer clears the debug
register as it may be helpful to get that for the error state. Also
recommended by Chris Wilson, use WARN() instead of DRM_ERROR, so we can
get a backtrace.
v2: Replace POSTING_READ with I915_READ_NOTRACE(GTFIFODBG). Recommended
by Chris Wilson
v3: Pull the fifo check out into a helper function to reduce code
duplication
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1658cfd..a7858a1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -379,16 +379,27 @@ void gen6_gt_force_wake_get(struct drm_i915_private
*dev_priv)
dev_priv-display.force_wake_get(dev_priv);
}
+static void gen6_gt_check_fifodbg(struct drm_i915_private *dev_priv)
+{
+ u32 gtfifodbg;
+ gtfifodbg = I915_READ_NOTRACE(GTFIFODBG);
+ WARN(gtfifodbg GT_FIFO_CPU_ERROR_MASK,
+MMIO read or write has been dropped %x\n, gtfifodbg);
+ I915_WRITE_NOTRACE(GTFIFODBG, GT_FIFO_CPU_ERROR_MASK);
+}
+
void __gen6_gt_force_wake_put(struct drm_i915_private *dev_priv)
{
I915_WRITE_NOTRACE(FORCEWAKE, 0);
- POSTING_READ(FORCEWAKE);
+ /* The below doubles as a POSTING_READ */
+ gen6_gt_check_fifodbg(dev_priv);
}
void __gen6_gt_force_wake_mt_put(struct drm_i915_private *dev_priv)
{
I915_WRITE_NOTRACE(FORCEWAKE_MT, (116) | 0);
- POSTING_READ(FORCEWAKE_MT);
+ /* The below doubles as a POSTING_READ */
+ gen6_gt_check_fifodbg(dev_priv);
}
/*
--
1.7.9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: check gtfifodbg after possibly failed writes
If we don't have a sufficient number of free entries in the FIFO, we
proceed to do a write anyway. With this check we should have a clue if
that write actually failed or not.
After some discussion with Daniel Vetter regarding his original
complaint, we agreed upon this.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.c | 15 ---
drivers/gpu/drm/i915/i915_drv.h |2 +-
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7858a1..ff5c3c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -413,8 +413,10 @@ void gen6_gt_force_wake_put(struct drm_i915_private
*dev_priv)
dev_priv-display.force_wake_put(dev_priv);
}
-void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
+int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv)
{
+ int ret = 0;
+
if (dev_priv-gt_fifo_count GT_FIFO_NUM_RESERVED_ENTRIES) {
int loop = 500;
u32 fifo = I915_READ_NOTRACE(GT_FIFO_FREE_ENTRIES);
@@ -422,10 +424,13 @@ void __gen6_gt_wait_for_fifo(struct drm_i915_private
*dev_priv)
udelay(10);
fifo = I915_READ_NOTRACE(GT_FIFO_FREE_ENTRIES);
}
- WARN_ON(loop 0 fifo = GT_FIFO_NUM_RESERVED_ENTRIES);
+ WARN_ON(loop 0 fifo = GT_FIFO_NUM_RESERVED_ENTRIES
+ ++ret);
dev_priv-gt_fifo_count = fifo;
}
dev_priv-gt_fifo_count--;
+
+ return ret;
}
static int i915_drm_freeze(struct drm_device *dev)
@@ -960,11 +965,15 @@ __i915_read(64, q)
#define __i915_write(x, y) \
void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x val) { \
+ u32 __fifo_ret = 0; \
trace_i915_reg_rw(true, reg, val, sizeof(val)); \
if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
- __gen6_gt_wait_for_fifo(dev_priv); \
+ __fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
} \
write##y(val, dev_priv-regs + reg); \
+ if (unlikely(__fifo_ret)) { \
+ gen6_gt_check_fifodbg(dev_priv); \
+ } \
}
__i915_write(8, b)
__i915_write(16, w)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f02a5f5..ad6408f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1350,7 +1350,7 @@ extern void intel_display_print_error_state(struct
seq_file *m,
*/
void gen6_gt_force_wake_get(struct drm_i915_private *dev_priv);
void gen6_gt_force_wake_put(struct drm_i915_private *dev_priv);
-void __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv);
+int __gen6_gt_wait_for_fifo(struct drm_i915_private *dev_priv);
/* We give fast paths for the really cool registers */
#define NEEDS_FORCE_WAKE(dev_priv, reg) \
--
1.7.9
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [pull] drm-intel-next-2012-01-20
Hi Dave, I've quickly looked at the qa report and one bug seems to be a benign warning due to one of Adam's paranoia patches. The other is a modeset failure because the kernel detects more modes (and the new ones fail). Could be either due to the CEA patch or one of the dp bandwidth patches. The old modes still all work. There's also a harmless dmesg splat issue on my i855, but I've already queued a fix for that and I'd like to send you the -next tree exactly as tested. Highlights: - Random small patches that got lost (mostly from Adam) - kill i915_mem.c - Export a HAS_LLC flag to be able to correctly chose optimal upload/download paths. - Start of a i9xx_mode_set refactor from Jesse - I've dropped the last one, it was too big. QA report below the pull request. Cheers, Daniel The following changes since commit 095f979a539245a46b9e5d600ec9c720b4d928e5: drm/nouveau/pm: fix build with HWMON off (2012-01-10 10:13:16 +) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied Adam Jackson (7): drm/i915: Silence _DSM errors drm/i915: Implement plane-disabled assertion for PCH too drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP) drm/i915: Remove a comment about PCH from the non-PCH path drm/i915/dp: Tweak auxch clock divider for PCH drm/i915/dp: Use auxch precharge value of 5 everywhere drm/i915/dp: Check for AUXCH error before checking for success Ben Widawsky (1): agp/intel: Add pci id for hostbridge from has/qemu Chris Wilson (1): drm/i915: Check that plane/pipe is disabled before removing the fb Daniel Vetter (1): drm/i915: kill i915_mem.c Eugeni Dodonov (3): drm/i915: there is no pipe CxSR on ironlake drm/i915: fix typo in function name drm/i915: add a LLC feature flag in device description Jesse Barnes (2): drm/i915: split 9xx refclk sdvo tv code out drm/i915: split out pll divider code Sean Paul (1): drm/i915: Only look for matching clocks for LVDS downclock Simon Que (1): drivers: i915: Fix BLC PWM register setup Thomas Meyer (1): drm/i915: Use kcalloc instead of kzalloc to allocate array drivers/char/agp/intel-agp.c |1 + drivers/gpu/drm/drm_ioctl.c |2 + drivers/gpu/drm/i915/Makefile|2 +- drivers/gpu/drm/i915/i915_debugfs.c |1 + drivers/gpu/drm/i915/i915_dma.c | 17 +- drivers/gpu/drm/i915/i915_drv.c |8 +- drivers/gpu/drm/i915/i915_drv.h | 15 +-- drivers/gpu/drm/i915/i915_gem.c |4 +- drivers/gpu/drm/i915/i915_mem.c | 387 -- drivers/gpu/drm/i915/intel_acpi.c|2 +- drivers/gpu/drm/i915/intel_bios.c|2 +- drivers/gpu/drm/i915/intel_display.c | 239 + drivers/gpu/drm/i915/intel_dp.c | 13 +- drivers/gpu/drm/i915/intel_panel.c |4 +- include/drm/i915_drm.h |1 + 15 files changed, 180 insertions(+), 518 deletions(-) delete mode 100644 drivers/gpu/drm/i915/i915_mem.c On Tue, Feb 07, 2012 at 10:09:56AM +, Sun, Yi wrote: We finished a new round of Kernel testing. Sorry for the late report sending, since we just come from vacation. We run through the testing with the latest commit(60f1358afca2d7778138c6dc187a3198f1a2425f) on Daniel's drm-intel-testing branch. In this round testing, we cover platform IvyBridge, SandyBridge and IronLake. Generally, 2 new bugs are filed (bug 45576, 45729). And the old ones which could be produced now are: 41140, 44305, 41977, 42194, 41976 and 44250. BTW, because of the vacation the nightly testing is unstable, so the intel-gpu-tools case failure will be summarized one or two days later. Thanks --Yi,Sun -- 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 3/3] drm/i915: gen7: work around a system hang on IVB
On Sun, 5 Feb 2012 20:47:06 -0200, Eugeni Dodonov eugeni.dodo...@intel.com wrote: This adds the workaround for WaCatErrorRejectionIssue which could result in a system hang. Reviewed-by: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |4 drivers/gpu/drm/i915/intel_display.c |5 + 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 92274b1..4f25cd5 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3035,6 +3035,10 @@ #define GEN7_L3_CHICKEN_MODE_REGISTER0xB030 #define GEN7_WA_L3_CHICKEN_MODE 0x2000 +/* WaCatErrorRejectionIssue */ +#define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG 0x9030 +#define GEN7_SQ_CHICKEN_MBCUNIT_SQINTMOB(111) In the BSpec, this is SQCM and they say 9030 not 9030h like normal, so it was hard to search for. Also, I'm not sure what SQINTMOB is supposed to mean. The bit is named Rejection FifoFlush Disable in the docs I can find. I'd like to see the names fixed up so that we can find them again later, but other than that, Reviewed-by: Eric Anholt e...@anholt.net pgpur16o5zJnx.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Is there a way to determine which display is the laptop display?
Your idea about proxying the lid state to the drm connection state would be perfect. Why leave the display turned on when you can't see it anyway? Closing the lid is pretty much equivalent to yanking a monitor cable. If that can't be done is there any chance something could be put into /sys/class/drm/card*_foo, like a new entry for the laptop screen, such as /sys/class/drm/card0-LVDS-1/laptop_screen? Could be created only for the laptop screen, or for every output but only the laptop returns TRUE. I've already got mapping from XRandR output names to drm output names (quite a bitch that was to get working across all systems), so reading the contents of the sysfs file wouldn't be hard. Thanks for the reply, Al Amaral From: Adam Jackson [mailto:a...@redhat.com] Sent: Mon 2/6/2012 4:44 PM To: Alan Amaral Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] Is there a way to determine which display is the laptop display? On 2/2/12 4:28 PM, Alan Amaral wrote: With earlier hardware it was pretty easy to determine which display was the laptop display as it was usually (always?) LVDS. With new hardware it's sometimes an embedded display port (eDP) display, and I've seen at least one laptop which has the laptop monitor listed as simply Display Port (DP), although that may not have been an Intel machine. In the DP case the laptop monitor can't be distinguished from a normal display port monitor. If the driver isn't reporting an eDP display as eDP, the driver is broken. The current code I have uses some heuristics to figure out what outputs are available on the system, i.e. checks for LVDS, then eDP, then DP, and makes a guess as to which one is the laptop monitor, but in some cases, like the DisplayPort case I described above, it's impossible to know for sure, and if a future release changes the names it will fail. The names won't change. There might be some new embedded display connectivity in the future with a new name, but that's something you'd have to handle then anyway. Ideally we'd come up with a way to proxy laptop lid state into DRM connector state directly, but a) there's a lot of broken hardware in the world and b) the kernel tends to stridently resist getting anything right in kernelspace when it's easier to let people get it wrong in userspace instead. Yes I'm bitter. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: swizzling support for snb/ivb
On Mon, 6 Feb 2012 16:45:00 +0100, Daniel Vetter dan...@ffwll.ch wrote:
On Sat, Feb 04, 2012 at 09:59:57PM +0100, Eric Anholt wrote:
On Thu, 2 Feb 2012 09:58:12 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We have to do this manually. Somebody had a Great Idea.
I've measured speed-ups just a few percent above the noise level
(below 5% for the best case), but no slowdows. Chris Wilson measured
quite a bit more (10-20% above the usual snb variance) on a more
recent and better tuned version of sna, but also recorded a few
slow-downs on benchmarks know for uglier amounts of snb-induced
variance.
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 51a2b0c..86fffd2 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3681,12 +3681,31 @@ i915_gem_idle(struct drm_device *dev)
return 0;
}
+void i915_gem_init_swizzling(struct drm_device *dev)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+
+ if (INTEL_INFO(dev)-gen 6 ||
+ dev_priv-mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_NONE)
+ return;
+
+ I915_WRITE(DISP_ARB_CTL, I915_READ(DISP_ARB_CTL) |
+ DISP_TILE_SURFACE_SWIZZLING);
+
+ I915_WRITE(TILECTL, I915_READ(TILECTL) | TILECTL_SWZCTL);
+ if (IS_GEN6(dev))
+ I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_SNB));
+ else
+ I915_WRITE(ARB_MODE, ARB_MODE_ENABLE(ARB_MODE_SWIZZLE_IVB));
+}
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 861223b..1a93066 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -93,8 +93,23 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
uint32_t swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
if (INTEL_INFO(dev)-gen = 6) {
- swizzle_x = I915_BIT_6_SWIZZLE_NONE;
- swizzle_y = I915_BIT_6_SWIZZLE_NONE;
+ uint32_t dimm_c0, dimm_c1;
+ dimm_c0 = I915_READ(MAD_DIMM_C0);
+ dimm_c1 = I915_READ(MAD_DIMM_C1);
+ dimm_c0 = MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
+ dimm_c1 = MAD_DIMM_A_SIZE_MASK | MAD_DIMM_B_SIZE_MASK;
+ /* Enable swizzling when the channels are populated with
+ * identically sized dimms. We don't need to check the 3rd
+ * channel because no cpu with gpu attached ships in that
+ * configuration. Also, swizzling only makes sense for 2
+ * channels anyway. */
+ if (dimm_c0 == dimm_c1) {
+ swizzle_x = I915_BIT_6_SWIZZLE_9_10;
+ swizzle_y = I915_BIT_6_SWIZZLE_9;
+ } else {
+ swizzle_x = I915_BIT_6_SWIZZLE_NONE;
+ swizzle_y = I915_BIT_6_SWIZZLE_NONE;
+ }
It looks to me like you're making the HW always swizzle bit 6 according
to 9 or 9/10 in i915_gem_init_swizzling, but you're not performing the
software side of swizzling in the !dual channel case. My guess would be
that when you take your other DIMM the swizzling for pread/pwrite/swap
goes wrong, and that the answer would be to just not look at dimm sizes.
Hm, I'm a bit confused here ... So let me explain how swizzling on gen6+
works with this patch:
Nah, I was the one confused. I missed the early return in init. Makes
sense to me now, and I agree that it should be safe to turn on
regardless, so the only issue might be that we should set swizzles on
more of the time than we actually manage to, which you already noted.
Reviewed-by: Eric Anholt e...@anholt.net
pgpvOmZZ1CjUy.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: don't unconditionally enable SPRITE_DEST_KEY on IVB
Now that we have specific color key ioctls, we don't need to set this all the time. Reported-by: Armin C Reese armin.c.re...@intel.com Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/intel_sprite.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 2288abf..4636811 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -95,7 +95,6 @@ ivb_update_plane(struct drm_plane *plane, struct drm_framebuffer *fb, /* must disable */ sprctl |= SPRITE_TRICKLE_FEED_DISABLE; sprctl |= SPRITE_ENABLE; - sprctl |= SPRITE_DEST_KEY; /* Sizes are 0 based */ src_w--; -- 1.7.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] updated -next
Hi all, I've just pushed out an updated -next tree. Highlights: - MI_WTF patches from Eric - ilk/dmar workaround recursion fix from Ben - pwrite/read EFAULT fixes for gtt userspace pointers - error_state rework and extension (still more to come here) and some debugfs refactoring to make that easier - shut up the harmless dmesg splatter from the previous next on i855gm - fence accounting improvements from Chris, fixes an sna vs. uxa perf regression on gen3 - some swizzling cleanups and fixes, notably to fix swapping on i915g/i945g - various other smaller things As usual, I've also updated drm-intel-testing to the latest -next with the latest -fixes from Keith merged in for easier testing. Go wild, test and please report any issues. 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
[Intel-gfx] [PATCH] drm/i915: add a force-dvi HDMI audio mode
When HDMI-DVI converter is used, it's not only necessary to turn off
audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since
the DVI mode is mainly tied to audio functionality from end user POV,
add a new force-dvi audio mode:
xrandr --output HDMI1 --set audio force-dvi
Note that most users won't need to set this and happily rely on the
EDID based DVI auto detection.
Reported-by: Andrea Arcangeli aarca...@redhat.com
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h|7 +++
drivers/gpu/drm/i915/intel_hdmi.c |8 +---
drivers/gpu/drm/i915/intel_modes.c |4 +++-
3 files changed, 15 insertions(+), 4 deletions(-)
--- linux-next.orig/drivers/gpu/drm/i915/i915_drv.h 2012-01-31
20:44:59.0 +0800
+++ linux-next/drivers/gpu/drm/i915/i915_drv.h 2012-02-08 10:37:30.0
+0800
@@ -749,6 +749,13 @@ typedef struct drm_i915_private {
struct drm_property *force_audio_property;
} drm_i915_private_t;
+enum hdmi_force_audio {
+ HDMI_AUDIO_OFF_DVI = -2,/* no aux data for HDMI-DVI converter */
+ HDMI_AUDIO_OFF, /* force turn off HDMI audio */
+ HDMI_AUDIO_AUTO,/* trust EDID */
+ HDMI_AUDIO_ON, /* force turn on HDMI audio */
+};
+
enum i915_cache_level {
I915_CACHE_NONE,
I915_CACHE_LLC,
--- linux-next.orig/drivers/gpu/drm/i915/intel_hdmi.c 2012-01-07
20:47:34.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_hdmi.c2012-02-08
10:37:30.0 +0800
@@ -339,7 +339,9 @@ intel_hdmi_detect(struct drm_connector *
if (edid) {
if (edid-input DRM_EDID_INPUT_DIGITAL) {
status = connector_status_connected;
- intel_hdmi-has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
+ if (intel_hdmi-force_audio != HDMI_AUDIO_OFF_DVI)
+ intel_hdmi-has_hdmi_sink =
+ drm_detect_hdmi_monitor(edid);
intel_hdmi-has_audio = drm_detect_monitor_audio(edid);
}
connector-display_info.raw_edid = NULL;
@@ -415,8 +417,8 @@ intel_hdmi_set_property(struct drm_conne
else
has_audio = i 0;
- if (has_audio == intel_hdmi-has_audio)
- return 0;
+ if (i == HDMI_AUDIO_OFF_DVI)
+ intel_hdmi-has_hdmi_sink = 0;
intel_hdmi-has_audio = has_audio;
goto done;
--- linux-next.orig/drivers/gpu/drm/i915/intel_modes.c 2011-10-19
11:11:20.0 +0800
+++ linux-next/drivers/gpu/drm/i915/intel_modes.c 2012-02-08
10:37:30.0 +0800
@@ -84,6 +84,7 @@ int intel_ddc_get_modes(struct drm_conne
}
static const char *force_audio_names[] = {
+ force-dvi,
off,
auto,
on,
@@ -106,7 +107,8 @@ intel_attach_force_audio_property(struct
return;
for (i = 0; i ARRAY_SIZE(force_audio_names); i++)
- drm_property_add_enum(prop, i, i-1,
force_audio_names[i]);
+ drm_property_add_enum(prop, i, i-2,
+ force_audio_names[i]);
dev_priv-force_audio_property = prop;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] uxa/glamor: Use a macro to specify module name.
-Original Message-
From: zhigang.g...@linux.intel.com [mailto:zhigang.g...@linux.intel.com]
Sent: Thursday, February 02, 2012 11:31 AM
To: ch...@chris-wilson.co.uk
Cc: intel-gfx@lists.freedesktop.org; zhigang.g...@linux.intel.com
Subject: [PATCH] uxa/glamor: Use a macro to specify module name.
From: Zhigang Gong zhigang.g...@linux.intel.com
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
src/intel_glamor.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/intel_glamor.c b/src/intel_glamor.c index
446dd3d..f908b7c
100644
--- a/src/intel_glamor.c
+++ b/src/intel_glamor.c
@@ -67,7 +67,7 @@ intel_glamor_pre_init(ScrnInfoPtr scrn)
intel = intel_get_screen_private(scrn);
/* Load glamor module */
- if ((glamor_module = xf86LoadSubModule(scrn, glamor_egl))) {
+ if ((glamor_module = xf86LoadSubModule(scrn,
GLAMOR_EGL_MODULE_NAME)))
+{
version = xf86GetModuleVersion(glamor_module);
if (version MODULE_VERSION_NUMERIC(0,3,0)) {
xf86DrvMsg(scrn-scrnIndex, X_ERROR,
--
1.7.4.4
This patch depends on glamor commit b5f8d...
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
