基于platform驱动模型的LED驱动

上一篇博文《platform设备驱动框架搭建分析》主要是根据内核源码来分析platform驱动模型工作的原理,在实际的驱动开发中如何使用Linux的这么一种模型来管理这种类型的设备呢?把tq2440开发板上的LED1当做是平台设备注册到Linux系统中,让系统可以用这种platform驱动来管理他。

①总线层:代码不用我们自己去写,内核已经提供了

②设备层:向platform总线层注册硬件相关的资源,一般是寄存器地址、内存空间、中断号(序号的一种代表)等等

led_dev.c

#include <linux/module.h>
#include <linux/version.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/interrupt.h>
#include <linux/list.h>
#include <linux/timer.h>
#include <linux/init.h>
#include <linux/serial_core.h>
#include <linux/platform_device.h>

static struct resource led_resource[] = {
    [0] = { //GPBCON
        .start = 0x56000010,
        .end   = 0x56000050 + 8 - 1,
        .flags = IORESOURCE_MEM, //一般地址类的操作就用这个flags
    },
    [1] = { //中断号
        .start = 5,
        .end   = 5,
        .flags = IORESOURCE_IRQ, //在这个例子中和中断并没有半毛钱的关系,纯粹就是表示一种序号的意思
    }

};

static void led_release(struct device * dev)
{
}

/* 构造platform_device结构体 */
static struct platform_device led_dev = {
    .name         = "myled",
    .id       = -1,
    .num_resources    = ARRAY_SIZE(led_resource),
    .resource     = led_resource,
    .dev = {
    	.release = led_release,
	},
};

/* 向platform_bus注册一个设置好的platform_device */
static int led_dev_init(void)
{
	platform_device_register(&led_dev);
	return 0;
}

static void led_dev_exit(void)
{
	platform_device_unregister(&led_dev);
}

module_init(led_dev_init);
module_exit(led_dev_exit);

MODULE_LICENSE("GPL");

③驱动层:从总线那里获取需要的硬件资源,根据要求用它来完成一些硬件相关的操作,然后把驱动注册到总线,同时还需要完成probe成员函数--这是驱动和设备匹配之后的核心工作,这工作一般是向用户空间提供API,即实现并填充file_operation结构体成员函数

led_drv.c

#include <linux/module.h>
#include <linux/version.h>
#include <linux/init.h>
#include <linux/fs.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/sched.h>
#include <linux/pm.h>
#include <linux/sysctl.h>
#include <linux/proc_fs.h>
#include <linux/delay.h>
#include <linux/platform_device.h>
#include <linux/input.h>
#include <linux/irq.h>
#include <asm/uaccess.h>
#include <asm/io.h>

static int major;
static struct class *cls;
static struct device *led_drv_device;

/* 在platform_get_resource()和ioremap()之前,下面这变量没有任何实际意义 */
static volatile unsigned long *gpio_con;
static volatile unsigned long *gpio_dat;
static int pin;

static int led_open(struct inode *inode, struct file *file)
{
	/* 配置为输出 */
	*gpio_con &= ~(0x3<<(pin*2));
	*gpio_con |= (0x1<<(pin*2));
	return 0;
}

static ssize_t led_write(struct file *file, const char __user *buf, size_t count, loff_t * ppos)
{
	int val;
	copy_from_user(&val, buf, count);
	if (val == 1)
	{
		// 点灯
		*gpio_dat &= ~(1<<pin);
	}
	else
	{
		// 灭灯
		*gpio_dat |= (1<<pin);
	}
	return 0;
}

static struct file_operations led_fops = {
    .owner  =   THIS_MODULE,
    .open   =   led_open,
	.write	=	led_write,
};

/* 驱动和设备匹配成功之后的核心工作:回到了过去注册字符设备那一套 */
static int led_probe(struct platform_device *pdev)
{
	struct resource		*res;
	/* 根据platform_device的资源进行ioremap */
	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
	gpio_con = ioremap(res->start, res->end - res->start + 1);
	gpio_dat = gpio_con + 1;
	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
	pin = res->start;

	/* 注册字符设备驱动程序 */
	major = register_chrdev(0, "myled", &led_fops);
	cls = class_create(THIS_MODULE, "myled");
	led_drv_device = device_create(cls, NULL, MKDEV(major, 0), NULL, "led"); /* /dev/led */
	return 0;
}

