linux实时时钟驱动三之代码分析

/ *****************************************************************************************************/

声明：本博内容均由http://blog.csdn.net/lmm670原创，转载请注明出处，谢谢！

/*****************************************************************************************************/

这里我们针对三星的S3C24XX系列进行RTC驱动框架的分析，关于RTC（实时时钟）的功能和硬件原理我就不在这里啰嗦了，相信大家都十分清楚，不清楚的可以google或者百度一下，我想通过RTC驱动和大家探讨一下linux驱动的一般框架，为大家在linux驱动的学习路上起到一个抛砖引玉的作用。那有哥们就要问了，为什么选择RTC驱动呢？就是因为它简单明了，大家都容易明白的东西才是好东西，好啦，废话不多说，开始进入正题：

Linux常见的驱动在driver目录下都有一个文件夹，当然我们的RTC也不例外，我们进入kernel主目录下的drivers/rtc，发现下面包含了许多开发平台的RTC驱动，我们这里是以S3C24xx为主，所以我们要寻找的是“rtc-s3c.c”这个美人儿，她是我们要分析的核心；其他几个相关联的文件分别是：alarm.c, alarm-dev.c,class.c, hctosys.c, interface.c, rtc-dev.c.这几个文件就是我们这部戏的主角儿。

看戏大家都喜欢去研究人物之间的关系，A喜欢B，B喜欢C,C又喜欢D…….这里我们也来先理顺一下这几个主角之间微妙的关系：

首先，当然是我们主角中的战斗机rtc-s3c.c，她是最顶层的直接和硬件打交道的驱动文件，每个平台，高通，marvell，三星都有自己的这部分，一般被命名为类似的”rtc-msm.c,rtc-pxa.c，rtc-s3c.c”;就像每个国家每个部落，总有一批底层工作者，在默默的为上层的骄奢淫逸，荣华富贵贡献着自己的血汗;

rtc-s3c.c上面的是interface.c，顾名思义就知道是接口文件，它主要是对rtc-s3c.c进行封装，给上层提供统一的接口，屏蔽底层差异化的东东。

Interface.c再往上就到了rtc-dev.c.，rtc-dev.c最终生成了/dev/rtc，上层的应用程序就是通过操作此文件来进行RTC的相关的设置系统时间，设置闹钟，等等。

所有整个人物关系图如下：

上层应用层序

|

|

V

rtc-dev.c

|

|

V

interface.c

|

|

V

rtc-s3c.c

好像三个文件就已经把整个RTC从底层到上层所有的东东都讲完了，那么还剩下几个文件干嘛呢？

Alarm.c和alarm-dev.c：这两个文件用来干什么呢？这里先留个悬念，后面和大家慢慢说明

class.c：提供了RTC子系统一些的公共函数，让各个RTC驱动注册集成到我们的linux内核中，她实际上是一个粘合剂。

hctosys.c：系统起来之后，会调用到这个文件中的rtc_hctosys()函数，主要功能是系统起来的时候，去读RTC硬件中的时间，然后更新我们的系统时间。

好啦，到这里，相信我们已经对整个rtc驱动各个层都比较清楚了，小时候我语文老师叫我们写作文的时候就喜欢玩“总分”结构，先“总”对整个过程有个大概把握，再“分”起来就容易多了，感觉一切都逃出不我们的“五指山”。

后面的几个小节，开始我们的“分”，从细节去分析理解每个文件。

第二节:

第一节已经分析了整个RTC驱动的框架，这一节我们开始分析真正的主角rtc-s3c.c.看一个驱动，一般都是从驱动文件的最底层看起，不知道是不是写linux内核的大师们学习过我们的《易经》，易经64卦，每一卦有6 爻，我们分析一个卦的时候，也是从底下一个爻开始分析。废话少说，把代码直接拉到最下面：



666-669行：该驱动文件的描述，作者，申明为开源，以及声明一个模块别称，这些和具体的功能无关，了解一下也不是坏事；

652-664行：这个大家再熟悉不过了，系统起来的时候回去执行s3c_rtc_init，模块卸载的时候回去调用s3c_rtc_exit；s3c_rtc_init很爽快，就干了一件事，把这个驱动注册到系统中，与对应的设备匹配起来；而他的兄弟s3c_rtc_exit完成了相反的动作；

638-648行：RTC驱动结构体，如果前面的驱动成功注册进系统后，并找到了何止相对应的设备名，则s3c_rtc_probe函数被调用，它才是驱动开始的第一炮；也就是说，系统起来的时候，只要此驱动找到了与之对应的设备名，probe函数就会被调用。

Suspend和resume也是一对好哥们，系统睡眠和唤醒的时候，分别被调用。这两个和电源管理有关的，我们就不去细究了。

下面我们进入到prboe函数中：



467-477行：从平台设备中获取中断资源；

490-504行：从平台设备中获取IO内存资源；

这里要提一下，前面驱动注册的时候用platform_driver_register();就是把驱动注册成了一个平台驱动，对应的平台设备为

struct platform_device s3c_device_rtc = {

.name = "s3c2410-rtc",

.id = -1,

.num_resources = ARRAY_SIZE(s3c_rtc_resource),

.resource = s3c_rtc_resource,

};

