[Intel-gfx] ~2000ms pausing with GNOME3 desktop
I regularly experiencing a ~2000ms pause when clicking on 'Activities'/moving to the top-left corner in the GNOME3 desktop environment (eg once every 5 mins), both on IVB and SNB and kernels up to 3.10, seen on an 1920x1200 display on SNB and 2880x1440 display on IVB (Macbook Retina). This hurts the user experience with Intel HD graphics on linux. What kind of profiling would be useful to understand what's stalling graphics updates? Also, has anyone else experienced this? Many thanks, Daniel -- Daniel J Blueman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
On Mon, Jul 22, 2013 at 11:02:08PM +0200, Daniel Vetter wrote:
On Mon, Jul 22, 2013 at 01:12:30PM -0700, Ben Widawsky wrote:
On Mon, Jul 22, 2013 at 12:12:38PM +0200, Daniel Vetter wrote:
This has been broken in
commit 2f63315692b1d3c055972ad33fc7168ae908b97b
Author: Ben Widawsky b...@bwidawsk.net
Date: Wed Jul 17 12:19:03 2013 -0700
drm/i915: Create VMAs
which resulted in an OOPS the first time around we've hit -ENOSPC.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67156
Cc: Imre Deak imre.d...@intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Tested-by: meng mengmeng.m...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index cfa6588..c87a6ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3121,8 +3121,8 @@ i915_gem_object_bind_to_gtt(struct
drm_i915_gem_object *obj,
vma = i915_gem_vma_create(obj, dev_priv-gtt.base);
if (IS_ERR(vma)) {
- i915_gem_object_unpin_pages(obj);
- return PTR_ERR(vma);
+ ret = PTR_ERR(vma);
+ goto err_unpin;
}
Adding the extra goto here seems pointless to me.
Like explained on irc, that's just to have a nice OCD reverse err_foo:
label stacking at the end of the function.
search_free:
@@ -3138,17 +3138,17 @@ search_free:
if (ret == 0)
goto search_free;
- goto err_out;
+ goto err_free_vma;
}
My preference would be to exit early in drm_mm_remove_node() if the node
isn't allocated. I think at least we should add a WARN to
drm_mm_remove_node if the node-allocated == 0.
Hm, good idea. I'll create a quick patch.
if (WARN_ON(!i915_gem_valid_gtt_space(dev, vma-node,
obj-cache_level))) {
ret = -EINVAL;
- goto err_out;
+ goto err_remove_node;
}
ret = i915_gem_gtt_prepare_object(obj);
if (ret)
- goto err_out;
+ goto err_remove_node;
list_move_tail(obj-global_list, dev_priv-mm.bound_list);
list_add_tail(obj-mm_list, vm-inactive_list);
@@ -3167,9 +3167,11 @@ search_free:
i915_gem_verify_gtt(dev);
return 0;
-err_out:
+err_remove_node:
drm_mm_remove_node(vma-node);
+err_free_vma:
i915_gem_vma_destroy(vma);
+err_unpin:
i915_gem_object_unpin_pages(obj);
return ret;
}
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Queued for -next, thanks for the review.
So I think this bug here warrants a testcase in igt. I've expected
gem_tiled_blits/interruptible to hit this, but apparently it does not.
So what we want is to fail the drm_mm_insert_node_in_range_generic call
(with -ENOSPC) and then again fail the i915_gem_evict_something call with
an error. That should be simplest to achieve (and indeed does happen as
the bug indicates) when a blocking wait for the gpu to evict a buffer it's
still using.
Hence why I've thought that gem_tiled_blits/interruptible should hit this,
since it thrashes the gtt (so plenty of -ENOSPC) and has the 2nd thread
interrupting us running in parallel (so we should see the occasional
-ERESTARTSYS). But apparently the tuning is wrong for this case. I guess
cranking up the signal rate (we might need a real interface for that
anyway since the current value is the most the wait ioctl test can stomach
before failing). Or using much bigger objects to have more gtt contention
going on. I'd still only use the first fixed part to do blits, but add a
variable part at then end to mix up the gtt drm_mm as much as possible.
Ofc this should be a new subtest so that we don't reduce existing test
coverage.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/20] drm/gem: create drm_gem_dumb_destroy
Hi Daniel, Thanks for the patch. On Tuesday 16 July 2013 09:12:04 Daniel Vetter wrote: All the gem based kms drivers really want the same function to destroy a dumb framebuffer backing storage object. So give it to them and roll it out in all drivers. This still leaves the option open for kms drivers which don't use GEM for backing storage, but it does decently simplify matters for gem drivers. Cc: Inki Dae inki@samsung.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Intel Graphics Development intel-gfx@lists.freedesktop.org Cc: Ben Skeggs skeg...@gmail.com Cc: Rob Clark robdcl...@gmail.com Cc: Alex Deucher alexdeuc...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/gpu/drm/ast/ast_drv.c | 2 +- drivers/gpu/drm/ast/ast_drv.h | 3 --- drivers/gpu/drm/ast/ast_main.c| 7 --- drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +- drivers/gpu/drm/cirrus/cirrus_drv.h | 3 --- drivers/gpu/drm/cirrus/cirrus_main.c | 7 --- drivers/gpu/drm/drm_gem.c | 14 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 10 -- drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 20 drivers/gpu/drm/exynos/exynos_drm_gem.h | 9 - drivers/gpu/drm/gma500/gem.c | 17 - drivers/gpu/drm/gma500/psb_drv.c | 2 +- drivers/gpu/drm/gma500/psb_drv.h | 2 -- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 2 -- drivers/gpu/drm/i915/i915_gem.c | 7 --- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +- drivers/gpu/drm/mgag200/mgag200_drv.h | 3 --- drivers/gpu/drm/mgag200/mgag200_main.c| 7 --- drivers/gpu/drm/nouveau/nouveau_display.c | 7 --- drivers/gpu/drm/nouveau/nouveau_display.h | 2 -- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- drivers/gpu/drm/omapdrm/omap_drv.c| 2 +- drivers/gpu/drm/omapdrm/omap_drv.h| 2 -- drivers/gpu/drm/omapdrm/omap_gem.c| 15 --- drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/qxl/qxl_drv.h | 3 --- drivers/gpu/drm/qxl/qxl_dumb.c| 7 --- drivers/gpu/drm/radeon/radeon.h | 3 --- drivers/gpu/drm/radeon/radeon_drv.c | 5 + drivers/gpu/drm/radeon/radeon_gem.c | 7 --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.c | 2 +- drivers/gpu/drm/udl/udl_drv.h | 2 -- drivers/gpu/drm/udl/udl_gem.c | 6 -- drivers/gpu/host1x/drm/drm.c | 2 +- drivers/gpu/host1x/drm/gem.c | 6 -- drivers/gpu/host1x/drm/gem.h | 2 -- drivers/staging/imx-drm/imx-drm-core.c| 2 +- include/drm/drmP.h| 3 +++ include/drm/drm_gem_cma_helper.h | 8 44 files changed, 33 insertions(+), 186 deletions(-) -- Regards, Laurent Pinchart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/20] drm/gem: create drm_gem_dumb_destroy
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch]
Sent: Tuesday, July 16, 2013 4:12 PM
To: DRI Development
Cc: Daniel Vetter; Inki Dae; Laurent Pinchart; Intel Graphics Development;
Ben Skeggs; Rob Clark; Alex Deucher
Subject: [PATCH 13/20] drm/gem: create drm_gem_dumb_destroy
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Cc: Inki Dae inki@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Intel Graphics Development intel-gfx@lists.freedesktop.org
Cc: Ben Skeggs skeg...@gmail.com
Cc: Rob Clark robdcl...@gmail.com
Cc: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Inki Dae inki@samsung.com
Thanks,
Inki Dae
---
drivers/gpu/drm/ast/ast_drv.c | 2 +-
drivers/gpu/drm/ast/ast_drv.h | 3 ---
drivers/gpu/drm/ast/ast_main.c| 7 ---
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_drv.h | 3 ---
drivers/gpu/drm/cirrus/cirrus_main.c | 7 ---
drivers/gpu/drm/drm_gem.c | 14 ++
drivers/gpu/drm/drm_gem_cma_helper.c | 10 --
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 20
drivers/gpu/drm/exynos/exynos_drm_gem.h | 9 -
drivers/gpu/drm/gma500/gem.c | 17 -
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 2 --
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_gem.c | 7 ---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ---
drivers/gpu/drm/mgag200/mgag200_main.c| 7 ---
drivers/gpu/drm/nouveau/nouveau_display.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_display.h | 2 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.c| 2 +-
drivers/gpu/drm/omapdrm/omap_drv.h| 2 --
drivers/gpu/drm/omapdrm/omap_gem.c| 15 ---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
drivers/gpu/drm/qxl/qxl_dumb.c| 7 ---
drivers/gpu/drm/radeon/radeon.h | 3 ---
drivers/gpu/drm/radeon/radeon_drv.c | 5 +
drivers/gpu/drm/radeon/radeon_gem.c | 7 ---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.h | 2 --
drivers/gpu/drm/udl/udl_gem.c | 6 --
drivers/gpu/host1x/drm/drm.c | 2 +-
drivers/gpu/host1x/drm/gem.c | 6 --
drivers/gpu/host1x/drm/gem.h | 2 --
drivers/staging/imx-drm/imx-drm-core.c| 2 +-
include/drm/drmP.h| 3 +++
include/drm/drm_gem_cma_helper.h | 8
44 files changed, 33 insertions(+), 186 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index df0d0a0..a144fb0 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -216,7 +216,7 @@ static struct drm_driver driver = {
.gem_free_object = ast_gem_free_object,
.dumb_create = ast_dumb_create,
.dumb_map_offset = ast_dumb_mmap_offset,
- .dumb_destroy = ast_dumb_destroy,
+ .dumb_destroy = drm_gem_dumb_destroy,
};
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 622d4ae..796dbb2 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -322,9 +322,6 @@ ast_bo(struct ttm_buffer_object *bo)
extern int ast_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-extern int ast_dumb_destroy(struct drm_file *file,
- struct drm_device *dev,
- uint32_t handle);
extern int ast_gem_init_object(struct drm_gem_object *obj);
extern void ast_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/ast/ast_main.c
b/drivers/gpu/drm/ast/ast_main.c
index f60fd7b..0ef4228 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -449,13 +449,6 @@ int ast_dumb_create(struct drm_file *file,
return 0;
}
-int ast_dumb_destroy(struct drm_file *file,
- struct
Re: [Intel-gfx] i915 irq storm mitigation in 3.10
Hi Jan -
Jan Niggemann writes:
As to the log: I messed up the kernel parameters this morning... was
out of coffee this morning and my 1,5y daughter played around me :-)
Here's my kernel log with drm.debug and printk.time enabled:
Uncompressed (22M): http://files.hz6.de/kern_20130722.log
bzip2'd (some 600 KB): http://files.hz6.de/kern_20130722.log.bz2
I've looked at the logs a bit more. Here's a patch adding some more
debug information. Would you please apply this to your 3.10 kernel
and generate a log file the same way as you did before.
The driver will be even more chatty - but I don't expect any problems
from this.
Cheers,
Egbert.
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e43d809..46bb77c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -919,6 +919,11 @@ static inline void intel_hpd_irq_handler(struct drm_device
*dev,
spin_lock(dev_priv-irq_lock);
for (i = 1; i HPD_NUM_PINS; i++) {
+ if (IS_G4X(dev) (hpd[i] hotplug_trigger)
+ dev_priv-hpd_stats[i].hpd_mark != HPD_ENABLED)
+ DRM_DEBUG_KMS(Received HPD intterupt although
disabled\n,
+ I915_READ(PORT_HOTPLUG_EN));
+
if (!(hpd[i] hotplug_trigger) ||
dev_priv-hpd_stats[i].hpd_mark != HPD_ENABLED)
continue;
@@ -929,6 +934,8 @@ static inline void intel_hpd_irq_handler(struct drm_device
*dev,
+
msecs_to_jiffies(HPD_STORM_DETECT_PERIOD))) {
dev_priv-hpd_stats[i].hpd_last_jiffies = jiffies;
dev_priv-hpd_stats[i].hpd_cnt = 0;
+ DRM_DEBUG_KMS(Received HPD interrupt on PIN %d -
jiffies: %d\n, i,
+ dev_priv-hpd_stats[i].hpd_last_jiffies);
} else if (dev_priv-hpd_stats[i].hpd_cnt
HPD_STORM_THRESHOLD) {
dev_priv-hpd_stats[i].hpd_mark = HPD_MARK_DISABLED;
dev_priv-hpd_event_bits = ~(1 i);
@@ -936,6 +943,8 @@ static inline void intel_hpd_irq_handler(struct drm_device
*dev,
storm_detected = true;
} else {
dev_priv-hpd_stats[i].hpd_cnt++;
+ DRM_DEBUG_KMS(Received HPD interrupt on PIN %d - cnt:
%d\n, i,
+ dev_priv-hpd_stats[i].hpd_cnt);
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: update last_vblank when disabling the power well
From: Paulo Zanoni paulo.r.zan...@intel.com
The DRM layer keeps track of our vblanks and it assumes our vblank
counters only go back to zero when they overflow. The problem is that
when we disable the power well our counters also go to zero, but it
doesn't mean they did overflow. So on this patch we grab the lock and
update last_vblank so the DRM layer won't think our counters
overflowed.
This patch fixes the following intel-gpu-tools test:
./kms_flip --run-subtest blocking-absolute-wf_vblank
Regression introduced by the following commit:
commit bf51d5e2cda5d36d98e4b46ac7fca9461e512c41
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date: Wed Jul 3 17:12:13 2013 -0300
drm/i915: switch disable_power_well default value to 1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66808
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 13 +
1 file changed, 13 insertions(+)
Tested on -nightly, but applies cleanly to -fixes.
I recognize this patch is not really beautiful, I'm open to suggestions.
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 7643b16..d401783 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5060,8 +5060,21 @@ static void __intel_set_power_well(struct drm_device
*dev, bool enable)
}
} else {
if (enable_requested) {
+ unsigned long irqflags;
+ enum pipe p;
+
I915_WRITE(HSW_PWR_WELL_DRIVER, 0);
+ POSTING_READ(HSW_PWR_WELL_DRIVER);
DRM_DEBUG_KMS(Requesting to disable the power well\n);
+
+ /* After this, the registers on the pipes that are part
+* of the power well will become zero, so we have to
+* adjust our counters according to that. */
+ spin_lock_irqsave(dev-vbl_lock, irqflags);
+ for_each_pipe(p)
+ if (p != PIPE_A)
+ dev-last_vblank[p] = 0;
+ spin_unlock_irqrestore(dev-vbl_lock, irqflags);
}
}
}
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: extend lpt_enable_clkout_dp
From: Paulo Zanoni paulo.r.zan...@intel.com
Now it implements 3 different sequences from BSpec and also has
support for ULT.
v2: - Change IS_ULT checks for LPT-LP checks
- Add check for LPT-LP + with_fdi (Ben)
- Merge DBUFF0/GEN0 bit definitions since they're the same
register (Ben)
- DBUFF0 (10) is Disable, not Enable
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 43 +---
2 files changed, 32 insertions(+), 14 deletions(-)
Resending the remaining patches of this series on a separate thread, as
requested by Daniel.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e20f093..0dfcbad 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4942,7 +4942,8 @@
#define SBI_SSCAUXDIV60x0610
#define SBI_SSCAUXDIV_FINALDIV2SEL(x)((x)4)
#define SBI_DBUFF00x2a00
-#define SBI_DBUFF0_ENABLE(10)
+#define SBI_GEN0 0x1f00
+#define SBI_GEN0_CFG_BUFFENABLE_DISABLE (10)
/* LPT PIXCLK_GATE */
#define PIXCLK_GATE0xC6020
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 62c5ab9..7f61ac5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5260,11 +5260,23 @@ static void lpt_program_fdi_mphy(struct
drm_i915_private *dev_priv)
intel_sbi_write(dev_priv, 0x21EC, tmp, SBI_MPHY);
}
-/* Sequence to enable CLKOUT_DP for FDI usage and configure PCH FDI I/O. */
-static void lpt_enable_clkout_dp(struct drm_device *dev)
+/* Implements 3 different sequences from BSpec chapter Display iCLK
+ * Programming based on the parameters passed:
+ * - Sequence to enable CLKOUT_DP
+ * - Sequence to enable CLKOUT_DP without spread
+ * - Sequence to enable CLKOUT_DP for FDI usage and configure PCH FDI I/O
+ */
+static void lpt_enable_clkout_dp(struct drm_device *dev, bool with_spread,
+bool with_fdi)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- uint32_t tmp;
+ uint32_t reg, tmp;
+
+ if (WARN(with_fdi !with_spread, FDI requires downspread\n))
+ with_spread = true;
+ if (WARN(dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE
+with_fdi, LP PCH doesn't have FDI\n))
+ with_fdi = false;
mutex_lock(dev_priv-dpio_lock);
@@ -5275,17 +5287,22 @@ static void lpt_enable_clkout_dp(struct drm_device *dev)
udelay(24);
- tmp = intel_sbi_read(dev_priv, SBI_SSCCTL, SBI_ICLK);
- tmp = ~SBI_SSCCTL_PATHALT;
- intel_sbi_write(dev_priv, SBI_SSCCTL, tmp, SBI_ICLK);
+ if (with_spread) {
+ tmp = intel_sbi_read(dev_priv, SBI_SSCCTL, SBI_ICLK);
+ tmp = ~SBI_SSCCTL_PATHALT;
+ intel_sbi_write(dev_priv, SBI_SSCCTL, tmp, SBI_ICLK);
- lpt_reset_fdi_mphy(dev_priv);
- lpt_program_fdi_mphy(dev_priv);
+ if (with_fdi) {
+ lpt_reset_fdi_mphy(dev_priv);
+ lpt_program_fdi_mphy(dev_priv);
+ }
+ }
- /* ULT uses SBI_GEN0, but ULT doesn't have VGA, so we don't care. */
- tmp = intel_sbi_read(dev_priv, SBI_DBUFF0, SBI_ICLK);
- tmp |= SBI_DBUFF0_ENABLE;
- intel_sbi_write(dev_priv, SBI_DBUFF0, tmp, SBI_ICLK);
+ reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
+ SBI_GEN0 : SBI_DBUFF0;
+ tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
+ tmp |= SBI_GEN0_CFG_BUFFENABLE_DISABLE;
+ intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
mutex_unlock(dev_priv-dpio_lock);
}
@@ -5307,7 +5324,7 @@ static void lpt_init_pch_refclk(struct drm_device *dev)
if (!has_vga)
return;
- lpt_enable_clkout_dp(dev);
+ lpt_enable_clkout_dp(dev, true, true);
}
/*
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915: disable CLKOUT_DP when it's not needed
From: Paulo Zanoni paulo.r.zan...@intel.com
We currently don't support HDMI clock bending nor use SSC for DP or
HDMI on Haswell, so the only case where we need CLKOUT_DP is for VGA.
v2: - Replace the IS_ULT check for LPT-LP
- Simplify GEN0/DBUFF0 check due to change on the previous patch
- Also check for SBI_SSCCTL_DISABLE (Ben).
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 36
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7f61ac5..deee650d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5307,6 +5307,34 @@ static void lpt_enable_clkout_dp(struct drm_device *dev,
bool with_spread,
mutex_unlock(dev_priv-dpio_lock);
}
+/* Sequence to disable CLKOUT_DP */
+static void lpt_disable_clkout_dp(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t reg, tmp;
+
+ mutex_lock(dev_priv-dpio_lock);
+
+ reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
+ SBI_GEN0 : SBI_DBUFF0;
+ tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
+ tmp = ~SBI_GEN0_CFG_BUFFENABLE_DISABLE;
+ intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
+
+ tmp = intel_sbi_read(dev_priv, SBI_SSCCTL, SBI_ICLK);
+ if (!(tmp SBI_SSCCTL_DISABLE)) {
+ if (!(tmp SBI_SSCCTL_PATHALT)) {
+ tmp |= SBI_SSCCTL_PATHALT;
+ intel_sbi_write(dev_priv, SBI_SSCCTL, tmp, SBI_ICLK);
+ udelay(32);
+ }
+ tmp |= SBI_SSCCTL_DISABLE;
+ intel_sbi_write(dev_priv, SBI_SSCCTL, tmp, SBI_ICLK);
+ }
+
+ mutex_unlock(dev_priv-dpio_lock);
+}
+
static void lpt_init_pch_refclk(struct drm_device *dev)
{
struct drm_mode_config *mode_config = dev-mode_config;
@@ -5321,10 +5349,10 @@ static void lpt_init_pch_refclk(struct drm_device *dev)
}
}
- if (!has_vga)
- return;
-
- lpt_enable_clkout_dp(dev, true, true);
+ if (has_vga)
+ lpt_enable_clkout_dp(dev, true, true);
+ else
+ lpt_disable_clkout_dp(dev);
}
/*
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: add functions to disable and restore LCPLL
From: Paulo Zanoni paulo.r.zan...@intel.com
For now there are no callers, but these functions are going to be
needed for the code that allows Package C8+. Other future features may
also require this code.
Also merge the commit which introduced assert_can_disable_lcpll and
had the following commit message:
Most of the hardware needs to be disabled before LCPLL is disabled, so
let's add a function to assert some of items listed in the Display
Sequences for LCPLL disabling documentation.
The idea is that hsw_disable_lcpll should not disable the hardware,
the callers need to take care of calling hsw_disable_lcpll only once
everything is already disabled.
v2: - Rebase.
- Fix D_COMP wait timeout.
v3: - Use wait_for_atomic_use (Ben)
- Remove/add a useless/needed POSTING_READ (Ben)
- Early return in case LCPLL is already restored (Ben)
- Add ndelay(100) (Ben)
v4: - Merge the commit that added assert_can_disable_lcpll (Ben)
- Add interrupt assertions (Ben)
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 15
drivers/gpu/drm/i915/intel_display.c | 136 +++
drivers/gpu/drm/i915/intel_drv.h | 3 +
3 files changed, 154 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0dfcbad..6caa748 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2261,6 +2261,8 @@
#define BLC_PWM_CPU_CTL2 0x48250
#define BLC_PWM_CPU_CTL0x48254
+#define HSW_BLC_PWM2_CTL 0x48350
+
/* PCH CTL1 is totally different, all but the below bits are reserved. CTL2 is
* like the normal CTL from gen4 and earlier. Hooray for confusing naming. */
#define BLC_PWM_PCH_CTL1 0xc8250
@@ -2269,6 +2271,12 @@
#define BLM_PCH_POLARITY (1 29)
#define BLC_PWM_PCH_CTL2 0xc8254
+#define UTIL_PIN_CTL 0x48400
+#define UTIL_PIN_ENABLE (1 31)
+
+#define PCH_GTC_CTL0xe7000
+#define PCH_GTC_ENABLE (1 31)
+
/* TV port control */
#define TV_CTL 0x68000
/** Enables the TV encoder */
@@ -5009,7 +5017,14 @@
#define LCPLL_CLK_FREQ_450(026)
#define LCPLL_CD_CLOCK_DISABLE(125)
#define LCPLL_CD2X_CLOCK_DISABLE (123)
+#define LCPLL_POWER_DOWN_ALLOW(122)
#define LCPLL_CD_SOURCE_FCLK (121)
+#define LCPLL_CD_SOURCE_FCLK_DONE (119)
+
+#define D_COMP (MCHBAR_MIRROR_BASE_SNB + 0x5F0C)
+#define D_COMP_RCOMP_IN_PROGRESS (19)
+#define D_COMP_COMP_FORCE (18)
+#define D_COMP_COMP_DISABLE (10)
/* Pipe WM_LINETIME - watermark line time */
#define PIPE_WM_LINETIME_A 0x45270
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index deee650d..0b0696a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5922,6 +5922,142 @@ static bool ironlake_get_pipe_config(struct intel_crtc
*crtc,
return true;
}
+static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+ struct intel_ddi_plls *plls = dev_priv-ddi_plls;
+ struct intel_crtc *crtc;
+ unsigned long irqflags;
+ uint32_t val, pch_hpd_mask;
+
+ pch_hpd_mask = SDE_PORTB_HOTPLUG_CPT | SDE_PORTC_HOTPLUG_CPT;
+ if (!HAS_LP_PCH(dev_priv))
+ pch_hpd_mask |= SDE_PORTD_HOTPLUG_CPT | SDE_CRT_HOTPLUG_CPT;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head)
+ WARN(crtc-base.enabled, CRTC for pipe %c enabled\n,
+pipe_name(crtc-pipe));
+
+ WARN(I915_READ(HSW_PWR_WELL_DRIVER), Power well on\n);
+ WARN(plls-spll_refcount, SPLL enabled\n);
+ WARN(plls-wrpll1_refcount, WRPLL1 enabled\n);
+ WARN(plls-wrpll2_refcount, WRPLL2 enabled\n);
+ WARN(I915_READ(PCH_PP_STATUS) PP_ON, Panel power on\n);
+ WARN(I915_READ(BLC_PWM_CPU_CTL2) BLM_PWM_ENABLE,
+CPU PWM1 enabled\n);
+ WARN(I915_READ(HSW_BLC_PWM2_CTL) BLM_PWM_ENABLE,
+CPU PWM2 enabled\n);
+ WARN(I915_READ(BLC_PWM_PCH_CTL1) BLM_PCH_PWM_ENABLE,
+PCH PWM1 enabled\n);
+ WARN(I915_READ(UTIL_PIN_CTL) UTIL_PIN_ENABLE,
+Utility pin enabled\n);
+ WARN(I915_READ(PCH_GTC_CTL) PCH_GTC_ENABLE, PCH GTC enabled\n);
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ val = I915_READ(DEIMR);
+ WARN((val ~DE_PCH_EVENT_IVB) != val,
+Unexpected DEIMR bits enabled: 0x%x\n, val);
+ val = I915_READ(SDEIMR);
+ WARN((val ~pch_hpd_mask) != val,
+Unexpected SDEIMR bits enabled: 0x%x\n, val);
+ spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+}
+
+/*
+ * This function implements pieces of two sequences
Re: [Intel-gfx] [PATCH 4/4] drm/i915: add HAS_LP_PCH check
On Tue, Jul 23, 2013 at 11:19:27AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We have 2 possible LPT PCHs: the normal version, which contains the
pixel path (FDI, transcoders, VGA, etc), and the LP version, which
comes with ULT machines and doesn't contain the pixel path. Both
models return true for HAS_PCH_LPT.
We already have a few places where we explicitly check for LPT-LP, so
add a HAS_LP_PCH check to simplify the code.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Hm, I'm not that much convinced that this cleans up things: If we'll have
more LP versions in future generations then either the check will get ugly
or we have a bit a confusion. Since the scope of this chekc is fairly
restricted to a bit of reference clock handling I think we're ok.
One thing we could do is trim the giant suffix a bit, i.e.
s/INTEL_PCH_LPT_LP_DEVICE_ID_TYPE/INTEL_PCH_LPT_LP/. Since we're always
comparing that constant against a pciid or pch_id field it's still rather
clear what's going on. But like I've said, since this has fairly minimal
scope imo not really worth to make a fuss about.
So punted on this one here for now, but merged the other three patches
from this series.
Thanks, Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 9 +++--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8b3167e..713e7bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1575,6 +1575,8 @@ struct drm_i915_file_private {
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
#define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
#define HAS_PCH_SPLIT(dev) (INTEL_PCH_TYPE(dev) != PCH_NONE)
+#define HAS_LP_PCH(dev_priv) ((dev_priv)-pch_id == \
+ INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
#define HAS_FORCE_WAKE(dev) (INTEL_INFO(dev)-has_force_wake)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b0696a..04a4550 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5274,8 +5274,7 @@ static void lpt_enable_clkout_dp(struct drm_device
*dev, bool with_spread,
if (WARN(with_fdi !with_spread, FDI requires downspread\n))
with_spread = true;
- if (WARN(dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE
- with_fdi, LP PCH doesn't have FDI\n))
+ if (WARN(HAS_LP_PCH(dev_priv) with_fdi, LP PCH doesn't have FDI\n))
with_fdi = false;
mutex_lock(dev_priv-dpio_lock);
@@ -5298,8 +5297,7 @@ static void lpt_enable_clkout_dp(struct drm_device
*dev, bool with_spread,
}
}
- reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
-SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_LP_PCH(dev_priv) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp |= SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
@@ -5315,8 +5313,7 @@ static void lpt_disable_clkout_dp(struct drm_device
*dev)
mutex_lock(dev_priv-dpio_lock);
- reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
-SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_LP_PCH(dev_priv) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp = ~SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 008e0e0..545d4ac 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4650,7 +4650,7 @@ static void lpt_init_clock_gating(struct drm_device
*dev)
* TODO: this bit should only be enabled when really needed, then
* disabled when not needed anymore in order to save power.
*/
- if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
+ if (HAS_LP_PCH(dev_priv))
I915_WRITE(SOUTH_DSPCLK_GATE_D,
I915_READ(SOUTH_DSPCLK_GATE_D) |
PCH_LP_PARTITION_LEVEL_DISABLE);
@@ -4665,7 +4665,7 @@ static void lpt_suspend_hw(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_LP_PCH(dev_priv)) {
uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH 3/4] drm/i915: add functions to disable and restore LCPLL
On Tue, Jul 23, 2013 at 11:19:26AM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
For now there are no callers, but these functions are going to be
needed for the code that allows Package C8+. Other future features may
also require this code.
Also merge the commit which introduced assert_can_disable_lcpll and
had the following commit message:
Most of the hardware needs to be disabled before LCPLL is disabled, so
let's add a function to assert some of items listed in the Display
Sequences for LCPLL disabling documentation.
The idea is that hsw_disable_lcpll should not disable the hardware,
the callers need to take care of calling hsw_disable_lcpll only once
everything is already disabled.
v2: - Rebase.
- Fix D_COMP wait timeout.
v3: - Use wait_for_atomic_use (Ben)
- Remove/add a useless/needed POSTING_READ (Ben)
- Early return in case LCPLL is already restored (Ben)
- Add ndelay(100) (Ben)
v4: - Merge the commit that added assert_can_disable_lcpll (Ben)
- Add interrupt assertions (Ben)
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 15
drivers/gpu/drm/i915/intel_display.c | 136
+++
drivers/gpu/drm/i915/intel_drv.h | 3 +
3 files changed, 154 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0dfcbad..6caa748 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2261,6 +2261,8 @@
#define BLC_PWM_CPU_CTL2 0x48250
#define BLC_PWM_CPU_CTL 0x48254
+#define HSW_BLC_PWM2_CTL 0x48350
+
/* PCH CTL1 is totally different, all but the below bits are reserved. CTL2
is
* like the normal CTL from gen4 and earlier. Hooray for confusing naming. */
#define BLC_PWM_PCH_CTL1 0xc8250
@@ -2269,6 +2271,12 @@
#define BLM_PCH_POLARITY (1 29)
#define BLC_PWM_PCH_CTL2 0xc8254
+#define UTIL_PIN_CTL 0x48400
+#define UTIL_PIN_ENABLE(1 31)
+
+#define PCH_GTC_CTL 0xe7000
+#define PCH_GTC_ENABLE (1 31)
+
/* TV port control */
#define TV_CTL 0x68000
/** Enables the TV encoder */
@@ -5009,7 +5017,14 @@
#define LCPLL_CLK_FREQ_450 (026)
#define LCPLL_CD_CLOCK_DISABLE (125)
#define LCPLL_CD2X_CLOCK_DISABLE(123)
+#define LCPLL_POWER_DOWN_ALLOW (122)
#define LCPLL_CD_SOURCE_FCLK(121)
+#define LCPLL_CD_SOURCE_FCLK_DONE (119)
+
+#define D_COMP (MCHBAR_MIRROR_BASE_SNB +
0x5F0C)
+#define D_COMP_RCOMP_IN_PROGRESS(19)
+#define D_COMP_COMP_FORCE (18)
+#define D_COMP_COMP_DISABLE (10)
/* Pipe WM_LINETIME - watermark line time */
#define PIPE_WM_LINETIME_A 0x45270
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index deee650d..0b0696a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5922,6 +5922,142 @@ static bool ironlake_get_pipe_config(struct
intel_crtc *crtc,
return true;
}
+static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+ struct intel_ddi_plls *plls = dev_priv-ddi_plls;
+ struct intel_crtc *crtc;
+ unsigned long irqflags;
+ uint32_t val, pch_hpd_mask;
+
+ pch_hpd_mask = SDE_PORTB_HOTPLUG_CPT | SDE_PORTC_HOTPLUG_CPT;
+ if (!HAS_LP_PCH(dev_priv))
This didn't compile, I've fixed it up.
-Daniel
+ pch_hpd_mask |= SDE_PORTD_HOTPLUG_CPT | SDE_CRT_HOTPLUG_CPT;
+
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head)
+ WARN(crtc-base.enabled, CRTC for pipe %c enabled\n,
+ pipe_name(crtc-pipe));
+
+ WARN(I915_READ(HSW_PWR_WELL_DRIVER), Power well on\n);
+ WARN(plls-spll_refcount, SPLL enabled\n);
+ WARN(plls-wrpll1_refcount, WRPLL1 enabled\n);
+ WARN(plls-wrpll2_refcount, WRPLL2 enabled\n);
+ WARN(I915_READ(PCH_PP_STATUS) PP_ON, Panel power on\n);
+ WARN(I915_READ(BLC_PWM_CPU_CTL2) BLM_PWM_ENABLE,
+ CPU PWM1 enabled\n);
+ WARN(I915_READ(HSW_BLC_PWM2_CTL) BLM_PWM_ENABLE,
+ CPU PWM2 enabled\n);
+ WARN(I915_READ(BLC_PWM_PCH_CTL1) BLM_PCH_PWM_ENABLE,
+ PCH PWM1 enabled\n);
+ WARN(I915_READ(UTIL_PIN_CTL) UTIL_PIN_ENABLE,
+ Utility pin enabled\n);
+ WARN(I915_READ(PCH_GTC_CTL) PCH_GTC_ENABLE, PCH GTC enabled\n);
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ val = I915_READ(DEIMR);
+ WARN((val ~DE_PCH_EVENT_IVB) != val,
+ Unexpected DEIMR bits enabled: 0x%x\n, val);
+ val = I915_READ(SDEIMR);
+ WARN((val ~pch_hpd_mask) != val,
+ Unexpected SDEIMR
Re: [Intel-gfx] i915 irq storm mitigation in 3.10
Egbert, Daniel, others, Am 22.07.2013 10:04, schrieb Egbert Eich: Daniel Vetter writes: On Sun, Jul 21, 2013 at 10:23 PM, Jan Niggemann j...@hz6.de wrote: But every time this happens we only let through a few interrupts, so this shouldn't affect you badly. Can you please check whether those slowdowns line up with 2 minute intervalls? I observed these slowdowns for a couple of weeks now. On my machine, they only happen once, some minutes after a cold boot. They last for a minute or two, and then they are gone. I'd have guessed that the storm detection kicks in pretty quickly after a storm is detected and that it would go unnoticed. Hm, that sounds like something doesn't quite work as expected. We should kill things once we get 5 interrupts or so in 1 second. So if it's bad enough that it slows your machine down it really should only be barely noticeable. The logs show that the disable mechanism got triggered, so there was a storm that got detected. The respective message is generated by the worker, everything up to there (detection and marking disabled) seems to be fine. I bet we are still getting interrupts but the respective bit in hpd_event_bits doesn't get set any more. Since we unconditionally queue the worker on interrupt there is surprise it is so busy. Then this points to the call to hpd_irq_setup() in intel_hpd_irq_handler() not doing what is expected, ie masking out the stormy interrupt. Could it be that we can't mask/disable an interrupt before ACKing it? @Jan, could you also specify what hardware you are using (ie give us an output of lspci -n)? It's a Lenovo ThinkPad T400, the model is 7434-AG2. root@muretop:~# lspci -n 00:00.0 0600: 8086:2a40 (rev 07) 00:02.0 0300: 8086:2a42 (rev 07) 00:02.1 0380: 8086:2a43 (rev 07) 00:03.0 0780: 8086:2a44 (rev 07) 00:19.0 0200: 8086:10f5 (rev 03) 00:1a.0 0c03: 8086:2937 (rev 03) 00:1a.1 0c03: 8086:2938 (rev 03) 00:1a.2 0c03: 8086:2939 (rev 03) 00:1a.7 0c03: 8086:293c (rev 03) 00:1b.0 0403: 8086:293e (rev 03) 00:1c.0 0604: 8086:2940 (rev 03) 00:1c.1 0604: 8086:2942 (rev 03) 00:1c.3 0604: 8086:2946 (rev 03) 00:1c.4 0604: 8086:2948 (rev 03) 00:1d.0 0c03: 8086:2934 (rev 03) 00:1d.1 0c03: 8086:2935 (rev 03) 00:1d.2 0c03: 8086:2936 (rev 03) 00:1d.7 0c03: 8086:293a (rev 03) 00:1e.0 0604: 8086:2448 (rev 93) 00:1f.0 0601: 8086:2917 (rev 03) 00:1f.2 0106: 8086:2929 (rev 03) 00:1f.3 0c05: 8086:2930 (rev 03) 03:00.0 0280: 8086:4237 15:00.0 0607: 1180:0476 (rev ba) As to the log: I messed up the kernel parameters this morning... was out of coffee this morning and my 1,5y daughter played around me :-) Here's my kernel log with drm.debug and printk.time enabled: Uncompressed (22M): http://files.hz6.de/kern_20130722.log bzip2'd (some 600 KB): http://files.hz6.de/kern_20130722.log.bz2 Regards jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/20] drm/gem: create drm_gem_dumb_destroy
On Tue, Jul 16, 2013 at 3:12 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
All the gem based kms drivers really want the same function to
destroy a dumb framebuffer backing storage object.
So give it to them and roll it out in all drivers.
This still leaves the option open for kms drivers which don't use GEM
for backing storage, but it does decently simplify matters for gem
drivers.
Cc: Inki Dae inki@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Intel Graphics Development intel-gfx@lists.freedesktop.org
Cc: Ben Skeggs skeg...@gmail.com
Cc: Rob Clark robdcl...@gmail.com
Cc: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/ast/ast_drv.c | 2 +-
drivers/gpu/drm/ast/ast_drv.h | 3 ---
drivers/gpu/drm/ast/ast_main.c| 7 ---
drivers/gpu/drm/cirrus/cirrus_drv.c | 2 +-
drivers/gpu/drm/cirrus/cirrus_drv.h | 3 ---
drivers/gpu/drm/cirrus/cirrus_main.c | 7 ---
drivers/gpu/drm/drm_gem.c | 14 ++
drivers/gpu/drm/drm_gem_cma_helper.c | 10 --
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 20
drivers/gpu/drm/exynos/exynos_drm_gem.h | 9 -
drivers/gpu/drm/gma500/gem.c | 17 -
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
drivers/gpu/drm/gma500/psb_drv.h | 2 --
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 --
drivers/gpu/drm/i915/i915_gem.c | 7 ---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ---
drivers/gpu/drm/mgag200/mgag200_main.c| 7 ---
drivers/gpu/drm/nouveau/nouveau_display.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_display.h | 2 --
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/omapdrm/omap_drv.c| 2 +-
drivers/gpu/drm/omapdrm/omap_drv.h| 2 --
drivers/gpu/drm/omapdrm/omap_gem.c| 15 ---
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 3 ---
drivers/gpu/drm/qxl/qxl_dumb.c| 7 ---
drivers/gpu/drm/radeon/radeon.h | 3 ---
drivers/gpu/drm/radeon/radeon_drv.c | 5 +
drivers/gpu/drm/radeon/radeon_gem.c | 7 ---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.c | 2 +-
drivers/gpu/drm/udl/udl_drv.h | 2 --
drivers/gpu/drm/udl/udl_gem.c | 6 --
drivers/gpu/host1x/drm/drm.c | 2 +-
drivers/gpu/host1x/drm/gem.c | 6 --
drivers/gpu/host1x/drm/gem.h | 2 --
drivers/staging/imx-drm/imx-drm-core.c| 2 +-
include/drm/drmP.h| 3 +++
include/drm/drm_gem_cma_helper.h | 8
44 files changed, 33 insertions(+), 186 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index df0d0a0..a144fb0 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -216,7 +216,7 @@ static struct drm_driver driver = {
.gem_free_object = ast_gem_free_object,
.dumb_create = ast_dumb_create,
.dumb_map_offset = ast_dumb_mmap_offset,
- .dumb_destroy = ast_dumb_destroy,
+ .dumb_destroy = drm_gem_dumb_destroy,
};
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 622d4ae..796dbb2 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -322,9 +322,6 @@ ast_bo(struct ttm_buffer_object *bo)
extern int ast_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
-extern int ast_dumb_destroy(struct drm_file *file,
- struct drm_device *dev,
- uint32_t handle);
extern int ast_gem_init_object(struct drm_gem_object *obj);
extern void ast_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f60fd7b..0ef4228 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -449,13 +449,6 @@ int ast_dumb_create(struct drm_file *file,
return 0;
}
-int ast_dumb_destroy(struct drm_file *file,
-struct drm_device *dev,
-uint32_t handle)
-{
- return drm_gem_handle_delete(file, handle);
-}
-
int ast_gem_init_object(struct drm_gem_object *obj)
{
BUG();
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Fix up map and fenceable for VMA
On Sun, Jul 21, 2013 at 07:08:09PM -0700, Ben Widawsky wrote:
formerly: drm/i915: Create VMAs (part 3.5) - map and fenceable
tracking
The map_and_fenceable tracking is per object. GTT mapping, and fences
only apply to global GTT. As such, object operations which are not
performed on the global GTT should not effect mappable or fenceable
characteristics.
Functionally, this commit could very well be squashed in to the previous
patch which updated object operations to take a VM argument. This
commit is split out because it's a bit tricky (or at least it was for
me).
Signed-off-by: Ben Widawsky b...@bwidawsk.net
On a quick read there seems to be lots of stuff in here which belongs into
other patches, like error handling changes, debugfs changes. At least
since you claim that the mappable/fenceable stuff is tricky it seems to
not stick out that much ...
---
drivers/gpu/drm/i915/i915_debugfs.c| 53
++
drivers/gpu/drm/i915/i915_drv.h| 5 ++--
drivers/gpu/drm/i915/i915_gem.c| 43 +--
drivers/gpu/drm/i915/i915_gem_evict.c | 14 -
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 37 ++--
6 files changed, 93 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f8e590f..0b7df6c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -144,7 +144,7 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct i915_address_space *vm = dev_priv-gtt.base;
- struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
size_t total_obj_size, total_gtt_size;
int count, ret;
@@ -152,6 +152,7 @@ static int i915_gem_object_list_info(struct seq_file *m,
void *data)
if (ret)
return ret;
+ /* FIXME: the user of this interface might want more than just GGTT */
switch (list) {
case ACTIVE_LIST:
seq_puts(m, Active:\n);
@@ -167,12 +168,12 @@ static int i915_gem_object_list_info(struct seq_file
*m, void *data)
}
total_obj_size = total_gtt_size = count = 0;
- list_for_each_entry(obj, head, mm_list) {
- seq_puts(m,);
- describe_obj(m, obj);
- seq_putc(m, '\n');
- total_obj_size += obj-base.size;
- total_gtt_size += i915_gem_obj_ggtt_size(obj);
+ list_for_each_entry(vma, head, mm_list) {
+ seq_printf(m,);
+ describe_obj(m, vma-obj);
+ seq_printf(m, \n);
+ total_obj_size += vma-obj-base.size;
+ total_gtt_size += i915_gem_obj_size(vma-obj, vma-vm);
count++;
}
mutex_unlock(dev-struct_mutex);
@@ -220,7 +221,18 @@ static int per_file_stats(int id, void *ptr, void *data)
return 0;
}
-static int i915_gem_object_info(struct seq_file *m, void *data)
+#define count_vmas(list, member) do { \
+ list_for_each_entry(vma, list, member) { \
+ size += i915_gem_obj_ggtt_size(vma-obj); \
+ ++count; \
+ if (vma-obj-map_and_fenceable) { \
+ mappable_size += i915_gem_obj_ggtt_size(vma-obj); \
+ ++mappable_count; \
+ } \
+ } \
+} while (0)
+
+static int i915_gem_object_info(struct seq_file *m, void* data)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
struct drm_device *dev = node-minor-dev;
@@ -230,6 +242,7 @@ static int i915_gem_object_info(struct seq_file *m, void
*data)
struct drm_i915_gem_object *obj;
struct i915_address_space *vm = dev_priv-gtt.base;
struct drm_file *file;
+ struct i915_vma *vma;
int ret;
ret = mutex_lock_interruptible(dev-struct_mutex);
@@ -249,12 +262,12 @@ static int i915_gem_object_info(struct seq_file *m,
void *data)
count, mappable_count, size, mappable_size);
size = count = mappable_size = mappable_count = 0;
- count_objects(vm-active_list, mm_list);
+ count_vmas(vm-active_list, mm_list);
seq_printf(m, %u [%u] active objects, %zu [%zu] bytes\n,
count, mappable_count, size, mappable_size);
size = count = mappable_size = mappable_count = 0;
- count_objects(vm-inactive_list, mm_list);
+ count_vmas(vm-inactive_list, mm_list);
seq_printf(m, %u [%u] inactive objects, %zu [%zu] bytes\n,
count, mappable_count, size, mappable_size);
@@ -1767,7 +1780,8 @@ i915_drop_caches_set(void *data, u64 val)
struct drm_device *dev = data;
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_i915_gem_object
Re: [Intel-gfx] [PATCH 04/12] drm/i915: Track active by VMA instead of object
On Sun, Jul 21, 2013 at 07:08:11PM -0700, Ben Widawsky wrote:
Even though we want to be able to track active by VMA, the rest of the
code is still using objects for most internal APIs. To solve this,
create an object_is_active() function to help us in converting over to
VMA usage.
Because we intend to keep around some functions that care about objects,
and not VMAs, having this function around will be useful even as we
begin to use VMAs more in function arguments.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Still not really convinced. For access synchronization we don't care
through which vm a bo is still access, only how (read/write) and when was
the last access (ring + seqno).
Note that this means that the per-vm lru doesn't really need an
active/inactive split anymore, for evict_something we only care about the
ordering and not whether a bo is active or not. unbind() will care but I'm
not sure that the same bo in multiple address spaces needs to be evicted
use-case is something we even should care about.
So imo this commit needs a good justificatio for _why_ we want to track
active per-vma. Atm I don't see a use-case, but I see complexity.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h| 15 +++
drivers/gpu/drm/i915/i915_gem.c| 64
++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
3 files changed, 48 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f809204..bdce9c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -541,6 +541,13 @@ struct i915_vma {
struct drm_i915_gem_object *obj;
struct i915_address_space *vm;
+ /**
+ * This is set if the object is on the active lists (has pending
+ * rendering and so a non-zero seqno), and is not set if it i s on
+ * inactive (ready to be unbound) list.
+ */
+ unsigned int active:1;
+
/** This object's place on the active/inactive lists */
struct list_head mm_list;
@@ -1266,13 +1273,6 @@ struct drm_i915_gem_object {
struct list_head exec_list;
/**
- * This is set if the object is on the active lists (has pending
- * rendering and so a non-zero seqno), and is not set if it i s on
- * inactive (ready to be unbound) list.
- */
- unsigned int active:1;
-
- /**
* This is set if the object has been written to since last bound
* to the GTT
*/
@@ -1726,6 +1726,7 @@ static inline void i915_gem_object_unpin_pages(struct
drm_i915_gem_object *obj)
int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
int i915_gem_object_sync(struct drm_i915_gem_object *obj,
struct intel_ring_buffer *to);
+bool i915_gem_object_is_active(struct drm_i915_gem_object *obj);
void i915_gem_object_move_to_active(struct drm_i915_gem_object *obj,
struct i915_address_space *vm,
struct intel_ring_buffer *ring);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6bdf89d..9ea6424 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -119,10 +119,22 @@ int i915_mutex_lock_interruptible(struct drm_device
*dev)
return 0;
}
+/* NB: Not the same as !i915_gem_object_is_inactive */
+bool i915_gem_object_is_active(struct drm_i915_gem_object *obj)
+{
+ struct i915_vma *vma;
+
+ list_for_each_entry(vma, obj-vma_list, vma_link)
+ if (vma-active)
+ return true;
+
+ return false;
+}
+
static inline bool
i915_gem_object_is_inactive(struct drm_i915_gem_object *obj)
{
- return i915_gem_obj_bound_any(obj) !obj-active;
+ return i915_gem_obj_bound_any(obj) !i915_gem_object_is_active(obj);
}
int
@@ -1883,14 +1895,14 @@ i915_gem_object_move_to_active(struct
drm_i915_gem_object *obj,
}
obj-ring = ring;
+ /* Move from whatever list we were on to the tail of execution. */
+ vma = i915_gem_obj_to_vma(obj, vm);
/* Add a reference if we're newly entering the active list. */
- if (!obj-active) {
+ if (!vma-active) {
drm_gem_object_reference(obj-base);
- obj-active = 1;
+ vma-active = 1;
}
- /* Move from whatever list we were on to the tail of execution. */
- vma = i915_gem_obj_to_vma(obj, vm);
list_move_tail(vma-mm_list, vm-active_list);
list_move_tail(obj-ring_list, ring-active_list);
@@ -1911,16 +1923,23 @@ i915_gem_object_move_to_active(struct
drm_i915_gem_object *obj,
}
static void
-i915_gem_object_move_to_inactive(struct drm_i915_gem_object *obj,
- struct i915_address_space *vm)
+i915_gem_object_move_to_inactive(struct drm_i915_gem_object *obj)
{
+
Re: [Intel-gfx] [PATCH 07/12] drm/i915: eliminate vm-insert_entries()
On Sun, Jul 21, 2013 at 07:08:14PM -0700, Ben Widawsky wrote:
With bind/unbind function pointers in place, we no longer need
insert_entries. We could, and want, to remove clear_range, however it's
not totally easy at this point. Since it's used in a couple of place
still that don't only deal in objects: setup, ppgtt init, and restore
gtt mappings.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Oh, -insert_entries has become defunct in the previous patches. I didn't
spot this ... Not great for rebasing -internal since such changes pretty
much guarantee that I botch the rebase. And I think we want to keep these
interfaces here.
-Daniel
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1de49a0..5c04887 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -315,7 +315,6 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-base.unmap_vma = NULL;
ppgtt-base.clear_range = gen6_ppgtt_clear_range;
ppgtt-base.map_vma = NULL;
- ppgtt-base.insert_entries = gen6_ppgtt_insert_entries;
ppgtt-base.cleanup = gen6_ppgtt_cleanup;
ppgtt-base.scratch = dev_priv-gtt.base.scratch;
ppgtt-pt_pages = kzalloc(sizeof(struct page *)*ppgtt-num_pd_entries,
@@ -570,19 +569,6 @@ static void gen6_ggtt_clear_range(struct
i915_address_space *vm,
readl(gtt_base);
}
-
-static void i915_ggtt_insert_entries(struct i915_address_space *vm,
- struct sg_table *st,
- unsigned int pg_start,
- enum i915_cache_level cache_level)
-{
- unsigned int flags = (cache_level == I915_CACHE_NONE) ?
- AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
-
- intel_gtt_insert_sg_entries(st, pg_start, flags);
-
-}
-
static void i915_ggtt_map_vma(struct i915_vma *vma,
enum i915_cache_level cache_level,
u32 unused)
@@ -895,7 +881,6 @@ static int gen6_gmch_probe(struct drm_device *dev,
dev_priv-gtt.base.clear_range = gen6_ggtt_clear_range;
dev_priv-gtt.base.unmap_vma = gen6_ggtt_unmap_vma;
- dev_priv-gtt.base.insert_entries = gen6_ggtt_insert_entries;
dev_priv-gtt.base.map_vma = gen6_ggtt_map_vma;
return ret;
@@ -929,7 +914,6 @@ static int i915_gmch_probe(struct drm_device *dev,
dev_priv-gtt.do_idle_maps = needs_idle_maps(dev_priv-dev);
dev_priv-gtt.base.clear_range = i915_ggtt_clear_range;
dev_priv-gtt.base.unmap_vma = i915_ggtt_unmap_vma;
- dev_priv-gtt.base.insert_entries = i915_ggtt_insert_entries;
dev_priv-gtt.base.map_vma = i915_ggtt_map_vma;
return 0;
--
1.8.3.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Convert object coloring to VMA
On Sun, Jul 21, 2013 at 07:08:18PM -0700, Ben Widawsky wrote:
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Oh, here's the patch I've been looking for in patch 1 ;-)
I think if you split up patch 1 into different pieces _without_ changing
anything in the aggregate diff (see my little howto on our internal wiki)
then I guess I can be appeased to merge stuff as-is, or suggest to squash
in individual fixups like this one here.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h | 3 ---
drivers/gpu/drm/i915/i915_gem.c | 18 +-
2 files changed, 1 insertion(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe41a3d..2b4f30c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1864,9 +1864,6 @@ bool i915_gem_obj_bound(struct drm_i915_gem_object *o,
struct i915_address_space *vm);
unsigned long i915_gem_obj_size(struct drm_i915_gem_object *o,
struct i915_address_space *vm);
-void i915_gem_obj_set_color(struct drm_i915_gem_object *o,
- struct i915_address_space *vm,
- enum i915_cache_level color);
struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
struct i915_address_space *vm);
struct i915_vma *
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 397a4b4..e038709 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3394,7 +3394,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
}
vm-map_vma(vma, cache_level, 0);
- i915_gem_obj_set_color(obj, vm, cache_level);
+ vma-node.color = cache_level;
}
if (cache_level == I915_CACHE_NONE) {
@@ -4800,22 +4800,6 @@ unsigned long i915_gem_obj_size(struct
drm_i915_gem_object *o,
return 0;
}
-void i915_gem_obj_set_color(struct drm_i915_gem_object *o,
- struct i915_address_space *vm,
- enum i915_cache_level color)
-{
- struct i915_vma *vma;
- BUG_ON(list_empty(o-vma_list));
- list_for_each_entry(vma, o-vma_list, vma_link) {
- if (vma-vm == vm) {
- vma-node.color = color;
- return;
- }
- }
-
- WARN(1, Couldn't set color for VM %p\n, vm);
-}
-
struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
--
1.8.3.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: disable stolen mem for OVERLAY_NEEDS_PHYSICAL
Our phys_object code can't deal with stolen memory and so blows up. Fixing this is quite a bit of work and not worth it much for a single page object, so just opt-out. This is necessary prep work to enable stolen on gen2/3 platforms where the overlay register file isn't stored in the gtt. Cc: Chris Wilson ch...@chris-wilson.co.uk Acked-by: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_overlay.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c index 2abb53e..9ec5a4e 100644 --- a/drivers/gpu/drm/i915/intel_overlay.c +++ b/drivers/gpu/drm/i915/intel_overlay.c @@ -1333,7 +1333,9 @@ void intel_setup_overlay(struct drm_device *dev) overlay-dev = dev; - reg_bo = i915_gem_object_create_stolen(dev, PAGE_SIZE); + reg_bo = NULL; + if (!OVERLAY_NEEDS_PHYSICAL(dev)) + reg_bo = i915_gem_object_create_stolen(dev, PAGE_SIZE); if (reg_bo == NULL) reg_bo = i915_gem_alloc_object(dev, PAGE_SIZE); if (reg_bo == NULL) -- 1.8.3.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use Graphics Base of Stolen Memory on all gen3+
On Thu, Jul 04, 2013 at 12:23:33AM +0100, Chris Wilson wrote: So I made the mistake of missing that the desktop and mobile chipsets have different layouts in their PCI configurations, and we were incorrectly setting the wrong physical address for stolen memory on mobile chipsets. Since all gen3+ are actually consistent in the location of the GBSM register in the PCI configuration space on device 2 (the GPU), use it. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: sta...@vger.kernel.org Ok, with the quick overlay ducttape I've just submitted this should be safe. Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/12] drm/i915: Fix up map and fenceable for VMA
On Tue, Jul 23, 2013 at 06:42:35PM +0200, Daniel Vetter wrote: On Sun, Jul 21, 2013 at 07:08:09PM -0700, Ben Widawsky wrote: formerly: drm/i915: Create VMAs (part 3.5) - map and fenceable tracking The map_and_fenceable tracking is per object. GTT mapping, and fences only apply to global GTT. As such, object operations which are not performed on the global GTT should not effect mappable or fenceable characteristics. Functionally, this commit could very well be squashed in to the previous patch which updated object operations to take a VM argument. This commit is split out because it's a bit tricky (or at least it was for me). Signed-off-by: Ben Widawsky b...@bwidawsk.net On a quick read there seems to be lots of stuff in here which belongs into other patches, like error handling changes, debugfs changes. At least since you claim that the mappable/fenceable stuff is tricky it seems to not stick out that much ... Yep. I can't remember if I intentionally squashed this, and didn't update the commit, or accidentally squashed it. In either case, you're right. -- 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 2/2] drm/i915: use devm_request_mem_region_ram() for i915 stolen reservations
Since this is actual RAM space we can clobber any padding intended to
prevent MMIO allocations in this space.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_gem_stolen.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 5c1a535..e057649 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -97,8 +97,9 @@ static unsigned long i915_stolen_to_physical(struct
drm_device *dev)
* kernel. So if the region is already marked as busy, something
* is seriously wrong.
*/
- r = devm_request_mem_region(dev-dev, base, dev_priv-gtt.stolen_size,
- Graphics Stolen Memory);
+ r = devm_request_mem_region_ram(dev-dev, base,
+ dev_priv-gtt.stolen_size,
+ Graphics Stolen Memory);
if (r == NULL) {
DRM_ERROR(conflict detected with stolen region: [0x%08x -
0x%08x]\n,
base, base + (uint32_t)dev_priv-gtt.stolen_size);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] resource: add devm_request_mem_region_ram() for reserving RAM regions
Early x86 code reserves a buffer called RAM buffer to prevent MMIO
reservations from landing on top of potential RAM space, which can fail
due to decode priority in the chipset.
However, some drivers need to reserve RAM regions that may overlap the
padding, and may not be described in the E820 map (like the i915
driver). So add a new entry point to allow this, that will shrink the
RAM buffer padding if needed.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
include/linux/ioport.h |6
kernel/resource.c | 75
2 files changed, 81 insertions(+)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 89b7c24..f44a4ad 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -209,11 +209,17 @@ struct device;
__devm_request_region(dev, ioport_resource, (start), (n), (name))
#define devm_request_mem_region(dev,start,n,name) \
__devm_request_region(dev, iomem_resource, (start), (n), (name))
+#define devm_request_mem_region_ram(dev,start,n,name) \
+ __devm_request_region_ram(dev, iomem_resource, (start), (n), (name))
extern struct resource * __devm_request_region(struct device *dev,
struct resource *parent, resource_size_t start,
resource_size_t n, const char *name);
+extern struct resource * __devm_request_region_ram(struct device *dev,
+ struct resource *parent, resource_size_t start,
+ resource_size_t n, const char *name);
+
#define devm_release_region(dev, start, n) \
__devm_release_region(dev, ioport_resource, (start), (n))
#define devm_release_mem_region(dev, start, n) \
diff --git a/kernel/resource.c b/kernel/resource.c
index 3f285dc..d8f8783 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1216,6 +1216,81 @@ struct resource * __devm_request_region(struct device
*dev,
}
EXPORT_SYMBOL(__devm_request_region);
+/* Same as above, but conflicts with RAM buffer are ok */
+struct resource * __devm_request_region_ram(struct device *dev,
+ struct resource *parent, resource_size_t start,
+ resource_size_t n, const char *name)
+{
+ struct region_devres *dr = NULL;
+ struct resource *res;
+
+ dr = devres_alloc(devm_region_release, sizeof(struct region_devres),
+ GFP_KERNEL);
+ if (!dr)
+ return NULL;
+
+ dr-parent = parent;
+ dr-start = start;
+ dr-n = n;
+
+ res = __request_region(parent, start, n, name, 0);
+ if (res) {
+ goto out;
+ } else {
+ struct resource *conflict;
+
+ res = alloc_resource(GFP_ATOMIC);
+ if (!res)
+ goto fail;
+
+ res-name = name;
+ res-start = start;
+ res-end = start + n;
+ res-flags = IORESOURCE_BUSY;
+
+ conflict = request_resource_conflict(parent, res);
+ if (!conflict)
+ goto out;
+
+ if (strcmp(conflict-name, RAM buffer))
+ goto fail_free;
+
+ if (conflict-start = res-start
+ conflict-end = res-end) {
+ resource_size_t new_size;
+
+ new_size = res-start - conflict-start;
+ adjust_resource(conflict, conflict-start, new_size);
+ } else if (conflict-start = res-start
+ conflict-end = res-end) {
+ resource_size_t new_size;
+
+ new_size = conflict-end - res-end;
+ adjust_resource(conflict, res-start, new_size);
+ }
+
+ conflict = request_resource_conflict(parent, res);
+ if (!conflict)
+ goto out;
+ else {
+ dev_err(failed to adjust RAM buffer for %s\n,
+ res-name);
+ goto fail_free;
+ }
+ }
+
+out:
+ devres_add(dev, dr);
+ return res;
+
+fail_free:
+ free_resource(res);
+fail:
+ devres_free(dr);
+ return res;
+}
+EXPORT_SYMBOL(__devm_request_region_ram);
+
void __devm_release_region(struct device *dev, struct resource *parent,
resource_size_t start, resource_size_t n)
{
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: move PCI IDs to i915_drm.h
Since we need to use them in early x86 boot code.
Signed-off-by: Jesse Barnes jbar...@virtuosugeek.org
---
drivers/gpu/drm/i915/i915_drv.c | 158 ++
include/drm/i915_drm.h | 180 +++
2 files changed, 208 insertions(+), 130 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b07362f..3834056 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -140,25 +140,6 @@ MODULE_PARM_DESC(fastboot, Try to skip unnecessary mode
sets at boot time
static struct drm_driver driver;
extern int intel_agp_enabled;
-#define INTEL_VGA_DEVICE(id, info) { \
- .class = PCI_BASE_CLASS_DISPLAY 16, \
- .class_mask = 0xff, \
- .vendor = 0x8086, \
- .device = id, \
- .subvendor = PCI_ANY_ID,\
- .subdevice = PCI_ANY_ID,\
- .driver_data = (unsigned long) info }
-
-#define INTEL_QUANTA_VGA_DEVICE(info) {\
- .class = PCI_BASE_CLASS_DISPLAY 16, \
- .class_mask = 0xff, \
- .vendor = 0x8086, \
- .device = 0x16a,\
- .subvendor = 0x152d,\
- .subdevice = 0x8990,\
- .driver_data = (unsigned long) info }
-
-
static const struct intel_device_info intel_i830_info = {
.gen = 2, .is_mobile = 1, .cursor_needs_physical = 1, .num_pipes = 2,
.has_overlay = 1, .overlay_needs_physical = 1,
@@ -333,118 +314,35 @@ static const struct intel_device_info
intel_haswell_m_info = {
.has_vebox_ring = 1,
};
+#define INTEL_PCI_IDS \
+ INTEL_I830_IDS(intel_i830_info), \
+ INTEL_I845G_IDS(intel_845g_info), \
+ INTEL_I85X_IDS(intel_i85x_info), \
+ INTEL_I865G_IDS(intel_i865g_info), \
+ INTEL_I915G_IDS(intel_i915g_info), \
+ INTEL_I915GM_IDS(intel_i915gm_info), \
+ INTEL_I945G_IDS(intel_i945g_info), \
+ INTEL_I945GM_IDS(intel_i945gm_info), \
+ INTEL_I965G_IDS(intel_i965g_info), \
+ INTEL_G33_IDS(intel_g33_info), \
+ INTEL_I965GM_IDS(intel_i965gm_info), \
+ INTEL_GM45_IDS(intel_gm45_info), \
+ INTEL_G45_IDS(intel_g45_info), \
+ INTEL_PINEVIEW_IDS(intel_pineview_info), \
+ INTEL_IRONLAKE_D_IDS(intel_ironlake_d_info), \
+ INTEL_IRONLAKE_M_IDS(intel_ironlake_m_info), \
+ INTEL_SNB_D_IDS(intel_sandybridge_d_info), \
+ INTEL_SNB_M_IDS(intel_sandybridge_m_info), \
+ INTEL_IVB_M_IDS(intel_ivybridge_m_info), \
+ INTEL_IVB_D_IDS(intel_ivybridge_d_info), \
+ INTEL_IVB_Q_IDS(intel_ivybridge_q_info), \
+ INTEL_HSW_D_IDS(intel_haswell_d_info), \
+ INTEL_HSW_M_IDS(intel_haswell_m_info), \
+ INTEL_VLV_M_IDS(intel_valleyview_m_info), \
+ INTEL_VLV_D_IDS(intel_valleyview_d_info)
+
static const struct pci_device_id pciidlist[] = { /* aka */
- INTEL_VGA_DEVICE(0x3577, intel_i830_info), /* I830_M */
- INTEL_VGA_DEVICE(0x2562, intel_845g_info), /* 845_G */
- INTEL_VGA_DEVICE(0x3582, intel_i85x_info), /* I855_GM */
- INTEL_VGA_DEVICE(0x358e, intel_i85x_info),
- INTEL_VGA_DEVICE(0x2572, intel_i865g_info),/* I865_G */
- INTEL_VGA_DEVICE(0x2582, intel_i915g_info),/* I915_G */
- INTEL_VGA_DEVICE(0x258a, intel_i915g_info),/* E7221_G */
- INTEL_VGA_DEVICE(0x2592, intel_i915gm_info), /* I915_GM */
- INTEL_VGA_DEVICE(0x2772, intel_i945g_info),/* I945_G */
- INTEL_VGA_DEVICE(0x27a2, intel_i945gm_info), /* I945_GM */
- INTEL_VGA_DEVICE(0x27ae, intel_i945gm_info), /* I945_GME */
- INTEL_VGA_DEVICE(0x2972, intel_i965g_info),/* I946_GZ */
- INTEL_VGA_DEVICE(0x2982, intel_i965g_info),/* G35_G */
- INTEL_VGA_DEVICE(0x2992, intel_i965g_info),/* I965_Q */
- INTEL_VGA_DEVICE(0x29a2, intel_i965g_info),/* I965_G */
- INTEL_VGA_DEVICE(0x29b2, intel_g33_info), /* Q35_G */
- INTEL_VGA_DEVICE(0x29c2, intel_g33_info), /* G33_G */
- INTEL_VGA_DEVICE(0x29d2, intel_g33_info), /* Q33_G */
- INTEL_VGA_DEVICE(0x2a02, intel_i965gm_info), /* I965_GM */
- INTEL_VGA_DEVICE(0x2a12, intel_i965gm_info), /* I965_GME */
- INTEL_VGA_DEVICE(0x2a42, intel_gm45_info), /* GM45_G */
- INTEL_VGA_DEVICE(0x2e02, intel_g45_info), /* IGD_E_G */
- INTEL_VGA_DEVICE(0x2e12, intel_g45_info), /* Q45_G */
- INTEL_VGA_DEVICE(0x2e22, intel_g45_info), /* G45_G */
-
[Intel-gfx] [PATCH 2/2] x86 early quirk: detect reserve graphics stolen memory for Intel devices
We need to do this early on before the E820 map is modified or
conflicting resources assigned on top.
---
arch/x86/kernel/early-quirks.c | 91
1 file changed, 91 insertions(+)
diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 94ab6b9..6017e45 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -208,6 +208,95 @@ static void __init intel_remapping_check(int num, int
slot, int func)
}
+static const struct pci_device_id gen3_method_ids[] = {
+ INTEL_I830_IDS(NULL),
+ INTEL_I845G_IDS(NULL),
+ INTEL_I85X_IDS(NULL),
+ INTEL_I865G_IDS(NULL),
+ INTEL_I915G_IDS(NULL),
+ INTEL_I915GM_IDS(NULL),
+ INTEL_I945G_IDS(NULL),
+ INTEL_I945GM_IDS(NULL),
+ INTEL_VLV_M_IDS(NULL),
+ INTEL_VLV_D_IDS(NULL),
+ INTEL_PINEVIEW_IDS(NULL),
+};
+static const struct pci_device_id gen4_method_ids[] = {
+ INTEL_I965G_IDS(NULL),
+ INTEL_G33_IDS(NULL),
+ INTEL_I965GM_IDS(NULL),
+ INTEL_GM45_IDS(NULL),
+ INTEL_G45_IDS(NULL),
+ INTEL_IRONLAKE_D_IDS(NULL),
+ INTEL_IRONLAKE_M_IDS(NULL),
+};
+static const struct pci_device_id gen6_method_ids[] = {
+ INTEL_SNB_D_IDS(NULL),
+ INTEL_SNB_M_IDS(NULL),
+ INTEL_IVB_M_IDS(NULL),
+ INTEL_IVB_D_IDS(NULL),
+ INTEL_IVB_Q_IDS(NULL),
+ INTEL_HSW_D_IDS(NULL),
+ INTEL_HSW_M_IDS(NULL),
+};
+
+static void __init intel_gen3_method(int num, int slot, int func,
+u32 *start, size_t *size)
+{
+}
+
+static void __init intel_gen4_method(int num, int slot, int func,
+u32 *start, size_t *size)
+{
+}
+
+static void __init intel_gen6_method(int num, int slot, int func,
+u32 *start, size_t *size)
+{
+}
+
+static void __init intel_graphics_stolen(int num, int slot, int func)
+{
+ size_t size;
+ int i;
+ u32 start;
+ u16 device, subvendor, subdevice;
+
+ device = read_pci_config_word(num, slot, func, PCI_DEVICE_ID);
+ subvendor = read_pci_config_word(num, slot, func, PCI_SUBVENDOR_ID);
+ subdevice = read_pci_config_word(num, slot, func, PCI_SUBDEVICE_ID);
+
+ for (i = 0; i ARRAY_SIZE(gen3_method_ids); i++) {
+ if (gen3_method_ids[i].device == device) {
+ intel_gen3_method(num, slot, func, start, size);
+ goto found;
+ }
+ }
+
+ for (i = 0; i ARRAY_SIZE(gen4_method_ids); i++) {
+ if (gen4_method_ids[i].device == device) {
+ intel_gen4_method(num, slot, func, start, size);
+ goto found;
+ }
+ }
+
+ for (i = 0; i ARRAY_SIZE(gen6_method_ids); i++) {
+ if (gen6_method_ids[i].device == device
+ (gen6_method_ids[i].subvendor == PCI_ANY_ID ||
+gen6_method_ids[i].subvendor == subvendor)
+ (gen6_method_ids[i].subdevice == PCI_ANY_ID ||
+gen6_method_ids[i].subdevce == subdevice)) {
+ intel_gen6_method(num, slot, func, start, size);
+ goto found;
+ }
+ }
+
+ /* No match, don't bother reserving */
+ return;
+found:
+ /* Mark this space as reserved */
+}
+
#define QFLAG_APPLY_ONCE 0x1
#define QFLAG_APPLIED 0x2
#define QFLAG_DONE (QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -241,6 +330,8 @@ static struct chipset early_qrk[] __initdata = {
PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
{ PCI_VENDOR_ID_INTEL, 0x3406, PCI_CLASS_BRIDGE_HOST,
PCI_BASE_CLASS_BRIDGE, 0, intel_remapping_check },
+ { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, PCI_CLASS_DISPLAY, PCI_ANY_ID,
+ QFLAG_APPLY_ONCE, intel_graphics_stolen }
{}
};
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] early stolen mem detection
This is getting ugly; looking for feedback. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/15] Unify interrupt register init/reset
From: Paulo Zanoni paulo.r.zan...@intel.com Hi This patch series is based on emails I sent a few days ago, with subject proposals/questions about the IRQ registers. The biggest goal of the series is to have an unified way to initialize/reset IRQ regsiters. After this series, when you add new interrupts to our driver you won't need to think about doing the correct reads, writes and posting_reads, all you'll need to worry about is to call the macros everyone else calls. So now either all the registers are initialized correctly or all the registers are initialized wrongly. The first 10 patches do all the rework on i915+. The changes should be incremental and any non-trivial changes are on separate patches, so bisecting regressions should be very easy. It is worth mentioning that patches 2, 6, 9 and 10 touch VLV-specific code, and I don't have a way to test this code. On my intial patches the i8xx code was changed along with the i915+ code, but Ben suggested I shouldn't be touching i8xx code, so patches 11-15 do the i8xx work. I don't know if we really want these patches, but they're here anyway, so feel free to give them a NACK, I won't complain. In case we decide to merge the patches, git bisect should easily spot regressions. Patches tested on Haswell (constant use for 2 weeks), SandyBridge (a few hours of usage) and Atom (only booted and then suspend/resumed once). Thanks, Paulo Paulo Zanoni (15): drm/i915: add INTEL_IRQ_REG_RESET drm/i915: change how VLV_IIR is reset drm/i915: port i965_irq_uninstall go INTEL_IRQ_REG_RESET drm/i915: really clear the IIR registers drm/i915: add INTEL_IRQ_REG_INIT drm/i915: use INTEL_IRQ_REG_INIT on VLV too drm/i915: reset the IIR registers at preinstall drm/i915: WARN if IIR is not zero at irq_postinstall drm/i915: remove additional zerogin of VLV_IIR at postinstall drm/i915: remove extra clearing of GTIIR from VLV irq preinstall drm/i915: add INTEL_IRQ_REG_RESET16 drm/i915: really clear the IIR registers on i8xx drm/i915: add INTEL_IRQ_REG_INIT16 drm/i915: reset the i8xx IIR registers at preinstall drm/i915: WARN if IIR is not zero at i8xx irq_postinstall drivers/gpu/drm/i915/i915_irq.c | 144 +--- 1 file changed, 62 insertions(+), 82 deletions(-) -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915: add INTEL_IRQ_REG_RESET
From: Paulo Zanoni paulo.r.zan...@intel.com
The goal is to standardize the way we reset IRQ registers and also
reduce source code size. The new functions should touch IMR, IER and
IIR in the same way we're currently doing.
There are a few more cases where we could call the new functions or
set IIR to non-zero, but these represent real changes, so I'll leave
them to future patches for better bisectability.
Idea for the macro implementation shamelessly copied from Ben/Daniel.
v2: - Convert functions to macros (Ben and Daniel)
- Don't touch i8xx code (Ben)
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 58 +++--
1 file changed, 21 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f708e4e..351e30a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -79,6 +79,15 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
+#define INTEL_IRQ_REG_RESET(type, do_iir) do { \
+ I915_WRITE(type##MR, 0x); \
+ I915_WRITE(type##ER, 0); \
+ if (do_iir) \
+ I915_WRITE(type##IR, I915_READ(type##IR)); \
+ else \
+ POSTING_READ(type##ER); \
+} while (0)
+
/* For display hotplug interrupt */
static void
ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -2003,17 +2012,10 @@ static void gen5_gt_irq_preinstall(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- /* and GT */
- I915_WRITE(GTIMR, 0x);
- I915_WRITE(GTIER, 0x0);
- POSTING_READ(GTIER);
+ INTEL_IRQ_REG_RESET(GTI, false);
- if (INTEL_INFO(dev)-gen = 6) {
- /* and PM */
- I915_WRITE(GEN6_PMIMR, 0x);
- I915_WRITE(GEN6_PMIER, 0x0);
- POSTING_READ(GEN6_PMIER);
- }
+ if (INTEL_INFO(dev)-gen = 6)
+ INTEL_IRQ_REG_RESET(GEN6_PMI, false);
}
/* drm_dma.h hooks
@@ -2026,9 +2028,7 @@ static void ironlake_irq_preinstall(struct drm_device
*dev)
I915_WRITE(HWSTAM, 0xeffe);
- I915_WRITE(DEIMR, 0x);
- I915_WRITE(DEIER, 0x0);
- POSTING_READ(DEIER);
+ INTEL_IRQ_REG_RESET(DEI, false);
gen5_gt_irq_preinstall(dev);
@@ -2061,9 +2061,7 @@ static void valleyview_irq_preinstall(struct drm_device
*dev)
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
I915_WRITE(VLV_IIR, 0x);
- I915_WRITE(VLV_IMR, 0x);
- I915_WRITE(VLV_IER, 0x0);
- POSTING_READ(VLV_IER);
+ INTEL_IRQ_REG_RESET(VLV_I, false);
}
static void ibx_hpd_irq_setup(struct drm_device *dev)
@@ -2286,9 +2284,7 @@ static void valleyview_irq_uninstall(struct drm_device
*dev)
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
I915_WRITE(VLV_IIR, 0x);
- I915_WRITE(VLV_IMR, 0x);
- I915_WRITE(VLV_IER, 0x0);
- POSTING_READ(VLV_IER);
+ INTEL_IRQ_REG_RESET(VLV_I, false);
}
static void ironlake_irq_uninstall(struct drm_device *dev)
@@ -2302,22 +2298,16 @@ static void ironlake_irq_uninstall(struct drm_device
*dev)
I915_WRITE(HWSTAM, 0x);
- I915_WRITE(DEIMR, 0x);
- I915_WRITE(DEIER, 0x0);
- I915_WRITE(DEIIR, I915_READ(DEIIR));
+ INTEL_IRQ_REG_RESET(DEI, true);
if (IS_GEN7(dev))
I915_WRITE(GEN7_ERR_INT, I915_READ(GEN7_ERR_INT));
- I915_WRITE(GTIMR, 0x);
- I915_WRITE(GTIER, 0x0);
- I915_WRITE(GTIIR, I915_READ(GTIIR));
+ INTEL_IRQ_REG_RESET(GTI, true);
if (HAS_PCH_NOP(dev))
return;
- I915_WRITE(SDEIMR, 0x);
- I915_WRITE(SDEIER, 0x0);
- I915_WRITE(SDEIIR, I915_READ(SDEIIR));
+ INTEL_IRQ_REG_RESET(SDEI, true);
if (HAS_PCH_CPT(dev) || HAS_PCH_LPT(dev))
I915_WRITE(SERR_INT, I915_READ(SERR_INT));
}
@@ -2491,9 +2481,7 @@ static void i915_irq_preinstall(struct drm_device * dev)
I915_WRITE16(HWSTAM, 0xeffe);
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0);
- I915_WRITE(IMR, 0x);
- I915_WRITE(IER, 0x0);
- POSTING_READ(IER);
+ INTEL_IRQ_REG_RESET(I, false);
}
static int i915_irq_postinstall(struct drm_device *dev)
@@ -2693,10 +2681,8 @@ static void i915_irq_uninstall(struct drm_device * dev)
I915_WRITE(PIPESTAT(pipe), 0);
I915_WRITE(PIPESTAT(pipe), I915_READ(PIPESTAT(pipe)));
}
- I915_WRITE(IMR, 0x);
- I915_WRITE(IER, 0x0);
- I915_WRITE(IIR, I915_READ(IIR));
+ INTEL_IRQ_REG_RESET(I, true);
}
static void i965_irq_preinstall(struct drm_device * dev)
@@ -2712,9 +2698,7 @@ static void
[Intel-gfx] [PATCH 02/15] drm/i915: change how VLV_IIR is reset
From: Paulo Zanoni paulo.r.zan...@intel.com In the current code VLV_IIR is reset before VLV_IER and VLV_IMR. This looks wrong because after we reset VLV_IIR and before we clear IMR/IER we can still get more interrupts, so when we finally disable IMR and IER, there's no guaranteee that IIR will be clean. So in this patch we use intel_irq_reg_reset which is the function that is used by everybody else and should be correct. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_irq.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 351e30a..292337b 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2060,8 +2060,7 @@ static void valleyview_irq_preinstall(struct drm_device *dev) I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT)); for_each_pipe(pipe) I915_WRITE(PIPESTAT(pipe), 0x); - I915_WRITE(VLV_IIR, 0x); - INTEL_IRQ_REG_RESET(VLV_I, false); + INTEL_IRQ_REG_RESET(VLV_I, true); } static void ibx_hpd_irq_setup(struct drm_device *dev) @@ -2283,8 +2282,7 @@ static void valleyview_irq_uninstall(struct drm_device *dev) I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT)); for_each_pipe(pipe) I915_WRITE(PIPESTAT(pipe), 0x); - I915_WRITE(VLV_IIR, 0x); - INTEL_IRQ_REG_RESET(VLV_I, false); + INTEL_IRQ_REG_RESET(VLV_I, true); } static void ironlake_irq_uninstall(struct drm_device *dev) -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: port i965_irq_uninstall go INTEL_IRQ_REG_RESET
From: Paulo Zanoni paulo.r.zan...@intel.com The problem here is that we have the PIPESTAT registers between IER and IIR, so when we use intel_irq_reg_reset we flip the order used to reset IIR and PIPESTAT. That should be safe since after we clear IMR/IER we won't get any other IIR/PIPESTAT interrupts. Still, the change is on its own patch, so it should be easy to bisect and revert if needed. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_irq.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 292337b..b1b6552 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2920,13 +2920,11 @@ static void i965_irq_uninstall(struct drm_device * dev) I915_WRITE(HWSTAM, 0x); for_each_pipe(pipe) I915_WRITE(PIPESTAT(pipe), 0); - I915_WRITE(IMR, 0x); - I915_WRITE(IER, 0x0); + INTEL_IRQ_REG_RESET(I, true); for_each_pipe(pipe) I915_WRITE(PIPESTAT(pipe), I915_READ(PIPESTAT(pipe)) 0x8000); - I915_WRITE(IIR, I915_READ(IIR)); } static void i915_reenable_hotplug_timer_func(unsigned long data) -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/15] drm/i915: really clear the IIR registers
From: Paulo Zanoni paulo.r.zan...@intel.com
As written on our docs, the IIR registers are capable of storing 2
interrupts, so if we write once to them there's no guarantee they will
become zero. So on this patch we write to the register, read to check
if it's zero, and then write again in case it's needed.
Also replace I915_WRITE(iir, I915_READ(iir)) with I915_WRITE(iir,
0x), and then move the POSTING_READs on IER because we removed
the extra IIR read.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b1b6552..29eac7a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -82,10 +82,14 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
#define INTEL_IRQ_REG_RESET(type, do_iir) do { \
I915_WRITE(type##MR, 0x); \
I915_WRITE(type##ER, 0); \
- if (do_iir) \
- I915_WRITE(type##IR, I915_READ(type##IR)); \
- else \
- POSTING_READ(type##ER); \
+ POSTING_READ(type##ER); \
+ if (do_iir) { \
+ I915_WRITE(type##IR, 0x); \
+ if (I915_READ(type##IR)) { \
+ I915_WRITE(type##IR, 0x); \
+ POSTING_READ(type##IR); \
+ } \
+ } \
} while (0)
/* For display hotplug interrupt */
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: use INTEL_IRQ_REG_INIT on VLV too
From: Paulo Zanoni paulo.r.zan...@intel.com This is a case where the code written doesn't match INTEL_IRQ_REG_INIT perfectly. Call it after clearing PIPESTAT so we make sure that it is cleared while the interrupts are disabled. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_irq.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index e416848..37420b5 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2236,12 +2236,9 @@ static int valleyview_irq_postinstall(struct drm_device *dev) I915_WRITE(PORT_HOTPLUG_EN, 0); POSTING_READ(PORT_HOTPLUG_EN); - I915_WRITE(VLV_IMR, dev_priv-irq_mask); - I915_WRITE(VLV_IER, enable_mask); - I915_WRITE(VLV_IIR, 0x); I915_WRITE(PIPESTAT(0), 0x); I915_WRITE(PIPESTAT(1), 0x); - POSTING_READ(VLV_IER); + INTEL_IRQ_REG_INIT(VLV_I, true, enable_mask, dev_priv-irq_mask); /* Interrupt setup is already guaranteed to be single-threaded, this is * just to make the assert_spin_locked check happy. */ -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/15] drm/i915: add INTEL_IRQ_REG_INIT
From: Paulo Zanoni paulo.r.zan...@intel.com
Same reason as intel_irq_reg_reset: let's standardize the way we init
registers so we make sure all the code is doing the same thing, and
then we can also change everybody at the same time if we need. This
function is for irq_postinstall functions. Again, this patch only
converts the cases where the new code perfectly matches the old one,
other cases will be done in separate patches for better bisectability.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 29eac7a..e416848 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -92,6 +92,14 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
} \
} while (0)
+#define INTEL_IRQ_REG_INIT(type, do_iir, ier_val, imr_val) do { \
+ if (do_iir) \
+ I915_WRITE(type##IR, I915_READ(type##IR)); \
+ I915_WRITE(type##MR, (imr_val)); \
+ I915_WRITE(type##ER, (ier_val)); \
+ POSTING_READ(type##ER); \
+} while (0)
+
/* For display hotplug interrupt */
static void
ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -2145,10 +2153,7 @@ static void gen5_gt_irq_postinstall(struct drm_device
*dev)
gt_irqs |= GT_BLT_USER_INTERRUPT | GT_BSD_USER_INTERRUPT;
}
- I915_WRITE(GTIIR, I915_READ(GTIIR));
- I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
- I915_WRITE(GTIER, gt_irqs);
- POSTING_READ(GTIER);
+ INTEL_IRQ_REG_INIT(GTI, true, gt_irqs, dev_priv-gt_irq_mask);
if (INTEL_INFO(dev)-gen = 6) {
pm_irqs |= GEN6_PM_RPS_EVENTS;
@@ -2156,10 +2161,7 @@ static void gen5_gt_irq_postinstall(struct drm_device
*dev)
if (HAS_VEBOX(dev))
pm_irqs |= PM_VEBOX_USER_INTERRUPT;
- I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
- I915_WRITE(GEN6_PMIMR, 0x);
- I915_WRITE(GEN6_PMIER, pm_irqs);
- POSTING_READ(GEN6_PMIER);
+ INTEL_IRQ_REG_INIT(GEN6_PMI, true, pm_irqs, 0x);
}
}
@@ -2189,11 +2191,8 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
dev_priv-irq_mask = ~display_mask;
- /* should always can generate irq */
- I915_WRITE(DEIIR, I915_READ(DEIIR));
- I915_WRITE(DEIMR, dev_priv-irq_mask);
- I915_WRITE(DEIER, display_mask | extra_mask);
- POSTING_READ(DEIER);
+ INTEL_IRQ_REG_INIT(DEI, true, display_mask | extra_mask,
+ dev_priv-irq_mask);
gen5_gt_irq_postinstall(dev);
@@ -2519,9 +2518,7 @@ static int i915_irq_postinstall(struct drm_device *dev)
dev_priv-irq_mask = ~I915_DISPLAY_PORT_INTERRUPT;
}
- I915_WRITE(IMR, dev_priv-irq_mask);
- I915_WRITE(IER, enable_mask);
- POSTING_READ(IER);
+ INTEL_IRQ_REG_INIT(I, false, enable_mask, dev_priv-irq_mask);
i915_enable_asle_pipestat(dev);
@@ -2751,6 +2748,7 @@ static int i965_irq_postinstall(struct drm_device *dev)
I915_WRITE(IMR, dev_priv-irq_mask);
I915_WRITE(IER, enable_mask);
POSTING_READ(IER);
+ INTEL_IRQ_REG_INIT(I, false, enable_mask, dev_priv-irq_mask);
I915_WRITE(PORT_HOTPLUG_EN, 0);
POSTING_READ(PORT_HOTPLUG_EN);
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/15] drm/i915: remove extra clearing of GTIIR from VLV irq preinstall
From: Paulo Zanoni paulo.r.zan...@intel.com After the last changes, gen5_gt_irq_preinstall should now guarantee that GTIIR will be zero. Also, at valleyview_irq_postinstall we call gen5_gt_irq_postinstall which calls intel_irq_reg_init, which will print a nice WARN in case GTIIR is not zero. Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_irq.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 5ca50a0..9684f1e 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2056,10 +2056,6 @@ static void valleyview_irq_preinstall(struct drm_device *dev) I915_WRITE(RING_IMR(GEN6_BSD_RING_BASE), 0); I915_WRITE(RING_IMR(BLT_RING_BASE), 0); - /* and GT */ - I915_WRITE(GTIIR, I915_READ(GTIIR)); - I915_WRITE(GTIIR, I915_READ(GTIIR)); - gen5_gt_irq_preinstall(dev); I915_WRITE(DPINVGTT, 0xff); -- 1.8.1.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] drm/i915: add INTEL_IRQ_REG_RESET16
From: Paulo Zanoni paulo.r.zan...@intel.com
Same thing as INTEL_IRQ_REG_RESET, but now on a separate patch, as
requested by Ben.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9684f1e..7588ad3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -79,6 +79,15 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
+#define INTEL_IRQ_REG_RESET16(type, do_iir) do { \
+ I915_WRITE16(type##MR, 0x); \
+ I915_WRITE16(type##ER, 0); \
+ if (do_iir) \
+ I915_WRITE16(type##IR, I915_READ16(type##IR)); \
+ else \
+ POSTING_READ16(type##ER); \
+} while (0)
+
#define INTEL_IRQ_REG_RESET(type) do { \
I915_WRITE(type##MR, 0x); \
I915_WRITE(type##ER, 0); \
@@ -2308,9 +2317,7 @@ static void i8xx_irq_preinstall(struct drm_device * dev)
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0);
- I915_WRITE16(IMR, 0x);
- I915_WRITE16(IER, 0x0);
- POSTING_READ16(IER);
+ INTEL_IRQ_REG_RESET16(I, false);
}
static int i8xx_irq_postinstall(struct drm_device *dev)
@@ -2448,9 +2455,7 @@ static void i8xx_irq_uninstall(struct drm_device * dev)
I915_WRITE(PIPESTAT(pipe), 0);
I915_WRITE(PIPESTAT(pipe), I915_READ(PIPESTAT(pipe)));
}
- I915_WRITE16(IMR, 0x);
- I915_WRITE16(IER, 0x0);
- I915_WRITE16(IIR, I915_READ16(IIR));
+ INTEL_IRQ_REG_RESET16(I, true);
}
static void i915_irq_preinstall(struct drm_device * dev)
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/i915: really clear the IIR registers on i8xx
From: Paulo Zanoni paulo.r.zan...@intel.com
Same thing as drm/i915: really clear the IIR registers, but on a
separate patch for easier bisecting.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7588ad3..a936c59 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -82,10 +82,14 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
#define INTEL_IRQ_REG_RESET16(type, do_iir) do { \
I915_WRITE16(type##MR, 0x); \
I915_WRITE16(type##ER, 0); \
- if (do_iir) \
- I915_WRITE16(type##IR, I915_READ16(type##IR)); \
- else \
- POSTING_READ16(type##ER); \
+ POSTING_READ16(type##ER); \
+ if (do_iir) { \
+ I915_WRITE16(type##IR, 0x); \
+ if (I915_READ16(type##IR)) { \
+ I915_WRITE16(type##IR, 0x); \
+ POSTING_READ16(type##IR); \
+ } \
+ } \
} while (0)
#define INTEL_IRQ_REG_RESET(type) do { \
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] drm/i915: add INTEL_IRQ_REG_INIT16
From: Paulo Zanoni paulo.r.zan...@intel.com
Same thing as INTEL_IRQ_REG_INIT, but on a separate patch.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a936c59..d32042d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -102,6 +102,14 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
} \
} while (0)
+#define INTEL_IRQ_REG_INIT16(type, do_iir, ier_val, imr_val) do { \
+ if (do_iir) \
+ I915_WRITE16(type##IR, I915_READ16(type##IR)); \
+ I915_WRITE16(type##MR, (imr_val)); \
+ I915_WRITE16(type##ER, (ier_val)); \
+ POSTING_READ16(type##ER); \
+} while (0)
+
#define INTEL_IRQ_REG_INIT(type, do_iir, ier_val, imr_val) do { \
WARN(I915_READ(type##IR) != 0, Register 0x%x is not 0\n, type##IR); \
I915_WRITE(type##MR, (imr_val)); \
@@ -2327,6 +2335,10 @@ static void i8xx_irq_preinstall(struct drm_device * dev)
static int i8xx_irq_postinstall(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
+ uint32_t enable_mask = (I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
+ I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
+ I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT |
+ I915_USER_INTERRUPT);
I915_WRITE16(EMR,
~(I915_ERROR_PAGE_TABLE | I915_ERROR_MEMORY_REFRESH));
@@ -2338,14 +2350,8 @@ static int i8xx_irq_postinstall(struct drm_device *dev)
I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT |
I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT |
I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT);
- I915_WRITE16(IMR, dev_priv-irq_mask);
-
- I915_WRITE16(IER,
-I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
-I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
-I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT |
-I915_USER_INTERRUPT);
- POSTING_READ16(IER);
+
+ INTEL_IRQ_REG_INIT16(I, false, enable_mask, dev_priv-irq_mask);
return 0;
}
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] drm/i915: WARN if IIR is not zero at i8xx irq_postinstall
From: Paulo Zanoni paulo.r.zan...@intel.com
Same thing as the previous non-i8xx commit.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4f0bc26..8b12caa 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -100,8 +100,8 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
} while (0)
#define INTEL_IRQ_REG_INIT16(type, do_iir, ier_val, imr_val) do { \
- if (do_iir) \
- I915_WRITE16(type##IR, I915_READ16(type##IR)); \
+ WARN(I915_READ16(type##IR) != 0, Register 0x%x is not 0\n, \
+type##IR); \
I915_WRITE16(type##MR, (imr_val)); \
I915_WRITE16(type##ER, (ier_val)); \
POSTING_READ16(type##ER); \
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/15] drm/i915: reset the i8xx IIR registers at preinstall
From: Paulo Zanoni paulo.r.zan...@intel.com
Same thing as the equivalent commit that touched INTEL_IRQ_REG_RESET.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d32042d..4f0bc26 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -79,16 +79,13 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-#define INTEL_IRQ_REG_RESET16(type, do_iir) do { \
+#define INTEL_IRQ_REG_RESET16(type) do { \
I915_WRITE16(type##MR, 0x); \
I915_WRITE16(type##ER, 0); \
- POSTING_READ16(type##ER); \
- if (do_iir) { \
+ I915_WRITE16(type##IR, 0x); \
+ if (I915_READ16(type##IR)) { \
I915_WRITE16(type##IR, 0x); \
- if (I915_READ16(type##IR)) { \
- I915_WRITE16(type##IR, 0x); \
- POSTING_READ16(type##IR); \
- } \
+ POSTING_READ16(type##IR); \
} \
} while (0)
@@ -2329,7 +2326,7 @@ static void i8xx_irq_preinstall(struct drm_device * dev)
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0);
- INTEL_IRQ_REG_RESET16(I, false);
+ INTEL_IRQ_REG_RESET16(I);
}
static int i8xx_irq_postinstall(struct drm_device *dev)
@@ -2465,7 +2462,7 @@ static void i8xx_irq_uninstall(struct drm_device * dev)
I915_WRITE(PIPESTAT(pipe), 0);
I915_WRITE(PIPESTAT(pipe), I915_READ(PIPESTAT(pipe)));
}
- INTEL_IRQ_REG_RESET16(I, true);
+ INTEL_IRQ_REG_RESET16(I);
}
static void i915_irq_preinstall(struct drm_device * dev)
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
