Skip to contentSkip to conversation

Framebuffer: client notification mecanism & PM

PATCH In review Benjamin Herrenschmidt 5 participants 18 messages Jul 29, 2003 – Aug 7, 2003

Subsystems (2)
Framebuffer layer Console
lore
Share & tools
lore

Benjamin Herrenschmidt

author
#0 lore raw

PATCH 1/1 Framebuffer: client notification mecanism & PM

Hi !

This patch adds a mecanism for in-kernel "clients" of a framebuffer device to get notified of events on this framebuffer device. It adds some basic Power Management callbacks based on this, and implements support in fbcon.

This allows fbdev low level drivers to instruct clients like "fbcon" to stop touching the framebuffer as the hardware is going to be suspended, and to restore the display after resume. I also defined (but didn't use yet) a mode change hook that would allow to restore 2.4 functionality of fbset to the fbdev driver keeping fbcon in sync with the new mode (lots of users are asking for this).

There is room for improvement, but this is a first step that makes suspend/resume work more reliably on pmacs. I'll send aty128fb and radeonfb bits using this framework once it's merged.

Ben.

drivers/video/console/fbcon.c +54 -1
diff -urN linux-2.5/drivers/video/console/fbcon.c linuxppc-2.5-benh/drivers/video/console/fbcon.c
@@ -199,7 +199,8 @@
 	if (!info || (info->cursor.rop == ROP_COPY))
 		return;
 	info->cursor.enable ^= 1;
-	info->fbops->fb_cursor(info, &info->cursor);
+	if (!info->suspended)
+		info->fbops->fb_cursor(info, &info->cursor);
 }
 
 #if (defined(__arm__) && defined(IRQ_VSYNCPULSE)) || defined(CONFIG_ATARI) || defined(CONFIG_MAC)

@@ -948,6 +949,9 @@
 	if (!height || !width)
 		return;
 
+	if (info->suspended)
+		return;
+
 	/* Split blits that cross physical y_wrap boundary */
 
 	y_break = p->vrows - p->yscroll;

@@ -972,6 +976,9 @@
 	if (vt_cons[vc->vc_num]->vc_mode != KD_TEXT)
 		return;
 
+	if (info->suspended)
+		return;
+
 	accel_putc(vc, info, c, real_y(p, ypos), xpos);
 }
 

@@ -987,6 +994,9 @@
 	if (vt_cons[vc->vc_num]->vc_mode != KD_TEXT)
 		return;
 
+	if (info->suspended)
+		return;
+
 	accel_putcs(vc, info, s, count, real_y(p, ypos), xpos);
 }
 

@@ -1001,6 +1011,9 @@
 	int y = real_y(p, vc->vc_y);
 	struct fb_cursor cursor;
 	
