Linux设备驱动之UIO机制

最新推荐文章于 2022-08-19 15:34:51 发布

Embedded engineer

最新推荐文章于 2022-08-19 15:34:51 发布

阅读量1.4k

点赞数

分类专栏： linux驱动

原文链接：https://blog.csdn.net/wenwuge_topsec/article/details/9628409

版权

linux驱动专栏收录该内容

9 篇文章 2 订阅

订阅专栏

1 uio理论部分

1.1 为什么出现了UIO?

硬件设备可以根据功能分为网络设备，块设备，字符设备，或者根据与CPU相连的方式分为PCI设备，USB设备等。它们被不同的内核子系统支持。这些标准的设备的驱动编写较为容易而且容易维护。很容易加入主内核源码树。但是，又有很多设备难以划分到这些子系统中，比如I/O卡，现场总线接口或者定制的FPGA。通常这些非标准设备的驱动被实现为字符驱动。这些驱动使用了很多内核内部函数和宏。而这些内部函数和宏是变化的。这样驱动的编写者必须编写一个完全的内核驱动，而且一直维护这些代码。而且这些驱动进不了主内核源码。于是就出现了用户空间I/O框架(Userspace I/O framework)。

1.2 UIO 是怎么工作的？

一个设备驱动的主要任务有两个:

存取设备的内存
处理设备产生的中断

对于第一个任务，UIO 核心实现了mmap()可以处理物理内存(physical memory)，逻辑内存(logical memory)，虚拟内存(virtual memory)。UIO驱动的编写是就不需要再考虑这些繁琐的细节。

第二个任务，对于设备中断的应答必须在内核空间进行。所以在内核空间有一小部分代码用来应答中断和禁止中断，但是其余的工作全部留给用户空间处理。
如果用户空间要等待一个设备中断，它只需要简单的阻塞在对 /dev/uioX的read()操作上。当设备产生中断时，read()操作立即返回。UIO 也实现了poll()系统调用，你可以使用 select()来等待中断的发生。select()有一个超时参数可以用来实现有限时间内等待中断。对设备的控制还可以通过/sys/class/uio下的各个文件的读写来完成。你注册的uio设备将会出现在该目录下。假如你的uio设备是uio0那么映射的设备内存文件出现在 /sys/class/uio/uio0/maps/mapX，对该文件的读写就是对设备内存的读写。

如下的图描述了uio驱动的内核部分，用户空间部分，和uio 框架以及内核内部函数的关系

Figure 1: uio_architecture

详细的UIO驱动的编写可以参考 drivers/uio/下的例子，以及Documentation/DocBook/uio-howto.tmp/，tmpl格式的文件可以借助 docbook-utils (debian下)工具转化为pdf或者html合格等。

1.3 uio核心的实现和uio驱动的内核部分的关系

重要的结构：

struct uio_device {
	struct module    *owner;
	struct device    *dev; //在__uio_register_device中初始化
	int     minor; // 次设备id号，uio_get_minor
	atomic_t    event; //中断事件计数
	struct fasync_struct  *async_queue;//该设备上的异步等待队列//
	                            // 关于 “异步通知“ //参见LDD3第六章
	wait_queue_head_t  wait; //该设备上的等待队列，在注册设备时(__uio_register_device)初始化
	int     vma_count;
	struct uio_info   *info;// 指向用户注册的uio_info，在__uio_register_device中被赋值的
	struct kobject   *map_dir;
	struct kobject   *portio_dir;
}; 
/*
* struct uio_info - UIO device capabilities
* @uio_dev:    the UIO device this info belongs to
* @name:    device name
* @version:    device driver version
* @mem:    list of mappable memory regions, size==0 for end of list
* @port:    list of port regions, size==0 for end of list
* @irq:    interrupt number or UIO_IRQ_CUSTOM
* @irq_flags:   flags for request_irq()
* @priv:    optional private data
* @handler:    the device's irq handler
* @mmap:    mmap operation for this uio device
* @open:    open operation for this uio device
* @release:    release operation for this uio device
* @irqcontrol:   disable/enable irqs when 0/1 is written to /dev/uioX
*/  
struct uio_info {
	struct uio_device  *uio_dev; // 在__uio_register_device中初始化
	const char   *name; // 调用__uio_register_device之前必须初始化
	const char   *version; //调用__uio_register_device之前必须初始化
	struct uio_mem   mem[MAX_UIO_MAPS];
	struct uio_port   port[MAX_UIO_PORT_REGIONS];
	long      irq; //分配给uio设备的中断号，调用__uio_register_device之前必须初始化
	unsigned long    irq_flags;// 调用__uio_register_device之前必须初始化
	void      *priv; //
	irqreturn_t (*handler)(int irq, struct uio_info *dev_info); //uio_interrupt中调用，用于中断处理
	                                            // 调用__uio_register_device之前必须初始化
	int (*mmap)(struct uio_info *info, struct vm_area_struct *vma); //在uio_mmap中被调用，
	                                                   // 执行设备打开特定操作
	int (*open)(struct uio_info *info, struct inode *inode);//在uio_open中被调用，执行设备打开特定操作
	int (*release)(struct uio_info *info, struct inode *inode);//在uio_device中被调用，执行设备关闭特定操作
	int (*irqcontrol)(struct uio_info *info, s32 irq_on);//在uio_write方法中被调用，执行用户驱动的/特定操作。
};

