• Antonino Daplas's avatar
    [PATCH] fbdev: Clean up framebuffer initialization · 1a6c2119
    Antonino Daplas authored
    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: default avatarAntonino Daplas <adaplas@pol.net>
    Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    1a6c2119
fbcon.c 73.9 KB