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