Chinaunix首页 | 论坛 | 博客
  • 博客访问: 25356
  • 博文数量: 3
  • 博客积分: 1744
  • 博客等级: 上尉
  • 技术积分: 110
  • 用 户 组: 普通用户
  • 注册时间: 2009-12-16 18:27
文章分类
文章存档

2012年(3)

分类: 嵌入式

2012-04-25 18:44:32

要了解Linux设备驱动,首先要理解linuxbusdevicedriver三个概念。

Bus就是总线,除了我们通常知道的i2cspiusb等总线之外,Linux中还有一个很重要的总线platform总线,虽然这个总线是虚拟的,但并不妨碍它的重要性(暂不谈)。

Linux驱动模型中devicedriver都挂在总线上,也就是总线上会维护一个devices链表和一个drivers的链表,当新加入一会device或的时候,linux kernel会将这个device加入它所属的busdevices链表中,然后扫描这个busdrivers链表,对于每一个driver调用bus指定的match函数,如果匹配的话就调驱动的probe函数,probe函数是初始化设备驱动的关键函数(初始化设备,注册设备访问接口等),同样在加载一个驱动的时候,加入到相应的busdrivers链表的同样也会扫描busdevices列表,match成功就调用probe

可以看出,要将一个设备驱动加载起来,不但要实现驱动代码,还要加入相应的设备结构代码,而且他们的总线类型要匹配。例如如果设备是挂在i2c总线上,那么驱动我们需要写成struct i2c_driver的结构,而设备则应该实现成i2c_board_info(会转换成struct i2c_dev)结构;平台设备的device端要写成struct platform_device结构,驱动端需要写成struct platform_driver结构,而且这两个结构体的.name成员必须一样才能匹配上。

好了,devicedriver都实现好了,但是它们什么时候成就良缘呢?这就不得不提起前面说的bus这个职业红娘了。devicedriver将自己的个人信息提交给bus这个红娘之后就是默默的祈祷、等待。Bus红娘在获取到一个新的device(征婚男?)driver(征婚女?)的信息之后,就会把新加入的这个靓男的资料加入到征婚男列表里面,然后翻出证婚女列表来看,一个一个找,看看有没有条件和这个新加入的征婚男相匹配(match)的,如果有,OK他们俩可以谈恋爱(probe)去了,给他们相互的联系方式吧,中介费bus红娘落袋为安,至于他们恋爱谈得如何是否结婚生子这个bus红娘才不会管。这么看来bus红娘还是很有职业道德的,收了钱就会认认真真的把事情干好,不会光喊为人民服务这么伟大的口号,而是实实在在的帮助很多单身解决了终生幸福问题。而且难能可贵的是,bus红娘很讲原则的不会只要有钱什么都干,你要是个靓男(device),OKbus红娘会很负责的去靓女群(drivers)中给你找对象,不会给你也牵手一个靓仔回来,bus红娘说:“我不支持同性恋”。

为了早日过上幸福的二人生活, devices们早早的就去了bus红娘婚介所登记,盼星星盼月亮,有的device终于等到了自己的driver, 牵手而去。久久等不到另一半的device忍不住了,过来问bus红娘怎么回事,bus红娘说:“符合你条件的另一半还没有出现,我也没办法,回去继续等吧!”,能怎么办呢,继续等吧,bus红娘很有信誉的,收钱绝对办事。Device回到家中烧起了高香:“哪位大神显显灵,让我的女神早日出现吧!”

看到device如此执着、如此虔诚,bus红娘也帮不上忙,善良的我们是不是想想办法帮帮他吧(我们可以帮device早日找到他的另一半,谁来解决我们的单身问题,谁来结束我们的苦逼生活呢,shit!)

Linux中初始化程序是分等级的,在init.h中我们可以找到

#define early_initcall(fn) __define_initcall("early",fn,early)

#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)

一共17个等级(实际上后接_sync7个等级是几乎没有用到的)。优先级从上往下越来越低,early > 0 > 1....> 7s(从下面的INITCALLS的链接顺序可以看出)

start_kernel->rest_init

系统在启动后在rest_init中会创建init内核线程

init->do_basic_setup->do_initcalls

do_initcalls中会把.initcall.init.中的函数依次执行一遍:

 

for (call = __initcall_start; call < __initcall_end; call++) {

.    .....

result = (*call)();

.    ........

}

 

这个__initcall_start是在文件定义的:

 .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {

   __initcall_start = .;

   INITCALLS

   __initcall_end = .;

  }

而在Vmlinux.lds.h中我们可以找到

#define INITCALLS \

*(.initcallearly.init) \

VMLINUX_SYMBOL(__early_initcall_end) = .; \

   *(.initcall0.init) \

   *(.initcall0s.init) \

   *(.initcall1.init) \

   *(.initcall1s.init) \

   *(.initcall2.init) \

   *(.initcall2s.init) \

   *(.initcall3.init) \

   *(.initcall3s.init) \

   *(.initcall4.init) \

   *(.initcall4s.init) \

   *(.initcall5.init) \

   *(.initcall5s.init) \

*(.initcallrootfs.init) \

   *(.initcall6.init) \

   *(.initcall6s.init) \

   *(.initcall7.init) \

   *(.initcall7s.init)

可以看到优先级越来越低。

好吧,这么多的等级,怎么让driver早些出现呢,可不可以随便指定一个呢,比如直接用pure_initcall。大哥,虽然没人说你这样做伤天害理,但大家都是文明人,买车票上厕所都是要排队的。不过孕妇是可以不排队的,好吧,我们就让指定的driver享享孕妇的待遇吧。

但是查队插到什么地方好呢,是不是越靠前越好呢?当然不是,我们先来理理通常的初始化函数的顺序设定。通常设备的加载是arch_initcall,从init/main.c看起:

-->Start_kernel (kernel启动的第一个函数)

...

-->setup_arch (arch/arm/kernel/setup.c)

...

-->init_machine = mdesc->init_machine//一般的设备都是在                                       //mdesc->init_machine中定义加载

另外我们可以在arch/arm/kernel/setup.c中看到:

static int __init customize_machine(void)

{

/* customizes platform devices, or adds new ones */

if (init_machine)

init_machine();

return 0;

}

arch_initcall(customize_machine);

这里对customize_machine定义的初始化级别为arch_initcall,也就是说一般device加载的优先级是arch_initcall,那么我们就没必要将driver提到arch_initcall之前吧,不然driver妹妹也是再那空等,咱们device还是要讲点绅士风度的,约会不迟到。

好吧我们就可以给开后门的这个驱动优先级设定为arch_initcallarch_initcall_syncsubsys_initcallubsys_initcall_syncfs_initcallfs_initcall_syncrootfs_initcall等几个等级了(有的人要问了,不还有device_initcalldevice_initcall_synclate_initcalllate_initcall_sync几个等级呢?额,正常我们设备驱动都是用device_initcall这个等级的,咱们没必要帮倒忙吧)。至于具体给他那个优先级呢,这个就要考虑些其他因素了,比如这个驱动的初始化是否依赖其他设备初始化的完成,如果要依赖于某个设备的初始化,那么就优先级就必须比另外那个的低。

好吧,下面我们给出一般设备和驱动加载的优先级列表:

初始化等级

             对应的初始化设备或驱动的函数

     备注

early_initcall

migration_initspawn_ksoftirqd

主要是register_cpu_notifier

pure_initcall

init_cpufreq_transition_notifier_list

core_initcall

netlink_proto_initcpuidle_initxxx_gpio_initfilelock_initpm_initsock_initwakelocks_init

主要是一些关键部分的初始化,像gpio、通信、电源管理等部分

core_initcall_sync

postcore_initcall

backlight_class_initdma_sysclass_initi2c_initkobject_uevent_initpci_driver_initspi_inittty_class_init

主要是一些总线的节点的创建和链表初始化等(总线驱动的加载在后面)

postcore_initcall_sync

arch_initcall

xxx_init_devicexxx_devices_setupcustomize_machineplatform_init

主要是板级设备的加载(i2cspiusb、串口等以及一些外设的加载)

arch_initcall_sync

subsys_initcall

blk_ioc_inixxx_dma_initxxx_i2c_init_driverusb_initxxx_spi_init

块设备驱动、以及主要的bus总线驱动

subsys_initcall_sync

fs_initcall

inet_initalignment_initchr_dev_inittracer_alloc_buffers

fs_initcall_sync

rootfs_initcall

populate_rootfsdefault_rootfs

Rootfs先关初始化

device_initcall

一般的外设驱动的加载函数

module_init = device_initcall,外设驱动

device_initcall_sync

late_initcall

late_resume_init 

late_initcall_sync

 

不同的芯片厂家给的BSP包中具体的初始化顺序可能会有些差异,但是大概都是和这差不多。

 

另外一般的外设驱动加载函数都是device_initcall级别的,如果外设很多,必然导致这一等级的加载函数很多。如何在这同一等级中调整driver加载的顺序呢?

对于同一等级(device_initcall)中的driverAdriverBdriverA说我比driverB大点,我要排到前面点去,driverB也没有意见,那好吧,我们可以来改改Makefile试试。

下面贴我自己写的几个驱动看看,这几个驱动都是放在/drivers/i2c/chip目录下的,先看我最初的Makefile

好,接着可以从System.map中看看各个驱动的链接的顺序:

看到了吧,链接中的顺序和Makefile中的先后顺序是一模一样的。接下来我们调整一下Makefile中编译的顺序,看看链接的顺序是否也会跟着变过来。

这是修改后的顺序,把bma023放到中间了,重新编译来看看System.map里面的顺序

看到了吧,真的也跑到中间去了,这样是可以修改设备驱动的加载顺序的,说明了linux kernel下链接的顺序和编译的顺序是一样的(顶层的Makefile中规则指定的吧,具体我没弄明白)。看链接的符号表我想大家应该想起了前面定义在INITCALLS里面的*(.initcall6.init)了吧,是的上面这个函数就是按顺序放在*(.initcall6.init)这个段中的。

对于不同目录的driver如果需要调整顺序,当然也可以调整/drivers目录下Makefile下各种驱动类型的编译顺序(不过这个必须谨慎,不能随便乱改)。

总结:linux设备驱动有busdevicedriver三个重要的组成部分,先有bus,然后在bus上挂devicedriver,有匹配的才调驱动的probe函数真正的初始化设备并注册API

修改设备加载的顺序可以有两种方法,一种是修改设备加载的初始化等级,另外就是修改Makefile中的顺序。

备注:在Linux中,usbsdi2cspi等总线上可以挂设备,但是它们自己相对于系统来说也是设备,也要有自己的驱动,在linux中,所有的这些总线都挂在platform这个虚拟总线上,在customize_machine(arch_initcall)的时候,我们先会加载这些总线的platform_device结构,而这些总线的驱动(platform _driver)一般是定义为subsys_initcall级。

总线设备和驱动匹配上后就会真正的初始化总线,然后这个婚介所正式挂牌成立。这么看来platform bus就是婚介所总部了 platform bus设备节点的创建和相关结构初始化在INITCALLS之前。

阅读(3836) | 评论(0) | 转发(6) |
0

上一篇:转 Camera模块解析之驱动篇

下一篇:没有了

给主人留下些什么吧!~~