Adjust the kernel driver Loading Sequence

During the development of TI's solution, we were not very satisfied with the system startup time, not only from xload to uboot, uboot running and loading the kernel, the time spent on these items is about 10 s. After the kernel is started up, the loading and initialization time of various peripheral drivers is astonishing. The kernel logo (little penguin) is displayed when the kernel is loaded successfully to the LCD ), this time is about five seconds long, And I really cannot afford it !!

After reading the system startup log, we found that after the kernel is loaded successfully, we initialized time-consuming devices such as USB, I2C, and UART before the LCD displays the logo, I do not know why Ti officially did this at the beginning. I always think it is not very good, because it is the most unbearable time for the handheld device to press the boot button to display the logo on the LCD! So why don't framebuffer and LCD initialization be placed before these time-consuming devices?

After finding relevant information on the Internet, the kernel has a certain sequence when loading the device driver.Include/Linux/init. hThis file contains the following code:

/* * A "pure" initcall has no dependencies on anything else, and purely * initializes variables that couldn't be statically initialized. * * This only exists for built-in code, not for modules. */#define pure_initcall(fn)__define_initcall("0",fn,0)#define core_initcall(fn)__define_initcall("1",fn,1)#define core_initcall_sync(fn)__define_initcall("1s",fn,1s)#define postcore_initcall(fn)__define_initcall("2",fn,2)#define postcore_initcall_sync(fn)__define_initcall("2s",fn,2s)#define arch_initcall(fn)__define_initcall("3",fn,3)#define arch_initcall_sync(fn)__define_initcall("3s",fn,3s)#define subsys_initcall(fn)__define_initcall("4",fn,4)#define subsys_initcall_sync(fn)__define_initcall("4s",fn,4s)#define fs_initcall(fn)__define_initcall("5",fn,5)#define fs_initcall_sync(fn)__define_initcall("5s",fn,5s)#define rootfs_initcall(fn)__define_initcall("rootfs",fn,rootfs)#define device_initcall(fn)__define_initcall("6",fn,6)#define device_initcall_sync(fn)__define_initcall("6s",fn,6s)#define late_initcall(fn)__define_initcall("7",fn,7)#define late_initcall_sync(fn)__define_initcall("7s",fn,7s)

I will not talk much about the related explanations. I have a lot of online materials. In a word: the drivers described through these macro functions (that is, the last thing we will see in each driver file: the order in which module_init (xx_init) is loaded is based on the priority value defined here. The smaller the value, the higher the priority, the higher the loading time.

Then let's take a look at the LCD (display driver) and framebuffer (omap-main.c) related to the display, we can see that the LCD driver is described by module_init, and framebuffer is described by late_initcall, no wonder the LCD logo is displayed after all the device drivers are loaded!

Here, I will describe the LCD Driver with arch_initcall, and describe the framebuffer driver with module_init, so that the logo will be displayed after the kernel is loaded successfully!