Camera驱动在Linux内核的移植

题_Camera驱动在Linux内核的移植

Camera驱动在Linux内核的移植Linux 3.0.8 内核的配置系统由以下3 个部分组成：

> Makefile：分布在Linux 内核源代码中的Makefile，定义Linux 内核的编译规则

> 配置文件Kconfig：给用户提供配置选择的功能

> 配置工具：包括配置命令解释器（对配置脚本中使用的配置命令进行解释）和配置用户界面（提供字符界面和图形界面）。这些配置工具都是使用脚本语言编写的，如Tcl/TK、perl 等。

在Linux 内核中增加程序需要完成以下 3 项工作：

> 1. 将编写的源代码复制到Linux 内核源代码的相应目录

> 2. 在目录的Kconfig 文件中增加新源代码对应项目的编译配置选项

> 3. 在目录的Makefile 文件中增加对新源代码的编译条目

1. 实例引导：S3C2440 处理器的RTC 与LED 驱动配置。

首先，在Linux/drivers/char 目录中包含了S3C2410 处理器的RTC 设备驱动源代码s3c2410-rtc.c。

而在该目录的Kconfig 文件中包含S3C2410_RTC 的配置项目：

config S3C2410_RTC

bool "S3C2410 RTC Driver"

depends on ARCH_S3C2410

help

RTC （Realtime Clock）driver for the clock inbuilt into the Samsung S3C2410. This can provide periodic interrupt rates from 1Hz to 64Hz for user programs, and wakeup from Alarm.

上述Kconfig 文件的这段脚本意味着只有在ARCH_S3C2410 项目被配置的情况下，才会出现S3C2410_RTC 配置项目，这个配置项目为布尔型（要么编译入内核，要么不编译，选择"Y" 或"N" ），菜单撒很难过显示的字符串为"S3C2410 RTC Driver"，"help" 后面的内容为帮助信息。

除了布尔型的配置项目外，还存在一种三态型（tristate）配置选项，它意味着要么编译入内核，要么编译为内核模块，选项为"Y"、"M” 或"N"。

在目录的Makefile 中关于S3C2410_RTC 的编译脚本为：

obj-$(CONFIG_S3C2410_RTC) += s3c2410-rtc.o

上述脚本意味着如果S3C2410——RTC 配置选项背选择为"Y" 或"M"，即obj-$(CONFIG_S3C2410_RTC) 等同于obj-y 或obj-m 时，则编译s3c2410-rtc.c，选择"Y" 的情况直接会将生成的目标代码直接连接到内核，为"M" 的情况则生成模块s3c2410-rtc.ko（由于S3C2410_RTC 为布尔型，实际不会为"M"）；如果S3C2410_RTC 配置选项将选择为"N"，即obj-$(CONFIG_S3C2410_RTC) 等同于obj-n 时，则不编译s3c2410-rtc.c。

一般而言，驱动工程师在内核源代码的drviers 目录的相应子目录中增加新设备驱动的源代码，并增加或修改Kconfig 配置脚本和Makefile 脚本，完全仿照上述过程执行即可。

再如，为S3C2410 的LED 编写了驱动，源代码为s3c2410-led.c，为使内核能支持对该模块的编译配置，应进行如下 3 项处理。

> 将编写的s3c2410-led.c 源代码复制到linux/drivers/char 目录

> 在目录的Kconfig 文件中增加LED 的编译配置选项，如下所示：

config S3C2410_LED

bool "S3C2410 LED Driver"

depends on ARCH_S3C2410

help

LED driver for the Samsung S3C2410.

> 在目录的Makefile 文件中增加对s3c2410-led.c 源代码的编译，如下所示：

obj-$(CONFIG_S3C2410_LED) += s3c2410-led.o

2. Makefile

下面对内核源代码各级子目录中的kbuild Makefile 进行介绍，这部分是内核模块或设备驱动的开发者最常接触到的。

kbuild Makefile 的语法包括如下几个方面。

（1）目标定义

目标定义用来定义哪些内容要作为模块编译，哪些要编译并连接进内核。

例如：obj-y += foo.o

