linux驱动模型

linux驱动模型
linux驱动模型

sysfs - _The_ filesystem for exporting kernel objects. sysfs - 用于导出内核对象(kobject)的文件系统

Patrick Mochel

翻译: tekkamanninja

10 January 2003

2003年1月10日

翻译时间:2007年12月29日

What it is:

简介:

~~~~~~~~~~~

sysfs is a ram-based filesystem initially based on ramfs. It provides

sysfs 是一个最初基于ramfs的位于内存的文件系统。它提供

a means to export kernel data structures, their attributes, and the

一些方法以导出内核的数据结构、他们的属性和

linkages between them to userspace.

他们与用户空间的连接。

sysfs is tied inherently to the kobject infrastructure. Please read

sysfs 始终与kobject的底层结构紧密相关。请阅读

Documentation/kobject.txt for more information concerning the kobject

Documentation/kobject.txt 文档以获得更多关于 kobject 接口的信息。

interface.

Using sysfs

使用

~~~~~~~~~~~

sysfs is always compiled in. You can access it by doing:

sysfs 通常被编译进内核。你可以通过使用以下命令访问它:

mount -t sysfs sysfs /sys

(此命令含义是挂载 sysfs 到根目录下的sys目录)

Directory Creation

创建目录

~~~~~~~~~~~~~~~~~~

For every kobject that is registered with the system, a directory is

一旦有 kobject 在系统中注册,就会有一个目录在sysfs中被创建。

created for it in sysfs. That directory is created as a subdirectory

这个目录是作为 kobject 的 parent 下的子目录创建的,

of the kobject's parent, expressing internal object hierarchies to

以准确的传递内核的对象层次到

userspace. Top-level directories in sysfs represent the common

用户空间。 sysfs中的顶层目录代表着内核对象层次的共同祖先;ancestors of object hierarchies; i.e. the subsystems the objects

例如:某些对象属于某个子系统。

belong to.

Sysfs internally stores the kobject that owns the directory in the

Sysfs内部存储着 kobject ,这些 kobject 在 d_fsdata 指针(在 kobject

->d_fsdata pointer of the directory's dentry. This allows sysfs to do

的dentry结构体中)中拥有目录。这使得 sysfs 可以在文件reference counting directly on the kobject when the file is opened and

打开和关闭时,直接在 kobject 上实现引用计数。

closed.

Attributes

属性

~~~~~~~~~~

Attributes can be exported for kobjects in the form of regular files in

kobject 的属性能在文件系统中以普通文件的形式导出。

the filesystem. Sysfs forwards file I/O operations to methods defined

Sysfs 为属性定义了面向文件 I/O 操作的方法,

for the attributes, providing a means to read and write kernel

以提供对内核属性的读写。

attributes.

Attributes should be ASCII text files, preferably with only one value

属性应为 ASCII 码文本文件,以一个文件只存储一个属性值为宜。

per file. It is noted that it may not be efficient to contain only

但一个文件只包含一个属性值可能影响效率,

value per file, so it is socially acceptable to express an array of

所以一个包含相同数据类型的属性值数组也是被广泛接受的。values of the same type.

Mixing types, expressing multiple lines of data, and doing fancy

混合类型、表达多行数据以及一些怪异的数据格式是会遭强烈反对。formatting of data is heavily frowned upon. Doing these things may get

这样做是很丢脸的,而且

you publically humiliated and your code rewritten without notice.

你的代码会在未通知你的情况下被重写。

An attribute definition is simply:

一个简单的属性结构定义如下:(到2.6.22.2已添加了struct module * owner;)

struct attribute {

char * name;

mode_t mode;

};

int sysfs_create_file(struct kobject * kobj, struct attribute * attr);

void sysfs_remove_file(struct kobject * kobj, struct attribute * attr);

A bare attribute contains no means to read or write the value of the

一个裸的属性并不包含读写其属性值的方法。

attribute. Subsystems are encouraged to define their own attribute

最好为子系统定义自己的属性

structure and wrapper functions for adding and removing attributes for

和 为了增删特殊对象类型的属性而 包装过的函数。

a specific object type.

For example, the driver model defines struct device_attribute like:

例如:驱动程序模型定义的device_attribute 结构体如下:

struct device_attribute {

struct attribute attr;

ssize_t (*show)(struct device * dev, char * buf);

ssize_t (*store)(struct device * dev, const char * buf);

};

int device_create_file(struct device *, struct device_attribute *);

void device_remove_file(struct device *, struct device_attribute *);

It also defines this helper for defining device attributes:

它为了定义设备的属性也定义了辅助的宏:

#define DEVICE_ATTR(_name, _mode, _show, _store) \

struct device_attribute dev_attr_##_name = { \

.attr = {.name =

.show = _show, \

.store = _store, \

};

For example, declaring

例如:声明

static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);

is equivalent to doing:

等同于这样的代码

static struct device_attribute dev_attr_foo = {

.attr= {

.name = "foo",

.mode = S_IWUSR | S_IRUGO,

},

.show = show_foo,

.store = store_foo,

};

Subsystem-Specific Callbacks

子系统特有的调用

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When a subsystem defines a new attribute type, it must implement a

当一个子系统定义一个新属性类型时,

set of sysfs operations for forwarding read and write calls to the

一系列的sysfs操作必须被执行,以帮助读写函数实现

show and store methods of the attribute owners.

属性所有者的显示和储存的方法。

struct sysfs_ops {

ssize_t (*show)(struct kobject *, struct attribute *, char *);

ssize_t (*store)(struct kobject *, struct attribute *, const char *); };

[ Subsystems should have already defined a struct kobj_type as a

[子系统应已经定义了一个kobj_type 结构体作为

descriptor for this type, which is where the sysfs_ops pointer is

这个类型的描述符,存储 sysfs_ops 的指针。

stored. See the kobject documentation for more information. ]

更多的信息参见 kobject 的文档 ]

When a file is read or written, sysfs calls the appropriate method

当一个文件被读写时,sysfs 会为这个类型调用适当的方法。

for the type. The method then translates the generic struct kobject