先看一个uio 核心和 uio 设备之间关系的图，有个整体印象：

uio核心部分是一个名为"uio"的字符设备(下文称为“uio核心字符设备“)。用户驱动的内核部分使用uio_register_device向uio核心部分注册uio设备。uio 核心的任务就是管理好这些注册的uio设备。这些uio设备使用的数据结构是 uio_device。而这些设备属性，比如name, open(), release()等操作都放在了uio_info结构中，用户使用 uio_register_device注册这些驱动之前要设置好uio_info。

uio核心字符设备注册的uio_open，uio_fasync， uio_release， uio_poll， uio_read， uio_write 中除了完成相关的维护工作外，还调用了注册在uio_info中的相关方法。比如，在 uio_open中调用了uio_info中注册的open方法。

那么这里有一个问题，uio核心字符设备怎么找到相关设备的uio_device结构的呢？
这就涉及到了内核的idr机制，关于该机制可以参考：
http://blog.csdn.net/ganggexiongqi/article/details/6737389

在uio.c中，有如下的定义：
static DEFINE_IDR(uio_idr);
/* Protect idr accesses */
static DEFINE_MUTEX(minor_lock);

在你调用uio_register_device(内部调用了__uio_register_device)注册你的uio 设备时，在__uio_register_device中调用了uio_get_minor函数，在uio_get_minor函数中，利用idr机制(idr_get_new)建立了次设备号和uio_device类型指针之间的联系。而uio_device指针指向了代表你注册的uio设备的内核结构。在uio核心字符设备的打开方法uio_open中先取得了设备的次设备号(iminor(inode))，再次利用idr机制提供的方法(idr_find)取得了对应的uio_device类型的指针。并且把该指针保存在了uio_listener结构中，以方便以后使用。

1.4 关于设备中断的处理

在__uio_register_device中，为uio设备注册了统一的中断处理函数uio_interrupt,在该函数中，调用了uio设备自己提供的中断处理函数handler(uio_info结构中)。并调用了uio_event_notify函数对uio设备的中断事件计数器增一, 通知各个读进程“有数据可读”。每个uio设备的中断处理函数都是单独注册的。
关于中断计数: uio_listener

struct uio_listener {
	struct uio_device *dev; // 保存uio设备的指针，便于访问
	s32 event_count; //跟踪uio设备的中断事件计数器
};

对于每一个注册的uio 设备(uio_device), 都关联一个这样的结构。它的作用就是跟踪每个uio设备(uio_device)的中断事件计数器值。在用户空间进行文件打开操作(open)时，与uio设备关联的uio_listener结构就被分配，指向它的指针被保存在filep指针的private_data字段以供其他操作使用。

在用户空间执行文件关闭操作时，和uio设备关联的uio_listener结构就被销毁。在uio设备注册时，uio core会为设备注册一个通用的中断处理函数(uio_interrupt),在该函数中，会调用uio设备自身的中断处理函数(handler). 中断发生时，uio_event_notify将被调用，用来对设备的中断事件计数器()增一，并通知各读进程，有数据可读。uio_poll 操作判断是否有数据可读的依据就是 listener中的中断事件计数值(event_count)和uio设备中的中断事件计数器值不一致(前者小于后者)。因为listener的值除了在执行文件打开操作时被置为被赋值外，只在uio_read操作中被更新为uio设备的中断事件计数器值。

疑问1：
对于中断事件计数器，uio_device中定义为 atomic_t 类型，又有
typedef struct {
int counter;
} atomic_t;
需不需要考虑溢出问题？
同样的问题存在在uio_listener的event_count字段。

关于uio_device的event字段 uio_howto中：
event: The total number of interrupts handled by the driver since the last time the device node was read.
【如果中断事件产生的频率是100MHZ的话，(2^32)/(108) = 42 秒】counter计数器就会溢出。所以，依赖于counter的操作可能会出现问题。//补充：中断发生的频率最多为kHz不会是 Mhz，所以[]中的假设是不合理的，但是溢出会发生，而且，依赖counter值的应用可能会出现问题！！

