概述
文章目录
- 系列文章目录
- 前言
- 驱动目录
- 正文
- 为什么需要设备驱动模型
- sysfs概述
- 设备驱动模型基本元素
- 驱动模型一
- 驱动模型二
- kobject
- kset
- kobj_type
- 代码示例
- 测试
- 总结
系列文章目录
Linux字符设备驱动详解
Linux字符设备驱动详解二(使用设备驱动模型)
Linux字符设备驱动详解三(使用class)
Linux字符设备驱动详解四(使用自属的xbus驱动总线)
Linux字符设备驱动详解五(使用platform虚拟平台总线)
Linux字符设备驱动详解六(设备树实现RGB灯驱动)
Linux字符设备驱动详解七(“插件“设备树实现RGB灯驱动)
前言
本文主要来自正点原子、野火Linux教程及本人理解,若有侵权请及时联系本人删除。
驱动目录
sys/kset_example/led_kobject/foo led
正文
为什么需要设备驱动模型
- 早期内核(2.4之前)没有统一的设备驱动模型,但照样可以用
- 2.4~2.6期间使用devfs,挂载在/dev目录。
- 需要在内核驱动中创建设备文件(devfs_register),命名死板
- 2.6以后使用sysfs,挂载在/sys目录
- 将设备分类、分层次统一进行管理
- 配合udev/mdev守护进程动态创建设备文件,命令规则自由制定
sysfs概述
linux系统通过sysfs体现出设备驱动模型
- sysfs是一个虚拟文件系统(类似proc文件系统)
- 目录对应的inode节点会记录基本驱动对象(kobject),从而将系统中的设备组成层次结构
- 用户可以读写目录下的不同文件来配置驱动对象(kobject)的不同属性
设备驱动模型基本元素
- kobject:sysfs中的一个目录,常用来表示基本驱动对象,不允许发送消息到用户空间
- kset:sysfs中的一个目录,常用来管理kobject,允许发送消息到用户空间
- kobj_type:目录下属性文件的操作接口
驱动模型一
kset可批量管理kobject
kobject无法批量管理kobject
驱动模型二
上层kobject节点无法遍历查找下层kobject
通常我们使用模型一,通过使用驱动模型,我们就不用再手动调用mknod命令创建设备文件(节点)
kobject
sysfs中每一个目录都对应一个kobject
struct kobject {
//用来表示该kobject的名称
const char *name;
//链表节点
struct list_head entry;
//该kobject的上层节点,构建kobject之间的层次关系
struct kobject *parent;
//该kobject所属的kset对象,用于批量管理kobject对象
struct kset *kset;
//该Kobject的sysfs文件系统相关的操作和属性
struct kobj_type *ktype;
//该kobject在sysfs文件系统中对应目录项
struct kernfs_node *sd; /* sysfs directory entry */
//该kobject的引用次数
struct kref kref;
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
struct delayed_work release;
#endif
//记录内核对象的初始化状态
unsigned int state_initialized:1;
//表示该kobject所代表的内核对象有没有在sysfs建立目录
unsigned int state_in_sysfs:1;
unsigned int state_add_uevent_sent:1;
unsigned int state_remove_uevent_sent:1;
unsigned int uevent_suppress:1;
};
kset
struct kset {
//用来将起中的object对象构建成链表
struct list_head list;
//自旋锁
spinlock_t list_lock;
//当前kset内核对象的kobject变量
struct kobject kobj;
//定义了一组函数指针,当kset中的某些kobject对象发生状态变化需要通知用户空间时,调用其中的函数来完成
const struct kset_uevent_ops *uevent_ops;
}
kobj_type
struct kobj_type {
//销毁kobject对象时调用
void (*release)(struct kobject *kobj);
//kobject对象属性文件统一操作接口
const struct sysfs_ops *sysfs_ops;
//kobject默认属性文件的名字、"文件具体操作接口"
struct attribute **default_attrs;
const struct kobj_ns_type_operations *(*child_ns_type)(struct kobject *kobj);
const void *(*namespace)(struct kobject *kobj);
void (*get_ownership)(struct kobject *kobj, kuid_t *uid, kgid_t *gid);
};
接下来我们就可以在驱动模块中完成设备文件系统的构建
首先从驱动模型中我们可以得知,kset作为kobject的容器,体现设备驱动的层次关系,通俗理解即sys/目录下的设备类型,我们通过kset_create_and_add()函数即可创建sys/目录下的一个设备类型目录
struct kset *kset_create_and_add(const char *name,
const struct kset_uevent_ops *uevent_ops,struct kobject *parent_kobj)
{
struct kset *kset;
int error;
kset = kset_create(name, uevent_ops, parent_kobj);
if (!kset)
return NULL;
error = kset_register(kset);
if (error) {
kfree(kset);
return NULL;
}
return kset;
}
接着通过kobject_create_and_add()函数我们完成了构建一个kobject对象,构建一个sysfs中的目录项(kernfs_node)并把他们关联起来,通俗理解就是创建了一个具体的设备,即sys/设备类型/具体设备
struct kobject *kobject_create_and_add(const char *name, struct kobject *parent)
{
struct kobject *kobj;
int retval;
/*创建并初始化一个kobject对象*/
kobj = kobject_create();
if (!kobj)
return NULL;
/*sysfs创建一个目录项并与kobject对象关联*/
retval = kobject_add(kobj, parent, "%s", name);
if (retval) {
pr_warn("%s: kobject_add error: %dn", __func__, retval);
kobject_put(kobj);
kobj = NULL;
}
return kobj;
}
最后需要完成为kobject对象构建多个属性文件,为每个属性文件设置具体操作接口以及vfs的inode对象与sysfs的kernfs_node对象的绑定过程。
对于这个过程我们首先构建多个kobj_attribute结构体,每个里面存放着具体属性的操作接口,将这些存放不同属性的结构体指针存放在attribute *类型的数组中,通过sysfs_create_group()函数我们可以调用数组指针完成不同属性文件的创建。
int sysfs_create_group(struct kobject *kobj,
const struct attribute_group *grp)
{
return internal_create_group(kobj, 0, grp);
}
kobj_attribute结构体
struct kobj_attribute {
struct attribute attr;
ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,
char *buf);
ssize_t (*store)(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count);
};
代码示例
以野火设备驱动模型代码为例
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/kobject.h>
#include <linux/string.h>
#include <linux/sysfs.h>
#include <linux/fs.h>
#include <linux/uaccess.h>
#include <asm/io.h>
#define DEV_MAJOR 0 /* 动态申请主设备号 */
#define DEV_NAME "red_led" /*led设备名字 */
/* GPIO虚拟地址指针 */
static void __iomem *IMX6U_CCM_CCGR1;
static void __iomem *SW_MUX_GPIO1_IO04;
static void __iomem *SW_PAD_GPIO1_IO04;
static void __iomem *GPIO1_DR;
static void __iomem *GPIO1_GDIR;
static int foo;
static ssize_t foo_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
return sprintf(buf, "%dn", foo);
}
static ssize_t foo_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count)
{
int ret;
ret = kstrtoint(buf, 10, &foo);
if (ret < 0)
return ret;
return count;
}
static struct kobj_attribute foo_attribute =
__ATTR(foo, 0664, foo_show, foo_store);
static ssize_t led_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
{
int var;
if (strcmp(attr->attr.name, "led") == 0)
var =123;
return sprintf(buf, "%dn", var);
}
static ssize_t led_store(struct kobject *kobj, struct kobj_attribute *attr,
const char *buf, size_t count)
{
if (strcmp(attr->attr.name, "led") == 0){
if(!memcmp(buf,"on",2)) {
iowrite32(0 << 4, GPIO1_DR);
} else if(!memcmp(buf,"off",3)) {
iowrite32(1 << 4, GPIO1_DR);
}
}
return count;
}
static struct kobj_attribute led_attribute =
__ATTR(led, 0664, led_show, led_store);
static struct attribute *attrs[] = {
&foo_attribute.attr,
&led_attribute.attr,
NULL, /* need to NULL terminate the list of attributes */
};
static struct attribute_group attr_group = {
.attrs = attrs,
};
static struct kobject *led_kobj;
static int __init led_init(void)
{
int retval;
/* GPIO相关寄存器映射 */
IMX6U_CCM_CCGR1 = ioremap(0x20c406c, 4);
SW_MUX_GPIO1_IO04 = ioremap(0x20e006c, 4);
SW_PAD_GPIO1_IO04 = ioremap(0x20e02f8, 4);
GPIO1_GDIR = ioremap(0x0209c004, 4);
GPIO1_DR = ioremap(0x0209c000, 4);
/* 使能GPIO1时钟 */
iowrite32(0xffffffff, IMX6U_CCM_CCGR1);
/* 设置GPIO1_IO04复用为普通GPIO*/
iowrite32(5, SW_MUX_GPIO1_IO04);
/*设置GPIO属性*/
iowrite32(0x10B0, SW_PAD_GPIO1_IO04);
/* 设置GPIO1_IO04为输出功能 */
iowrite32(1 << 4, GPIO1_GDIR);
/* LED输出高电平 */
iowrite32(1<< 4, GPIO1_DR);
/* 创建一个kobject对象*/
led_kobj = kobject_create_and_add("led_kobject", NULL);
if (!led_kobj)
return -ENOMEM;
/* 为kobject设置属性文件*/
retval = sysfs_create_group(led_kobj, &attr_group);
if (retval)
kobject_put(led_kobj);
return retval;
return 0;
}
static void __exit led_exit(void)
{
/* 取消映射 */
iounmap(IMX6U_CCM_CCGR1);
iounmap(SW_MUX_GPIO1_IO04);
iounmap(SW_PAD_GPIO1_IO04);
iounmap(GPIO1_DR);
iounmap(GPIO1_GDIR);
/* 注销字符设备驱动 */
kobject_put(led_kobj);
}
module_init(led_init);
module_exit(led_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("embedfire ");
MODULE_DESCRIPTION("led_module");
MODULE_ALIAS("led_module");
测试
加载完驱动模块,我们就可以通过命令进行测试
sudo sh -c "ecoh '5' >/sys/led_kobject/foo"
此时向该文件写入单字符'5',foo_store()函数将它转化为十进制数存到全局变量中,foo_store()函数按照十进制将其打印到终端
sudo cat /sys/led_kobject/foo
执行cat命令查看foo文件内容后会打印数字5
sudo cat /sys/led_kobject/led
执行cat命令查看led文件内容后会打印数字123,与文件写入无关
sudo sh -c "ecoh 'on' >/sys/led_kobject/led"
点灯
sudo sh -c "ecoh 'off' >/sys/led_kobject/led"
灭灯
总结
通过使用驱动模型,我们就不用再手动调用mknod命令创建设备文件(节点),本节演示并未创建/dev/目录下的设备文件,只是在/sys/目录下演示设备驱动的框架。只有调用了kobject_uevent(led_kobj, KOBJ_ADD)后,内核才会向用户空间udev/mdev守护进程发送消息,udev/mdev守护进程才会在用户空间/dev/目录下创建设备文件。
请阅读:Linux字符设备驱动详解三(使用class)
最后
以上就是自然哑铃为你收集整理的Linux字符设备驱动详解二(使用设备驱动模型)系列文章目录前言驱动目录正文总结的全部内容,希望文章能够帮你解决Linux字符设备驱动详解二(使用设备驱动模型)系列文章目录前言驱动目录正文总结所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复