On Thu, Dec 15, 2011 at 9:05 PM, Rob Clark <rob.clark@xxxxxxxxxx> wrote:
> From: Rob Clark <rob@xxxxxx>
>
> 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@xxxxxx>
> ---
> 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
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