这个方法会将一般的 kobject 和 attribute 结构体指针转换为and struct attribute pointers to the appropriate pointer types, and

适当的指针类型后

calls the associated methods.

调用相关联的函数。

To illustrate:

示例:

#define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr)

#define to_dev(d) container_of(d, struct device, kobj)

static ssize_t

dev_attr_show(struct kobject * kobj, struct attribute * attr, char * buf)

{

struct device_attribute * dev_attr = to_dev_attr(attr);

struct device * dev = to_dev(kobj);

ssize_t ret = 0;

if (dev_attr->show)

ret = dev_attr->show(dev, buf);

return ret;

}

Reading/Writing Attribute Data

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

读写属性数据

To read or write attributes, show() or store() methods must be

在声明属性时,show() 或 store() 方法必须被指明,以实现属性的读或写。specified when declaring the attribute. The method types should be as

这些方法的类型应该和以下的设备属性simple as those defined for device attributes:

的定义一样简单。

ssize_t (*show)(struct device * dev, char * buf);

ssize_t (*store)(struct device * dev, const char * buf);

IOW, they should take only an object and a buffer as parameters.

也就是说,他们应该只以一个处理对象和一个缓冲指针作为参数。sysfs allocates a buffer of size (PAGE_SIZE) and passes it to the

sysfs 会分配一个缓冲区的大小(PAGE_SIZE)并传递给这个方法。method. Sysfs will call the method exactly once for each read or

Sysfs 将会为每次读写操作调用一次这个方法。

write. This forces the following behavior on the method

这导致了这些方法的执行会出现以下的行为:implementations:

- On read(2), the show() method should fill the entire buffer.

-在读方面,show() 方法应该填充整个缓冲区。

Recall that an attribute should only be exporting one value, or an

回想起属性应只导出了一个属性值或是一个同类型的属性值的数组, array of similar values, so this shouldn't be that expensive.

所以这个代价将不会不太高。

This allows userspace to do partial reads and seeks arbitrarily over

这使得用户空间可以局部地读和任意的搜索整个文件。

the entire file at will.

- On write(2), sysfs expects the entire buffer to be passed during the

-在些方面,sysfs 希望在第一次写操作时得到整个缓冲区。

first write. Sysfs then passes the entire buffer to the store()

之后 Sysfs 传递整个缓冲区给 store()方法。

method.

When writing sysfs files, userspace processes should first read the

当要写 sysfs 文件时,用户空间进程应该首先读整个文件,

entire file, modify the values it wishes to change, then write the

修该想要改变的值,然后回写整个缓冲区。

entire buffer back.

Attribute method implementations should operate on an identical

在读写属性值时,属性方法的执行应操作相同的缓冲区。

buffer when reading and writing values.

Other notes:

注记:

- The buffer will always be PAGE_SIZE bytes in length. On i386, this

is 4096.

- 缓冲区应总是 PAGE_SIZE 大小。对于i386,这个值为4096。

- show() methods should return the number of bytes printed into the

buffer. This is the return value of snprintf().

- show() 方法应该返回写入缓冲区的字节数,也就是 snprintf()的返回值。- show() should always use snprintf().

- show() 应始终使用 snprintf()。

- store() should return the number of bytes used from the buffer. This

can be done using strlen().

- store() 应返回缓冲区的已用字节数,可使用 strlen()。

- show() or store() can always return errors. If a bad value comes

through, be sure to return an error.

- show() 或 store() 可以返回错误值。当得到一个非法值,必须返回一个错误值。

- The object passed to the methods will be pinned in memory via sysfs

referencing counting its embedded object. However, the physical

entity (e.g. device) the object represents may not be present. Be

sure to have a way to check this, if necessary.

- 一个传递给方法的对象将会通过 sysfs 调用对象内嵌的引用计数固定在内存中。尽管如此,对象代表的物理实体(如设备)可能已不存在。如有必要,应该实现一个检测机制。

A very simple (and naive) implementation of a device attribute is:

一个简单的(未经实验证实的)设备属性例程如下:

static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf)

{

return snprintf(buf, PAGE_SIZE, "%s\n", dev->name);

}

static ssize_t store_name(struct device * dev, const char * buf)

{

sscanf(buf, "%20s", dev->name);

return strnlen(buf, PAGE_SIZE);

}

static DEVICE_ATTR(name, S_IRUGO, show_name, store_name);

(Note that the real implementation doesn't allow userspace to set the

name for a device.)

(注意:真实的程序不允许用户空间设置设备名。)

Top Level Directory Layout

~~~~~~~~~~~~~~~~~~~~~~~~~~

顶层目录

The sysfs directory arrangement exposes the relationship of kernel

sysfs 目录的安排显示了内核数据结构之间的关系。

data structures.

The top level sysfs directory looks like:

顶层 sysfs 目录如下:

block/

bus/

class/

devices/

firmware/

net/

fs/

devices/ contains a filesystem representation of the device tree. It maps

devices/ 包含了一个设备树的文件系统表示。 他直接directly to the internal kernel device tree, which is a hierarchy of

以内核设备树的形式反映了设备的层次结构。

struct device.

bus/ contains flat directory layout of the various bus types in the

bus/ 包含了各种内核总线类型的固定目录布局。

kernel. Each bus's directory contains two subdirectories:

每个总线目录包含两个子目录:

devices/

drivers/

devices/ contains symlinks for each device discovered in the system

devices/ 包含了每个系统中出现的设备指向设备目录/dev 的动态链接。

that point to the device's directory under root/.

drivers/ contains a directory for each device driver that is loaded

drivers/ 包含了一个每个已为特定总线上的设备而挂载的驱动程序的目录for devices on that particular bus (this assumes that drivers do not

(这里假定驱动没有多个总线类型)。

span multiple bus types).

fs/ contains a directory for some filesystems. Currently each

fs/ 包含了一个为文件系统设立的目录。现在每个想要导出属性的filesystem wanting to export attributes must create its own hierarchy

文件系统必须在 fs/ 下创建自己的层次结构

below fs/ (see ./fuse.txt for an example).

(可参见./fuse.txt 作为参考)。

More information can driver-model specific features can be found in

更多有关driver-model 的特性信息可以在

