diff mbox

drm/omap: avoid aquiring mutex in atomic context (v2)

Message ID 1324056874-10635-1-git-send-email-rob.clark@linaro.org
State Accepted
Commit af69592aa098ff8cd640e8109ba946db3c1cdb4e
Headers show

Commit Message

Rob Clark Dec. 16, 2011, 5:34 p.m. UTC 
From: Rob Clark <rob@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 <rob@ti.com>
---
 drivers/staging/omapdrm/omap_gem.c |   16 ++++++++++++++--
 1 files changed, 14 insertions(+), 2 deletions(-)

Comments

Felipe Contreras Jan. 1, 2012, 7:16 p.m. UTC | #1 
On Fri, Dec 16, 2011 at 7:34 PM, Rob Clark <rob.clark@linaro.org> wrote:
> --- 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.
> +                */

Multi-line comments are supposed to be of the form:
/*
 * Foo.
 */

> +               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;
> --

Cheers.
diff mbox

Patch

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;