platform_get_resource的分析

阅读platformdriver的代码时,发现在probe函数直接调用platform_get_resource从pdev中获取io内存,但却没有判断传给probe的pdev是否属于这个驱动 !

后来发现原来在arch目录下的对应目录里面有个devs.c文件(这个文件可能因不同的架构而不一样),这个文件里面声明了一个platform设备的资源数组foo_devices,原型如下:

static struct platform_device* foo_devices[] __initdata;

这个数组里面包含了所有platform设备的资源信息。例如:一个设备的资源声明如下:

static struct resource foo_resource[] =
{
[0] =
{
.start = (FOO_BASE_PA),
.end = (FOO_BASE_PA) + (0x0008000),
.flags = IORESOURCE_MEM,
},
[1] =
{
.start = (IRQ_FOO),
.end = (IRQ_FOO),
.flags = IORESOURCE_IRQ,
},
};

static struct platform_device device_foo =
{
.name = "device_foo",
.id = 0,
.resource = foo_resource,
.num_resources = ARRAY_SIZE(foo_resource),
.dev =
{
//根据源代码,这两个成员置成0表示不起作用
.dma_mask = 0x0,
.coherent_dma_mask = 0x0,
},
};

那么将这个device_foo加入foo_devices数组,就能直接在probe函数中用platform_get_resource获取资源了,但是要注意驱动的name成员必须和platform_device结构中的name成员完全相同。

那为什么加入foo_devices数组后就能直接访问了呢?
在 相关体系的machine_desc结构体中(对于每个特定平台都有一个MACHINE_START宏用来定义machine_desc结构体),有一个 接口init_machine,这个接口中会调用platform_add_devices添加foo_devices。例如:

platform_add_devices(foo_devices);

platform_get_resource函数源码如下:

struct resource *platform_get_resource(struct platform_device *dev,

unsigned int type, unsigned int num)

{

int i;

for (i = 0; i < dev->num_resources; i++) {

struct resource *r = &dev->resource[i];

if (type == resource_type(r) && num-- == 0)

return r;

}

return NULL;

}

函数分析:

struct resource *r = &dev->resource[i];

这行代码使得不管你是想获取哪一份资源都从第一份资源开始搜索。

if (type == resource_type(r) && num-- == 0)

这行代码首先通过type == resource_type(r)判断当前这份资源的类型是否匹配,如果匹配则再通过num-- == 0判断是否是你要的,如果不匹配重新提取下一份资源而不会执行num-- == 0这一句代码。

通过以上两步就能定位到你要找的资源了,接着把资源返回即可。如果都不匹配就返回NULL。

实例分析:

下面通过一个例子来看看它是如何拿到设备资源的。

设备资源如下:

static struct resource s3c_buttons_resource[] = {

[0]={

.start = S3C24XX_PA_GPIO,

.end   = S3C24XX_PA_GPIO + S3C24XX_SZ_GPIO - 1,

.flags = IORESOURCE_MEM,

},

[1]={

.start = IRQ_EINT8,

.end   = IRQ_EINT8,

.flags = IORESOURCE_IRQ,

},

[2]={

.start = IRQ_EINT11,

.end   = IRQ_EINT11,

.flags = IORESOURCE_IRQ,

},

[3]={

.start = IRQ_EINT13,

.end   = IRQ_EINT13,

.flags = IORESOURCE_IRQ,

},

[4]={

.start = IRQ_EINT14,

.end   = IRQ_EINT14,

.flags = IORESOURCE_IRQ,

},

[5]={

.start = IRQ_EINT15,

.end   = IRQ_EINT15,

.flags = IORESOURCE_IRQ,

},

[6]={

.start = IRQ_EINT19,

.end   = IRQ_EINT19,

.flags = IORESOURCE_IRQ,

}

};

驱动中通过下面代码拿到第一份资源:

struct resource *res;

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

函数进入for里面,i=0,num_resources=7,拿出resource[0]资源。resource_type(r)提取出该份资源 的资源类型并与函数传递下来的资源类型进行比较,匹配。Num=0(这里先判断是否等于0再自减1)符合要求,从而返回该资源。

获取剩下资源的代码如下:

for(i=0; i<6; i++){

buttons_irq = platform_get_resource(pdev,IORESOURCE_IRQ,i);

if(buttons_irq == NULL){

dev_err(dev,"no irq resource specified\n");

ret = -ENOENT;

goto err_map;

}

button_irqs[i] = buttons_irq->start;

}

分析如下:

For第一次循环:

buttons_irq = platform_get_resource(pdev,IORESOURCE_IRQ,0);

在拿出第一份资源进行resource_type(r)判断资源类型时不符合(此时num-- == 0这句没有执行),进而拿出第二份资源,此时i=1,num_resources=7,num传递下来为0,资源类型判断时候匹配,num也等于0,从而确定资源并返回。

For第二次循环:

buttons_irq = platform_get_resource(pdev,IORESOURCE_IRQ,1);

拿出第二份资源的时候resource_type(r)资源类型匹配,但是num传递下来时候为1,执行num-- == 0时不符合(但num开始自减1,这导致拿出第三份资源时num==0),只好拿出第三份资源。剩下的以此类推。

总结:

struct resource *platform_get_resource(struct platform_device *dev,

unsigned int type, unsigned int num)

unsigned int type决定资源的类型,unsigned int num决定type类型的第几份资源(从0开始)。即使同类型资源在资源数组中不是连续排放也可以定位得到该资源。