+	if (info->suspended)
+		return;
+
 	if (mode & CM_SOFTBACK) {
 		mode &= ~CM_SOFTBACK;
 		if (softback_lines) {

@@ -1385,6 +1398,9 @@
 	if (!count || vt_cons[vc->vc_num]->vc_mode != KD_TEXT)
 		return 0;
 
+	if (info->suspended)
+		return 0;
+
 	fbcon_cursor(vc, CM_ERASE);
 
 	/*

@@ -1545,6 +1561,9 @@
 	if (!width || !height)
 		return;
 
+	if (info->suspended)
+		return;
+
 	/*  Split blits that cross physical y_wrap case.
 	 *  Pathological case involves 4 blits, better to use recursive
 	 *  code rather than unrolled case

@@ -1633,6 +1652,9 @@
 	struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
 	struct display *p = &fb_display[vc->vc_num];
 
+	if (info->suspended)
+		return 0;
+
 	if (softback_top) {
 		int l = fbcon_softback_size / vc->vc_size_row;
 		if (softback_lines)

@@ -1704,6 +1726,9 @@
 	if (blank < 0)		/* Entering graphics mode */
 		return 0;
 
+	if (info->suspended)
+		return 0;
+
 	fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
 
 	if (!info->fbops->fb_blank) {

@@ -2067,6 +2092,9 @@
 	int i, j, k;
 	u8 val;
 
+	if (info->suspended)
+		return 0;
+
 	if (!vc->vc_can_do_color
 	    || (!info->fbops->fb_blank && console_blanked))
 		return -EINVAL;

@@ -2171,6 +2199,9 @@
 	struct display *p = &fb_display[fg_console];
 	int offset, limit, scrollback_old;
 
+	if (info->suspended)
+		return 0;
+
 	if (softback_top) {
 		if (vc->vc_num != fg_console)
 			return 0;

@@ -2259,6 +2290,19 @@
 	return 0;
 }
 
+static void fbcon_suspended(void *data, struct fb_info *info)
+{
+	/* Here, we should do something to properly
+	 * synchronize with the cursor interrupt on
+	 * SMP...
+	 */
+}
+
+static void fbcon_resumed(void *data, struct fb_info *info)
+{
+	update_screen(fg_console);
+}
+
 /*
  *  The console `switch' structure for the frame buffer based console
  */

@@ -2285,16 +2329,25 @@
 	.con_resize             = fbcon_resize,
 };
 
+static struct fb_client_ops fbcon_client = {
+	.owner			= THIS_MODULE,
+	.mode_changed		= NULL, /* TODO */
+	.suspended		= fbcon_suspended,
+	.resumed		= fbcon_resumed,
+};
+
 int __init fb_console_init(void)
 {
 	if (!num_registered_fb)
 		return -ENODEV;
 	take_over_console(&fb_con, first_fb_vc, last_fb_vc, fbcon_is_default);
+	register_fb_client(&fbcon_client, NULL);
 	return 0;
 }
 
 void __exit fb_console_exit(void)
 {
+	unregister_fb_client(&fbcon_client);
 	give_up_console(&fb_con);
 }
drivers/video/fbmem.c +92 -0

127 lines not on this page · raw message

include/linux/fb.h +56 -0

80 lines not on this page · raw message

#1 lore raw

Hi!

Quoted 5 lines

There is room for improvement, but this is a first step that makes suspend/resume work more reliably on pmacs. I'll send aty128fb and radeonfb bits using this framework once it's merged.

drivers/video/console/fbcon.c line 206

Quoted 9 lines
drivers/video/console/fbcon.c +2 -1
@@ -199,7 +199,8 @@
 	if (!info || (info->cursor.rop == ROP_COPY))
 		return;
 	info->cursor.enable ^= 1;
-	info->fbops->fb_cursor(info, &info->cursor);
+	if (!info->suspended)
+		info->fbops->fb_cursor(info, &info->cursor);
 }
 
 	y_break = p->vrows - p->yscroll;

Would not it be simpler to replace info->fbops with some dummy ones?

Signature · 2 lines
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
author
#2 lore raw
Quoted 3 lines

Would not it be simpler to replace info->fbops with some dummy ones?

I did that for 2.4, that's indeed an option. I suppose we are completely sure fbcon will never touch the framebuffer without going through those fb_ops (fb_fillrect, fb_imageblit, etc...) ? That mean we would still run a lot of useless code, but that's not too bad.

We still want the notification mecanism though, at least for proper refresh on wakeup, and other "clients" (the DRI comes to mind) may make good use of it as well.

Ben.

author
#3 lore raw

PATCH 1/1 Framebuffer: 2nd try: client notification mecanism & PM

So, here's a new version that removes checking for suspend field all over fbcon. I tried it here with a modified radeonfb that sets the fbops to some dummy functions (provided by fbmem.c in this patch though you may want to move them around).
In theory, I could implement power management properly without the client notification mecanism by just setting the dummy fbops and directly calling update_screen from the low level fbdev on resume, but that doesn't smell good. The console subsystem is a bit of a nightmare to me, James, can we currently have several consoles on several heads ? (that currcons in vt.c is disturbing me). It may be worth doing better than just update_screen (fg_console) when resuming in fbcon.c... (this callback will be called for each fbdev who is waking up).

Let me know what you think, in all cases, asap so I can push the remaining fbdev driver bits.

Ben.

===== drivers/video/fbmem.c 1.77 vs edited =====

drivers/video/fbmem.c +116 -0
@@ -392,6 +392,9 @@
 struct fb_info *registered_fb[FB_MAX];
 int num_registered_fb;
 
+static LIST_HEAD(fb_clients);
+static DECLARE_MUTEX(fb_clients_lock);
+
 #ifdef CONFIG_FB_OF
 static int ofonly __initdata = 0;
 #endif

@@ -935,6 +938,8 @@
 			fb_pan_display(info, &info->var);
 
 			fb_set_cmap(&info->cmap, 1, info);
+
+			fb_clients_call_mode_changed(info);
 		}
 	}
 	return 0;

