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>