MTK platform LCD driver framework (I)

Many learning embedded systems enter the MTK development platform, and many things are unfamiliar. On the MTK platform, you can simply light up a screen in just a few minutes. Coupled with the rapid development of MTK, there is little time to organize and learn by yourself. If you are not enterprising, do not work overtime to learn. It's easy to go ....... It is no wonder that some people say that MTK has created a group of lazy people and destroyed a group of engineers. But they are all developed based on Linux, and the core things are the same. When I was just in the industry, I sorted out the source code myself when I was confused. I want to slowly retrieve my familiar feelings and master the overall MTK framework. We also hope to help people in need. Okay! Start with the topic.

There are certainly many mistakes and incomprehension in this article, and many are not in-depth enough. You are welcome to criticize and correct them. After all, it is my personal understanding and I hope to communicate with you more. Let's take a look at MTK. If you are not familiar with the "Linux platform device driver" model, please refer to the relevant materials.

Note: --> indicates the call between functions.

I. Platform-driven: mtkfb. c

Let's start with the mtkfb. c file. Path: Alps \ mediatek \ platform \ common \ kernel \ drivers \ video \ mtkfb. c

In this file, we are very familiar with seeing the original kernel state. Below I cut out some of the most familiar source code.

static struct platform_driver mtkfb_driver ={    .driver = {        .name    = MTKFB_DRIVER,#ifdef CONFIG_PM        .pm     = &mtkfb_pm_ops,#endif        .bus     = &platform_bus_type,        .probe   = mtkfb_probe,        .remove  = mtkfb_remove,        .suspend = mtkfb_suspend,        .resume  = mtkfb_resume,.shutdown = mtkfb_shutdown,    },};

/* Register both the driver and the device */int __init mtkfb_init(void){    int r = 0;    MSG_FUNC_ENTER();#ifdef DEFAULT_MMP_ENABLE    MMProfileEnable(1);init_mtkfb_mmp_events();    init_ddp_mmp_events();    MMProfileStart(1);#endif    /* Register the driver with LDM */    if (platform_driver_register(&mtkfb_driver)) {        PRNERR("failed to register mtkfb driver\n");        r = -ENODEV;        goto exit;    }#ifdef CONFIG_HAS_EARLYSUSPEND   register_early_suspend(&mtkfb_early_suspend_handler);#endif    DBG_Init();//#ifdef MTK_DISP_CONFIG_SUPPORTConfigPara_Init();//In order to Trigger Display Customization Tool..//#endifexit:    MSG_FUNC_LEAVE();    return r;}

module_init(mtkfb_init);module_exit(mtkfb_cleanup);

After reading the above Code, you will surely know that the mtkfb_probe function is the core function. However, I do not want to talk about this part yet, because the underlying framework has not been fully analyzed. ANYONE FAMILIAR WITH platform device drivers knows that only the driver cannot run the probe function. The entry function allows you to register both driver and device. I don't know whether it's MTK or my colleagues' error annotations. I didn't find the device-related registration code in it. This article is intended to be explained by those who have read this article.

Ii. platform device: mt_devs.c

In fact, I followed the register function of the device in another place. In mt_devs.c, the path is in: mediatek \ platform \ common \ kernel \ drivers \ video (there is also a copy in the bootable \ bootloader \ LK directory, which cannot be clearly explained at present .)

1. In this file: __init int mt_board_init (void) function --> platform_device_register (& mt6575_device_fb), we can see disp_device.name = "mtkfb" in the mt6575_device_fb structure ". Compare mtkfb_driver.name = mtkfb_driver in mtkfb. C. We can find that the two have the same name. This is what we are familiar. If a device of the same name appears, the kernel calls the probe function in mtkfb. C. Now we can start to analyze the probe function.

2. Before that, let's take a look at the call process of the _ init int mt_board_init (void) function. the kmain function in C --> platform_early_init --> board_init --> mt_board_init. The source traces back to the main. c Entry of the C function. I followed because mt_devs.c is not a device registered in the form of modules we are familiar with, that is, there is no module_init () entry mark at all, in addition, the mt_board_init function registers almost all platform devices. This is something else to learn in peacetime. This also prevents you from wondering why the device driver file does not have an entry function just like me.

It's time to get off work. Next, let's talk about the work in the mtkfb_probe function.

To be continued ............