search for: fb_set_suspend

...c index 23fa049..a2f29d4 100644 --- a/drivers/staging/msm/msm_fb.c +++ b/drivers/staging/msm/msm_fb.c @@ -347,7 +347,7 @@ static int msm_fb_suspend(struct platform_device *pdev, pm_message_t state) if ((!mfd) || (mfd->key != MFD_KEY)) return 0; - acquire_console_sem(); + console_lock(); fb_set_suspend(mfd->fbi, 1); ret = msm_fb_suspend_sub(mfd); @@ -358,7 +358,7 @@ static int msm_fb_suspend(struct platform_device *pdev, pm_message_t state) pdev->dev.power.power_state = state; } - release_console_sem(); + console_unlock(); return ret; } #else @@ -431,11 +431,11 @@ static int...

...c index 23fa049..a2f29d4 100644 --- a/drivers/staging/msm/msm_fb.c +++ b/drivers/staging/msm/msm_fb.c @@ -347,7 +347,7 @@ static int msm_fb_suspend(struct platform_device *pdev, pm_message_t state) if ((!mfd) || (mfd->key != MFD_KEY)) return 0; - acquire_console_sem(); + console_lock(); fb_set_suspend(mfd->fbi, 1); ret = msm_fb_suspend_sub(mfd); @@ -358,7 +358,7 @@ static int msm_fb_suspend(struct platform_device *pdev, pm_message_t state) pdev->dev.power.power_state = state; } - release_console_sem(); + console_unlock(); return ret; } #else @@ -431,11 +431,11 @@ static int...

...c index 23fa049..a2f29d4 100644 --- a/drivers/staging/msm/msm_fb.c +++ b/drivers/staging/msm/msm_fb.c @@ -347,7 +347,7 @@ static int msm_fb_suspend(struct platform_device *pdev, pm_message_t state) if ((!mfd) || (mfd->key != MFD_KEY)) return 0; - acquire_console_sem(); + console_lock(); fb_set_suspend(mfd->fbi, 1); ret = msm_fb_suspend_sub(mfd); @@ -358,7 +358,7 @@ static int msm_fb_suspend(struct platform_device *pdev, pm_message_t state) pdev->dev.power.power_state = state; } - release_console_sem(); + console_unlock(); return ret; } #else @@ -431,11 +431,11 @@ static int...

On resume of a hibernated notebook, I get garbled virtual consoles. fb_set_suspend(*dev, state == 0 means dev is running ...) This patch fixes that issue for me: hibernate: kernel: nouveau [ DRM] suspending fbcon... kernel: nouveau [ DRM] suspending display... kernel: nouveau [ DRM] unpinning framebuffer(s)... kernel: nouveau [ DRM] evicting buffers... kerne...

On 03/10/13 15:41, Christoph Rudorff wrote: > On resume of a hibernated notebook, I get garbled virtual consoles. > > fb_set_suspend(*dev, state == 0 means dev is running ...) > > This patch fixes that issue for me: > Ouch, nice catch Christoph :) Seems like the following commit flipped the logic unintentionally, thus causing the issue. Stange enough I have no problems with s2d although I must admit it's not the...

