邮箱：zhuimengcanyang@163.com 痴爱嵌入式技术的蜗牛
分类： LINUX
2015-11-17 08:49:35
平台总线设备驱动模型—代码分析
上节我们分析了平台总线的工作流程，这一节里我们来分析代码：
先来看设备驱动代码：
点击(此处)折叠或打开
static struct resource led_resource[] = {
[0] = {
.start = 0x56000050,
.end = 0x56000050 + 8 - 1,
.flags = IORESOURCE_MEM, //表示是内存资源，使用的时候需要ioremap
},
[1] = {
.start = 5,
.end = 5,
.flags = IORESOURCE_IRQ, //表示是中断资源，不用映射
}
};
static void led_release(struct device * dev)//这个函数是必须的，但里面可以什么都不做
{
}
static struct platform_device led_dev = {
.name = "myled", //这里的设备名要和驱动里的驱动名相同的哦
.id = -1,
.num_resources = ARRAY_SIZE(led_resource),
.resource = led_resource, //这里就是刚刚定义的资源
.dev = {
.release = led_release, //注册release函数，应该是platform_device_unregister的时候会调用
},
};
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");
再来看一下驱动代码：
点击(此处)折叠或打开
static volatile unsigned long *gpio_dat;
static struct class *cls;
static int major;
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 int led_write (struct file *file, const char __user *buff, size_t count, loff_t *ppos)
{
int val;
copy_from_user(&val, buff, count);
if (val == 0)
{
*gpio_dat &=
~(1<
}
else
{
*gpio_dat |=
(1<
}
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;
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;
printk("led_probe, found led\n");
major=register_chrdev(0, "myled", &led_fops); //注册字符设备，那么下面肯定重点放在了file_operations结构体上了
cls = class_create(THIS_MODULE, "myled"); //创建类
class_device_create(cls, NULL, MKDEV(major, 0), NULL, "led");//类下创建设备，这样保证了udev机制可以自动创建设备文件
return 0;
}
static int led_remove(struct platform_device *pdev)
{
printk("led_remove, remove led\n");
class_device_destroy(cls, MKDEV(major, 0));
class_destroy(cls);
unregister_chrdev(major, "myled");
iounmap(gpio_con);
return 0;
}
struct platform_driver led_drv = {
.probe = led_probe, //这里是probe函数，当总线发现有设备的名字和驱动的名字相同时会调用这个函数，所以我们的主要工作放在了这里面
.remove = led_remove, //这个函数应该是在platform_driver_unregister是调用用，因此可以将一些卸载函数放在这个地方
.driver = {
.name = "myled", //这名字要和设备相匹配的哦
}
};
static int led_drv_init(void)
{
platform_driver_register(&led_drv);//注册平台总线驱动，里面有比较重要的platform_driver 结构体
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");
下面再来看看测试程序：
点击(此处)折叠或打开
int main(int argc, char **argv)
{
int fd;
int val = 1;
fd = open("/dev/led", O_RDWR);
if (fd < 0)
{
printf("can't open!\n");
}
if (argc != 2)
{
printf("Usage :\n");
printf("%s on|off\n", argv[0]);
return 0;
}
if (strcmp(argv[1], "on") == 0)
{
val = 1;
}
else
{
val = 0;
}
write(fd, &val, 4);
return 0;
}
测试方法：假设测试程序编译出来后名字是ledtest
我们在命令行输入：./ledtest on 则灯亮
输入：./ledtest off 则灯灭
我们来总结一下这三个程序的原理：
比如我们先注册了设备，这时总线会遍历驱动，寻找可以匹配该设备的驱动。由于我们还没有注册驱动，所以这时候不会发生什么事情。接着我们注册了驱动，这时会去遍历设备，这时因为设备已经注册了，所以会找到匹配项，这时将调用驱动中的probe函数，在这个函数里完成了字符设备的注册，以及设备文件的自动生成。然后运行我们的测试程序就可以对字符设备进行操作了。
那我们想想这种机制有什么好处呢？其实这就是采用了一种分离的机制，将设备和驱动分开，当我们想操作其它设备的时候，只需要修改设备文件就可以了！比如我们想操作其它的led，那么只需将设备文件里的资源改掉就可以了，并不需要修改驱动文件。这就为移植提供了很大的方面，后面会深有体会的哦！
下面是一些小的知识点：
1、resource *platform_get_resource(struct platform_device *dev, unsigned int type, unsigned int num)
功能：
获取平台设备中定义的资源
参数：
dev：平台设备
type：要获取的资源的类型
num：表示第几个该类型的资源