@@ -1371,6 +1376,107 @@
 
 __setup("video=", video_setup);
 
+/*
+ * Dummy operations used typically when power managing
+ */
+
+int fb_dummy_cursor(struct fb_info *info, struct fb_cursor *cursor)
+{
+	return 0;
+}
+
+void fb_dummy_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
+{
+}
+
+void fb_dummy_copyarea(struct fb_info *info, const struct fb_copyarea *area)
+{
+}
+
+void fb_dummy_imageblit(struct fb_info *info, const struct fb_image *image)
+{
+}
+
+/*
+ * Wrappers to client calls
+ */
+
+int
+fb_set_suspend(struct fb_info *info, int suspended)
+{
+	if (suspended == info->suspended)
+		return 0;
+
+	info->suspended = suspended;
+	if (suspended)
+		fb_clients_call_suspended(info);
+	else
+		fb_clients_call_resumed(info);
+
+	return 0;
+}
+
+int register_fb_client(struct fb_client_ops *ops, void *data)
+{
+	struct fb_client *client;
+
+	client = kmalloc(sizeof(*client), GFP_KERNEL);
+	if (client == NULL)
+		return -ENOMEM;
+
+	memset(client, 0, sizeof(*client));
+	client->ops = ops;
+	client->data = data;
+	
+	down(&fb_clients_lock);
+	list_add(&client->link, &fb_clients);
+	up(&fb_clients_lock);
+
+	return 0;
+}
+
+int unregister_fb_client(struct fb_client_ops *ops)
+{
+	struct fb_client *client = NULL;
+	struct list_head *pos;
+	
+	down(&fb_clients_lock);
+	list_for_each(pos, &fb_clients) {
+		client = list_entry(pos, struct fb_client, link);
+		if (client->ops == ops) {
+			list_del(&client->link);
+			kfree(client);
+			break;
+		}
+	}
+	up(&fb_clients_lock);
+
+	return 0;
+}
+
+#define make_fb_client_call(name) \
+int fb_clients_call_##name(struct fb_info *info) \
+{ \
+	struct fb_client *client = NULL; \
+	struct list_head *pos; \
+\
+	down(&fb_clients_lock); \
+	list_for_each(pos, &fb_clients) { \
+		client = list_entry(pos, struct fb_client, link); \
+		if (try_module_get(client->ops->owner)) { \
+			if (client->ops->name) \
+				client->ops->name(client->data, info); \
+			module_put(client->ops->owner); \
+		} \
+	} \
+	up(&fb_clients_lock); \
+	return 0; \
+}
+
+make_fb_client_call(mode_changed)
+make_fb_client_call(suspended)
+make_fb_client_call(resumed)
+
     /*
      *  Visible symbols for modules
      */

@@ -1387,5 +1493,15 @@
 EXPORT_SYMBOL(fb_get_buffer_offset);
 EXPORT_SYMBOL(move_buf_unaligned);
 EXPORT_SYMBOL(move_buf_aligned);
+EXPORT_SYMBOL(fb_set_suspend);
+EXPORT_SYMBOL(register_fb_client);
+EXPORT_SYMBOL(unregister_fb_client);
+EXPORT_SYMBOL(fb_clients_call_mode_changed);
+EXPORT_SYMBOL(fb_clients_call_suspended);
+EXPORT_SYMBOL(fb_clients_call_resumed);
+EXPORT_SYMBOL(fb_dummy_fillrect);
+EXPORT_SYMBOL(fb_dummy_copyarea);
+EXPORT_SYMBOL(fb_dummy_imageblit);
+EXPORT_SYMBOL(fb_dummy_cursor);
 
 MODULE_LICENSE("GPL");

===== drivers/video/console/fbcon.c 1.102 vs edited =====

drivers/video/console/fbcon.c +22 -0
@@ -2259,6 +2259,19 @@
 	return 0;
 }
 
+static void fbcon_suspended(void *data, struct fb_info *info)
+{
+	/* Here, we should do something to properly erase the
+	 * cursor and synchronize with the cursor interrupt on
+	 * SMP... (may not be that critical though...)
+	 */
+}
+
+static void fbcon_resumed(void *data, struct fb_info *info)
+{
+	update_screen(fg_console);
+}
+
 /*
  *  The console `switch' structure for the frame buffer based console
  */

@@ -2285,16 +2298,25 @@
 	.con_resize             = fbcon_resize,
 };
 
+static struct fb_client_ops fbcon_client = {
+	.owner			= THIS_MODULE,
+	.mode_changed		= NULL, /* TODO */
+	.suspended		= fbcon_suspended,
+	.resumed		= fbcon_resumed,
+};
+
 int __init fb_console_init(void)
 {
 	if (!num_registered_fb)
 		return -ENODEV;
 	take_over_console(&fb_con, first_fb_vc, last_fb_vc, fbcon_is_default);
+	register_fb_client(&fbcon_client, NULL);
 	return 0;
 }
 
 void __exit fb_console_exit(void)
 {
+	unregister_fb_client(&fbcon_client);
 	give_up_console(&fb_con);
 }

===== include/linux/fb.h 1.53 vs edited =====

include/linux/fb.h +60 -0

90 lines not on this page · raw message

author
#4 lore raw

PATCH 1/1 Framebuffer: 2nd try: client notification mecanism & PM

In reply to Benjamin Herrenschmidt

(resent with proper recipients list, sorry)

So, here's a new version that removes checking for suspend field all over fbcon. I tried it here with a modified radeonfb that sets the fbops to some dummy functions (provided by fbmem.c in this patch though you may want to move them around).
In theory, I could implement power management properly without the client notification mecanism by just setting the dummy fbops and directly calling update_screen from the low level fbdev on resume, but that doesn't smell good. The console subsystem is a bit of a nightmare to me, James, can we currently have several consoles on several heads ? (that currcons in vt.c is disturbing me). It may be worth doing better than just update_screen (fg_console) when resuming in fbcon.c... (this callback will be called for each fbdev who is waking up).

Let me know what you think, in all cases, asap so I can push the remaining fbdev driver bits.

Ben.

===== drivers/video/fbmem.c 1.77 vs edited =====

drivers/video/fbmem.c +116 -0
@@ -392,6 +392,9 @@
 struct fb_info *registered_fb[FB_MAX];
 int num_registered_fb;
 
+static LIST_HEAD(fb_clients);
+static DECLARE_MUTEX(fb_clients_lock);
+
 #ifdef CONFIG_FB_OF
 static int ofonly __initdata = 0;
 #endif

@@ -935,6 +938,8 @@
 			fb_pan_display(info, &info->var);
 
 			fb_set_cmap(&info->cmap, 1, info);
+
+			fb_clients_call_mode_changed(info);
 		}
 	}
 	return 0;

@@ -1371,6 +1376,107 @@
 
 __setup("video=", video_setup);
 
+/*
+ * Dummy operations used typically when power managing
+ */
+
+int fb_dummy_cursor(struct fb_info *info, struct fb_cursor *cursor)
+{
+	return 0;
+}
+
+void fb_dummy_fillrect(struct fb_info *info, const struct fb_fillrect *rect)
+{
+}
+
+void fb_dummy_copyarea(struct fb_info *info, const struct fb_copyarea *area)
+{
+}
+
+void fb_dummy_imageblit(struct fb_info *info, const struct fb_image *image)
+{
+}
+
+/*
+ * Wrappers to client calls
+ */
+
+int
+fb_set_suspend(struct fb_info *info, int suspended)
+{
+	if (suspended == info->suspended)
+		return 0;
+
+	info->suspended = suspended;
+	if (suspended)
+		fb_clients_call_suspended(info);
+	else
+		fb_clients_call_resumed(info);
+
+	return 0;
+}
+
+int register_fb_client(struct fb_client_ops *ops, void *data)
+{
+	struct fb_client *client;
+
+	client = kmalloc(sizeof(*client), GFP_KERNEL);
+	if (client == NULL)
+		return -ENOMEM;
+
+	memset(client, 0, sizeof(*client));
+	client->ops = ops;
+	client->data = data;
+	
+	down(&fb_clients_lock);
+	list_add(&client->link, &fb_clients);
+	up(&fb_clients_lock);
+
+	return 0;
+}
+
+int unregister_fb_client(struct fb_client_ops *ops)
+{
+	struct fb_client *client = NULL;
+	struct list_head *pos;
+	
+	down(&fb_clients_lock);
+	list_for_each(pos, &fb_clients) {
+		client = list_entry(pos, struct fb_client, link);
+		if (client->ops == ops) {
+			list_del(&client->link);
+			kfree(client);
+			break;
+		}
+	}
+	up(&fb_clients_lock);
+
+	return 0;
+}
+
+#define make_fb_client_call(name) \
+int fb_clients_call_##name(struct fb_info *info) \
+{ \
+	struct fb_client *client = NULL; \
+	struct list_head *pos; \
+\
+	down(&fb_clients_lock); \
+	list_for_each(pos, &fb_clients) { \
+		client = list_entry(pos, struct fb_client, link); \
+		if (try_module_get(client->ops->owner)) { \
+			if (client->ops->name) \
+				client->ops->name(client->data, info); \
+			module_put(client->ops->owner); \
+		} \
+	} \
+	up(&fb_clients_lock); \
+	return 0; \
+}
+
+make_fb_client_call(mode_changed)
+make_fb_client_call(suspended)
+make_fb_client_call(resumed)
+
     /*
      *  Visible symbols for modules
      */

@@ -1387,5 +1493,15 @@
 EXPORT_SYMBOL(fb_get_buffer_offset);
 EXPORT_SYMBOL(move_buf_unaligned);
 EXPORT_SYMBOL(move_buf_aligned);
+EXPORT_SYMBOL(fb_set_suspend);
+EXPORT_SYMBOL(register_fb_client);
+EXPORT_SYMBOL(unregister_fb_client);
+EXPORT_SYMBOL(fb_clients_call_mode_changed);
+EXPORT_SYMBOL(fb_clients_call_suspended);
+EXPORT_SYMBOL(fb_clients_call_resumed);
+EXPORT_SYMBOL(fb_dummy_fillrect);
+EXPORT_SYMBOL(fb_dummy_copyarea);
+EXPORT_SYMBOL(fb_dummy_imageblit);
+EXPORT_SYMBOL(fb_dummy_cursor);
 
 MODULE_LICENSE("GPL");

===== drivers/video/console/fbcon.c 1.102 vs edited =====

drivers/video/console/fbcon.c +22 -0
@@ -2259,6 +2259,19 @@
 	return 0;
 }
 