表示要由foo.c 或者foo.s 文件编译得到foo.o 并连接进内核，而obj-m 则表示该文件要作为模块编译。除了y、m 以外的obj-x 形式的目标都不会被编译。而更常见的做法是根据 .config 文件的CONFIG 变量来决定文件的编译方式，如下表示：

obj-$(CONFIG_ISDN) += isdn.o

ob 课题_Camera驱动在Linux内核的移植_文档下载https://www.sodocs.net/doc/2814321957.html,/b-004408600242a8956aece406.html

j-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o

除了obj- 形式的目标以外，还有lib-y library库、hostprogs-y 主机程序等目标，但是基本都应用在特定的目录和场合下。

（2）多文件模块的定义

如果一个模块由多个文件组成，这时候应采用模块名加-objs 后缀或者-y 后缀的形式来定义模块的组成文件。如下面的例子所示：

obj-$(CONFIG_EXT2_FS) += ext2.o

ext2-y := balloc.o bitmap.o

ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o

模块的名字为ext2，由balloc.o 和bitmap.o 两个目标文件最终连接生成ext2.o 直至ext2.ko 文件，是否包括xattr.o 取决于内核配置文件的配置情况。如果CONFIG_EXT2_FS 的值是y 也没有关系，在此过程中生成的ext2.o 将被连接进built-in.o 最终连接进内核。这里需要注意的一点是，该kbuild Makefile 所在的目录中不能再包含和模块名相同的源文件和ext2.c/ext2.s。

或者写如-objs 的形式：

obj-$(CONFIG_ISDN) +=isdn.o

isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o

（3）目录层次的迭代

示例：obj-$(CONFIG_EXT2_FS) += ext2/

当CONFIG_EXT2_FS 的值为y 或m时，kbuild 将会把ext2 目录列入向下迭代的目标中，具体ext2 目录下的文件是要作为模块编译还是链入内核由ext2 目录下的Makefile 文件的内容决定。

3. Kconfig

（1）菜单入口

大多数的内核配置选项都对应Kconfig 中的一个菜单入口，如下所示：

config MODVERSIONS

bool "Set version information on all module symbols"

depends on MODULES

help

Usually, modules have to be recompiled whenever you switch to a new kernel.....

"config" 关键字定义新的配置选项，之后的几行定义了该配置选项的属性。配置选项的属性包括类型、数据范围、输入提示、依赖关系（及反向依赖关系）、帮助信息和默认值等。

每个配置选项都必须制定类型，类型包括bool、tristate、string、hex 和int，其中tristate 和string 是两种基本的类型，其他类型都基于这两种基本类型。类型定义后可以紧跟输入提示，下面的两段脚本是等价的。

脚本1：bool "Networking support"

脚本2: bool

prompt "Networking support"

输入提示的一般格式的如下所示：

prompt [if ]

其中可选的if 用来表示该提示课题_Camera驱动在Linux内核的移植_文档下载https://www.sodocs.net/doc/2814321957.html,/b-004408600242a8956aece406-2.html 的依赖关系。

默认值的格式如下所示：default [if ]

一般配置选项可以存在任意多个默认值，这种情况下，只有第一个被定义的值是可用的。如果用户不设置对应的选项，配置选项的值就是默认值。

依赖关系的格式如下所示：depends on (或者requires)

如果定义了多个依赖关系，他们之间用“&&”间隔。依赖关系也可以应用到该菜单中所有的其他选项中（这些选项同样可接受if 表达式），下面的两端段脚本是等价的。

脚本1：bool "foo" if BAR

default y if BAR

脚本2: depends on BAR

bool "foo"

default y

反向依赖关系的格式如下所示：select [if ]

depends能限定一个symbol 的上限，即如果A 依赖于B，则在B 被配置为"Y" 的情况下，A 可以为“Y"、"M" 和"N"；在B 被配置为“M" 情况下，A 可以被配置为"M" 或"N"；B 在被配置为"N" 的情况下，A 只能为“N"。

select 能限定一个symbol 的下限，若 A 反向依赖于B，则 A 的配置值会高于或等于B（正好与depends)。如果symbol 反向依赖于多个对象，则它的下陷是这些对象的最大值。

