* Re: [PATCH 3/4] drm/i915: Allow userspace to hint that the relocations were known
From: Daniel Vetter @ 2012-11-10 17:16 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <1352560547-1423-3-git-send-email-chris@chris-wilson.co.uk>
On Sat, Nov 10, 2012 at 03:15:46PM +0000, Chris Wilson wrote:
> Userspace is able to hint to the kernel that its command stream and
> auxiliary state buffers already hold the correct presumed addresses and
> so the relocation process may be skipped if the kernel does not need to
> move any buffers in preparation for the execbuffer. Thus for the common
> case where the allotment of buffers is static between batches, we can
> avoid the overhead of individually checking the relocation entries.
>
> Note that this requires userspace to supply the domain tracking and
> requests for workarounds itself that would otherwise be computed based
> upon the relocation entries.
>
> Using copywinwin10 as an example that is dependent upon emitting a lot
> of relocations (2 per operation), we see improvements of:
>
> c2d/gm45: 618000.0/sec to 632000.0/sec.
> i3-330m: 748000.0/sec to 830000.0/sec.
>
> (measured relative to a baseline with neither optimisations applied).
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Nice stuff! A few requests from you bastard maintainer though for this
patch series:
- An i-g-t testcase for the reloc.handle checking, both for the
out-of-bounds case for the LUT and the "no such object" for the old
case. At least I couldn't find anything like that on a quick check.
- Also an i-g-t test to check whether the gen6 "global gtt mapping for
pipe control writes" w/a works would be great, since we've fumbled that.
Again for both the old and new ways of doing things.
- I think we should start checking for not yet defined flag values
everywhere in execbuf and return -EINVAL - both to make the ioctl more
robust against broken userspace (we've already had such an OOPS-causing
issue with cpu domains in relocations). And to ensure that we can keep
on extending things. Obviously needs to come with an i-g-t check. I know
that every extension will then break old i-g-t versions of that tests,
but imo the more rigid abi checking is worth that tradeoff.
The above i-g-t stuff could be a nice exercise for reviewers ... </hint>
On the patch itself:
- Some small comment on EXEC_OBJECT_NEEDS_GTT explaing that we need this
for a gen6 w/a and that it's valid only with the NO_RELOC mode.
- Can we abolish the pending_read/write_domains and just go with a
per-object GPU_WRITE flag? Afaik that's all we need with the
flushing_list gone. To avoid a massive rewrite of the code I'm thinking
of just keeping around a pending_gpu_write bool (since reads are
implicit) and then using that to fill out generic gpu domains in
i915_gem_execbuffer_move_to_active. E.g. set all gpu read domains if
there is no write, otherwise just set the render domain in both.
While reading through the code I've also noticed that we could replace the
obj->write_domain check in there (for updating the write_seqno) with a
pending_gpu_write check - the former was required due to the delayed
flushing caused by the flushing_list.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_dma.c | 3 ++
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 50 ++++++++++++++++++----------
> include/uapi/drm/i915_drm.h | 11 ++++++
> 3 files changed, 46 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 4beb7bc..a0c4b4f 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1017,6 +1017,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
> case I915_PARAM_HAS_SECURE_BATCHES:
> value = capable(CAP_SYS_ADMIN);
> break;
> + case I915_PARAM_HAS_EXEC_NO_RELOC:
> + value = 1;
> + break;
> default:
> DRM_DEBUG_DRIVER("Unknown parameter %d\n",
> param->param);
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 1738ebd..30beea6 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -412,7 +412,8 @@ i915_gem_execbuffer_relocate(struct drm_device *dev,
>
> static int
> i915_gem_execbuffer_reserve_object(struct drm_i915_gem_object *obj,
> - struct intel_ring_buffer *ring)
> + struct intel_ring_buffer *ring,
> + bool *need_reloc)
> {
> struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
> struct drm_i915_gem_exec_object2 *entry = obj->exec_entry;
> @@ -452,7 +453,18 @@ i915_gem_execbuffer_reserve_object(struct drm_i915_gem_object *obj,
> obj->has_aliasing_ppgtt_mapping = 1;
> }
>
> - entry->offset = obj->gtt_offset;
> + if (entry->offset != obj->gtt_offset) {
> + entry->offset = obj->gtt_offset;
> + *need_reloc = true;
> + }
> +
> + obj->base.pending_read_domains = entry->rsvd1 & 0xffffffff;
> + obj->base.pending_write_domain = (entry->rsvd1 >> 32) & 0xffffffff;
> +
> + if (entry->flags & EXEC_OBJECT_NEEDS_GTT &&
> + !obj->has_global_gtt_mapping)
> + i915_gem_gtt_bind_object(obj, obj->cache_level);
> +
> return 0;
> }
>
> @@ -478,7 +490,8 @@ i915_gem_execbuffer_unreserve_object(struct drm_i915_gem_object *obj)
> static int
> i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
> struct drm_file *file,
> - struct list_head *objects)
> + struct list_head *objects,
> + bool *need_relocs)
> {
> struct drm_i915_gem_object *obj;
> struct list_head ordered_objects;
> @@ -502,8 +515,6 @@ i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
> else
> list_move_tail(&obj->exec_list, &ordered_objects);
>
> - obj->base.pending_read_domains = 0;
> - obj->base.pending_write_domain = 0;
> obj->pending_fenced_gpu_access = false;
> }
> list_splice(&ordered_objects, objects);
> @@ -541,7 +552,7 @@ i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
> (need_fence && !obj->map_and_fenceable))
> ret = i915_gem_object_unbind(obj);
> else
> - ret = i915_gem_execbuffer_reserve_object(obj, ring);
> + ret = i915_gem_execbuffer_reserve_object(obj, ring, need_relocs);
> if (ret)
> goto err;
> }
> @@ -551,7 +562,7 @@ i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
> if (obj->gtt_space)
> continue;
>
> - ret = i915_gem_execbuffer_reserve_object(obj, ring);
> + ret = i915_gem_execbuffer_reserve_object(obj, ring, need_relocs);
> if (ret)
> goto err;
> }
> @@ -571,16 +582,18 @@ err: /* Decrement pin count for bound objects */
>
> static int
> i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
> + struct drm_i915_gem_execbuffer2 *args,
> struct drm_file *file,
> struct intel_ring_buffer *ring,
> struct eb_objects *eb,
> - struct drm_i915_gem_exec_object2 *exec,
> - int count)
> + struct drm_i915_gem_exec_object2 *exec)
> {
> struct drm_i915_gem_relocation_entry *reloc;
> struct drm_i915_gem_object *obj;
> + bool need_relocs;
> int *reloc_offset;
> int i, total, ret;
> + int count = args->buffer_count;
>
> /* We may process another execbuffer during the unlock... */
> while (!list_empty(&eb->objects)) {
> @@ -635,7 +648,8 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
> if (ret)
> goto err;
>
> - ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects);
> + need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
> + ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects, &need_relocs);
> if (ret)
> goto err;
>
> @@ -848,10 +862,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> struct intel_ring_buffer *ring;
> u32 ctx_id = i915_execbuffer2_get_context_id(*args);
> u32 exec_start, exec_len;
> - u32 seqno;
> - u32 mask;
> - u32 flags;
> + u32 seqno, mask, flags;
> int ret, mode, i;
> + bool need_relocs;
>
> if (!i915_gem_check_execbuffer(args)) {
> DRM_DEBUG("execbuf with invalid offset/length\n");
> @@ -993,17 +1006,18 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
> exec_list);
>
> /* Move the objects en-masse into the GTT, evicting if necessary. */
> - ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects);
> + need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
> + ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects, &need_relocs);
> if (ret)
> goto err;
>
> /* The objects are in their final locations, apply the relocations. */
> - ret = i915_gem_execbuffer_relocate(dev, eb);
> + if (need_relocs)
> + ret = i915_gem_execbuffer_relocate(dev, eb);
> if (ret) {
> if (ret == -EFAULT) {
> - ret = i915_gem_execbuffer_relocate_slow(dev, file, ring,
> - eb, exec,
> - args->buffer_count);
> + ret = i915_gem_execbuffer_relocate_slow(dev, args, file, ring,
> + eb, exec);
> BUG_ON(!mutex_is_locked(&dev->struct_mutex));
> }
> if (ret)
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 067b98e..7657d3e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -309,6 +309,7 @@ typedef struct drm_i915_irq_wait {
> #define I915_PARAM_HAS_PRIME_VMAP_FLUSH 21
> #define I915_PARAM_RSVD_FOR_FUTURE_USE 22
> #define I915_PARAM_HAS_SECURE_BATCHES 23
> +#define I915_PARAM_HAS_EXEC_NO_RELOC 24
>
> typedef struct drm_i915_getparam {
> int param;
> @@ -629,7 +630,10 @@ struct drm_i915_gem_exec_object2 {
> __u64 offset;
>
> #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
> +#define EXEC_OBJECT_NEEDS_GTT (1<<1)
> __u64 flags;
> +
> + /** Low 32-bits for read-domains, high 32-bits for write-domains. */
> __u64 rsvd1;
> __u64 rsvd2;
> };
> @@ -679,6 +683,13 @@ struct drm_i915_gem_execbuffer2 {
> */
> #define I915_EXEC_SECURE (1<<9)
>
> +/** Provide a hint to the kernel that the command stream and auxilliary
> + * state buffers already holds the correct presumed addresses and so the
> + * relocation process may be skipped if no buffers need to be moved in
> + * preparation for the execbuffer.
> + */
> +#define I915_EXEC_NO_RELOC (1<<10)
> +
> #define I915_EXEC_CONTEXT_ID_MASK (0xffffffff)
> #define i915_execbuffer2_set_context_id(eb2, context) \
> (eb2).rsvd1 = context & I915_EXEC_CONTEXT_ID_MASK
> --
> 1.7.10.4
>
> _______________________________________________
> 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
^ permalink raw reply
* [PATCH] drm/i915/i2c: Track users of GMBUS force-bit
From: Chris Wilson @ 2012-11-10 15:58 UTC (permalink / raw)
To: intel-gfx; +Cc: Jani Nikula, Mika Kuoppala
This fixes a regression for SDVO from
commit fbfcc4f3a0cf8bbde87646b74241faa8e37426bf
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Oct 22 16:12:18 2012 +0300
drm/i915/sdvo: restore i2c adapter config on intel_sdvo_init() failures
As SDVOB and SDVOC are multiplexed on the same pin, if a chipset does
not have the second SDVO encoder, it will then remove the force-bit
setting on the common i2c adapter during teardown. All subsequent
attempts of trying to use GMBUS with SDVOB then fail.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_i2c.c | 9 ++++++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c2daad1..cf407b1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -394,7 +394,7 @@ struct intel_fbc_work;
struct intel_gmbus {
struct i2c_adapter adapter;
- bool force_bit;
+ u32 force_bit;
u32 reg0;
u32 gpio_reg;
struct i2c_algo_bit_data bit_algo;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 84b68a6..f8ca0be 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -482,7 +482,7 @@ timeout:
I915_WRITE(GMBUS0 + reg_offset, 0);
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging instead. */
- bus->force_bit = true;
+ bus->force_bit = 1;
ret = i2c_bit_algo.master_xfer(adapter, msgs, num);
out:
@@ -542,7 +542,7 @@ int intel_setup_gmbus(struct drm_device *dev)
/* gmbus seems to be broken on i830 */
if (IS_I830(dev))
- bus->force_bit = true;
+ bus->force_bit = 1;
intel_gpio_setup(bus, port);
@@ -583,7 +583,10 @@ void intel_gmbus_force_bit(struct i2c_adapter *adapter, bool force_bit)
{
struct intel_gmbus *bus = to_intel_gmbus(adapter);
- bus->force_bit = force_bit;
+ bus->force_bit += force_bit ? 1 : -1;
+ DRM_DEBUG_KMS("%sabling bit-banging on %s. force bit now %d\n",
+ force_bit ? "dis" : "en", adapter->name,
+ bus->force_bit);
}
void intel_teardown_gmbus(struct drm_device *dev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/4] drm/i915: Allow userspace to hint that the relocations were known
From: Chris Wilson @ 2012-11-10 15:15 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1352560547-1423-1-git-send-email-chris@chris-wilson.co.uk>
Userspace is able to hint to the kernel that its command stream and
auxiliary state buffers already hold the correct presumed addresses and
so the relocation process may be skipped if the kernel does not need to
move any buffers in preparation for the execbuffer. Thus for the common
case where the allotment of buffers is static between batches, we can
avoid the overhead of individually checking the relocation entries.
Note that this requires userspace to supply the domain tracking and
requests for workarounds itself that would otherwise be computed based
upon the relocation entries.
Using copywinwin10 as an example that is dependent upon emitting a lot
of relocations (2 per operation), we see improvements of:
c2d/gm45: 618000.0/sec to 632000.0/sec.
i3-330m: 748000.0/sec to 830000.0/sec.
(measured relative to a baseline with neither optimisations applied).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_dma.c | 3 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 50 ++++++++++++++++++----------
include/uapi/drm/i915_drm.h | 11 ++++++
3 files changed, 46 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4beb7bc..a0c4b4f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1017,6 +1017,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_SECURE_BATCHES:
value = capable(CAP_SYS_ADMIN);
break;
+ case I915_PARAM_HAS_EXEC_NO_RELOC:
+ value = 1;
+ break;
default:
DRM_DEBUG_DRIVER("Unknown parameter %d\n",
param->param);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1738ebd..30beea6 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -412,7 +412,8 @@ i915_gem_execbuffer_relocate(struct drm_device *dev,
static int
i915_gem_execbuffer_reserve_object(struct drm_i915_gem_object *obj,
- struct intel_ring_buffer *ring)
+ struct intel_ring_buffer *ring,
+ bool *need_reloc)
{
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
struct drm_i915_gem_exec_object2 *entry = obj->exec_entry;
@@ -452,7 +453,18 @@ i915_gem_execbuffer_reserve_object(struct drm_i915_gem_object *obj,
obj->has_aliasing_ppgtt_mapping = 1;
}
- entry->offset = obj->gtt_offset;
+ if (entry->offset != obj->gtt_offset) {
+ entry->offset = obj->gtt_offset;
+ *need_reloc = true;
+ }
+
+ obj->base.pending_read_domains = entry->rsvd1 & 0xffffffff;
+ obj->base.pending_write_domain = (entry->rsvd1 >> 32) & 0xffffffff;
+
+ if (entry->flags & EXEC_OBJECT_NEEDS_GTT &&
+ !obj->has_global_gtt_mapping)
+ i915_gem_gtt_bind_object(obj, obj->cache_level);
+
return 0;
}
@@ -478,7 +490,8 @@ i915_gem_execbuffer_unreserve_object(struct drm_i915_gem_object *obj)
static int
i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
struct drm_file *file,
- struct list_head *objects)
+ struct list_head *objects,
+ bool *need_relocs)
{
struct drm_i915_gem_object *obj;
struct list_head ordered_objects;
@@ -502,8 +515,6 @@ i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
else
list_move_tail(&obj->exec_list, &ordered_objects);
- obj->base.pending_read_domains = 0;
- obj->base.pending_write_domain = 0;
obj->pending_fenced_gpu_access = false;
}
list_splice(&ordered_objects, objects);
@@ -541,7 +552,7 @@ i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
(need_fence && !obj->map_and_fenceable))
ret = i915_gem_object_unbind(obj);
else
- ret = i915_gem_execbuffer_reserve_object(obj, ring);
+ ret = i915_gem_execbuffer_reserve_object(obj, ring, need_relocs);
if (ret)
goto err;
}
@@ -551,7 +562,7 @@ i915_gem_execbuffer_reserve(struct intel_ring_buffer *ring,
if (obj->gtt_space)
continue;
- ret = i915_gem_execbuffer_reserve_object(obj, ring);
+ ret = i915_gem_execbuffer_reserve_object(obj, ring, need_relocs);
if (ret)
goto err;
}
@@ -571,16 +582,18 @@ err: /* Decrement pin count for bound objects */
static int
i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
+ struct drm_i915_gem_execbuffer2 *args,
struct drm_file *file,
struct intel_ring_buffer *ring,
struct eb_objects *eb,
- struct drm_i915_gem_exec_object2 *exec,
- int count)
+ struct drm_i915_gem_exec_object2 *exec)
{
struct drm_i915_gem_relocation_entry *reloc;
struct drm_i915_gem_object *obj;
+ bool need_relocs;
int *reloc_offset;
int i, total, ret;
+ int count = args->buffer_count;
/* We may process another execbuffer during the unlock... */
while (!list_empty(&eb->objects)) {
@@ -635,7 +648,8 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
if (ret)
goto err;
- ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects);
+ need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
+ ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects, &need_relocs);
if (ret)
goto err;
@@ -848,10 +862,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct intel_ring_buffer *ring;
u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 exec_start, exec_len;
- u32 seqno;
- u32 mask;
- u32 flags;
+ u32 seqno, mask, flags;
int ret, mode, i;
+ bool need_relocs;
if (!i915_gem_check_execbuffer(args)) {
DRM_DEBUG("execbuf with invalid offset/length\n");
@@ -993,17 +1006,18 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
exec_list);
/* Move the objects en-masse into the GTT, evicting if necessary. */
- ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects);
+ need_relocs = (args->flags & I915_EXEC_NO_RELOC) == 0;
+ ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects, &need_relocs);
if (ret)
goto err;
/* The objects are in their final locations, apply the relocations. */
- ret = i915_gem_execbuffer_relocate(dev, eb);
+ if (need_relocs)
+ ret = i915_gem_execbuffer_relocate(dev, eb);
if (ret) {
if (ret == -EFAULT) {
- ret = i915_gem_execbuffer_relocate_slow(dev, file, ring,
- eb, exec,
- args->buffer_count);
+ ret = i915_gem_execbuffer_relocate_slow(dev, args, file, ring,
+ eb, exec);
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
}
if (ret)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 067b98e..7657d3e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -309,6 +309,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_PRIME_VMAP_FLUSH 21
#define I915_PARAM_RSVD_FOR_FUTURE_USE 22
#define I915_PARAM_HAS_SECURE_BATCHES 23
+#define I915_PARAM_HAS_EXEC_NO_RELOC 24
typedef struct drm_i915_getparam {
int param;
@@ -629,7 +630,10 @@ struct drm_i915_gem_exec_object2 {
__u64 offset;
#define EXEC_OBJECT_NEEDS_FENCE (1<<0)
+#define EXEC_OBJECT_NEEDS_GTT (1<<1)
__u64 flags;
+
+ /** Low 32-bits for read-domains, high 32-bits for write-domains. */
__u64 rsvd1;
__u64 rsvd2;
};
@@ -679,6 +683,13 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_SECURE (1<<9)
+/** Provide a hint to the kernel that the command stream and auxilliary
+ * state buffers already holds the correct presumed addresses and so the
+ * relocation process may be skipped if no buffers need to be moved in
+ * preparation for the execbuffer.
+ */
+#define I915_EXEC_NO_RELOC (1<<10)
+
#define I915_EXEC_CONTEXT_ID_MASK (0xffffffff)
#define i915_execbuffer2_set_context_id(eb2, context) \
(eb2).rsvd1 = context & I915_EXEC_CONTEXT_ID_MASK
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/4] drm/i915: Use the reloc.handle as an index into the execbuffer array
From: Chris Wilson @ 2012-11-10 15:15 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1352560547-1423-1-git-send-email-chris@chris-wilson.co.uk>
Using copywinwin10 as an example that is dependent upon emitting a lot
of relocations (2 per operation), we see improvements of:
c2d/gm45: 618000.0/sec to 623000.0/sec.
i3-330m: 748000.0/sec to 789000.0/sec.
(measured relative to a baseline with neither optimisations applied).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_dma.c | 3 +
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 90 +++++++++++++++++-----------
include/uapi/drm/i915_drm.h | 6 ++
3 files changed, 63 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a0c4b4f..a35217d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1020,6 +1020,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_EXEC_NO_RELOC:
value = 1;
break;
+ case I915_PARAM_HAS_EXEC_HANDLE_LUT:
+ value = 1;
+ break;
default:
DRM_DEBUG_DRIVER("Unknown parameter %d\n",
param->param);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 30beea6..9ccd860 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -39,25 +39,40 @@
struct eb_objects {
struct list_head objects;
- int and;
- struct hlist_head buckets[0];
+ unsigned int and;
+ union {
+ struct drm_i915_gem_object *lut[0];
+ struct hlist_head buckets[0];
+ };
};
static struct eb_objects *
-eb_create(int size)
+eb_create(struct drm_i915_gem_execbuffer2 *args)
{
- struct eb_objects *eb;
- int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
- BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));
- while (count > size)
- count >>= 1;
- eb = kzalloc(count*sizeof(struct hlist_head) +
- sizeof(struct eb_objects),
- GFP_KERNEL);
- if (eb == NULL)
- return eb;
-
- eb->and = count - 1;
+ struct eb_objects *eb = NULL;
+
+ if (args->flags & I915_EXEC_HANDLE_LUT) {
+ int size = args->buffer_count;
+ size *= sizeof(struct drm_i915_gem_object);
+ size += sizeof(struct eb_objects);
+ eb = kzalloc(size, GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
+ }
+
+ if (eb == NULL) {
+ int size = args->buffer_count;
+ int count = (PAGE_SIZE - sizeof(struct eb_objects)) / sizeof(struct hlist_head);
+ BUILD_BUG_ON(!is_power_of_2(PAGE_SIZE / sizeof(struct hlist_head)));
+ while (count > 2*size)
+ count >>= 1;
+ eb = kzalloc(count*sizeof(struct hlist_head) +
+ sizeof(struct eb_objects),
+ GFP_TEMPORARY);
+ if (eb == NULL)
+ return eb;
+
+ eb->and = count - 1;
+ }
+
INIT_LIST_HEAD(&eb->objects);
return eb;
}
@@ -65,14 +80,8 @@ eb_create(int size)
static void
eb_reset(struct eb_objects *eb)
{
- memset(eb->buckets, 0, (eb->and+1)*sizeof(struct hlist_head));
-}
-
-static void
-eb_add_object(struct eb_objects *eb, struct drm_i915_gem_object *obj)
-{
- hlist_add_head(&obj->exec_node,
- &eb->buckets[obj->exec_handle & eb->and]);
+ if (eb->and)
+ memset(eb->buckets, 0, (eb->and+1)*sizeof(struct hlist_head));
}
static int
@@ -105,9 +114,14 @@ eb_lookup_objects(struct eb_objects *eb,
drm_gem_object_reference(&obj->base);
list_add_tail(&obj->exec_list, &eb->objects);
- obj->exec_handle = exec[i].handle;
obj->exec_entry = &exec[i];
- eb_add_object(eb, obj);
+ if (eb->and == 0) {
+ eb->lut[i] = obj;
+ } else {
+ obj->exec_handle = exec[i].handle;
+ hlist_add_head(&obj->exec_node,
+ &eb->buckets[exec[i].handle & eb->and]);
+ }
}
spin_unlock(&file->table_lock);
@@ -117,18 +131,22 @@ eb_lookup_objects(struct eb_objects *eb,
static struct drm_i915_gem_object *
eb_get_object(struct eb_objects *eb, unsigned long handle)
{
- struct hlist_head *head;
- struct hlist_node *node;
- struct drm_i915_gem_object *obj;
+ if (eb->and == 0) {
+ return eb->lut[handle];
+ } else {
+ struct hlist_head *head;
+ struct hlist_node *node;
- head = &eb->buckets[handle & eb->and];
- hlist_for_each(node, head) {
- obj = hlist_entry(node, struct drm_i915_gem_object, exec_node);
- if (obj->exec_handle == handle)
- return obj;
- }
+ head = &eb->buckets[handle & eb->and];
+ hlist_for_each(node, head) {
+ struct drm_i915_gem_object *obj;
- return NULL;
+ obj = hlist_entry(node, struct drm_i915_gem_object, exec_node);
+ if (obj->exec_handle == handle)
+ return obj;
+ }
+ return NULL;
+ }
}
static void
@@ -988,7 +1006,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto pre_mutex_err;
}
- eb = eb_create(args->buffer_count);
+ eb = eb_create(args);
if (eb == NULL) {
mutex_unlock(&dev->struct_mutex);
ret = -ENOMEM;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 7657d3e..82c1088 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -310,6 +310,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_RSVD_FOR_FUTURE_USE 22
#define I915_PARAM_HAS_SECURE_BATCHES 23
#define I915_PARAM_HAS_EXEC_NO_RELOC 24
+#define I915_PARAM_HAS_EXEC_HANDLE_LUT 25
typedef struct drm_i915_getparam {
int param;
@@ -690,6 +691,11 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_NO_RELOC (1<<10)
+/** Use the reloc.handle as an index into the exec object array rather
+ * than as the per-file handle.
+ */
+#define I915_EXEC_HANDLE_LUT (1<<11)
+
#define I915_EXEC_CONTEXT_ID_MASK (0xffffffff)
#define i915_execbuffer2_set_context_id(eb2, context) \
(eb2).rsvd1 = context & I915_EXEC_CONTEXT_ID_MASK
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/4] drm/i915: Take the handle idr spinlock once for looking up the exec objects
From: Chris Wilson @ 2012-11-10 15:15 UTC (permalink / raw)
To: intel-gfx
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 86 +++++++++++++++-------------
1 file changed, 46 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index b33d525..c491ab1 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -73,6 +73,46 @@ eb_add_object(struct eb_objects *eb, struct drm_i915_gem_object *obj)
&eb->buckets[obj->exec_handle & eb->and]);
}
+static int
+eb_lookup_objects(struct eb_objects *eb,
+ struct drm_i915_gem_exec_object2 *exec,
+ int count,
+ struct drm_file *file,
+ struct list_head *objects)
+{
+ int i;
+
+ spin_lock(&file->table_lock);
+ for (i = 0; i < count; i++) {
+ struct drm_i915_gem_object *obj;
+
+ obj = to_intel_bo(idr_find(&file->object_idr, exec[i].handle));
+ if (obj == NULL) {
+ spin_unlock(&file->table_lock);
+ DRM_DEBUG("Invalid object handle %d at index %d\n",
+ exec[i].handle, i);
+ return -ENOENT;
+ }
+
+ if (!list_empty(&obj->exec_list)) {
+ spin_unlock(&file->table_lock);
+ DRM_DEBUG("Object %p [handle %d, index %d] appears more than once in object list\n",
+ obj, exec[i].handle, i);
+ return -EINVAL;
+ }
+
+ drm_gem_object_reference(&obj->base);
+ list_add_tail(&obj->exec_list, objects);
+
+ obj->exec_handle = exec[i].handle;
+ obj->exec_entry = &exec[i];
+ eb_add_object(eb, obj);
+ }
+ spin_unlock(&file->table_lock);
+
+ return 0;
+}
+
static struct drm_i915_gem_object *
eb_get_object(struct eb_objects *eb, unsigned long handle)
{
@@ -583,21 +623,9 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
/* reacquire the objects */
eb_reset(eb);
- for (i = 0; i < count; i++) {
- obj = to_intel_bo(drm_gem_object_lookup(dev, file,
- exec[i].handle));
- if (&obj->base == NULL) {
- DRM_DEBUG("Invalid object handle %d at index %d\n",
- exec[i].handle, i);
- ret = -ENOENT;
- goto err;
- }
-
- list_add_tail(&obj->exec_list, objects);
- obj->exec_handle = exec[i].handle;
- obj->exec_entry = &exec[i];
- eb_add_object(eb, obj);
- }
+ ret = eb_lookup_objects(eb, exec, count, file, objects);
+ if (ret)
+ goto err;
ret = i915_gem_execbuffer_reserve(ring, file, objects);
if (ret)
@@ -949,31 +977,9 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
/* Look up object handles */
INIT_LIST_HEAD(&objects);
- for (i = 0; i < args->buffer_count; i++) {
- struct drm_i915_gem_object *obj;
-
- obj = to_intel_bo(drm_gem_object_lookup(dev, file,
- exec[i].handle));
- if (&obj->base == NULL) {
- DRM_DEBUG("Invalid object handle %d at index %d\n",
- exec[i].handle, i);
- /* prevent error path from reading uninitialized data */
- ret = -ENOENT;
- goto err;
- }
-
- if (!list_empty(&obj->exec_list)) {
- DRM_DEBUG("Object %p [handle %d, index %d] appears more than once in object list\n",
- obj, exec[i].handle, i);
- ret = -EINVAL;
- goto err;
- }
-
- list_add_tail(&obj->exec_list, &objects);
- obj->exec_handle = exec[i].handle;
- obj->exec_entry = &exec[i];
- eb_add_object(eb, obj);
- }
+ ret = eb_lookup_objects(eb, exec, args->buffer_count, file, &objects);
+ if (ret)
+ goto err;
/* take note of the batch buffer before we might reorder the lists */
batch_obj = list_entry(objects.prev,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/4] drm/i915: Move the execbuffer objects list from the stack into the tracker
From: Chris Wilson @ 2012-11-10 15:15 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1352560547-1423-1-git-send-email-chris@chris-wilson.co.uk>
Instead of passing around the eb-objects hashtable and a separate object
list, we can include the object list into the eb-objects structure for
convenience.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 58 +++++++++++++---------------
1 file changed, 27 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index c491ab1..1738ebd 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -38,6 +38,7 @@
#define __EXEC_NEEDS_CHIPSET_FLUSH (1<<29)
struct eb_objects {
+ struct list_head objects;
int and;
struct hlist_head buckets[0];
};
@@ -57,6 +58,7 @@ eb_create(int size)
return eb;
eb->and = count - 1;
+ INIT_LIST_HEAD(&eb->objects);
return eb;
}
@@ -77,8 +79,7 @@ static int
eb_lookup_objects(struct eb_objects *eb,
struct drm_i915_gem_exec_object2 *exec,
int count,
- struct drm_file *file,
- struct list_head *objects)
+ struct drm_file *file)
{
int i;
@@ -102,7 +103,7 @@ eb_lookup_objects(struct eb_objects *eb,
}
drm_gem_object_reference(&obj->base);
- list_add_tail(&obj->exec_list, objects);
+ list_add_tail(&obj->exec_list, &eb->objects);
obj->exec_handle = exec[i].handle;
obj->exec_entry = &exec[i];
@@ -133,6 +134,15 @@ eb_get_object(struct eb_objects *eb, unsigned long handle)
static void
eb_destroy(struct eb_objects *eb)
{
+ while (!list_empty(&eb->objects)) {
+ struct drm_i915_gem_object *obj;
+
+ obj = list_first_entry(&eb->objects,
+ struct drm_i915_gem_object,
+ exec_list);
+ list_del_init(&obj->exec_list);
+ drm_gem_object_unreference(&obj->base);
+ }
kfree(eb);
}
@@ -377,8 +387,7 @@ i915_gem_execbuffer_relocate_object_slow(struct drm_i915_gem_object *obj,
static int
i915_gem_execbuffer_relocate(struct drm_device *dev,
- struct eb_objects *eb,
- struct list_head *objects)
+ struct eb_objects *eb)
{
struct drm_i915_gem_object *obj;
int ret = 0;
@@ -391,7 +400,7 @@ i915_gem_execbuffer_relocate(struct drm_device *dev,
* lockdep complains vehemently.
*/
pagefault_disable();
- list_for_each_entry(obj, objects, exec_list) {
+ list_for_each_entry(obj, &eb->objects, exec_list) {
ret = i915_gem_execbuffer_relocate_object(obj, eb);
if (ret)
break;
@@ -564,7 +573,6 @@ static int
i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
struct drm_file *file,
struct intel_ring_buffer *ring,
- struct list_head *objects,
struct eb_objects *eb,
struct drm_i915_gem_exec_object2 *exec,
int count)
@@ -575,8 +583,8 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
int i, total, ret;
/* We may process another execbuffer during the unlock... */
- while (!list_empty(objects)) {
- obj = list_first_entry(objects,
+ while (!list_empty(&eb->objects)) {
+ obj = list_first_entry(&eb->objects,
struct drm_i915_gem_object,
exec_list);
list_del_init(&obj->exec_list);
@@ -623,15 +631,15 @@ i915_gem_execbuffer_relocate_slow(struct drm_device *dev,
/* reacquire the objects */
eb_reset(eb);
- ret = eb_lookup_objects(eb, exec, count, file, objects);
+ ret = eb_lookup_objects(eb, exec, count, file);
if (ret)
goto err;
- ret = i915_gem_execbuffer_reserve(ring, file, objects);
+ ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects);
if (ret)
goto err;
- list_for_each_entry(obj, objects, exec_list) {
+ list_for_each_entry(obj, &eb->objects, exec_list) {
int offset = obj->exec_entry - exec;
ret = i915_gem_execbuffer_relocate_object_slow(obj, eb,
reloc + reloc_offset[offset]);
@@ -834,7 +842,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_i915_gem_exec_object2 *exec)
{
drm_i915_private_t *dev_priv = dev->dev_private;
- struct list_head objects;
struct eb_objects *eb;
struct drm_i915_gem_object *batch_obj;
struct drm_clip_rect *cliprects = NULL;
@@ -976,28 +983,26 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
}
/* Look up object handles */
- INIT_LIST_HEAD(&objects);
- ret = eb_lookup_objects(eb, exec, args->buffer_count, file, &objects);
+ ret = eb_lookup_objects(eb, exec, args->buffer_count, file);
if (ret)
goto err;
/* take note of the batch buffer before we might reorder the lists */
- batch_obj = list_entry(objects.prev,
+ batch_obj = list_entry(eb->objects.prev,
struct drm_i915_gem_object,
exec_list);
/* Move the objects en-masse into the GTT, evicting if necessary. */
- ret = i915_gem_execbuffer_reserve(ring, file, &objects);
+ ret = i915_gem_execbuffer_reserve(ring, file, &eb->objects);
if (ret)
goto err;
/* The objects are in their final locations, apply the relocations. */
- ret = i915_gem_execbuffer_relocate(dev, eb, &objects);
+ ret = i915_gem_execbuffer_relocate(dev, eb);
if (ret) {
if (ret == -EFAULT) {
ret = i915_gem_execbuffer_relocate_slow(dev, file, ring,
- &objects, eb,
- exec,
+ eb, exec,
args->buffer_count);
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
}
@@ -1020,7 +1025,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (flags & I915_DISPATCH_SECURE && !batch_obj->has_global_gtt_mapping)
i915_gem_gtt_bind_object(batch_obj, batch_obj->cache_level);
- ret = i915_gem_execbuffer_move_to_gpu(ring, &objects);
+ ret = i915_gem_execbuffer_move_to_gpu(ring, &eb->objects);
if (ret)
goto err;
@@ -1090,20 +1095,11 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
goto err;
}
- i915_gem_execbuffer_move_to_active(&objects, ring, seqno);
+ i915_gem_execbuffer_move_to_active(&eb->objects, ring, seqno);
i915_gem_execbuffer_retire_commands(dev, file, ring);
err:
eb_destroy(eb);
- while (!list_empty(&objects)) {
- struct drm_i915_gem_object *obj;
-
- obj = list_first_entry(&objects,
- struct drm_i915_gem_object,
- exec_list);
- list_del_init(&obj->exec_list);
- drm_gem_object_unreference(&obj->base);
- }
mutex_unlock(&dev->struct_mutex);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 2/2] drm/i915: Update load-detect failure paths for modeset-rework
From: Daniel Vetter @ 2012-11-10 13:46 UTC (permalink / raw)
To: Chris Wilson; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <1352154308-12441-2-git-send-email-chris@chris-wilson.co.uk>
On Mon, Nov 05, 2012 at 10:25:08PM +0000, Chris Wilson wrote:
> After the rework, intel_set_mode() became a little better behaved in
> restoring the current mode if we failed to apply the requested modeline.
> However, the failure path for load-detect would clobber the existing
> state, leading to an oops during BIOS takeover on older machines.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Both patches applied to dinq.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] drm/i915: Missed lock change with rps lock
From: Daniel Vetter @ 2012-11-10 13:41 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
In-Reply-To: <1352212596-824-1-git-send-email-ben@bwidawsk.net>
On Tue, Nov 06, 2012 at 02:36:36PM +0000, Ben Widawsky wrote:
> Fixes a WARN_ON in igt/tests/debugfs_reader
>
> CC: Jesse Barnes <jbarnes@virtuousgeek.org>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Queued for -next, thanks for the patch (I've accidentaly replied to the
wrong patch, hence the two replies for the sparse fixup patch).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer
From: Daniel Vetter @ 2012-11-10 13:39 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <1350905535-4957-1-git-send-email-chris@chris-wilson.co.uk>
On Mon, Oct 22, 2012 at 12:32:15PM +0100, Chris Wilson wrote:
> The specs for gen2 say that the watermark values "should always be set
> assuming a 32bpp display mode, even though the display mode may be 15 or
> 16 bpp."
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH] Revert "drm/i915: enable rc6 on ilk again"
From: Chris Wilson @ 2012-11-10 10:00 UTC (permalink / raw)
To: intel-gfx
Even with the cumulative set of ilk w/a, rc6 is demonstrably still
failing and causing GPU hangs as found by Peter Wu. So we need to disable
it again until it is stable.
This reverts
commit 456470eb583f063ee84c6818251e638598be0fb8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Aug 8 23:35:40 2012 +0200
drm/i915: enable rc6 on ilk again
and the follow-on
commit cd7988eea561a70a4f98e431c1395f913672d626
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 26 20:33:18 2012 +0200
drm/i915: disable rc6 on ilk when vt-d is enabled
Reported-by: Peter Wu <lekensteyn@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4018ef4..2bda628 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2381,15 +2381,9 @@ int intel_enable_rc6(const struct drm_device *dev)
if (i915_enable_rc6 >= 0)
return i915_enable_rc6;
- if (INTEL_INFO(dev)->gen == 5) {
-#ifdef CONFIG_INTEL_IOMMU
- /* Disable rc6 on ilk if VT-d is on. */
- if (intel_iommu_gfx_mapped)
- return false;
-#endif
- DRM_DEBUG_DRIVER("Ironlake: only RC6 available\n");
- return INTEL_RC6_ENABLE;
- }
+ /* Disable RC6 on Ironlake */
+ if (INTEL_INFO(dev)->gen == 5)
+ return 0;
if (IS_HASWELL(dev)) {
DRM_DEBUG_DRIVER("Haswell: only RC6 available\n");
--
1.7.10.4
^ permalink raw reply related
* [PATCH] Revert "drm/i915: enable rc6 on ilk again"
From: Chris Wilson @ 2012-11-10 9:59 UTC (permalink / raw)
To: intel-gfx
Even with the cumulative set of ilk w/a, rc6 is demonstrably still
failing and causing GPU hangs as found by Peter Wu. So we need to disable
it again until it is stable.
This reverts
commit 456470eb583f063ee84c6818251e638598be0fb8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Aug 8 23:35:40 2012 +0200
drm/i915: enable rc6 on ilk again
and the follow-on
commit cd7988eea561a70a4f98e431c1395f913672d626
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 26 20:33:18 2012 +0200
drm/i915: disable rc6 on ilk when vt-d is enabled
Reported-by: Peter Wu <lekensteyn@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4018ef4..2bda628 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2381,15 +2381,9 @@ int intel_enable_rc6(const struct drm_device *dev)
if (i915_enable_rc6 >= 0)
return i915_enable_rc6;
- if (INTEL_INFO(dev)->gen == 5) {
-#ifdef CONFIG_INTEL_IOMMU
- /* Disable rc6 on ilk if VT-d is on. */
- if (intel_iommu_gfx_mapped)
- return false;
-#endif
- DRM_DEBUG_DRIVER("Ironlake: only RC6 available\n");
- return INTEL_RC6_ENABLE;
- }
+ /* Disable RC6 on Ironlake */
+ if (INTEL_INFO(dev)->gen == 5)
+ return 0;
if (IS_HASWELL(dev)) {
DRM_DEBUG_DRIVER("Haswell: only RC6 available\n");
--
1.7.10.4
^ permalink raw reply related
* [PATCH] Revert "drm/i915: enable rc6 on ilk again"
From: Chris Wilson @ 2012-11-10 8:25 UTC (permalink / raw)
To: intel-gfx
Even with the cumulative set of ilk w/a, rc6 is demonstrably still
failing and causing GPU hangs as found by Peter Wu. So we need to disable
it again until it is stable.
This reverts
commit 456470eb583f063ee84c6818251e638598be0fb8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Aug 8 23:35:40 2012 +0200
drm/i915: enable rc6 on ilk again
and the follow-on
commit cd7988eea561a70a4f98e431c1395f913672d626
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 26 20:33:18 2012 +0200
drm/i915: disable rc6 on ilk when vt-d is enabled
Reported-by: Peter Wu <lekensteyn@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=55984
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4018ef4..2bda628 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2381,15 +2381,9 @@ int intel_enable_rc6(const struct drm_device *dev)
if (i915_enable_rc6 >= 0)
return i915_enable_rc6;
- if (INTEL_INFO(dev)->gen == 5) {
-#ifdef CONFIG_INTEL_IOMMU
- /* Disable rc6 on ilk if VT-d is on. */
- if (intel_iommu_gfx_mapped)
- return false;
-#endif
- DRM_DEBUG_DRIVER("Ironlake: only RC6 available\n");
- return INTEL_RC6_ENABLE;
- }
+ /* Disable RC6 on Ironlake */
+ if (INTEL_INFO(dev)->gen == 5)
+ return 0;
if (IS_HASWELL(dev)) {
DRM_DEBUG_DRIVER("Haswell: only RC6 available\n");
--
1.7.10.4
^ permalink raw reply related
* [PATCH] intel: Fix missing ETIME on BSD operating systems
From: Richard Yao @ 2012-11-10 5:24 UTC (permalink / raw)
To: intel-gfx; +Cc: gentoo-bsd, David Shao
From: David Shao <davshao@gmail.com>
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
---
intel/intel_bufmgr_gem.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 8d45839..512bc6f 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -54,6 +54,9 @@
#include <stdbool.h>
#include "errno.h"
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
#include "libdrm_lists.h"
#include "intel_bufmgr.h"
#include "intel_bufmgr_priv.h"
--
1.7.8.6
^ permalink raw reply related
* [PATCH] intel: Fix missing ETIME on BSD operating systems
From: Richard Yao @ 2012-11-10 5:23 UTC (permalink / raw)
To: intel-gfx; +Cc: gentoo-bsd, David Shao
From: David Shao <davshao@gmail.com>
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
---
intel/intel_bufmgr_gem.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 8d45839..512bc6f 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -54,6 +54,9 @@
#include <stdbool.h>
#include "errno.h"
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
#include "libdrm_lists.h"
#include "intel_bufmgr.h"
#include "intel_bufmgr_priv.h"
--
1.7.8.6
^ permalink raw reply related
* [PATCH] intel: Fix missing ETIME on BSD operating systems
From: Richard Yao @ 2012-11-10 5:06 UTC (permalink / raw)
To: intel-gfx; +Cc: gentoo-bsd, David Shao
From: David Shao <davshao@gmail.com>
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
---
intel/intel_bufmgr_gem.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 8d45839..512bc6f 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -54,6 +54,9 @@
#include <stdbool.h>
#include "errno.h"
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
#include "libdrm_lists.h"
#include "intel_bufmgr.h"
#include "intel_bufmgr_priv.h"
--
1.7.8.6
^ permalink raw reply related
* [PATCH] intel: Fix missing ETIME on BSD operating systems
From: Richard Yao @ 2012-11-09 22:06 UTC (permalink / raw)
To: intel-gfx; +Cc: gentoo-bsd, David Shao
From: David Shao <davshao@gmail.com>
Originally posted to Free Desktop bug #52549 by David Shao.
Resolves Gentoo Bug #433403.
Commit message by Richard Yao.
Reviewed-by: Richard Yao <ryao@gentoo.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
---
intel/intel_bufmgr_gem.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 8d45839..512bc6f 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -54,6 +54,9 @@
#include <stdbool.h>
#include "errno.h"
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
#include "libdrm_lists.h"
#include "intel_bufmgr.h"
#include "intel_bufmgr_priv.h"
--
1.7.8.6
^ permalink raw reply related
* Re: [PATCH] drm/i915: Fix sparse warnings in from AGP kill code
From: Daniel Vetter @ 2012-11-09 20:27 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
In-Reply-To: <1352195416-855-1-git-send-email-ben@bwidawsk.net>
On Tue, Nov 06, 2012 at 09:50:16AM +0000, Ben Widawsky wrote:
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] drm/i915: Fix sparse warnings in from AGP kill code
From: Daniel Vetter @ 2012-11-09 20:27 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
In-Reply-To: <1352195416-855-1-git-send-email-ben@bwidawsk.net>
On Tue, Nov 06, 2012 at 09:50:16AM +0000, Ben Widawsky wrote:
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH 1/5 v5] drm/i915: Stop using AGP layer for GEN6+
From: Chris Wilson @ 2012-11-09 18:35 UTC (permalink / raw)
Cc: Daniel Vetter, Ben Widawsky, intel-gfx
In-Reply-To: <1352049691-2810-1-git-send-email-ben@bwidawsk.net>
On Sun, 4 Nov 2012 09:21:27 -0800, Ben Widawsky <ben@bwidawsk.net> wrote:
> void i915_gem_gtt_bind_object(struct drm_i915_gem_object *obj,
> enum i915_cache_level cache_level)
> {
> struct drm_device *dev = obj->base.dev;
> - unsigned int agp_type = cache_level_to_agp_type(dev, cache_level);
> + if (INTEL_INFO(dev)->gen < 6) {
> + unsigned int flags = (cache_level == I915_CACHE_LLC) ?
> + AGP_USER_CACHED_MEMORY : AGP_USER_MEMORY;
And we still failed to get this right. :(
cache_level == I915_CACHE_NONE ? AGP_USER_MEMORY : AGP_USER_CACHED_MEMORY;
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH] drm/i915: Guard pages being reaped by OOM whilst binding-to-GTT
From: Chris Wilson @ 2012-11-09 8:58 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20121108134909.345d14e3@bwidawsk.net>
In the circumstances that the shrinker is allowed to steal the mutex
in order to reap pages, we need to be careful to prevent it operating on
the current object and shooting ourselves in the foot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_gem.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 159dca5..f225583 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3091,6 +3091,8 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
if (ret)
return ret;
+ i915_gem_object_pin_pages(obj);
+
search_free:
if (map_and_fenceable)
free_space =
@@ -3121,14 +3123,17 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
obj->cache_level,
map_and_fenceable,
nonblocking);
- if (ret)
+ if (ret) {
+ i915_gem_object_unpin_pages(obj);
return ret;
+ }
goto search_free;
}
if (WARN_ON(!i915_gem_valid_gtt_space(dev,
obj->gtt_space,
obj->cache_level))) {
+ i915_gem_object_unpin_pages(obj);
drm_mm_put_block(obj->gtt_space);
obj->gtt_space = NULL;
return -EINVAL;
@@ -3137,6 +3142,7 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
ret = i915_gem_gtt_prepare_object(obj);
if (ret) {
+ i915_gem_object_unpin_pages(obj);
drm_mm_put_block(obj->gtt_space);
obj->gtt_space = NULL;
return ret;
@@ -3159,6 +3165,7 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object *obj,
obj->map_and_fenceable = mappable && fenceable;
+ i915_gem_object_unpin_pages(obj);
trace_i915_gem_object_bind(obj, map_and_fenceable);
i915_gem_verify_gtt(dev);
return 0;
--
1.7.10.4
^ permalink raw reply related
* Re: REg: Doubt in drm kernel driver
From: Xiang, Haihao @ 2012-11-09 8:58 UTC (permalink / raw)
To: Duraisamy, Srinath; +Cc: 'intel-gfx@lists.freedesktop.org'
In-Reply-To: <EF89443C002B9B4287015412D63AC90B24371DA9@BGSMSX102.gar.corp.intel.com>
No, you don't need to modify the drm kernel for the decoded output data.
You can directly map the corresponding buffer (GEM buffer) after
executing the batchbuffer.
BTW The decoded frame is specified in MFX_PIPE_BUF_ADDR_STATE too.
Thanks
Haihao
> Hi all,
>
>
>
> Anybody has any suggestions or any information for my doubts below,
> it will be really helpful.
>
>
>
> Thanks and regards
>
> Srinath.D
>
>
>
> From: Duraisamy, Srinath
> Sent: Wednesday, November 07, 2012 8:41 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: REg: Doubt in drm kernel driver
>
>
>
>
> Hi all,
>
>
>
> I am working on a project related to MFX part of Gen7 GPU. I am
> working on dumping the input commands and data being passed to MFX
> pipeline while decoding.
>
> And to dump the decoded output data from the MFX pipeline. I am using
> mplayer to decode the h264 file with vaapi support to use the MFX
> pipeline.
>
>
>
> I have modified the intel_driver code - gen7_mfd.c file, and I am able
> to dump the input commands and data being sent to the MFX into a file.
>
> Now I need to dump the decoded output of the MFX pipeline. I am not
> able to find it in user space intel-driver and drm driver code.
>
> I believe we need to modify the drm kernel driver code for dumping the
> decoded output data.
>
>
>
> It will be really helpful if anyone can provide me information on
> where to modify the drm kernel driver code to dump the following data
>
>
>
> 1. The output of the current decoded frame.
>
> 2. The output of the decoded motion vectors of the current frame.
> The decoded motion vector will be stored in address passed in
> “MFX_AVC_DIRECTMODE_STATE” command.
>
> 3. The motion vector information for the reference frame needed
> for decoding the current frame. This information will be in the
> address passed in “MFX_AVC_REF_IDX_STATE” command.
>
> 4. The decoder reference picture data used for motion
> compensation. These data can be read from the
> “MFX_PIPE_BUF_ADDR_STATE“ command.
>
>
>
> Please let me know if you have any questions.
>
>
>
> Thanks in advance.
>
> Srinath
>
>
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: REg: Doubt in drm kernel driver
From: Duraisamy, Srinath @ 2012-11-09 5:34 UTC (permalink / raw)
To: 'intel-gfx@lists.freedesktop.org'
In-Reply-To: <EF89443C002B9B4287015412D63AC90B24371963@BGSMSX102.gar.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1764 bytes --]
Hi all,
Anybody has any suggestions or any information for my doubts below, it will be really helpful.
Thanks and regards
Srinath.D
From: Duraisamy, Srinath
Sent: Wednesday, November 07, 2012 8:41 PM
To: intel-gfx@lists.freedesktop.org
Subject: REg: Doubt in drm kernel driver
Hi all,
I am working on a project related to MFX part of Gen7 GPU. I am working on dumping the input commands and data being passed to MFX pipeline while decoding.
And to dump the decoded output data from the MFX pipeline. I am using mplayer to decode the h264 file with vaapi support to use the MFX pipeline.
I have modified the intel_driver code - gen7_mfd.c file, and I am able to dump the input commands and data being sent to the MFX into a file.
Now I need to dump the decoded output of the MFX pipeline. I am not able to find it in user space intel-driver and drm driver code.
I believe we need to modify the drm kernel driver code for dumping the decoded output data.
It will be really helpful if anyone can provide me information on where to modify the drm kernel driver code to dump the following data
1. The output of the current decoded frame.
2. The output of the decoded motion vectors of the current frame. The decoded motion vector will be stored in address passed in "MFX_AVC_DIRECTMODE_STATE" command.
3. The motion vector information for the reference frame needed for decoding the current frame. This information will be in the address passed in "MFX_AVC_REF_IDX_STATE" command.
4. The decoder reference picture data used for motion compensation. These data can be read from the "MFX_PIPE_BUF_ADDR_STATE " command.
Please let me know if you have any questions.
Thanks in advance.
Srinath
[-- Attachment #1.2: Type: text/html, Size: 7730 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] drm/i915: Borrow our struct_mutex for the direct reclaim
From: Ben Widawsky @ 2012-11-08 13:49 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <1349881739-32277-1-git-send-email-chris@chris-wilson.co.uk>
On Wed, 10 Oct 2012 16:08:59 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:
> If we have hit oom whilst holding our struct_mutex, then currently we
> cannot reap our own GPU buffers which likely pin most of memory, making
> an outright OOM more likely. So if we are running in direct reclaim and
> already hold the mutex, attempt to free buffers knowing that the
> original function can not continue until we return.
>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
I will try to review this a bit further on the plane ride home. It's
quite a scary patch, but it fixes OOM destroying IGT runs, so it's
pretty necessary IMO.
Meanwhile:
Tested-by: Ben Widawsky <ben@bwidawsk.net>
> ---
> drivers/gpu/drm/i915/i915_gem.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1d0cbfb..bed4084 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4589,6 +4589,18 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file)
> spin_unlock(&file_priv->mm.lock);
> }
>
> +static bool mutex_is_locked_by(struct mutex *mutex, struct task_struct *task)
> +{
> + if (!mutex_is_locked(mutex))
> + return false;
> +
> +#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_SMP)
> + return mutex->owner == task;
> +#else
> + return false;
> +#endif
> +}
> +
> static int
> i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc)
> {
> @@ -4599,10 +4611,15 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc)
> struct drm_device *dev = dev_priv->dev;
> struct drm_i915_gem_object *obj;
> int nr_to_scan = sc->nr_to_scan;
> + bool unlock = true;
> int cnt;
>
> - if (!mutex_trylock(&dev->struct_mutex))
> - return 0;
> + if (!mutex_trylock(&dev->struct_mutex)) {
> + if (mutex_is_locked_by(&dev->struct_mutex, current))
> + unlock = false;
> + else
> + return 0;
> + }
>
> if (nr_to_scan) {
> nr_to_scan -= i915_gem_purge(dev_priv, nr_to_scan);
> @@ -4618,6 +4635,7 @@ i915_gem_inactive_shrink(struct shrinker *shrinker, struct shrink_control *sc)
> if (obj->pin_count == 0 && obj->pages_pin_count == 0)
> cnt += obj->base.size >> PAGE_SHIFT;
>
> - mutex_unlock(&dev->struct_mutex);
> + if (unlock)
> + mutex_unlock(&dev->struct_mutex);
> return cnt;
> }
--
Ben Widawsky, Intel Open Source Technology Center
^ permalink raw reply
* About HD3000(sandybridge) driver on vxWorks
From: for1984 @ 2012-11-08 7:18 UTC (permalink / raw)
To: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 1003 bytes --]
Dear Sir:
My name is wenjie zhou.I come from Wuhan China. Now I am writing HD3000(sandybridge) driver on vxWorks.But,there are some problems confusing me for a long time.Please help me!Thank you!
My problme is:When I use the blitter engine to realize filling the color to the rectangle,CP will stop in the first instruction(BR00).In the progrm,there are six instuction:br00,br13,br14,br09,br16 and MI_NOP.After allowing the CP to excute ,the Mode Register's bit9(Rings Idle) is set to 0.It means parser is not idle or ring arbiter is not idle.And the Error Status Register (ESR)'s bit0 will be set to 1. It means instruction error.The RING_BUFFER_HEADER register's value is 0x4.So I think the problem happened when the CP excuted the br00 instruction. When the CP excutes flush command, it works very well. I wonder why it happens? Is it relate with cache?PS:this ringbuffer program works very well on the ironlake platform.
Thank you!
Sincerely yours,
Wenjie Zhou
[-- Attachment #1.2: Type: text/html, Size: 1381 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: S3 causing IRQ delivery mismatch - i915 hotplug storm
From: Ben Guthro @ 2012-11-07 21:15 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <CAOvdn6UV_6uyuFsLCMsRTZEL-uummiHvKhzo=8zTY_xMxoXuUA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1488 bytes --]
On Wed, Nov 7, 2012 at 2:43 PM, Ben Guthro <ben@guthro.net> wrote:
>>
>>
>> There seems to be a mismatch for these IRQ delivery - or at least exhibits the behavior similar to such a problem.
>>
>
> I was mistaken here. The i8042 IRQ would just start up the IRQ handling - but the i915 driver always thinks it has pending work, and schedules it.
> It seems that the hotplug mask is not getting cleared in pch_iir (in i915_irq.c)
>
> Manually clearing this bit with
> pch_iir = pch_iir ^ hotplug_mask;
> in the ironlake_irq_handler() function
>
> seems to resolve the issue - making it so I don't get the flurry of hotplug work bogging down the system.
> ...but is this disabling hotplug detection entirely?
>
>
The attached patch seems to resolve the issue of the interrupt storm
after S3 for this Ibex Peak PCH system.
Could someone comment on whether this will have any unintended side effects?
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 32e1bda..d8f2f79 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -802,8 +802,13 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
/* check event from PCH */
if (de_iir & DE_PCH_EVENT) {
- if (pch_iir & hotplug_mask)
+ if (pch_iir & hotplug_mask) {
queue_work(dev_priv->wq, &dev_priv->hotplug_work);
+
+ if (!HAS_PCH_CPT(dev))
+ pch_iir = pch_iir ^ SDE_HOTPLUG_MASK;
+ }
+
if (HAS_PCH_CPT(dev))
cpt_irq_handler(dev, pch_iir);
else
[-- Attachment #2: hotplug.patch --]
[-- Type: application/octet-stream, Size: 588 bytes --]
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 32e1bda..d8f2f79 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -802,8 +802,13 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
/* check event from PCH */
if (de_iir & DE_PCH_EVENT) {
- if (pch_iir & hotplug_mask)
+ if (pch_iir & hotplug_mask) {
queue_work(dev_priv->wq, &dev_priv->hotplug_work);
+
+ if (!HAS_PCH_CPT(dev))
+ pch_iir = pch_iir ^ SDE_HOTPLUG_MASK;
+ }
+
if (HAS_PCH_CPT(dev))
cpt_irq_handler(dev, pch_iir);
else
[-- Attachment #3: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox