dm9000源码的分析

通过Platform机制开发发底层驱动的大致流程为: 定义 platform_device---注册 platform_device ---定义 platform_driver-----注册 platform_driver。 

1. Platform_device 定义于 kernel/include/linux/platform_device.h中，

struct platform_device {

 const char * name;

 u32 id;

 struct device dev;

 u32 num_resources;

 struct resource * resource;

};

定义一个platform_device一般需要初始化两个方面的内容：设备占用的资源resource和设备私有数据dev.platform_data。最重要的是resource

设备占用的资源主要是两个方面：IO内存和irq资源。

Resource定义于kernel/include/linux/ioport.h中，

struct resource {

 const char *name;

 unsigned long start, end;

 unsigned long flags;

 struct resource *parent, *sibling, *child;

};

实际上是对地址范围及其属性的一个描述。最后几个用于树型结构的指针是内核用于管理所有资源的。

而platform_data则是设置给struct device dev;中的platform_data指针(void *)。这个指针内核并不使用，而是驱动自身来定义及使用。

比如说对于DM9000，对应的platform_data定义于include/linux/dm9000.H中。

struct dm9000_plat_data {

unsigned int flags;

/* allow replacement IO routines */

void (*inblk)(void __iomem *reg, void *data, int len);

void (*outblk)(void __iomem *reg, void *data, int len);

void (*dumpblk)(void __iomem *reg, int len);

};

OK，初始化完资源和platform_data，一个平台设备就定义好了。把这个平台设备变量的地址添加到资源列表中去。比如在2410平台：

在arm/arm/mach-s3c2410/mach-smdk2410.c把设备地址添加到*smdk2410_devices[] __initdata 数组中去。

最后在arch/arm/mach-3sc2410/cpu.c 中初始化函数__init s3c_arch_init(void)会对smdk2410_devices[]每一个设备的指针ptr调用platform_device_register(ptr)。主要是建立device的层次结构(建立sysfs入口)，将设备占用的资源添加到内核资源管理。接下来看看platform_driver：

2. platform_driver结构定义于include/linux/platform_device.H :
struct platform_driver {

int (*probe)(struct platform_device *);

int (*remove)(struct platform_device *);

void (*shutdown)(struct platform_device *);

int (*suspend)(struct platform_device *, pm_message_t state);

int (*resume)(struct platform_device *);

struct device_driver driver;

};

它内部封装了一个device_driver，更有意思的是其它的全是函数，并且这些函数名与device_driver中提供的一样，只是参数由device * 变成了 platform_device *  。

驱动应该实现platform_driver中的这些操作，而内嵌的device_driver中的对应函数则在注册时被指定为内核指定的操作，这些指定操作只是把调用参数转换成platform_driver和platform_device来调用platform_driver提供的操作而已。 好像有点乱。。不过代码可以解释一切：

平台驱动注册：

int platform_driver_register(struct platform_driver *drv)

{

drv->driver.bus = &platform_bus_type;

if (drv->probe)

drv->driver.probe = platform_drv_probe;

if (drv->remove)

drv->driver.remove = platform_drv_remove;

if (drv->shutdown)

drv->driver.shutdown = platform_drv_shutdown;

if (drv->suspend)

drv->driver.suspend = platform_drv_suspend;

if (drv->resume)

drv->driver.resume = platform_drv_resume;

return driver_register(&drv->driver);

}

OK，如果device_driver的方法没有定义就会变成对应的platform_drv_*方法。

来看看其中的一个的实现：比如 platform_drv_probe

static int platform_drv_probe(struct device *_dev)

{

struct platform_driver *drv = to_platform_driver(_dev->driver);

struct platform_device *dev = to_platform_device(_dev);

return drv->probe(dev);

}

事情很清楚，先把设备的device_driver转成platform_driver,同样转换device为platform_device。然后去调用platform_driver提供的函数。类型转换当然是通过container_of()宏实现的。

因此，驱动只需要实现platform_driver中的方法。然后注册即可。

关于注册，由上面的代码可知，最终也是通过 driver_register(&drv->driver);来做的。

