Chinaunix首页 | 论坛 | 博客
  • 博客访问: 268092
  • 博文数量: 60
  • 博客积分: 2010
  • 博客等级: 大尉
  • 技术积分: 820
  • 用 户 组: 普通用户
  • 注册时间: 2010-01-18 00:28
文章分类

全部博文(60)

文章存档

2010年(60)

我的朋友

分类:

2010-04-16 09:25:27

今天折腾了一天的SPI设备的驱动加载,甚至动用了逻辑分析仪来查看spi总线的波形,主要包括两个SPI设备,at45db321d和mcp2515,一个是串行的dataflash,一个是can总线设备芯片。前者对于我们来说非常重要,我们可以借助该设备对uboot和kernel以及根文件系统进行更新。
    预备知识:设备和驱动是如何匹配的?系统的热插拔是如何实现的?
    首先一点,设备和驱动是严格区分的,设备是设备,驱动是驱动,设备通过struct device来定义,当然用户也可以将该结构体封装到自己定义的device结构体中,例如,struct platform_device,这是我们采用platform_bus_type总线的设备定义的结构体形式:

include/linux/platform_device.h文件中:
struct platform_device {
    const char    * name
    u32        id
    struct device    dev
    u32        num_resources
    struct resource    * resource
}
只要是9260的外围模块,就像IIC硬件控制器,SPI硬件控制器,都被完全的定义成这种结构体的格式,这种结构体主要包含了硬件资源和名称,硬件资源分为寄存器和IRQ两种。platform_device通过向内核注册struct device dev这个结构体来告诉内核加载这个设备,
    方法就是  device_register(&platform_device->dev)  
内核不关心你使用的是platform_device还是spi_device,内核只关心你的struct device结构体,内核通过这个struct device结构体自然能够顺藤摸瓜找到你是platform_device还是spi_device,这就是linux最引以为傲的contian_of()大法。

驱动通过struct driver这个结构体来定义,与struct device一致,你也可以用自己的结构体去封装:例如,struct 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 (*suspend_late)(struct platform_device *, pm_message_t state)
    int (*resume_early)(struct platform_device *)
    int (*resume)(struct platform_device *)
    struct device_driver driver
}
与device一致,应用程序通过driver_register(&platform_driver->driver)向内核中注册你当前的驱动,而内核不关心你封装成的结构,而内核搜索的方法还是同样的contain_of大法。

 

系统如何将这两者匹配上的?而不会将iic的设备加载到spi的驱动上面?不会将这个iic设备的驱动加载到那个iic设备上,设备和驱动之间是如何联系的?总线,这就是总线的作用!
include/linux/device.h文件中有总线类型的定义。
struct bus_type {
    const char        * name

    struct subsystem    subsys
    struct kset        drivers
    struct kset        devices
    struct klist        klist_devices
    struct klist        klist_drivers

    struct blocking_notifier_head bus_notifier

    struct bus_attribute    * bus_attrs
    struct device_attribute    * dev_attrs
    struct driver_attribute    * drv_attrs

    int        (*match)(struct device * dev, struct device_driver * drv)
    int        (*uevent)(struct device *dev, char **envp,
                  int num_envp, char *buffer, int buffer_size)
    int        (*probe)(struct device * dev)
    int        (*remove)(struct device * dev)
    void        (*shutdown)(struct device * dev)

    int (*suspend)(struct device * dev, pm_message_t state)
    int (*suspend_late)(struct device * dev, pm_message_t state)
    int (*resume_early)(struct device * dev)
    int (*resume)(struct device * dev)
}
这个总线设备中最重要的可能是match成员,由于我们一般很少去建立一个新的总线,所以我们很少涉及总线的编程,我们就只关注我们所关注的。
总线如何将两者关联起来,热插拔大家知道吧,当一个设备被通过device_register注册到内核中时,会导致一个热插拔事件产生,系统会遍历该总线上的所有驱动程序,调用bus的match算法,来寻找与该设备相匹配的驱动程序,当一个驱动注册到内核的时候,处理过程与此相似(这是我理解的阿,大家批评指正),而一般的macth算法都比较简单,例如platform_bus的匹配算法就很简单,就是比较platform_device和platform_driver的name成员,如果匹配成功,就加载相应的设备或者驱动!这就完成了一个连接的过程。。。

 