static int led_remove(struct platform_device *pdev)
{
	device_unregister(led_drv_device);
	class_destroy(cls);
	unregister_chrdev(major, "myled");
	iounmap(gpio_con);
	return 0;
}

struct platform_driver led_drv = {
	.probe		= led_probe,
	.remove		= led_remove,
	.driver		= {
		.name	= "myled",
	}
};

static int led_drv_init(void)
{
	platform_driver_register(&led_drv);
	return 0;
}

static void led_drv_exit(void)
{
	platform_driver_unregister(&led_drv);
}

module_init(led_drv_init);
module_exit(led_drv_exit);

MODULE_LICENSE("GPL");

小结:写一个platform驱动需要我们做哪些事情?

①一个xxx_drv.c文件:

驱动初始化和注销函数:

xxx_drv_init()

platform_driver_register(struct platform_driver *drv);

xxx_drv_exit()

platform_driver_unregister(struct platform_driver *drv);

驱动初始化原材料:

struct platform_driver xxx_drv = {

.probe = xxx_probe,

.remove = xxx_remove,

.driver = {

.name = "xxx",

}

};

实现原材料的成员函数:

xxx_probe(struct platform_device *pdev)

{

//工作:

//1.根据需要向总线获取对应设备资源,

//2.然后拿着这资源该干嘛就干嘛去,有一点是通常都要做的:给应用层提供接口xxx_read() xxx_write() xxx_open() xxx_close()

}

xxx_remove(struct platform_device *pdev)

{

//把刚才probe函数里边注册申请的空间释放掉,动作刚好相反

}

②一个xxx_dev.c文件:

设备初始化和注销函数:

xxx_dev_init()

platform_device_register(struct platform_device *pdev);

xxx_dev_exit()

platform_device_unregister(struct platform_device *pdev);

设备初始化原材料:

static struct platform_device xxx_dev = {

.name         = "xxx",  //重构name成员

.id       = -1,

.num_resources    = ARRAY_SIZE(xxx_resource),

.resource     = xxx_resource,

.dev = {

.release = xxx_release,  //这个函数是要自己重定义的不然加载驱动模块时会出错,哪怕这个函数里边什么都不做都好。

},

};

定义并构造xxx_resource资源:有如下成员

struct resource {

resource_size_t start;

resource_size_t end;

const char *name;

unsigned long
flags; //只是一种代表

struct resource *parent, *sibling, *child;

};

时间: 2024-10-25 08:19:22

基于platform驱动模型的LED驱动的相关文章

linux驱动(九)platform驱动模型详解,以及基于platform驱动模型的led驱动

参考: http://blog.csdn.net/qq_28992301/article/details/52385518 http://blog.csdn.net/zoe6553/article/details/6372445 http://blog.chinaunix.net/uid-25014876-id-111745.html 1:什么是platform总线?platform总线是区别于实体总线USB. I2C.SPI .PIC总线的虚拟总线,一些usb设备选址的话需要通过USB总线来进

20150226 IMX257 总线设备驱动模型编程之驱动篇

20150226 IMX257 总线设备驱动模型编程之驱动篇 2015-02-26 11:42 李海沿 前面我们已经实现了 总线和设备 的驱动程序,接下来我们的任务就是 实现 驱动 了 地址:http://www.cnblogs.com/lihaiyan/p/4301079.html http://www.cnblogs.com/lihaiyan/p/4301072.html 在实现驱动程序之前,我们来想两个问题: 一.问题分析 1.什么时候驱动程序会在总线上找它可以处理的设备? 在driver

驱动学习之LED驱动框架

一:什么是驱动框架  (1)内核中驱动部分维护者针对每个种类的驱动设计一套成熟的.标准的.典型的驱动实现,然后把不同厂家的同类硬件驱动中相同的部分抽出来自己实现好,再把不同部分留出接口给具体的驱动开发工程师来实现,这就叫驱动框架.  (2)内核维护者在内核中设计了一些统一管控系统资源的体系,这些体系让内核能够对资源在各个驱动之间的使用统一协调和分配,保证整个内核的稳定健康运行.譬如系统中所有的GPIO就属于系统资源,每个驱动模块如果要使用某个GPIO就要先调用特殊的接口先申请,申请到后使用,使用

