Re: [Intel-gfx] [PATCH 02/26] drm/i915: Extract switch to default context
On Mon, Mar 17, 2014 at 10:48:34PM -0700, Ben Widawsky wrote:
This patch existed for another reason which no longer exists. I liked
it, so I kept it in the series. It can skipped if undesirable.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 35f9a37..c59b707 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2476,6 +2476,8 @@ int i915_gem_context_enable(struct drm_i915_private
*dev_priv);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct intel_ring_buffer *ring,
struct drm_file *file, struct i915_hw_context *to);
+#define i915_switch_to_default(ring) \
+ i915_switch_context(ring, NULL, ring-default_context)
struct i915_hw_context *
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id);
void i915_gem_context_free(struct kref *ctx_ref);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b2565d2..ed09dda 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2799,7 +2799,7 @@ int i915_gpu_idle(struct drm_device *dev)
/* Flush everything onto the inactive list. */
for_each_ring(ring, dev_priv, i) {
- ret = i915_switch_context(ring, NULL, ring-default_context);
+ ret = i915_switch_to_default(ring);
Switch what to default? What it does is not very clear, sorry.
Skip unless we change it to i915_switch_to_default_context()?
intel_ring_switch_to_default_context()? Doesn't seem like much of a win
by that point. :|
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/26] drm/i915: rename map/unmap to dma_map/unmap
On Mon, Mar 17, 2014 at 10:48:36PM -0700, Ben Widawsky wrote: Upcoming patches will use the terms map and unmap in references to the page table entries. Having this distinction will really help with code clarity at that point. Nice. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/26] drm/i915: Wrap VMA binding
On Mon, Mar 17, 2014 at 10:48:38PM -0700, Ben Widawsky wrote: This will be useful for some upcoming patches which do more platform specific work. Having it in one central place just makes things a bit cleaner and easier. There is a small functional change here. There are more calls to the tracepoints. NOTE: I didn't actually end up using this patch for the intended purpose, but I thought it was a nice patch to keep around. Signed-off-by: Ben Widawsky b...@bwidawsk.net --- drivers/gpu/drm/i915/i915_drv.h| 3 +++ drivers/gpu/drm/i915/i915_gem.c| 8 drivers/gpu/drm/i915/i915_gem_context.c| 2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++-- drivers/gpu/drm/i915/i915_gem_gtt.c| 16 ++-- 5 files changed, 25 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index c59b707..b3e31fd 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2408,6 +2408,9 @@ 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_bind_vma(struct i915_vma *vma, enum i915_cache_level, +unsigned flags); +void i915_gem_unbind_vma(struct i915_vma *vma); Being pedantic, this should be i915_vma_bind, i915_vma_unbind. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/26] drm/i915: clean up PPGTT init error path
On Mon, Mar 17, 2014 at 10:48:39PM -0700, Ben Widawsky wrote:
The old code (I'm having trouble finding the commit) had a reason for
doing things when there was an error, and would continue on, thus the
!ret. For the newer code however, this looks completely silly.
Follow the normal idiom of if (ret) return ret.
Also, put the pde wiring in the gen specific init, now that GEN8 exists.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1620211..5f73284 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1202,6 +1202,8 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-pd_offset =
ppgtt-node.start / PAGE_SIZE * sizeof(gen6_gtt_pte_t);
+ gen6_write_pdes(ppgtt);
+
ppgtt-base.clear_range(ppgtt-base, 0, ppgtt-base.total, true);
DRM_DEBUG_DRIVER(Allocated pde space (%ldM) at GTT entry: %lx\n,
@@ -1226,20 +1228,14 @@ int i915_gem_init_ppgtt(struct drm_device *dev,
struct i915_hw_ppgtt *ppgtt)
else
BUG();
- if (!ret) {
- struct drm_i915_private *dev_priv = dev-dev_private;
- kref_init(ppgtt-ref);
- drm_mm_init(ppgtt-base.mm, ppgtt-base.start,
- ppgtt-base.total);
- i915_init_vm(dev_priv, ppgtt-base);
- if (INTEL_INFO(dev)-gen 8) {
- gen6_write_pdes(ppgtt);
- DRM_DEBUG(Adding PPGTT at offset %x\n,
- ppgtt-pd_offset 10);
- }
- }
+ if (ret)
+ return ret;
- return ret;
+ kref_init(ppgtt-ref);
+ drm_mm_init(ppgtt-base.mm, ppgtt-base.start, ppgtt-base.total);
+ i915_init_vm(dev_priv, ppgtt-base);
Didn't we just delete the dev_priv local variable?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/26] drm/i915: Split out gtt specific header file
On Mon, Mar 17, 2014 at 10:48:41PM -0700, Ben Widawsky wrote: TODO: Do header files need a copyright? Short answer: yes. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/26] drm/i915: Make gen6_write_pdes gen6_map_page_tables
On Mon, Mar 17, 2014 at 10:48:42PM -0700, Ben Widawsky wrote: Split out single mappings which will help with upcoming work. Also while here, rename the function because it is a better description - but this function is going away soon. At this moment, I'm not sure about the name genX_map_single(). Maybe it will make sense in a bit... -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/26] drm/i915: Range clearing is PPGTT agnostic
On Mon, Mar 17, 2014 at 10:48:43PM -0700, Ben Widawsky wrote: Therefore we can do it from our general init function. Eventually, I hope to have a lot more commonality like this. It won't arrive yet, but this was a nice easy one. Lgtm. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Give the sprite width to the WM computation
On Mon, Mar 17, 2014 at 05:58:14PM +, Damien Lespiau wrote:
In the future, we'll need the height of the fb we're fetching from
memory for WM computation.
At some point in the future, it'd be nice to give a pointer to a
mystical plane_config structure instead of chaplet of parameters.
Given that we kinda have such a beast now (but somewhere totally else
unforutnately), should we just start using that one? Or do you think it's
better to add parameters until we're clearer on where plane_config needs
to go to?
Imo the pile of parameters we now have in these functions cross the chasm
into I can't read this any more without constantly jumping backforth.
Ville, Paulo, any opinions on how to move forward here with the least
amount of madness?
-Daniel
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_drv.h| 5 -
drivers/gpu/drm/i915/intel_pm.c | 17 +++--
drivers/gpu/drm/i915/intel_sprite.c | 15 +--
4 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 70fbe90..057873e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -438,8 +438,8 @@ struct drm_i915_display_funcs {
void (*update_wm)(struct drm_crtc *crtc);
void (*update_sprite_wm)(struct drm_plane *plane,
struct drm_crtc *crtc,
- uint32_t sprite_width, int pixel_size,
- bool enable, bool scaled);
+ uint32_t sprite_width, uint32_t sprite_height,
+ int pixel_size, bool enable, bool scaled);
void (*modeset_global_resources)(struct drm_device *dev);
/* Returns the active state of the crtc, and if the crtc is active,
* fills out the pipe-config with the hw state. */
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index e0064a1..8e6f971 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -392,6 +392,7 @@ struct intel_crtc {
struct intel_plane_wm_parameters {
uint32_t horiz_pixels;
+ uint32_t vert_pixels;
uint8_t bytes_per_pixel;
bool enabled;
bool scaled;
@@ -873,7 +874,9 @@ void intel_suspend_hw(struct drm_device *dev);
void intel_update_watermarks(struct drm_crtc *crtc);
void intel_update_sprite_watermarks(struct drm_plane *plane,
struct drm_crtc *crtc,
- uint32_t sprite_width, int pixel_size,
+ uint32_t sprite_width,
+ uint32_t sprite_height,
+ int pixel_size,
bool enabled, bool scaled);
void intel_init_pm(struct drm_device *dev);
void intel_pm_setup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ad58ce3..6dbaf66 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2579,10 +2579,11 @@ static void ilk_update_wm(struct drm_crtc *crtc)
ilk_write_wm_values(dev_priv, results);
}
-static void ilk_update_sprite_wm(struct drm_plane *plane,
- struct drm_crtc *crtc,
- uint32_t sprite_width, int pixel_size,
- bool enabled, bool scaled)
+static void
+ilk_update_sprite_wm(struct drm_plane *plane,
+ struct drm_crtc *crtc,
+ uint32_t sprite_width, uint32_t sprite_height,
+ int pixel_size, bool enabled, bool scaled)
{
struct drm_device *dev = plane-dev;
struct intel_plane *intel_plane = to_intel_plane(plane);
@@ -2590,6 +2591,7 @@ static void ilk_update_sprite_wm(struct drm_plane
*plane,
intel_plane-wm.enabled = enabled;
intel_plane-wm.scaled = scaled;
intel_plane-wm.horiz_pixels = sprite_width;
+ intel_plane-wm.vert_pixels = sprite_width;
intel_plane-wm.bytes_per_pixel = pixel_size;
/*
@@ -2720,13 +2722,16 @@ void intel_update_watermarks(struct drm_crtc *crtc)
void intel_update_sprite_watermarks(struct drm_plane *plane,
struct drm_crtc *crtc,
- uint32_t sprite_width, int pixel_size,
+ uint32_t sprite_width,
+ uint32_t sprite_height,
+ int pixel_size,
bool enabled, bool scaled)
{
struct drm_i915_private *dev_priv = plane-dev-dev_private;
if (dev_priv-display.update_sprite_wm)
- dev_priv-display.update_sprite_wm(plane, crtc, sprite_width,
+
Re: [Intel-gfx] [PATCH] drm/i915: Remove spurious '()' in WARN macros
On Mon, Mar 17, 2014 at 05:59:48PM +, Damien Lespiau wrote:
No need of any here.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d34add5..c6743f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1166,7 +1166,7 @@ static void assert_planes_disabled(struct
drm_i915_private *dev_priv,
if (INTEL_INFO(dev)-gen = 4) {
reg = DSPCNTR(pipe);
val = I915_READ(reg);
- WARN((val DISPLAY_PLANE_ENABLE),
+ WARN(val DISPLAY_PLANE_ENABLE,
plane %c assertion failure, should be disabled but not\n,
plane_name(pipe));
return;
@@ -1195,20 +1195,20 @@ static void assert_sprites_disabled(struct
drm_i915_private *dev_priv,
for_each_sprite(pipe, sprite) {
reg = SPCNTR(pipe, sprite);
val = I915_READ(reg);
- WARN((val SP_ENABLE),
+ WARN(val SP_ENABLE,
sprite %c assertion failure, should be off on
pipe %c but is still active\n,
sprite_name(pipe, sprite), pipe_name(pipe));
}
} else if (INTEL_INFO(dev)-gen = 7) {
reg = SPRCTL(pipe);
val = I915_READ(reg);
- WARN((val SPRITE_ENABLE),
+ WARN(val SPRITE_ENABLE,
sprite %c assertion failure, should be off on pipe %c but
is still active\n,
plane_name(pipe), pipe_name(pipe));
} else if (INTEL_INFO(dev)-gen = 5) {
reg = DVSCNTR(pipe);
val = I915_READ(reg);
- WARN((val DVS_ENABLE),
+ WARN(val DVS_ENABLE,
sprite %c assertion failure, should be off on pipe %c but
is still active\n,
plane_name(pipe), pipe_name(pipe));
}
--
1.8.3.1
___
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] drm/i915: Rename intel_setup_wm_latency() to ilk_setup_wm_latency()
On Mon, Mar 17, 2014 at 06:01:16PM +, Damien Lespiau wrote:
This function is only used on ILK+, so rename it accordingly.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6dbaf66..47bf433 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2085,7 +2085,7 @@ static void intel_print_wm_latency(struct drm_device
*dev,
}
}
-static void intel_setup_wm_latency(struct drm_device *dev)
+static void ilk_setup_wm_latency(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -5990,7 +5990,7 @@ void intel_init_pm(struct drm_device *dev)
/* For FIFO watermark updates */
if (HAS_PCH_SPLIT(dev)) {
- intel_setup_wm_latency(dev);
+ ilk_setup_wm_latency(dev);
if ((IS_GEN5(dev) dev_priv-wm.pri_latency[1]
dev_priv-wm.spr_latency[1]
dev_priv-wm.cur_latency[1]) ||
--
1.8.3.1
___
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 12/26] drm/i915: Page table helpers, and define renames
On Mon, Mar 17, 2014 at 10:48:44PM -0700, Ben Widawsky wrote:
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -1,8 +1,11 @@
#ifndef _I915_GEM_GTT_H
#define _I915_GEM_GTT_H
-#define GEN6_PPGTT_PD_ENTRIES 512
-#define I915_PPGTT_PT_ENTRIES (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
+/* GEN Agnostic defines */
+#define I915_PDES_PER_PD 512
+#define I915_PTE_MASK(PAGE_SHIFT-1)
That looks decidely fishy.
PAGE_SHIFT is 12 - PTE_MASK = 0xb
+#define I915_PDE_MASK(I915_PDES_PER_PD-1)
+
typedef uint32_t gen6_gtt_pte_t;
typedef uint64_t gen8_gtt_pte_t;
typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
@@ -23,6 +26,98 @@ typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
#define GEN6_PTE_ADDR_ENCODE(addr) GEN6_GTT_ADDR_ENCODE(addr)
#define HSW_PTE_ADDR_ENCODE(addr)HSW_GTT_ADDR_ENCODE(addr)
+
+/* GEN6 PPGTT resembles a 2 level page table:
+ * 31:22 | 21:12 | 11:0
+ * PDE | PTE | offset
+ */
+#define GEN6_PDE_SHIFT 22
+#define GEN6_PTES_PER_PT (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
+
+static inline uint32_t i915_pte_index(uint64_t address, uint32_t pde_shift)
+{
+ const uint32_t mask = (1 (pde_shift - PAGE_SHIFT)) - 1;
+ return (address PAGE_SHIFT) mask;
+}
+
+/* Helper to counts the number of PTEs within the given length. This count
does
+ * not cross a page table boundary, so the max value would be
+ * GEN6_PTES_PER_PT for GEN6, and GEN8_PTES_PER_PT for GEN8.
+ */
+static inline size_t i915_pte_count(uint64_t addr, size_t length,
+ uint32_t pde_shift)
+{
+ const uint64_t pd_mask = ~((1 pde_shift) - 1);
+ uint64_t end;
+
+ if (WARN_ON(!length))
+ return 0;
+
+ if (WARN_ON(addr % PAGE_SIZE))
+ addr = round_down(addr, PAGE_SIZE);
+
+ if (WARN_ON(length % PAGE_SIZE))
+ length = round_up(length, PAGE_SIZE);
Oh oh. I think these fixups are very suspect, so just
BUG_ON(length == 0);
BUG_ON(offset_in_page(addr|length));
+
+ end = addr + length;
+
+ if ((addr pd_mask) != (end pd_mask))
+ return (1 (pde_shift - PAGE_SHIFT)) -
#define NUM_PTE(pde_shift) (1 (pde_shift - PAGE_SHIFT))
here and for computing the pd_mask.
+ i915_pte_index(addr, pde_shift);
+
+ return i915_pte_index(end, pde_shift) - i915_pte_index(addr, pde_shift);
+}
Otherwise the helpers look a useful improvement in readability.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/26] drm/i915: Complete page table structures
On Mon, Mar 17, 2014 at 10:48:46PM -0700, Ben Widawsky wrote: Move the remaining members over to the new page table structures. This can be squashed with the previous commit if desire. The reasoning is the same as that patch. I simply felt it is easier to review if split. I'm not liking the shorter names much. Is there precedence elsewhere (e.g. daddr)? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/26] drm/i915: Create page table allocators
On Mon, Mar 17, 2014 at 10:48:47PM -0700, Ben Widawsky wrote: As we move toward dynamic page table allocation, it becomes much easier to manage our data structures if break do things less coarsely by breaking up all of our actions into individual tasks. This makes the code easier to write, read, and verify. Aside from the dissection of the allocation functions, the patch statically allocates the page table structures without a page directory. This remains the same for all platforms, The patch itself should not have much functional difference. The primary noticeable difference is the fact that page tables are no longer allocated, but rather statically declared as part of the page directory. This has non-zero overhead, but things gain non-trivial complexity as a result. We increase overhead for increased complexity. What's the selling point of this patch then? Otherwise, patch does as you say. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/26] drm/i915: Split out gtt specific header file
On Mon, Mar 17, 2014 at 10:48:41PM -0700, Ben Widawsky wrote:
TODO: Do header files need a copyright?
Yup ;-)
I like this though, especially since finer-grained files will make
kerneldoc inclusion (well, grouped into sensible chapters at least) much
simpler.
-Daniel
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 162 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 57 -
drivers/gpu/drm/i915/i915_gem_gtt.h | 225
3 files changed, 227 insertions(+), 217 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_gem_gtt.h
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 084e82f..b19442c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -44,6 +44,8 @@
#include linux/kref.h
#include linux/pm_qos.h
+#include i915_gem_gtt.h
+
/* General customization:
*/
@@ -572,166 +574,6 @@ enum i915_cache_level {
I915_CACHE_WT, /* hsw:gt3e WriteThrough for scanouts */
};
-typedef uint32_t gen6_gtt_pte_t;
-
-/**
- * A VMA represents a GEM BO that is bound into an address space. Therefore,
a
- * VMA's presence cannot be guaranteed before binding, or after unbinding the
- * object into/from the address space.
- *
- * To make things as simple as possible (ie. no refcounting), a VMA's
lifetime
- * will always be = an objects lifetime. So object refcounting should cover
us.
- */
-struct i915_vma {
- struct drm_mm_node node;
- struct drm_i915_gem_object *obj;
- struct i915_address_space *vm;
-
- /** This object's place on the active/inactive lists */
- struct list_head mm_list;
-
- struct list_head vma_link; /* Link in the object's VMA list */
-
- /** This vma's place in the batchbuffer or on the eviction list */
- struct list_head exec_list;
-
- /**
- * Used for performing relocations during execbuffer insertion.
- */
- struct hlist_node exec_node;
- unsigned long exec_handle;
- struct drm_i915_gem_exec_object2 *exec_entry;
-
- /**
- * How many users have pinned this object in GTT space. The following
- * users can each hold at most one reference: pwrite/pread, pin_ioctl
- * (via user_pin_count), execbuffer (objects are not allowed multiple
- * times for the same batchbuffer), and the framebuffer code. When
- * switching/pageflipping, the framebuffer code has at most two buffers
- * pinned per crtc.
- *
- * In the worst case this is 1 + 1 + 1 + 2*2 = 7. That would fit into 3
- * bits with absolutely no headroom. So use 4 bits. */
- unsigned int pin_count:4;
-#define DRM_I915_GEM_OBJECT_MAX_PIN_COUNT 0xf
-
- /** Unmap an object from an address space. This usually consists of
- * setting the valid PTE entries to a reserved scratch page. */
- void (*unbind_vma)(struct i915_vma *vma);
- /* Map an object into an address space with the given cache flags. */
-#define GLOBAL_BIND (10)
- void (*bind_vma)(struct i915_vma *vma,
- enum i915_cache_level cache_level,
- u32 flags);
-};
-
-struct i915_address_space {
- struct drm_mm mm;
- struct drm_device *dev;
- struct list_head global_link;
- unsigned long start;/* Start offset always 0 for dri2 */
- size_t total; /* size addr space maps (ex. 2GB for ggtt) */
-
- struct {
- dma_addr_t addr;
- struct page *page;
- } scratch;
-
- /**
- * List of objects currently involved in rendering.
- *
- * Includes buffers having the contents of their GPU caches
- * flushed, not necessarily primitives. last_rendering_seqno
- * represents when the rendering involved will be completed.
- *
- * A reference is held on the buffer while on this list.
- */
- struct list_head active_list;
-
- /**
- * LRU list of objects which are not in the ringbuffer and
- * are ready to unbind, but are still in the GTT.
- *
- * last_rendering_seqno is 0 while an object is in this list.
- *
- * A reference is not held on the buffer while on this list,
- * as merely being GTT-bound shouldn't prevent its being
- * freed, and we'll pull it off the list in the free path.
- */
- struct list_head inactive_list;
-
- /* FIXME: Need a more generic return type */
- gen6_gtt_pte_t (*pte_encode)(dma_addr_t addr,
- enum i915_cache_level level,
- bool valid); /* Create a valid PTE */
- void (*clear_range)(struct i915_address_space *vm,
- uint64_t start,
- uint64_t length,
- bool use_scratch);
- void (*insert_entries)(struct
Re: [Intel-gfx] [PATCH 16/26] drm/i915: Generalize GEN6 mapping
On Mon, Mar 17, 2014 at 10:48:48PM -0700, Ben Widawsky wrote:
Having a more general way of doing mappings will allow the ability to
easy map and unmap a specific page table. Specifically in this case, we
pass down the page directory + entry, and the page table to map. This
works similarly to the x86 code.
The same work will need to happen for GEN8. At that point I will try to
combine functionality.
pt-daddr is quite close to pgtt-pd_addr (just arguing that I'm not
convinced by the choice of daddr naming)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 61
+++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
2 files changed, 34 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5c08cf9..35acccb 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -663,18 +663,13 @@ bail:
static void gen6_dump_ppgtt(struct i915_hw_ppgtt *ppgtt, struct seq_file *m)
{
- struct drm_i915_private *dev_priv = ppgtt-base.dev-dev_private;
struct i915_address_space *vm = ppgtt-base;
- gen6_gtt_pte_t __iomem *pd_addr;
gen6_gtt_pte_t scratch_pte;
uint32_t pd_entry;
int pte, pde;
scratch_pte = vm-pte_encode(vm-scratch.addr, I915_CACHE_LLC, true);
- pd_addr = (gen6_gtt_pte_t __iomem *)dev_priv-gtt.gsm +
- ppgtt-pd.pd_offset / sizeof(gen6_gtt_pte_t);
-
seq_printf(m, VM %p (pd_offset %x-%x):\n, vm,
ppgtt-pd.pd_offset,
ppgtt-pd.pd_offset + ppgtt-num_pd_entries);
@@ -682,7 +677,7 @@ static void gen6_dump_ppgtt(struct i915_hw_ppgtt *ppgtt,
struct seq_file *m)
u32 expected;
gen6_gtt_pte_t *pt_vaddr;
dma_addr_t pt_addr = ppgtt-pd.page_tables[pde]-daddr;
- pd_entry = readl(pd_addr + pde);
+ pd_entry = readl(ppgtt-pd_addr + pde);
expected = (GEN6_PDE_ADDR_ENCODE(pt_addr) | GEN6_PDE_VALID);
if (pd_entry != expected)
@@ -718,39 +713,43 @@ static void gen6_dump_ppgtt(struct i915_hw_ppgtt
*ppgtt, struct seq_file *m)
}
}
-static void gen6_map_single(struct i915_hw_ppgtt *ppgtt,
- const unsigned pde_index,
- dma_addr_t daddr)
+/* Map pde (index) from the page directory @pd to the page table @pt */
+static void gen6_map_single(struct i915_pagedir *pd,
+ const int pde, struct i915_pagetab *pt)
{
- struct drm_i915_private *dev_priv = ppgtt-base.dev-dev_private;
- uint32_t pd_entry;
- gen6_gtt_pte_t __iomem *pd_addr = (gen6_gtt_pte_t
__iomem*)dev_priv-gtt.gsm;
- pd_addr += ppgtt-pd.pd_offset / sizeof(gen6_gtt_pte_t);
+ struct i915_hw_ppgtt *ppgtt =
+ container_of(pd, struct i915_hw_ppgtt, pd);
+ u32 pd_entry;
- pd_entry = GEN6_PDE_ADDR_ENCODE(daddr);
+ pd_entry = GEN6_PDE_ADDR_ENCODE(pt-daddr);
pd_entry |= GEN6_PDE_VALID;
- writel(pd_entry, pd_addr + pde_index);
+ writel(pd_entry, ppgtt-pd_addr + pde);
+
+ /* XXX: Caller needs to make sure the write completes if necessary */
}
/* Map all the page tables found in the ppgtt structure to incrementing page
* directories. */
-static void gen6_map_page_tables(struct i915_hw_ppgtt *ppgtt)
+static void gen6_map_page_range(struct drm_i915_private *dev_priv,
+ struct i915_pagedir *pd, unsigned pde, size_t n)
{
- struct drm_i915_private *dev_priv = ppgtt-base.dev-dev_private;
- int i;
+ if (WARN_ON(pde + n I915_PDES_PER_PD))
+ n = I915_PDES_PER_PD - pde;
I don't think the rest of the code is prepared for such errors.
- WARN_ON(ppgtt-pd.pd_offset 0x3f);
- for (i = 0; i ppgtt-num_pd_entries; i++)
- gen6_map_single(ppgtt, i, ppgtt-pd.page_tables[i]-daddr);
+ n += pde;
+
+ for (; pde n; pde++)
+ gen6_map_single(pd, pde, pd-page_tables[pde]);
+ /* Make sure write is complete before other code can use this page
+ * table. Also require for WC mapped PTEs */
readl(dev_priv-gtt.gsm);
}
static uint32_t get_pd_offset(struct i915_hw_ppgtt *ppgtt)
{
BUG_ON(ppgtt-pd.pd_offset 0x3f);
-
return (ppgtt-pd.pd_offset / 64) 16;
}
@@ -1184,7 +1183,10 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-pd.pd_offset =
ppgtt-node.start / PAGE_SIZE * sizeof(gen6_gtt_pte_t);
- gen6_map_page_tables(ppgtt);
+ ppgtt-pd_addr = (gen6_gtt_pte_t __iomem*)dev_priv-gtt.gsm +
+ ppgtt-pd.pd_offset / sizeof(gen6_gtt_pte_t);
Would this look simpler as
ppgtt-pd_addr = (gen6_gtt_pte_t __iomem *)
(dev_priv-gtt.gsm + ppgtt-pd.pd_offset);
Although the use of (gen6_gtt_pte_t __iomem*) looks
Re: [Intel-gfx] [PATCH 17/26] drm/i915: Clean up pagetable DMA map unmap
On Mon, Mar 17, 2014 at 10:48:49PM -0700, Ben Widawsky wrote: Map and unmap are common operations across all generations for pagetables. With a simple helper, we can get a nice net code reduction as well as simplified complexity. There is some room for optimization here, for instance with the multiple page mapping, that can be done in one pci_map operation. In that case however, the max value we'll ever see there is 512, and so I believe the simpler code makes this a worthwhile trade-off. Also, the range mapping functions are place holders to help transition the code. Eventually, mapping will only occur during a page allocation which will always be a discrete operation. Nice. (Except still uneasy about that WARN_ON ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/26] drm/i915: Always dma map page table allocations
On Mon, Mar 17, 2014 at 10:48:50PM -0700, Ben Widawsky wrote: There is never a case where we don't want to do it. Since we've broken up the allocations into nice clean helper functions, it's both easy and obvious to do the dma mapping at the same time. Lvgtm. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 19/26] drm/i915: Consolidate dma mappings
On Mon, Mar 17, 2014 at 10:48:51PM -0700, Ben Widawsky wrote: With a little bit of macro magic, and the fact that every page table/dir/etc. we wish to map will have a page, and daddr member, we can greatly simplify and reduce code. The patch introduces an i915_dma_map/unmap which has the same semantics as pci_map_page, but is 1 line, and doesn't require newlines, or local variables to make it fit cleanly. Notice that even the page allocation shares this same attribute. For now, I am leaving that code untouched because the macro version would be a bit on the big side - but it's a nice cleanup as well (IMO) Doesn't this make the error unwinding very fragile and likely to unmap a pci_dma_mapping_error() cookie rather than the dma_addr_t? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/26] drm/i915: Always dma map page directory allocations
On Mon, Mar 17, 2014 at 10:48:52PM -0700, Ben Widawsky wrote: Similar to the patch a few back in the series, we can always map and unmap page directories when we do their allocation and teardown. Page directory pages only exist on gen8+, so this should only effect behavior on those platforms. Lgtm. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: make semaphore signaller detection more robust
Extract all this logic into a new helper function
semaphore_wait_to_signaller_ring because:
- The current code has way too much magic.
- The current code doesn't look at bi16, which encodes VECS signallers
on HSW. Those are just added after the fact, so can't be encoded in
a neat formula.
- It blindly trust the hardware for the dev_priv-ring array
derefence, which given that we have a gpu hang at hand is scary. The
current logic can't blow up since it limits its value range
sufficiently, but that's a bit too tricky to rely on in my opinion.
Especially when we start to add bdw support.
- I'm not a big fan of the explicit ring-semaphore_register list, but
I think it's more robust to use the same mapping both when
constructing the semaphore commands and when decoding them.
- Finally add a FIXME comment about lack of broadwell support here,
like in the earlier ipehr semaphore cmd detection function.
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_irq.c | 35 ++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 0f3a6d791502..98f95ca77246 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2543,6 +2543,39 @@ ipehr_is_semaphore_wait(struct drm_device *dev, u32
ipehr)
}
static struct intel_ring_buffer *
+semaphore_wait_to_signaller_ring(struct intel_ring_buffer *ring, u32 ipehr)
+{
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
+ struct intel_ring_buffer *signaller;
+ int i;
+
+ if (INTEL_INFO(dev_priv-dev)-gen = 8) {
+ /*
+* FIXME: gen8 semaphore support - currently we don't emit
+* semaphores on bdw anyway, but this needs to be addressed when
+* we merge that code.
+*/
+ return NULL;
+ } else {
+ u32 sync_bits = ipehr MI_SEMAPHORE_SYNC_MASK;
+
+ for_each_ring(signaller, dev_priv, i) {
+ if(ring == signaller)
+ continue;
+
+ if (sync_bits ==
+ signaller-semaphore_register[ring-id])
+ return signaller;
+ }
+ }
+
+ DRM_ERROR(No signaller ring found for ring %i, ipehr 0x%08x\n,
+ ring-id, ipehr);
+
+ return NULL;
+}
+
+static struct intel_ring_buffer *
semaphore_waits_for(struct intel_ring_buffer *ring, u32 *seqno)
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
@@ -2582,7 +2615,7 @@ semaphore_waits_for(struct intel_ring_buffer *ring, u32
*seqno)
return NULL;
*seqno = ioread32(ring-virtual_start + head + 4) + 1;
- return dev_priv-ring[(ring-id + (((ipehr 17) 1) + 1)) % 3];
+ return semaphore_wait_to_signaller_ring(ring, ipehr);
}
static int semaphore_passed(struct intel_ring_buffer *ring)
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] lib: Export interval_tree
On Mon, Mar 17, 2014 at 06:08:57AM -0700, Michel Lespinasse wrote: On Mon, Mar 17, 2014 at 5:31 AM, David Woodhouse dw...@infradead.org wrote: On Mon, 2014-03-17 at 12:21 +, Chris Wilson wrote: +EXPORT_SYMBOL(interval_tree_insert); +EXPORT_SYMBOL(interval_tree_remove); +EXPORT_SYMBOL(interval_tree_iter_first); +EXPORT_SYMBOL(interval_tree_iter_next); I'd prefer to see EXPORT_SYMBOL_GPL for this. I'm fine with it either way. I think it would help if you stated the reason for your preference though ? Nobody objects? How about v3: Prefer EXPORT_SYMBOL_GPL for new library routines as the reason in the changelog for amending the patch? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable full ppgtt by default
On Thu, Mar 06, 2014 at 09:30:01PM +0100, Daniel Vetter wrote: On Thu, Mar 06, 2014 at 10:17:12AM -0800, Ben Widawsky wrote: On Thu, Mar 06, 2014 at 12:14:21PM +0100, Daniel Vetter wrote: There are too many oustanding issues: - Fence handling in the current code is broken. There's a patch series from me, but it's blocked on and extended review (which includes writing the testcases). - IOMMU mapping handling is broken, we need to properly refcount it - currently it gets destroyed when the first vma is unbound, so way too early. - There's a pending reset issue on snb. Since Mika's reset work and full ppgtt have been pulled in in separate branches and ended up intermittingly breaking each another it's unclear who's the exact culprit here. - We still have persistent evidince of crazy recursion bugs through vma_unbind and ppgtt_relase, e.g. https://bugs.freedesktop.org/show_bug.cgi?id=73383 This issue (and a few others meanwhile resolved) have blocked our performance measuring/tuning group since 3 months. - Secure batch dispatching is broken. This is blocking Brad Volkin's command checker work since 3 months. All these issues are confirmed to only happen when full ppgtt is enabled, falling back to aliasing ppgtt resolves them. But even aliasing ppgtt itself still has a regression: - We currently unconditionally bind objects into the aliasing ppgtt, which means all priviledged objects like ringbuffers are visible to unpriviledged access again. On top of that this also breaks the command checker for aliasing ppgtt, since it can't hide the validated batch any more. Furthermore topic/full-ppgtt has never been reviewed: - Lifetime rules around vma unbinding/release are unclear, resulting into this awesome hack called ppgtt_release. Which seems to take the blame for most of the recursion fallout. - Context/ring init works different on gpu reset than anywhere else. Such differeneces have in the past always lead to really hard to track down bugs. - Aliasing ppgtt is treated in a bunch of places as a real address space, but it isn't - the real address space is always the global gtt in that case. This results in a bit a mess between contexts and ppgtt object, further complication the context/ppgtt/vma lifetime rules. - We don't have any docs describing the overall concepts introduced with full ppgtt. A short, concise overview describing vmas and some of the strange bits around them (like the unbound vmas used by execbuf, or the new binding rules) really is needed. Note that a lot of the post topic/full-ppgtt merge fallout has already been addressed, this entire list here of 10 issues really only contains the still outstanding issues. Finally the 3.15 merge window is approaching and I think we need to use the remaining time to ensure that our fallback option of using aliasing ppgtt is in solid shape. Hence I think it's time to throw the switch. While at it demote the helper from static inline status because really. Cc: Ben Widawsky b...@bwidawsk.net Cc: Dave Airlie airl...@gmail.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch [snip] I want a concise list in the commit message so it's obvious as we fix things if we've achieved the goal or not. If you want to have nice prose describing the reason and/or your feelings, that's fine, but please put it after the concise list. I'll start what I want, and please fill in as needed. I believe this is all 10 you mentioned. * Fence handling broken: BUG # We have patches from me, and Paulo is signed up to do the review+igt testcase on our review board. * IOMMU Broken: BUG # No bug report thus far. I can create one if people want, but that's more work than firing up my damn ivb, enabling dmar again and fixing it. Imo the short description above should be good enough to understand the bug. * Reset issue: Bug # https://bugs.freedesktop.org/show_bug.cgi?id=74100 Mika is working on this afaik. * Secure dispatch: Failing testcase: There's a Jira with full details: VIZ-3490 * Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73383 There's also been reports from Ville and iirc Chris also had pending issues, at least compared to dinq. Note that plain igt doesn't seem to be sufficient to provoke all these cases :( * Documentation The above description is imo sufficient as a task description. There's also jira for this with more details: VIZ-3468 Then there is fuzzy stuff that you want which need more clarification on exactly what will satisfy you. * Lifetime rules: No clear requirement from you. Whomever tracks down the recursion bugs will likely have to sort his out. Essentially I want ppgtt_release gone, that entire
[Intel-gfx] [PATCH v3 1/1] kms_cursor_crc: Enabling this test for all cursor sizes
From: Sagar Kamble sagar.a.kam...@intel.com
v1: Added 128x128 and 256x256 cursor size support.
v2: Refined the test to use igt_subtest_f and automate enumeration.
v3: Restructuring test enumeration using drmGetCap. [Daniel's review comments]
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
---
tests/kms_cursor_crc.c | 131 ++---
1 file changed, 80 insertions(+), 51 deletions(-)
diff --git a/tests/kms_cursor_crc.c b/tests/kms_cursor_crc.c
index f98fbdb..9ddf9b4 100644
--- a/tests/kms_cursor_crc.c
+++ b/tests/kms_cursor_crc.c
@@ -32,6 +32,13 @@
#include igt_debugfs.h
#include igt_kms.h
+#ifndef DRM_CAP_CURSOR_WIDTH
+#define DRM_CAP_CURSOR_WIDTH 0x8
+#endif
+#ifndef DRM_CAP_CURSOR_HEIGHT
+#define DRM_CAP_CURSOR_HEIGHT 0x9
+#endif
+
enum cursor_type {
WHITE_VISIBLE,
WHITE_INVISIBLE,
@@ -124,7 +131,7 @@ static void cursor_disable(test_data_t *test_data)
}
static void test_crc(test_data_t *test_data, enum cursor_type cursor_type,
-bool onscreen)
+bool onscreen, int cursor_w, int cursor_h)
{
int left = test_data-left;
int right = test_data-right;
@@ -135,43 +142,43 @@ static void test_crc(test_data_t *test_data, enum
cursor_type cursor_type,
if (onscreen) {
/* cursor onscreen, crc should match, except when white visible
cursor is used */
- test_data-crc_must_match = cursor_type != WHITE_VISIBLE;
+ test_data-crc_must_match = (cursor_type != WHITE_VISIBLE);
/* fully inside */
do_test(test_data, left, right, top, bottom);
/* 2 pixels inside */
- do_test(test_data, left - 62, right + 62, top , bottom
);
- do_test(test_data, left , right , top - 62, bottom +
62);
- do_test(test_data, left - 62, right + 62, top - 62, bottom +
62);
+ do_test(test_data, left - (cursor_w-2), right + (cursor_w-2),
top , bottom );
+ do_test(test_data, left , right ,
top - (cursor_h-2), bottom + (cursor_h-2));
+ do_test(test_data, left - (cursor_w-2), right + (cursor_w-2),
top - (cursor_h-2), bottom + (cursor_h-2));
/* 1 pixel inside */
- do_test(test_data, left - 63, right + 63, top , bottom
);
- do_test(test_data, left , right , top - 63, bottom +
63);
- do_test(test_data, left - 63, right + 63, top - 63, bottom +
63);
+ do_test(test_data, left - (cursor_w-1), right + (cursor_w-1),
top , bottom );
+do_test(test_data, left , right ,
top - (cursor_h-1), bottom + (cursor_h-1));
+do_test(test_data, left - (cursor_w-1), right + (cursor_w-1),
top - (cursor_h-1), bottom + (cursor_h-1));
} else {
/* cursor offscreen, crc should always match */
test_data-crc_must_match = true;
/* fully outside */
- do_test(test_data, left - 64, right + 64, top , bottom
);
- do_test(test_data, left , right , top - 64, bottom +
64);
- do_test(test_data, left - 64, right + 64, top - 64, bottom +
64);
+ do_test(test_data, left - (cursor_w), right + (cursor_w), top
, bottom );
+do_test(test_data, left , right , top
- (cursor_h), bottom + (cursor_h));
+do_test(test_data, left - (cursor_w), right + (cursor_w), top
- (cursor_h), bottom + (cursor_h));
/* fully outside by 1 extra pixels */
- do_test(test_data, left - 65, right + 65, top , bottom
);
- do_test(test_data, left , right , top - 65, bottom +
65);
- do_test(test_data, left - 65, right + 65, top - 65, bottom +
65);
+ do_test(test_data, left - (cursor_w+1), right + (cursor_w+1),
top , bottom );
+do_test(test_data, left , right ,
top - (cursor_h+1), bottom + (cursor_h+1));
+do_test(test_data, left - (cursor_w+1), right + (cursor_w+1),
top - (cursor_h+1), bottom + (cursor_h+1));
/* fully outside by 2 extra pixels */
- do_test(test_data, left - 66, right + 66, top , bottom
);
- do_test(test_data, left , right , top - 66, bottom +
66);
- do_test(test_data, left - 66, right + 66, top - 66, bottom +
66);
+ do_test(test_data, left - (cursor_w+2), right + (cursor_w+2),
top , bottom );
+do_test(test_data, left , right ,
top - (cursor_h+2), bottom + (cursor_h+2));
+
Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: use the new drm helpers for dp aux
On Mon, 17 Mar 2014, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula jani.nik...@intel.com wrote:
Functionality remains largely the same as before.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 257
+-
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 116 insertions(+), 142 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 22134edc03dd..24cbf4bd36c4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -575,97 +575,77 @@ out:
return ret;
}
-/* Write data to the aux channel in native mode */
-static int
-intel_dp_aux_native_write(struct intel_dp *intel_dp,
- uint16_t address, uint8_t *send, int send_bytes)
+#define HEADER_SIZE4
+static ssize_t
+intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
+ struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
+ uint8_t txbuf[20], rxbuf[20];
+ size_t txsize, rxsize;
int ret;
- uint8_t msg[20];
- int msg_bytes;
- uint8_t ack;
- int retry;
- if (WARN_ON(send_bytes 16))
- return -E2BIG;
+ txbuf[0] = msg-request 4;
+ txbuf[1] = msg-address 8;
+ txbuf[2] = msg-address 0xff;
+ txbuf[3] = msg-size - 1;
- intel_dp_check_edp(intel_dp);
- msg[0] = DP_AUX_NATIVE_WRITE 4;
- msg[1] = address 8;
- msg[2] = address 0xff;
- msg[3] = send_bytes - 1;
- memcpy(msg[4], send, send_bytes);
- msg_bytes = send_bytes + 4;
- for (retry = 0; retry 7; retry++) {
we were retrying 7 times always, but now we are now retrying only 3
times or even none.
I'm confused, what are you referring to? drm_dp_dpcd_access() in
drm_dp_helper.c has the retry loop now.
I think you're mixing this with the intel_dp_dpcd_read_wake() wrapper,
but that ends up in drm_dp_dpcd_access() as well.
Couldn't it trigger some new bug or regression?
- ret = intel_dp_aux_ch(intel_dp, msg, msg_bytes, ack, 1);
- if (ret 0)
- return ret;
- ack = 4;
- if ((ack DP_AUX_NATIVE_REPLY_MASK) ==
DP_AUX_NATIVE_REPLY_ACK)
- return send_bytes;
- else if ((ack DP_AUX_NATIVE_REPLY_MASK) ==
DP_AUX_NATIVE_REPLY_DEFER)
- usleep_range(400, 500);
we are also not checking this ack x defer (here nor in native_write)
replies anymore.
Ditto, we store ack = 4 into msg-reply which gets checked in
drm_dp_dpcd_access().
BR,
Jani.
Don't we need it anymore? why?
- else
- return -EIO;
- }
+ switch (msg-request ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ txsize = HEADER_SIZE + msg-size;
+ rxsize = 1;
- DRM_ERROR(too many retries, giving up\n);
- return -EIO;
-}
+ if (WARN_ON(txsize 20))
+ return -E2BIG;
-/* Write a single byte to the aux channel in native mode */
-static int
-intel_dp_aux_native_write_1(struct intel_dp *intel_dp,
- uint16_t address, uint8_t byte)
-{
- return intel_dp_aux_native_write(intel_dp, address, byte, 1);
-}
+ memcpy(txbuf + HEADER_SIZE, msg-buffer, msg-size);
-/* read bytes from a native aux channel */
-static int
-intel_dp_aux_native_read(struct intel_dp *intel_dp,
-uint16_t address, uint8_t *recv, int recv_bytes)
-{
- uint8_t msg[4];
- int msg_bytes;
- uint8_t reply[20];
- int reply_bytes;
- uint8_t ack;
- int ret;
- int retry;
+ ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf,
rxsize);
+ if (ret 0) {
+ msg-reply = rxbuf[0] 4;
- if (WARN_ON(recv_bytes 19))
- return -E2BIG;
+ /* Return payload size. */
+ ret = msg-size;
+ }
+ break;
- intel_dp_check_edp(intel_dp);
- msg[0] = DP_AUX_NATIVE_READ 4;
- msg[1] = address 8;
- msg[2] = address 0xff;
- msg[3] = recv_bytes - 1;
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ txsize = HEADER_SIZE;
+ rxsize = msg-size + 1;
- msg_bytes = 4;
- reply_bytes = recv_bytes + 1;
+ if (WARN_ON(rxsize 20))
+ return -E2BIG;
- for (retry = 0; retry 7; retry++) {
- ret = intel_dp_aux_ch(intel_dp, msg, msg_bytes,
- reply, reply_bytes);
- if (ret == 0)
-
Re: [Intel-gfx] [PATCH 2/6] drm/i915: properly disable the VDD when disabling the panel
On Fri, 14 Mar 2014, Patrik Jakobsson patrik.r.jakobs...@gmail.com wrote: On Fri, Mar 14, 2014 at 2:57 PM, Daniel Vetter dan...@ffwll.ch wrote: On Fri, Mar 14, 2014 at 1:07 PM, Jani Nikula jani.nik...@linux.intel.com wrote: Fixes regression introduced by: commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 Author: Patrik Jakobsson patrik.r.jakobs...@gmail.com Date: Tue Mar 4 00:42:44 2014 +0100 drm/i915: Don't just say it, actually force edp vdd Patrik, would you mind acking/testing this patch, as it blames your commit for regressing? Testing will be hard I guess since it does the equivalent change Patrik has done to the pre-hsw dp code to the ddi hsw+ code. But a review would be nice - I've signed up Damien for this but he seems to be sick :( -Daniel Yes, as expected, this patch applied on top of -nightly is working fine. It's the EDP_FORCE_VDD bit that is required for my Macbook Air 6,x. Is the proper fix for -fixes to completely revert: dff392dbd258381a6c3164f38420593f2d291e3b Hi Patrik, I've done just that. Giving the drm-intel-fixes branch a spin would be great, if you don't mind me asking. BR, Jani. Tested-by: Patrik Jakobsson patrik.r.jakobs...@gmail.com Thanks Patrik -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH for -fixes] Revert drm/i915: don't touch the VDD when disabling the panel
On Mon, Mar 17, 2014 at 3:42 PM, Jani Nikula jani.nik...@intel.com wrote:
This reverts
commit dff392dbd258381a6c3164f38420593f2d291e3b
Author: Paulo Zanoni paulo.r.zan...@intel.com
Date: Fri Dec 6 17:32:41 2013 -0200
drm/i915: don't touch the VDD when disabling the panel
which didn't take into account
commit 6cb49835da0426f69a2931bc2a0a8156344b0e41
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sun May 20 17:14:50 2012 +0200
drm/i915: enable vdd when switching off the eDP panel
and
commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sun Aug 12 22:17:14 2012 +0200
drm/i915: reorder edp disabling to fix ivb MacBook Air
Unsurprisingly, various MacBooks failed.
Effectively the same has already been done in drm-intel-next-queued.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
Cc: Patrik Jakobsson patrik.r.jakobs...@gmail.com
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c |1 +
drivers/gpu/drm/i915/intel_dp.c | 10 +-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index e06b9e017d6b..234ac5f7bc5a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1244,6 +1244,7 @@ static void intel_ddi_post_disable(struct
intel_encoder *intel_encoder)
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
+ ironlake_edp_panel_vdd_on(intel_dp);
ironlake_edp_panel_off(intel_dp);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 41bdac44dfc1..2688f6d64bb9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1249,17 +1249,24 @@ void ironlake_edp_panel_off(struct intel_dp
*intel_dp)
DRM_DEBUG_KMS(Turn eDP power off\n);
+ WARN(!intel_dp-want_panel_vdd, Need VDD to turn off panel\n);
+
pp = ironlake_get_pp_control(intel_dp);
/* We need to switch off panel power _and_ force vdd, for
otherwise some
* panels get very unhappy and cease to work. */
- pp = ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE);
+ pp = ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET |
EDP_BLC_ENABLE);
pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
I915_WRITE(pp_ctrl_reg, pp);
POSTING_READ(pp_ctrl_reg);
+ intel_dp-want_panel_vdd = false;
+
ironlake_wait_panel_off(intel_dp);
+
+ /* We got a reference when we enabled the VDD. */
+ intel_runtime_pm_put(dev_priv);
}
void ironlake_edp_backlight_on(struct intel_dp *intel_dp)
@@ -1784,6 +1791,7 @@ static void intel_disable_dp(struct intel_encoder
*encoder)
/* Make sure the panel is off before trying to change the mode.
But also
* ensure that we have vdd while we switch off the panel. */
+ ironlake_edp_panel_vdd_on(intel_dp);
ironlake_edp_backlight_off(intel_dp);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
ironlake_edp_panel_off(intel_dp);
--
1.7.9.5
This fixes my MacBook Air problem.
Thanks
Patrik
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active
From: Chris Wilson ch...@chris-wilson.co.uk
We have reports of heavy screen corruption if we try to use the stolen
memory reserved by the BIOS whilst the DMA-Remapper is active. This
quirk may be only specific to a few machines or BIOSes, but first lets
apply the big hammer and always disable use of stolen memory when DMAR
is active.
v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Daniel, is this the color you want?
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index d58b4e287e32..28d24caa49f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -214,6 +214,13 @@ int i915_gem_init_stolen(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int bios_reserved = 0;
+#ifdef CONFIG_INTEL_IOMMU
+ if (intel_iommu_gfx_mapped) {
+ DRM_INFO(DMAR active, disabling use of stolen memory\n);
+ return 0;
+ }
+#endif
+
if (dev_priv-gtt.stolen_size == 0)
return 0;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: use the new drm helpers for dp aux
Thanks for explanations Jani and Daniel.
Feel free to use Reviewe-by: Rodrigo Vivi rodrigo.v...@gmail.com
On Tue, Mar 18, 2014 at 7:54 AM, Jani Nikula jani.nik...@intel.com wrote:
On Mon, 17 Mar 2014, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Fri, Mar 14, 2014 at 11:51 AM, Jani Nikula jani.nik...@intel.com wrote:
Functionality remains largely the same as before.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 257
+-
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 116 insertions(+), 142 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index 22134edc03dd..24cbf4bd36c4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -575,97 +575,77 @@ out:
return ret;
}
-/* Write data to the aux channel in native mode */
-static int
-intel_dp_aux_native_write(struct intel_dp *intel_dp,
- uint16_t address, uint8_t *send, int send_bytes)
+#define HEADER_SIZE4
+static ssize_t
+intel_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
{
+ struct intel_dp *intel_dp = container_of(aux, struct intel_dp, aux);
+ uint8_t txbuf[20], rxbuf[20];
+ size_t txsize, rxsize;
int ret;
- uint8_t msg[20];
- int msg_bytes;
- uint8_t ack;
- int retry;
- if (WARN_ON(send_bytes 16))
- return -E2BIG;
+ txbuf[0] = msg-request 4;
+ txbuf[1] = msg-address 8;
+ txbuf[2] = msg-address 0xff;
+ txbuf[3] = msg-size - 1;
- intel_dp_check_edp(intel_dp);
- msg[0] = DP_AUX_NATIVE_WRITE 4;
- msg[1] = address 8;
- msg[2] = address 0xff;
- msg[3] = send_bytes - 1;
- memcpy(msg[4], send, send_bytes);
- msg_bytes = send_bytes + 4;
- for (retry = 0; retry 7; retry++) {
we were retrying 7 times always, but now we are now retrying only 3
times or even none.
I'm confused, what are you referring to? drm_dp_dpcd_access() in
drm_dp_helper.c has the retry loop now.
I think you're mixing this with the intel_dp_dpcd_read_wake() wrapper,
but that ends up in drm_dp_dpcd_access() as well.
Couldn't it trigger some new bug or regression?
- ret = intel_dp_aux_ch(intel_dp, msg, msg_bytes, ack, 1);
- if (ret 0)
- return ret;
- ack = 4;
- if ((ack DP_AUX_NATIVE_REPLY_MASK) ==
DP_AUX_NATIVE_REPLY_ACK)
- return send_bytes;
- else if ((ack DP_AUX_NATIVE_REPLY_MASK) ==
DP_AUX_NATIVE_REPLY_DEFER)
- usleep_range(400, 500);
we are also not checking this ack x defer (here nor in native_write)
replies anymore.
Ditto, we store ack = 4 into msg-reply which gets checked in
drm_dp_dpcd_access().
BR,
Jani.
Don't we need it anymore? why?
- else
- return -EIO;
- }
+ switch (msg-request ~DP_AUX_I2C_MOT) {
+ case DP_AUX_NATIVE_WRITE:
+ case DP_AUX_I2C_WRITE:
+ txsize = HEADER_SIZE + msg-size;
+ rxsize = 1;
- DRM_ERROR(too many retries, giving up\n);
- return -EIO;
-}
+ if (WARN_ON(txsize 20))
+ return -E2BIG;
-/* Write a single byte to the aux channel in native mode */
-static int
-intel_dp_aux_native_write_1(struct intel_dp *intel_dp,
- uint16_t address, uint8_t byte)
-{
- return intel_dp_aux_native_write(intel_dp, address, byte, 1);
-}
+ memcpy(txbuf + HEADER_SIZE, msg-buffer, msg-size);
-/* read bytes from a native aux channel */
-static int
-intel_dp_aux_native_read(struct intel_dp *intel_dp,
-uint16_t address, uint8_t *recv, int recv_bytes)
-{
- uint8_t msg[4];
- int msg_bytes;
- uint8_t reply[20];
- int reply_bytes;
- uint8_t ack;
- int ret;
- int retry;
+ ret = intel_dp_aux_ch(intel_dp, txbuf, txsize, rxbuf,
rxsize);
+ if (ret 0) {
+ msg-reply = rxbuf[0] 4;
- if (WARN_ON(recv_bytes 19))
- return -E2BIG;
+ /* Return payload size. */
+ ret = msg-size;
+ }
+ break;
- intel_dp_check_edp(intel_dp);
- msg[0] = DP_AUX_NATIVE_READ 4;
- msg[1] = address 8;
- msg[2] = address 0xff;
- msg[3] = recv_bytes - 1;
+ case DP_AUX_NATIVE_READ:
+ case DP_AUX_I2C_READ:
+ txsize = HEADER_SIZE;
+ rxsize = msg-size + 1;
- msg_bytes = 4;
- reply_bytes = recv_bytes + 1;
+ if (WARN_ON(rxsize 20))
+ return -E2BIG;
- for (retry = 0; retry 7;
Re: [Intel-gfx] [PATCH 4/6] drm/i915/dp: use the new drm helpers for dp aux
On Tue, Mar 18, 2014 at 3:02 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: Thanks for explanations Jani and Daniel. Feel free to use Reviewe-by: Rodrigo Vivi rodrigo.v...@gmail.com Thanks to patches review, all pulled into a topic branch, will probably merge into dinq in a few days. -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
[Intel-gfx] [PATCH 2/2] uxa: Add support for server managed fds
I've just noticed that my previous patch-set for server managed fds misses
out on adding server managed fds support to uxa, because uxa does its own
/dev/dri/... device node management.
This commit switches uxa over to using intel_device.c device node management.
This is a nice cleanup and as an added bonus adds server managed fd support.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
src/intel_device.c | 14 --
src/intel_driver.h | 2 --
src/uxa/intel_driver.c | 44 +++-
3 files changed, 3 insertions(+), 57 deletions(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index 2d31ec8..8c2 100644
--- a/src/intel_device.c
+++ b/src/intel_device.c
@@ -442,20 +442,6 @@ int intel_put_master(ScrnInfoPtr scrn)
return ret;
}
-void __intel_uxa_release_device(ScrnInfoPtr scrn)
-{
- struct intel_device *dev = intel_device(scrn);
- if (dev dev-open_count == 0) {
- intel_set_device(scrn, NULL);
-
- drmClose(dev-fd);
- if (dev-render_node != dev-master_node)
- free(dev-render_node);
- free(dev-master_node);
- free(dev);
- }
-}
-
void intel_put_device(ScrnInfoPtr scrn)
{
struct intel_device *dev = intel_device(scrn);
diff --git a/src/intel_driver.h b/src/intel_driver.h
index b2cb1b9..182a30e 100644
--- a/src/intel_driver.h
+++ b/src/intel_driver.h
@@ -132,8 +132,6 @@ int intel_get_master(ScrnInfoPtr scrn);
int intel_put_master(ScrnInfoPtr scrn);
void intel_put_device(ScrnInfoPtr scrn);
-void __intel_uxa_release_device(ScrnInfoPtr scrn);
-
#define hosted() (0)
#endif /* INTEL_DRIVER_H */
diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index 7ea3b63..a0b0a48 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -248,38 +248,12 @@ static Bool intel_open_drm_master(ScrnInfoPtr scrn)
{
intel_screen_private *intel = intel_get_screen_private(scrn);
struct pci_device *dev = intel-PciInfo;
- drmSetVersion sv;
struct drm_i915_getparam gp;
int err, has_gem;
- char busid[20];
- snprintf(busid, sizeof(busid), pci:%04x:%02x:%02x.%d,
-dev-domain, dev-bus, dev-dev, dev-func);
-
- intel-drmSubFD = drmOpen(NULL, busid);
- if (intel-drmSubFD == -1) {
- xf86DrvMsg(scrn-scrnIndex, X_ERROR,
- [drm] Failed to open DRM device for %s: %s\n,
- busid, strerror(errno));
+ intel-drmSubFD = intel_get_device(scrn);
+ if (intel-drmSubFD == -1)
return FALSE;
- }
-
- /* Check that what we opened was a master or a master-capable FD,
-* by setting the version of the interface we'll use to talk to it.
-* (see DRIOpenDRMMaster() in DRI1)
-*/
- sv.drm_di_major = 1;
- sv.drm_di_minor = 1;
- sv.drm_dd_major = -1;
- sv.drm_dd_minor = -1;
- err = drmSetInterfaceVersion(intel-drmSubFD, sv);
- if (err != 0) {
- xf86DrvMsg(scrn-scrnIndex, X_ERROR,
- [drm] failed to set drm interface version.\n);
- drmClose(intel-drmSubFD);
- intel-drmSubFD = -1;
- return FALSE;
- }
has_gem = FALSE;
gp.param = I915_PARAM_HAS_GEM;
@@ -289,22 +263,12 @@ static Bool intel_open_drm_master(ScrnInfoPtr scrn)
if (!has_gem) {
xf86DrvMsg(scrn-scrnIndex, X_ERROR,
[drm] Failed to detect GEM. Kernel 2.6.28
required.\n);
- drmClose(intel-drmSubFD);
- intel-drmSubFD = -1;
return FALSE;
}
return TRUE;
}
-static void intel_close_drm_master(intel_screen_private *intel)
-{
- if (intel intel-drmSubFD 0) {
- drmClose(intel-drmSubFD);
- intel-drmSubFD = -1;
- }
-}
-
static int intel_init_bufmgr(intel_screen_private *intel)
{
int batch_size;
@@ -1090,7 +1054,7 @@ static void I830FreeScreen(FREE_SCREEN_ARGS_DECL)
if (intel !((uintptr_t)intel 1)) {
intel_mode_fini(intel);
- intel_close_drm_master(intel);
+ intel_put_device(scrn);
intel_bufmgr_fini(intel);
free(intel);
@@ -1293,8 +1257,6 @@ static Bool I830PMEvent(SCRN_ARG_TYPE arg, pmEvent event,
Bool undo)
Bool intel_init_scrn(ScrnInfoPtr scrn)
{
- __intel_uxa_release_device(scrn);
-
scrn-PreInit = I830PreInit;
scrn-ScreenInit = I830ScreenInit;
scrn-SwitchMode = I830SwitchMode;
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] intel_device: Don't close the fd on probe failure if it is server managed
I hit this corner case when testing a single X server spanning both intel gfx + an usb display link adapter driven by xf86-video-modesetting. In this scenario the intel driver gets its platformProbe method called first, and if it then closes the server managed fd, the xf86-video-modesetting gets EBADFD errors. Signed-off-by: Hans de Goede hdego...@redhat.com --- src/intel_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/intel_device.c b/src/intel_device.c index c0e1582..2d31ec8 100644 --- a/src/intel_device.c +++ b/src/intel_device.c @@ -339,7 +339,8 @@ int intel_open_device(int entity_num, return fd; err_close: - close(fd); + if (master_count == 0) /* Don't close server-fds */ + close(fd); err_path: free(local_path); return -1; -- 1.9.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] tests/gem_wait_render_timeout: Use XY_COLOR_BLT instead of COLOR_BLT.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
tests/gem_wait_render_timeout.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/gem_wait_render_timeout.c b/tests/gem_wait_render_timeout.c
index 2971752..4ecb93f 100644
--- a/tests/gem_wait_render_timeout.c
+++ b/tests/gem_wait_render_timeout.c
@@ -86,13 +86,13 @@ static void blt_color_fill(struct intel_batchbuffer *batch,
{
const unsigned short height = pages/4;
const unsigned short width = 4096;
- BEGIN_BATCH(5);
- OUT_BATCH(COLOR_BLT_CMD |
- COLOR_BLT_WRITE_ALPHA |
- COLOR_BLT_WRITE_RGB);
+ BEGIN_BATCH(6);
+ OUT_BATCH(XY_COLOR_BLT_CMD_NOLEN | 4 |
+ COLOR_BLT_WRITE_ALPHA | XY_COLOR_BLT_WRITE_RGB);
OUT_BATCH((3 24) | /* 32 Bit Color */
- 0xF0 | /* Raster OP copy background register */
+ (0xF0 16) | /* Raster OP copy background register */
0); /* Dest pitch is 0 */
+ OUT_BATCH(0);
OUT_BATCH(width 16 |
height);
OUT_RELOC(buf, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] tests/gem_wait_render_timeout: Fix for BDW
Update XY_COLOR_BLT command for Broadwell.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
tests/gem_wait_render_timeout.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/tests/gem_wait_render_timeout.c b/tests/gem_wait_render_timeout.c
index 4ecb93f..9fe6910 100644
--- a/tests/gem_wait_render_timeout.c
+++ b/tests/gem_wait_render_timeout.c
@@ -86,9 +86,17 @@ static void blt_color_fill(struct intel_batchbuffer *batch,
{
const unsigned short height = pages/4;
const unsigned short width = 4096;
- BEGIN_BATCH(6);
- OUT_BATCH(XY_COLOR_BLT_CMD_NOLEN | 4 |
- COLOR_BLT_WRITE_ALPHA | XY_COLOR_BLT_WRITE_RGB);
+
+ if (intel_gen(batch-devid) = 8) {
+ BEGIN_BATCH(8);
+ OUT_BATCH(MI_NOOP);
+ OUT_BATCH(XY_COLOR_BLT_CMD_NOLEN | 5 |
+ COLOR_BLT_WRITE_ALPHA | XY_COLOR_BLT_WRITE_RGB);
+ } else {
+ BEGIN_BATCH(6);
+ OUT_BATCH(XY_COLOR_BLT_CMD_NOLEN | 4 |
+ COLOR_BLT_WRITE_ALPHA | XY_COLOR_BLT_WRITE_RGB);
+ }
OUT_BATCH((3 24) | /* 32 Bit Color */
(0xF0 16) | /* Raster OP copy background register */
0); /* Dest pitch is 0 */
@@ -96,6 +104,8 @@ static void blt_color_fill(struct intel_batchbuffer *batch,
OUT_BATCH(width 16 |
height);
OUT_RELOC(buf, I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER, 0);
+ if (intel_gen(batch-devid) = 8)
+ OUT_BATCH(0);
OUT_BATCH(rand()); /* random pattern */
ADVANCE_BATCH();
}
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] tests/gem_gtt_hog: Use XY_COLOR_BLT instead of COLOR_BLT.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
tests/gem_gtt_hog.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/tests/gem_gtt_hog.c b/tests/gem_gtt_hog.c
index 5f14109..d22e074 100644
--- a/tests/gem_gtt_hog.c
+++ b/tests/gem_gtt_hog.c
@@ -42,9 +42,6 @@
#include i915_drm.h
#include drmtest.h
-#define BLT_WRITE_ALPHA(121)
-#define BLT_WRITE_RGB (120)
-
static const uint32_t canary = 0xdeadbeef;
static double elapsed(const struct timeval *start,
@@ -60,7 +57,7 @@ static void busy(int fd, uint32_t handle, int size, int loops)
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_pwrite gem_pwrite;
struct drm_i915_gem_create create;
- uint32_t buf[102], *b;
+ uint32_t buf[122], *b;
int i;
memset(reloc, 0, sizeof(reloc));
@@ -69,9 +66,11 @@ static void busy(int fd, uint32_t handle, int size, int
loops)
b = buf;
for (i = 0; i 20; i++) {
- *b++ = COLOR_BLT_CMD | BLT_WRITE_ALPHA | BLT_WRITE_RGB;
+ *b++ = XY_COLOR_BLT_CMD_NOLEN | 4 |
+ COLOR_BLT_WRITE_ALPHA | XY_COLOR_BLT_WRITE_RGB;
*b++ = 0xf0 16 | 1 25 | 1 24 | 4096;
- *b++ = size 12 16 | 4096;
+ *b++ = 0;
+ *b++ = size 12 16 | 1024;
reloc[i].offset = (b - buf) * sizeof(uint32_t);
reloc[i].target_handle = handle;
reloc[i].read_domains = I915_GEM_DOMAIN_RENDER;
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] tests/gem_gtt_hog: Fix for BDW
Update XY_COLOR_BLT command for Broadwell.
v2: stash devid and remove ugly double allocation. (by Chris).
v3: fix inverted blt command size and stash fd, devid and intel_gen.
v4: improved len calculation and noop between blt commands. (by Chris).
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73724
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
tests/gem_gtt_hog.c | 52 +---
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/tests/gem_gtt_hog.c b/tests/gem_gtt_hog.c
index d22e074..c7206dc 100644
--- a/tests/gem_gtt_hog.c
+++ b/tests/gem_gtt_hog.c
@@ -44,20 +44,26 @@
static const uint32_t canary = 0xdeadbeef;
+typedef struct data {
+ int fd;
+ int devid;
+ int intel_gen;
+} data_t;
+
static double elapsed(const struct timeval *start,
const struct timeval *end)
{
return 1e6*(end-tv_sec - start-tv_sec) + (end-tv_usec -
start-tv_usec);
}
-static void busy(int fd, uint32_t handle, int size, int loops)
+static void busy(data_t *data, uint32_t handle, int size, int loops)
{
struct drm_i915_gem_relocation_entry reloc[20];
struct drm_i915_gem_exec_object2 gem_exec[2];
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_pwrite gem_pwrite;
struct drm_i915_gem_create create;
- uint32_t buf[122], *b;
+ uint32_t buf[170], *b;
int i;
memset(reloc, 0, sizeof(reloc));
@@ -66,7 +72,8 @@ static void busy(int fd, uint32_t handle, int size, int loops)
b = buf;
for (i = 0; i 20; i++) {
- *b++ = XY_COLOR_BLT_CMD_NOLEN | 4 |
+ *b++ = XY_COLOR_BLT_CMD_NOLEN |
+ ((data-intel_gen = 8) ? 5 : 4) |
COLOR_BLT_WRITE_ALPHA | XY_COLOR_BLT_WRITE_RGB;
*b++ = 0xf0 16 | 1 25 | 1 24 | 4096;
*b++ = 0;
@@ -76,66 +83,68 @@ static void busy(int fd, uint32_t handle, int size, int
loops)
reloc[i].read_domains = I915_GEM_DOMAIN_RENDER;
reloc[i].write_domain = I915_GEM_DOMAIN_RENDER;
*b++ = 0;
+ if (data-intel_gen = 8)
+ *b++ = 0;
*b++ = canary;
}
*b++ = MI_BATCH_BUFFER_END;
- *b++ = 0;
+ if ((b - buf) 1)
+ *b++ = 0;
gem_exec[0].handle = handle;
gem_exec[0].flags = EXEC_OBJECT_NEEDS_FENCE;
create.handle = 0;
create.size = 4096;
- drmIoctl(fd, DRM_IOCTL_I915_GEM_CREATE, create);
+ drmIoctl(data-fd, DRM_IOCTL_I915_GEM_CREATE, create);
gem_exec[1].handle = create.handle;
gem_exec[1].relocation_count = 20;
gem_exec[1].relocs_ptr = (uintptr_t)reloc;
execbuf.buffers_ptr = (uintptr_t)gem_exec;
execbuf.buffer_count = 2;
- execbuf.batch_len = sizeof(buf);
+ execbuf.batch_len = (b - buf) * sizeof(buf[0]);
execbuf.flags = 1 11;
- if (HAS_BLT_RING(intel_get_drm_devid(fd)))
+ if (HAS_BLT_RING(data-devid))
execbuf.flags |= I915_EXEC_BLT;
gem_pwrite.handle = gem_exec[1].handle;
gem_pwrite.offset = 0;
- gem_pwrite.size = sizeof(buf);
+ gem_pwrite.size = execbuf.batch_len;
gem_pwrite.data_ptr = (uintptr_t)buf;
- if (drmIoctl(fd, DRM_IOCTL_I915_GEM_PWRITE, gem_pwrite) == 0) {
+ if (drmIoctl(data-fd, DRM_IOCTL_I915_GEM_PWRITE, gem_pwrite) == 0) {
while (loops--)
- drmIoctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, execbuf);
+ drmIoctl(data-fd, DRM_IOCTL_I915_GEM_EXECBUFFER2,
execbuf);
}
- drmIoctl(fd, DRM_IOCTL_GEM_CLOSE, create.handle);
+ drmIoctl(data-fd, DRM_IOCTL_GEM_CLOSE, create.handle);
}
-static void run(int child)
+static void run(data_t *data, int child)
{
const int size = 4096 * (256 + child * child);
const int tiling = child % 2;
const int write = child % 2;
- int fd = drm_open_any();
- uint32_t handle = gem_create(fd, size);
+ uint32_t handle = gem_create(data-fd, size);
uint32_t *ptr;
uint32_t x;
igt_assert(handle);
if (tiling != I915_TILING_NONE)
- gem_set_tiling(fd, handle, tiling, 4096);
+ gem_set_tiling(data-fd, handle, tiling, 4096);
/* load up the unfaulted bo */
- busy(fd, handle, size, 100);
+ busy(data, handle, size, 100);
/* Note that we ignore the API and rely on the implict
* set-to-gtt-domain within the fault handler.
*/
if (write) {
- ptr = gem_mmap(fd, handle, size, PROT_READ | PROT_WRITE);
+ ptr = gem_mmap(data-fd, handle, size, PROT_READ | PROT_WRITE);
ptr[rand() % (size / 4)] = canary;
} else
- ptr = gem_mmap(fd, handle, size,
Re: [Intel-gfx] [PATCH 2/2] uxa: Add support for server managed fds
On Tue, Mar 18, 2014 at 03:16:31PM +0100, Hans de Goede wrote: I've just noticed that my previous patch-set for server managed fds misses out on adding server managed fds support to uxa, because uxa does its own /dev/dri/... device node management. This commit switches uxa over to using intel_device.c device node management. This is a nice cleanup and as an added bonus adds server managed fd support. I thought this was going to be uglier... Let me double check if I was just imagining the extra complexity. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix up the forcewake timer initialization
This is a regression introduced in
commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Mar 13 12:00:29 2014 +
drm/i915: Consolidate forcewake resetting to a single function
The reordered setup sequence ended up calling del_timer_sync before
the timer was set up correctly, resulting in endless hilarity when
loading the driver.
Compared to Ben's patch (which moved around the setup_timer call to
sanitize_early) this moves the sanitize_early call around in the
driver load call. This way we avoid calling setup_timer again in the
resume code (where we also call sanitize_early).
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Tested-by: Rodrigo Vivi rodrigo.v...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76242
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 2 --
drivers/gpu/drm/i915/intel_uncore.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e4d2b9f15ae2..9faee49f210d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1608,8 +1608,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto put_bridge;
}
- intel_uncore_early_sanitize(dev);
-
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e2e328d86aff..c3832d9270a6 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -736,6 +736,8 @@ void intel_uncore_init(struct drm_device *dev)
setup_timer(dev_priv-uncore.force_wake_timer,
gen6_force_wake_timer, (unsigned long)dev_priv);
+ intel_uncore_early_sanitize(dev);
+
if (IS_VALLEYVIEW(dev)) {
dev_priv-uncore.funcs.force_wake_get = __vlv_force_wake_get;
dev_priv-uncore.funcs.force_wake_put = __vlv_force_wake_put;
--
1.8.5.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active
On Tue, Mar 18, 2014 at 02:59:04PM +0200, Jani Nikula wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
We have reports of heavy screen corruption if we try to use the stolen
memory reserved by the BIOS whilst the DMA-Remapper is active. This
quirk may be only specific to a few machines or BIOSes, but first lets
apply the big hammer and always disable use of stolen memory when DMAR
is active.
v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Daniel, is this the color you want?
Yeah, colour looks shiny ;-) Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index d58b4e287e32..28d24caa49f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -214,6 +214,13 @@ int i915_gem_init_stolen(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int bios_reserved = 0;
+#ifdef CONFIG_INTEL_IOMMU
+ if (intel_iommu_gfx_mapped) {
+ DRM_INFO(DMAR active, disabling use of stolen memory\n);
+ return 0;
+ }
+#endif
+
if (dev_priv-gtt.stolen_size == 0)
return 0;
--
1.7.9.5
--
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 v2 for -fixes] drm/i915: Disable stolen memory when DMAR is active
On Tue, Mar 18, 2014 at 05:48:28PM +0100, Daniel Vetter wrote:
On Tue, Mar 18, 2014 at 02:59:04PM +0200, Jani Nikula wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
We have reports of heavy screen corruption if we try to use the stolen
memory reserved by the BIOS whilst the DMA-Remapper is active. This
quirk may be only specific to a few machines or BIOSes, but first lets
apply the big hammer and always disable use of stolen memory when DMAR
is active.
v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
Daniel, is this the color you want?
Yeah, colour looks shiny ;-) Reviewed-by: Daniel Vetter
daniel.vet...@ffwll.ch
Correction, cc: stable is missing.
-Daniel
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_gem_stolen.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index d58b4e287e32..28d24caa49f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -214,6 +214,13 @@ int i915_gem_init_stolen(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int bios_reserved = 0;
+#ifdef CONFIG_INTEL_IOMMU
+ if (intel_iommu_gfx_mapped) {
+ DRM_INFO(DMAR active, disabling use of stolen memory\n);
+ return 0;
+ }
+#endif
+
if (dev_priv-gtt.stolen_size == 0)
return 0;
--
1.7.9.5
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 2/2] uxa: Add support for server managed fds
On Tue, Mar 18, 2014 at 03:16:28PM +, Chris Wilson wrote: On Tue, Mar 18, 2014 at 03:16:31PM +0100, Hans de Goede wrote: I've just noticed that my previous patch-set for server managed fds misses out on adding server managed fds support to uxa, because uxa does its own /dev/dri/... device node management. This commit switches uxa over to using intel_device.c device node management. This is a nice cleanup and as an added bonus adds server managed fd support. I thought this was going to be uglier... Let me double check if I was just imagining the extra complexity. No it was that easy, and we could remove a few more lines as well. Thanks for the patches, pushed. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] uxa: Support BLT ring flushes on Broadwell, but not render ring flushes.
On 03/18/2014 01:29 AM, Chris Wilson wrote: On Mon, Mar 17, 2014 at 09:27:16AM -0700, Kenneth Graunke wrote: Chris, In the future, if you're going to rewrite significant portions of my patches, could you please at least put your Signed-off-by or something on it? In the version of uxa: Enable BLT acceleration on Broadwell., you committed, at least half the patch was not actually written by me, and the resulting code either hit assertion failures or GPU hangs if run at all. It's pretty disconcerting to see code committed under my name, with my Signed-off-by, that doesn't work and which I've never even seen before. I do apologise that you felt I made substantive changes to the patch. As far I was concerned the addition of the libdrm_intel version bump in configure (a vital build fix), the change in if-else cascade (cosmetic) and the only functional change of disabling TexturedVideo for gen8+ were trivial. The fact that the original patch made an assumption that was then broken by not applying the first patch in the series was not altered by those changes. And I should have realised that at the time. -Chris Definitely thanks for those fixes! I should've remembered the libdrm requirement bump. Also, thanks for taking the patches. --Ken signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/20] drm/i915: use GEN8_IRQ_INIT on GEN5
On Fri, Mar 07, 2014 at 08:10:19PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And rename is to GEN5_IRQ_INIT.
We have discussed doing equivalent changes on July 2013, and I even
sent a patch series for this: [PATCH 00/15] Unify interrupt register
init/reset. Now that the BDW code was merged, I have one more
argument in favor of these changes.
Here's what really changes with the Gen 5 IRQ init code:
- We now clear the IIR registers at preinstall (they are also
cleared at postinstall, but we will change that later).
- We have an additional POSTING_READ at the IMR register.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 49
+++--
1 file changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 852844d..7be7da1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -80,12 +80,30 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
+/*
+ * IIR can theoretically queue up two events. Be paranoid.
+ * Also, make sure callers of these macros have something equivalent to a
+ * POSTING_READ on the IIR register.
+ * */
I don't understand what you mean in this comment. If you're always going
to sending a posting read after the second IIR write, why not just put
it in the macro?
The reason it wasn't in my original macro is because we've done the
posting read on IER, and IMR - so we're not going to get new interrupts.
When the second IIR write lands is irrelevant. The POSTING_READ in
between is to prevent the [probably impossible] case of the writes
getting collapsed into one write.
+#define GEN8_IRQ_INIT_NDX(type, which) do { \
+ I915_WRITE(GEN8_##type##_IMR(which), 0x); \
+ POSTING_READ(GEN8_##type##_IMR(which)); \
+ I915_WRITE(GEN8_##type##_IER(which), 0); \
+ I915_WRITE(GEN8_##type##_IIR(which), 0x); \
+ POSTING_READ(GEN8_##type##_IIR(which)); \
+ I915_WRITE(GEN8_##type##_IIR(which), 0x); \
+} while (0)
+
#define GEN5_IRQ_INIT(type) do { \
I915_WRITE(type##IMR, 0x); \
+ POSTING_READ(type##IMR); \
I915_WRITE(type##IER, 0); \
- POSTING_READ(type##IER); \
+ I915_WRITE(type##IIR, 0x); \
+ POSTING_READ(type##IIR); \
+ I915_WRITE(type##IIR, 0x); \
} while (0)
+
/* For display hotplug interrupt */
static void
ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -2789,6 +2807,7 @@ static void gen5_gt_irq_preinstall(struct drm_device
*dev)
GEN5_IRQ_INIT(GT);
if (INTEL_INFO(dev)-gen = 6)
GEN5_IRQ_INIT(GEN6_PM);
+ POSTING_READ(GTIIR);
}
/* drm_dma.h hooks
@@ -2843,25 +2862,6 @@ static void gen8_irq_preinstall(struct drm_device *dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- /* IIR can theoretically queue up two events. Be paranoid */
-#define GEN8_IRQ_INIT_NDX(type, which) do { \
- I915_WRITE(GEN8_##type##_IMR(which), 0x); \
- POSTING_READ(GEN8_##type##_IMR(which)); \
- I915_WRITE(GEN8_##type##_IER(which), 0); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- } while (0)
-
-#define GEN8_IRQ_INIT(type) do { \
- I915_WRITE(GEN8_##type##_IMR, 0x); \
- POSTING_READ(GEN8_##type##_IMR); \
- I915_WRITE(GEN8_##type##_IER, 0); \
- I915_WRITE(GEN8_##type##_IIR, 0x); \
- POSTING_READ(GEN8_##type##_IIR); \
- I915_WRITE(GEN8_##type##_IIR, 0x); \
- } while (0)
-
GEN8_IRQ_INIT_NDX(GT, 0);
GEN8_IRQ_INIT_NDX(GT, 1);
GEN8_IRQ_INIT_NDX(GT, 2);
@@ -2871,12 +2871,9 @@ static void gen8_irq_preinstall(struct drm_device *dev)
GEN8_IRQ_INIT_NDX(DE_PIPE, pipe);
}
- GEN8_IRQ_INIT(DE_PORT);
- GEN8_IRQ_INIT(DE_MISC);
- GEN8_IRQ_INIT(PCU);
-#undef GEN8_IRQ_INIT
-#undef GEN8_IRQ_INIT_NDX
-
+ GEN5_IRQ_INIT(GEN8_DE_PORT_);
+ GEN5_IRQ_INIT(GEN8_DE_MISC_);
+ GEN5_IRQ_INIT(GEN8_PCU_);
POSTING_READ(GEN8_PCU_IIR);
ibx_irq_preinstall(dev);
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/20] drm/i915: properly clear IIR at irq_uninstall on Gen5+
On Fri, Mar 07, 2014 at 08:10:22PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The IRQ_INIT and IRQ_FINI macros are basically the same thing, with
the exception that IRQ_FINI doesn't properly clear IIR twice and
doesn't have as many POSTING_READs as IRQ_INIT. So rename the macro to
IRQ_RESET and use it everywhere.
Make me happy and call it GEN5_IRQ_DISABLE(). Also note, I've argued
with the, doesn't properly clear IIR twice in a previous patch, but
that's not a big deal.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 76
+++--
1 file changed, 28 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f681462..73f1125 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -85,7 +85,7 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
* Also, make sure callers of these macros have something equivalent to a
* POSTING_READ on the IIR register.
* */
-#define GEN8_IRQ_INIT_NDX(type, which) do { \
+#define GEN8_IRQ_RESET_NDX(type, which) do { \
I915_WRITE(GEN8_##type##_IMR(which), 0x); \
POSTING_READ(GEN8_##type##_IMR(which)); \
I915_WRITE(GEN8_##type##_IER(which), 0); \
@@ -94,7 +94,7 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
I915_WRITE(GEN8_##type##_IIR(which), 0x); \
} while (0)
-#define GEN5_IRQ_INIT(type) do { \
+#define GEN5_IRQ_RESET(type) do { \
I915_WRITE(type##IMR, 0x); \
POSTING_READ(type##IMR); \
I915_WRITE(type##IER, 0); \
@@ -103,12 +103,6 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
I915_WRITE(type##IIR, 0x); \
} while (0)
-#define GEN5_IRQ_FINI(type) do { \
- I915_WRITE(type##IMR, 0x); \
- I915_WRITE(type##IER, 0); \
- I915_WRITE(type##IIR, I915_READ(type##IIR)); \
-} while (0)
-
/* For display hotplug interrupt */
static void
ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -2794,7 +2788,7 @@ static void ibx_irq_preinstall(struct drm_device *dev)
if (HAS_PCH_NOP(dev))
return;
- GEN5_IRQ_INIT(SDE);
+ GEN5_IRQ_RESET(SDE);
/*
* SDEIER is also touched by the interrupt handler to work around missed
* PCH interrupts. Hence we can't update it after the interrupt handler
@@ -2809,9 +2803,9 @@ static void gen5_gt_irq_preinstall(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- GEN5_IRQ_INIT(GT);
+ GEN5_IRQ_RESET(GT);
if (INTEL_INFO(dev)-gen = 6)
- GEN5_IRQ_INIT(GEN6_PM);
+ GEN5_IRQ_RESET(GEN6_PM);
POSTING_READ(GTIIR);
}
@@ -2823,7 +2817,7 @@ static void ironlake_irq_preinstall(struct drm_device
*dev)
I915_WRITE(HWSTAM, 0xeffe);
- GEN5_IRQ_INIT(DE);
+ GEN5_IRQ_RESET(DE);
gen5_gt_irq_preinstall(dev);
@@ -2867,18 +2861,18 @@ static void gen8_irq_preinstall(struct drm_device
*dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- GEN8_IRQ_INIT_NDX(GT, 0);
- GEN8_IRQ_INIT_NDX(GT, 1);
- GEN8_IRQ_INIT_NDX(GT, 2);
- GEN8_IRQ_INIT_NDX(GT, 3);
+ GEN8_IRQ_RESET_NDX(GT, 0);
+ GEN8_IRQ_RESET_NDX(GT, 1);
+ GEN8_IRQ_RESET_NDX(GT, 2);
+ GEN8_IRQ_RESET_NDX(GT, 3);
for_each_pipe(pipe) {
- GEN8_IRQ_INIT_NDX(DE_PIPE, pipe);
+ GEN8_IRQ_RESET_NDX(DE_PIPE, pipe);
}
- GEN5_IRQ_INIT(GEN8_DE_PORT_);
- GEN5_IRQ_INIT(GEN8_DE_MISC_);
- GEN5_IRQ_INIT(GEN8_PCU_);
+ GEN5_IRQ_RESET(GEN8_DE_PORT_);
+ GEN5_IRQ_RESET(GEN8_DE_MISC_);
+ GEN5_IRQ_RESET(GEN8_PCU_);
POSTING_READ(GEN8_PCU_IIR);
ibx_irq_preinstall(dev);
@@ -3237,32 +3231,17 @@ static void gen8_irq_uninstall(struct drm_device *dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
-#define GEN8_IRQ_FINI_NDX(type, which) do { \
- I915_WRITE(GEN8_##type##_IMR(which), 0x); \
- I915_WRITE(GEN8_##type##_IER(which), 0); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- } while (0)
-
-#define GEN8_IRQ_FINI(type) do { \
- I915_WRITE(GEN8_##type##_IMR, 0x); \
- I915_WRITE(GEN8_##type##_IER, 0); \
- I915_WRITE(GEN8_##type##_IIR, 0x); \
- } while (0)
+ GEN8_IRQ_RESET_NDX(GT, 0);
+ GEN8_IRQ_RESET_NDX(GT, 1);
+ GEN8_IRQ_RESET_NDX(GT, 2);
+ GEN8_IRQ_RESET_NDX(GT, 3);
- GEN8_IRQ_FINI_NDX(GT, 0);
- GEN8_IRQ_FINI_NDX(GT, 1);
- GEN8_IRQ_FINI_NDX(GT, 2);
- GEN8_IRQ_FINI_NDX(GT, 3);
-
- for_each_pipe(pipe) {
- GEN8_IRQ_FINI_NDX(DE_PIPE, pipe);
- }
+
Re: [Intel-gfx] [PATCH 03/20] drm/i915: use GEN8_IRQ_INIT on GEN5
On Tue, Mar 18, 2014 at 10:11:38AM -0700, Ben Widawsky wrote:
On Fri, Mar 07, 2014 at 08:10:19PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And rename is to GEN5_IRQ_INIT.
We have discussed doing equivalent changes on July 2013, and I even
sent a patch series for this: [PATCH 00/15] Unify interrupt register
init/reset. Now that the BDW code was merged, I have one more
argument in favor of these changes.
Here's what really changes with the Gen 5 IRQ init code:
- We now clear the IIR registers at preinstall (they are also
cleared at postinstall, but we will change that later).
- We have an additional POSTING_READ at the IMR register.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 49
+++--
1 file changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 852844d..7be7da1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -80,12 +80,30 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
+/*
+ * IIR can theoretically queue up two events. Be paranoid.
+ * Also, make sure callers of these macros have something equivalent to a
+ * POSTING_READ on the IIR register.
+ * */
I don't understand what you mean in this comment. If you're always going
to sending a posting read after the second IIR write, why not just put
it in the macro?
Bspec says if there's a 2nd interrupt queued up IMR/IER don't affect that
bit and it will show up /sometimes/ after the first bit has been cleared
from IIR. My best guess for that was on the next read, hence the
POSTING_READ to make sure it happens.
Or do you mean something else?
In any case a bit of Bspec citation for this would be appropriate.
-Daniel
The reason it wasn't in my original macro is because we've done the
posting read on IER, and IMR - so we're not going to get new interrupts.
When the second IIR write lands is irrelevant. The POSTING_READ in
between is to prevent the [probably impossible] case of the writes
getting collapsed into one write.
+#define GEN8_IRQ_INIT_NDX(type, which) do { \
+ I915_WRITE(GEN8_##type##_IMR(which), 0x); \
+ POSTING_READ(GEN8_##type##_IMR(which)); \
+ I915_WRITE(GEN8_##type##_IER(which), 0); \
+ I915_WRITE(GEN8_##type##_IIR(which), 0x); \
+ POSTING_READ(GEN8_##type##_IIR(which)); \
+ I915_WRITE(GEN8_##type##_IIR(which), 0x); \
+} while (0)
+
#define GEN5_IRQ_INIT(type) do { \
I915_WRITE(type##IMR, 0x); \
+ POSTING_READ(type##IMR); \
I915_WRITE(type##IER, 0); \
- POSTING_READ(type##IER); \
+ I915_WRITE(type##IIR, 0x); \
+ POSTING_READ(type##IIR); \
+ I915_WRITE(type##IIR, 0x); \
} while (0)
+
/* For display hotplug interrupt */
static void
ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -2789,6 +2807,7 @@ static void gen5_gt_irq_preinstall(struct drm_device
*dev)
GEN5_IRQ_INIT(GT);
if (INTEL_INFO(dev)-gen = 6)
GEN5_IRQ_INIT(GEN6_PM);
+ POSTING_READ(GTIIR);
}
/* drm_dma.h hooks
@@ -2843,25 +2862,6 @@ static void gen8_irq_preinstall(struct drm_device
*dev)
I915_WRITE(GEN8_MASTER_IRQ, 0);
POSTING_READ(GEN8_MASTER_IRQ);
- /* IIR can theoretically queue up two events. Be paranoid */
-#define GEN8_IRQ_INIT_NDX(type, which) do { \
- I915_WRITE(GEN8_##type##_IMR(which), 0x); \
- POSTING_READ(GEN8_##type##_IMR(which)); \
- I915_WRITE(GEN8_##type##_IER(which), 0); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- POSTING_READ(GEN8_##type##_IIR(which)); \
- I915_WRITE(GEN8_##type##_IIR(which), 0x); \
- } while (0)
-
-#define GEN8_IRQ_INIT(type) do { \
- I915_WRITE(GEN8_##type##_IMR, 0x); \
- POSTING_READ(GEN8_##type##_IMR); \
- I915_WRITE(GEN8_##type##_IER, 0); \
- I915_WRITE(GEN8_##type##_IIR, 0x); \
- POSTING_READ(GEN8_##type##_IIR); \
- I915_WRITE(GEN8_##type##_IIR, 0x); \
- } while (0)
-
GEN8_IRQ_INIT_NDX(GT, 0);
GEN8_IRQ_INIT_NDX(GT, 1);
GEN8_IRQ_INIT_NDX(GT, 2);
@@ -2871,12 +2871,9 @@ static void gen8_irq_preinstall(struct drm_device
*dev)
GEN8_IRQ_INIT_NDX(DE_PIPE, pipe);
}
- GEN8_IRQ_INIT(DE_PORT);
- GEN8_IRQ_INIT(DE_MISC);
- GEN8_IRQ_INIT(PCU);
-#undef GEN8_IRQ_INIT
-#undef GEN8_IRQ_INIT_NDX
-
+ GEN5_IRQ_INIT(GEN8_DE_PORT_);
+ GEN5_IRQ_INIT(GEN8_DE_MISC_);
+ GEN5_IRQ_INIT(GEN8_PCU_);
POSTING_READ(GEN8_PCU_IIR);
ibx_irq_preinstall(dev);
--
[Intel-gfx] [PATCH] drm/i915: Use the correct format string modifier for ptrdiff_t
When compiling on 32bits, I have the following warning:
drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’
expects argument of type ‘long int’, but argument 7 has type ‘int’
[-Wformat=]
DRM_DEBUG_DRIVER(CMD: Command length exceeds batch length: 0x%08X
length=%d batchlen=%ld\n,
The ptrdiff_t type has its own modifier: 't'.
Cc: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7a5756e..0eaed44 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -402,7 +402,7 @@ int i915_parse_cmds(struct intel_ring_buffer *ring,
length = ((*cmd desc-length.mask) + LENGTH_BIAS);
if ((batch_end - cmd) length) {
- DRM_DEBUG_DRIVER(CMD: Command length exceeds batch
length: 0x%08X length=%d batchlen=%ld\n,
+ DRM_DEBUG_DRIVER(CMD: Command length exceeds batch
length: 0x%08X length=%d batchlen=%td\n,
*cmd,
length,
batch_end - cmd);
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use the correct format string modifier for ptrdiff_t
Thanks for fixing this Damien.
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Tue, Mar 18, 2014 at 05:43:08PM +, Damien Lespiau wrote:
When compiling on 32bits, I have the following warning:
drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’
expects argument of type ‘long int’, but argument 7 has type ‘int’
[-Wformat=]
DRM_DEBUG_DRIVER(CMD: Command length exceeds batch length: 0x%08X
length=%d batchlen=%ld\n,
The ptrdiff_t type has its own modifier: 't'.
Cc: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7a5756e..0eaed44 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -402,7 +402,7 @@ int i915_parse_cmds(struct intel_ring_buffer *ring,
length = ((*cmd desc-length.mask) + LENGTH_BIAS);
if ((batch_end - cmd) length) {
- DRM_DEBUG_DRIVER(CMD: Command length exceeds batch
length: 0x%08X length=%d batchlen=%ld\n,
+ DRM_DEBUG_DRIVER(CMD: Command length exceeds batch
length: 0x%08X length=%d batchlen=%td\n,
*cmd,
length,
batch_end - cmd);
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/20] drm/i915: don't forget to uninstall the PM IRQs
On Fri, Mar 07, 2014 at 08:10:21PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com It's the only thihg missing, apparently. s/thihg/thing There is a potential fixup in patch 3, but with or without, everything up through here is: Reviewed-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com --- drivers/gpu/drm/i915/i915_irq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index a9f173c..f681462 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -3314,6 +3314,8 @@ static void ironlake_irq_uninstall(struct drm_device *dev) I915_WRITE(GEN7_ERR_INT, I915_READ(GEN7_ERR_INT)); GEN5_IRQ_FINI(GT); + if (INTEL_INFO(dev)-gen = 6) + GEN5_IRQ_FINI(GEN6_PM); if (HAS_PCH_NOP(dev)) return; -- 1.8.5.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: no MCHBAR on VLV
Junxiao, can you add you reviewed-by to this patch?
Thanks,
Jesse
On Mon, 3 Mar 2014 14:27:57 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
So don't try to allocate and program it, we're only fooling ourselves.
Reported-by: Chang, Junxiao junxiao.ch...@intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 7688abc..22f839b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1187,6 +1187,9 @@ intel_setup_mchbar(struct drm_device *dev)
u32 temp;
bool enabled;
+ if (IS_VALLEYVIEW(dev))
+ return;
+
dev_priv-mchbar_need_disable = false;
if (IS_I915G(dev) || IS_I915GM(dev)) {
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/20] drm/i915: add GEN5_IRQ_INIT
On Fri, Mar 07, 2014 at 08:10:23PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
And the equivalent GEN8_IRQ_INIT_NDX macro. These macros are for the
postinstall functions. The next patch will improve this macro.
Notice that I could have included POSTING_READ calls to the macro, but
that would mean the code would do a few more POSTING_READs than
necessary. OTOH it would be more fail-proof. I can change that if
needed.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 33 ++---
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73f1125..6d4daf2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -103,6 +103,16 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
I915_WRITE(type##IIR, 0x); \
} while (0)
+#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) do { \
+ I915_WRITE(GEN8_##type##_IMR(which), (imr_val)); \
+ I915_WRITE(GEN8_##type##_IER(which), (ier_val)); \
+} while (0)
+
+#define GEN5_IRQ_INIT(type, imr_val, ier_val) do { \
+ I915_WRITE(type##IMR, (imr_val)); \
+ I915_WRITE(type##IER, (ier_val)); \
+} while (0)
+
I don't like these macros. IMO they make the code less readable, and
only save a couple LOC. They don't prevent any programmer errors either,
since all the logic is still contained in the values you pass in.
I'll read on ahead to see if they're required in your grand scheme.
/* For display hotplug interrupt */
static void
ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -2957,9 +2967,7 @@ static void gen5_gt_irq_postinstall(struct drm_device
*dev)
}
I915_WRITE(GTIIR, I915_READ(GTIIR));
- I915_WRITE(GTIMR, dev_priv-gt_irq_mask);
- I915_WRITE(GTIER, gt_irqs);
- POSTING_READ(GTIER);
+ GEN5_IRQ_INIT(GT, dev_priv-gt_irq_mask, gt_irqs);
if (INTEL_INFO(dev)-gen = 6) {
pm_irqs |= GEN6_PM_RPS_EVENTS;
@@ -2969,10 +2977,9 @@ static void gen5_gt_irq_postinstall(struct drm_device
*dev)
dev_priv-pm_irq_mask = 0x;
I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
- I915_WRITE(GEN6_PMIMR, dev_priv-pm_irq_mask);
- I915_WRITE(GEN6_PMIER, pm_irqs);
- POSTING_READ(GEN6_PMIER);
+ GEN5_IRQ_INIT(GEN6_PM, dev_priv-pm_irq_mask, pm_irqs);
}
+ POSTING_READ(GTIER);
}
static int ironlake_irq_postinstall(struct drm_device *dev)
@@ -3005,9 +3012,7 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
/* 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);
+ GEN5_IRQ_INIT(DE, dev_priv-irq_mask, display_mask | extra_mask);
gen5_gt_irq_postinstall(dev);
@@ -3172,8 +3177,7 @@ static void gen8_gt_irq_postinstall(struct
drm_i915_private *dev_priv)
if (tmp)
DRM_ERROR(Interrupt (%d) should have been masked in
pre-install 0x%08x\n,
i, tmp);
- I915_WRITE(GEN8_GT_IMR(i), ~gt_interrupts[i]);
- I915_WRITE(GEN8_GT_IER(i), gt_interrupts[i]);
+ GEN8_IRQ_INIT_NDX(GT, i, ~gt_interrupts[i], gt_interrupts[i]);
}
POSTING_READ(GEN8_GT_IER(0));
}
@@ -3196,13 +3200,12 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
if (tmp)
DRM_ERROR(Interrupt (%d) should have been masked in
pre-install 0x%08x\n,
pipe, tmp);
- I915_WRITE(GEN8_DE_PIPE_IMR(pipe), dev_priv-de_irq_mask[pipe]);
- I915_WRITE(GEN8_DE_PIPE_IER(pipe), de_pipe_enables);
+ GEN8_IRQ_INIT_NDX(DE_PIPE, pipe, dev_priv-de_irq_mask[pipe],
+ de_pipe_enables);
}
POSTING_READ(GEN8_DE_PIPE_ISR(0));
- I915_WRITE(GEN8_DE_PORT_IMR, ~GEN8_AUX_CHANNEL_A);
- I915_WRITE(GEN8_DE_PORT_IER, GEN8_AUX_CHANNEL_A);
+ GEN5_IRQ_INIT(GEN8_DE_PORT_, ~GEN8_AUX_CHANNEL_A, GEN8_AUX_CHANNEL_A);
POSTING_READ(GEN8_DE_PORT_IER);
}
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/20] drm/i915: check if IIR is still zero at postinstall on Gen5+
On Fri, Mar 07, 2014 at 08:10:24PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Instead of trying to clear it again. It should already be masked and
disabled and zeroed at preinstall/uninstall.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6d4daf2..4d0a8b1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -103,12 +103,24 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
I915_WRITE(type##IIR, 0x); \
} while (0)
+/*
+ * We should clear IMR at preinstall/uninstall, and just check at
postinstall.
+ */
+#define GEN5_ASSERT_IIR_IS_ZERO(reg) do { \
+ u32 val = I915_READ(reg); \
+ if (val) \
+ DRM_ERROR(Interrupt register 0x%x is not zero: 0x%08x\n, \
+ (reg), val); \
+} while (0)
+
#define GEN8_IRQ_INIT_NDX(type, which, imr_val, ier_val) do { \
+ GEN5_ASSERT_IIR_IS_ZERO(GEN8_##type##_IIR(which)); \
I915_WRITE(GEN8_##type##_IMR(which), (imr_val)); \
I915_WRITE(GEN8_##type##_IER(which), (ier_val)); \
} while (0)
#define GEN5_IRQ_INIT(type, imr_val, ier_val) do { \
+ GEN5_ASSERT_IIR_IS_ZERO(type##IIR); \
I915_WRITE(type##IMR, (imr_val)); \
I915_WRITE(type##IER, (ier_val)); \
} while (0)
Okay, this is replacing a POSTED_WRITE, with a (slower) POSTING_READ
which gives an error that we can do nothing about other than clear it
anyway.
I'd be in favor of dropping this patch.
@@ -2940,7 +2952,7 @@ static void ibx_irq_postinstall(struct drm_device *dev)
I915_WRITE(SERR_INT, I915_READ(SERR_INT));
}
- I915_WRITE(SDEIIR, I915_READ(SDEIIR));
+ GEN5_ASSERT_IIR_IS_ZERO(SDEIIR);
I915_WRITE(SDEIMR, ~mask);
}
@@ -2966,7 +2978,6 @@ 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));
GEN5_IRQ_INIT(GT, dev_priv-gt_irq_mask, gt_irqs);
if (INTEL_INFO(dev)-gen = 6) {
@@ -2976,7 +2987,6 @@ static void gen5_gt_irq_postinstall(struct drm_device
*dev)
pm_irqs |= PM_VEBOX_USER_INTERRUPT;
dev_priv-pm_irq_mask = 0x;
- I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
GEN5_IRQ_INIT(GEN6_PM, dev_priv-pm_irq_mask, pm_irqs);
}
POSTING_READ(GTIER);
@@ -3010,8 +3020,6 @@ 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));
GEN5_IRQ_INIT(DE, dev_priv-irq_mask, display_mask | extra_mask);
gen5_gt_irq_postinstall(dev);
@@ -3172,13 +3180,8 @@ static void gen8_gt_irq_postinstall(struct
drm_i915_private *dev_priv)
GT_RENDER_USER_INTERRUPT GEN8_VECS_IRQ_SHIFT
};
- for (i = 0; i ARRAY_SIZE(gt_interrupts); i++) {
- u32 tmp = I915_READ(GEN8_GT_IIR(i));
- if (tmp)
- DRM_ERROR(Interrupt (%d) should have been masked in
pre-install 0x%08x\n,
- i, tmp);
+ for (i = 0; i ARRAY_SIZE(gt_interrupts); i++)
GEN8_IRQ_INIT_NDX(GT, i, ~gt_interrupts[i], gt_interrupts[i]);
- }
POSTING_READ(GEN8_GT_IER(0));
}
@@ -3195,14 +3198,9 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
dev_priv-de_irq_mask[PIPE_B] = ~de_pipe_masked;
dev_priv-de_irq_mask[PIPE_C] = ~de_pipe_masked;
- for_each_pipe(pipe) {
- u32 tmp = I915_READ(GEN8_DE_PIPE_IIR(pipe));
- if (tmp)
- DRM_ERROR(Interrupt (%d) should have been masked in
pre-install 0x%08x\n,
- pipe, tmp);
+ for_each_pipe(pipe)
GEN8_IRQ_INIT_NDX(DE_PIPE, pipe, dev_priv-de_irq_mask[pipe],
de_pipe_enables);
- }
POSTING_READ(GEN8_DE_PIPE_ISR(0));
GEN5_IRQ_INIT(GEN8_DE_PORT_, ~GEN8_AUX_CHANNEL_A, GEN8_AUX_CHANNEL_A);
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/20] drm/i915: fix SERR_INT init/reset code
On Fri, Mar 07, 2014 at 08:10:25PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
The SERR_INT register is very similar to the other IIR registers, so
let's zero it at preinstall/uninstall and WARN for a non-zero value at
postinstall, just like we do with the other IIR registers. For this
one, there's no need to double-clear since it can't store more than
one interrupt.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Without the assert that I don't like, this is
Reviewed-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4d0a8b1..d295624 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2811,6 +2811,10 @@ static void ibx_irq_preinstall(struct drm_device *dev)
return;
GEN5_IRQ_RESET(SDE);
+
+ if (HAS_PCH_CPT(dev) || HAS_PCH_LPT(dev))
+ I915_WRITE(SERR_INT, 0x);
+
/*
* SDEIER is also touched by the interrupt handler to work around missed
* PCH interrupts. Hence we can't update it after the interrupt handler
@@ -2949,7 +2953,7 @@ static void ibx_irq_postinstall(struct drm_device *dev)
} else {
mask = SDE_GMBUS_CPT | SDE_AUX_MASK_CPT | SDE_ERROR_CPT;
- I915_WRITE(SERR_INT, I915_READ(SERR_INT));
+ GEN5_ASSERT_IIR_IS_ZERO(SERR_INT);
}
GEN5_ASSERT_IIR_IS_ZERO(SDEIIR);
@@ -3303,7 +3307,7 @@ static void ironlake_irq_uninstall(struct drm_device
*dev)
GEN5_IRQ_RESET(SDE);
if (HAS_PCH_CPT(dev) || HAS_PCH_LPT(dev))
- I915_WRITE(SERR_INT, I915_READ(SERR_INT));
+ I915_WRITE(SERR_INT, 0x);
}
static void i8xx_irq_preinstall(struct drm_device * dev)
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/26] drm/i915: Page table helpers, and define renames
On Tue, 18 Mar 2014 09:05:58 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Mar 17, 2014 at 10:48:44PM -0700, Ben Widawsky wrote:
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -1,8 +1,11 @@
#ifndef _I915_GEM_GTT_H
#define _I915_GEM_GTT_H
-#define GEN6_PPGTT_PD_ENTRIES 512
-#define I915_PPGTT_PT_ENTRIES (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
+/* GEN Agnostic defines */
+#define I915_PDES_PER_PD 512
+#define I915_PTE_MASK (PAGE_SHIFT-1)
That looks decidely fishy.
PAGE_SHIFT is 12 - PTE_MASK = 0xb
+#define I915_PDE_MASK (I915_PDES_PER_PD-1)
+
typedef uint32_t gen6_gtt_pte_t;
typedef uint64_t gen8_gtt_pte_t;
typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
@@ -23,6 +26,98 @@ typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
#define GEN6_PTE_ADDR_ENCODE(addr) GEN6_GTT_ADDR_ENCODE(addr)
#define HSW_PTE_ADDR_ENCODE(addr) HSW_GTT_ADDR_ENCODE(addr)
+
+/* GEN6 PPGTT resembles a 2 level page table:
+ * 31:22 | 21:12 | 11:0
+ * PDE | PTE | offset
+ */
+#define GEN6_PDE_SHIFT 22
+#define GEN6_PTES_PER_PT (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
+
+static inline uint32_t i915_pte_index(uint64_t address, uint32_t pde_shift)
+{
+ const uint32_t mask = (1 (pde_shift - PAGE_SHIFT)) - 1;
+ return (address PAGE_SHIFT) mask;
+}
+
+/* Helper to counts the number of PTEs within the given length. This count
does
+ * not cross a page table boundary, so the max value would be
+ * GEN6_PTES_PER_PT for GEN6, and GEN8_PTES_PER_PT for GEN8.
+ */
+static inline size_t i915_pte_count(uint64_t addr, size_t length,
+ uint32_t pde_shift)
+{
+ const uint64_t pd_mask = ~((1 pde_shift) - 1);
+ uint64_t end;
+
+ if (WARN_ON(!length))
+ return 0;
+
+ if (WARN_ON(addr % PAGE_SIZE))
+ addr = round_down(addr, PAGE_SIZE);
+
+ if (WARN_ON(length % PAGE_SIZE))
+ length = round_up(length, PAGE_SIZE);
Oh oh. I think these fixups are very suspect, so just
BUG_ON(length == 0);
BUG_ON(offset_in_page(addr|length));
+
+ end = addr + length;
+
+ if ((addr pd_mask) != (end pd_mask))
+ return (1 (pde_shift - PAGE_SHIFT)) -
#define NUM_PTE(pde_shift) (1 (pde_shift - PAGE_SHIFT))
here and for computing the pd_mask.
+ i915_pte_index(addr, pde_shift);
+
+ return i915_pte_index(end, pde_shift) - i915_pte_index(addr, pde_shift);
+}
Otherwise the helpers look a useful improvement in readability.
-Chris
Can we use GTT_PAGE_SIZE here too? I'm worried the kernel PAGE_SIZE
will change at some point and blow us up. At least in places where
we're doing our own thing rather than using the x86 bits...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use the correct format string modifier for ptrdiff_t
On Tue, Mar 18, 2014 at 10:53:01AM -0700, Volkin, Bradley D wrote:
Thanks for fixing this Damien.
Reviewed-by: Brad Volkin bradley.d.vol...@intel.com
On Tue, Mar 18, 2014 at 05:43:08PM +, Damien Lespiau wrote:
When compiling on 32bits, I have the following warning:
drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’
expects argument of type ‘long int’, but argument 7 has type ‘int’
[-Wformat=]
DRM_DEBUG_DRIVER(CMD: Command length exceeds batch length: 0x%08X
length=%d batchlen=%ld\n,
The ptrdiff_t type has its own modifier: 't'.
Cc: Brad Volkin bradley.d.vol...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 7a5756e..0eaed44 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -402,7 +402,7 @@ int i915_parse_cmds(struct intel_ring_buffer *ring,
length = ((*cmd desc-length.mask) + LENGTH_BIAS);
if ((batch_end - cmd) length) {
- DRM_DEBUG_DRIVER(CMD: Command length exceeds batch
length: 0x%08X length=%d batchlen=%ld\n,
+ DRM_DEBUG_DRIVER(CMD: Command length exceeds batch
length: 0x%08X length=%d batchlen=%td\n,
*cmd,
length,
batch_end - cmd);
--
1.8.3.1
___
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 10/20] drm/i915: fix GEN7_ERR_INT init/reset code
On Fri, Mar 07, 2014 at 08:10:26PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Same as SERR_INT and the other IIR registers: reset on
preinstall/uninstall and WARN for non-zero values at postinstall. This
one also doesn't need double-clear.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
This one just like patch 9 is:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Like that, I'd prefer to get rid of the IIR assertion
---
drivers/gpu/drm/i915/i915_irq.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d295624..02eb493 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2845,6 +2845,9 @@ static void ironlake_irq_preinstall(struct drm_device
*dev)
GEN5_IRQ_RESET(DE);
+ if (IS_GEN7(dev))
+ I915_WRITE(GEN7_ERR_INT, 0x);
+
gen5_gt_irq_preinstall(dev);
ibx_irq_preinstall(dev);
@@ -3011,7 +3014,7 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
extra_mask = (DE_PIPEC_VBLANK_IVB | DE_PIPEB_VBLANK_IVB |
DE_PIPEA_VBLANK_IVB);
- I915_WRITE(GEN7_ERR_INT, I915_READ(GEN7_ERR_INT));
+ GEN5_ASSERT_IIR_IS_ZERO(GEN7_ERR_INT);
} else {
display_mask = (DE_MASTER_IRQ_CONTROL | DE_GSE | DE_PCH_EVENT |
DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
@@ -3295,7 +3298,7 @@ static void ironlake_irq_uninstall(struct drm_device
*dev)
GEN5_IRQ_RESET(DE);
if (IS_GEN7(dev))
- I915_WRITE(GEN7_ERR_INT, I915_READ(GEN7_ERR_INT));
+ I915_WRITE(GEN7_ERR_INT, 0x);
GEN5_IRQ_RESET(GT);
if (INTEL_INFO(dev)-gen = 6)
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add a DRM property psr
This property helps one turn PSR on and off via xrandr.
The default value is same as that of the module param i915.enable_psr.
Signed-off-by: Siva Chandra sivachan...@google.com
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_dp.c | 37 +
2 files changed, 43 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 70fbe90..83e6303 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1607,6 +1607,7 @@ typedef struct drm_i915_private {
struct drm_property *broadcast_rgb_property;
struct drm_property *force_audio_property;
+ struct drm_property *psr_property;
uint32_t hw_context_size;
struct list_head context_list;
@@ -1661,6 +1662,11 @@ enum hdmi_force_audio {
HDMI_AUDIO_ON, /* force turn on HDMI audio */
};
+enum psr_state {
+ EDP_PSR_ON,
+ EDP_PSR_OFF
+};
+
#define I915_GTT_OFFSET_NONE ((u32)-1)
struct drm_i915_gem_object_ops {
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 59ee4dc..c4546fa 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3197,6 +3197,33 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
return 0;
}
+static const struct drm_prop_enum_list psr_names[] = {
+ { EDP_PSR_ON, on },
+ { EDP_PSR_OFF, off }
+};
+
+static void intel_attach_psr_property(struct drm_connector *connector)
+{
+ struct drm_device *dev = connector-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_property *prop;
+
+ prop = dev_priv-psr_property;
+ if (prop == NULL) {
+ prop = drm_property_create_enum(
+ dev,
+ i915.enable_psr ? EDP_PSR_ON : EDP_PSR_OFF,
+ psr,
+ psr_names,
+ ARRAY_SIZE(psr_names));
+ if (prop == NULL)
+ return;
+
+ dev_priv-psr_property = prop;
+ }
+ drm_object_attach_property(connector-base, prop, 0);
+}
+
static bool
intel_dp_detect_audio(struct drm_connector *connector)
{
@@ -3302,6 +3329,15 @@ intel_dp_set_property(struct drm_connector *connector,
goto done;
}
+ if (is_edp(intel_dp) property == dev_priv-psr_property) {
+ if (val == EDP_PSR_ON)
+ intel_edp_psr_enable(intel_dp);
+ else
+ intel_edp_psr_disable(intel_dp);
+
+ return 0;
+ }
+
return -EINVAL;
done:
@@ -3424,6 +3460,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
{
struct intel_connector *intel_connector = to_intel_connector(connector);
+ intel_attach_psr_property(connector);
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_dp-color_range_auto = true;
--
1.9.0.279.gdc9e3eb
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add a DRM property psr
On Tue, 18 Mar 2014 12:51:07 -0700 Siva Chandra sivachan...@chromium.org wrote: This property helps one turn PSR on and off via xrandr. The default value is same as that of the module param i915.enable_psr. Signed-off-by: Siva Chandra sivachan...@google.com --- So are you using this in Chromium for disabling PSR in cases where it doesn't work? Or to optimize power consumption when the kernel driver gets it wrong? Or just for debug? Seems potentially useful, just curious what motivated you guys. Thanks, -- Jesse Barnes, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/20] drm/i915: enable SDEIER later
On Fri, Mar 07, 2014 at 08:10:30PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
On the preinstall stage we should just disable all the interrupts, but
we currently enable all the south display interrupts due to the way we
touch SDEIER at the IRQ handlers (note: they are still masked and our
IRQ handler is disabled).
I think this statement is false. The interrupt is enabled right after
preinstall(). For the nomodeset case, this actually seems to make some
difference. It still looks fine to me though.
Instead of doing that, let's make the
preinstall stage just disable all the south interrupts, and do the
proper interrupt dance/ordering at the postinstall stage, including an
assert to check if everything is behaving as expected.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 95f535b..4479e29 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2814,13 +2814,24 @@ static void ibx_irq_preinstall(struct drm_device *dev)
if (HAS_PCH_CPT(dev) || HAS_PCH_LPT(dev))
I915_WRITE(SERR_INT, 0x);
+}
- /*
- * SDEIER is also touched by the interrupt handler to work around missed
- * PCH interrupts. Hence we can't update it after the interrupt handler
- * is enabled - instead we unconditionally enable all PCH interrupt
- * sources here, but then only unmask them as needed with SDEIMR.
- */
+/*
+ * SDEIER is also touched by the interrupt handler to work around missed PCH
+ * interrupts. Hence we can't update it after the interrupt handler is
enabled -
+ * instead we unconditionally enable all PCH interrupt sources here, but then
+ * only unmask them as needed with SDEIMR.
+ *
+ * This function needs to be called before interrupts are enabled.
+ */
+static void ibx_irq_pre_postinstall(struct drm_device *dev)
sde_irq_postinstall()?
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (HAS_PCH_NOP(dev))
+ return;
+
+ WARN_ON(I915_READ(SDEIER) != 0);
I915_WRITE(SDEIER, 0x);
POSTING_READ(SDEIER);
}
@@ -3026,6 +3037,8 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
dev_priv-irq_mask = ~display_mask;
+ ibx_irq_pre_postinstall(dev);
+
GEN5_IRQ_INIT(DE, dev_priv-irq_mask, display_mask | extra_mask);
gen5_gt_irq_postinstall(dev);
@@ -3217,6 +3230,8 @@ static int gen8_irq_postinstall(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ ibx_irq_pre_postinstall(dev);
+
gen8_gt_irq_postinstall(dev_priv);
gen8_de_irq_postinstall(dev_priv);
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/20] drm/i915: add gen8_irq_reset
On Fri, Mar 07, 2014 at 08:10:34PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
So we can merge all the common code from postinstall and uninstall.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 26 +++---
1 file changed, 7 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4917a8c..d6723ab 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2899,7 +2899,7 @@ static void valleyview_irq_preinstall(struct drm_device
*dev)
POSTING_READ(VLV_IER);
}
-static void gen8_irq_preinstall(struct drm_device *dev)
+static void gen8_irq_reset(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int pipe;
@@ -2924,6 +2924,11 @@ static void gen8_irq_preinstall(struct drm_device *dev)
ibx_irq_reset(dev);
}
+static void gen8_irq_preinstall(struct drm_device *dev)
+{
+ gen8_irq_reset(dev);
+}
+
static void ibx_hpd_irq_setup(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
@@ -3253,30 +3258,13 @@ static int gen8_irq_postinstall(struct drm_device
*dev)
static void gen8_irq_uninstall(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- int pipe;
if (!dev_priv)
return;
intel_hpd_irq_uninstall(dev_priv);
- I915_WRITE(GEN8_MASTER_IRQ, 0);
-
- GEN8_IRQ_RESET_NDX(GT, 0);
- GEN8_IRQ_RESET_NDX(GT, 1);
- GEN8_IRQ_RESET_NDX(GT, 2);
- GEN8_IRQ_RESET_NDX(GT, 3);
-
- for_each_pipe(pipe)
- GEN8_IRQ_RESET_NDX(DE_PIPE, pipe);
-
- GEN5_IRQ_RESET(GEN8_DE_PORT_);
- GEN5_IRQ_RESET(GEN8_DE_MISC_);
- GEN5_IRQ_RESET(GEN8_PCU_);
-
- POSTING_READ(GEN8_PCU_IIR);
-
- ibx_irq_reset(dev);
+ gen8_irq_reset(dev);
BTW: This looks like a bad hunk. I've merged up to this point, and I do
not have ibx_irq_reset().
}
static void valleyview_irq_uninstall(struct drm_device *dev)
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/20] drm/i915: add POSTING_READs to the IRQ init/reset macros
On Fri, Mar 07, 2014 at 08:10:36PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
I previously chose to keep the POSTING_READ calls as something to be
done by the macro callers, but the conclusion after discussing this on
the mailing list is that leaving the POSTING_READ calls to the macros
makes the code safer, and the additional useless register reads
shouldn't be noticeable. So move the POSTING_READ calls to the
callers.
Can you just squash this into the earlier patch? Either way,
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 79a8196..dee3a3b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -80,11 +80,7 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-/*
- * IIR can theoretically queue up two events. Be paranoid.
- * Also, make sure callers of these macros have something equivalent to a
- * POSTING_READ on the IIR register.
- * */
+/* IIR can theoretically queue up two events. Be paranoid. */
#define GEN8_IRQ_RESET_NDX(type, which) do { \
I915_WRITE(GEN8_##type##_IMR(which), 0x); \
POSTING_READ(GEN8_##type##_IMR(which)); \
@@ -92,6 +88,7 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
I915_WRITE(GEN8_##type##_IIR(which), 0x); \
POSTING_READ(GEN8_##type##_IIR(which)); \
I915_WRITE(GEN8_##type##_IIR(which), 0x); \
+ POSTING_READ(GEN8_##type##_IIR(which)); \
} while (0)
#define GEN5_IRQ_RESET(type) do { \
@@ -101,6 +98,7 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
I915_WRITE(type##IIR, 0x); \
POSTING_READ(type##IIR); \
I915_WRITE(type##IIR, 0x); \
+ POSTING_READ(type##IIR); \
} while (0)
/*
@@ -117,12 +115,14 @@ static const u32 hpd_status_i915[] = { /* i915 and
valleyview are the same */
GEN5_ASSERT_IIR_IS_ZERO(GEN8_##type##_IIR(which)); \
I915_WRITE(GEN8_##type##_IMR(which), (imr_val)); \
I915_WRITE(GEN8_##type##_IER(which), (ier_val)); \
+ POSTING_READ(GEN8_##type##_IER(which)); \
} while (0)
#define GEN5_IRQ_INIT(type, imr_val, ier_val) do { \
GEN5_ASSERT_IIR_IS_ZERO(type##IIR); \
I915_WRITE(type##IMR, (imr_val)); \
I915_WRITE(type##IER, (ier_val)); \
+ POSTING_READ(type##IER); \
} while (0)
/* For display hotplug interrupt */
@@ -2843,7 +2843,6 @@ static void gen5_gt_irq_reset(struct drm_device *dev)
GEN5_IRQ_RESET(GT);
if (INTEL_INFO(dev)-gen = 6)
GEN5_IRQ_RESET(GEN6_PM);
- POSTING_READ(GTIIR);
}
/* drm_dma.h hooks
@@ -2917,7 +2916,6 @@ static void gen8_irq_reset(struct drm_device *dev)
GEN5_IRQ_RESET(GEN8_DE_PORT_);
GEN5_IRQ_RESET(GEN8_DE_MISC_);
GEN5_IRQ_RESET(GEN8_PCU_);
- POSTING_READ(GEN8_PCU_IIR);
ibx_irq_reset(dev);
}
@@ -3016,7 +3014,6 @@ static void gen5_gt_irq_postinstall(struct drm_device
*dev)
dev_priv-pm_irq_mask = 0x;
GEN5_IRQ_INIT(GEN6_PM, dev_priv-pm_irq_mask, pm_irqs);
}
- POSTING_READ(GTIER);
}
static int ironlake_irq_postinstall(struct drm_device *dev)
@@ -3213,7 +3210,6 @@ static void gen8_gt_irq_postinstall(struct
drm_i915_private *dev_priv)
for (i = 0; i ARRAY_SIZE(gt_interrupts); i++)
GEN8_IRQ_INIT_NDX(GT, i, ~gt_interrupts[i], gt_interrupts[i]);
- POSTING_READ(GEN8_GT_IER(0));
}
static void gen8_de_irq_postinstall(struct drm_i915_private *dev_priv)
@@ -3232,10 +3228,8 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
for_each_pipe(pipe)
GEN8_IRQ_INIT_NDX(DE_PIPE, pipe, dev_priv-de_irq_mask[pipe],
de_pipe_enables);
- POSTING_READ(GEN8_DE_PIPE_ISR(0));
GEN5_IRQ_INIT(GEN8_DE_PORT_, ~GEN8_AUX_CHANNEL_A, GEN8_AUX_CHANNEL_A);
- POSTING_READ(GEN8_DE_PORT_IER);
}
static int gen8_irq_postinstall(struct drm_device *dev)
--
1.8.5.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/20] ILK+ interrupt improvements, v2
On Fri, Mar 07, 2014 at 08:10:16PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Hi This is basically a rebase of [PATCH 00/19] ILK+ interrupt improvements, which was sent to the mailing list on January 22. There are no real differences, except for the last patch, which is new. Original cover letter: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038679.html The idea behind this series is that at some point our runtime PM code will just call our irq_preinstall, irq_postinstall and irq_uninstall functions instead of using dev_priv-pc8.regsave, so I decided to audit, cleanup and add a few WARNs to our code before we do that change. We gotta be in shape if we want to be exposed to runtime! Thanks, Paulo Paulo Zanoni (20): drm/i915: add GEN5_IRQ_INIT macro drm/i915: also use GEN5_IRQ_INIT with south display interrupts drm/i915: use GEN8_IRQ_INIT on GEN5 drm/i915: add GEN5_IRQ_FINI drm/i915: don't forget to uninstall the PM IRQs drm/i915: properly clear IIR at irq_uninstall on Gen5+ drm/i915: add GEN5_IRQ_INIT drm/i915: check if IIR is still zero at postinstall on Gen5+ drm/i915: fix SERR_INT init/reset code drm/i915: fix GEN7_ERR_INT init/reset code drm/i915: fix open coded gen5_gt_irq_preinstall drm/i915: extract ibx_irq_uninstall drm/i915: call ibx_irq_uninstall from gen8_irq_uninstall drm/i915: enable SDEIER later drm/i915: remove ibx_irq_uninstall drm/i915: add missing intel_hpd_irq_uninstall drm/i915: add ironlake_irq_reset drm/i915: add gen8_irq_reset drm/i915: only enable HWSTAM interrupts on postinstall on ILK+ drm/i915: add POSTING_READs to the IRQ init/reset macros drivers/gpu/drm/i915/i915_irq.c | 270 ++-- 1 file changed, 121 insertions(+), 149 deletions(-) Okay, here is the summary of my review. At first I was complaining to myself about how many patches you used to do a simple thing. But, I must admit it made reviewing the thing a lot easier, and when I look back at how much stuff you combined, I'm really glad you did it this way. I'm sure I've missed something silly though, since every patch looks so similar :P 1-5: Reviewed-by: Ben Widawsky b...@bwidawsk.net (with possible comment improvement on #3) 7: I don't like. Can we drop? I guess doing this would make a decent amount of churn, so if you don't want to drop it, that's fine, and it's functionally correct: Reviewed-by: Ben Widawsky b...@bwidawsk.net 8: I'd really like to drop this one. 9-10: Reviewed-by: Ben Widawsky b...@bwidawsk.net 12-13: I wouldn't mind cpt_irq_* rename, but either way Reviewed-by: Ben Widawsky b...@bwidawsk.net 14: With the requested change in the mail: Reviewed-by: Ben Widawsky b...@bwidawsk.net 16: Reviewed-by: Ben Widawsky b...@bwidawsk.net 20: Should be squashed, but Reviewed-by: Ben Widawsky b...@bwidawsk.net 6, 11, 15, 17, 18, 19: You introduce the term _reset as a verb which seems to always mean disable. I think disable makes the code so much clearer, and would really love if you can apply this simple rename. With the rename, they're: Reviewed-by: Ben Widawsky b...@bwidawsk.net -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/bdw: Restore PPAT on thaw
Apparently it is wiped out from under us, and we get some really fun
caching artifacts upon resume (it seems to be WB for all types by
default).
Reported-by: James Ausmus james.aus...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bd016e2..1b45a04 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -30,6 +30,8 @@
#include i915_trace.h
#include intel_drv.h
+static void gen8_setup_private_ppat(struct drm_i915_private *dev_priv);
+
bool intel_enable_ppgtt(struct drm_device *dev, bool full)
{
if (i915.enable_ppgtt == 0 || !HAS_ALIASING_PPGTT(dev))
@@ -1371,8 +1373,10 @@ void i915_gem_restore_gtt_mappings(struct drm_device
*dev)
}
- if (INTEL_INFO(dev)-gen = 8)
+ if (INTEL_INFO(dev)-gen = 8) {
+ gen8_setup_private_ppat(dev_priv);
return;
+ }
list_for_each_entry(vm, dev_priv-vm_list, global_link) {
/* TODO: Perhaps it shouldn't be gen6 specific */
--
1.9.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] !SQUASH drm/i915: Do not dereference pointers from ring buffer in evict event
There isn't a 'dev' variable that can be referenced here. Use vm-dev instead. Signed-off-by: Bob Paauwe bob.j.paa...@intel.com --- drivers/gpu/drm/i915/i915_trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index 93342a4..23c26f1 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -243,7 +243,7 @@ TRACE_EVENT(i915_gem_evict_vm, ), TP_fast_assign( - __entry-dev = dev-primary-index; + __entry-dev = vm-dev-primary-index; __entry-vm = vm; ), -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Per-process stats work better when evaluated per-process
On Thu, Mar 13, 2014 at 11:57:00AM -0300, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
The idea of printing objects used by each process is to judge how each
process is using them. This means that we need to evaluate whether the
object is bound for that particular process, rather than just whether it
is bound into the global GTT.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ben Widawsky benjamin.widaw...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 34
++---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 1 +
3 files changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a90d31c..ed3965f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -299,28 +299,46 @@ static int i915_gem_stolen_list_info(struct seq_file
*m, void *data)
} while (0)
struct file_stats {
+ struct drm_i915_file_private *file_priv;
int count;
- size_t total, active, inactive, unbound;
+ size_t total, global, active, inactive, unbound;
};
static int per_file_stats(int id, void *ptr, void *data)
{
struct drm_i915_gem_object *obj = ptr;
struct file_stats *stats = data;
+ struct i915_vma *vma;
stats-count++;
stats-total += obj-base.size;
- if (i915_gem_obj_ggtt_bound(obj)) {
- if (!list_empty(obj-ring_list))
+ list_for_each_entry(vma, obj-vma_list, vma_link) {
+ struct i915_hw_ppgtt *ppgtt;
+
+ if (!drm_mm_node_allocated(vma-node))
+ continue;
+
+ ppgtt = container_of(vma-vm, struct i915_hw_ppgtt, base);
+ if (ppgtt-ctx == NULL) {
+ stats-global += obj-base.size;
+ continue;
+ }
I'm not really clear how this is supposed to work for global. Can you
make me happy and change it to:
if (i915_is_ggtt(vma-vm))
+
+ if (ppgtt-ctx-file_priv != stats-file_priv)
+ continue;
+
+ if (obj-ring) /* XXX per-vma statistic */
stats-active += obj-base.size;
Doesn't active get counted too many times if multiple VMAs exist for the
same active object (not a new problem to this patch)?
else
stats-inactive += obj-base.size;
- } else {
- if (!list_empty(obj-global_list))
- stats-unbound += obj-base.size;
+
+ return 0;
}
+ if (!list_empty(obj-global_list))
+ stats-unbound += obj-base.size;
+
return 0;
}
@@ -411,6 +429,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
struct task_struct *task;
memset(stats, 0, sizeof(stats));
+ stats.file_priv = file-driver_priv;
idr_for_each(file-object_idr, per_file_stats, stats);
/*
* Although we have a valid reference on file-pid, that does
@@ -420,12 +439,13 @@ static int i915_gem_object_info(struct seq_file *m,
void* data)
*/
rcu_read_lock();
task = pid_task(file-pid, PIDTYPE_PID);
- seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu unbound)\n,
+ seq_printf(m, %s: %u objects, %zu bytes (%zu active, %zu
inactive, %zu global, %zu unbound)\n,
task ? task-comm : unknown,
stats.count,
stats.total,
stats.active,
stats.inactive,
+stats.global,
stats.unbound);
rcu_read_unlock();
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2a319ba..b76c6de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -721,6 +721,8 @@ struct i915_hw_ppgtt {
dma_addr_t *gen8_pt_dma_addr[4];
};
+ struct i915_hw_context *ctx;
+
int (*enable)(struct i915_hw_ppgtt *ppgtt);
int (*switch_mm)(struct i915_hw_ppgtt *ppgtt,
struct intel_ring_buffer *ring,
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ce41cff..1a94b07 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -215,6 +215,7 @@ create_vm_for_ctx(struct drm_device *dev, struct
i915_hw_context *ctx)
return ERR_PTR(ret);
}
+ ppgtt-ctx = ctx;
return ppgtt;
}
--
1.8.5.3
--
Ben Widawsky, Intel Open Source Technology Center
[Intel-gfx] [RFCv3 14/14] drm/i915: Add cursor handlers and create cursor at crtc init
Cc: Intel Graphics Development intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 90 +++-
1 file changed, 89 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f661469..36bee38 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10781,11 +10781,98 @@ static struct drm_plane
*intel_primary_plane_create(struct drm_device *dev,
return primary-base;
}
+static int
+intel_cursor_plane_update(struct drm_plane *plane, struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+ unsigned int crtc_w, unsigned int crtc_h,
+ uint32_t src_x, uint32_t src_y,
+ uint32_t src_w, uint32_t src_h)
+{
+ int ret;
+
+ /* setplane API takes shifted source rectangle values; unshift them */
+ src_x = 16;
+ src_y = 16;
+ src_w = 16;
+ src_h = 16;
+
+ /* Cursor planes are locked to their owning CRTC */
+ if (plane-possible_crtcs != drm_crtc_mask(crtc)) {
+ DRM_DEBUG_KMS(Cannot change cursor plane CRTC\n);
+ return -EINVAL;
+ }
+
+ /* Current hardware can't scale the cursor plane. */
+ if (crtc_w != src_w || crtc_h != src_h) {
+ DRM_DEBUG_KMS(Can't scale cursor plane\n);
+ return -EINVAL;
+ }
+
+ ret = cursor_set_common(crtc, crtc-cursor, fb);
+ if (ret)
+ return ret;
+
+ intel_crtc_cursor_move(crtc, crtc_x, crtc_y);
+ intel_crtc_update_cursor(crtc, fb);
+
+ return 0;
+}
+
+static int
+intel_cursor_plane_disable(struct drm_plane *plane)
+{
+ if (!plane-fb)
+ return 0;
+
+ BUG_ON(!plane-crtc);
+
+ return cursor_set_common(plane-crtc, plane, NULL);
+}
+
+static void intel_cursor_plane_destroy(struct drm_plane *plane)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ intel_cursor_plane_disable(plane);
+ drm_plane_cleanup(plane);
+ kfree(intel_plane);
+}
+
+static const struct drm_plane_funcs intel_cursor_plane_funcs = {
+ .update_plane = intel_cursor_plane_update,
+ .disable_plane = intel_cursor_plane_disable,
+ .destroy = intel_cursor_plane_destroy,
+};
+
+static const uint32_t cursor_formats[] = {
+ DRM_FORMAT_ARGB,
+};
+
+static struct drm_plane *intel_cursor_plane_create(struct drm_device *dev,
+ int pipe)
+{
+ struct intel_plane *cursor;
+
+ cursor = kzalloc(sizeof(*cursor), GFP_KERNEL);
+ if (cursor == NULL)
+ return NULL;
+
+ cursor-can_scale = false;
+ cursor-pipe = pipe;
+ cursor-plane = pipe;
+
+ drm_plane_init(dev, cursor-base, 0,
+ intel_cursor_plane_funcs, cursor_formats,
+ ARRAY_SIZE(cursor_formats),
+ DRM_PLANE_TYPE_CURSOR);
+ return cursor-base;
+}
+
static void intel_crtc_init(struct drm_device *dev, int pipe)
{
drm_i915_private_t *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc;
struct drm_plane *primary;
+ struct drm_plane *cursor;
int i, ret;
intel_crtc = kzalloc(sizeof(*intel_crtc), GFP_KERNEL);
@@ -10793,7 +10880,8 @@ static void intel_crtc_init(struct drm_device *dev, int
pipe)
return;
primary = intel_primary_plane_create(dev, pipe);
- ret = drm_crtc_init(dev, intel_crtc-base, primary, NULL,
+ cursor = intel_cursor_plane_create(dev, pipe);
+ ret = drm_crtc_init(dev, intel_crtc-base, primary, cursor,
intel_crtc_funcs);
if (ret) {
drm_crtc_cleanup(intel_crtc-base);
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFCv3 10/14] drm/i915: Rename similar plane functions to avoid confusion
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.
On a similar note, intel_display.c already had a function called
intel_disable_primary_plane() that programs the hardware to disable a
pipe's primary plane. When we hook up primary planes through the DRM
plane interface, one of the natural handler names will be
intel_primary_plane_disable(), which is very similar. To avoid
confusion, rename the existing intel_disable_primary_plane() to
intel_disable_primary_hw_plane() to make the two names a little more
distinct.
Cc: Intel Graphics Development intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 5 +--
drivers/gpu/drm/i915/intel_display.c | 60
2 files changed, 36 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 70fbe90..a937711 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -462,8 +462,9 @@ struct drm_i915_display_funcs {
struct drm_framebuffer *fb,
struct drm_i915_gem_object *obj,
uint32_t flags);
- int (*update_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
- int x, int y);
+ int (*update_primary_plane)(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ int x, int y);
void (*hpd_irq_setup)(struct drm_device *dev);
/* clock updates for mode set */
/* cursor updates */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c2f3730..849a241 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1872,15 +1872,15 @@ void intel_flush_primary_plane(struct drm_i915_private
*dev_priv,
}
/**
- * intel_enable_primary_plane - enable the primary plane on a given pipe
+ * intel_enable_primary_hw_plane - enable the primary plane on a given pipe
* @dev_priv: i915 private structure
* @plane: plane to enable
* @pipe: pipe being fed
*
* Enable @plane on @pipe, making sure that @pipe is running first.
*/
-static void intel_enable_primary_plane(struct drm_i915_private *dev_priv,
- enum plane plane, enum pipe pipe)
+static void intel_enable_primary_hw_plane(struct drm_i915_private *dev_priv,
+ enum plane plane, enum pipe pipe)
{
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
@@ -1905,15 +1905,15 @@ static void intel_enable_primary_plane(struct
drm_i915_private *dev_priv,
}
/**
- * intel_disable_primary_plane - disable the primary plane
+ * intel_disable_primary_hw_plane - disable the primary hardware plane
* @dev_priv: i915 private structure
* @plane: plane to disable
* @pipe: pipe consuming the data
*
* Disable @plane; should be an independent operation.
*/
-static void intel_disable_primary_plane(struct drm_i915_private *dev_priv,
- enum plane plane, enum pipe pipe)
+static void intel_disable_primary_hw_plane(struct drm_i915_private *dev_priv,
+ enum plane plane, enum pipe pipe)
{
struct intel_crtc *intel_crtc =
to_intel_crtc(dev_priv-pipe_to_crtc_mapping[pipe]);
@@ -2153,8 +2153,9 @@ static void intel_find_plane_obj(struct intel_crtc
*intel_crtc,
}
}
-static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb,
-int x, int y)
+static int i9xx_update_primary_plane(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int x, int y)
{
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -2253,8 +2254,9 @@ static int i9xx_update_plane(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
return 0;
}
-static int ironlake_update_plane(struct drm_crtc *crtc,
-struct drm_framebuffer *fb, int x, int y)
+static int ironlake_update_primary_plane(struct drm_crtc *crtc,
+struct drm_framebuffer *fb,
+int x, int y)
{
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -2358,7 +2360,7 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct
drm_framebuffer *fb,
dev_priv-display.disable_fbc(dev);
intel_increase_pllclock(crtc);
- return dev_priv-display.update_plane(crtc, fb, x, y);
+
[Intel-gfx] [RFCv3 13/14] drm/i915: Split cursor update code from cursor ioctl handling
Legacy cursor ioctls took GEM buffer handles from userspace directly
whereas the new unified plane handling assigns drm_framebuffer's to
cursor planes. Splitting the code that actually updates the cursor
plane from the code that handles object lookup and reference counting
allows us to share common code between both interfaces.
Cc: Intel Graphics Development intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 197 ---
drivers/gpu/drm/i915/intel_drv.h | 2 -
2 files changed, 134 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d43b31d..f661469 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -43,7 +43,8 @@
#include linux/dma_remapping.h
static void intel_increase_pllclock(struct drm_crtc *crtc);
-static void intel_crtc_update_cursor(struct drm_crtc *crtc, bool on);
+static void intel_crtc_update_cursor(struct drm_crtc *crtc,
+struct drm_framebuffer *fb);
static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config);
@@ -56,6 +57,11 @@ static int intel_framebuffer_init(struct drm_device *dev,
struct intel_framebuffer *ifb,
struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_i915_gem_object *obj);
+static struct drm_framebuffer *
+intel_user_framebuffer_create(struct drm_device *dev,
+ struct drm_file *filp,
+ struct drm_mode_fb_cmd2 *mode_cmd);
+static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb);
typedef struct {
int min, max;
@@ -3709,7 +3715,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
intel_enable_pipe(intel_crtc);
intel_enable_primary_hw_plane(dev_priv, plane, pipe);
intel_enable_planes(crtc);
- intel_crtc_update_cursor(crtc, true);
+ intel_crtc_update_cursor(crtc, crtc-cursor-fb);
if (intel_crtc-config.has_pch_encoder)
ironlake_pch_enable(crtc);
@@ -3753,7 +3759,7 @@ static void haswell_crtc_enable_planes(struct drm_crtc
*crtc)
intel_enable_primary_hw_plane(dev_priv, plane, pipe);
intel_enable_planes(crtc);
- intel_crtc_update_cursor(crtc, true);
+ intel_crtc_update_cursor(crtc, crtc-cursor-fb);
hsw_enable_ips(intel_crtc);
@@ -3781,7 +3787,7 @@ static void haswell_crtc_disable_planes(struct drm_crtc
*crtc)
hsw_disable_ips(intel_crtc);
- intel_crtc_update_cursor(crtc, false);
+ intel_crtc_update_cursor(crtc, NULL);
intel_disable_planes(crtc);
intel_disable_primary_hw_plane(dev_priv, plane, pipe);
}
@@ -3909,7 +3915,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
if (dev_priv-fbc.plane == plane)
intel_disable_fbc(dev);
- intel_crtc_update_cursor(crtc, false);
+ intel_crtc_update_cursor(crtc, NULL);
intel_disable_planes(crtc);
intel_disable_primary_hw_plane(dev_priv, plane, pipe);
@@ -4396,7 +4402,7 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
intel_set_cpu_fifo_underrun_reporting(dev, pipe, true);
intel_enable_primary_hw_plane(dev_priv, plane, pipe);
intel_enable_planes(crtc);
- intel_crtc_update_cursor(crtc, true);
+ intel_crtc_update_cursor(crtc, crtc-cursor-fb);
intel_update_fbc(dev);
@@ -4440,7 +4446,7 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
/* The fixup needs to happen before cursor is enabled */
if (IS_G4X(dev))
g4x_fixup_plane(dev_priv, pipe);
- intel_crtc_update_cursor(crtc, true);
+ intel_crtc_update_cursor(crtc, crtc-cursor-fb);
/* Give the overlay scaler a chance to enable if it's on this pipe */
intel_crtc_dpms_overlay(intel_crtc, true);
@@ -4491,7 +4497,7 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
intel_disable_fbc(dev);
intel_crtc_dpms_overlay(intel_crtc, false);
- intel_crtc_update_cursor(crtc, false);
+ intel_crtc_update_cursor(crtc, NULL);
intel_disable_planes(crtc);
intel_disable_primary_hw_plane(dev_priv, plane, pipe);
@@ -7739,7 +7745,7 @@ static void ivb_update_cursor(struct drm_crtc *crtc, u32
base)
/* If no-part of the cursor is visible on the framebuffer, then the GPU may
hang... */
static void intel_crtc_update_cursor(struct drm_crtc *crtc,
-bool on)
+struct drm_framebuffer *fb)
{
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -7750,32 +7756,36 @@ static void
[Intel-gfx] [RFCv3 00/14] Unified plane support
Previous revision and explanation of series: http://lists.freedesktop.org/archives/dri-devel/2014-March/055222.html Main changes since last pass: * Added cursor plane support on i915. Unfortunately it isn't possible to create nice generic helper functions that make use of the legacy API's for cursor planes as was done for primary planes; the legacy cursor ioctl's take a driver handle directly (e.g., from GEM) rather than a DRM framebuffer. With the unified plane support, we receive a DRM framebuffer via the SetPlane API, but have no way of turning that into a driver handle that can be passed to the legacy interfaces. * Updated msm and omapdrm to use their existing private planes as primary rather than using the primary helper functions. (thanks Rob Clark!) * Fixed several s/crtc-fb/crtc-primary-fb/ conversions that were missed on the first pass (or new instances that popped up due to rebasing to the latest code). I believe some of the next steps are: * Create some new read-only plane properties that describe in more detail the capabilities limitations of various planes (max/min size, scaling capabilities, tiling restrictions, etc.) so that generic userspace compositors can make intelligent decisions about how best to use the various planes on the plane list. If anyone has strong feelings on what these properties should look like, this would be a good time to start the discussion. * Update cursor support for the rest of the non-i915 drivers. I believe the list of drivers that currently support cursors are: armada, ast, gma500, mgag200, msm, nouveau, radeon, vmwgfx, and qxl. * Update imx-drm's CRTC creation to use its existing private primary plane rather than using the primary helper function to create one. * Provide patches for weston xf86-video-modesetting that make use of the unified plane interface to make real-world testing of this patchset a bit easier. Note that the first patch here is simply a build fix for current breakage of the drm-intel-nightly branch of the drm-intel repo. Matt Roper (14): SQUASH! drm/i915: Do not dereference pointers from ring buffer in evict event drm: Add support for multiple plane types drm: Add primary plane helpers drm/exynos: Restrict plane loops to only operate on overlay planes drm/i915: Restrict plane loops to only operate on overlay planes drm: Add plane type property drm: Specify primary plane at CRTC initialization (v2) drm: Replace crtc fb with primary plane fb (v2) drm: Allow userspace to ask for full plane list (universal planes) drm/i915: Rename similar plane functions to avoid confusion drm/i915: Intel-specific primary plane handling drm: Specify cursor plane at CRTC initialization drm/i915: Split cursor update code from cursor ioctl handling drm/i915: Add cursor handlers and create cursor at crtc init drivers/gpu/drm/armada/armada_crtc.c | 4 +- drivers/gpu/drm/armada/armada_overlay.c | 3 +- drivers/gpu/drm/ast/ast_mode.c | 16 +- drivers/gpu/drm/bochs/bochs_kms.c| 8 +- drivers/gpu/drm/cirrus/cirrus_mode.c | 15 +- drivers/gpu/drm/drm_crtc.c | 441 +++ drivers/gpu/drm/drm_crtc_helper.c| 21 +- drivers/gpu/drm/drm_fb_helper.c | 9 +- drivers/gpu/drm/drm_ioctl.c | 5 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 + drivers/gpu/drm/exynos/exynos_drm_plane.c| 4 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_dp.c| 2 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/gma_display.c | 17 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c| 2 +- drivers/gpu/drm/gma500/mdfld_intel_display.c | 17 +- drivers/gpu/drm/gma500/oaktrail_crtc.c | 13 +- drivers/gpu/drm/gma500/psb_intel_display.c | 7 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_irq.c | 4 +- drivers/gpu/drm/i915/i915_trace.h| 2 +- drivers/gpu/drm/i915/intel_display.c | 623 --- drivers/gpu/drm/i915/intel_dp.c | 5 +- drivers/gpu/drm/i915/intel_drv.h | 3 +- drivers/gpu/drm/i915/intel_fbdev.c | 6 +- drivers/gpu/drm/i915/intel_overlay.c | 4 +- drivers/gpu/drm/i915/intel_pm.c | 39 +- drivers/gpu/drm/i915/intel_sprite.c | 2 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 33 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 33 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c| 4 +-
[Intel-gfx] [RFCv3 11/14] drm/i915: Intel-specific primary plane handling
Intel hardware allows the primary plane to be disabled independently of
the CRTC. Provide custom primary plane handling to allow this.
Cc: Intel Graphics Development intel-gfx@lists.freedesktop.org
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 132 ++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 130 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 849a241..7d6878b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -39,6 +39,7 @@
#include i915_trace.h
#include drm/drm_dp_helper.h
#include drm/drm_crtc_helper.h
+#include drm/drm_rect.h
#include linux/dma_remapping.h
static void intel_increase_pllclock(struct drm_crtc *crtc);
@@ -10589,19 +10590,144 @@ static void intel_shared_dpll_init(struct drm_device
*dev)
BUG_ON(dev_priv-num_shared_dpll I915_NUM_PLLS);
}
+static int
+intel_primary_plane_setplane(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned int crtc_h,
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct drm_framebuffer *tmpfb;
+ struct drm_rect dest = {
+ .x1 = crtc_x,
+ .y1 = crtc_y,
+ .x2 = crtc_x + crtc_w,
+ .y2 = crtc_y + crtc_h,
+ };
+ struct drm_rect clip = {
+ .x2 = crtc-mode.hdisplay,
+ .y2 = crtc-mode.vdisplay,
+ };
+ int ret;
+
+ /* setplane API takes shifted source rectangle values; unshift them */
+ src_x = 16;
+ src_y = 16;
+ src_w = 16;
+ src_h = 16;
+
+ /*
+* Current hardware can't reposition the primary plane or scale it
+* (although this could change in the future).
+*/
+ drm_rect_intersect(dest, clip);
+ if (dest.x1 != 0 || dest.y1 != 0 ||
+ dest.x2 != crtc-mode.hdisplay || dest.y2 != crtc-mode.vdisplay) {
+ DRM_DEBUG_KMS(Primary plane must cover entire CRTC\n);
+ return -EINVAL;
+ }
+
+ if (crtc_w != src_w || crtc_h != src_h) {
+ DRM_DEBUG_KMS(Can't scale primary plane\n);
+ return -EINVAL;
+ }
+
+ /*
+* pipe_set_base() adjusts crtc-primary-fb; however the DRM setplane
+* code that called us expects to handle the framebuffer update and
+* reference counting; save and restore the current fb before
+* calling it.
+*/
+ tmpfb = plane-fb;
+ ret = intel_pipe_set_base(crtc, src_x, src_y, fb);
+ if (ret)
+ return ret;
+ plane-fb = tmpfb;
+
+ if (!intel_crtc-primary_enabled)
+ intel_enable_primary_hw_plane(dev_priv, intel_crtc-plane,
+ intel_crtc-pipe);
+
+ return 0;
+}
+
+static int
+intel_primary_plane_disable(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane-dev;
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct intel_crtc *intel_crtc;
+
+ if (!plane-fb)
+ return 0;
+
+ if (WARN_ON(!plane-crtc))
+ return -EINVAL;
+
+ intel_crtc = to_intel_crtc(plane-crtc);
+ if (intel_crtc-primary_enabled)
+ intel_disable_primary_hw_plane(dev_priv, intel_plane-plane,
+ intel_plane-pipe);
+
+ return 0;
+}
+
+static void intel_primary_plane_destroy(struct drm_plane *plane)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ intel_primary_plane_disable(plane);
+ drm_plane_cleanup(plane);
+ kfree(intel_plane);
+}
+
+static const struct drm_plane_funcs intel_primary_plane_funcs = {
+ .update_plane = intel_primary_plane_setplane,
+ .disable_plane = intel_primary_plane_disable,
+ .destroy = intel_primary_plane_destroy,
+};
+
+static struct drm_plane *intel_primary_plane_create(struct drm_device *dev,
+ int pipe)
+{
+ struct intel_plane *primary;
+
+ primary = kzalloc(sizeof(*primary), GFP_KERNEL);
+ if (primary == NULL)
+ return NULL;
+
+ primary-can_scale = false;
+ primary-pipe = pipe;
+ primary-plane = pipe;
+
+ drm_plane_init(dev, primary-base, 0,
+ intel_primary_plane_funcs, legacy_modeset_formats,
+ ARRAY_SIZE(legacy_modeset_formats),
+
[Intel-gfx] [RFCv3 01/14] SQUASH! drm/i915: Do not dereference pointers from ring buffer in evict event
Build fix for drm-intel-nightly: there is no 'dev' variable for TP_fast_assign(); should be vm-dev. Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Matt Roper matthew.d.ro...@intel.com --- drivers/gpu/drm/i915/i915_trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index 93342a4..23c26f1 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -243,7 +243,7 @@ TRACE_EVENT(i915_gem_evict_vm, ), TP_fast_assign( - __entry-dev = dev-primary-index; + __entry-dev = vm-dev-primary-index; __entry-vm = vm; ), -- 1.8.5.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Restore PPAT on thaw
On Tue, Mar 18, 2014 at 4:09 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
Apparently it is wiped out from under us, and we get some really fun
caching artifacts upon resume (it seems to be WB for all types by
default).
Reported-by: James Ausmus james.aus...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Tested-by: James Ausmus james.aus...@intel.com
Works for me backported on to both a 3.14-rc3 w/ ChromeOS sauce and a
vanilla 3.14-rc6. Thanks!
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bd016e2..1b45a04 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -30,6 +30,8 @@
#include i915_trace.h
#include intel_drv.h
+static void gen8_setup_private_ppat(struct drm_i915_private *dev_priv);
+
bool intel_enable_ppgtt(struct drm_device *dev, bool full)
{
if (i915.enable_ppgtt == 0 || !HAS_ALIASING_PPGTT(dev))
@@ -1371,8 +1373,10 @@ void i915_gem_restore_gtt_mappings(struct drm_device
*dev)
}
- if (INTEL_INFO(dev)-gen = 8)
+ if (INTEL_INFO(dev)-gen = 8) {
+ gen8_setup_private_ppat(dev_priv);
return;
+ }
list_for_each_entry(vm, dev_priv-vm_list, global_link) {
/* TODO: Perhaps it shouldn't be gen6 specific */
--
1.9.0
--
James Ausmus
Sr. Software Engineer
SSG-OTC ChromeOS Integration
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFCv3 00/14] Unified plane support
On Tue, Mar 18, 2014 at 8:22 PM, Matt Roper matthew.d.ro...@intel.com wrote: Previous revision and explanation of series: http://lists.freedesktop.org/archives/dri-devel/2014-March/055222.html Main changes since last pass: * Added cursor plane support on i915. Unfortunately it isn't possible to create nice generic helper functions that make use of the legacy API's for cursor planes as was done for primary planes; the legacy cursor ioctl's take a driver handle directly (e.g., from GEM) rather than a DRM framebuffer. With the unified plane support, we receive a DRM framebuffer via the SetPlane API, but have no way of turning that into a driver handle that can be passed to the legacy interfaces. * Updated msm and omapdrm to use their existing private planes as primary rather than using the primary helper functions. (thanks Rob Clark!) * Fixed several s/crtc-fb/crtc-primary-fb/ conversions that were missed on the first pass (or new instances that popped up due to rebasing to the latest code). I believe some of the next steps are: * Create some new read-only plane properties that describe in more detail the capabilities limitations of various planes (max/min size, scaling capabilities, tiling restrictions, etc.) so that generic userspace compositors can make intelligent decisions about how best to use the various planes on the plane list. If anyone has strong feelings on what these properties should look like, this would be a good time to start the discussion. * Update cursor support for the rest of the non-i915 drivers. I believe the list of drivers that currently support cursors are: armada, ast, gma500, mgag200, msm, nouveau, radeon, vmwgfx, and qxl. * Update imx-drm's CRTC creation to use its existing private primary plane rather than using the primary helper function to create one. * Provide patches for weston xf86-video-modesetting that make use of the unified plane interface to make real-world testing of this patchset a bit easier. not sure other's opionions, but personally I wouldn't object to doing some of this as follow-up patchsets. Ofc my selfish motivation is that basing atomic on top of primary plane really seems like the right move, and so sooner we can get the initial parts of this patchset merged, the sooner we can try to merge atomic ;-) BR, -R Note that the first patch here is simply a build fix for current breakage of the drm-intel-nightly branch of the drm-intel repo. Matt Roper (14): SQUASH! drm/i915: Do not dereference pointers from ring buffer in evict event drm: Add support for multiple plane types drm: Add primary plane helpers drm/exynos: Restrict plane loops to only operate on overlay planes drm/i915: Restrict plane loops to only operate on overlay planes drm: Add plane type property drm: Specify primary plane at CRTC initialization (v2) drm: Replace crtc fb with primary plane fb (v2) drm: Allow userspace to ask for full plane list (universal planes) drm/i915: Rename similar plane functions to avoid confusion drm/i915: Intel-specific primary plane handling drm: Specify cursor plane at CRTC initialization drm/i915: Split cursor update code from cursor ioctl handling drm/i915: Add cursor handlers and create cursor at crtc init drivers/gpu/drm/armada/armada_crtc.c | 4 +- drivers/gpu/drm/armada/armada_overlay.c | 3 +- drivers/gpu/drm/ast/ast_mode.c | 16 +- drivers/gpu/drm/bochs/bochs_kms.c| 8 +- drivers/gpu/drm/cirrus/cirrus_mode.c | 15 +- drivers/gpu/drm/drm_crtc.c | 441 +++ drivers/gpu/drm/drm_crtc_helper.c| 21 +- drivers/gpu/drm/drm_fb_helper.c | 9 +- drivers/gpu/drm/drm_ioctl.c | 5 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 + drivers/gpu/drm/exynos/exynos_drm_plane.c| 4 +- drivers/gpu/drm/gma500/cdv_intel_display.c | 2 +- drivers/gpu/drm/gma500/cdv_intel_dp.c| 2 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/gma_display.c | 17 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c| 2 +- drivers/gpu/drm/gma500/mdfld_intel_display.c | 17 +- drivers/gpu/drm/gma500/oaktrail_crtc.c | 13 +- drivers/gpu/drm/gma500/psb_intel_display.c | 7 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 2 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_irq.c | 4 +- drivers/gpu/drm/i915/i915_trace.h| 2 +- drivers/gpu/drm/i915/intel_display.c | 623 ---
Re: [Intel-gfx] [PATCH] drm/i915: Fix up the forcewake timer initialization
On Tue, Mar 18, 2014 at 04:31:03PM +0100, Daniel Vetter wrote:
This is a regression introduced in
commit 0294ae7b44bba7ab0d4cef9a8736287f38bdb4fd
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Mar 13 12:00:29 2014 +
drm/i915: Consolidate forcewake resetting to a single function
The reordered setup sequence ended up calling del_timer_sync before
the timer was set up correctly, resulting in endless hilarity when
loading the driver.
Compared to Ben's patch (which moved around the setup_timer call to
sanitize_early) this moves the sanitize_early call around in the
driver load call. This way we avoid calling setup_timer again in the
resume code (where we also call sanitize_early).
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Mika Kuoppala mika.kuopp...@intel.com
Cc: Ben Widawsky benjamin.widaw...@intel.com
Tested-by: Rodrigo Vivi rodrigo.v...@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76242
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_dma.c | 2 --
drivers/gpu/drm/i915/intel_uncore.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e4d2b9f15ae2..9faee49f210d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1608,8 +1608,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
goto put_bridge;
}
- intel_uncore_early_sanitize(dev);
-
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e2e328d86aff..c3832d9270a6 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -736,6 +736,8 @@ void intel_uncore_init(struct drm_device *dev)
setup_timer(dev_priv-uncore.force_wake_timer,
gen6_force_wake_timer, (unsigned long)dev_priv);
+ intel_uncore_early_sanitize(dev);
+
if (IS_VALLEYVIEW(dev)) {
dev_priv-uncore.funcs.force_wake_get = __vlv_force_wake_get;
dev_priv-uncore.funcs.force_wake_put = __vlv_force_wake_put;
If you only want to setup_timer once, the setup_timer call should be in
intel_uncore_init() which is the only one called only at load time. And
of course, this is where the bug is. Otherwise, thaw calls
uncore_early_sanitize, which will setup_timer again (which I thought was
your complaint with my original patch).
How about this, (only minimally tested):
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e2e328d..7ef5aa3 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -387,8 +387,6 @@ void intel_uncore_early_sanitize(struct drm_device *dev)
if (IS_GEN6(dev) || IS_GEN7(dev))
__raw_i915_write32(dev_priv, GTFIFODBG,
__raw_i915_read32(dev_priv, GTFIFODBG));
-
- intel_uncore_forcewake_reset(dev, false);
}
void intel_uncore_sanitize(struct drm_device *dev)
@@ -413,6 +411,8 @@ void intel_uncore_sanitize(struct drm_device *dev)
mutex_unlock(dev_priv-rps.hw_lock);
}
+
+ intel_uncore_forcewake_reset(dev, false);
}
/*
@@ -846,7 +846,6 @@ void intel_uncore_fini(struct drm_device *dev)
{
/* Paranoia: make sure we have disabled everything before we exit. */
intel_uncore_sanitize(dev);
- intel_uncore_forcewake_reset(dev, false);
}
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/26] drm/i915: Page table helpers, and define renames
On Tue, Mar 18, 2014 at 11:29:58AM -0700, Jesse Barnes wrote:
On Tue, 18 Mar 2014 09:05:58 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Mar 17, 2014 at 10:48:44PM -0700, Ben Widawsky wrote:
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -1,8 +1,11 @@
#ifndef _I915_GEM_GTT_H
#define _I915_GEM_GTT_H
-#define GEN6_PPGTT_PD_ENTRIES 512
-#define I915_PPGTT_PT_ENTRIES (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
+/* GEN Agnostic defines */
+#define I915_PDES_PER_PD 512
+#define I915_PTE_MASK(PAGE_SHIFT-1)
That looks decidely fishy.
PAGE_SHIFT is 12 - PTE_MASK = 0xb
Thanks for catching this. I'll presume the define isn't even used.
+#define I915_PDE_MASK(I915_PDES_PER_PD-1)
+
typedef uint32_t gen6_gtt_pte_t;
typedef uint64_t gen8_gtt_pte_t;
typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
@@ -23,6 +26,98 @@ typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
#define GEN6_PTE_ADDR_ENCODE(addr) GEN6_GTT_ADDR_ENCODE(addr)
#define HSW_PTE_ADDR_ENCODE(addr)HSW_GTT_ADDR_ENCODE(addr)
+
+/* GEN6 PPGTT resembles a 2 level page table:
+ * 31:22 | 21:12 | 11:0
+ * PDE | PTE | offset
+ */
+#define GEN6_PDE_SHIFT 22
+#define GEN6_PTES_PER_PT (PAGE_SIZE / sizeof(gen6_gtt_pte_t))
+
+static inline uint32_t i915_pte_index(uint64_t address, uint32_t
pde_shift)
+{
+ const uint32_t mask = (1 (pde_shift - PAGE_SHIFT)) - 1;
+ return (address PAGE_SHIFT) mask;
+}
+
+/* Helper to counts the number of PTEs within the given length. This
count does
+ * not cross a page table boundary, so the max value would be
+ * GEN6_PTES_PER_PT for GEN6, and GEN8_PTES_PER_PT for GEN8.
+ */
+static inline size_t i915_pte_count(uint64_t addr, size_t length,
+ uint32_t pde_shift)
+{
+ const uint64_t pd_mask = ~((1 pde_shift) - 1);
+ uint64_t end;
+
+ if (WARN_ON(!length))
+ return 0;
+
+ if (WARN_ON(addr % PAGE_SIZE))
+ addr = round_down(addr, PAGE_SIZE);
+
+ if (WARN_ON(length % PAGE_SIZE))
+ length = round_up(length, PAGE_SIZE);
Oh oh. I think these fixups are very suspect, so just
BUG_ON(length == 0);
BUG_ON(offset_in_page(addr|length));
I thought someone might have an issue with the BUG_ON. But I prefer it
as well.
+
+ end = addr + length;
+
+ if ((addr pd_mask) != (end pd_mask))
+ return (1 (pde_shift - PAGE_SHIFT)) -
#define NUM_PTE(pde_shift) (1 (pde_shift - PAGE_SHIFT))
here and for computing the pd_mask.
+ i915_pte_index(addr, pde_shift);
+
+ return i915_pte_index(end, pde_shift) - i915_pte_index(addr, pde_shift);
+}
Otherwise the helpers look a useful improvement in readability.
-Chris
Can we use GTT_PAGE_SIZE here too? I'm worried the kernel PAGE_SIZE
will change at some point and blow us up. At least in places where
we're doing our own thing rather than using the x86 bits...
That's fine with me. We have quite a few other places in our code which
depend on PAGE_SIZE being 4k though.
It's likely I'll be maintaining this branch myself for a while, but I'll
modify these both locally.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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] linux-next: build failure after merge of the drm-intel tree
Hi all,
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/trace/define_trace.h:90:0,
from drivers/gpu/drm/i915/i915_trace.h:520,
from drivers/gpu/drm/i915/i915_trace_points.c:12:
drivers/gpu/drm/i915/./i915_trace.h: In function
'ftrace_raw_event_i915_gem_evict_vm':
drivers/gpu/drm/i915/./i915_trace.h:246:22: error: 'dev' undeclared (first use
in this function)
__entry-dev = dev-primary-index;
^
include/trace/ftrace.h:574:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(i915_gem_evict_vm,
^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^
drivers/gpu/drm/i915/./i915_trace.h:246:22: note: each undeclared identifier is
reported only once for each function it appears in
__entry-dev = dev-primary-index;
^
include/trace/ftrace.h:574:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(i915_gem_evict_vm,
^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^
In file included from include/trace/define_trace.h:90:0,
from drivers/gpu/drm/i915/i915_trace.h:520,
from drivers/gpu/drm/i915/i915_trace_points.c:12:
drivers/gpu/drm/i915/./i915_trace.h: In function 'perf_trace_i915_gem_evict_vm':
drivers/gpu/drm/i915/./i915_trace.h:246:22: error: 'dev' undeclared (first use
in this function)
__entry-dev = dev-primary-index;
^
include/trace/ftrace.h:708:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^
include/trace/ftrace.h:36:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^
drivers/gpu/drm/i915/./i915_trace.h:236:1: note: in expansion of macro
'TRACE_EVENT'
TRACE_EVENT(i915_gem_evict_vm,
^
drivers/gpu/drm/i915/./i915_trace.h:245:6: note: in expansion of macro
'TP_fast_assign'
TP_fast_assign(
^
Caused by commit a25ca17c1eac (drm/i915: Do not dereference pointers
from ring buffer in evict event).
I have used the drm-intel tree from next-20140318 for today.
--
Cheers,
Stephen Rothwell s...@canb.auug.org.au
pgpqeWOMxmBp5.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel tree
On Wed, 19 Mar 2014 11:53:50 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: Caused by commit a25ca17c1eac (drm/i915: Do not dereference pointers from ring buffer in evict event). I have used the drm-intel tree from next-20140318 for today. Bah! I'm still suffering from jet lag (just came back from Linux-Tage in Chemnitz). The next time I compile test a patch for a module, I'll make sure I have that module's config option set :-( The woe of using localmodconfig. I should have picked the box with the i915. :-/ Below is the fix. I'll repost a v2 of the original patch. Sorry about that. -- Steve diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index f3e8a90..783ae08 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -243,7 +243,7 @@ TRACE_EVENT(i915_gem_evict_vm, ), TP_fast_assign( - __entry-dev = dev-primary-index; + __entry-dev = vm-dev-primary-index; __entry-vm = vm; ), ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Rename and comment all the RPS *stuff*
On Sat, Feb 22, 2014 at 01:37:16PM +, Chris Wilson wrote: On Mon, Feb 17, 2014 at 07:01:44PM -0800, Ben Widawsky wrote: The names of the struct members for RPS are stupid. Every time I need to do anything in this code I have to spend a significant amount of time to remember what it all means. By renaming the variables (and adding the comments) I hope to clear up the situation. Indeed doing this make some upcoming patches more readable. I've avoided ILK because it's possible that the naming used for Ironlake matches what is in the docs. I believe the ILK power docs were never published, and I am too lazy to dig them up. While there may be mistakes, this patch was mostly done via sed. The renaming of hw_max required a bit of interactivity. It lost the distinction between RPe and RPn. I am in favour of keeping RP0, RP1, RPe, RPn for the hardware/spec values and adding the set of soft values used for actual interaction. -Chris Okay, as stated before, you are correct - I need to bring back RPe/RPn distinction. I think using the mix of values (basically s/_delay/_freq) doesn't fully relize what I was hoping to achieve. I don't think there is ever a case, except when debugging where it's easier to refer to the RP mnemonic. How strongly do you feel about this one? I'd really prefer to just fix RPe/RPn. Does anyone else have an opinion on: max_freq_hardlimit vs. rp0 Does anyone else want to review this one? -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-intel tree
On Tue, Mar 18, 2014 at 09:18:42PM -0400, Steven Rostedt wrote: On Wed, 19 Mar 2014 11:53:50 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: Caused by commit a25ca17c1eac (drm/i915: Do not dereference pointers from ring buffer in evict event). I have used the drm-intel tree from next-20140318 for today. Bah! I'm still suffering from jet lag (just came back from Linux-Tage in Chemnitz). The next time I compile test a patch for a module, I'll make sure I have that module's config option set :-( The woe of using localmodconfig. I should have picked the box with the i915. :-/ Below is the fix. I'll repost a v2 of the original patch. Sorry about that. I was about to send out the same fix when I saw this. Reviewed-by: Ben Widawsky b...@bwidawsk.net -- Steve diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h index f3e8a90..783ae08 100644 --- a/drivers/gpu/drm/i915/i915_trace.h +++ b/drivers/gpu/drm/i915/i915_trace.h @@ -243,7 +243,7 @@ TRACE_EVENT(i915_gem_evict_vm, ), TP_fast_assign( -__entry-dev = dev-primary-index; +__entry-dev = vm-dev-primary-index; __entry-vm = vm; ), ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: no MCHBAR on VLV
Hi Jesse,
I just registered patchwork account in freedesktop.org, but I don't know how to
add reviewed by to the patch http://patchwork.freedesktop.org/patch/21324/.
Could you tell me how to add reviewed by to the patch?
Thanks,
Junxiao
-Original Message-
From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
Sent: Wednesday, March 19, 2014 2:13 AM
To: Jesse Barnes
Cc: intel-gfx@lists.freedesktop.org; Chang, Junxiao
Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: no MCHBAR on VLV
Junxiao, can you add you reviewed-by to this patch?
Thanks,
Jesse
On Mon, 3 Mar 2014 14:27:57 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
So don't try to allocate and program it, we're only fooling ourselves.
Reported-by: Chang, Junxiao junxiao.ch...@intel.com
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c index 7688abc..22f839b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1187,6 +1187,9 @@ intel_setup_mchbar(struct drm_device *dev)
u32 temp;
bool enabled;
+ if (IS_VALLEYVIEW(dev))
+ return;
+
dev_priv-mchbar_need_disable = false;
if (IS_I915G(dev) || IS_I915GM(dev)) {
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: no MCHBAR on VLV
On Wed, Mar 19, 2014 at 12:13 PM, Chang, Junxiao junxiao.ch...@intel.com wrote: Hi Jesse, I just registered patchwork account in freedesktop.org, but I don't know how to add reviewed by to the patch http://patchwork.freedesktop.org/patch/21324/. Could you tell me how to add reviewed by to the patch? Just reply here, with Reviewed-by: tag, and patckwork picks it up. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Rename and comment all the RPS *stuff*
On Tue, Mar 18, 2014 at 06:27:03PM -0700, Ben Widawsky wrote: On Sat, Feb 22, 2014 at 01:37:16PM +, Chris Wilson wrote: On Mon, Feb 17, 2014 at 07:01:44PM -0800, Ben Widawsky wrote: The names of the struct members for RPS are stupid. Every time I need to do anything in this code I have to spend a significant amount of time to remember what it all means. By renaming the variables (and adding the comments) I hope to clear up the situation. Indeed doing this make some upcoming patches more readable. I've avoided ILK because it's possible that the naming used for Ironlake matches what is in the docs. I believe the ILK power docs were never published, and I am too lazy to dig them up. While there may be mistakes, this patch was mostly done via sed. The renaming of hw_max required a bit of interactivity. It lost the distinction between RPe and RPn. I am in favour of keeping RP0, RP1, RPe, RPn for the hardware/spec values and adding the set of soft values used for actual interaction. -Chris Okay, as stated before, you are correct - I need to bring back RPe/RPn distinction. I think using the mix of values (basically s/_delay/_freq) doesn't fully relize what I was hoping to achieve. I don't think there is ever a case, except when debugging where it's easier to refer to the RP mnemonic. How strongly do you feel about this one? I'd really prefer to just fix RPe/RPn. Does anyone else have an opinion on: max_freq_hardlimit vs. rp0 Does anyone else want to review this one? Okay, I started on this, and I somewhat agree. How about: u8 cur_freq;/* Current frequency (cached, may not == HW) */ u8 min_freq_softlimit; /* Minimum frequency permitted by the driver */ u8 max_freq_softlimit; /* Max frequency permitted by the driver */ u8 max_freq;/* Maximum frequency, RP0 if not overclocking */ u8 min_freq;/* AKA RPn. Minimum frequency */ u8 efficient_freq; /* AKA RPe. Pre-determined balanced frequency */ u8 rp1_freq;/* less than RP0 power/freqency */ u8 rp0_freq;/* Non-overclocked max frequency. */ Conveniently, this matches sysfs, minus the efficiency one, and I don't think there's a point in explicitly storing RPn, since it's always == min_freq. -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: no MCHBAR on VLV
Reviewed-by: Junxiao Chang junxiao.ch...@intel.com Thanks, Junxiao -Original Message- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Wednesday, March 19, 2014 10:32 AM To: Chang, Junxiao Cc: Jesse Barnes; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: no MCHBAR on VLV On Wed, Mar 19, 2014 at 12:13 PM, Chang, Junxiao junxiao.ch...@intel.com wrote: Hi Jesse, I just registered patchwork account in freedesktop.org, but I don't know how to add reviewed by to the patch http://patchwork.freedesktop.org/patch/21324/. Could you tell me how to add reviewed by to the patch? Just reply here, with Reviewed-by: tag, and patckwork picks it up. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
