[PATCH] fbdev: Clean up framebuffer initialization
This patch probably deserves discussion among developers. Currently, the framebuffer system is initialized in a roundabout manner. First, drivers/char/mem.c calls fbmem_init(). fbmem_init() will then iterate over an array of individual drivers' xxxfb_init(), then each driver registers its presence back to fbmem. During console_init(), drivers/char/vt.c will call fb_console_init(). fbcon will check for registered drivers, and if any are present, will call take_over_console() in drivers/char/vt.c. This patch changes the initialization sequence so it proceeds in this manner: Each driver has its own module_init(). Each driver calls register_framebuffer() in fbmem.c. fbmem.c will then notify fbcon of the driver registration. Upon notification, fbcon calls take_over_console() in vt.c. The following are the changes brought about by this patch: - Each subsystem (fbcon, fbmem, xxxfb) will have their own module_init. Thus, explicit calls to each subsystem's init functions are eliminated. - The struct fb_drivers array in fbmem.c can be removed. This slashes around 400 lines in fbmem.c - Parsing of kernel boot options were done by fbmem.c calling each driver's xxxfb_setup() function. Because this is not possible with this patch, drivers can choose to either: - have their own __setup() routine - call fb_get_options("xxxfb") and pass the return value to xxxfb_setup(). This is to maintain compatibility with the 'video=xxxfb:<options>' semantics. - Getting a framebuffer console will occur a bit late during the boot process since the initialization sequence will depend upon the link order. So, 'video/' is moved up in drivers/Makefile, shortly after 'pci/' - Because driver initialization will be dependent on the link order, hardware that depends on other subsystems (agpgart, usb, serial, etc) may choose to initialize after the subsystems they depend on. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Showing
Please register or sign in to comment