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
>