Documentation/driver-model/.

Documentation/driver-model/中找到。

TODO: Finish this section.

Current Interfaces

~~~~~~~~~~~~~~~~~~

当前接口

The following interface layers currently exist in sysfs:

以下的接口层普遍出现在sysfs中:

- devices (include/linux/device.h)

- 设备

----------------------------------

Structure:

结构体:

struct device_attribute {

struct attribute attr;

ssize_t (*show)(struct device * dev, char * buf);

ssize_t (*store)(struct device * dev, const char * buf);

};

Declaring:

声明:

DEVICE_ATTR(_name, _str, _mode, _show, _store);

Creation/Removal:

增/删属性:

int device_create_file(struct device *device, struct device_attribute * attr); void device_remove_file(struct device * dev, struct device_attribute * attr);

- bus drivers (include/linux/device.h)

- 总线驱动程序

--------------------------------------

Structure:

结构体:

struct bus_attribute {

struct attribute attr;

ssize_t (*show)(struct bus_type *, char * buf);

ssize_t (*store)(struct bus_type *, const char * buf);

};

Declaring:

声明:

BUS_ATTR(_name, _mode, _show, _store)

Creation/Removal:

增/删属性:

int bus_create_file(struct bus_type *, struct bus_attribute *);

void bus_remove_file(struct bus_type *, struct bus_attribute *);

- device drivers (include/linux/device.h)

- 设备驱动程序

-----------------------------------------

Structure:

结构体:

struct driver_attribute {

struct attribute attr;

ssize_t (*show)(struct device_driver *, char * buf);

ssize_t (*store)(struct device_driver *, const char * buf);

};

Declaring:

声明:

DRIVER_ATTR(_name, _mode, _show, _store)

Creation/Removal:

增/删属性

int driver_create_file(struct device_driver *, struct driver_attribute *); void driver_remove_file(struct device_driver *, struct driver_attribute *);

Linux设备驱动程序举例

Linux设备驱动程序设计实例2007-03-03 23:09 Linux系统中,设备驱动程序是操作系统内核的重要组成部分,在与硬件设备之间 建立了标准的抽象接口。通过这个接口,用户可以像处理普通文件一样,对硬件设 备进行打开(open)、关闭(close)、读写(read/write)等操作。通过分析和设计设 备驱动程序,可以深入理解Linux系统和进行系统开发。本文通过一个简单的例子 来说明设备驱动程序的设计。 1、程序清单 //MyDev.c 2000年2月7日编写 #ifndef __KERNEL__ #define __KERNEL__//按内核模块编译 #endif #ifndef MODULE #define MODULE//设备驱动程序模块编译 #endif #define DEVICE_NAME "MyDev" #define OPENSPK 1 #define CLOSESPK 2 //必要的头文件 #include //同kernel.h,最基本的内核模块头文件 #include //同module.h,最基本的内核模块头文件 #include //这里包含了进行正确性检查的宏 #include //文件系统所必需的头文件 #include //这里包含了内核空间与用户空间进行数据交换时的函数宏 #include //I/O访问 int my_major=0; //主设备号 static int Device_Open=0; static char Message[]="This is from device driver"; char *Message_Ptr; int my_open(struct inode *inode, struct file *file) {//每当应用程序用open打开设备时,此函数被调用 printk ("\ndevice_open(%p,%p)\n", inode, file); if (Device_Open) return -EBUSY;//同时只能由一个应用程序打开 Device_Open++; MOD_INC_USE_COUNT;//设备打开期间禁止卸载 return 0; } static void my_release(struct inode *inode, struct file *file)

嵌入式Linux系统中音频驱动的设计与实现

第31卷 第2期 2008年4月 电子器件 Ch in es e Jo u rnal Of Electro n Devi ces Vol.31 No.2Apr.2008 Design and Implementation of Audio Driver for Embedded Linux System YU Yue,YA O G uo -liang * (N ational A S I C S ystem Eng ine ering Center ,S outhe ast Unive rsity ,N anj ing 210096,China) Abstract:This paper intro duces the fundam ental principle and architecture of the audio system w hich con -sists of the CODEC UCB1400and the 805puls,and describes the design of audio dev ice dr iv er based on Audio Codec .97for Embedded Linux System.The paper focuses o n the implementatio n of the DM A trans -port and ioctl interface.T he audio dr iv e is running w ell in actual Embedded Linux system equipments.Key words:805plus;embedded Linux;Audio A C .97driver;DM A;ioctl interface EEACC :1130B 嵌入式Linux 系统中音频驱动的设计与实现 虞 跃,姚国良 * (东南大学国家专用集成电路系统工程中心,南京210096) 收稿日期:2007-07-09 作者简介:虞 跃(1982-),男,东南大学电子工程系国家专用集成电路工程技术研究中心硕士研究生,研究方向为嵌入式系统设计; 姚国良(1979-),男,东南大学电子工程系博士研究生,yuyueo@https://www.360docs.net/doc/ef16804912.html,. 摘 要:介绍了由805puls 处理器和U CB1400编解码芯片构成的音频系统体系结构及工作原理,接着阐述了嵌入式Linux 操作系统下基于A C .97协议标准的音频设备驱动程序的设计与实现。其中着重讲述了采用循环缓冲区进行音频数据的DM A 传输流程以及ioctl 接口的实现。此设计方案已在嵌入式L inux 系统中得到使用,运行效果良好。 关键词:805plus;嵌入式L inux ;AC .97音频驱动;DM A;ioctl 接口中图分类号:TP391 文献标识码:A 文章编号:1005-9490(2008)02-0709-03 嵌入式音频系统广泛应用于GPS 自动导航、PDA,3G 手机等移动信息终端,具备播放、录音功能的音频系统的应用使得移动信息终端上视听娱乐IP 电话、音频录制等成为可能,并推动了移动信息终端设备的发展。 在软件上,嵌入式操作系统的新兴力量Linux 的开源性,内核可定制等优点吸引了许多的开发者与开发商。它是个和U nix 相似、以核心为基础的、完全内存保护、多任务多进程的操作系统。支持广泛的计算机硬件,包括X86,A lpha,Sparc,M IPS,PPC,ARM ,NEC,MOT OROLA 等现有的大部分芯片[1]。 本文针对805puls 微处理器选用Philips 公司的编解码芯片(CODEC)U CB1400,构建了基于Au -dio Codec .97(AC .97)标准的音频系统。并介绍了该音频系统在Linux 操作系统2.4.19内核下驱动 程序的实现技术。 1 音频系统构架 1.1 微处理器805plus 805plus 是东南大学ASIC 系统工程技术研究中心和北京大学微处理器研究开发中心共同设计和开发的32bit 嵌入式微处理器,是采用H ar vard 结构的RISC 处理器。内部采用五级流水线结构,兼容16bit 和32bit 的指令系统805plus 嵌入式微处理器集成了存储接口EMI,时钟和功耗管理PM C,中断控制器INTC,通用定时器T IM ER,脉宽调制器PWM,实时时钟RT C,通用串口UA RT,LCD 控制器LCDC,AC .97控制器,同步外设接口SPI 。1.2 AC .97协议标准[2] AC'97协议标准是一套关于A C'97数字音频处理(AC'97Digital Controller)、AC '97数字串口(AC