+static void fbcon_suspended(void *data, struct fb_info *info)
+{
+	/* Here, we should do something to properly erase the
+	 * cursor and synchronize with the cursor interrupt on
+	 * SMP... (may not be that critical though...)
+	 */
+}
+
+static void fbcon_resumed(void *data, struct fb_info *info)
+{
+	update_screen(fg_console);
+}
+
 /*
  *  The console `switch' structure for the frame buffer based console
  */

@@ -2285,16 +2298,25 @@
 	.con_resize             = fbcon_resize,
 };
 
+static struct fb_client_ops fbcon_client = {
+	.owner			= THIS_MODULE,
+	.mode_changed		= NULL, /* TODO */
+	.suspended		= fbcon_suspended,
+	.resumed		= fbcon_resumed,
+};
+
 int __init fb_console_init(void)
 {
 	if (!num_registered_fb)
 		return -ENODEV;
 	take_over_console(&fb_con, first_fb_vc, last_fb_vc, fbcon_is_default);
+	register_fb_client(&fbcon_client, NULL);
 	return 0;
 }
 
 void __exit fb_console_exit(void)
 {
+	unregister_fb_client(&fbcon_client);
 	give_up_console(&fb_con);
 }

===== include/linux/fb.h 1.53 vs edited =====

include/linux/fb.h +60 -0

90 lines not on this page · raw message

author
#5 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

James, if you are ok, can you get that upstream to Linus asap so I can start pushing the driver bits for radeon & aty128 ?

Ben.

#6 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Quoted 3 lines

James, if you are ok, can you get that upstream to Linus asap so I can start pushing the driver bits for radeon & aty128 ?

Working on it. I'm thinking about also how it effects userland and how userland affects the console if present. Basically the logic will go

pci suspend -> framebuffer driver supend function -> call each client

Just give me a few days to piece it together.

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

author
#7 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Quoted 9 lines · James Simmons
Quoted 2 lines

James, if you are ok, can you get that upstream to Linus asap so I can start pushing the driver bits for radeon & aty128 ?

Working on it. I'm thinking about also how it effects userland and how userland affects the console if present. Basically the logic will go

pci suspend -> framebuffer driver supend function -> call each client

Just give me a few days to piece it together.

Right now, we don't have a proper userland notification. So far, the main affected thing is XFree, but this is ok as it will have received a suspend request via /dev/apm_bios (which we emulate on PowerMacs), and so won't touch the framebuffer until resumed.

There isn't much we can do against a userland client tapping the framebuffer that it mmap'ed previously. I don't know how feasible it would be to sort of "hack" this process mapping on the fly (would involve some nasty SMP synchronisation issues) so that the userland process is just put to sleep on fb access while the fb is suspended (or get a SEGV). We probably want to extend the notification mecanism to userland in some way, but this isn't something i cover in this patch.

Ben.

#8 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Hi!

Quoted 15 lines
Quoted 9 lines
Quoted 2 lines

James, if you are ok, can you get that upstream to Linus asap so I can start pushing the driver bits for radeon & aty128 ?

Working on it. I'm thinking about also how it effects userland and how userland affects the console if present. Basically the logic will go

pci suspend -> framebuffer driver supend function -> call each client

Just give me a few days to piece it together.

Right now, we don't have a proper userland notification. So far, the main affected thing is XFree, but this is ok as it will have received a suspend request via /dev/apm_bios (which we emulate on PowerMacs), and so won't touch the framebuffer until resumed.

Quoted 8 lines

There isn't much we can do against a userland client tapping the framebuffer that it mmap'ed previously. I don't know how feasible it would be to sort of "hack" this process mapping on the fly (would involve some nasty SMP synchronisation issues) so that the userland process is just put to sleep on fb access while the fb is suspended (or get a SEGV). We probably want to extend the notification mecanism to userland in some way, but this isn't something i cover in this patch.

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)
Pavel

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
author
#9 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Quoted 5 lines · Pavel Machek

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