我们可以添加一个timer，在timer 处理函数中，调用uio_event_notify增加counter的值，
很快会观察到溢出。
//其实，可以在我们注册的函数中，得到uio_device的指针，可以直接修改event的值。

1.5 关于 sysfs文件创建

sysfs下uio相关的文件结构如下
sys
├───uio
├───uio0
│ ├───maps
│ ├───mapX
├───uio1
├───maps
│ ├───mapX
├───portio
├───portX

其中的uio是uio模块加载时，uio_init调用init_uio_class调用class_register注册到内核空间的。关于这个类的方法有个疑问，就是比如在show_event方法中，struct uio_device *idev = dev_get_drvdata(dev);//具体的uio设备相关的信息这个uio_device相关的信息是怎么跟 uio class联系上的?
在调用__uio_register_device注册uio设备时，通过

 idev->dev = device_create(uio_class, parent, MKDEV(uio_major, idev->minor), idev, "uio%d", idev->minor);

其中，idev就是 uio_device类型的指针，它作为drvdata被传入，device_create调用了device_create调用了device_create_vargs调用了dev_set_drvdata。这样在uio class的 show_event方法中，就可以使用struct uio_device *idev = dev_get_drvdata(dev)得到了uio设备的结构体的指针。device_create调用完毕后在 /sys/class/uio/下就会出现代表uio设备的uioX文件夹，其中X为uio设备的次设备号。

1.6 编写uio驱动

为了用最简单的例子说明问题，我们在我们uio驱动的内核部分只映射了一块1024字节的逻辑内存。没有申请中断。这样加载上我们的驱动后，将会在/sys/class/uio/uio0/maps/map0中看到addr，name, offset, size。他们分别是映射内存的起始地址, 映射内存的名字，起始地址的页内偏移, 映射内存的大小。在uio驱动的用户空间部分，我们将打开addr, size以便使用映射好的内存。

/** 
* This is a simple demon of uio driver. 
* Compile:  
*  Save this file name it simple.c 
*  # echo "obj-m := simple.o" &gt; Makefile 
*  # make -Wall -C /lib/modules/`uname -r`/build M=`pwd` modules 
* Load the module: 
*  #modprobe uio 
*  #insmod simple.ko 
*/ 

#include <linux/module.h> 
#include <linux/platform_device.h> 
#include <linux/uio_driver.h> 
#include <linux/slab.h> /* kmalloc, kfree */ 
struct uio_info kpart_info = { 
    .name = "kpart", 
    .version = "0.1", 
    .irq = UIO_IRQ_NONE, 
}; 

static int drv_kpart_probe(struct device *dev); 
static int drv_kpart_remove(struct device *dev); 
static struct device_driver uio_dummy_driver = { 
    .name = "kpart", 
    .bus = &amp;platform_bus_type, 
    .probe = drv_kpart_probe, 
    .remove = drv_kpart_remove, 
}; 

static int drv_kpart_probe(struct device *dev) 
{ 
    printk("drv_kpart_probe( %p)\n", dev); 
    kpart_info.mem[0].addr = (unsigned long)kmalloc(1024,GFP_KERNEL); 

    if(kpart_info.mem[0].addr == 0) 
        return -ENOMEM; 
    kpart_info.mem[0].memtype = UIO_MEM_LOGICAL; 
    kpart_info.mem[0].size = 1024; 

    if( uio_register_device(dev, &amp;kpart_info)) 
        return -ENODEV; 
    return 0; 
} 

static int drv_kpart_remove(struct device *dev) 
{ 
	uio_unregister_device(&amp;kpart_info); 
	return 0; 
} 

static struct platform_device *uio_dummy_device; 

static int __init uio_kpart_init(void) 
{ 
    uio_dummy_device = platform_device_register_simple("kpart", -1, NULL, 0); 
    return driver_register(&amp;uio_dummy_driver); 
} 

static void __exit uio_kpart_exit(void) 
{ 
    platform_device_unregister(uio_dummy_device); 
    driver_unregister(&amp;uio_dummy_driver); 
} 

module_init(uio_kpart_init); 
module_exit(uio_kpart_exit); 

MODULE_LICENSE("GPL"); 
MODULE_AUTHOR("Benedikt Spranger"); 
MODULE_DESCRIPTION("UIO dummy driver");

这个文件是我们uio驱动的内核部分。下面做下简要解释。
一个uio驱动的注册过程简单点说有两个步骤：

初始化设备相关的 uio_info结构。
调用uio_register_device 分配并注册一个uio设备。

uio驱动必须要提供并初始化的结构 uio_info, 它包含了您要注册的uio_device的重要特性。

struct uio_info kpart_info = {
    .name = "kpart",
    .version = "0.1",
    .irq = UIO_IRQ_NONE,//我们没有使用中断，所以初始为UIO_IRQ_NONE
};

