linux驱动开发之蜂鸣器驱动源码分析（一）

蜂鸣器的驱动源码在/driver/char/buzzer/x210-buzzer.c文件中，源码如下

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/fs.h>
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/poll.h>
#include <asm/irq.h>
#include <asm/io.h>
#include <linux/interrupt.h>
#include <asm/uaccess.h>
#include <mach/hardware.h>
#include <plat/regs-timer.h>
#include <mach/regs-irq.h>
#include <asm/mach/time.h>
#include <linux/clk.h>
#include <linux/cdev.h>
#include <linux/device.h>
#include <linux/miscdevice.h>

#include <linux/gpio.h>

#include <plat/gpio-cfg.h>
//#include <plat/regs-clock.h>
//#include <plat/regs-gpio.h>

//#include <plat/gpio-bank-e.h>
//#include <plat/gpio-bank-f.h>
//#include <plat/gpio-bank-k.h>

#define DEVICE_NAME     "buzzer"

#define PWM_IOCTL_SET_FREQ		1
#define PWM_IOCTL_STOP			0

static struct semaphore lock;

// TCFG0在Uboot中设置，这里不再重复设置
// Timer0输入频率Finput=pclk/(prescaler1+1)/MUX1
//                     =66M/16/16
// TCFG0 = tcnt = (pclk/16/16)/freq;
// PWM0输出频率Foutput =Finput/TCFG0= freq
static void PWM_Set_Freq( unsigned long freq )
{
unsigned long tcon;
unsigned long tcnt;
unsigned long tcfg1;

struct clk *clk_p;
unsigned long pclk;

//unsigned tmp;

//设置GPD0_2为PWM输出
s3c_gpio_cfgpin(S5PV210_GPD0(2), S3C_GPIO_SFN(2));

tcon = __raw_readl(S3C2410_TCON);
tcfg1 = __raw_readl(S3C2410_TCFG1);

//mux = 1/16
tcfg1 &= ~(0xf<<8);
tcfg1 |= (0x4<<8);
__raw_writel(tcfg1, S3C2410_TCFG1);

clk_p = clk_get(NULL, "pclk");
pclk  = clk_get_rate(clk_p);

tcnt  = (pclk/16/16)/freq;

__raw_writel(tcnt, S3C2410_TCNTB(2));
__raw_writel(tcnt/2, S3C2410_TCMPB(2));//占空比为50%

tcon &= ~(0xf<<12);
tcon |= (0xb<<12);		//disable deadzone, auto-reload, inv-off, update TCNTB0&TCMPB0, start timer 0
__raw_writel(tcon, S3C2410_TCON);

tcon &= ~(2<<12);			//clear manual update bit
__raw_writel(tcon, S3C2410_TCON);
}

void PWM_Stop( void )
{
//将GPD0_2设置为input
s3c_gpio_cfgpin(S5PV210_GPD0(2), S3C_GPIO_SFN(0));
}

static int x210_pwm_open(struct inode *inode, struct file *file)
{
if (!down_trylock(&lock))
return 0;
else
return -EBUSY;

}

static int x210_pwm_close(struct inode *inode, struct file *file)
{
up(&lock);
return 0;
}

// PWM:GPF14->PWM0
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;
}

static struct file_operations dev_fops = {
.owner   =   THIS_MODULE,
.open    =   x210_pwm_open,
.release =   x210_pwm_close,
.ioctl   =   x210_pwm_ioctl,
};

static struct miscdevice misc = {
.minor = MISC_DYNAMIC_MINOR,
.name = DEVICE_NAME,
.fops = &dev_fops,
};

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;
}

static void __exit dev_exit(void)
{
misc_deregister(&misc);
}

module_init(dev_init);
module_exit(dev_exit);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("www.9tripod.com");
MODULE_DESCRIPTION("x210 PWM Driver");

蜂鸣器的驱动模块代码如上。和其他驱动模块代码一样，module_init中的函数为驱动模块被加载的时候（insmd）时运行的函数，module_exit中的函数为驱动模块被卸载时（rmmod）运行的函数，

首先看下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;
}

上面代码中的init_MUTEX(&lock),这个lock是在本文件全局定义的，定义如下，init_MUTEXH函数是初始化信号量的，将信号量的计数值初始化为1。计数值初始化为1的信号量其实就是互斥锁，由这个代码可以知道，编写者的本意是想用的互斥锁的，但可能那个时候并没有互斥锁，只有信号量，所以用信号量来实现了互斥锁。因为信号量的计数值为1，其实跟互斥锁就是类似的了。因为信号量没有互斥锁优化的好，所以这里使用信号量其实并不是现在主流的。

static struct semaphore lock;

struct semaphore是一个信号量结构体，信号量和互斥锁的不同前面已经讲过。结构体内容如下

struct semaphore {
spinlock_t		lock;
unsigned int		count;
struct list_head	wait_list;    //信号量的等待队列
};

在dev_init函数中，接着代码是

ret = misc_register(&misc);

misc_register是注册misc杂散类设备的函数，参数misc是被定义在全局并且填充好的结构体变量，内容如下