I admit I quite like this solution. It would also help displaying something sane (blank, pattern, whatever) on screen during driver teardown instead of the junk left by X...

I'll look into including that switch into my pmac code as well and see if it works properly in all cases (I think so). Also, recent DRI CVS finally has working suspend/resume (works on console switch too).

Ben.

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

#10 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Quoted 10 lines
Quoted 6 lines

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

I admit I quite like this solution. It would also help displaying something sane (blank, pattern, whatever) on screen during driver teardown instead of the junk left by X...

There is the case of framebuffer without VT console. Of course X can't work except with specific patches. X shouldn't be touching the console.

#11 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

In reply to Benjamin Herrenschmidt

Hi.

Would this play well with the suspend process itself displaying output? (Eg progress, errors...).

Regards,

Nigel

Quoted 23 lines · Benjamin Herrenschmidt
Quoted 5 lines · Pavel Machek

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

I admit I quite like this solution. It would also help displaying something sane (blank, pattern, whatever) on screen during driver teardown instead of the junk left by X...

I'll look into including that switch into my pmac code as well and see if it works properly in all cases (I think so). Also, recent DRI CVS finally has working suspend/resume (works on console switch too).

Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 14 lines
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

You see, at just the right time, when we were still powerless,
Christ died for the ungodly.
	-- Romans 5:6, NIV.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
#12 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Hi!

Quoted 2 lines

Would this play well with the suspend process itself displaying output? (Eg progress, errors...).

Yes.
Pavel

...

Quoted 21 lines
Quoted 21 lines
Quoted 5 lines

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

I admit I quite like this solution. It would also help displaying something sane (blank, pattern, whatever) on screen during driver teardown instead of the junk left by X...

I'll look into including that switch into my pmac code as well and see if it works properly in all cases (I think so). Also, recent DRI CVS finally has working suspend/resume (works on console switch too).

Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Signature · 9 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
author
#13 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

In reply to Pavel Machek
Quoted 6 lines

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

I tried using it on pmac, but it causes hell with XFree. I'm not sure what's up yet, I suspect it may be XFree still doing things after calling the RELDISP ioctl but I'm not completely sure yet.

The setup XFree + DRI is working without switching to suspend console (with only the apm_bios emulation for XFree to suspend/restore itself) but not when switching to suspend console right before doing the apm emulation callbacks (which should be ignored by X since it's no longer the frontmost process at this point).

For some reason, it seems that after we have switched to the suspend console, we race with the X server on accel engine, and on resume, the X server just crashes.

Ben.

#14 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Quoted 4 lines

For some reason, it seems that after we have switched to the suspend console, we race with the X server on accel engine, and on resume, the X server just crashes.

Are you shutting down the accel engine in the fbdev driver on suspend?

#15 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

In reply to Benjamin Herrenschmidt

Hi!

Quoted 9 lines
Quoted 5 lines

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

I tried using it on pmac, but it causes hell with XFree. I'm not sure what's up yet, I suspect it may be XFree still doing things after calling the RELDISP ioctl but I'm not completely sure yet.

Sounds like XFree bug to me ;-).
Pavel

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
#16 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

In reply to Pavel Machek
Quoted 6 lines

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

Not very helpful on embedded systems that use the framebuffer without the VT console.

#17 lore raw

Re: [Linux-fbdev-devel] [PATCH] Framebuffer: 2nd try: client notification mecanism & PM

Hi!

Quoted 8 lines
Quoted 5 lines

I believe solution to this is simple: always switch to kernel-owned console during suspend. (swsusp does it, there's patch for S3 to do the same). That way, Xfree (or qtopia or whoever) should clean up after themselves and leave the console to the kernel. (See kernel/power/console.c)

Not very helpful on embedded systems that use the framebuffer without the VT console.

Okay, that might be a problem. But such system will need some special notification... Is VT so much overhead?
Pavel

Signature · 2 lines
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]