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:

1. Each subsystem (fbcon, fbmem, xxxfb) will have their own module_init. Thus, explicit calls to each subsystem's init functions are eliminated.

2. The struct fb_drivers array in fbmem.c can be removed. This slashes around 400 lines in fbmem.c

3. 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:
a. have their own __setup() routine
b. call fb_get_options("xxxfb") and pass the return value to
xxxfb_setup(). This is to maintain compatibility with the
'video=xxxfb:<options>' semantics.

4. 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/'

5. 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 <[email protected]>

Quoted 5 lines

5. 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 <[email protected]>

I don't really see a benefit but it's ok with me.

(Thanks for considering the "unified" nature of sisfb, by the way. Very considarate. Very much appreciated.)

I assume that you tested this stuff before posting it here.

Mainly cleanup, but also point #5. The i810fb, for instance, depends on agpgart, but agpgart gets initialized way after fbdev. The workaround is for i810fb to explicitly call intel_agp_init(). Besides the ugliness, forcibly initializing the agpgart subsystem out of sequence may cause problems.

Quoted 5 lines · Antonino A. Daplas

Mainly cleanup, but also point #5. The i810fb, for instance, depends on agpgart, but agpgart gets initialized way after fbdev. The workaround is for i810fb to explicitly call intel_agp_init(). Besides the ugliness, forcibly initializing the agpgart subsystem out of sequence may cause problems.

Sorry if I interrupt without deeper knowledge but doesn't this sound very strange?

Why is a subsystem initialized much later than the one which depends on it? Doesn't this look like a design error?

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.

Quoted 8 lines · Antonino A. Daplas

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.

Quoted 5 lines

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.

My main concern with this change is that it will be no longer possible to change initialization order (and hence choose the primary display for systems with multiple graphics adapters) by specifying `video=xxxfb' on the kernel command line.

Quoted 15 lines · Geert Uytterhoeven

Quoted 8 lines · Antonino A. Daplas

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.

Quoted 5 lines

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.

Quoted 4 lines

My main concern with this change is that it will be no longer possible to change initialization order (and hence choose the primary display for systems with multiple graphics adapters) by specifying `video=xxxfb' on the kernel command line.

I see your point. But, can we use "fbcon=" setup options to choose which fb gets mapped to what console? We already have fbcon=map:<option> so we can choose which becomes the primary display. Granted the "fbcon=" setup is currently broken, but if fixed, will that be a fair compromise?

Quoted 21 lines · Antonino A. Daplas

Quoted 19 lines · Geert Uytterhoeven

Quoted 8 lines · Antonino A. Daplas

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.

Quoted 5 lines

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.

My main concern with this change is that it will be no longer possible to change initialization order (and hence choose the primary display for systems with multiple graphics adapters) by specifying `video=xxxfb' on the kernel command line.

Quoted 4 lines

I see your point. But, can we use "fbcon=" setup options to choose which fb gets mapped to what console? We already have fbcon=map:<option> so we can choose which becomes the primary display. Granted the "fbcon=" setup is currently broken, but if fixed, will that be a fair compromise?

Yes, sounds fine.

Just thinking of something else: right now it's possible to disable a fbdev by saying `video=xxxfb:off'. This can be useful if the fbdev driver doesn't work with your hardware. After you change, individual fbdev drivers will have to reimplement this theirselves in their __setup() functions.