一个简单的演示用的Linux字符设备驱动程序.

实现如下的功能: --字符设备驱动程序的结构及驱动程序需要实现的系统调用 --可以使用cat命令或者自编的readtest命令读出"设备"里的内容 --以8139网卡为例,演示了I/O端口和I/O内存的使用 本文中的大部分内容在Linux Device Driver这本书中都可以找到, 这本书是Linux驱动开发者的唯一圣经。 ================================================== ===== 先来看看整个驱动程序的入口,是char8139_init(这个函数 如果不指定MODULE_LICENSE("GPL", 在模块插入内核的 时候会出错,因为将非"GPL"的模块插入内核就沾污了内核的 "GPL"属性。 module_init(char8139_init; module_exit(char8139_exit; MODULE_LICENSE("GPL"; MODULE_AUTHOR("ypixunil"; MODULE_DESCRIPTION("Wierd char device driver for Realtek 8139 NIC"; 接着往下看char8139_init( static int __init char8139_init(void {

int result; PDBG("hello. init.\n"; /* register our char device */ result=register_chrdev(char8139_major, "char8139", &char8139_fops; if(result<0 { PDBG("Cannot allocate major device number!\n"; return result; } /* register_chrdev( will assign a major device number and return if it called * with "major" parameter set to 0 */ if(char8139_major == 0 char8139_major=result; /* allocate some kernel memory we need */ buffer=(unsigned char*(kmalloc(CHAR8139_BUFFER_SIZE, GFP_KERNEL; if(!buffer { PDBG("Cannot allocate memory!\n"; result= -ENOMEM;

Linux驱动程序工作原理简介

Linux驱动程序工作原理简介 一、linux驱动程序的数据结构 (1) 二、设备节点如何产生? (2) 三、应用程序是如何访问设备驱动程序的? (2) 四、为什么要有设备文件系统? (3) 五、设备文件系统如何实现? (4) 六、如何使用设备文件系统? (4) 七、具体设备驱动程序分析 (5) 1、驱动程序初始化时,要注册设备节点,创建子设备文件 (5) 2、驱动程序卸载时要注销设备节点,删除设备文件 (7) 参考书目 (8) 一、linux驱动程序的数据结构 设备驱动程序实质上是提供一组供应用程序操作设备的接口函数。 各种设备由于功能不同,驱动程序提供的函数接口也不相同,但linux为了能够统一管理,规定了linux下设备驱动程序必须使用统一的接口函数file_operations 。 所以,一种设备的驱动程序主要内容就是提供这样的一组file_operations 接口函数。 那么,linux是如何管理种类繁多的设备驱动程序呢? linux下设备大体分为块设备和字符设备两类。 内核中用2个全局数组存放这2类驱动程序。 #define MAX_CHRDEV 255 #define MAX_BLKDEV 255 struct device_struct { const char * name; struct file_operations * fops; }; static struct device_struct chrdevs[MAX_CHRDEV]; static struct { const char *name; struct block_device_operations *bdops; } blkdevs[MAX_BLKDEV]; //此处说明一下,struct block_device_operations是块设备驱动程序内部的接口函数,上层文件系统还是通过struct file_operations访问的。

CAN总线在嵌入式Linux下驱动程序的实现

CAN总线在嵌入式Linux下驱动程序的实现 时间:2009-11-05 09:41:22 来源:微计算机信息作者:黄捷峰蔡启仲郭毅锋田小刚 1 引言 基于嵌入式系统设计的工业控制装置,在工业控制现场受到各种干扰,如电磁、粉尘、天气等对系统的正常运行造成很大的影响。在工业控制现场各个设备之间要经常交换、传输数据,需要一种抗干扰性强、稳定、传输速率快的现场总线进行通信。文章采用CAN总线,基于嵌入式系统32位的S3C44B0X微处理器,通过其SPI接口,MCP2510 CAN控制器扩展CAN总线;将嵌入式操作系统嵌入到S3C44B0X微处理器中,能实现多任务、友好图形用户界面;针对S3C44B0X微处理器没有内存管理单元MMU,采用uClinux嵌入式操作系统。这样在嵌入式系统中扩展CAN设备关键技术就是CAN设备在嵌入式操作系统下驱动程序的实现。文章重点解决了CAN总线在嵌入式操作系统下驱动程序实现的问题。对于用户来说,CAN设备在嵌入式操作系统驱动的实现为用户屏蔽了硬件的细节,用户不用关心硬件就可以编出自己的用户程序。实验结果表明驱动程序的正确性,能提高整个系统的抗干扰能力,稳定性好,最大传输速率达到1Mb/s;硬件的错误检定特性也增强了CAN的抗电磁干扰能力。 2 系统硬件设计 系统采用S3C44B0X微处理器,需要扩展CAN控制器。常用的CAN控制器有SJA1000和MCP2510,这两种芯片都支持CAN2.0B标准。SJA1000采用的总线是地址线和数据线复用的方式,但是嵌入式处理器外部总线大多是地址线和数据线分开的结构,这样每次对SJA1000操作时需要先后写入地址和数据2次数据,而且SJA1000使用5V逻辑电平。所以应用MCP2510控制器进行扩展,收发器采用82C250。MCP2510控制器特点:1.支持标准格式和扩展格式的CAN数据帧结构(CAN2.0B);2.0~8字节的有效数据长度,支持远程帧;3.最大1Mb/s的可编程波特率;4.2个支持过滤器的接受缓冲区,3个发送缓冲区; 5.SPI高速串行总线,最大5MHz; 6.3~5.5V宽电压范围供电。MCP2510工作电压为3.3V,能够直接与S3C44B0X微处理器I/O口相连。为了进一步提高系统抗干扰性,可在CAN控制器和收发器之间加一个光隔6N137。其结构原理框图如图1: 图1.S3C44B0X扩展CAN结构框图图2.字符设备注册表 3 CAN设备驱动程序的设计 Linux把设备看成特殊的文件进行管理,添加一种设备,首先要注册该设备,增加它的驱动。设备驱动程序是操作系统内核与设备硬件之间的接口,并为应用程序屏蔽了硬件细节。在linux中用户进程不能直接对物理设备进行操作,必须通过系统调用向内核提出请求,

Linux设备驱动程序学习(18)-USB 驱动程序(三)

Linux设备驱动程序学习(18)-USB 驱动程序(三) (2009-07-14 11:45) 分类:Linux设备驱动程序 USB urb (USB request block) 内核使用2.6.29.4 USB 设备驱动代码通过urb和所有的 USB 设备通讯。urb用 struct urb 结构描述(include/linux/usb.h )。 urb以一种异步的方式同一个特定USB设备的特定端点发送或接受数据。一个USB 设备驱动可根据驱动的需要,分配多个 urb 给一个端点或重用单个 urb 给多个不同的端点。设备中的每个端点都处理一个 urb 队列, 所以多个 urb 可在队列清空之前被发送到相同的端点。 一个 urb 的典型生命循环如下: (1)被创建; (2)被分配给一个特定 USB 设备的特定端点; (3)被提交给 USB 核心; (4)被 USB 核心提交给特定设备的特定 USB 主机控制器驱动; (5)被 USB 主机控制器驱动处理, 并传送到设备; (6)以上操作完成后,USB主机控制器驱动通知 USB 设备驱动。 urb 也可被提交它的驱动在任何时间取消;如果设备被移除,urb 可以被USB 核心取消。urb 被动态创建并包含一个内部引用计数,使它们可以在最后一个用户释放它们时被自动释放。 struct urb

struct list_head urb_list;/* list head for use by the urb's * current owner */ struct list_head anchor_list;/* the URB may be anchored */ struct usb_anchor *anchor; struct usb_device *dev;/* 指向这个 urb 要发送的目标 struct usb_device 的指针,这个变量必须在这个 urb 被发送到 USB 核心之前被USB 驱动初始化.*/ struct usb_host_endpoint *ep;/* (internal) pointer to endpoint */ unsigned int pipe;/* 这个 urb 所要发送到的特定struct usb_device 的端点消息,这个变量必须在这个 urb 被发送到 USB 核心之前被 USB 驱动初始化.必须由下面的函数生成*/ int status;/*当 urb开始由 USB 核心处理或处理结束, 这个变量被设置为 urb 的当前状态. USB 驱动可安全访问这个变量的唯一时间是在 urb 结束处理例程函数中. 这个限制是为防止竞态. 对于等时 urb, 在这个变量中成功值(0)只表示这个 urb 是否已被去链. 为获得等时 urb 的详细状态, 应当检查 iso_frame_desc 变量. */ unsigned int transfer_flags;/* 传输设置*/ void*transfer_buffer;/* 指向用于发送数据到设备(OUT urb)或者从设备接收数据(IN urb)的缓冲区指针。为了主机控制器驱动正确访问这个缓冲, 它必须使用 kmalloc 调用来创建, 不是在堆栈或者静态内存中。对控制端点, 这个缓冲区用于数据中转*/ dma_addr_t transfer_dma;/* 用于以 DMA 方式传送数据到 USB 设备的缓冲区*/ int transfer_buffer_length;/* transfer_buffer 或者 transfer_dma 变量指向的缓冲区大小。如果这是 0, 传送缓冲没有被 USB 核心所使用。对于一个 OUT 端点, 如果这个端点大小比这个变量指定的值小, 对这个USB 设备的传输将被分成更小的块,以正确地传送数据。这种大的传送以连续的 USB 帧进行。在一个 urb 中提交一个大块数据, 并且使 USB 主机控制器去划分为更小的块, 比以连续地顺序发送小缓冲的速度快得多*/

linux设备驱动中常用函数

Linux2.6设备驱动常用的接口函数(一) ----字符设备 刚开始,学习linux驱动,觉得linux驱动很难,有字符设备,块设备,网络设备,针对每一种设备其接口函数,驱动的架构都不一样。这么多函数,要每一个的熟悉,那可多难啦!可后来发现linux驱动有很多规律可循,驱动的基本框架都差不多,再就是一些通用的模块。 基本的架构里包括:加载,卸载,常用的读写,打开,关闭,这是那种那基本的咯。利用这些基本的功能,当然无法实现一个系统。比方说:当多个执行单元对资源进行访问时,会引发竞态;当执行单元获取不到资源时,它是阻塞还是非阻塞?当突然间来了中断,该怎么办?还有内存管理,异步通知。而linux 针对这些问题提供了一系列的接口函数和模板框架。这样,在实际驱动设计中,根据具体的要求,选择不同的模块来实现其功能需求。 觉得能熟练理解,运用这些函数,是写号linux设备驱动的第一步。因为是设备驱动,是与最底层的设备打交道,就必须要熟悉底层设备的一些特性,例如字符设备,块设备等。系统提供的接口函数,功能模块就像是工具,能够根据不同的底层设备的的一些特性,选择不同的工具,方能在linux驱动中游刃有余。 最后就是调试,这可是最头疼的事。在调试过程中,总会遇到这样,那样的问题。怎样能更快,更好的发现并解决这些问题,就是一个人的道行咯!我个人觉得: 发现问题比解决问题更难! 时好时坏的东西,最纠结! 看得见的错误比看不见的错误好解决! 一:Fops结构体中函数: ①ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); 用来从设备中获取数据. 在这个位置的一个空指针导致 read 系统调用以-EINVAL("Invalid argument") 失败. 一个非负返回值代表了成功读取的字节数( 返回值是一个 "signed size" 类型, 常常是目标平台本地的整数类型). ②ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); 发送数据给设备. 如果 NULL, -EINVAL 返回给调用 write 系统调用的程序. 如果非负, 返回值代表成功写的字节数 ③loff_t (*llseek) (struct file *, loff_t, int); llseek 方法用作改变文件中的当前读/写位置, 并且新位置作为(正的)返回值. loff_t 参数是一个"long offset", 并且就算在 32位平台上也至少 64 位宽. 错误由一个负返回值指示. 如果这个函数指针是 NULL, seek 调用会以潜在地无法预知的方式修改 file 结构中的位置计数器( 在"file 结构" 一节中描述). ④int (*open) (struct inode *, struct file *);

Linux设备驱动模型之platform总线深入浅出

Linux设备驱动模型之platform总线深入浅出 在Linux2.6以后的设备驱动模型中,需关心总线,设备和驱动这三种实体,总线将设备和驱动绑定。在系统每注册一个设备的时候,会寻找与之匹配的驱动;相反,在系统每注册一个驱动的时候,会寻找与之匹配的设备,而匹配由总线完成。 对于依附在USB、PCI、I2C、SPI等物理总线来这些都不是问题。但是在嵌入式系统里面,在Soc系统中集成的独立外设控制器,挂接在Soc内存空间的外设等却不依附在此类总线。基于这一背景,Linux发明了一种总线,称为platform。相对于USB、PCI、I2C、SPI等物理总线来说,platform总线是一种虚拟、抽象出来的总线,实际中并不存在这样的总线。 platform总线相关代码:driver\base\platform.c 文件相关结构体定义:include\linux\platform_device.h 文件中 platform总线管理下最重要的两个结构体是platform_device和platform_driver 分别表示设备和驱动在Linux中的定义如下一:platform_driver //include\linux\platform_device.h struct platform_driver { int (*probe)(struct platform_device *); //探测函数,在注册平台设备时被调用int (*remove)(struct platform_device *); //删除函数,在注销平台设备时被调用void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); //挂起函数,在关机被调用int (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *);//恢复函数,在开机时被调用struct device_driver driver;//设备驱动结构}; 1 2 3 4 5 6 7 8

Linux设备驱动程序学习(20)-内存映射和DMA-基本概念

Linux设备驱动程序学习(20)-内存映射和DMA-基本概念 (2011-09-25 15:47) 标签: 虚拟内存设备驱动程序Linux技术分类:Linux设备驱动程序 这部分主要研究 Linux 内存管理的基础知识, 重点在于对设备驱动有用的技术. 因为许多驱动编程需要一些对于虚拟内存(VM)子系统原理的理解。 而这些知识主要分为三个部分: 1、 mmap系统调用的实现原理:它允许设备内存直接映射到一个用户进程地址 空间. 这样做对一些设备来说可显著地提高性能. 2、与mmap的功能相反的应用原理:内核态代码如何跨过边界直接存取用户空间的内存页. 虽然较少驱动需要这个能力. 但是了解如何映射用户空间内存到内 核(使用 get_user_pages)会有用. 3、直接内存存取( DMA ) I/O 操作, 它提供给外设对系统内存的直接存取. 但所有这些技术需要理解 Linux 内存管理的基本原理, 因此我将先学习VM子 系统的基本原理. 一、Linux的内存管理 这里重点是 Linux 内存管理实现的主要特点,而不是描述操作系统的内存管理理论。Linux虚拟内存管理非常的复杂,要写可以写一本书:《深入理解Linux 虚拟内存管理》。学习驱动无须如此深入, 但是对它的工作原理的基本了解是必要的. 解了必要的背景知识后,才可以学习内核管理内存的数据结构. Linux是一个虚拟内存系统(但是在没有MMU的CPU中跑的ucLinux除外), 意味着在内核启动了MMU 之后所有使用的地址不直接对应于硬件使用的物理地址,这些地址(称之为虚拟地址)都经过了MMU转换为物理地址之后再从CPU的内存总线中发出,读取/写入数据. 这样 VM 就引入了一个间接层, 它是许多操作成为可能: 1、系统中运行的程序可以分配远多于物理内存的内存空间,即便单个进程都可拥有一个大于系统的物理内存的虚拟地址空间. 2、虚拟内存也允许程序对进程的地址空间运用多种技巧, 包括映射程序的内存到设备内存.等等~~~ 1、地址类型 Linux 系统处理几种类型的地址, 每个有它自己的含义: 用户虚拟地址:User virtual addresses,用户程序见到的常规地址. 用户地址在长度上是 32 位或者 64 位, 依赖底层的硬件结构, 并且每个进程有它自己 的虚拟地址空间.

嵌入式linux android驱动工程师 面试题总汇

嵌入式linux android驱动工程师面试题总汇 1.嵌入式系统中断服务子程序(ISR)收藏中断是嵌入式系统中重要的组成部分,这导致了很多编译开发商提供一种扩展—让标准C支持中断。具代表事实是,产生了一个新的关键字__interrupt。下面的代码就使用了__interrupt关键字去定义了一个中断服务子程序(ISR),请评论一下这段代码的。 2.C语言中对位的操作,比如对a的第三位清0,第四位置1.本来应该会的,一犯晕写反了,以后注意! #define BIT3 (1<<3) #define BIT4 (1<<4) a &= ~BIT3;a |= BIT4; 3.考到volatile含义并举例: 理解出错,举了很具体的例子,连程序都搬上去了,有些理解不深的没举出来…… volatile表示这个变量会被意想不到的改变,每次用他的时候都会小心的重新读取一遍,不适用寄存器保存的副本。 volatile表示直接存取原始地址 例: 并行设备的硬件寄存器(状态寄存器) 在多线程运行的时候共享变量也要时时更新 一个中断服务子程序中访问到的的非自动变量(不太清楚,正在查找资料ing……) 4.要求设置一绝对地址为0x67a9的整型变量的值为0xaa66

当时我的写法: #define AA *(volatile unsigned long *)0xaa66AA = 0x67a9; 答案: int *ptr =(int *)0xaa66; *ptr = 0x67a9; 我感觉自己写的应该不算错吧(自我感觉,还请达人指正),我写的适合裸机下用,当做寄存器用,而答案就是适合在操作系统下的写法。 1. linux内核里面,内存申请有哪几个函数,各自的区别? 2. IRQ和FIQ有什么区别,在CPU里面是是怎么做的? 3. int *a; char *b; a 和b本身是什么类型? a、b里面本身存放的只是一个地址,难道是这两个地址有不同么? 4.xx的上半部分和下半部分的问题: 讲下分成上半部分和下半部分的原因,为何要分?讲下如何实现? 5.内核函数mmap的实现原理,机制? 6.驱动里面为什么要有并发、互斥的控制?如何实现?讲个例子? 7. spinlock自旋锁是如何实现的? 8.任务调度的机制? 【二、本人碰到】

Linux设备驱动程序简介

第一章Linux设备驱动程序简介 Linux Kernel 系统架构图 一、驱动程序的特点 ?是应用和硬件设备之间的一个软件层。 ?这个软件层一般在内核中实现 ?设备驱动程序的作用在于提供机制,而不是提供策略,编写访问硬件的内核代码时不要给用户强加任何策略 o机制:驱动程序能实现什么功能。 o策略:用户如何使用这些功能。 二、设备驱动分类和内核模块 ?设备驱动类型。Linux 系统将设备驱动分成三种类型 o字符设备 o块设备 o网络设备 ?内核模块:内核模块是内核提供的一种可以动态加载功能单元来扩展内核功能的机制,类似于软件中的插件机制。这种功能单元叫内核模块。 ?通常为每个驱动创建一个不同的模块,而不在一个模块中实现多个设备驱动,从而实现良好的伸缩性和扩展性。 三、字符设备 ?字符设备是个能够象字节流<比如文件)一样访问的设备,由字符设备驱动程序来实现这种特性。通过/dev下的字符设备文件来访问。字符设备驱动程序通常至少需要实现 open、close、read 和 write 等系统调用 所对应的对该硬件进行操作的功能函数。 ?应用程序调用system call<系统调用),例如:read、write,将会导致操作系统执行上层功能组件的代码,这些代码会处理内核的一些内部 事务,为操作硬件做好准备,然后就会调用驱动程序中实现的对硬件进 行物理操作的函数,从而完成对硬件的驱动,然后返回操作系统上层功 能组件的代码,做好内核内部的善后事务,最后返回应用程序。 ?由于应用程序必须使用/dev目录下的设备文件<参见open调用的第1个参数),所以该设备文件必须事先创建。谁创建设备文件呢? ?大多数字符设备是个只能顺序访问的数据通道,不能前后移动访问指针,这点和文件不同。比如串口驱动,只能顺序的读写设备。然而,也 存在和数据区或者文件特性类似的字符设备,访问它们时可前后移动访

linux驱动程序的编写

linux驱动程序的编写 一、实验目的 1.掌握linux驱动程序的编写方法 2.掌握驱动程序动态模块的调试方法 3.掌握驱动程序填加到内核的方法 二、实验内容 1. 学习linux驱动程序的编写流程 2. 学习驱动程序动态模块的调试方法 3. 学习驱动程序填加到内核的流程 三、实验设备 PentiumII以上的PC机,LINUX操作系统,EL-ARM860实验箱 四、linux的驱动程序的编写 嵌入式应用对成本和实时性比较敏感,而对linux的应用主要体现在对硬件的驱动程序的编写和上层应用程序的开发上。 嵌入式linux驱动程序的基本结构和标准Linux的结构基本一致,也支持模块化模式,所以,大部分驱动程序编成模块化形式,而且,要求可以在不同的体系结构上安装。linux是可以支持模块化模式的,但由于嵌入式应用是针对具体的应用,所以,一般不采用该模式,而是把驱动程序直接编译进内核之中。但是这种模式是调试驱动模块的极佳方法。 系统调用是操作系统内核和应用程序之间的接口,设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节,这样在应用程序看来,硬件设备只是一个设备文件,应用程序可以像操作普通文件一样对硬件设备进行操作。同时,设备驱动程序是内核的一部分,它完成以下的功能:对设备初始化和释放;把数据从内核传送到硬件和从硬件读取数据;读取应用程序传送给设备文件的数据和回送应用程序请求的数据;检测和处理设备出现的错误。在linux操作系统下有字符设备和块设备,网络设备三类主要的设备文件类型。 字符设备和块设备的主要区别是:在对字符设备发出读写请求时,实际的硬件I/O一般就紧接着发生了;块设备利用一块系统内存作为缓冲区,当用户进程对设备请求满足用户要求时,就返回请求的数据。块设备是主要针对磁盘等慢速设备设计的,以免耗费过多的CPU时间来等待。 1 字符设备驱动结构 Linux字符设备驱动的关键数据结构是cdev和file_operations结构体。

嵌入式LINUX四按键驱动

对一个具有四个按键的按键驱动的分析 源代码: /*Headers-------------------------------------------------*/ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #ifdef CONFIG_DEVFS_FS #include #endif /*V ars----------------------------------------------------*/ #define DEVICE_NAME "buttons" #define EXTINT_OFF (IRQ_EINT4 - 4) unsigned int buttons_major=0; unsigned int buttons_minor=0; unsigned int type = IRQT_FALLING; struct button_info { unsigned int irq_no; unsigned int gpio_port; unsigned int IN; int button_no; }; struct button_info realarm_button_info[4] = { { IRQ_EINT19, S3C2410_GPG11, S3C2410_GPG11_INP, 1 }, { IRQ_EINT8, S3C2410_GPG0, S3C2410_GPG0_INP, 2 },

如何实现Linux设备驱动模型

文库资料?2017 Guangzhou ZHIYUAN Electronics Stock Co., Ltd. 如何实现Linux 设备驱动模型 设备驱动模型,对系统的所有设备和驱动进行了抽象,形成了复杂的设备树型结构,采用面向对象的方法,抽象出了device 设备、driver 驱动、bus 总线和class 类等概念,所有已经注册的设备和驱动都挂在总线上,总线来完成设备和驱动之间的匹配。总线、设备、驱动以及类之间的关系错综复杂,在Linux 内核中通过kobject 、kset 和subsys 来进行管理,驱动编写可以忽略这些管理机制的具体实现。 设备驱动模型的内部结构还在不停的发生改变,如device 、driver 、bus 等数据结构在不同版本都有差异,但是基于设备驱动模型编程的结构基本还是统一的。 Linux 设备驱动模型是Linux 驱动编程的高级内容,这一节只对device 、driver 等这些基本概念作介绍,便于阅读和理解内核中的代码。实际上,具体驱动也不会孤立的使用这些概念,这些概念都融合在更高层的驱动子系统中。对于大多数读者可以忽略这一节内容。 1.1.1 设备 在Linux 设备驱动模型中,底层用device 结构来描述所管理的设备。device 结构在文件中定义,如程序清单错误!文档中没有指定样式的文字。.1所示。 程序清单错误!文档中没有指定样式的文字。.1 device 数据结构定义 struct device { struct device *parent; /* 父设备 */ struct device_private *p; /* 设备的私有数据 */ struct kobject kobj; /* 设备的kobject 对象 */ const char *init_name; /*设备的初始名字 */ struct device_type *type; /* 设备类型 */ struct mutex mutex; /*同步驱动的互斥信号量 */ struct bus_type *bus; /*设备所在的总线类型 */ struct device_driver *driver; /*管理该设备的驱动程序 */ void *platform_data; /*平台相关的数据 */ struct dev_pm_info power; /* 电源管理 */ #ifdef CONFIG_NUMA int numa_node; /*设备接近的非一致性存储结构 */ #endif u64 *dma_mask; /* DMA 掩码 */ u64 coherent_dma_mask; /*设备一致性的DMA 掩码 */ struct device_dma_parameters *dma_parms; /* DMA 参数 */ struct list_head dma_pools; /* DMA 缓冲池 */ struct dma_coherent_mem *dma_mem; /* DMA 一致性内存 */ /*体系结构相关的附加项*/ struct dev_archdata archdata; /* 体系结构相关的数据 */ #ifdef CONFIG_OF

从零开始搭建Linux驱动开发环境

参考: 韦东山视频第10课第一节内核启动流程分析之编译体验 第11课第三节构建根文件系统之busybox 第11课第四节构建根文件系统之构建根文件系统韦东山书籍《嵌入式linux应用开发完全手册》 其他《linux设备驱动程序》第三版 平台: JZ2440、mini2440或TQ2440 交叉网线和miniUSB PC机(windows系统和Vmware下的ubuntu12.04) 一、交叉编译环境的选型 具体的安装交叉编译工具,网上很多资料都有,我的那篇《arm-linux- gcc交叉环境相关知识》也有介绍,这里我只是想提示大家:构建跟文件系统中所用到的lib库一定要是本系统Ubuntu中的交叉编译环境arm-linux- gcc中的。即如果电脑ubuntu中的交叉编译环境为arm-linux-

二、主机、开发板和虚拟机要三者互通 w IP v2.0》一文中有详细的操作步骤,不再赘述。 linux 2.6.22.6_jz2440.patch组合而来,具体操作: 1. 解压缩内核和其补丁包 tar xjvf linux-2.6.22.6.tar.bz2 # 解压内核 tar xjvf linux-2.6.22.6_jz2440.tar.bz2 # 解压补丁

cd linux_2.6.22.6 patch –p1 < ../linux-2.6.22.6_jz2440.patch 3. 配置 在内核目录下执行make 2410_defconfig生成配置菜单,至于怎么配置,《嵌入式linux应用开发完全手册》有详细介绍。 4. 生成uImage make uImage 四、移植busybox 在我们的根文件系统中的/bin和/sbin目录下有各种命令的应用程序,而这些程序在嵌入式系统中都是通过busybox来构建的,每一个命令实际上都是一个指向bu sybox的链接,busybox通过传入的参数来决定进行何种命令操作。 1)配置busybox 解压busybox-1.7.0,然后进入该目录,使用make menuconfig进行配置。这里我们这配置两项 一是在编译选项选择动态库编译,当然你也可以选择静态,不过那样构建的根文件系统会比动态编译的的大。 ->Busybox Settings ->Build Options

嵌入式Linux下3G模块的驱动和应用

嵌入式Linux下3G模块的驱动和应用 1、开发资源 1.1、硬件资源: ZTE-mf637u(中国联通) ZTE-mu351(中国移动) 1.2、软件资源: 1.2.1、usb-modeswitch-1.1.3 libusb-0.1.12.tar.gz usb-modeswitch-1.1.3.tar.bz2 1.2.2、ppp-2.4.4 libpcap-0.9.8.tar.gz ppp-2.4.4.tar.gz 1.2.3、wvdial 1.2.3.1、wvdial-1.54.0(arm-linux-gcc 3.4.1) zlib-1.2.5.tar.bz2 openssl-0.9.7g.tar.gz openssl-0.9.7g-fix_manpages-1.patch wvstreams-4.0.1.tar.bz2

wvstreams-4.0.1-tcl84-1.patch wvdial-1.54.0.tar.gz 1.2.3.2、wvdial_1.60.4(arm-linux-gcc 4.2.2) zlib-1.2.5.tar.bz2 openssl-0.9.8n.tar.gz openssl-0.9.8n-fix_manpages-1.patch wvstreams-4.6.1.tar.gz wvdial_1.60.4.tar.gz 2、Linux开发环境 2.1、主机环境 2.1.1、主机linux系统 Fedora Core 6 2.1.2、主机编译环境 2.1.2.1、gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile

相关文档
最新文档