MTK platform LCD driver framework (2)

Previous blog link: http://blog.csdn.net/xuan_h/article/details/38519975

In the previous blog, we talked about the mtkfb_probe function. This article describes the mtkfb_probe function. I plan to analyze the specific call process from the application call. This is the core of our understanding of the driving framework, rather than simply accepting it.

1. Analysis of driver core fbmem. C (Alps \ kernel \ drivers \ video \ fbmem. c)

The following is a part of the source code, including the entry function, fb_fops, and open function in fb_fops. When the user calls the OPEN function to open the LCD, The fb_open function will be called here. We will analyze the process from this function.

Static int fb_open (struct inode * inode, struct file * file) _ acquires (& info-> lock) _ Releases (& info-> lock) {int fbidx = iminor (inode); // obtain the device number struct fb_info * Info; int res = 0; Info = get_fb_info (fbidx ); // obtain the fb_info struct if (! Info) {request_module ("FB % d", fbidx); Info = get_fb_info (fbidx); If (! Info) Return-enodev;} If (is_err (Info) return ptr_err (Info); mutex_lock (& info-> lock); If (! Try_module_get (Info-> fbops-> owner) {res =-enodev; goto out;} file-> private_data = Info; If (Info-> fbops-> fb_open) {res = Info-> fbops-> fb_open (file, info, 1); If (RES) module_put (Info-> fbops-> owner );} # ifdef evaluate (Info-> fbdefio) fb_deferred_io_open (Info, inode, file); # endifout: mutex_unlock (& info-> lock); If (RES) put_fb_info (Info ); return res;} static const struct file_operations fb_fops = {. owner = this_module ,. read = fb_read ,. write = fb_write ,. unlocked_ioctl = fb_ioctl, # ifdef config_compat.compat_ioctl = fb_compat_ioctl, # endif. MMAP = fb_mmap ,. open = fb_open ,. release = fb_release, # ifdef encoding = get_fb_unmapped_area, # endif # ifdef config_fb_deferred_io.fsync = fb_deferred_io_fsync, # endif. llseek = default_llseek,}; static int _ init fbmem_init (void) {proc_create ("FB", 0, null, & fb_proc_fops); If (register_chrdev (fb_major, "FB ", & fb_fops) // register the character device printk ("unable to get Major % d For FB Devs \ n", fb_major); fb_class = class_create (this_module, "graphics "); // create a class if (is_err (fb_class) {printk (kern_warning "unable to create FB class; errno = % LD \ n", ptr_err (fb_class )); fb_class = NULL;} return 0 ;}# ifdef modulemodule_init (fbmem_init );

The implementation of the get_fb_info function in the open function is as follows:

Static struct fb_info * get_fb_info (unsigned int idx) {struct fb_info * fb_info; If (idx> = fb_max) return err_ptr (-enodev); mutex_lock (& registration_lock ); fb_info = registered_fb [idx]; // assign an IF (fb_info) atomic_inc (& fb_info-> count) to fb_info; mutex_unlock (& registration_lock); Return fb_info ;}

Focus on the code in this function: fb_info = registered_fb [idx]; assign values to fb_info from the register_fb [] Array Based on the sub-device ID idx. When is the array register_fb [] assigned? Search for the file and find it. The call process is as follows:

Register_framebuffer (struct fb_info * fb_info)

--> Ret = do_register_framebuffer (fb_info );

--> Registered_fb [I] = fb_info;

Who calls the register_framebuffer? Here we can start to talk about our probe. The probe function calls register_framebuffer to register an fb_info struct with the kernel. The fb_info structure is the core of the LCD driver. It is the fb_info struct that the application calls open. Below we can summarize the core work of the probe function, which is also the core work of writing the entire driver:

1. Allocate the fb_info struct;

2. Set the fb_info struct;

3. register_framebuffer () registers the fb_info struct with the kernel;

In this way, when the application calls the OPEN function, it will find the submitted fb_info struct. And apply the settings to complete the corresponding operations. Of course, apart from open functions, read, write and other functions will call our fb_info. If you are interested, you can follow the source code by yourself. Now, probe is more practical.

Ii. mtkfb_probe

The following is a description in the form of function calls and comments. There are too many words, so it is a bit dizzy. It is best to follow the source code below, and the top of the function at the same level is called by a tab.

Mtkfb_probe ------------ disp_drv.c ----------------- FBI = framebuffer_alloc (sizeof (struct mtkfb_device), Dev); // 1. Assign the FBI struct: the FBI is the fb_info struct/********. The next call is closely related to the driver file provided by MTK *********/disp_init disp_drv_init_context disp_detectdevice disp_drv_get_lcm_driver // obtain the lcm_driver struct function if (lcm_count = 1) // there is only one DRV. In the lcm_driver_list of mt65xx_lcm_list.c, several screens are defined in Mak, and lcm_count is the number of LCM = lcm_driver_list [0]; // there is only one, and the first one is paid to LCM, this is the lcm_driver struct in the driver LCM-> set_util_funcs (& lcm_utils); // you can set the function LCM-> get_params (& s_lcm_params ); // obtain the LCM parameter lcm_params = & s_lcm_params; // save these parameters lcm_drv = LCM; // save LCM else for (I = 0; I <lcm_count; I ++) // traverse the lcm_driver_list struct lcm_params = & s_lcm_params; LCM = lcm_driver_list [I]; // store the lcm_driver struct LCM-> set_util_funcs (& lcm_utils); disp_drv_init_ctrl_if (); // interface settings (DBI, DPI, DSI ...) Return lcm_drv;/* Register to system */r = mtkfb_fbinfo_init (FBI); // 2. Set the FBI struct Info-> fbops = & mtkfb_ops; // 2.1, set fops memset (& var, 0, sizeof (VAR); // 2.2, clear variable parameters ...... // 2.3. Set the variable parameter r = mtkfb_check_var (& var, Info); // 2.4. Check the variable parameter mtkfb_set_par set_fb_fix (fbdev ); // 2.5. set fixed parameters ............ /* 2.6. Usually some hardware operations are required to initialize the LCD registers and time series. I haven't followed up on this part of work yet. I will find it later */............ // 3. To be continued ............ R = register_framebuffer (FBI); // 4. register the FBI struct.

The above is just a general, not perfect. As mentioned in note 2.6, we are most concerned with one piece (hardware operations ). For the time being, I have not made it too clear, so I leave it empty in the form of ellipsis. After this part is completed in the future, the general framework will be clear.

Here I also want to talk about the relationship between the fb_info struct we registered and the MTK driver? Note 3. This part will be explained next time because of the time relationship.