那么这两种设备驱动中最重要的类型在linux中如何表现出来,那我们就有必要介绍一下从2.6开始实现的sys文件系统了,

/sys/bus $ cat /etc/fstab
proc            /proc   proc    defaults    0   0
devpts   /dev/pts   devpts  defaults   0 0
tmpfs           /dev/shm         tmpfs  defaults        0       0
sysfs           /sys             sysfs          defaults        0       0
/dev/mtdblock2  /mnt/flash2     yaffs   defaults        0       0

加载这个文件系统对于我们分析设备模型是非常有好处的。
sys文件夹下一般有如下的目录:
/sys $ ls -al
drwxr-xr-x   10 root     root            0 Jan  1  1970 .
drwxrwxrwx   11 1000     tao          4096 May 22 06:56 ..
drwxr-xr-x    7 root     root            0 Oct 27 14:09 block
drwxr-xr-x    8 root     root            0 Jan  1  1970 bus
drwxr-xr-x   21 root     root            0 Jan  1  1970 class
drwxr-xr-x    4 root     root            0 Jan  1  1970 devices
drwxr-xr-x    2 root     root            0 Jan  1  1970 firmware
drwxr-xr-x    2 root     root            0 Jan  1  1970 fs
drwxr-xr-x    2 root     root            0 Jan  1  1970 kernel
drwxr-xr-x   22 root     root            0 Oct 27 14:10 module
block是由于历史原因形成的block设备的文件夹。我们关心的是bus文件夹。
我们以spi设备为例:spi部分要包括两种设备,一种是platform_device,一种是spi_device。
在arch/arm/mach-at91/at91sam9260_device.c文件中,定义的SPI硬件控制模块设备,这我们不需要关心。
还有一种是spi_device,定义在arch/arm/mach-at91/board-sam9260ek.c文件中,这就是我们的dataflash和mcp2515设备,
所以如何设备加载成功的话,在bus下面的每个目录里面,都存在devices和drivers两个文件夹,分别对应设备和文件。
/sys/bus/platform/devices $ ls -al
drwxr-xr-x    2 root     root            0 Oct 27 16:01 .
drwxr-xr-x    4 root     root            0 Jan  1  1970 ..
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 at91_i2c -> ../../../devices/platform/at91_i2c
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 at91_nand -> ../../../devices/platform/at91_nand
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 at91_ohci -> ../../../devices/platform/at91_ohci
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 atmel_spi.0 -> ../../../devices/platform/atmel_spi.0
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 atmel_spi.1 -> ../../../devices/platform/atmel_spi.1
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 atmel_usart.0 -> ../../../devices/platform/atmel_usart.0
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 atmel_usart.1 -> ../../../devices/platform/atmel_usart.1
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 atmel_usart.2 -> ../../../devices/platform/atmel_usart.2
lrwxrwxrwx    1 root     root            0 Oct 27 16:01 macb -> ../../../devices/platform/macb
驱动
/sys/bus/platform/drivers/atmel_spi $ ls -al
drwxr-xr-x    2 root     root            0 Jan  1  1970 .
drwxr-xr-x    8 root     root            0 Jan  1  1970 ..
lrwxrwxrwx    1 root     root            0 Oct 27 16:10 atmel_spi.0 -> ../../../../devices/platform/atmel_spi.0
lrwxrwxrwx    1 root     root            0 Oct 27 16:10 atmel_spi.1 -> ../../../../devices/platform/atmel_spi.1
w-    1 root     root         4096 Oct 27 16:10 bind
w-    1 root     root         4096 Oct 27 16:10 unbind
如果出现上面的这个情况,说明你的设备(两路spi总线)和驱动都加载成功了,如果你的devices下面没有spi.0设备和spi.1设备的话,说明
board-sam9260ek.c文件中的这个函数出错:
static void __init ek_board_init(void)
{
    /* Serial */
    at91_add_device_serial()
    /* USB Host */
    at91_add_device_usbh(&ek_usbh_data)
    /* USB Device */
    at91_add_device_udc(&ek_udc_data)
    /* SPI */
    at91_add_device_spi(ek_spi_devices, ARRAY_SIZE(ek_spi_devices))
    /* NAND */
    at91_add_device_nand(&ek_nand_data)
    /* Ethernet */
    at91_add_device_eth(&ek_macb_data)
    /* MMC */
    at91_add_device_mmc(0, &ek_mmc_data)
    /* I2C */
    at91_add_device_i2c()
}
这里是设备注册的地方,我们还应该在下面这个目录下看到这两个文件。
/sys/bus/spi/devices $ ls -al
drwxr-xr-x    2 root     root            0 Oct 27 14:09 .
drwxr-xr-x    4 root     root            0 Jan  1  1970 ..
lrwxrwxrwx    1 root     root            0 Oct 27 14:09 spi0.1 -> ../../../devices/platform/atmel_spi.0/spi0.1
lrwxrwxrwx    1 root     root            0 Oct 27 14:09 spi1.0 -> ../../../devices/platform/atmel_spi.1/spi1.0
这两个链接说明我们的两个spi设备注册都被接受了,剩下来就是驱动的问题。有人看不懂这个sys文件系统的层次关系,其实这里比较好说明,就是spi0.1是atmel_spi.0设备的子设备嘛,很好理解的。