mini2440驱动奇谭——LED驱动与测试(动态加载)

我的博客:http://blog.csdn.net/muyang_ren 实现功能:开发板动态加载led驱动模块并能通过测试程序 系统:Ubuntu 14.04 驱动交叉编译内核:linux-2.6.32.2               //建立交叉编译 开发板:mini2440 (128M nandflash)     //关于怎么烧写linux到开发板请点击,Linux RootFs 选择rootfs_rtm_2440.img  (光盘目录:image/linux/rtm ) 开发所需工具:

第三十三天:Tiny4412驱动开发之LED驱动和按键驱动编写

从今天开始进入驱动开发的课程的学习,共完成四件事情.一:u-boot的简单移植,二:uboot中编写helloword程序 三:开发板中led灯的驱动编写,包括led点亮,闪烁,跑马,流水.四:开发板中按键的驱动编写,按下按键后在屏幕中显示字符. 一:u-boot的简单移植 1.进入开发板提供的源码文件包,解压uboot源码包. cd /home/bunfly/source_code/ tar xf uboot_tiny4412-20130729.tgz 2.进入uboot文件夹,更改uboot

字符设备驱动、平台设备驱动、设备驱动模型、sysfs的关系

Linux驱动开发的童鞋们来膜拜吧:-)  学习Linux设备驱动开发的过程中自然会遇到字符设备驱动.平台设备驱动.设备驱动模型和sysfs等相关概念和技术.对于初学者来说会非常困惑,甚至对Linux有一定基础的工程师而言,能够较好理解这些相关技术也相对不错了.要深刻理解其中的原理需要非常熟悉设备驱动相关的框架和模型代码.网络上有关这些技术的文章不少,但多是对其中的某一点进行阐述,很难找到对这些技术进行比较和关联的分析.对于开发者而言,能够熟悉某一点并分享出来已很难得,但对于专注传授技术和经验给

[kernel]字符设备驱动、平台设备驱动、设备驱动模型、sysfs几者之间的比较和关联

转自:http://www.2cto.com/kf/201510/444943.html Linux驱动开发经验总结,绝对干货! 学习Linux设备驱动开发的过程中自然会遇到字符设备驱动.平台设备驱动.设备驱动模型和sysfs等相关概念和技术.对于初学者来说会非常困惑,甚至对Linux有一定基础的工程师而言,能够较好理解这些相关技术也相对不错了.要深刻理解其中的原理需要非常熟悉设备驱动相关的框架和模型代码.网络上有关这些技术的文章不少,但多是对其中的某一点进行阐述,很难找到对这些技术进行比较和关

linux RTC 驱动模型分析【转】

转自:http://blog.csdn.net/yaozhenguo2006/article/details/6824970 RTC(real time clock)实时时钟,主要作用是给Linux系统提供时间.RTC因为是电池供电的,所以掉电后时间不丢失.Linux内核把RTC用作“离线”的时间与日期维护器.当Linux内核启动时,它从RTC中读取时间与日期,作为基准值.在运行期间内核完全抛开RTC,以软件的形式维护系统的当前时间与日期,并在需要时将时间回写RTC芯片.另外如果RTC提供了IR

第7章:LED驱动的实现原理

本章完成了一个真正意义上的 Linux 驱动.该 Linux 驱动用来控 制开发版上的 4个 LED 小灯.也就是说通过向 Linux 驱动发送数据可以控制 LED 小灯的开关.为 了方便称呼这个驱动,本书及后面的章节都将其称为 LED 驱动. 虽然 LED 驱动并不复杂,只是控制 了 4个 LED,"但 LED 驱动已经包括了 Linux 驱动所有必要的部分 一个完整的 Linux 驱动主要由 内部处理和与硬件交互降部分组成.其中内部处理主要是指 Linux 驱动的装载.卸载.与设备文件 相关