With the removal of timer implementation for cursor work[1],
the cursor delayed work does not get rescheduled if it fails
to acquire the console lock.
This has been found to cause issue during the resume sequence
of the IGT test kms_fbcon_fbt@fbc-suspend[2]. The test expects
cursor blinking to start after the system resumes from suspend
state.
fbcon_resumed()
redraw_screen()
set_cursor()
fb_flashcursor()
But the cursor work fails to acuire the lock and it never gets
rescheduled unless some other function comes in and invokes
fbcon_add_cursor_work() which adds the worker to the queue.
>From empirical evidence this happens if we tweak the console
log level.
Push the cursor work to the queue if we fail to acquire the lock.
[1] commit 3b0fb6ab25dd ("fbcon: Use delayed work for cursor")
[2]
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_17565/re-mtlp-11/igt@[email protected]
Signed-off-by: Chaitanya Kumar Borah <[email protected]>
---
drivers/video/fbdev/core/fbcon.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 9771134beb8a..96e81f15af90 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -401,8 +401,11 @@ static void fb_flashcursor(struct work_struct *work)
/* instead we just fail to flash the cursor if we can't get
* the lock instead of blocking fbcon deinit */
ret = console_trylock();
- if (ret == 0)
+ if (ret == 0) {
+ queue_delayed_work(system_power_efficient_wq, &ops->cursor_work,
+ ops->cur_blink_jiffies);
return;
+ }
/* protected by console_lock */
info = par->info;
--
2.25.1