驱动:
platform_driver驱动:
/sys/bus/platform/drivers $ ls -al
drwxr-xr-x    8 root     root            0 Jan  1  1970 .
drwxr-xr-x    4 root     root            0 Jan  1  1970 ..
drwxr-xr-x    2 root     root            0 Jan  1  1970 at91_i2c
drwxr-xr-x    2 root     root            0 Jan  1  1970 at91_nand
drwxr-xr-x    2 root     root            0 Jan  1  1970 at91_ohci
drwxr-xr-x    2 root     root            0 Oct 27 16:10 atmel_spi
drwxr-xr-x    2 root     root            0 Jan  1  1970 atmel_usart
drwxr-xr-x    2 root     root            0 Jan  1  1970 macb
我们可以看到这个驱动只有一个atmel_spi,这个驱动是在哪加载的?
driver/spi/atmel_spi.c文件加载的。

spi_driver驱动:
/sys/bus/spi/drivers $ ls -al
drwxr-xr-x    4 root     root            0 Oct 27 14:10 .
drwxr-xr-x    4 root     root            0 Jan  1  1970 ..
drwxr-xr-x    2 root     root            0 Oct 27 14:10 mcp2515
drwxr-xr-x    2 root     root            0 Oct 27 14:09 mtd_dataflash
这是我们加载的两个驱动,说明驱动也加载正常了。

下面我们来说说我们遇到的问题吧。
在设备和驱动都加载正常之后,出现与dataflash设备通信不上的情况,驱动加载的时候,读取芯片的状态字读出是0xff,说明工作不正常,动用逻辑分析仪监控spi总线的通信,意外的发现,sck信号和cs信号正常,但是mosi无信号输出,开始觉得可能是spi总线适配器有问题,后来仔细观察原理图之后,发现dataflash和mmc/sd是使用同样的io口的,即pa0,pa1,pa2,而我的内核配置中打开了对mmc的支持,所以导致mosi不正常,所以可能9260的mmc与dataflash不能同时使用,但9263的可以。
解决办法:make menuconfig
Device Drivers->MMC/SD card support,取消其支持,问题解决
文章出处:DIY部落()

阅读(7650) | 评论(0) | 转发(3) |
给主人留下些什么吧!~~