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 change pushes the cursor
work to the queue if we fail to acquire the 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.
Re-scheduling the work heals the issue. I am not sure if this
is the best solution we can have, particularly with the "Fix me"
comment which indicates a bigger underlying problem. Hence, the
RFC.
[1] 3b0fb6ab25("fbcon: Use delayed work for cursor")
[2] https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13243/shard-glk2/igt@kms_fbcon_fbt@xxxxxxxxxxxxxxxx
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@xxxxxxxxx>
---
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 c6c9d040bdec..b98ea62836ae 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -357,8 +357,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 = ops->info;
--
2.25.1