...than console_lock. But that means > fixing up fbcon locking horror shows. console_lock seems needed for some code down the call stack, removing it risks some blow ups. Some archaeology: this locking problem was introduced with 054430e773c9 ("fbcon: fix locking harder"). In the past fb_set_suspend also took the fb_info lock but that was removed in 9e769ff3f585 ("fb: avoid possible deadlock caused by fb_set_suspend"). Peter > > My current plan is to move stuff out of the lock and allow (just) > > resuming the console to be delayed. Some drivers (nouveau, > > rad...

...den 03.10.2013, 23:50 +0100 schrieb Emil Velikov: > I'm not entirely sure this is correct. One needs to save and disable > accleration before suspending the fb. Please try the following > > - if (state == 0) > + if (state == 1) > nouveau_fbcon_save_disable_accel(dev); > fb_set_suspend(drm->fbcon->helper.fbdev, state); > - if (state == 1) > + if (state == 0) > nouveau_fbcon_restore_accel(dev); > console_unlock(); > > Cheers, > Emil Hi! That was my first try! I guessed the same but I got exactly one trap message on resume. So it's about first...

...: sparse: call with no type! drivers/gpu/drm/qxl/qxl_drv.c:181:30: sparse: call with no type! drivers/gpu/drm/qxl/qxl_drv.c: In function 'qxl_drm_freeze': drivers/gpu/drm/qxl/qxl_drv.c:144:2: error: implicit declaration of function 'qxl_fbdev_set_suspend'; did you mean 'fb_set_suspend'? [-Werror=implicit-function-declaration] qxl_fbdev_set_suspend(qdev, 1); ^~~~~~~~~~~~~~~~~~~~~ fb_set_suspend cc1: some warnings being treated as errors -- >> drivers/gpu/drm/qxl/qxl_fb.c:166:21: sparse: incorrect type in assignment (different address spaces) @@ expe...

Signed-off-by: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 3ed12a8cfc91..a4a586807903 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -370,6 +370,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper, ret = -ENOMEM; goto

On Wed, Jul 13, 2016 at 11:54:49AM +0200, Daniel Vetter wrote: > On Tue, Jul 12, 2016 at 06:49:34PM +0200, Peter Wu wrote: > > The FBIOPUT_CON2FBMAP ioctl takes a console_lock(). When this is called > > while nouveau was runtime suspended, a deadlock would occur due to > > nouveau_fbcon_set_suspend also trying to obtain console_lock(). > > > > Fix this by delaying

...vers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -513,11 +513,11 @@ void nouveau_fbcon_set_suspend(struct drm_device *dev, int state) { struct nouveau_drm *drm = nouveau_drm(dev); console_lock(); - if (state == 0) - nouveau_fbcon_save_disable_accel(dev); - fb_set_suspend(drm->fbcon->helper.fbdev, state); - if (state == 1) + if (state == FBINFO_STATE_RUNNING) nouveau_fbcon_restore_accel(dev); + fb_set_suspend(drm->fbcon->helper.fbdev, state); + if (state == FBINFO_STATE_SUSPENDED) + nouveau_fbcon_save_disable_accel(dev); console_unlock(); } --...

...gt;> I'm not entirely sure this is correct. One needs to save and disable >>> accleration before suspending the fb. Please try the following >>> >>> - if (state == 0) >>> + if (state == 1) >>> nouveau_fbcon_save_disable_accel(dev); >>> fb_set_suspend(drm->fbcon->helper.fbdev, state); >>> - if (state == 1) >>> + if (state == 0) >>> nouveau_fbcon_restore_accel(dev); >>> console_unlock(); >>> >>> Cheers, >>> Emil >> >> Hi! >> >> That was my first try! I...

...schrieb Emil Velikov: >> I'm not entirely sure this is correct. One needs to save and disable >> accleration before suspending the fb. Please try the following >> >> - if (state == 0) >> + if (state == 1) >> nouveau_fbcon_save_disable_accel(dev); >> fb_set_suspend(drm->fbcon->helper.fbdev, state); >> - if (state == 1) >> + if (state == 0) >> nouveau_fbcon_restore_accel(dev); >> console_unlock(); >> >> Cheers, >> Emil > > Hi! > > That was my first try! I guessed the same but I got exactly one tr...

...e+0x5a/0x70 [<ffffffff81557ad7>] down_read+0x47/0x5c [<ffffffff810697c1>] __blocking_notifier_call_chain+0x51/0xc0 [<ffffffff81069841>] blocking_notifier_call_chain+0x11/0x20 [<ffffffff81262a16>] fb_notifier_call_chain+0x16/0x20 [<ffffffff81263146>] fb_set_suspend+0x46/0x60 [<ffffffffa0204da2>] nouveau_fbcon_set_suspend+0x92/0xc0 [nouveau] [<ffffffffa01f5451>] nouveau_do_suspend+0x51/0x200 [nouveau] [<ffffffffa01f564f>] nouveau_pmops_suspend+0x2f/0x80 [nouveau] [<ffffffffa01f723c>] nouveau_switcheroo_set_state+0x5c/0xc...

...ock is leaked on an error path. > - i915: I think that clearing the fb memory can be done outside the > lock too as the console is suspended. > > Please correct me if my assumptions are flawed. Yeah, fixing this independent issues should definitely help, irrespective of how we fix fb_set_suspend. > > Besides this, when fixing a deadlock pls provide more details about the > > precise callchain and the locks involved in the deadlock. If you > > discovered this using lockdep, then just add the entire lockdep splat to > > the commit message. Otherwise there's lots...