Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, 29 Oct 2012 23:16:24 +0100 Antonio Ospite wrote: > Hi, > > I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), > my video adapter is the one integrated on the MSI M3N78-VM motherboard > (hence x86_64): > [...] > [ 1943.858601] BUG: unable to handle kernel paging request at fff8 > [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 [nouveau] > [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 > [ 1943.858803] Oops: [#1] SMP [..] > [ 1943.860018] Call Trace: > [ 1943.860019] [] ? kmem_cache_alloc_trace+0xbf/0xcf > [ 1943.860019] [] ? should_resched+0x5/0x23 > [ 1943.860019] [] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau] Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits a7dbf00 and 5cad16a which seem to be related to the problem I was having; would you mind elaborating a bit about what you think was causing the crash on my side? Maybe the chipset used on this motherboard doesn't support some feature? And how did you figured out from the logs? Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite wrote: > On Mon, 29 Oct 2012 23:16:24 +0100 > Antonio Ospite wrote: > >> Hi, >> >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), >> my video adapter is the one integrated on the MSI M3N78-VM motherboard >> (hence x86_64): >> > [...] >> [ 1943.858601] BUG: unable to handle kernel paging request at >> fff8 >> [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 [nouveau] >> [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 >> [ 1943.858803] Oops: [#1] SMP > [..] >> [ 1943.860018] Call Trace: >> [ 1943.860019] [] ? kmem_cache_alloc_trace+0xbf/0xcf >> [ 1943.860019] [] ? should_resched+0x5/0x23 >> [ 1943.860019] [] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau] > > Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits > a7dbf00 and 5cad16a which seem to be related to the problem I was > having; would you mind elaborating a bit about what you think was > causing the crash on my side? Maybe the chipset used on this motherboard > doesn't support some feature? And how did you figured out from the logs? > 5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix The chipset hasn't got Z compression support, and the oops once decoded pointed out the new code was trying to allocate Z tags from a NULL memory block. The old code use to allocate an empty memory block instead of NULL, and it got lost in the rewrite, Ben just fixed it to allow empty memory blocks again. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 8/8] drm_modes: add of_videomode helpers
On Wed, Oct 31, 2012 at 10:28:08AM +0100, Steffen Trumtrar wrote: [...] > +/** > + * of_get_drm_display_mode - get a drm_display_mode from devicetree > + * @np: device_node with the timing specification > + * @dmode: will be set to the return value > + * @index: index into the list of display timings in devicetree > + * > + * DESCRIPTION: I don't think this is necessary. > + * This function is expensive and should only be used, if only one mode is > to be > + * read from DT. To get multiple modes start with of_get_display_timing_list > ond You probably meant "and" at the end of this line. Also I'm not even sure that we should be exposing this function, but rather provide a helper which automatically adds the parsed modes to a DRM connector object. Thierry pgpsKUVl5QVMg.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops
A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and down. In-Reply-To: ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: Make hashtab rcu-safe
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned
long key)
hashed_key = hash_long(key, ht->order);
DRM_DEBUG("Key is 0x%08lx, Hashed key is 0x%08x\n", key, hashed_key);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG("count %d, key: 0x%08lx\n", count++, entry->key);
- }
}
static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct
drm_open_hash *ht,
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return list;
if (entry->key > key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
parent = NULL;
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return -EINVAL;
if (entry->key > key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
parent = list;
}
if (parent) {
- hlist_add_after(parent, &item->head);
+ hlist_add_after_rcu(parent, &item->head);
} else {
- hlist_add_head(&item->head, h_list);
+ hlist_add_head_rcu(&item->head, h_list);
}
return 0;
}
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
list = drm_ht_find_key(ht, key);
if (list) {
- hlist_del_init(list);
+ hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
{
- hlist_del_init(&item->head);
+ hlist_del_init_rcu(&item->head);
return 0;
}
EXPORT_SYMBOL(drm_ht_remove_item);
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] kref: Implement kref_get_unless_zero
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.
Signed-off-by: Thomas Hellstrom
---
include/linux/kref.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..fd16042 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
}
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+ return !atomic_add_unless(&kref->refcount, 1, 0);
+}
#endif /* _KREF_H_ */
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm/ttm_object.h |4
include/linux/kref.h |2 +-
4 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
*/
struct ttm_object_device {
- rwlock_t object_lock;
+ spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
kref_init(&base->refcount);
ret = drm_ht_just_insert_please(&tdev->object_hash,
&base->hash,
(unsigned long)base, 31, 0, 0);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (unlikely(ret != 0))
goto out_err0;
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;
+ spin_lock(&tdev->object_lock);
(void)drm_ht_remove_item(&tdev->object_hash, &base->hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (base->refcount_release) {
ttm_object_file_unref(&base->tfile);
base->refcount_release(&base);
}
- write_lock(&tdev->object_lock);
}
void ttm_base_object_unref(struct ttm_base_object **p_base)
{
struct ttm_base_object *base = *p_base;
- struct ttm_object_device *tdev = base->tfile->tdev;
*p_base = NULL;
- /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
- write_lock(&tdev->object_lock);
kref_put(&base->refcount, ttm_release_base);
- write_unlock(&tdev->object_lock);
}
EXPORT_SYMBOL(ttm_base_object_unref);
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
- read_lock(&tdev->object_lock);
+ rcu_read_lock();
ret = drm_ht_find_item(&tdev->object_hash, key, &hash);
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
- kref_get(&base->refcount);
+ ret = kref_get_unless_zero(&base->refcount);
}
- read_unlock(&tdev->object_lock);
+ rcu_read_unlock();
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct
ttm_mem_global
return NULL;
tdev->mem_glob = mem_glob;
- rwlock_init(&tdev->object_lock);
+ spin_lock_init(&tdev->object_lock);
atomic_set(&tdev->object_count, 0);
ret = drm_ht_create(&tdev->object_hash, hash_order);
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device
**p_tdev)
*p_tdev = NULL;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
drm_ht_remove(&tdev->object_hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
kfree(tdev);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;
- kfree(ctx);
+ ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
}
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
- kfree(user_srf);
+ ttm_base_object_kfree(user_srf, base);
[PATCH 4/4] drm/ttm: Optimize reservation slightly
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo->glob;
int ret;
- while (unlikely(atomic_cmpxchg(&bo->reserved, 0, 1) != 0)) {
+ while (unlikely(atomic_read(&bo->reserved) != 0)) {
/**
* Deadlock avoidance for multi-bo reserving.
*/
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}
+ atomic_set(&bo->reserved, 1);
if (use_sequence) {
/**
* Wake up waiters that may need to recheck for deadlock,
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups
On 11/05/2012 02:31 PM, Thomas Hellstrom wrote:
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm/ttm_object.h |4
include/linux/kref.h |2 +-
4 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
*/
struct ttm_object_device {
- rwlock_t object_lock;
+ spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
kref_init(&base->refcount);
ret = drm_ht_just_insert_please(&tdev->object_hash,
&base->hash,
(unsigned long)base, 31, 0, 0);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (unlikely(ret != 0))
goto out_err0;
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;
+ spin_lock(&tdev->object_lock);
(void)drm_ht_remove_item(&tdev->object_hash, &base->hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (base->refcount_release) {
ttm_object_file_unref(&base->tfile);
base->refcount_release(&base);
}
- write_lock(&tdev->object_lock);
}
void ttm_base_object_unref(struct ttm_base_object **p_base)
{
struct ttm_base_object *base = *p_base;
- struct ttm_object_device *tdev = base->tfile->tdev;
*p_base = NULL;
- /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
- write_lock(&tdev->object_lock);
kref_put(&base->refcount, ttm_release_base);
- write_unlock(&tdev->object_lock);
}
EXPORT_SYMBOL(ttm_base_object_unref);
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
- read_lock(&tdev->object_lock);
+ rcu_read_lock();
ret = drm_ht_find_item(&tdev->object_hash, key, &hash);
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
- kref_get(&base->refcount);
+ ret = kref_get_unless_zero(&base->refcount);
}
- read_unlock(&tdev->object_lock);
+ rcu_read_unlock();
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct
ttm_mem_global
return NULL;
tdev->mem_glob = mem_glob;
- rwlock_init(&tdev->object_lock);
+ spin_lock_init(&tdev->object_lock);
atomic_set(&tdev->object_count, 0);
ret = drm_ht_create(&tdev->object_hash, hash_order);
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device **p_tdev)
*p_tdev = NULL;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
drm_ht_remove(&tdev->object_hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
kfree(tdev);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;
- kfree(ctx);
+ ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
}
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
- kfree(user_srf);
+ ttm_base_objec
[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops v2
A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and down. v2: Formatting fixes. In-Reply-To: >From Thomas Hellstrom # This line is ignored. From: Thomas Hellstrom Subject: In-Reply-To: ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm: Make hashtab rcu-safe
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned
long key)
hashed_key = hash_long(key, ht->order);
DRM_DEBUG("Key is 0x%08lx, Hashed key is 0x%08x\n", key, hashed_key);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG("count %d, key: 0x%08lx\n", count++, entry->key);
- }
}
static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct
drm_open_hash *ht,
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return list;
if (entry->key > key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
parent = NULL;
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return -EINVAL;
if (entry->key > key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
parent = list;
}
if (parent) {
- hlist_add_after(parent, &item->head);
+ hlist_add_after_rcu(parent, &item->head);
} else {
- hlist_add_head(&item->head, h_list);
+ hlist_add_head_rcu(&item->head, h_list);
}
return 0;
}
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
list = drm_ht_find_key(ht, key);
if (list) {
- hlist_del_init(list);
+ hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
{
- hlist_del_init(&item->head);
+ hlist_del_init_rcu(&item->head);
return 0;
}
EXPORT_SYMBOL(drm_ht_remove_item);
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] kref: Implement kref_get_unless_zero v2
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.
v2: Formatting fixes.
Signed-off-by: Thomas Hellstrom
---
include/linux/kref.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..bae91d0 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
}
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+ *
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+ return !atomic_add_unless(&kref->refcount, 1, 0);
+}
#endif /* _KREF_H_ */
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v2
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
v2: Don't touch include/linux/kref.h
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm/ttm_object.h |4
3 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
*/
struct ttm_object_device {
- rwlock_t object_lock;
+ spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
kref_init(&base->refcount);
ret = drm_ht_just_insert_please(&tdev->object_hash,
&base->hash,
(unsigned long)base, 31, 0, 0);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (unlikely(ret != 0))
goto out_err0;
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;
+ spin_lock(&tdev->object_lock);
(void)drm_ht_remove_item(&tdev->object_hash, &base->hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (base->refcount_release) {
ttm_object_file_unref(&base->tfile);
base->refcount_release(&base);
}
- write_lock(&tdev->object_lock);
}
void ttm_base_object_unref(struct ttm_base_object **p_base)
{
struct ttm_base_object *base = *p_base;
- struct ttm_object_device *tdev = base->tfile->tdev;
*p_base = NULL;
- /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
- write_lock(&tdev->object_lock);
kref_put(&base->refcount, ttm_release_base);
- write_unlock(&tdev->object_lock);
}
EXPORT_SYMBOL(ttm_base_object_unref);
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
- read_lock(&tdev->object_lock);
+ rcu_read_lock();
ret = drm_ht_find_item(&tdev->object_hash, key, &hash);
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
- kref_get(&base->refcount);
+ ret = kref_get_unless_zero(&base->refcount);
}
- read_unlock(&tdev->object_lock);
+ rcu_read_unlock();
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct
ttm_mem_global
return NULL;
tdev->mem_glob = mem_glob;
- rwlock_init(&tdev->object_lock);
+ spin_lock_init(&tdev->object_lock);
atomic_set(&tdev->object_count, 0);
ret = drm_ht_create(&tdev->object_hash, hash_order);
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device
**p_tdev)
*p_tdev = NULL;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
drm_ht_remove(&tdev->object_hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
kfree(tdev);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;
- kfree(ctx);
+ ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
}
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
- kfree(user_srf);
+ ttm_base_object_kfree(user_srf, base);
ttm_mem_glob
[PATCH 4/4] drm/ttm: Optimize reservation slightly
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo->glob;
int ret;
- while (unlikely(atomic_cmpxchg(&bo->reserved, 0, 1) != 0)) {
+ while (unlikely(atomic_read(&bo->reserved) != 0)) {
/**
* Deadlock avoidance for multi-bo reserving.
*/
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}
+ atomic_set(&bo->reserved, 1);
if (use_sequence) {
/**
* Wake up waiters that may need to recheck for deadlock,
--
1.7.4.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly
Hey,
Op 05-11-12 14:31, Thomas Hellstrom schreef:
> Reservation locking currently always takes place under the LRU spinlock.
> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
> atomic_read followed by atomic_write since nobody else will ever reserve
> without the lru spinlock held.
> At least on Intel this should remove a locked bus cycle on successful
> reserve.
>
> Signed-off-by: Thomas Hellstrom
>
Is that really a good thing to submit when I am busy killing lru lock around
reserve? :-)
- while (unlikely(atomic_cmpxchg(&bo->reserved, 0, 1) != 0)) {
+ while (unlikely(atomic_xchg(&bo->reserved, 1) != 0)) {
Works without lru lock too!
In fact mutexes are done in a similar way[1], except with some more magic, and
unlocked state is 1, not 0.
However I do think that to get that right (saves a irq disable in unlock path,
and less wakeups in contended
case), I should really just post the mutex extension patches for reservations
and ride the flames. It's
getting too close to real mutexes so I really want it to be a mutex in that
case. So lets convert it.. Soon! :-)
~Maarten
[1] See linux/include/asm-generic/mutex-xchg.h and
linux/include/asm-generic/mutex-dec.h for how
archs generally implement mutex fastpaths.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #12 from Alex Deucher --- (In reply to comment #11) > Found what is wrong with the help of a few printk and by comparing to the > code being replaced. All the logic is good (going through crtc, disabling > them, waiting for vblank) BUT setting "tmp |= > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. > > If I do as in the previous code by setting tmp = 0 and then continuing with: > radeon_wait_for_vblank(rdev, i); > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); > everything works fine as before. > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? > From what I read with printk, it is far from a 0 or a 1. Is this normal? That's the most important bit in the entire sequence. It's a bit field in a register (bit 24 to be exact). That bit is the bit that actually disables the requests from the display controller in the memory controller. The whole point of this code is to disable all clients of the memory controller (mc_stop()) so that we can change the location of vram within the GPU's address space. Once we've moved vram, we can re-enable the clients (mc_resume()) so that they point to the new vram location. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
This patch is having dependency on linux-samsung-soc patchset named
"add dt based support for iommu for hdmi"
Signed-off-by: Rahul Sharma
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d1a1d71..ee110c9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
}
#ifdef CONFIG_OF
+
+static int drm_hdmi_dt_init_iommu(struct device *dev)
+{
+ struct platform_device *pds;
+ struct device_node *dn, *dns;
+ const __be32 *parp;
+
+ dn = dev->of_node;
+ parp = of_get_property(dn, "sysmmu", NULL);
+ if (parp == NULL) {
+ dev_err(dev, "failed to find sysmmu property\n");
+ return -EINVAL;
+ }
+ dns = of_find_node_by_phandle(be32_to_cpup(parp));
+ if (dns == NULL) {
+ dev_err(dev, "failed to find sysmmu node\n");
+ return -EINVAL;
+ }
+ pds = of_find_device_by_node(dns);
+ if (pds == NULL) {
+ dev_err(dev, "failed to find sysmmu platform device\n");
+ return -EINVAL;
+ }
+
+ platform_set_sysmmu(&pds->dev, dev);
+ return 0;
+}
+
static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
{
@@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
goto err_data;
}
+ if (drm_hdmi_dt_init_iommu(dev)){
+ DRM_ERROR("no sysmmu property found\n");
+ goto err_data;
+ }
+
pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
return pd;
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/ttm: Optimize reservation slightly
On 11/05/2012 03:01 PM, Maarten Lankhorst wrote: Hey, Op 05-11-12 14:31, Thomas Hellstrom schreef: Reservation locking currently always takes place under the LRU spinlock. Hence, strictly there is no need for an atomic_cmpxchg call; we can use atomic_read followed by atomic_write since nobody else will ever reserve without the lru spinlock held. At least on Intel this should remove a locked bus cycle on successful reserve. Signed-off-by: Thomas Hellstrom Is that really a good thing to submit when I am busy killing lru lock around reserve? :-) If your patch series makes it into the same kernel, let's kill this patch. Otherwise it may live at least for a kernel release. It's not a big thing to rebase against, and I won't complain if your patch adds another atomic read-modify-write op here. :) /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugzilla.kernel.org/show_bug.cgi?id=49981 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other@kernel- |drivers_video-dri@kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50
https://bugzilla.kernel.org/show_bug.cgi?id=16193 Alan changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk --- Comment #2 from Alan 2012-11-05 14:16:22 --- Closing as obsolete. If this is still seen on modern kernels (3.2+) please update/reopen -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50
https://bugzilla.kernel.org/show_bug.cgi?id=16193 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 16065] linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor.
https://bugzilla.kernel.org/show_bug.cgi?id=16065 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/1] drm: exynos: fix for mapping contigous dma buffers
2012. 11. 3. 오후 9:21 Rahul Sharma 작성:
> This patch fixes the problem of mapping contigous dma buffers. Currently page
> struct is calculated from the buf->dma_addr which is not the physical address.
> It is replaced by buf->pages which points to the page struct of the first page
> of contigous memory chunk. This gives the correct page frame number for
> mapping.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index c557ac7..50d73f1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -120,8 +120,12 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object
> *obj,
>}
>
>pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
> -} else
> -pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
> +} else {
> +if (!buf->pages)
> +return -EINTR;
> +
> +pfn = page_to_pfn(buf->pages[0]) + page_offset;
> +}
Is there any reason you are sending patches respectively? It's better to
combine them.
Thanks,
Inki Dae
>
>return vm_insert_mixed(vma, f_vaddr, pfn);
> }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17511] Display no longer works with KMS enabled
https://bugzilla.kernel.org/show_bug.cgi?id=17511 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INSUFFICIENT_DATA -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #13 from Alex Deucher --- Created attachment 69564 --> https://bugs.freedesktop.org/attachment.cgi?id=69564&action=edit possible fix Slightly adjusted wait for vblank function. Maybe this will help? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #14 from Alexandre Demers --- (In reply to comment #12) > (In reply to comment #11) > > Found what is wrong with the help of a few printk and by comparing to the > > code being replaced. All the logic is good (going through crtc, disabling > > them, waiting for vblank) BUT setting "tmp |= > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. > > > > If I do as in the previous code by setting tmp = 0 and then continuing with: > > radeon_wait_for_vblank(rdev, i); > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); > > everything works fine as before. > > > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? > > From what I read with printk, it is far from a 0 or a 1. Is this normal? > > That's the most important bit in the entire sequence. It's a bit field in a > register (bit 24 to be exact). That bit is the bit that actually disables > the requests from the display controller in the memory controller. The > whole point of this code is to disable all clients of the memory controller > (mc_stop()) so that we can change the location of vram within the GPU's > address space. Once we've moved vram, we can re-enable the clients > (mc_resume()) so that they point to the new vram location. Thank you, you confirmed what I had assumed. I had already understood that it was the most important part in the sequence since it is associated to a "write" instruction. I don't have the (decimal/binary) values with me right now, but I'll be able to give you what was read from the register and from the result returned from the bitwise OR assignment we are pushing in the register. I'll confirm which bit(s) are changing. I'm sure the assignment was setting one (or more) bit in the register to "1". Is bit 24 the only one expected to change in the register? Should it be put to "1" or "0"? Another question: why were we setting "0" in the register before? By doing so, we were setting the whole register to "0" (the whole 32 bits), right? If I remember correctly, from what I saw yesterday with the help of printk, it seems we are setting at least one bit to "1" in this register, which would be the opposite of what was being done before and therefore of what was working correctly with my video card. I'm just trying to understand why we were doing something in the first place that was working correctly and that was introduce to fix this problem in the first place, both at boot time for grub (set gfxpayload=keep) and when suspending/resuming, and we are now doing the opposite, thus breaking the code for some setups. Is it possible that the bit/register logic is not the same for all Radeon GPUs? After all, we already introduced a different path for DCE6. I'll also try your patch when I'll get home tonight. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
This patch is having dependency on linux-samsung-soc patchset posted at
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/13556
Signed-off-by: Rahul Sharma
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d1a1d71..a04452c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
}
#ifdef CONFIG_OF
+
+static int drm_hdmi_dt_init_iommu(struct device *dev)
+{
+ struct platform_device *pds;
+ struct device_node *dn, *dns;
+ const __be32 *parp;
+
+ dn = dev->of_node;
+ parp = of_get_property(dn, "sysmmu", NULL);
+ if (parp == NULL) {
+ dev_err(dev, "failed to find sysmmu property\n");
+ return -EINVAL;
+ }
+ dns = of_find_node_by_phandle(be32_to_cpup(parp));
+ if (dns == NULL) {
+ dev_err(dev, "failed to find sysmmu node\n");
+ return -EINVAL;
+ }
+ pds = of_find_device_by_node(dns);
+ if (pds == NULL) {
+ dev_err(dev, "failed to find sysmmu platform device\n");
+ return -EINVAL;
+ }
+
+ platform_set_sysmmu(&pds->dev, dev);
+ return 0;
+}
+
static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
{
@@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
goto err_data;
}
+ if (drm_hdmi_dt_init_iommu(dev)) {
+ DRM_ERROR("no sysmmu property found\n");
+ goto err_data;
+ }
+
pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
return pd;
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: exynos: fix for mapping of dma buffers
This patch fixes the problem of mapping contigous and non contigous dma buffers.
Currently page struct is calculated from the buf->dma_addr which is not the
physical address. It is replaced by buf->pages which points to the page struct
of the first page of contigous memory chunk. This gives the correct page frame
number for mapping.
Non-contigous dma buffers are described using SG table and SG lists. Each
valid SG List is pointing to a single page or group of pages which are
physically contigous. Current implementation just maps the first page of each
SG List and leave the other pages unmapped, leading to a crash. Given solution
finds the page struct for the faulting page through parsing SG table and map it.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8cb6824..50d73f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -95,15 +95,37 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object
*obj,
{
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
+ struct scatterlist *sgl;
unsigned long pfn;
+ int i;
if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
+ if (!buf->sgt)
+ return -EINTR;
+
+ sgl = buf->sgt->sgl;
+ for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
+ if (!sgl) {
+ DRM_ERROR("invalid SG table\n");
+ return -EINTR;
+ }
+ if (page_offset < (sgl->length >> PAGE_SHIFT))
+ break;
+ page_offset -= (sgl->length >> PAGE_SHIFT);
+ }
+
+ if (i >= buf->sgt->nents) {
+ DRM_ERROR("invalid page offset\n");
+ return -EINVAL;
+ }
+
+ pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
+ } else {
if (!buf->pages)
return -EINTR;
- pfn = page_to_pfn(buf->pages[page_offset++]);
- } else
- pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
+ pfn = page_to_pfn(buf->pages[0]) + page_offset;
+ }
return vm_insert_mixed(vma, f_vaddr, pfn);
}
--
1.7.0.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote:
> Alex Deucher wrote:
>>
>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote:
>>>
>>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890
>>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off
>>> and then turn TV on and -
>>>
>>> xrandr --output DVI-0 --auto
>>>
>>> to bring up the the TV and get a clone of monitor.
>>>
>>> This still works with drm-core-next but not with drm-fixes (todays or
>>> from a
>>> few days ago).
>>>
>>> With df I now loose the monitor with signal out of range when doing
>>> above,
>>> the TV output is OK. To get the monitor back I need to turn off TV, then
>>> off/auto the monitor.
>>>
>>> xrandr --output DVI-0 --off
>>> xrandr --output DVI-1 --off
>>> xrandr --output DVI-1 --auto
>>>
>>> The output from xrandr while the monitor is showing signal out of range
>>> looks normal.
>>>
>>> If I boot with the TV on it works OK.
>>
>>
>> Can you bisect?
>
>
> 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit
> commit 29dbe3bcd2e28e71823febdca989d63d5c27d152
> Author: Alex Deucher
> Date: Fri Oct 5 10:22:02 2012 -0400
>
> drm/radeon: allocate PPLLs from low to high
>
> The order shouldn't matter, but there have been problems
> reported on certain older asics. This behaves more
> like the original code before the PPLL allocation
> rework.
>
> Signed-off-by: Alex Deucher
> Cc: Markus Trippelsdorf
>
>
That's bizarre. That patch reverts the behavior back to the 3.6 and
earlier kernel behavior. I guess it's some issue with the ordering of
the modesetting programming sequence. I've attached a couple of
things to try.
The first patch is a simple fix. It just reverts back to the previous
pll allocation order for discrete cards like yours:
0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch
The second set of patches implements a more complex fix which may help
regardless of the order in which plls are allocated:
0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch
0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch
0003-drm-radeon-disable-the-pll-before-a-modeset.patch
Can you see if the second set helps? If not, please try the first patch.
Alex
From b6cd7967513fe86c0822db4b41745da2140914b7 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 5 Nov 2012 10:16:12 -0500
Subject: [PATCH] drm/radeon/dce3: switch back to old pll allocation order for
discrete
The order shouldn't matter, but this seems to cause regressions for
certain specific cases. This should fix it for now. We probably
need to investigate a proper fix in the next development cycle.
Signed-off-by: Alex Deucher
Cc: Andy Furniss
---
drivers/gpu/drm/radeon/atombios_crtc.c | 54 ++-
1 files changed, 31 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 2e566e1..3bce029 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1696,35 +1696,43 @@ static int radeon_atom_pick_pll(struct drm_crtc *crtc)
return ATOM_PPLL2;
DRM_ERROR("unable to allocate a PPLL\n");
return ATOM_PPLL_INVALID;
- } else {
- if (ASIC_IS_AVIVO(rdev)) {
- /* in DP mode, the DP ref clock can come from either PPLL
- * depending on the asic:
- * DCE3: PPLL1 or PPLL2
- */
- if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc->encoder))) {
-/* use the same PPLL for all DP monitors */
-pll = radeon_get_shared_dp_ppll(crtc);
-if (pll != ATOM_PPLL_INVALID)
- return pll;
- } else {
-/* use the same PPLL for all monitors with the same clock */
-pll = radeon_get_shared_nondp_ppll(crtc);
-if (pll != ATOM_PPLL_INVALID)
- return pll;
- }
- /* all other cases */
- pll_in_use = radeon_get_pll_use_mask(crtc);
+ } else if (ASIC_IS_AVIVO(rdev)) {
+ /* in DP mode, the DP ref clock can come from either PPLL
+ * depending on the asic:
+ * DCE3: PPLL1 or PPLL2
+ */
+ if (ENCODER_MODE_IS_DP(atombios_get_encoder_mode(radeon_crtc->encoder))) {
+ /* use the same PPLL for all DP monitors */
+ pll = radeon_get_shared_dp_ppll(crtc);
+ if (pll != ATOM_PPLL_INVALID)
+return pll;
+ } else {
+ /* use the same PPLL for all monitors with the same clock */
+ pll = radeon_get_shared_nondp_ppll(crtc);
+ if (pll != ATOM_PPLL_INVALID)
+return pll;
+ }
+ /* all other cases */
+ pll_in_use = radeon_get_pll_use_mask(crtc);
+ /* the order shouldn't matter here, but we probably
+ * need this until we have atomic modeset
+ */
+ if (rdev->flags & RADEON_IS_IGP) {
if (!(pll_in_use & (1 << ATOM_PPLL1)))
return ATOM_PPLL1;
if (!(pll_in_use & (1 << ATOM_PPLL2)))
return ATOM_PPLL2;
- DRM_ERROR("unable to allocate a PPLL\n");
- return ATOM_PPLL_INVALID;
} else {
- /* on pre-R5xx asics, the crtc to pll mapping is hardcoded */
- r
Re: nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, 5 Nov 2012 08:40:38 + Dave Airlie wrote: > On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite > wrote: > > On Mon, 29 Oct 2012 23:16:24 +0100 > > Antonio Ospite wrote: > > > >> Hi, > >> > >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), > >> my video adapter is the one integrated on the MSI M3N78-VM motherboard > >> (hence x86_64): > >> > > [...] > >> [ 1943.858601] BUG: unable to handle kernel paging request at > >> fff8 > >> [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 > >> [nouveau] > >> [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 > >> [ 1943.858803] Oops: [#1] SMP > > [..] > >> [ 1943.860018] Call Trace: > >> [ 1943.860019] [] ? kmem_cache_alloc_trace+0xbf/0xcf > >> [ 1943.860019] [] ? should_resched+0x5/0x23 > >> [ 1943.860019] [] ? nv50_fb_vram_new+0xc5/0x1f2 > >> [nouveau] > > > > Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits > > a7dbf00 and 5cad16a which seem to be related to the problem I was > > having; would you mind elaborating a bit about what you think was > > causing the crash on my side? Maybe the chipset used on this motherboard > > doesn't support some feature? And how did you figured out from the logs? > > > > 5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix > > The chipset hasn't got Z compression support, and the oops once decoded > pointed > out the new code was trying to allocate Z tags from a NULL memory block. The > old > code use to allocate an empty memory block instead of NULL, and it got > lost in the > rewrite, Ben just fixed it to allow empty memory blocks again. > > Dave. > Thanks a lot for the explanation. Regards, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #15 from Alex Deucher --- (In reply to comment #14) > (In reply to comment #12) > > (In reply to comment #11) > > > Found what is wrong with the help of a few printk and by comparing to the > > > code being replaced. All the logic is good (going through crtc, disabling > > > them, waiting for vblank) BUT setting "tmp |= > > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. > > > > > > If I do as in the previous code by setting tmp = 0 and then continuing > > > with: > > > radeon_wait_for_vblank(rdev, i); > > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); > > > everything works fine as before. > > > > > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? > > > From what I read with printk, it is far from a 0 or a 1. Is this normal? > > > > That's the most important bit in the entire sequence. It's a bit field in a > > register (bit 24 to be exact). That bit is the bit that actually disables > > the requests from the display controller in the memory controller. The > > whole point of this code is to disable all clients of the memory controller > > (mc_stop()) so that we can change the location of vram within the GPU's > > address space. Once we've moved vram, we can re-enable the clients > > (mc_resume()) so that they point to the new vram location. > > Thank you, you confirmed what I had assumed. I had already understood that > it was the most important part in the sequence since it is associated to a > "write" instruction. I don't have the (decimal/binary) values with me right > now, but I'll be able to give you what was read from the register and from > the result returned from the bitwise OR assignment we are pushing in the > register. I'll confirm which bit(s) are changing. I'm sure the assignment > was setting one (or more) bit in the register to "1". Is bit 24 the only one > expected to change in the register? Should it be put to "1" or "0"? > Setting bit 24 to 1 disables memory requests from the display controller. Setting bit 24 to 0, enables memory requests from the display controller. > Another question: why were we setting "0" in the register before? By doing > so, we were setting the whole register to "0" (the whole 32 bits), right? If > I remember correctly, from what I saw yesterday with the help of printk, it > seems we are setting at least one bit to "1" in this register, which would > be the opposite of what was being done before and therefore of what was > working correctly with my video card. I'm just trying to understand why we > were doing something in the first place that was working correctly and that > was introduce to fix this problem in the first place, both at boot time for > grub (set gfxpayload=keep) and when suspending/resuming, and we are now > doing the opposite, thus breaking the code for some setups. Is it possible > that the bit/register logic is not the same for all Radeon GPUs? After all, > we already introduced a different path for DCE6. Bit 0 for CRTC_CONTROL turns on/off the entire crtc. If bit 0 is 0 the crtc is disabled. If bit 0 is 1, the crtc is enabled. If the crtc is disabled (bit 0 = 0) bit 24 is irrelevant. There are separate bits to enable the crtc and disable memory requests since there are cases (like this one) where we want to keep the crtc timing running so that the monitor stays synced, but disable reads from memory so we can reconfigure the memory controller. If we disable the crtc entirely, the monitor would lose sync and you would get additional flicker during boot up. Ideally, eventually we'd like to just hand over control from the firmware without touching the display hardware so the user gets a flicker free boot experience. DCE4 and 5 have the same logic and bit layout for these registers. The logic is different on DCE6 chips. On DCE6, the the memory controller request bit is now tied in with the crtc blanking bit. When the crtc is blanked, memory requests are also disabled. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #16 from Alex Deucher --- Created attachment 69573 --> https://bugs.freedesktop.org/attachment.cgi?id=69573&action=edit possible fix Actually, I think I found the problem. Missing index in mc_resume(). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix typo in evergreen_mc_resume()
From: Alex Deucher
Add missing index that may have led us to enabling
more crtcs than necessary.
May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 14313ad..af31f82 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1372,7 +1372,7 @@ void evergreen_mc_resume(struct radeon_device *rdev,
struct evergreen_mc_save *s
WREG32(BIF_FB_EN, FB_READ_EN | FB_WRITE_EN);
for (i = 0; i < rdev->num_crtc; i++) {
- if (save->crtc_enabled) {
+ if (save->crtc_enabled[i]) {
if (ASIC_IS_DCE6(rdev)) {
tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL +
crtc_offsets[i]);
tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
Alex Deucher wrote: On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote: Alex Deucher wrote: On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off and then turn TV on and - xrandr --output DVI-0 --auto to bring up the the TV and get a clone of monitor. This still works with drm-core-next but not with drm-fixes (todays or from a few days ago). With df I now loose the monitor with signal out of range when doing above, the TV output is OK. To get the monitor back I need to turn off TV, then off/auto the monitor. xrandr --output DVI-0 --off xrandr --output DVI-1 --off xrandr --output DVI-1 --auto The output from xrandr while the monitor is showing signal out of range looks normal. If I boot with the TV on it works OK. Can you bisect? 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit commit 29dbe3bcd2e28e71823febdca989d63d5c27d152 Author: Alex Deucher Date: Fri Oct 5 10:22:02 2012 -0400 drm/radeon: allocate PPLLs from low to high The order shouldn't matter, but there have been problems reported on certain older asics. This behaves more like the original code before the PPLL allocation rework. Signed-off-by: Alex Deucher Cc: Markus Trippelsdorf That's bizarre. That patch reverts the behavior back to the 3.6 and earlier kernel behavior. I guess it's some issue with the ordering of the modesetting programming sequence. I've attached a couple of things to try. The first patch is a simple fix. It just reverts back to the previous pll allocation order for discrete cards like yours: 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch The second set of patches implements a more complex fix which may help regardless of the order in which plls are allocated: 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch 0003-drm-radeon-disable-the-pll-before-a-modeset.patch Can you see if the second set helps? If not, please try the first patch. The second set doesn't fix it. The first patch does. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 Tony Thomas changed: What|Removed |Added Attachment #68684|0 |1 is obsolete|| Attachment #68717|0 |1 is obsolete|| --- Comment #8 from Tony Thomas --- Created attachment 69579 --> https://bugs.freedesktop.org/attachment.cgi?id=69579&action=edit Debian Sid w/3.6.8-pf dmesg (drm.debug=6) Switched system to Debian Sid, clean install. Sid is tracking 8.0.5-1 mesa http://packages.debian.org/search?keywords=mesa&searchon=names&suite=unstable§ion=all Screen corruption still, using Sid 3.2.0-4 stock kernel, and 3.6.8-pf kernel from here: http://kernel.night-leshiy.ru/ Attaching drm.debug=6 dmesg from Debian 3.6.8-pf kernel -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 Tony Thomas changed: What|Removed |Added Attachment #68713|0 |1 is obsolete|| --- Comment #9 from Tony Thomas --- Created attachment 69580 --> https://bugs.freedesktop.org/attachment.cgi?id=69580&action=edit Debian Sid w/3.6.8-pf xorg.0.log (fail) Xorg.0.log from above failure (Debian Sid, 3.6.8-pf kernel) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 --- Comment #10 from Tony Thomas --- Of note: with most kernel combo and 8.0 mesa branch (also tried on Arch Linux), failures and corruption DO NOT prevent VT-switching as the 9.0 branch does. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53130] 99c65ba breaks rendering (flickery, eventual fail)
https://bugs.freedesktop.org/show_bug.cgi?id=53130 --- Comment #3 from Darren Salt --- I've rebuilt mesa with this re-enabled and I saw a lot of rendering glitches. I suspect that DISCARD_RANGE being re-enabled is the problem, although I've also built and installed an updated xf86-video-ati (cdf522f→20bfc65). My current mesa build has 1eedebc reverted; I'll re-check with that undone later. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #17 from Alexandre Demers --- I'm about to test patches. But before, as promised, here are the values retrieved read and written to the registers. By the way, I have only a single monitor. tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]); -> 272696081 (0001 0100 0001 0011 0001 0001) tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; -> 289473297 (0001 0001 0100 0001 0011 0001 0001) So, it is set as you explained me earlier. I'll be back soon with some news from the patches. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56788] New: [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"
https://bugs.freedesktop.org/show_bug.cgi?id=56788 Priority: medium Bug ID: 56788 Assignee: dri-devel@lists.freedesktop.org Summary: [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders" Severity: normal Classification: Unclassified OS: All Reporter: emil.l.veli...@gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/DRI/Radeon Product: Mesa Created attachment 69589 --> https://bugs.freedesktop.org/attachment.cgi?id=69589&action=edit Untrimmed stdout & stderr As of approx 1 Nov 2012, Dota2 crashes while playing/spectating a game Initially I was suspecting the recent vbo work by Marek, although I'm leaning towards memory bug/buggy shader in one of the Dota2 3 updates - 29,30 and 1 Nov Cannot downgrade to verify, although backtrace does point that the crash occurs after the above message is printed to stderr Brief list of the other messages printed to strout & strerr WARNING: value %35 not uniquely defined ... WARNING: value %277 not uniquely defined WARNING: value %17 not uniquely defined context mis-match in pipe_sampler_view_release() WARNING: value %28 not uniquely defined ... WARNING: value %17 not uniquely defined WARNING: out of code space, evicting all shaders. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"
https://bugs.freedesktop.org/show_bug.cgi?id=56788 --- Comment #1 from Emil Velikov --- Created attachment 69590 --> https://bugs.freedesktop.org/attachment.cgi?id=69590&action=edit Wine backtrace -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"
https://bugs.freedesktop.org/show_bug.cgi?id=56788 Emil Velikov changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org|rg Component|Drivers/DRI/Radeon |Drivers/DRI/nouveau --- Comment #2 from Emil Velikov --- Correcting component -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()
https://bugzilla.kernel.org/show_bug.cgi?id=48941 Florian Mickler changed: What|Removed |Added CC||flor...@mickler.org --- Comment #7 from Florian Mickler 2012-11-05 23:15:22 --- A patch referencing this bug report has been merged in Linux v3.7-rc3: commit 614499b4d844dcceae5ae2f1e53a2963789a8933 Author: Alex Deucher Date: Wed Oct 17 17:20:24 2012 -0400 drm/radeon: give each backlight a unique id -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()
https://bugzilla.kernel.org/show_bug.cgi?id=48941 Igor Murzov changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX --- Comment #8 from Igor Murzov 2012-11-05 23:36:42 --- Fixed. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #18 from Alexandre Demers --- (In reply to comment #16) > Created attachment 69573 [details] [review] > possible fix > > Actually, I think I found the problem. Missing index in mc_resume(). This seems to fix my resume problem I was experiencing where the display would come up, but then it would crash. However, it doesn't solve the boot/grub2 bug. So, this patch should be kept (but not for the current bug). -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #19 from Alexandre Demers --- (In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #12) > > > (In reply to comment #11) > > > > Found what is wrong with the help of a few printk and by comparing to > > > > the > > > > code being replaced. All the logic is good (going through crtc, > > > > disabling > > > > them, waiting for vblank) BUT setting "tmp |= > > > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. > > > > > > > > If I do as in the previous code by setting tmp = 0 and then continuing > > > > with: > > > > radeon_wait_for_vblank(rdev, i); > > > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); > > > > everything works fine as before. > > > > > > > > What is expected from "tmp |= > > > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? > > > > From what I read with printk, it is far from a 0 or a 1. Is this normal? > > > > > > That's the most important bit in the entire sequence. It's a bit field > > > in a > > > register (bit 24 to be exact). That bit is the bit that actually disables > > > the requests from the display controller in the memory controller. The > > > whole point of this code is to disable all clients of the memory > > > controller > > > (mc_stop()) so that we can change the location of vram within the GPU's > > > address space. Once we've moved vram, we can re-enable the clients > > > (mc_resume()) so that they point to the new vram location. > > > > Thank you, you confirmed what I had assumed. I had already understood that > > it was the most important part in the sequence since it is associated to a > > "write" instruction. I don't have the (decimal/binary) values with me right > > now, but I'll be able to give you what was read from the register and from > > the result returned from the bitwise OR assignment we are pushing in the > > register. I'll confirm which bit(s) are changing. I'm sure the assignment > > was setting one (or more) bit in the register to "1". Is bit 24 the only one > > expected to change in the register? Should it be put to "1" or "0"? > > > > Setting bit 24 to 1 disables memory requests from the display controller. > Setting bit 24 to 0, enables memory requests from the display controller. > > > Another question: why were we setting "0" in the register before? By doing > > so, we were setting the whole register to "0" (the whole 32 bits), right? If > > I remember correctly, from what I saw yesterday with the help of printk, it > > seems we are setting at least one bit to "1" in this register, which would > > be the opposite of what was being done before and therefore of what was > > working correctly with my video card. I'm just trying to understand why we > > were doing something in the first place that was working correctly and that > > was introduce to fix this problem in the first place, both at boot time for > > grub (set gfxpayload=keep) and when suspending/resuming, and we are now > > doing the opposite, thus breaking the code for some setups. Is it possible > > that the bit/register logic is not the same for all Radeon GPUs? After all, > > we already introduced a different path for DCE6. > > Bit 0 for CRTC_CONTROL turns on/off the entire crtc. If bit 0 is 0 the crtc > is disabled. If bit 0 is 1, the crtc is enabled. If the crtc is disabled > (bit 0 = 0) bit 24 is irrelevant. There are separate bits to enable the > crtc and disable memory requests since there are cases (like this one) where > we want to keep the crtc timing running so that the monitor stays synced, > but disable reads from memory so we can reconfigure the memory controller. > If we disable the crtc entirely, the monitor would lose sync and you would > get additional flicker during boot up. Ideally, eventually we'd like to > just hand over control from the firmware without touching the display > hardware so the user gets a flicker free boot experience. > > DCE4 and 5 have the same logic and bit layout for these registers. The > logic is different on DCE6 chips. On DCE6, the the memory controller > request bit is now tied in with the crtc blanking bit. When the crtc is > blanked, memory requests are also disabled. If I followed you correctly, setting bit 24 to "1" disables memory but keeps the CRTC state as it is (hopefully in sync with the monitor). However, what I see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor. Sometimes the display will be black, other times it will only appear in the first couple of vertical lines, in others it will be vertically synced but shifted to the right at half or at two third of the screen. In other words, this really seems to be a sync problem. Should I try to combine patch 69113 and patch 69370 with the others? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.free
[ANNOUNCE] libdrm 2.4.40
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, libdrm 2.4.40 has been released. The reason is we need to use the radeon stencil mipmap allocator for combined depth-stencil buffers in Mesa. Alex Deucher (1): radeon: add some new SI pci ids Andreas Boll (1): radeon: fix unused-function warning Chris Wilson (3): intel: Fix "properly test for HAS_LLC" intel: Correct the word decoding for gen2 3DSTATE_LOAD_STATE_IMMEDIATE_1 intel: Silence a trivial compiler warning Daniel Stone (1): configure.ac: Allow forcible disabling of Cairo support Daniel Vetter (1): intel: properly test for HAS_LLC Dave Airlie (1): fix make distcheck Jakob Bornecrantz (1): vmwgfx: No longer experimental Jesse Barnes (2): intel: add support for ValleyView libdrm: man page infrastructure and a few sample man pages Kristian Høgsberg (1): intel: Mark bo's exported to prime as not reusable Marcin Slusarz (1): libkms: link against libdrm Marek Olšák (5): radeon: don't take the stencil-specific codepath for buffers without stencil radeon: don't force stencil tile split to 0 radeon: fix stencil miptree allocation of combined ZS buffers on EG and SI radeon: fix tile_split of 128-bit surface formats with 8x MSAA configure.ac: bump version to 2.4.40 for release Michel Dänzer (3): radeon: Fix layout of linear aligned mipmaps on SI. radeon: Memory footprint of SI mipmap base level is padded to powers of two. radeon: Sampling pitch for non-mipmaps seems padded to slice alignment on SI. Rob Clark (2): update gitignore initialize width/height fields in drmModeCrtc Vincent Penquerc'h (1): omap: release lock also on error paths git tag: libdrm-2.4.40 http://dri.freedesktop.org/libdrm/libdrm-2.4.40.tar.bz2 MD5: 626a3dc44a40ef37565b61732b688567 libdrm-2.4.40.tar.bz2 SHA1: 0f77aa49922e17102caa75de86c8e79bbf23b4a1 libdrm-2.4.40.tar.bz2 SHA256: 48c14e4600ea0fde522292893eb4055d2f6d86a69d093d379c827deaccffaa1f libdrm-2.4.40.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.40.tar.gz MD5: d6c7eae620f0c0252377f0bf6a02ce54 libdrm-2.4.40.tar.gz SHA1: fa16e9704514e3368a5b207ba250a7d7626b627b libdrm-2.4.40.tar.gz SHA256: 9f2ea4c1e5656c28e9237e9a67c58282b86b8e964aac5734774a2cd30ee17381 libdrm-2.4.40.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJQmGD3AAoJEP3RXVrO8PKxg4cH/RDZUrVYqm4nDfnuVUFHLcju SgPv3HEScFMvYeyrwNIGJKFca6ZkUQdS19YtS9x88WeRjsC811BNjQoNyvZd1D+V 6mKZwATR0IZ4bRmTTU58zgqFqboIdzrzXi/Cv0U3Qx7pbDdCUrHUAvcyjvLG5/Y6 SU9VmrQe1p/tlr3beQbJALhSFJpXJMS57BXz0M/58MlmeKplXjoPLVd/teOZGXB2 s4kxj1r4WBKcdnD9vnjoRrcrRV5ghdliqnmZf+xM2edBRIoreGQ/ZPzc9tXT8ywF 3BsBvyDxRwZFtUlDTocUrdTAeCpGQPhDe2pbxcMUKnA98ZUfmk+mHR7WL2HpE84= =eban -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: exynos: fix for mapping of dma buffers
Applied.
Thanks,
Inki Dae
2012/11/6 Rahul Sharma
> This patch fixes the problem of mapping contigous and non contigous dma
> buffers.
>
> Currently page struct is calculated from the buf->dma_addr which is not the
> physical address. It is replaced by buf->pages which points to the page
> struct
> of the first page of contigous memory chunk. This gives the correct page
> frame
> number for mapping.
>
> Non-contigous dma buffers are described using SG table and SG lists. Each
> valid SG List is pointing to a single page or group of pages which are
> physically contigous. Current implementation just maps the first page of
> each
> SG List and leave the other pages unmapped, leading to a crash. Given
> solution
> finds the page struct for the faulting page through parsing SG table and
> map it.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c | 28
> +---
> 1 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 8cb6824..50d73f1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -95,15 +95,37 @@ static int exynos_drm_gem_map_buf(struct
> drm_gem_object *obj,
> {
> struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
> struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
> + struct scatterlist *sgl;
> unsigned long pfn;
> + int i;
>
> if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
> + if (!buf->sgt)
> + return -EINTR;
> +
> + sgl = buf->sgt->sgl;
> + for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
> + if (!sgl) {
> + DRM_ERROR("invalid SG table\n");
> + return -EINTR;
> + }
> + if (page_offset < (sgl->length >> PAGE_SHIFT))
> + break;
> + page_offset -= (sgl->length >> PAGE_SHIFT);
> + }
> +
> + if (i >= buf->sgt->nents) {
> + DRM_ERROR("invalid page offset\n");
> + return -EINVAL;
> + }
> +
> + pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
> + } else {
> if (!buf->pages)
> return -EINTR;
>
> - pfn = page_to_pfn(buf->pages[page_offset++]);
> - } else
> - pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
> + pfn = page_to_pfn(buf->pages[0]) + page_offset;
> + }
>
> return vm_insert_mixed(vma, f_vaddr, pfn);
> }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 255/259] drivers/gpu/drm/i915/i915_gem_gtt.c:366:36: sparse: dereference of noderef expression
Hi Ben,
FYI, there are new sparse warnings show up in
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: afef67fbc09aec8508c88aac1931661a36e91958
commit: a1e0e54668f41badfaf5e49cae9fc10b79635b25 [255/259] drm/i915: Stop using
AGP layer for GEN6+
+ drivers/gpu/drm/i915/i915_gem_gtt.c:366:36: sparse: dereference of noderef
expression
vim +366 drivers/gpu/drm/i915/i915_gem_gtt.c
a1e0e546 Ben Widawsky 2012-11-04 350 {
a1e0e546 Ben Widawsky 2012-11-04 351 struct drm_device *dev = obj->base.dev;
a1e0e546 Ben Widawsky 2012-11-04 352 struct drm_i915_private *dev_priv =
dev->dev_private;
a1e0e546 Ben Widawsky 2012-11-04 353 struct sg_table *st = obj->pages;
a1e0e546 Ben Widawsky 2012-11-04 354 struct scatterlist *sg = st->sgl;
a1e0e546 Ben Widawsky 2012-11-04 355 const int first_entry =
obj->gtt_space->start >> PAGE_SHIFT;
a1e0e546 Ben Widawsky 2012-11-04 356 const int max_entries =
dev_priv->mm.gtt->gtt_total_entries - first_entry;
a1e0e546 Ben Widawsky 2012-11-04 357 gtt_pte_t __iomem *gtt_entries =
dev_priv->mm.gtt->gtt + first_entry;
a1e0e546 Ben Widawsky 2012-11-04 358 int unused, i = 0;
a1e0e546 Ben Widawsky 2012-11-04 359 unsigned int len, m = 0;
a1e0e546 Ben Widawsky 2012-11-04 360 dma_addr_t addr;
a1e0e546 Ben Widawsky 2012-11-04 361
a1e0e546 Ben Widawsky 2012-11-04 362 for_each_sg(st->sgl, sg, st->nents,
unused) {
a1e0e546 Ben Widawsky 2012-11-04 363 len = sg_dma_len(sg) >>
PAGE_SHIFT;
a1e0e546 Ben Widawsky 2012-11-04 364 for (m = 0; m < len; m++) {
a1e0e546 Ben Widawsky 2012-11-04 365 addr =
sg_dma_address(sg) + (m << PAGE_SHIFT);
a1e0e546 Ben Widawsky 2012-11-04 @366 gtt_entries[i] =
pte_encode(dev, addr, level);
a1e0e546 Ben Widawsky 2012-11-04 367 i++;
a1e0e546 Ben Widawsky 2012-11-04 368 }
a1e0e546 Ben Widawsky 2012-11-04 369 }
a1e0e546 Ben Widawsky 2012-11-04 370
a1e0e546 Ben Widawsky 2012-11-04 371 BUG_ON(i > max_entries);
a1e0e546 Ben Widawsky 2012-11-04 372 BUG_ON(i != obj->base.size / PAGE_SIZE);
a1e0e546 Ben Widawsky 2012-11-04 373
a1e0e546 Ben Widawsky 2012-11-04 374 /* XXX: This serves as a posting read
to make sure that the PTE has
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: merging printk and WARN
On Sun, Nov 04, 2012 at 09:25:53PM +0100, Julia Lawall wrote: > It looks like these patches were not a good idea, because in each case the > printk provides an error level, and WARN then provides another one. I think this is not a problem within btrfs at the place where this has changed. david ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[bisected] drm i915 hangs on heavy io load
On Sunday 04 November 2012 16:08:47 Dave Airlie wrote: > On Sun, Nov 4, 2012 at 10:44 AM, Norbert Preining wrote: > > On Di, 30 Okt 2012, Dave Airlie wrote: > >> I would suggest starting a bisect on drivers/gpu/drm/i915 from 3.6 > >> final to 3.7-rc1 or maybe -rc2. > > > > Sorry for my ignorance ... I did on master branch > > > > $ git checkout v3.7-rc1 > > ... > > $ git bisect start drivers/gpu/drm/i915 > > $ git bisect bad > > $ git bisect good v3.6 > > Bisecting: 121 revisions left to test after this (roughly 7 steps) > > [25c5b2665fe4cc5a93edd29b62e7c05c1526] drm/i915: implement new > > set_mode code flow $ > > > > after that I am back somewhere around > > > > 3.6.0-rc2 > > > > ??? > > > > Am I doing something wrong? I thought I am bisecting between 3.6 and > > 3.7.-rc2? How can I go back to 3.6.0-rc2? > > Yeah thats fine, bisecting works by going to where commits were > originally committed, so drm-intel-next was 3.6.0-rc2 at some point > was only merged into Linus later. As I mentioned on https://bugs.freedesktop.org/show_bug.cgi?id=55984, I also hit this bug. The first time was on branch drm-intel-next-2012-09-20 on Daniel Vetters drm-intel git. I guess it has something to do with low memory. To reproduce the bug on my laptop with 8GB RAM and a i5-460M, I did: 1. Boot (I use KDE) 3. Start glxspheres (from http://virtualgl.org/, but glxgears might work too, not tested) 2. Copy a 1.2 GiB Linux source tree to /dev/shm and /tmp (both tmpfs), 5 times. This uses 6GiB of RAM. I used this bash script: #!/bin/bash for i in /tmp/hang-l1 /tmp/hang-l2 /tmp/hang-l3 \ /dev/shm/hang-l1 /dev/shm/hang-l2; do cp -ra ~/Linux-src/linux "$i" & done; wait 3. When the copy is almost done, watch the machine become sluggish and eventually print the "[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung" message to the kernel log. Until the machine is rebooted, all OpenGL applications will fail to load. On kernels where it was working fine, there is no lag when the copy is almost finished. 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 is the first bad commit commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846 Author: Chris Wilson Date: Thu Aug 23 13:12:52 2012 +0100 drm/i915: Use cpu relocations if the object is in the GTT but not mappable This prevents the case of unbinding the object in order to process the relocations through the GTT and then rebinding it only to then proceed to use cpu relocations as the object is now in the CPU write domain. By choosing to use cpu relocations up front, we can therefore avoid the rebind penalty. Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter :04 04 090ed3d52b4f3210b988877f747b6ff86e123385 1d48be89ded4777a543b693db833de64877059c4 M drivers Regards, Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the >>manager needs to observe all the possible displays used at the same >>time... > >Right. I was wondering if omapfb/omapdrm could understand the 'all >possible displays information' better compared to a panel's probe. > >Even omapdrm/omafb can't be perfect because we could insert a panel >driver module at any time, and omapfb/omapdrm may miss that out. True, omapdrm/fb may have a better idea. It's still unclear though. Currently we have quite strict order in the sequence the modules need to be loaded, which is quite bad and causes issues. We should make things more dynamic, so that the initialization of the drivers could happen more freely. But that creates more problems: when booting up, omapfb starts. But omapfb can't know if all the panel drivers have already been loaded. omapfb may see that DVI is the default display, but what should it do if DVI doesn't have a driver yet? It could wait, but perhaps the driver for DVI will never even be loaded. The encoder which is connected to the crtc (manager) is picked by combination of encoder->possible_crtcs bitmask and connector->best_encoder(). We could keep things limited so that the association of crtc to encoder (manager to output, roughly) never changes, but this isn't really the right thing to do. It is better that the dssdev not rely on knowing the manager it is attached to at probe time, but instead grab resources more dynamically. Also, at the moment we don't really have any notification to userspace about new encoders/connectors showing up (or conversely, being removed). Only about existing connectors being plugged/unplugged. The closest analogy is perhaps the USB display devices, but even there it is only the entire drm device that is plugged/unplugged. And TBH I don't really see the point in supporting panel drivers being dynamically loaded. It isn't like someone is dynamically soldering on a new display connector to some board that is running. I think omapfb or omapdrm probe should trigger registering the compiled-in panel drivers, so that it can be sure that the dssdev's pop up before it goes and creates drm connector objects. Currently we have to hack around this in omapdrm with late_initcall() to ensure the panel drivers are probed first, but that is an ugly hack that I'd like to get rid of. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix typo in evergreen_mc_resume()
On Mon, 2012-11-05 at 11:34 -0500, alexdeuc...@gmail.com wrote: > From: Alex Deucher > > Add missing index that may have led us to enabling > more crtcs than necessary. > > May also fix: > https://bugs.freedesktop.org/show_bug.cgi?id=56139 > > Signed-off-by: Alex Deucher Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm i915 hangs on heavy io load
On So, 04 Nov 2012, Dave Airlie wrote:
> Yeah thats fine, bisecting works by going to where commits were
> originally committed, so drm-intel-next was 3.6.0-rc2 at some point
> was only merged into Linus later.
Ok, thanks, didn't know that. Have started the bisect game now,
coming back in about 1 year ;-)
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
SCOPWICK (n.)
The flap of skin which is torn off you lip when trying to smoke an
untipped cigarette.
--- Douglas Adams, The Meaning of Liff
[PATCH v4] drm/exynos: add iommu support for exynos drm framework
Changelog v4:
- fix condition to drm_iommu_detach_device funtion.
Changelog v3:
- add dma_parms->max_segment_size setting of drm_device->dev.
- use devm_kzalloc instead of kzalloc.
Changelog v2:
- fix iommu attach condition.
. check archdata.dma_ops of drm device instead of
subdrv device's one.
- code clean to exynos_drm_iommu.c file.
. remove '#ifdef CONFIG_ARM_DMA_USE_IOMMU' from exynos_drm_iommu.c
and add it to driver/gpu/drm/exynos/Kconfig.
Changelog v1:
This patch adds iommu support for exynos drm framework with dma mapping
api. In this patch, we used dma mapping api to allocate physical memory
and maps it with iommu table and removed some existing codes and added
new some codes for iommu support.
GEM allocation requires one device object to use dma mapping api so
this patch uses one iommu mapping for all sub drivers. In other words,
all sub drivers have same iommu mapping.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/Kconfig |6 +
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos_drm_buf.c| 88 +
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 87 +---
drivers/gpu/drm/exynos/exynos_drm_drv.c| 23 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 11 ++
drivers/gpu/drm/exynos/exynos_drm_fb.c | 52 +++-
drivers/gpu/drm/exynos/exynos_drm_gem.c| 210 ++--
drivers/gpu/drm/exynos/exynos_drm_gem.h|1 +
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 150
drivers/gpu/drm/exynos/exynos_drm_iommu.h | 85 +++
11 files changed, 409 insertions(+), 305 deletions(-)
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.c
create mode 100644 drivers/gpu/drm/exynos/exynos_drm_iommu.h
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 59a26e5..4ea8cdc 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -10,6 +10,12 @@ config DRM_EXYNOS
Choose this option if you have a Samsung SoC EXYNOS chipset.
If M is selected the module will be called exynosdrm.
+config DRM_EXYNOS_IOMMU
+ bool "EXYNOS DRM IOMMU Support"
+ depends on DRM_EXYNOS && EXYNOS_IOMMU && ARM_DMA_USE_IOMMU
+ help
+ Choose this option if you want to use IOMMU feature for DRM.
+
config DRM_EXYNOS_DMABUF
bool "EXYNOS DRM DMABUF"
depends on DRM_EXYNOS
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index eb651ca..26813b8 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -8,6 +8,7 @@ exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o
exynos_drm_connector.o \
exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
exynos_drm_plane.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
exynosdrm-$(CONFIG_DRM_EXYNOS_DMABUF) += exynos_drm_dmabuf.o
exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)+= exynos_hdmi.o exynos_mixer.o \
diff --git a/drivers/gpu/drm/exynos/exynos_drm_buf.c
b/drivers/gpu/drm/exynos/exynos_drm_buf.c
index 118c117..48c5896 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_buf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_buf.c
@@ -33,71 +33,58 @@
static int lowlevel_buffer_allocate(struct drm_device *dev,
unsigned int flags, struct exynos_drm_gem_buf *buf)
{
- dma_addr_t start_addr;
+ int ret = 0;
unsigned int npages, i = 0;
struct scatterlist *sgl;
- int ret = 0;
+ enum dma_attr attr = DMA_ATTR_FORCE_CONTIGUOUS;
DRM_DEBUG_KMS("%s\n", __FILE__);
- if (IS_NONCONTIG_BUFFER(flags)) {
- DRM_DEBUG_KMS("not support allocation type.\n");
- return -EINVAL;
- }
-
if (buf->dma_addr) {
DRM_DEBUG_KMS("already allocated.\n");
return 0;
}
- if (buf->size >= SZ_1M) {
- npages = buf->size >> SECTION_SHIFT;
- buf->page_size = SECTION_SIZE;
- } else if (buf->size >= SZ_64K) {
- npages = buf->size >> 16;
- buf->page_size = SZ_64K;
- } else {
- npages = buf->size >> PAGE_SHIFT;
- buf->page_size = PAGE_SIZE;
+ init_dma_attrs(&buf->dma_attrs);
+
+ if (flags & EXYNOS_BO_NONCONTIG)
+ attr = DMA_ATTR_WRITE_COMBINE;
+
+ dma_set_attr(attr, &buf->dma_attrs);
+
+ buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
+ &buf->dma_addr, GFP_KERNEL, &buf->dma_attrs);
+ if (!buf->kvaddr) {
+ DRM_ERROR("failed to allocate buffer.\n");
+ return -ENOMEM;
}
buf->sgt = kzalloc(sizeof(struct sg_table), GFP_KERNEL);
if (!buf->sgt) {
DRM_ERROR("failed to allocate sg table.\n");
- return -ENOMEM;
[PATCH] drm/exynos: add userptr feature for g2d module
This patch adds userptr feautre for G2D module.
The userptr means user space address allocated by malloc().
And the purpose of this feature is to make G2D's dma able
to access the user space region.
To user this feature, user should flag G2D_BUF_USRPTR to
offset variable of struct drm_exynos_g2d_cmd and fill
struct drm_exynos_g2d_userptr with user space address
and size for it and then should set a pointer to
drm_exynos_g2d_userptr object to data variable of struct
drm_exynos_g2d_cmd. The last bit of offset variable is used
to check if the cmdlist's buffer type is userptr or not.
If userptr, the g2d driver gets user space address and size
and then gets pages through get_user_pages().
(another case is counted as gem handle)
Below is sample codes:
static void set_cmd(struct drm_exynos_g2d_cmd *cmd,
unsigned long offset, unsigned long data)
{
cmd->offset = offset;
cmd->data = data;
}
static int solid_fill_test(int x, int y, unsigned long userptr)
{
struct drm_exynos_g2d_cmd cmd_gem[5];
struct drm_exynos_g2d_userptr g2d_userptr;
unsigned int gem_nr = 0;
...
g2d_userptr.userptr = userptr;
g2d_userptr.size = x * y * 4;
set_cmd(&cmd_gem[gem_nr++], DST_BASE_ADDR_REG |
G2D_BUF_USERPTR,
(unsigned long)&g2d_userptr);
...
}
int main(int argc, char **argv)
{
unsigned long addr;
...
addr = malloc(x * y * 4);
...
solid_fill_test(x, y, addr);
...
}
And next, the pages are mapped with iommu table and the device
address is set to cmdlist so that G2D's dma can access it.
As you may know, the pages from get_user_pages() are pinned.
In other words, they CAN NOT be migrated and also swapped out.
So the dma access would be safe.
But the use of userptr feature has performance overhead so
this patch also has memory pool to the userptr feature.
Please, assume that user sends cmdlist filled with userptr
and size every time to g2d driver, and the get_user_pages
funcion will be called every time.
The memory pool has maximum 64MB size and the userptr that
user had ever sent, is holded in the memory pool.
This meaning is that if the userptr from user is same as one
in the memory pool, device address to the userptr in the memory
pool is set to cmdlist.
And last, the pages from get_user_pages() will be freed once
user calls free() and the dma access is completed. Actually,
get_user_pages() takes 2 reference counts if the user process
has never accessed user region allocated by malloc(). Then, if
the user calls free(), the page reference count becomes 1 and
becomes 0 with put_page() call. And the reverse holds as well.
This means how the pages backed are used by dma and freed.
This patch is based on "drm/exynos: add iommu support for g2d",
https://patchwork.kernel.org/patch/1629481/
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.h |3 +-
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 342 --
drivers/gpu/drm/exynos/exynos_drm_gem.c | 123 +++
drivers/gpu/drm/exynos/exynos_drm_gem.h | 45
include/uapi/drm/exynos_drm.h | 13 +-
5 files changed, 499 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index a9db025..a4702a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -231,8 +231,7 @@ struct exynos_drm_g2d_private {
struct device *dev;
struct list_headinuse_cmdlist;
struct list_headevent_list;
- struct list_headgem_list;
- unsigned intgem_nr;
+ struct list_headuserptr_list;
};
struct drm_exynos_file_private {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index bac2399..a9002ad 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -97,11 +97,19 @@
#define MAX_BUF_ADDR_NR6
+/* maximum buffer pool size of userptr is 64MB as default */
+#define MAX_POOL (64 * 1024 * 1024)
+
+enum {
+ BUF_TYPE_GEM = 1,
+ BUF_TYPE_USERPTR,
+};
+
/* cmdlist data structure */
struct g2d_cmdlist {
- u32 head;
- u32 data[G2D_CMDLIST_DATA_NUM];
- u32 last; /* last data offset */
+ u32 head;
+ unsigned long data[G2D_CMDLIST_DATA_NUM];
+ u32 last; /* last data offset */
};
struct drm_exynos_pending_g2d_event {
@@ -109,11 +117,26 @@ struct drm_exynos_pending_g2d_event {
struct drm_exynos_g2d_event event;
};
+struct g2d_cmdlist_userptr {
+ struct list_headlist;
+ dma_addr_t dma_addr;
+ unsigned long userptr;
+ unsigned
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #11 from Alexandre Demers --- Found what is wrong with the help of a few printk and by comparing to the code being replaced. All the logic is good (going through crtc, disabling them, waiting for vblank) BUT setting "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. If I do as in the previous code by setting tmp = 0 and then continuing with: radeon_wait_for_vblank(rdev, i); WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); everything works fine as before. What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? From what I read with printk, it is far from a 0 or a 1. Is this normal? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/ab1a6c11/attachment-0001.html>
nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, 29 Oct 2012 23:16:24 +0100 Antonio Ospite wrote: > Hi, > > I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), > my video adapter is the one integrated on the MSI M3N78-VM motherboard > (hence x86_64): > [...] > [ 1943.858601] BUG: unable to handle kernel paging request at fff8 > [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 [nouveau] > [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 > [ 1943.858803] Oops: [#1] SMP [..] > [ 1943.860018] Call Trace: > [ 1943.860019] [] ? kmem_cache_alloc_trace+0xbf/0xcf > [ 1943.860019] [] ? should_resched+0x5/0x23 > [ 1943.860019] [] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau] Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits a7dbf00 and 5cad16a which seem to be related to the problem I was having; would you mind elaborating a bit about what you think was causing the crash on my side? Maybe the chipset used on this motherboard doesn't support some feature? And how did you figured out from the logs? Thanks, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite wrote: > On Mon, 29 Oct 2012 23:16:24 +0100 > Antonio Ospite wrote: > >> Hi, >> >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), >> my video adapter is the one integrated on the MSI M3N78-VM motherboard >> (hence x86_64): >> > [...] >> [ 1943.858601] BUG: unable to handle kernel paging request at >> fff8 >> [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 [nouveau] >> [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 >> [ 1943.858803] Oops: [#1] SMP > [..] >> [ 1943.860018] Call Trace: >> [ 1943.860019] [] ? kmem_cache_alloc_trace+0xbf/0xcf >> [ 1943.860019] [] ? should_resched+0x5/0x23 >> [ 1943.860019] [] ? nv50_fb_vram_new+0xc5/0x1f2 [nouveau] > > Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits > a7dbf00 and 5cad16a which seem to be related to the problem I was > having; would you mind elaborating a bit about what you think was > causing the crash on my side? Maybe the chipset used on this motherboard > doesn't support some feature? And how did you figured out from the logs? > 5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix The chipset hasn't got Z compression support, and the oops once decoded pointed out the new code was trying to allocate Z tags from a NULL memory block. The old code use to allocate an empty memory block instead of NULL, and it got lost in the rewrite, Ben just fixed it to allow empty memory blocks again. Dave.
[PATCH v7 8/8] drm_modes: add of_videomode helpers
On Wed, Oct 31, 2012 at 10:28:08AM +0100, Steffen Trumtrar wrote: [...] > +/** > + * of_get_drm_display_mode - get a drm_display_mode from devicetree > + * @np: device_node with the timing specification > + * @dmode: will be set to the return value > + * @index: index into the list of display timings in devicetree > + * > + * DESCRIPTION: I don't think this is necessary. > + * This function is expensive and should only be used, if only one mode is > to be > + * read from DT. To get multiple modes start with of_get_display_timing_list > ond You probably meant "and" at the end of this line. Also I'm not even sure that we should be exposing this function, but rather provide a helper which automatically adds the parsed modes to a DRM connector object. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/41cb8434/attachment.pgp>
[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops
A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and down. In-Reply-To:
[PATCH 1/4] drm: Make hashtab rcu-safe
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned
long key)
hashed_key = hash_long(key, ht->order);
DRM_DEBUG("Key is 0x%08lx, Hashed key is 0x%08x\n", key, hashed_key);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG("count %d, key: 0x%08lx\n", count++, entry->key);
- }
}
static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct
drm_open_hash *ht,
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return list;
if (entry->key > key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
parent = NULL;
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return -EINVAL;
if (entry->key > key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
parent = list;
}
if (parent) {
- hlist_add_after(parent, &item->head);
+ hlist_add_after_rcu(parent, &item->head);
} else {
- hlist_add_head(&item->head, h_list);
+ hlist_add_head_rcu(&item->head, h_list);
}
return 0;
}
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
list = drm_ht_find_key(ht, key);
if (list) {
- hlist_del_init(list);
+ hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
{
- hlist_del_init(&item->head);
+ hlist_del_init_rcu(&item->head);
return 0;
}
EXPORT_SYMBOL(drm_ht_remove_item);
--
1.7.4.4
[PATCH 2/4] kref: Implement kref_get_unless_zero
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.
Signed-off-by: Thomas Hellstrom
---
include/linux/kref.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..fd16042 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
}
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+ return !atomic_add_unless(&kref->refcount, 1, 0);
+}
#endif /* _KREF_H_ */
--
1.7.4.4
[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm/ttm_object.h |4
include/linux/kref.h |2 +-
4 files changed, 20 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
*/
struct ttm_object_device {
- rwlock_t object_lock;
+ spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
kref_init(&base->refcount);
ret = drm_ht_just_insert_please(&tdev->object_hash,
&base->hash,
(unsigned long)base, 31, 0, 0);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (unlikely(ret != 0))
goto out_err0;
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;
+ spin_lock(&tdev->object_lock);
(void)drm_ht_remove_item(&tdev->object_hash, &base->hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (base->refcount_release) {
ttm_object_file_unref(&base->tfile);
base->refcount_release(&base);
}
- write_lock(&tdev->object_lock);
}
void ttm_base_object_unref(struct ttm_base_object **p_base)
{
struct ttm_base_object *base = *p_base;
- struct ttm_object_device *tdev = base->tfile->tdev;
*p_base = NULL;
- /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
- write_lock(&tdev->object_lock);
kref_put(&base->refcount, ttm_release_base);
- write_unlock(&tdev->object_lock);
}
EXPORT_SYMBOL(ttm_base_object_unref);
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
- read_lock(&tdev->object_lock);
+ rcu_read_lock();
ret = drm_ht_find_item(&tdev->object_hash, key, &hash);
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
- kref_get(&base->refcount);
+ ret = kref_get_unless_zero(&base->refcount);
}
- read_unlock(&tdev->object_lock);
+ rcu_read_unlock();
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct
ttm_mem_global
return NULL;
tdev->mem_glob = mem_glob;
- rwlock_init(&tdev->object_lock);
+ spin_lock_init(&tdev->object_lock);
atomic_set(&tdev->object_count, 0);
ret = drm_ht_create(&tdev->object_hash, hash_order);
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device
**p_tdev)
*p_tdev = NULL;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
drm_ht_remove(&tdev->object_hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
kfree(tdev);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;
- kfree(ctx);
+ ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
}
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
- kfree(user_srf);
+ ttm_base_object_kfree(user_srf, base);
ttm_mem_global
[PATCH 4/4] drm/ttm: Optimize reservation slightly
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo->glob;
int ret;
- while (unlikely(atomic_cmpxchg(&bo->reserved, 0, 1) != 0)) {
+ while (unlikely(atomic_read(&bo->reserved) != 0)) {
/**
* Deadlock avoidance for multi-bo reserving.
*/
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}
+ atomic_set(&bo->reserved, 1);
if (use_sequence) {
/**
* Wake up waiters that may need to recheck for deadlock,
--
1.7.4.4
[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups
On 11/05/2012 02:31 PM, Thomas Hellstrom wrote:
> The mostly used lookup+get put+potential_destroy path of TTM objects
> is converted to use RCU locks. This will substantially decrease the amount
> of locked bus cycles during normal operation.
> Since we use kfree_rcu to free the objects, no rcu synchronization is needed
> at module unload time.
>
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_object.c | 30
> +++---
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
> include/drm/ttm/ttm_object.h |4
> include/linux/kref.h |2 +-
> 4 files changed, 20 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_object.c
> b/drivers/gpu/drm/ttm/ttm_object.c
> index c785787..9d7f674 100644
> --- a/drivers/gpu/drm/ttm/ttm_object.c
> +++ b/drivers/gpu/drm/ttm/ttm_object.c
> @@ -80,7 +80,7 @@ struct ttm_object_file {
>*/
>
> struct ttm_object_device {
> - rwlock_t object_lock;
> + spinlock_t object_lock;
> struct drm_open_hash object_hash;
> atomic_t object_count;
> struct ttm_mem_global *mem_glob;
> @@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
> base->refcount_release = refcount_release;
> base->ref_obj_release = ref_obj_release;
> base->object_type = object_type;
> - write_lock(&tdev->object_lock);
> + spin_lock(&tdev->object_lock);
> kref_init(&base->refcount);
> ret = drm_ht_just_insert_please(&tdev->object_hash,
> &base->hash,
> (unsigned long)base, 31, 0, 0);
> - write_unlock(&tdev->object_lock);
> + spin_unlock(&tdev->object_lock);
> if (unlikely(ret != 0))
> goto out_err0;
>
> @@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
> container_of(kref, struct ttm_base_object, refcount);
> struct ttm_object_device *tdev = base->tfile->tdev;
>
> + spin_lock(&tdev->object_lock);
> (void)drm_ht_remove_item(&tdev->object_hash, &base->hash);
> - write_unlock(&tdev->object_lock);
> + spin_unlock(&tdev->object_lock);
> if (base->refcount_release) {
> ttm_object_file_unref(&base->tfile);
> base->refcount_release(&base);
> }
> - write_lock(&tdev->object_lock);
> }
>
> void ttm_base_object_unref(struct ttm_base_object **p_base)
> {
> struct ttm_base_object *base = *p_base;
> - struct ttm_object_device *tdev = base->tfile->tdev;
>
> *p_base = NULL;
>
> - /*
> - * Need to take the lock here to avoid racing with
> - * users trying to look up the object.
> - */
> -
> - write_lock(&tdev->object_lock);
> kref_put(&base->refcount, ttm_release_base);
> - write_unlock(&tdev->object_lock);
> }
> EXPORT_SYMBOL(ttm_base_object_unref);
>
> @@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct
> ttm_object_file *tfile,
> struct drm_hash_item *hash;
> int ret;
>
> - read_lock(&tdev->object_lock);
> + rcu_read_lock();
> ret = drm_ht_find_item(&tdev->object_hash, key, &hash);
>
> if (likely(ret == 0)) {
> base = drm_hash_entry(hash, struct ttm_base_object, hash);
> - kref_get(&base->refcount);
> + ret = kref_get_unless_zero(&base->refcount);
> }
> - read_unlock(&tdev->object_lock);
> + rcu_read_unlock();
>
> if (unlikely(ret != 0))
> return NULL;
> @@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct
> ttm_mem_global
> return NULL;
>
> tdev->mem_glob = mem_glob;
> - rwlock_init(&tdev->object_lock);
> + spin_lock_init(&tdev->object_lock);
> atomic_set(&tdev->object_count, 0);
> ret = drm_ht_create(&tdev->object_hash, hash_order);
>
> @@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device
> **p_tdev)
>
> *p_tdev = NULL;
>
> - write_lock(&tdev->object_lock);
> + spin_lock(&tdev->object_lock);
> drm_ht_remove(&tdev->object_hash);
> - write_unlock(&tdev->object_lock);
> + spin_unlock(&tdev->object_lock);
>
> kfree(tdev);
> }
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> index da3c6b5..ae675c6 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> @@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource
> *res)
> container_of(res, struct vmw_user_context, res);
> struct vmw_private *dev_priv = res->dev_priv;
>
> - kfree(ctx);
> + ttm_base_object_kfree(ctx, base);
> ttm_mem_global_free(vmw_mem_glob(dev_priv),
> vmw_user_context_size);
> }
> @@ -1147,7 +1147,7 @@ static void vmw_user_surf
[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops v2
A patch series for next that removes a substantial number of read-modify-write operations from TTM command submission, in particular if TTM objects are used to export objects to user-space. The only per-object atomic r-m-w operations left during a typical execbuf call should be refcount up and down. v2: Formatting fixes. In-Reply-To: >From Thomas Hellstrom # This line is ignored. From: Thomas Hellstrom Subject: In-Reply-To:
[PATCH 1/4] drm: Make hashtab rcu-safe
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned
long key)
hashed_key = hash_long(key, ht->order);
DRM_DEBUG("Key is 0x%08lx, Hashed key is 0x%08x\n", key, hashed_key);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG("count %d, key: 0x%08lx\n", count++, entry->key);
- }
}
static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct
drm_open_hash *ht,
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return list;
if (entry->key > key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
hashed_key = hash_long(key, ht->order);
h_list = &ht->table[hashed_key];
parent = NULL;
- hlist_for_each(list, h_list) {
- entry = hlist_entry(list, struct drm_hash_item, head);
+ hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return -EINVAL;
if (entry->key > key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct
drm_hash_item *item)
parent = list;
}
if (parent) {
- hlist_add_after(parent, &item->head);
+ hlist_add_after_rcu(parent, &item->head);
} else {
- hlist_add_head(&item->head, h_list);
+ hlist_add_head_rcu(&item->head, h_list);
}
return 0;
}
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
list = drm_ht_find_key(ht, key);
if (list) {
- hlist_del_init(list);
+ hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned
long key)
int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
{
- hlist_del_init(&item->head);
+ hlist_del_init_rcu(&item->head);
return 0;
}
EXPORT_SYMBOL(drm_ht_remove_item);
--
1.7.4.4
[PATCH 2/4] kref: Implement kref_get_unless_zero v2
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.
v2: Formatting fixes.
Signed-off-by: Thomas Hellstrom
---
include/linux/kref.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..bae91d0 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
}
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return 0 if the increment succeeded. Otherwise return non-zero.
+ *
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+ return !atomic_add_unless(&kref->refcount, 1, 0);
+}
#endif /* _KREF_H_ */
--
1.7.4.4
[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v2
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
v2: Don't touch include/linux/kref.h
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm/ttm_object.h |4
3 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..9d7f674 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
*/
struct ttm_object_device {
- rwlock_t object_lock;
+ spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
kref_init(&base->refcount);
ret = drm_ht_just_insert_please(&tdev->object_hash,
&base->hash,
(unsigned long)base, 31, 0, 0);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (unlikely(ret != 0))
goto out_err0;
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;
+ spin_lock(&tdev->object_lock);
(void)drm_ht_remove_item(&tdev->object_hash, &base->hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
if (base->refcount_release) {
ttm_object_file_unref(&base->tfile);
base->refcount_release(&base);
}
- write_lock(&tdev->object_lock);
}
void ttm_base_object_unref(struct ttm_base_object **p_base)
{
struct ttm_base_object *base = *p_base;
- struct ttm_object_device *tdev = base->tfile->tdev;
*p_base = NULL;
- /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
- write_lock(&tdev->object_lock);
kref_put(&base->refcount, ttm_release_base);
- write_unlock(&tdev->object_lock);
}
EXPORT_SYMBOL(ttm_base_object_unref);
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
- read_lock(&tdev->object_lock);
+ rcu_read_lock();
ret = drm_ht_find_item(&tdev->object_hash, key, &hash);
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
- kref_get(&base->refcount);
+ ret = kref_get_unless_zero(&base->refcount);
}
- read_unlock(&tdev->object_lock);
+ rcu_read_unlock();
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct
ttm_mem_global
return NULL;
tdev->mem_glob = mem_glob;
- rwlock_init(&tdev->object_lock);
+ spin_lock_init(&tdev->object_lock);
atomic_set(&tdev->object_count, 0);
ret = drm_ht_create(&tdev->object_hash, hash_order);
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device
**p_tdev)
*p_tdev = NULL;
- write_lock(&tdev->object_lock);
+ spin_lock(&tdev->object_lock);
drm_ht_remove(&tdev->object_hash);
- write_unlock(&tdev->object_lock);
+ spin_unlock(&tdev->object_lock);
kfree(tdev);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;
- kfree(ctx);
+ ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
}
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
- kfree(user_srf);
+ ttm_base_object_kfree(user_srf, base);
ttm_mem_global_free(vmw_mem_
[PATCH 4/4] drm/ttm: Optimize reservation slightly
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo->glob;
int ret;
- while (unlikely(atomic_cmpxchg(&bo->reserved, 0, 1) != 0)) {
+ while (unlikely(atomic_read(&bo->reserved) != 0)) {
/**
* Deadlock avoidance for multi-bo reserving.
*/
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}
+ atomic_set(&bo->reserved, 1);
if (use_sequence) {
/**
* Wake up waiters that may need to recheck for deadlock,
--
1.7.4.4
[PATCH 4/4] drm/ttm: Optimize reservation slightly
Hey,
Op 05-11-12 14:31, Thomas Hellstrom schreef:
> Reservation locking currently always takes place under the LRU spinlock.
> Hence, strictly there is no need for an atomic_cmpxchg call; we can use
> atomic_read followed by atomic_write since nobody else will ever reserve
> without the lru spinlock held.
> At least on Intel this should remove a locked bus cycle on successful
> reserve.
>
> Signed-off-by: Thomas Hellstrom
>
Is that really a good thing to submit when I am busy killing lru lock around
reserve? :-)
- while (unlikely(atomic_cmpxchg(&bo->reserved, 0, 1) != 0)) {
+ while (unlikely(atomic_xchg(&bo->reserved, 1) != 0)) {
Works without lru lock too!
In fact mutexes are done in a similar way[1], except with some more magic, and
unlocked state is 1, not 0.
However I do think that to get that right (saves a irq disable in unlock path,
and less wakeups in contended
case), I should really just post the mutex extension patches for reservations
and ride the flames. It's
getting too close to real mutexes so I really want it to be a mutex in that
case. So lets convert it.. Soon! :-)
~Maarten
[1] See linux/include/asm-generic/mutex-xchg.h and
linux/include/asm-generic/mutex-dec.h for how
archs generally implement mutex fastpaths.
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #12 from Alex Deucher --- (In reply to comment #11) > Found what is wrong with the help of a few printk and by comparing to the > code being replaced. All the logic is good (going through crtc, disabling > them, waiting for vblank) BUT setting "tmp |= > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. > > If I do as in the previous code by setting tmp = 0 and then continuing with: > radeon_wait_for_vblank(rdev, i); > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); > everything works fine as before. > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? > From what I read with printk, it is far from a 0 or a 1. Is this normal? That's the most important bit in the entire sequence. It's a bit field in a register (bit 24 to be exact). That bit is the bit that actually disables the requests from the display controller in the memory controller. The whole point of this code is to disable all clients of the memory controller (mc_stop()) so that we can change the location of vram within the GPU's address space. Once we've moved vram, we can re-enable the clients (mc_resume()) so that they point to the new vram location. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/f777c29e/attachment.html>
[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
This patch is having dependency on linux-samsung-soc patchset named
"add dt based support for iommu for hdmi"
Signed-off-by: Rahul Sharma
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d1a1d71..ee110c9 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
}
#ifdef CONFIG_OF
+
+static int drm_hdmi_dt_init_iommu(struct device *dev)
+{
+ struct platform_device *pds;
+ struct device_node *dn, *dns;
+ const __be32 *parp;
+
+ dn = dev->of_node;
+ parp = of_get_property(dn, "sysmmu", NULL);
+ if (parp == NULL) {
+ dev_err(dev, "failed to find sysmmu property\n");
+ return -EINVAL;
+ }
+ dns = of_find_node_by_phandle(be32_to_cpup(parp));
+ if (dns == NULL) {
+ dev_err(dev, "failed to find sysmmu node\n");
+ return -EINVAL;
+ }
+ pds = of_find_device_by_node(dns);
+ if (pds == NULL) {
+ dev_err(dev, "failed to find sysmmu platform device\n");
+ return -EINVAL;
+ }
+
+ platform_set_sysmmu(&pds->dev, dev);
+ return 0;
+}
+
static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
{
@@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
goto err_data;
}
+ if (drm_hdmi_dt_init_iommu(dev)){
+ DRM_ERROR("no sysmmu property found\n");
+ goto err_data;
+ }
+
pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
return pd;
--
1.7.0.4
[PATCH 4/4] drm/ttm: Optimize reservation slightly
On 11/05/2012 03:01 PM, Maarten Lankhorst wrote: > Hey, > > Op 05-11-12 14:31, Thomas Hellstrom schreef: >> Reservation locking currently always takes place under the LRU spinlock. >> Hence, strictly there is no need for an atomic_cmpxchg call; we can use >> atomic_read followed by atomic_write since nobody else will ever reserve >> without the lru spinlock held. >> At least on Intel this should remove a locked bus cycle on successful >> reserve. >> >> Signed-off-by: Thomas Hellstrom >> > Is that really a good thing to submit when I am busy killing lru lock around > reserve? :-) > If your patch series makes it into the same kernel, let's kill this patch. Otherwise it may live at least for a kernel release. It's not a big thing to rebase against, and I won't complain if your patch adds another atomic read-modify-write op here. :) /Thomas
[Bug 49981] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugzilla.kernel.org/show_bug.cgi?id=49981 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(Other)|Video(DRI - non Intel) AssignedTo|drivers_video-other at kernel- |drivers_video-dri at kernel-bu |bugs.osdl.org |gs.osdl.org -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50
https://bugzilla.kernel.org/show_bug.cgi?id=16193 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk --- Comment #2 from Alan 2012-11-05 14:16:22 --- Closing as obsolete. If this is still seen on modern kernels (3.2+) please update/reopen -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 16193] NULL pointer dereference - radeon_unmap_vram_bos+0x22/0x50
https://bugzilla.kernel.org/show_bug.cgi?id=16193 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||OBSOLETE -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 16065] linux 2.6.34 keeps ranting that it can't retrieve EDID from my old LCD monitor.
https://bugzilla.kernel.org/show_bug.cgi?id=16065 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 1/1] drm: exynos: fix for mapping contigous dma buffers
2012. 11. 3. ?? 9:21 Rahul Sharma ??:
> This patch fixes the problem of mapping contigous dma buffers. Currently page
> struct is calculated from the buf->dma_addr which is not the physical address.
> It is replaced by buf->pages which points to the page struct of the first page
> of contigous memory chunk. This gives the correct page frame number for
> mapping.
>
> Signed-off-by: Rahul Sharma
> ---
> drivers/gpu/drm/exynos/exynos_drm_gem.c |8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index c557ac7..50d73f1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -120,8 +120,12 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object
> *obj,
>}
>
>pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
> -} else
> -pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
> +} else {
> +if (!buf->pages)
> +return -EINTR;
> +
> +pfn = page_to_pfn(buf->pages[0]) + page_offset;
> +}
Is there any reason you are sending patches respectively? It's better to
combine them.
Thanks,
Inki Dae
>
>return vm_insert_mixed(vma, f_vaddr, pfn);
> }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 17511] Display no longer works with KMS enabled
https://bugzilla.kernel.org/show_bug.cgi?id=17511 Alan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INSUFFICIENT_DATA -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #13 from Alex Deucher --- Created attachment 69564 --> https://bugs.freedesktop.org/attachment.cgi?id=69564&action=edit possible fix Slightly adjusted wait for vblank function. Maybe this will help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/42dbed96/attachment.html>
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #14 from Alexandre Demers --- (In reply to comment #12) > (In reply to comment #11) > > Found what is wrong with the help of a few printk and by comparing to the > > code being replaced. All the logic is good (going through crtc, disabling > > them, waiting for vblank) BUT setting "tmp |= > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. > > > > If I do as in the previous code by setting tmp = 0 and then continuing with: > > radeon_wait_for_vblank(rdev, i); > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); > > everything works fine as before. > > > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? > > From what I read with printk, it is far from a 0 or a 1. Is this normal? > > That's the most important bit in the entire sequence. It's a bit field in a > register (bit 24 to be exact). That bit is the bit that actually disables > the requests from the display controller in the memory controller. The > whole point of this code is to disable all clients of the memory controller > (mc_stop()) so that we can change the location of vram within the GPU's > address space. Once we've moved vram, we can re-enable the clients > (mc_resume()) so that they point to the new vram location. Thank you, you confirmed what I had assumed. I had already understood that it was the most important part in the sequence since it is associated to a "write" instruction. I don't have the (decimal/binary) values with me right now, but I'll be able to give you what was read from the register and from the result returned from the bitwise OR assignment we are pushing in the register. I'll confirm which bit(s) are changing. I'm sure the assignment was setting one (or more) bit in the register to "1". Is bit 24 the only one expected to change in the register? Should it be put to "1" or "0"? Another question: why were we setting "0" in the register before? By doing so, we were setting the whole register to "0" (the whole 32 bits), right? If I remember correctly, from what I saw yesterday with the help of printk, it seems we are setting at least one bit to "1" in this register, which would be the opposite of what was being done before and therefore of what was working correctly with my video card. I'm just trying to understand why we were doing something in the first place that was working correctly and that was introduce to fix this problem in the first place, both at boot time for grub (set gfxpayload=keep) and when suspending/resuming, and we are now doing the opposite, thus breaking the code for some setups. Is it possible that the bit/register logic is not the same for all Radeon GPUs? After all, we already introduced a different path for DCE6. I'll also try your patch when I'll get home tonight. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/c151856a/attachment.html>
[PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled
This patch adds iommu support for hdmi driver with device tree based
search. It searches for sysmmu property in hdmi dt node to get tv
iommu device pointer which will be used to configure iommu hw interface.
This patch is based on "exynos-drm-next-iommu" branch at
http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git
This patch is having dependency on linux-samsung-soc patchset posted at
http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/13556
Signed-off-by: Rahul Sharma
Signed-off-by: Prathyush K
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 35 ++
1 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d1a1d71..a04452c 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -34,7 +34,9 @@
#include
#include
#include
+#include
#include
+#include
#include
@@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client
*hdmiphy)
}
#ifdef CONFIG_OF
+
+static int drm_hdmi_dt_init_iommu(struct device *dev)
+{
+ struct platform_device *pds;
+ struct device_node *dn, *dns;
+ const __be32 *parp;
+
+ dn = dev->of_node;
+ parp = of_get_property(dn, "sysmmu", NULL);
+ if (parp == NULL) {
+ dev_err(dev, "failed to find sysmmu property\n");
+ return -EINVAL;
+ }
+ dns = of_find_node_by_phandle(be32_to_cpup(parp));
+ if (dns == NULL) {
+ dev_err(dev, "failed to find sysmmu node\n");
+ return -EINVAL;
+ }
+ pds = of_find_device_by_node(dns);
+ if (pds == NULL) {
+ dev_err(dev, "failed to find sysmmu platform device\n");
+ return -EINVAL;
+ }
+
+ platform_set_sysmmu(&pds->dev, dev);
+ return 0;
+}
+
static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
(struct device *dev)
{
@@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data
*drm_hdmi_dt_parse_pdata
goto err_data;
}
+ if (drm_hdmi_dt_init_iommu(dev)) {
+ DRM_ERROR("no sysmmu property found\n");
+ goto err_data;
+ }
+
pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
return pd;
--
1.7.0.4
[PATCH] drm: exynos: fix for mapping of dma buffers
This patch fixes the problem of mapping contigous and non contigous dma buffers.
Currently page struct is calculated from the buf->dma_addr which is not the
physical address. It is replaced by buf->pages which points to the page struct
of the first page of contigous memory chunk. This gives the correct page frame
number for mapping.
Non-contigous dma buffers are described using SG table and SG lists. Each
valid SG List is pointing to a single page or group of pages which are
physically contigous. Current implementation just maps the first page of each
SG List and leave the other pages unmapped, leading to a crash. Given solution
finds the page struct for the faulting page through parsing SG table and map it.
Signed-off-by: Rahul Sharma
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 28 +---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 8cb6824..50d73f1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -95,15 +95,37 @@ static int exynos_drm_gem_map_buf(struct drm_gem_object
*obj,
{
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
+ struct scatterlist *sgl;
unsigned long pfn;
+ int i;
if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
+ if (!buf->sgt)
+ return -EINTR;
+
+ sgl = buf->sgt->sgl;
+ for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
+ if (!sgl) {
+ DRM_ERROR("invalid SG table\n");
+ return -EINTR;
+ }
+ if (page_offset < (sgl->length >> PAGE_SHIFT))
+ break;
+ page_offset -= (sgl->length >> PAGE_SHIFT);
+ }
+
+ if (i >= buf->sgt->nents) {
+ DRM_ERROR("invalid page offset\n");
+ return -EINVAL;
+ }
+
+ pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
+ } else {
if (!buf->pages)
return -EINTR;
- pfn = page_to_pfn(buf->pages[page_offset++]);
- } else
- pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
+ pfn = page_to_pfn(buf->pages[0]) + page_offset;
+ }
return vm_insert_mixed(vma, f_vaddr, pfn);
}
--
1.7.0.4
Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote: > Alex Deucher wrote: >> >> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: >>> >>> For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 >>> and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off >>> and then turn TV on and - >>> >>> xrandr --output DVI-0 --auto >>> >>> to bring up the the TV and get a clone of monitor. >>> >>> This still works with drm-core-next but not with drm-fixes (todays or >>> from a >>> few days ago). >>> >>> With df I now loose the monitor with signal out of range when doing >>> above, >>> the TV output is OK. To get the monitor back I need to turn off TV, then >>> off/auto the monitor. >>> >>> xrandr --output DVI-0 --off >>> xrandr --output DVI-1 --off >>> xrandr --output DVI-1 --auto >>> >>> The output from xrandr while the monitor is showing signal out of range >>> looks normal. >>> >>> If I boot with the TV on it works OK. >> >> >> Can you bisect? > > > 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit > commit 29dbe3bcd2e28e71823febdca989d63d5c27d152 > Author: Alex Deucher > Date: Fri Oct 5 10:22:02 2012 -0400 > > drm/radeon: allocate PPLLs from low to high > > The order shouldn't matter, but there have been problems > reported on certain older asics. This behaves more > like the original code before the PPLL allocation > rework. > > Signed-off-by: Alex Deucher > Cc: Markus Trippelsdorf > > That's bizarre. That patch reverts the behavior back to the 3.6 and earlier kernel behavior. I guess it's some issue with the ordering of the modesetting programming sequence. I've attached a couple of things to try. The first patch is a simple fix. It just reverts back to the previous pll allocation order for discrete cards like yours: 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch The second set of patches implements a more complex fix which may help regardless of the order in which plls are allocated: 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch 0003-drm-radeon-disable-the-pll-before-a-modeset.patch Can you see if the second set helps? If not, please try the first patch. Alex -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch Type: text/x-patch Size: 3153 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment.bin> -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch Type: text/x-patch Size: 3600 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0001.bin> -- next part -- A non-text attachment was scrubbed... Name: 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch Type: text/x-patch Size: 3166 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0002.bin> -- next part -- A non-text attachment was scrubbed... Name: 0003-drm-radeon-disable-the-pll-before-a-modeset.patch Type: text/x-patch Size: 910 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/4eee7cd3/attachment-0003.bin>
nouveau, linux3.7-rc3: BUG: unable to handle kernel paging request at fffffffffffffff8
On Mon, 5 Nov 2012 08:40:38 + Dave Airlie wrote: > On Mon, Nov 5, 2012 at 8:29 AM, Antonio Ospite > wrote: > > On Mon, 29 Oct 2012 23:16:24 +0100 > > Antonio Ospite wrote: > > > >> Hi, > >> > >> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1), > >> my video adapter is the one integrated on the MSI M3N78-VM motherboard > >> (hence x86_64): > >> > > [...] > >> [ 1943.858601] BUG: unable to handle kernel paging request at > >> fff8 > >> [ 1943.858669] IP: [] nouveau_mm_head+0x30/0x127 > >> [nouveau] > >> [ 1943.858779] PGD 160d067 PUD 160e067 PMD 0 > >> [ 1943.858803] Oops: [#1] SMP > > [..] > >> [ 1943.860018] Call Trace: > >> [ 1943.860019] [] ? kmem_cache_alloc_trace+0xbf/0xcf > >> [ 1943.860019] [] ? should_resched+0x5/0x23 > >> [ 1943.860019] [] ? nv50_fb_vram_new+0xc5/0x1f2 > >> [nouveau] > > > > Ben, I cannot reproduce the crash with 3.7-rc4, I spotted commits > > a7dbf00 and 5cad16a which seem to be related to the problem I was > > having; would you mind elaborating a bit about what you think was > > causing the crash on my side? Maybe the chipset used on this motherboard > > doesn't support some feature? And how did you figured out from the logs? > > > > 5cad16acd25b16681a060d28d10eeacf98d07701 is the actual fix > > The chipset hasn't got Z compression support, and the oops once decoded > pointed > out the new code was trying to allocate Z tags from a NULL memory block. The > old > code use to allocate an empty memory block instead of NULL, and it got > lost in the > rewrite, Ben just fixed it to allow empty memory blocks again. > > Dave. > Thanks a lot for the explanation. Regards, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #15 from Alex Deucher --- (In reply to comment #14) > (In reply to comment #12) > > (In reply to comment #11) > > > Found what is wrong with the help of a few printk and by comparing to the > > > code being replaced. All the logic is good (going through crtc, disabling > > > them, waiting for vblank) BUT setting "tmp |= > > > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong. > > > > > > If I do as in the previous code by setting tmp = 0 and then continuing > > > with: > > > radeon_wait_for_vblank(rdev, i); > > > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp); > > > everything works fine as before. > > > > > > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"? > > > From what I read with printk, it is far from a 0 or a 1. Is this normal? > > > > That's the most important bit in the entire sequence. It's a bit field in a > > register (bit 24 to be exact). That bit is the bit that actually disables > > the requests from the display controller in the memory controller. The > > whole point of this code is to disable all clients of the memory controller > > (mc_stop()) so that we can change the location of vram within the GPU's > > address space. Once we've moved vram, we can re-enable the clients > > (mc_resume()) so that they point to the new vram location. > > Thank you, you confirmed what I had assumed. I had already understood that > it was the most important part in the sequence since it is associated to a > "write" instruction. I don't have the (decimal/binary) values with me right > now, but I'll be able to give you what was read from the register and from > the result returned from the bitwise OR assignment we are pushing in the > register. I'll confirm which bit(s) are changing. I'm sure the assignment > was setting one (or more) bit in the register to "1". Is bit 24 the only one > expected to change in the register? Should it be put to "1" or "0"? > Setting bit 24 to 1 disables memory requests from the display controller. Setting bit 24 to 0, enables memory requests from the display controller. > Another question: why were we setting "0" in the register before? By doing > so, we were setting the whole register to "0" (the whole 32 bits), right? If > I remember correctly, from what I saw yesterday with the help of printk, it > seems we are setting at least one bit to "1" in this register, which would > be the opposite of what was being done before and therefore of what was > working correctly with my video card. I'm just trying to understand why we > were doing something in the first place that was working correctly and that > was introduce to fix this problem in the first place, both at boot time for > grub (set gfxpayload=keep) and when suspending/resuming, and we are now > doing the opposite, thus breaking the code for some setups. Is it possible > that the bit/register logic is not the same for all Radeon GPUs? After all, > we already introduced a different path for DCE6. Bit 0 for CRTC_CONTROL turns on/off the entire crtc. If bit 0 is 0 the crtc is disabled. If bit 0 is 1, the crtc is enabled. If the crtc is disabled (bit 0 = 0) bit 24 is irrelevant. There are separate bits to enable the crtc and disable memory requests since there are cases (like this one) where we want to keep the crtc timing running so that the monitor stays synced, but disable reads from memory so we can reconfigure the memory controller. If we disable the crtc entirely, the monitor would lose sync and you would get additional flicker during boot up. Ideally, eventually we'd like to just hand over control from the firmware without touching the display hardware so the user gets a flicker free boot experience. DCE4 and 5 have the same logic and bit layout for these registers. The logic is different on DCE6 chips. On DCE6, the the memory controller request bit is now tied in with the crtc blanking bit. When the crtc is blanked, memory requests are also disabled. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/f62d09d7/attachment.html>
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #16 from Alex Deucher --- Created attachment 69573 --> https://bugs.freedesktop.org/attachment.cgi?id=69573&action=edit possible fix Actually, I think I found the problem. Missing index in mc_resume(). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/ce8d9998/attachment.html>
[PATCH] drm/radeon: fix typo in evergreen_mc_resume()
From: Alex Deucher
Add missing index that may have led us to enabling
more crtcs than necessary.
May also fix:
https://bugs.freedesktop.org/show_bug.cgi?id=56139
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 14313ad..af31f82 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1372,7 +1372,7 @@ void evergreen_mc_resume(struct radeon_device *rdev,
struct evergreen_mc_save *s
WREG32(BIF_FB_EN, FB_READ_EN | FB_WRITE_EN);
for (i = 0; i < rdev->num_crtc; i++) {
- if (save->crtc_enabled) {
+ if (save->crtc_enabled[i]) {
if (ASIC_IS_DCE6(rdev)) {
tmp = RREG32(EVERGREEN_CRTC_BLANK_CONTROL +
crtc_offsets[i]);
tmp |= EVERGREEN_CRTC_BLANK_DATA_EN;
--
1.7.7.5
Radeon monitor + hdmi TV regression between drm-core-next and drm-fixes
Alex Deucher wrote: > On Sun, Nov 4, 2012 at 4:00 PM, Andy Furniss wrote: >> Alex Deucher wrote: >>> >>> On Sun, Nov 4, 2012 at 10:27 AM, Andy Furniss wrote: For the last 2 years when running a DVI 60Hz monitor with a radeon HD4890 and a (native 50Hz) HDMI TV I've been able to boot/startx with the TV off and then turn TV on and - xrandr --output DVI-0 --auto to bring up the the TV and get a clone of monitor. This still works with drm-core-next but not with drm-fixes (todays or from a few days ago). With df I now loose the monitor with signal out of range when doing above, the TV output is OK. To get the monitor back I need to turn off TV, then off/auto the monitor. xrandr --output DVI-0 --off xrandr --output DVI-1 --off xrandr --output DVI-1 --auto The output from xrandr while the monitor is showing signal out of range looks normal. If I boot with the TV on it works OK. >>> >>> >>> Can you bisect? >> >> >> 29dbe3bcd2e28e71823febdca989d63d5c27d152 is the first bad commit >> commit 29dbe3bcd2e28e71823febdca989d63d5c27d152 >> Author: Alex Deucher >> Date: Fri Oct 5 10:22:02 2012 -0400 >> >> drm/radeon: allocate PPLLs from low to high >> >> The order shouldn't matter, but there have been problems >> reported on certain older asics. This behaves more >> like the original code before the PPLL allocation >> rework. >> >> Signed-off-by: Alex Deucher >> Cc: Markus Trippelsdorf >> >> > > That's bizarre. That patch reverts the behavior back to the 3.6 and > earlier kernel behavior. I guess it's some issue with the ordering of > the modesetting programming sequence. I've attached a couple of > things to try. > > The first patch is a simple fix. It just reverts back to the previous > pll allocation order for discrete cards like yours: > 0001-drm-radeon-dce3-switch-back-to-old-pll-allocation-or.patch > > The second set of patches implements a more complex fix which may help > regardless of the order in which plls are allocated: > 0001-drm-radeon-split-out-the-pll-disable-into-a-helper-f.patch > 0002-drm-radeon-add-a-helper-to-check-if-a-pll-is-shared.patch > 0003-drm-radeon-disable-the-pll-before-a-modeset.patch > > Can you see if the second set helps? If not, please try the first patch. The second set doesn't fix it. The first patch does.
[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 Tony Thomas changed: What|Removed |Added Attachment #68684|0 |1 is obsolete|| Attachment #68717|0 |1 is obsolete|| --- Comment #8 from Tony Thomas --- Created attachment 69579 --> https://bugs.freedesktop.org/attachment.cgi?id=69579&action=edit Debian Sid w/3.6.8-pf dmesg (drm.debug=6) Switched system to Debian Sid, clean install. Sid is tracking 8.0.5-1 mesa http://packages.debian.org/search?keywords=mesa&searchon=names&suite=unstable§ion=all Screen corruption still, using Sid 3.2.0-4 stock kernel, and 3.6.8-pf kernel from here: http://kernel.night-leshiy.ru/ Attaching drm.debug=6 dmesg from Debian 3.6.8-pf kernel -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/23436beb/attachment.html>
[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 Tony Thomas changed: What|Removed |Added Attachment #68713|0 |1 is obsolete|| --- Comment #9 from Tony Thomas --- Created attachment 69580 --> https://bugs.freedesktop.org/attachment.cgi?id=69580&action=edit Debian Sid w/3.6.8-pf xorg.0.log (fail) Xorg.0.log from above failure (Debian Sid, 3.6.8-pf kernel) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/3a4df1cb/attachment-0001.html>
[Bug 56081] (SUMO2) Black screen on X Launch, corrupted VTs when using KMS
https://bugs.freedesktop.org/show_bug.cgi?id=56081 --- Comment #10 from Tony Thomas --- Of note: with most kernel combo and 8.0 mesa branch (also tried on Arch Linux), failures and corruption DO NOT prevent VT-switching as the 9.0 branch does. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/a08cad9d/attachment.html>
[Bug 53130] 99c65ba breaks rendering (flickery, eventual fail)
https://bugs.freedesktop.org/show_bug.cgi?id=53130 --- Comment #3 from Darren Salt --- I've rebuilt mesa with this re-enabled and I saw a lot of rendering glitches. I suspect that DISCARD_RANGE being re-enabled is the problem, although I've also built and installed an updated xf86-video-ati (cdf522f?20bfc65). My current mesa build has 1eedebc reverted; I'll re-check with that undone later. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/48a9a737/attachment.html>
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #17 from Alexandre Demers --- I'm about to test patches. But before, as promised, here are the values retrieved read and written to the registers. By the way, I have only a single monitor. tmp = RREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i]); -> 272696081 (0001 0100 0001 0011 0001 0001) tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE; -> 289473297 (0001 0001 0100 0001 0011 0001 0001) So, it is set as you explained me earlier. I'll be back soon with some news from the patches. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/b3edd9fd/attachment.html>
[Bug 56788] New: [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"
https://bugs.freedesktop.org/show_bug.cgi?id=56788 Priority: medium Bug ID: 56788 Assignee: dri-devel at lists.freedesktop.org Summary: [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders" Severity: normal Classification: Unclassified OS: All Reporter: emil.l.velikov at gmail.com Hardware: Other Status: NEW Version: unspecified Component: Drivers/DRI/Radeon Product: Mesa Created attachment 69589 --> https://bugs.freedesktop.org/attachment.cgi?id=69589&action=edit Untrimmed stdout & stderr As of approx 1 Nov 2012, Dota2 crashes while playing/spectating a game Initially I was suspecting the recent vbo work by Marek, although I'm leaning towards memory bug/buggy shader in one of the Dota2 3 updates - 29,30 and 1 Nov Cannot downgrade to verify, although backtrace does point that the crash occurs after the above message is printed to stderr Brief list of the other messages printed to strout & strerr WARNING: value %35 not uniquely defined ... WARNING: value %277 not uniquely defined WARNING: value %17 not uniquely defined context mis-match in pipe_sampler_view_release() WARNING: value %28 not uniquely defined ... WARNING: value %17 not uniquely defined WARNING: out of code space, evicting all shaders. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/15747cc0/attachment.html>
[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"
https://bugs.freedesktop.org/show_bug.cgi?id=56788 --- Comment #1 from Emil Velikov --- Created attachment 69590 --> https://bugs.freedesktop.org/attachment.cgi?id=69590&action=edit Wine backtrace -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/39e5eb6a/attachment.html>
[Bug 56788] [nv96] Dota2 (wine) consistently crashes with "WARNING: out of code space, evicting all shaders"
https://bugs.freedesktop.org/show_bug.cgi?id=56788 Emil Velikov changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |nouveau at lists.freedesktop.o |.org|rg Component|Drivers/DRI/Radeon |Drivers/DRI/nouveau --- Comment #2 from Emil Velikov --- Correcting component -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/7015d7ee/attachment.html>
[Bug 48941] Error creating '/sys/class/backlight/radeon_bl' in radeon_atom_backlight_init()
https://bugzilla.kernel.org/show_bug.cgi?id=48941 Florian Mickler changed: What|Removed |Added CC||florian at mickler.org --- Comment #7 from Florian Mickler 2012-11-05 23:15:22 --- A patch referencing this bug report has been merged in Linux v3.7-rc3: commit 614499b4d844dcceae5ae2f1e53a2963789a8933 Author: Alex Deucher Date: Wed Oct 17 17:20:24 2012 -0400 drm/radeon: give each backlight a unique id -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