3.更深入的小窥一下平台设备与平台驱动的注册：

根据LDD3中指出的设备模型，一个设备和驱动必然属于某一个总线。Platform_device和platform-driver在层次上隶属于叫platform_bus_type的总线类型。OK，平台驱动注册的时候(平台设备必须先于驱动注册)将引用它所属总线的匹配函数去决定总线上每一个设备是否属于自己。然后二者建立联系：设备的驱动指针指向该驱动，驱动的设备列表中加入匹配的设备。

当然，这是在设备和驱动这一层面来说的，更深入一层，kobjects和ksets建立层次关系，建立sysfs入口等等。。

注意，platform_bus_type的匹配函数只是比较一下driver和device的name是否相同。因此，同一设备的platform_device和platform_driver的name应该设为相同的。见platform_bus_type匹配函数定义：
static int platform_match(struct device * dev, struct device_driver * drv)

{

struct platform_device *pdev = container_of(dev, struct platform_device, dev);

return (strncmp(pdev->name, drv->name, BUS_ID_SIZE) == 0);

}

因此，dm9000的platform_device和platform_driver的name都为"Dm9000"。

4.下面一个问题：资源怎么用？？Platform_data一般怎么用？

资源描述的是设备占用的IO内存，IO端口，及中断线。

Dm9000驱动中是这样使用的。这符合惯例：

在probe中获取资源，并且申请资源，最后映射到内核空间，把映射结果保存起来。

在net_device中的open函数里，注册中断处理函数。

Platform_data的使用极为灵活，首先platform_data结构不同设备之间没有定论，一般可用来保存特定于设备的一些配置，操作等。比如对于DM9000，可以存在按字节，按字访问的不同模式，因此其platform_data定义成这样：

struct dm9000_plat_data {

unsigned int flags;

/* allow replacement IO routines */

void (*inblk)(void __iomem *reg, void *data, int len);

void (*outblk)(void __iomem *reg, void *data, int len);

void (*dumpblk)(void __iomem *reg, int len);

};

其中flags是8/16位模式的选择标志，下面三个是在该模式下的IO存取函数。 

然后Dm9000驱动只使用了它的flags标志，其余的并不使用。

因为对于网络net_device，有一个叫着private_data的指针，在分配一个net_device的时候可以让内核为其开辟指定大小的内存。这部分内存可以通过net_device访问，而且内容也是驱动开发者自定义的。在DM9000的驱动中，net_devict的private_data使用了一个叫board_info的结构体来包括更多设备相关的信息和操作。

dm9000_plat_data提供的内容也被包括进board_info。因此驱动只使用了初始时设置的flags，除此外dm9000_plat_data中的方法没有使用的必要。

从中得到的启示:
Device 包含一个platform_data。

Net_device则包含一个private区域.

这样既实现了设备模型的统一管理，又实现了保持不同设备的信息与方法的灵活性。

四. Dm9000驱动源码的简要分析。

1.定义并注册DM9000 的 platform_device 。定义设备占用资源和platform_data。(具体的见前面)

2.将platform_device添加到板子的设备列表中去，在系统初始化时注册入内核。

3.在DM9000.C中，定义了dm9000的platform_driver。
static struct platform_driver dm9000_driver = {

.driver = {

.name    = "dm9000",

.owner  = THIS_MODULE,

},

.probe   = dm9000_probe,

.remove  = dm9000_drv_remove,

.suspend = dm9000_drv_suspend,

.resume  = dm9000_drv_resume,

};

这里面关健的东西是name和probe，remove。

4.在模块初始化函数module_init(dm9000_init);中注册dm9000_driver。
platform_driver_register(&dm9000_driver);
这将导致驱动的probe函数被调用。

5.驱动还定义了一个数据结构：board_info来记录芯片的信息及操作。如统计信息，读写操作，占用的IO地址资源，状态。

6.OK，现在接着4说，模块初始化函数最终将调用probe函数。这个函数完成的基本过程 ：

1)获取一个netdevice:
ndev = alloc_etherdev(sizeof (struct board_info));

