Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing.
There was already one in the blank handler, but it failed silently. That makes it impossible for drivers (like i915) who subclass these functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we really don't want to be bothered right now. This also allows us to remove a pile of FIXMEs from the i915 fbdev code (since due to the failure code they now won't attempt to grab dangerous locks any more).
Cc: Dave Airlie airlied@gmail.com Cc: Rodrigo Vivi rodrigo.vivi@gmail.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- drivers/gpu/drm/drm_fb_helper.c | 24 ++++++++++++------------ drivers/gpu/drm/i915/intel_fbdev.c | 21 --------------------- 2 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 73f90f7e2f74..77f570a470da 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) int i, j;
/* - * fbdev->blank can be called from irq context in case of a panic. - * Since we already have our own special panic handler which will - * restore the fbdev console mode completely, just bail out early. - */ - if (oops_in_progress) - return; - - /* * For each CRTC in this fb, turn the connectors on/off. */ drm_modeset_lock_all(dev); @@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) */ int drm_fb_helper_blank(int blank, struct fb_info *info) { + if (oops_in_progress) + return -EBUSY; + switch (blank) { /* Display: On; HSync: On, VSync: On */ case FB_BLANK_UNBLANK: @@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) int i, j, rc = 0; int start;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { + if (oops_in_progress) return -EBUSY; - } + + drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY; @@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info) struct drm_fb_helper *fb_helper = info->par; struct fb_var_screeninfo *var = &info->var;
+ if (oops_in_progress) + return -EBUSY; + if (var->pixclock != 0) { DRM_ERROR("PIXEL CLOCK SET\n"); return -EINVAL; @@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var, int ret = 0; int i;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) { + if (oops_in_progress) return -EBUSY; - } + + drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY; diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index eef54feb7545..b763f24e20ef 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info) ret = drm_fb_helper_set_par(info);
if (ret == 0) { - /* - * FIXME: fbdev presumes that all callbacks also work from - * atomic contexts and relies on that for emergency oops - * printing. KMS totally doesn't do that and the locking here is - * by far not the only place this goes wrong. Ignore this for - * now until we solve this for real. - */ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex); @@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info) ret = drm_fb_helper_blank(blank, info);
if (ret == 0) { - /* - * FIXME: fbdev presumes that all callbacks also work from - * atomic contexts and relies on that for emergency oops - * printing. KMS totally doesn't do that and the locking here is - * by far not the only place this goes wrong. Ignore this for - * now until we solve this for real. - */ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex); @@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var, ret = drm_fb_helper_pan_display(var, info);
if (ret == 0) { - /* - * FIXME: fbdev presumes that all callbacks also work from - * atomic contexts and relies on that for emergency oops - * printing. KMS totally doesn't do that and the locking here is - * by far not the only place this goes wrong. Ignore this for - * now until we solve this for real. - */ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);
Since the panic handling is gone this is only used for force-restoring the fbdev/fbcon from sysrq, and that's done with a work item. No need any more to do trylocks, we can just do normal locking.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- drivers/gpu/drm/drm_fb_helper.c | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 77f570a470da..a9043ab7f58b 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -416,19 +416,10 @@ static bool drm_fb_helper_force_kernel_mode(void) if (dev->switch_power_state == DRM_SWITCH_POWER_OFF) continue;
- /* - * NOTE: Use trylock mode to avoid deadlocks and sleeping in - * panic context. - */ - if (__drm_modeset_lock_all(dev, true) != 0) { - error = true; - continue; - } - + drm_modeset_lock_all(dev); ret = drm_fb_helper_restore_fbdev_mode(helper); if (ret) error = true; - drm_modeset_unlock_all(dev); } return error;
The last user is gone, no need for trylocking any more in this legacy helper.
Signed-off-by: Daniel Vetter daniel.vetter@intel.com --- drivers/gpu/drm/drm_modeset_lock.c | 52 ++++++++------------------------------ include/drm/drm_modeset_lock.h | 1 - 2 files changed, 11 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/drm_modeset_lock.c b/drivers/gpu/drm/drm_modeset_lock.c index b4ddd1801642..9abee87c1501 100644 --- a/drivers/gpu/drm/drm_modeset_lock.c +++ b/drivers/gpu/drm/drm_modeset_lock.c @@ -53,41 +53,27 @@ * drm_modeset_acquire_fini(&ctx); */
- /** - * __drm_modeset_lock_all - internal helper to grab all modeset locks - * @dev: DRM device - * @trylock: trylock mode for atomic contexts - * - * This is a special version of drm_modeset_lock_all() which can also be used in - * atomic contexts. Then @trylock must be set to true. + * drm_modeset_lock_all - take all modeset locks + * @dev: drm device * - * Returns: - * 0 on success or negative error code on failure. + * This function takes all modeset locks, suitable where a more fine-grained + * scheme isn't (yet) implemented. Locks must be dropped with + * drm_modeset_unlock_all. */ -int __drm_modeset_lock_all(struct drm_device *dev, - bool trylock) +void drm_modeset_lock_all(struct drm_device *dev) { struct drm_mode_config *config = &dev->mode_config; struct drm_modeset_acquire_ctx *ctx; int ret;
- ctx = kzalloc(sizeof(*ctx), - trylock ? GFP_ATOMIC : GFP_KERNEL); - if (!ctx) - return -ENOMEM; + ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); + if (WARN_ON(!ctx)) + return;
- if (trylock) { - if (!mutex_trylock(&config->mutex)) { - ret = -EBUSY; - goto out; - } - } else { - mutex_lock(&config->mutex); - } + mutex_lock(&config->mutex);
drm_modeset_acquire_init(ctx, 0); - ctx->trylock_only = trylock;
retry: ret = drm_modeset_lock(&config->connection_mutex, ctx); @@ -106,7 +92,7 @@ retry:
drm_warn_on_modeset_not_all_locked(dev);
- return 0; + return;
fail: if (ret == -EDEADLK) { @@ -114,23 +100,7 @@ fail: goto retry; }
-out: kfree(ctx); - return ret; -} -EXPORT_SYMBOL(__drm_modeset_lock_all); - -/** - * drm_modeset_lock_all - take all modeset locks - * @dev: drm device - * - * This function takes all modeset locks, suitable where a more fine-grained - * scheme isn't (yet) implemented. Locks must be dropped with - * drm_modeset_unlock_all. - */ -void drm_modeset_lock_all(struct drm_device *dev) -{ - WARN_ON(__drm_modeset_lock_all(dev, false) != 0); } EXPORT_SYMBOL(drm_modeset_lock_all);
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h index 70595ff565ba..5dd18bfdf601 100644 --- a/include/drm/drm_modeset_lock.h +++ b/include/drm/drm_modeset_lock.h @@ -130,7 +130,6 @@ struct drm_crtc; struct drm_plane;
void drm_modeset_lock_all(struct drm_device *dev); -int __drm_modeset_lock_all(struct drm_device *dev, bool trylock); void drm_modeset_unlock_all(struct drm_device *dev); void drm_modeset_lock_crtc(struct drm_crtc *crtc, struct drm_plane *plane);
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing.
There was already one in the blank handler, but it failed silently. That makes it impossible for drivers (like i915) who subclass these functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we really don't want to be bothered right now. This also allows us to remove a pile of FIXMEs from the i915 fbdev code (since due to the failure code they now won't attempt to grab dangerous locks any more).
I guess drivers that were keeping fbdev buffer pinned just for opps' can stop doing that now..
anyways, lgtm.. for the series:
Reviewed-by: Rob Clark robdclark@gmail.com
Cc: Dave Airlie airlied@gmail.com Cc: Rodrigo Vivi rodrigo.vivi@gmail.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
drivers/gpu/drm/drm_fb_helper.c | 24 ++++++++++++------------ drivers/gpu/drm/i915/intel_fbdev.c | 21 --------------------- 2 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 73f90f7e2f74..77f570a470da 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) int i, j;
/*
* fbdev->blank can be called from irq context in case of a panic.* Since we already have our own special panic handler which will* restore the fbdev console mode completely, just bail out early.*/if (oops_in_progress)return;/* * For each CRTC in this fb, turn the connectors on/off. */ drm_modeset_lock_all(dev);@@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) */ int drm_fb_helper_blank(int blank, struct fb_info *info) {
if (oops_in_progress)return -EBUSY;switch (blank) { /* Display: On; HSync: On, VSync: On */ case FB_BLANK_UNBLANK:@@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) int i, j, rc = 0; int start;
if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
if (oops_in_progress) return -EBUSY;
}
drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY;@@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info) struct drm_fb_helper *fb_helper = info->par; struct fb_var_screeninfo *var = &info->var;
if (oops_in_progress)return -EBUSY;if (var->pixclock != 0) { DRM_ERROR("PIXEL CLOCK SET\n"); return -EINVAL;@@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var, int ret = 0; int i;
if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
if (oops_in_progress) return -EBUSY;
}
drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY;diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index eef54feb7545..b763f24e20ef 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info) ret = drm_fb_helper_set_par(info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);@@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info) ret = drm_fb_helper_blank(blank, info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);@@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var, ret = drm_fb_helper_pan_display(var, info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);-- 2.1.4
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing.
There was already one in the blank handler, but it failed silently. That makes it impossible for drivers (like i915) who subclass these functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we really don't want to be bothered right now. This also allows us to remove a pile of FIXMEs from the i915 fbdev code (since due to the failure code they now won't attempt to grab dangerous locks any more).
I guess drivers that were keeping fbdev buffer pinned just for opps' can stop doing that now..
Well there's still the kgdb stuff, but we might want to nuke that too. Also fbdev assumes (at least afaik) that the mmap is always valid and it just writes to it. At least that's why we have the fbdev_set_suspend call to in suspend/resume to tell it that now it's really no longer cool to draw fbcon. But userspace doesn't have anything like that I think.
anyways, lgtm.. for the series:
Reviewed-by: Rob Clark robdclark@gmail.com
Thanks for the review, all merged. -Daniel
Cc: Dave Airlie airlied@gmail.com Cc: Rodrigo Vivi rodrigo.vivi@gmail.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
drivers/gpu/drm/drm_fb_helper.c | 24 ++++++++++++------------ drivers/gpu/drm/i915/intel_fbdev.c | 21 --------------------- 2 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 73f90f7e2f74..77f570a470da 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) int i, j;
/*
* fbdev->blank can be called from irq context in case of a panic.* Since we already have our own special panic handler which will* restore the fbdev console mode completely, just bail out early.*/if (oops_in_progress)return;/* * For each CRTC in this fb, turn the connectors on/off. */ drm_modeset_lock_all(dev);@@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) */ int drm_fb_helper_blank(int blank, struct fb_info *info) {
if (oops_in_progress)return -EBUSY;switch (blank) { /* Display: On; HSync: On, VSync: On */ case FB_BLANK_UNBLANK:@@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) int i, j, rc = 0; int start;
if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
if (oops_in_progress) return -EBUSY;
}
drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY;@@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info) struct drm_fb_helper *fb_helper = info->par; struct fb_var_screeninfo *var = &info->var;
if (oops_in_progress)return -EBUSY;if (var->pixclock != 0) { DRM_ERROR("PIXEL CLOCK SET\n"); return -EINVAL;@@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var, int ret = 0; int i;
if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
if (oops_in_progress) return -EBUSY;
}
drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY;diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index eef54feb7545..b763f24e20ef 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info) ret = drm_fb_helper_set_par(info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);@@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info) ret = drm_fb_helper_blank(blank, info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);@@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var, ret = drm_fb_helper_pan_display(var, info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);-- 2.1.4
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Jul 28, 2015 at 11:55 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Jul 28, 2015 at 10:30:08AM -0400, Rob Clark wrote:
On Tue, Jul 28, 2015 at 7:18 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
Trying to do anything with kms drivers when oopsing has become a failing proposition. But since we can end up in the fbdev code simply due to the console unblanking that's done unconditionally just removing our panic handler isn't enough. We need to block all fbdev callbacks when oopsing.
There was already one in the blank handler, but it failed silently. That makes it impossible for drivers (like i915) who subclass these functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we really don't want to be bothered right now. This also allows us to remove a pile of FIXMEs from the i915 fbdev code (since due to the failure code they now won't attempt to grab dangerous locks any more).
I guess drivers that were keeping fbdev buffer pinned just for opps' can stop doing that now..
Well there's still the kgdb stuff, but we might want to nuke that too. Also fbdev assumes (at least afaik) that the mmap is always valid and it just writes to it. At least that's why we have the fbdev_set_suspend call to in suspend/resume to tell it that now it's really no longer cool to draw fbcon. But userspace doesn't have anything like that I think.
we couldn't put_pages but we could unpin from iommu/gtt/etc and unpin the pages so they could be moved by mm at least.. but letting 'em get swapped out, probably not..
BR, -R
anyways, lgtm.. for the series:
Reviewed-by: Rob Clark robdclark@gmail.com
Thanks for the review, all merged. -Daniel
Cc: Dave Airlie airlied@gmail.com Cc: Rodrigo Vivi rodrigo.vivi@gmail.com Signed-off-by: Daniel Vetter daniel.vetter@intel.com
drivers/gpu/drm/drm_fb_helper.c | 24 ++++++++++++------------ drivers/gpu/drm/i915/intel_fbdev.c | 21 --------------------- 2 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 73f90f7e2f74..77f570a470da 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -491,14 +491,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) int i, j;
/*
* fbdev->blank can be called from irq context in case of a panic.* Since we already have our own special panic handler which will* restore the fbdev console mode completely, just bail out early.*/if (oops_in_progress)return;/* * For each CRTC in this fb, turn the connectors on/off. */ drm_modeset_lock_all(dev);@@ -531,6 +523,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) */ int drm_fb_helper_blank(int blank, struct fb_info *info) {
if (oops_in_progress)return -EBUSY;switch (blank) { /* Display: On; HSync: On, VSync: On */ case FB_BLANK_UNBLANK:@@ -755,9 +750,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) int i, j, rc = 0; int start;
if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
if (oops_in_progress) return -EBUSY;
}
drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY;@@ -906,6 +902,9 @@ int drm_fb_helper_set_par(struct fb_info *info) struct drm_fb_helper *fb_helper = info->par; struct fb_var_screeninfo *var = &info->var;
if (oops_in_progress)return -EBUSY;if (var->pixclock != 0) { DRM_ERROR("PIXEL CLOCK SET\n"); return -EINVAL;@@ -931,9 +930,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var, int ret = 0; int i;
if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
if (oops_in_progress) return -EBUSY;
}
drm_modeset_lock_all(dev); if (!drm_fb_helper_is_bound(fb_helper)) { drm_modeset_unlock_all(dev); return -EBUSY;diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index eef54feb7545..b763f24e20ef 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info) ret = drm_fb_helper_set_par(info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);@@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info) ret = drm_fb_helper_blank(blank, info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);@@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo *var, ret = drm_fb_helper_pan_display(var, info);
if (ret == 0) {
/** FIXME: fbdev presumes that all callbacks also work from* atomic contexts and relies on that for emergency oops* printing. KMS totally doesn't do that and the locking here is* by far not the only place this goes wrong. Ignore this for* now until we solve this for real.*/ mutex_lock(&fb_helper->dev->struct_mutex); intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex);-- 2.1.4
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
-- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Daniel Vetter -
Rob Clark