当你没有实际的硬件设备，但是，还想产生中断的话，就可以把irq设置为UIO_IRQ_CUSTOM，
并初始化uio_info的handler字段，那么在产生中断时，你注册的中断处理函数将会被调用。
如果有实际的硬件设备，那么irq应该是您的硬件设备实际使用的中断号。然后，在drv_kpart_probe函数(先不要管为什么在这个函数中进行这些操作)中，完成了kpart_info.mem[0].addr， kpart_info.mem[0].memtype，kpart_info.mem[0].size字段的初始化。这是内存映射必须要设置的。其中, kpart_info.mem[0].memtype可以是 UIO_MEM_PHYS，那么被映射到用户空间的是你设备的物理内存。也可以是UIO_MEM_LOGICAL，那么被映射到用户空间的是逻辑内存(比如使用 kmalloc分配的内存)。还可以是UIO_MEM_VIRTUAL,那么被映射到用户空间的是虚拟内存(比如用vmalloc分配的内存).这样就完成了uio_info结构的初始化。下一步，还是在drv_kpart_probe中，调用uio_register_device完成了uio设备向uio core的注册。

下面讲一下，为什么我们的设备跟platform之类的东东扯上了关系?
我们的驱动不存在真正的物理设备与之对应。而 Platform 驱动“自动探测“，这个特性是我们在没有实际硬件的情况下需要的。
先从uio_kpart_init开始分析。

platform_device_register_simple的调用创建了一个简单的platform设备。
注册device_driver类型的uio_dummy_driver变量到bus。

这里需要注意一个问题，就是 device_driver结构中的name为“kpart", 我们创建的platform设备名称也是"kpart"。而且先创建platform设备，后注册驱动。这是因为，创建好设备后，注册驱动时，驱动依靠name来匹配设备。之后 drv_kpart_probe就完成了uio_info的初始化和uio设备的注册。

1.7 uio驱动的用户空间部分

#include <stdio.h>; 
#include <fcntl.h>; 
#include <stdlib.h>; 
#include <unistd.h>; 
#include <sys/mman.h>; 
#include <errno.h>; 

#define UIO_DEV "/dev/uio0" 
#define UIO_ADDR "/sys/class/uio/uio0/maps/map0/addr" 
#define UIO_SIZE "/sys/class/uio/uio0/maps/map0/size" 

static char uio_addr_buf[16], uio_size_buf[16]; 

int main(void) 
{ 
	int uio_fd, addr_fd, size_fd; 
	int uio_size; 
	void* uio_addr, *access_address; 
	
	uio_fd = open(UIO_DEV, /*O_RDONLY*/O_RDWR); 
	addr_fd = open(UIO_ADDR, O_RDONLY); 
	size_fd = open(UIO_SIZE, O_RDONLY); 
	if( addr_fd < 0 || size_fd < 0 || uio_fd < 0) { 
		fprintf(stderr, "mmap: %s\n", strerror(errno)); 
		exit(-1); 
	} 
	read(addr_fd, uio_addr_buf, sizeof(uio_addr_buf)); 
	read(size_fd, uio_size_buf, sizeof(uio_size_buf)); 
	uio_addr = (void*)strtoul(uio_addr_buf, NULL, 0); 
	uio_size = (int)strtol(uio_size_buf, NULL, 0); 
	
	access_address = mmap(NULL, uio_size, PROT_READ | PROT_WRITE, MAP_SHARED, uio_fd, 0); 
	if (access_address == (void*) -1) { 
		fprintf(stderr, "mmap: %s\n", strerror(errno)); 
		exit(-1); 
	} 
	printf("The device address %p (lenth %d)\n" 
	 		"can be accessed over\n" 
			 "logical address %p\n", uio_addr, uio_size, access_address); 
	//读写操作 
	/* 
	access_address = (void*)mremap(access_address, getpagesize(), uio_size + getpagesize() + 11111, MAP_SHARED); 
	if ( access_address == (void*) -1) { 
		  fprintf(stderr, "mremmap: %s\n", strerror(errno)); 
		  exit(-1); 
	} 
	printf("&gt;&gt;&gt;AFTER REMAP:" 
	   "logical address %p\n", access_address); 
	*/ 
	return 0; 
}

加载uio模块

#modprobe uio

加载simple.ko

#insmod simple.ko

ls /dev/ | grep uio0
uio0

ls /sys/class/uio/uio0

如果相应的文件都存在，那么加载用户空间驱动部分。

./user_part
The device address 0xee244400 (lenth 1024)
can be accessed over
logical address 0xb78d4000
======================================================================

原文链接：https://blog.csdn.net/wenwuge_topsec/article/details/9628409