[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.