kbuild Makefile 中的expr (表达式）定义如下所示：

::=

'='

'!='

' ( ' ' ) '

' ! '

'&&'

' || '

也就是说expr 是由symbol 、两个symbol 相等、两个symbol 不等以及expr 的赋值、非、与、或运算构成。而symbol 分为两类，一类是由菜单入口定义配置选项定义的非常数symbol，另一类是作为expr 组成部分的常数symbol。

数据范围的格式如下：

rang [if ]

为int 和hex 类型的选项设置可以接受的输入值范围，用户只能输入大于等于第一个symbol，小于等于第二个symbol 的值。

帮助信息的格式如下：help(或--help--)

结束

帮助信息完全靠文本缩进识别结束。"--help--" 和"help" 在作用上没有区别，设计"--help--" 的初衷在于将文件中的配置逻辑与给开发人员的提示分开。menuconfig 关键字的作用与config 类似，但它在config 的基础上要求所有的子选项作为独立的行显示。

（2）菜单结构

菜单入口在菜单树结构中的位置可由两种方法决定。第一种方式如下所示：

menu "Networking device support"

depends on NET

config NETDEVICES

....

endmenu

所有处于"menu" 和"endmenu" 之间的菜单入口都会成为"Network device support" 的子菜单。而且，所有子菜单选项都会继承父菜单的依赖关系，比如，" Network device support" 对"Net" 的依赖被加到了配置选项NETDEVICES 的依赖列表中。

另一种方式是通过分析依赖关系生成菜单结构。如果菜单选项在一定程度上依赖于前面的选项，它就恩能能成为该选项的子菜单。如果父选项为"N"，则子选项不可见；如果父选项为"Y" 或"M" ，则子选项可见，例如：

config MODULES

bool "Enable loadable module support"

config MODVERSIONS

bool "Set version information on all module symbols"

depends on MODULES

comment "module support disabled"

depends on !MODULES

MODVERSIONS 直接依赖MODULES，如果MODULES 不为“N"，该选项才可见。

除此之外，Kconfig 中还可能使用“choices.....endchoice"、"comment"、"if ... endif" 这样的语法结构。其中"choices .. end choice” 的结构如下所示：

choice

endchoice

它定义一个选择群，其接受的选项（chioce options）可以是前面描述的任何属性。在课题_Camera驱动在Linux内核的移植_文档下载https://www.sodocs.net/doc/2814321957.html,/b-004408600242a8956aece406-3.html 一个硬件有多个驱动的情况下使用，使用选择可以实现最终只有一个驱动被编译进内核或模块。选择群还可以接受的另一个选项是“optional”，这样菜单入口就被设置为"N"，没有被选中。

4. 应用实例：在内核中新增加驱动代码目录和子目录

假设要在内核源代码drivers 目录下为ARM 体系结构新增如下用于test driver 的树型目录：

|--test

|--cpu

|--cpu.c

|--test.c

|--test_client.c

|--test_ioctl.c

|--test_proc.c

|--test_queue.c

在内核中增加目录和子目录，我们需为相应的新增目录创建Kconfig 和Makefile 文件，而新增目录的父目录中的Kconfig 和Makefile 文件爱也需要修改，以便新增的Kconfig 和Makefile 文件能被引用。

在新增的test 目录下，应该包含如下Kconfig 文件：

#

#Test driver configuration

#

menu "TEST Driver"

comment " TEST Driver"

config CONFIG_TEST

bool "TEST support"

config CONFIG_TEST_USER

tristate "TEST user-space interface"

depends on CONFIG_TEST

endmenu

由于TEST_driver 对于内核来说是新的功能，所以首先需要创建一个菜单TEST Driver；然后显示" TEST support"，等待用户选择；接下来判断用户是否选择了TEST Driver，如果是（CONFIG_TEST=y），则进一步显示子功能：用户接口与CPU 功能：用户接口与CPU 功能支持；由于用户接口功能可以被编译成内核模块，所以这里的询问语句使用了tristate。