资源结构体：

static struct resource s3c_rtc_resource[] = {

[0] = {

.start = S3C24XX_PA_RTC,

.end = S3C24XX_PA_RTC + 0xff,

.flags = IORESOURCE_MEM,

},

[1] = {

.start = IRQ_RTC,

.end = IRQ_RTC,

.flags = IORESOURCE_IRQ,

},

[2] = {

.start = IRQ_TICK,

.end = IRQ_TICK,

.flags = IORESOURCE_IRQ

}

};

我们在回过头来跟进

int platform_get_irq(struct platform_device *dev, unsigned int num)

{

struct resource *r = platform_get_resource(dev, IORESOURCE_IRQ, num);

return r ? r->start : -ENXIO;

}

是不是一目了然了。

接着分析：



507-519行，获取clock并使能时钟，enable RTC;

524行：device_init_wakeup(&pdev->dev, 1);打开唤醒中断开关，RTC能在睡眠情况下唤醒系统，这只是一个开关，真正能不能唤醒系统，需要把中断设置为唤醒中断。

528行：把RTC驱动注册进linux系统，从此，这个RTC就在linux内核中有一席之地了，不再是“没房”一族了。

531-534行：注册失败，打道回府，后面都是徒劳。

到这里probe函数的主要功能算是完成啦。后面几行留给大家分析一下。

讲了这么多，好像还是和RTC的功能没占上半毛钱关系，什么设置闹钟，设置时间的词眼还没出现一个，下面一节开始分析这一块。

第三节:

函数把rtc驱动注册进了linux中，主要就是注册了对RTC的一些列操作，设置时间，设置闹钟等等，而这些操作都被包含在&s3c_rtcops中，我们来仔细观察这个家伙的全貌：

static const struct rtc_class_ops s3c_rtcops = {

.open = s3c_rtc_open,

.release = s3c_rtc_release,

.read_time = s3c_rtc_gettime,

.set_time = s3c_rtc_settime,

.read_alarm = s3c_rtc_getalarm,

.set_alarm = s3c_rtc_setalarm,

.irq_set_freq = s3c_rtc_setfreq,

.irq_set_state = s3c_rtc_setpie,

.proc = s3c_rtc_proc,

};

是不是很清楚了呢？所有的RTC相关的操作全在里面。读出RTC时间，设置rtc时间,设置闹钟，读取闹钟，设置rtc频率参数等等，我就不一一分析了，无非就是一些对硬件寄存器的读写操作，千篇一律，搞驱动的兄弟和他们熟悉的不能在熟悉了。

我们重点来看一个函数，那就是s3c_rtc_open：



在这个函数中我们发现只做了一件事：就是通过request_irq把 RTC的两个终端注册进系统，我们来看看这2个中断函数：



这2个函数都调用了同一个函数rtc_update_irq只是传进去的参数不一样而已，一个是闹钟中断，一个是系统时钟滴答中断。

进入代码分析：



392行：异步通知系统此中断的到来；

到这里，rtc-s3c.c已经分析完。

下面一节我们看看上层是如何和底层打交道的

第四节:

这一节我们分析RTC驱动框架的最上层rtc-dev.c


 /

系统起来的时候，rtc_dev_init会被调用，此函数生成了文件/dev/rtc.

501行：把操作集rtc_dev_fops分配给/dev/rtc，而函数rtc_dev_prepare就是在rtc-s3c.c中注册RTC驱动时被调用的；

现在上层的接口文件/dev/rtc有了，它的操作集也有了rtc_dev_fops

static const struct file_operations rtc_dev_fops = {

.owner = THIS_MODULE,

.llseek = no_llseek,

.read = rtc_dev_read,

.poll = rtc_dev_poll,

.unlocked_ioctl = rtc_dev_ioctl,

.open = rtc_dev_open,

.release = rtc_dev_release,

.fasync = rtc_dev_fasync,

};

接下来我们就看看上层是如何最终设置RTC的。

流程大致如下：

首先上层程序会去open文件/dev/rtc，得到一个文件描述符；接下来就可以对她为所欲为了：

比如：设置RTC时间，上层通过ioctl命令RTC_SET_TIME操作文件描述符，会调用到rtc_dev_ioctl中：



而rtc_set_time()位于（interface.c）,跟进去：



发现调用了rtc->ops->set_time(rtc->dev.parent, tm);即回调到了我们第3节中的结构体s3c_rtcops中的s3c_rtc_settime函数，继续跟进：



直接对RTC寄存器进行写操作，把上层传进来的时间写到rtc寄存器中去。

到这里貌似一切该结束了，好像前面还刘了一个悬念：

Alarm.c和alarm-dev.c：这两个文件用来干什么呢？

因为我拿到的这份代码是 android linux kernel，这2个文件是android的开发者添加上去的，android内核把rtc-dev.c丢弃了，取而代之的就是这2个东东，因而android下对RTC的操作文件为/dev/alarm而不是我们这里的/dev/rtc,感兴趣的哥们可以好好研究一下。

好了，整个RTC驱动框架分析到此结束了。