比如第一份IORESOURCE_IRQ类型资源在resource[2],而第二份在resource[5],那

platform_get_resource(pdev,IORESOURCE_IRQ,0);

可以定位第一份IORESOURCE_IRQ资源;

platform_get_resource(pdev,IORESOURCE_IRQ,1);

可以定位第二份IORESOURCE_IRQ资源。

之所以能定位到资源,在于函数实现中的这一行代码:

if (type == resource_type(r) && num-- == 0)

该行代码,如果没有匹配资源类型,num-- == 0不会执行而重新提取下一份资源,只有资源匹配了才会寻找该类型的第几份资源,即使这些资源排放不连续。

时间: 2024-10-07 19:23:55

platform_get_resource的分析的相关文章

IMX6Q RTC驱动分析

对于在工作中学习驱动的,讲究的是先使用,再理解.好吧,我们来看看板子里是如何注册的? 在板文件里,它的注册函数是这样的: imx6q_add_imx_snvs_rtc() 好吧,让我们追踪下去: 1 extern const struct imx_snvs_rtc_data imx6q_imx_snvs_rtc_data __initconst; 2 #define imx6q_add_imx_snvs_rtc() 3 imx_add_snvs_rtc(&imx6q_imx_snvs_rtc_d

tty初探—uart驱动框架分析(二)uart_add_one_port

在前面的一篇文章中,我们分析了一个 uart_driver 的向上注册过程,主要是 tty 的一些东西,知道了 tty 注册了一个字符设备驱动,我们在用户空间 open 时将调用到 uart_port.ops.startup ,在用户空间 write 则调用 uart_port.ops.start_tx ,还知道了如何 read 数据等等.但是,这些都是内核帮我们实现好的,在真正的驱动开发过程中几乎不涉及那些代码的修改移植工作,真正需要我们触碰的是 uart_port 这个结构体,它真正的对应于

蓝牙驱动分析 linux

蓝牙驱动分析 这个驱动分析的是OK6410开发板自带的内核版本是linux3.0.1,所支持的wifi和蓝牙一体芯片是marvell的8688和8787.根据开发板的设计,芯片与主机之间是通过sdio协议接口通信的,所以驱动也是通过sdio的方式写的. 个人分析驱动的过程是从插入设备驱动的动作开始的. 首先每次插入设备和拔出设备驱动都会通过终端打印相应的信息,判断在sd卡槽中肯定是触发中断的,通过看硬件原理图和数据手册中的SDMMC控制器可知用于mmc的中断号分别为56和57,回到代码中.在内核

UART驱动分析

在linux用户层上要操作底层串口需要对/dev/ttySxxx操作,这里的ttySx指实际的终端串口. 以下以全志A64为实例,分析UART驱动以及浅谈TTY架构. linux-3.10/drivers/tty/serial/sunxi-uart.c: 1 static const struct of_device_id sunxi_uart_match[] = { 2 { .compatible = "allwinner,sun8i-uart", }, 3 { .compatibl

RTC驱动模型分析

①RTC设备层: 设备资源的定义:arch/arm/plat-s3c24xx/devs.c static struct resource s3c_rtc_resource[] = { [0] = { .start = S3C24XX_PA_RTC, .end = S3C24XX_PA_RTC + 0xff, .flags = IORESOURCE_MEM, }, [1] = { .start = IRQ_RTC, .end = IRQ_RTC, .flags = IORESOURCE_IRQ,

i2c驱动程序全面分析,从adapter驱动程序到设备驱动程序

开发板    :mini2440 内核版本:linux2.6.32.2 驱动程序参考:韦东山老师毕业班i2c 内容概括: 1.adapter client 简介 2.adapter 驱动框架 2.1 设备侧 2.2 驱动侧 2.2.1 probe 函数 2.2.1.1 注册adapter new_device del_device board_info i2c_detect i2c_new_device 3.i2c 设备驱动框架 3.1 i2c_bus_type 3.2 i2c_driver 3

OTG驱动分析(一)

前一段时间弄了2个礼拜的OTG驱动调试,感觉精神疲惫啊.主要原因还是自己对OTG功能不了解造成的. 如今最终完毕可是对实质原理还有些模糊.所以自己又一次总结一下. 由于自己是菜鸟,所以用菜鸟的白话方式分析. 高手滤过吧. 所谓OTG功能就是具备该功能的设备就可以当主设备(host)去轮询别人,也能够当从设备(device)去被别人轮--(双性人?). 正所谓全部的产品和功能都是由于需求存在的,举个最简单的需求.原来MP3想传送一个歌曲都得通过电脑.如今仅仅要两个MP3链接,当中一个MP3有OTG

S3C6410 LCD驱动分析(转)

一. 理论分析1. 几个概念:FIMC :    Fully Interactive Mobile Camera (完全交互式移动摄像机)FIMD:     Fully Interactive Mobile Display (完全交互式移动显示设备)2. 设置VCLK在VIDCON0中bit[3:2]-->Select the Video Clock source =00 --> HCLK=133MHZbit[13:6] --> CLKVAL_F = 13  (这个值是在驱动中计算出来的

am335x i2c分析

/***************************************************************************** * am335x i2c分析 * i2c驱动主要关注i2c_algorithm结构体,不同芯片实现自己的master_xfer函数. * 不同芯片i2c驱动框架都类似. * 本文主要描述am335x_i2c设备和驱动的注册,提及文件: * arch/arm/mach-omap2/board-am335xevm.c * drivers/i2c