static struct miscdevice misc = {    //这里定义miscdevice结构体并填充了三个成员，根据实际情况进行填充
.minor = MISC_DYNAMIC_MINOR,    //次设备号minor成员被赋值为MISC_DYNAMIC_MINOR宏的值（255）,前面说过该值表示让内核为我们自动分配次设备                                        //号。
.name = DEVICE_NAME,    //该设备的名字，这个设备的名字并不像platform平台总线机制中的名字那么重要（因为是用来macth函数匹配设备和驱动的//）。这里这个name作用只是用来记录的。
.fops = &dev_fops,    //该设备的操作方法
};

上面定义的strcut miscdevice结构体中的fops成员被绑定成dev_fops，dev_fops也是被定义在本文件的全局的，该结构体包含的是操作这个驱动的操作而方法，内容如下

static struct file_operations dev_fops = {
.owner   =   THIS_MODULE,
.open    =   x210_pwm_open,    //应用层open操作该设备文件时执行的函数
.release =   x210_pwm_close,     //应用层close操作该设备文件时执行的函数
.ioctl   =   x210_pwm_ioctl,    //应用层ioctl操作该设备文件时执行的函数
};

经过misc_register(&misc)后，就会将该misc设备和其驱动的操作方法进行注册，完成杂散类设备的注册。

在dev_init函数中接下来的代码就是对蜂鸣器硬件相关的设置，根据硬件原理图来看蜂鸣器对应的GPIO，操作设置如下

/* GPD0_2 (PWMTOUT2) */
ret = gpio_request(S5PV210_GPD0(2), "GPD0");    //向内核申请GPIOD0_2引脚资源
if(ret)
printk("buzzer-x210: request gpio GPD0(2) fail");

s3c_gpio_setpull(S5PV210_GPD0(2), S3C_GPIO_PULL_UP);    //向内核申请后，设置GPIOD0_2引脚为上拉
s3c_gpio_cfgpin(S5PV210_GPD0(2), S3C_GPIO_SFN(1));    //将该GPIOD0_2引脚的模式设置成S3C_GPIO_SFN(1)模式（特殊模式1，根据手册是输出
//模式，详细情况看数据手册）
gpio_set_value(S5PV210_GPD0(2), 0);    //设置该引脚初始输出0低电平，因为是初始化为0低电平，所以蜂鸣器开始是不会响的。

printk ("x210 "DEVICE_NAME" initialized\n");    //DEVICE_NAME宏是设备名字，这种方式的打印信息，编译会将宏代表的字符串一起打印出来。
return ret;

上面的分析已经将蜂鸣器驱动模块被装载时发生的事情（dev_init）分析完了。dev_init函数执行成功表示驱动已经安装好了，此时驱动代码为待命状态。等待应用层去操作。

应用层用open代开蜂鸣器设备文件时，对应的驱动执行函数是x210_pwm_open，代码如下

static int x210_pwm_open(struct inode *inode, struct file *file)
{
if (!down_trylock(&lock))    //因为蜂鸣器这种设备很简单，所以open函数是空的，这里只是执行了这么一个上锁操作，防止蜂鸣器设备被打开多次
return 0;            //使用非阻塞的方式去尝试上锁，如果上锁不成功则返回失败
else
return -EBUSY;

}

应用层用close关闭蜂鸣器设备时，对应的驱动执行函数是x210_pwm_close，代码如下

static int x210_pwm_close(struct inode *inode, struct file *file)
{
up(&lock);    //解锁操作
return 0;
}

应用层ioctl操作蜂鸣器设备文件时，对应的驱动函数是x210_pwm_ioctl，这个是我们这次分析的重点，代码如下

// PWM:GPF14->PWM0
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;
}

1、为什么用ioctl呢？

ioctl就是（input output control，输入输出控制）。这个函数的目的是让设备进行输入或者输出，让设备进行读或者写。

2、既然同样是为了让设备进行读和写，那么为什么不用read和write而要使用iotcl呢？

这是因为read和write是有缺陷的，ioctl是为了让一件事情更加美好，如果没有ictol只有read和write也是没有问题的，ioctl的存在只是为了更好。read和write的缺陷在于应用层和驱动层进行数据交换与定义比较麻烦。

举个例子：之前我们在写led的驱动时，写write和read驱动操作方法时，定义为wirte写1时表示led灭，写0时表示led亮，这是体现在驱动中的，那么应用层使用write操作led设备的时候就必须要知道用write去写什么值是让led亮和灭的，这个时候就很麻烦，写驱动的人可能要写一个文档来告诉写应用的人，write这个设备1是灭，0是亮。也可能要将驱动的代码给应用的人，让应用的人来知道write什么内容时对应的到底是什么操作，这两种可能虽然都能解决问题，但是都不完美，因为无论那样你都需要写文档，或者让应用的人去阅读驱动代码，都需要写应用的人去看文档或者驱动代码。这种复杂性在简单的设备中可能体会不出来，但是在一些复杂的设备中就体现出来了，ioctl解决的问题就是这种复杂性问题，让写应用的人好一些。

上面的代码中使用了ioctl的方式，其中有两个宏命令，分别是PWM_IOCTL_STOP和PWM_IOTCL_SET_FREQ,这两个宏分别对应的是0或1，我们可以将这两个宏写到一个头文件中，将这个头文件提供给写应用的人，写应用的人一看这两个宏就知道干嘛的，应用层使用ioctl时直接传参宏进去就可。前面在测试蜂鸣器驱动的时候已经写了关于蜂鸣器应用操作的C代码。