2)获取设备资源：
db->addr_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
db->data_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
db->irq_res  = platform_get_resource(pdev, IORESOURCE_IRQ, 0);

3)申请IO资源，映射到内核并保存映射地址：
db->addr_req = request_mem_region(db->addr_res->start, i,pdev->name);
db->data_req = request_mem_region(db->data_res->start, iosize,pdev->name);
db->io_addr = ioremap(db->addr_res->start, i);
db->io_data = ioremap(db->data_res->start, iosize);
这里的db即是驱动自定义的board_info结构指针。伴随ndev申请内存。

4)根据DM9000数据位宽设置 读写数据帧的函数指针。
Dm9000_set_io(db, iosize);

5)OK，现在复位芯片：dm9000_reset(db); db中已经包含了详细的芯片信息。

6)读取芯片ID号并判断是否为0x90000A46。

7)初始化以太网ndev : ether_setup(ndev);

8)设置ndev的基本操作：
ndev->open  = &dm9000_open;
ndev->hard_start_xmit    = &dm9000_start_xmit;
ndev->tx_timeout         = &dm9000_timeout;
ndev->watchdog_timeo = msecs_to_jiffies(watchdog);
ndev->stop  = &dm9000_stop;
ndev->get_stats  = &dm9000_get_stats;
ndev->set_multicast_list = &dm9000_hash_table;

9)添加一些打开中断，设置MAC地址的操作在这里。

10)将ndev记录于平台设备platform_dev中去。注册ndev。
platform_set_drvdata(pdev, ndev);  //pdev->dev->dev_driver_data=ndev.
ret = register_netdev(ndev);

OK，probe的使命OVER了。这也是ndev与platform_dev建立联系的地方。
可以这么理解，linux的设备模型负责的只是设备的管理(检测，启动，移除)，而如何访问这个设备的数据，比如说以字符流模式，块设备方式，网络接口，则定义相应的cdev,gendisk,ndev，然后注册到内核。所有的数据访问工作都以这三种界面提供。

7.OK，一旦probe正常的执行完，内核中注册好了eth0这个网络接口(因为只有一个网卡)。在系统启动之后，配置eth0,这将引起ndev->open()调用。来看看open做些什么？
Open(dev)流程：
申请中断线：
request_irq(dev->irq, &dm9000_interrupt, IRQF_SHARED, dev->name, dev)
复位DM9000，初始化芯片的各个寄存器使其工作在适当的状态。
设置timer(用于传输超时)，
调用netif_start_queue(dev);使设备可以开始收发数据。

8.OK，配置好eth0接口后，网络设备连接好。数据收发就绪。现在简要的分析一下收发过程：
发送数据包：协议层用已经封装好上层协议数据的skb_buffer调用dm9000_start_xmit(struct sk_buff *skb, struct net_device *dev)函数。
发送函数流程：
netif_stop_queue(dev); 暂停接口，使上层暂时不能发送数据。
正在发送中的数据计数加1。
如果只有当前包发送，写指令，写数据帧，发送包。
如果多于一包数据正在发送，当前帧不发送。
释放skb。
重新使能接口：netif_wake_queue(dev);

发送结束，DM9000产生中断，在中断函数中读取芯片相关寄存器判断中断原因，如果是发送结束，则递减正发送包计数。并netif_wake_queue(dev);

9.接收过程：
网络数据包到达，DM9000自动接收并存放在DM内部RAM中，产生中断。在中断处理中识别中断原因并调用接收处理函数dm9000_rx(struct net_device *dev)。
dm9000_rx：
读取芯片相关寄存器确认DM9000正确的收到一帧数据。
申请skb_buffer，将数据从DM9000中拷贝到skb_buffer中。设置skb->dev=nev,skb->protocol=eth_type_trans(skb, dev)。

然后把skb_buffer交给上层协议：netif_rx(skb);

最后更新接口统计信息：db->stats.rx_packets++; 收到包总数+1。

整个DM9000驱动的移植和源码主要部分的简要分析至此结束。