[PATCH 2/3] drm/omap: avoid aquiring mutex in atomic context

[Rob Clark]

On Thu, Dec 15, 2011 at 9:05 PM, Rob Clark <rob.clark at linaro.org> wrote:
> From: Rob Clark <rob at ti.com>
>
> omap_gem_roll() could be called by fbcon in atomic context.  Avoid
> aquiring mutex, or calling tiler_pin() (which itself is not safe
> for atomic context) in these cases.
>
> Signed-off-by: Rob Clark <rob at 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..2bc570a 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()) {

ugg, this isn't even sufficient if you have any debug printks that can
be enabled within struct_mutex critical section..

updated patch coming

BR,
-R


> +               /* 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
>