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;

}
时间: 2024-10-30 07:13:38

linux驱动开发之蜂鸣器驱动源码分析(一)的相关文章

FiddlerCoreAPI开发(一)源码分析

1.前言 前一段时间想利用fiddlercore截取本地HTTPS的流量做一些分析,按照样例代码的注释学习了一下,没搞清楚怎么实现,后来又在网上查了些资料,对HTTPS的处理提及很少,都没有解决我的问题,主要是HTTPS证书的问题,索性自己研究了一下,终于解决了问题.我会在下篇文章中分享下我的思路,本篇文章先简单分析下fiddlercore自带样例的代码,帮助刚接触fiddlercore的人快速入门,如果有说的不对的地方,欢迎批评指正. 2.源码分析 首先从官网下载FiddlerCoreAPI

linux驱动开发之蜂鸣器驱动源码分析(二)

这次分析/driver/char/buzzer/x210-buzzer.c中蜂鸣器驱动代码中的应用层执行ioctl时对应的x210_pwm_ioctl函数中的PWM_Set_Freq.PWM_Stop两个真正操作硬件的函数,x210_pwm_iotcl函数整体代码内容如下 static int x210_pwm_ioctl(struct inode *inode, struct file *file, unsigned int cmd, unsigned long arg) { switch (

驱动学习之led-class.c源码分析

1:subsys_initcall宏 #define __define_initcall(level,fn,id) \  static initcall_t __initcall_##fn##id __used     __attribute__((__section__(".initcall" level ".init"))) = fn      #define subsys_initcall(fn)        __define_initcall("

Android cocos2dx游戏开发——示例程序HelloCpp源码分析

本文通过分析cocos2dx提供的示例程序HelloCpp来分析cocos2dx的启动过程. 我们从HelloCpp.java开始: [java] view plaincopyprint? package org.cocos2dx.hellocpp; import org.cocos2dx.lib.Cocos2dxActivity; import android.os.Bundle; public class HelloCpp extends Cocos2dxActivity{ protecte

Linux c 开发 - Memcached源码分析之命令解析(2)

前言 从我们上一章<Linux c 开发 - Memcached源码分析之基于Libevent的网络模型>我们基本了解了Memcached的网络模型.这一章节,我们需要详细解读Memcached的命令解析. 我们回顾上一章发现Memcached会分成主线程和N个工作线程.主线程主要用于监听accpet客户端的Socket连接,而工作线程主要用于接管具体的客户端连接. 主线程和工作线程之间主要通过基于Libevent的pipe的读写事件来监听,当有连接练上来的时候,主线程会将连接交个某一个工作线

squid源码分析之--epoll和event驱动机制

最近在看squid的源码,刚开始毫无头绪,后来逐步找到一些感觉,记录之. squid的源码中大概有100多个c文件,一个一个地看明显行不通.我们需要逐步找出设计者的主线. 先从main.c入手,需要关注的,是main.c离结尾比较近的那一段,它是squid的心脏: "for(::){ ... event_run(); ... swich(comm_select()... ... }" event_run()函数定义在event.c文件里,它每次在恰当的时间从event.c的一个全局的e

Linux 设备驱动开发 —— platform设备驱动应用实例解析

前面我们已经学习了platform设备的理论知识Linux 设备驱动开发 -- platform 设备驱动 ,下面将通过一个实例来深入我们的学习. 一.platform 驱动的工作过程 platform模型驱动编程,platform 驱动只是在字符设备驱动外套一层platform_driver 的外壳. 在一般情况下,2.6内核中已经初始化并挂载了一条platform总线在sysfs文件系统中.那么我们编写platform模型驱动时,需要完成两个工作: a -- 实现platform驱动 架构就

Linux内核源码分析--内核启动之(5)Image内核启动(rest_init函数)(Linux-3.0 ARMv7)【转】

原文地址:Linux内核源码分析--内核启动之(5)Image内核启动(rest_init函数)(Linux-3.0 ARMv7) 作者:tekkamanninja 转自:http://blog.chinaunix.net/uid-25909619-id-4938395.html 前面粗略分析start_kernel函数,此函数中基本上是对内存管理和各子系统的数据结构初始化.在内核初始化函数start_kernel执行到最后,就是调用rest_init函数,这个函数的主要使命就是创建并启动内核线

Linux内核源码分析--内核启动之(6)Image内核启动(do_basic_setup函数)(Linux-3.0 ARMv7)【转】

原文地址:Linux内核源码分析--内核启动之(6)Image内核启动(do_basic_setup函数)(Linux-3.0 ARMv7) 作者:tekkamanninja 转自:http://blog.chinaunix.net/uid-25909619-id-4938396.html 在基本分析完内核启动流程的之后,还有一个比较重要的初始化函数没有分析,那就是do_basic_setup.在内核init线程中调用了do_basic_setup,这个函数也做了很多内核和驱动的初始化工作,详解