misc杂散类设备虽然单独的归为杂散类这个类中,但其实也是字符设备驱动的一种,很多的代码的实现都与字符设备驱动如出一辙,这里以一个比较简单的蜂鸣器buzzer设备为例,以实际的代码分析misc杂散类设备的注册过程:
1.驱动的入口:
module_init(dev_init);
static int __init dev_init(void)
{
int ret;
init_MUTEX(&lock);
ret = misc_register(&misc);
/* GPD0_2 (PWMTOUT2) */
ret = gpio_request(S5PV210_GPD0(2), "GPD0");
if(ret)
printk("buzzer-x210: request gpio GPD0(2) fail");
s3c_gpio_setpull(S5PV210_GPD0(2), S3C_GPIO_PULL_UP);
s3c_gpio_cfgpin(S5PV210_GPD0(2), S3C_GPIO_SFN(1));
gpio_set_value(S5PV210_GPD0(2), 0);
printk ("x210 "DEVICE_NAME" initialized\n");
return ret;
}
(1)利用信号量,使得buzzer设备不会被多个进程同时操作,
init_MUTEX(&lock);
这里使用了信号量,但是经过分析,实际信号量只能计数一次,也就是以信号量的形式实现了一个互斥锁,使得对于该buzzer设备的操作,不能同时被多次执行。对于这里的信号量后面会再做介绍。
(2)核心注册杂散设备:misc_register
ret = misc_register(&misc);
(3)注册是核心是misc_register()函数的传参,对misc分析:
static struct miscdevice misc = {
.minor = MISC_DYNAMIC_MINOR,
.name = DEVICE_NAME,
.fops = &dev_fops,
};
指定次设备号为255,让系统帮我们动态分配次设备号,指定了次设备号的名字,以及最重要file_operations.
(4)file_operations结构体变量dev_fops:
static struct file_operations dev_fops = {
.owner = THIS_MODULE,
.open = x210_pwm_open,
.release = x210_pwm_close,
.ioctl = x210_pwm_ioctl,
};
open、release函数的实现比较普通,较为简单,在这里不做分析,对ioctl函数的实现做一个简单的分析:
(5) .ioctl = x210_pwm_ioctl分析:
static int x210_pwm_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg)
{
switch (cmd)
{
case PWM_IOCTL_SET_FREQ:
printk("PWM_IOCTL_SET_FREQ:\r\n");
if (arg == 0)
return -EINVAL;
PWM_Set_Freq(arg);
break;
case PWM_IOCTL_STOP:
default:
printk("PWM_IOCTL_STOP:\r\n");
PWM_Stop();
break;
}
return 0;
}
首先说一下x210_pwm_ioctl()函数如何使用:
打开:x210_pwm_ioctl(fd,"/dev/buzzer",PWM_IOCTL_SET_FREQ,xxx),xxx是你欲设置的输出频率;
关闭:x210_pwm_ioctl(fd,"/dev/buzzer",PWM_IOCTL_STOP)。
ioctl函数在驱动中实现之后会提供给应用开发者使用,那么为了减少应用开发者的麻烦,驱动这里将对ioctl函数中原本控制设备工作、静止的数字变量宏定义为一个直观的变量:
#define PWM_IOCTL_SET_FREQ 1
#define PWM_IOCTL_STOP 0
这样应用开发者就可以更清楚这个函数如何操作硬件。
而根据函数的使用方法,由结果,我们接着对代码的实现进行分析:
首先比较我们输入的参数,然后如果是PWM_IOCTL_SET_FREQ 则表示打开,然后调用PWM_Set_Freq(arg)将频率设置为我们设定的参数,如果是PWM_IOCTL_STOP或者一个无效的参数,则将设备进行关闭。
回到入口函数dev_init()中继续分析
(6)设置buzzer的硬件相关的输出模式:
ret = gpio_request(S5PV210_GPD0(2), "GPD0");
if(ret)
printk("buzzer-x210: request gpio GPD0(2) fail");
s3c_gpio_setpull(S5PV210_GPD0(2), S3C_GPIO_PULL_UP);
s3c_gpio_cfgpin(S5PV210_GPD0(2), S3C_GPIO_SFN(1));
gpio_set_value(S5PV210_GPD0(2), 0);
先向gpiolib申请gpio口,然后将其设置为上拉模式,输出模式,输出值为0,也就是一开始将其设置为静止。
到这里buzzer设备驱动的分析基本完成,下面对一开始说的信号量进行一个分析:
(7)对信号量的使用进行分析:
init_MUTEX(&lock);
static struct semaphore lock;
struct semaphore {
spinlock_t lock;
unsigned int count;
struct list_head wait_list;
};
lock表示信号,count表示信号量的计数次数,wait_list表示如果信号量阻塞等待时将其放在一个链表中。
以上是对信号量定义的一个追踪,而真正对信号量的使用是在几个open、release函数中间接使用:
①对信号量进行申请,也就是上锁。
extern void down(struct semaphore *sem);
②释放信号量,也就是解锁。
extern void up(struct semaphore *sem);
值得注意的是:这两个函数的返回值都是void类型的,因为down、up操作肯定是是成功才能返回的,所以不需要再用返回值来标识情况,而其余的几个操作的函数返回值都是int类型的,不同的返回值代表不同的执行情况。
③阻塞等待申请信号量时可以被其他的信号量打断:
extern int __must_check down_interruptible(struct semaphore *sem);
④阻塞等待申请信号量,过程中可以被杀死:
extern int __must_check down_killable(struct semaphore *sem);
⑤非阻塞形式实现阻塞等待,当申请时如果申请不到,则返回错误,这也是此设备open时使用的方法:
extern int __must_check down_trylock(struct semaphore *sem);
static int x210_pwm_open(struct inode *inode, struct file *file)
{
if (!down_trylock(&lock))
return 0;
else
return -EBUSY;
}
这也保证了设备不会被重复打开,重复使用。
⑥超时机制的阻塞等待,在规定的时间内进行阻塞等待,超时不再等待:
extern int __must_check down_timeout(struct semaphore *sem, long jiffies);
2.驱动的出口:
static void __exit dev_exit(void)
{
misc_deregister(&misc);
}
驱动的出口很是简单,只是调用一个misc_deregister(&misc);函数,而函数的内部替我们完成了很多的回收,销毁工作。
写在最后:驱动的分析不能从头到尾进行分析,此篇博文的分析过程是一个比较合适、正确的分析流程,大家可以借鉴参考。
End。。。。。。