S3C2440 LCD驱动(FrameBuffer)实例开发<二>(转)

开发板自带的LCD驱动是基于platform总线写的，所以如果要使其它的LCD能够在自己的开发板上跑起来，那么就先了解platform驱动的架构，下面简单记录下自己看platform驱动时体会，简单的说platform是一种虚拟总线，那么它也是一条总线，所以它分为3个部分，platform_bus，platform_device，platform_driver。在platform_device向platform_bus注册设备，platform_driver向platform_bus注册驱动，注册后在platform_bus中会有一条device链表和driver链表，platform_bus中match函数将匹配两者的名字，如果相同那就把驱动和设备进行绑定。Linux platform driver机制和传统的device driver机制（通过driver_register进行注册）相比，一个明显的优势在于platform机制将设备本身的资源注册进内核，由内核统一管理，在驱动中使用这些资源时通过platform device提供的标准结构进行申请并使用。这样提高了驱动和资源的独立性，并且具有较好的可移植性和安全性（这些标准接口是安全的）。下面举一个简单platform驱动的例子来分析platform_device和platform_driver是怎么联系，platform_driver是怎么使用platform_device提供硬件信息的。

led_dev.c

Led_drv.c

这就是一个简单的platform驱动，这两个文件我们完全可以写道一个文件中去实现，现在看下由一个文件如何实现这个驱动：

由此可见，如果由platform驱动去实现led驱动将会多出很多东西，而这些多出来的就是我们如何把一个驱动程序融合到platform里面，那既然用platform驱动要多写那么多东西那问什么还要写基于platform的驱动呢？我的理解是基于以下几个原因：如果一个设备挂在总线上，其结果是配套的sysfs结点，设备电源管理都成为可能；隔离了BSP和驱动，在BSP中定义platform设备和设备使用的资源，设备的具体配置信息，而在驱动中，只要通过API去获取资源和数据，做到了板相关代码与驱动代码的分离，使得驱动具有更好的可移植性和更好的扩展性和跨平台性；假如我们要实现一个LCD驱动，那么我们只需修改BSP相关的代码，platform基本上不需修改，避免重复着轮子的可能性；基于platformplatform机制将设备本身的资源注册进内核，由内核统一管理。

上面platform的例子还没有完全按照linux platform的标准去写，因为阅读代码可知linux platform驱动把platform_device相关的代码放在一块，然后统一进行注册！

下面记录下如何把device添加到板级文件中（最开始还是建议写成两个文件，分别编译成模块加载，因为如果是放到板级文件中那么需要重新编译内核，这个将在编译上浪费很多时间）

步骤：

1. 在/arch/arm/plat-s3c24xx/devs.c中定义led 相关的设备及资源，代码如下：

请注意最后一行是导出led平台设备，会在mach-smdk2440.c中添加到平台设备列表中。

2. 如果还需定义led的其它信息，那么在/arch/arm/plat-s3c2410/include/mach/fb.h 为led平台设备定义一个s3c2410fb_mach_info结果体。led很简单所以没有必要再去定义，但是后面讲的LCD的平台设备需要定义！因为仅仅通过resource，驱动还无法操作LCD。

3. 不要实现，只是记录下系统还会做什么事！ 在mach-smdk2440.c中将会调用platform_add_devices()，注册平台设备。

好了对platform有了一定了解后，那么看看如果将LCD驱动写成linux设备模型的platform驱动，同样给出不使用platform架构是一个完整的字符设备驱动的lcd驱动，在给出一个符合platform模型的lcd驱动，通过这两个文件的对比，就可以知道在符合platform模型的lcd驱动中可以找到LCD驱动的全部信息，也会发现基本上所有plat_form驱动出了驱动本身的东西外，框架性的东西基本上一样的，所以如果理解了一两个platform驱动，那么以后写platform驱动或看platform代码跟不以flatform写出的代码是没有什么区别的！代码如下：

基于platform的代码在这就不贴出来了，太多了，可以参考/driver/videv/s3c2410fb.c