Message ID | 1324004717-20595-2-git-send-email-rob.clark@linaro.org |
---|---|
State | New |
Headers | show |
On Thu, Dec 15, 2011 at 9:05 PM, Rob Clark <rob.clark@linaro.org> wrote: > From: Rob Clark <rob@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@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 >
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()) { + /* 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;