From: Rob Clark <r...@ti.com>
omap_gem_roll() could be called by fbcon in atomic context or when
struct_mutext is held. Avoid aquiring mutex (deadlock), or calling
tiler_pin() (which itself is not safe for atomic context) in these
cases.
Signed-off-by: Rob Clark <r...@ti.com>
---
drivers/staging/omapdrm/omap_gem.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_gem.c
b/drivers/staging/omapdrm/omap_gem.c
index 9684891..63490f7 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -538,10 +538,22 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t
roll)
return -EINVAL;
}
- mutex_lock(&obj->dev->struct_mutex);
-
omap_obj->roll = roll;
+ if (in_atomic() || mutex_is_locked(&obj->dev->struct_mutex)) {
+ /* this can get called from fbcon in atomic context.. so
+ * just ignore it and wait for next time called from
+ * interruptible context to update the PAT.. the result
+ * may be that user sees wrap-around instead of scrolling
+ * momentarily on the screen. If we wanted to be fancier
+ * we could perhaps schedule some workqueue work at this
+ * point.
+ */
+ return 0;
+ }
+
+ mutex_lock(&obj->dev->struct_mutex);
+
/* if we aren't mapped yet, we don't need to do anything */
if (omap_obj->block) {
struct page **pages;
--
1.7.5.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
