SDIO总线 驱动

SDIO卡

       SDIO卡是在SD内存卡接口的基础上发展起来的接口，SDIO接口兼容以前的SD内存卡，并且可以连接SDIO接口的设备，目前根据SDIO协议的SPEC，SDIO接口支持的设备总类有蓝牙，网卡，电视卡等。

       SDIO协议是由SD卡的协议演化升级而来的，很多地方保留了SD卡的读写协议，同时SDIO协议又在SD卡协议之上添加了CMD52和CMD53命令。由于这个，SDIO和SD卡规范间的一个重要区别是增加了低速标准，低速卡的目标应用是以最小的硬件开始来支持低速I/O能力。低速卡支持类似调制解调器,条形码扫描仪和GPS接收器等应用。高速卡支持网卡，电视卡还有“组合”卡等，组合卡指的是存储器+SDIO。

       SDIO和SD卡的SPEC间的又一个重要区别是增加了低速标准。SDIO卡只需要SPI和1位SD传输模式。低速卡的目标应用是以最小的硬件开支来支持低速I/O能力，低速卡支持类似MODEM，条形扫描仪和GPS接收器等应用。对组合卡来说，全速和4BIT操作对卡内存储器和SDIO部分都是强制要求的。

       在非组合卡的SDIO设备里，其最高速度要只有达到25M，而组合卡的最高速度同SD卡的最高速度一样，要高于25M。

 

SDIO总线

       SDIO总线和USB总线类似，SDIO总线也有两端，其中一端是主机（HOST）端，另一端是设备端（DEVICE），采用HOST- DEVICE这样的设计是为了简化DEVICE的设计，所有的通信都是由HOST端发出命令开始的。在DEVICE端只要能解溪HOST的命令，就可以同HOST进行通信了。

       SDIO的HOST可以连接多个DEVICE，如下图所示:

 

 

       这个是同SD的总线一样的,其中有如下的几种信号

1.       CLK信号:HOST给DEVICE的时钟信号.

2.       CMD信号：双向的信号，用于传送命令和反应。

3.       DAT0-DAT3 信号:四条用于传送的数据线。

4.       VDD信号:电源信号。

5.       VSS1，VSS2:电源地信号。

在SDIO总线定义中,DAT1信号线复用为中断线。在SDIO的1BIT模式下DAT0用来传输数据，DAT1用作中断线。在SDIO的4BIT模式下DAT0-DAT3用来传输数据，其中DAT1复用作中断线。

 

SDIO命令：

       SDIO总线上都是HOST端发起请求，然后DEVICE端回应请求。其中请求和回应中会数据信息。

1.       Command:用于开始传输的命令，是由HOST端发往DEVICE端的。其中命令是通过CMD信号线传送的。

2.       Response:回应是DEVICE返回的HOST的命令，作为Command的回应。也是通过

CMD线传送的。

3.       Data:数据是双向的传送的。可以设置为1线模式，也可以设置为4线模式。数据是通过DAT0-DAT3信号线传输的。

　　SDIO的每次操作都是由HOST在CMD线上发起一个CMD，对于有的CMD，DEVICE需要返回Response，有的则不需要。

       对于读命令，首先HOST会向DEVICE发送命令，紧接着DEVICE会返回一个握手信号，此时，当HOST收到回应的握手信号后，会将数据放在4位的数据线上，在传送数据的同时会跟随着CRC校验码。当整个读传送完毕后，HOST会再次发送一个命令，通知DEVICE操作完毕，DEVICE同时会返回一个响应。

       对于写命令，首先HOST会向DEVICE发送命令，紧接着DEVICE会返回一个握手信号，此时，当HOST收到回应的握手信号后，会将数据放在4位的数据线上，在传送数据的同时会跟随着CRC校验码。当整个写传送完毕后，HOST会再次发送一个命令，通知DEVICE操作完毕，DEVICE同时会返回一个响应。

 

SDIO的寄存器：

      SDIO卡的设备驱动80%的任务就是操作SDIO卡上的有关寄存器。SDIO卡最多允许有7个功能（function）,这个同其功能号是对应的（0～7）,每个功能都对应一个128K字节大小的寄存器，这个见下面的图。功能号之所以取值范围是1~7，而没有包含0，是因为功能0并不代表真正的功能，而代表CIA寄存器，即Common I/O Area，这个纪录着SDIO卡的一些基本信息和特性，并且可以改写这些寄存器。其中地址0x1000~0x17fff是SDIO卡的CIS区域，就是基本信息区域，Common Information Structure。初始化的时候读取并配对SDIO设备。

       这些寄存器的详细分区已经其对应的功能，在开发过程中都是需要仔细研读的，这些都在协议的SPEC中都有详细说明，这里就不在罗索了。 

 

CMD52命令：

SDIO设备为了和SD内存卡兼容，SD卡所有Command和Response完全兼容，同时加入了一些新的Command和Response。例如，初始化SD内存卡使用ACMD41，而SDIO卡设备则用CMD5通知DEVICE进行初始化。

但二者最重要的区别是，SDIO卡比SD内存卡多了CMD52和CMD53命令，这两个命令可以方便的访问某个功能的某个地址寄存器。

CMD52命令是IO_RW_DIRECT命令的简称，其命令格式如下

首先第一位为0,表明是起始位，第二位为传输方向，这里为1，代表方向为HOST向DEVICE设备传送，其后6位为命令号，这里是110100b，用十进制表示为52，CMD52的名字也由此而来。紧接着是读写标志位。

      然后是操作的功能号。也就是function　number。如果为0则指示为CCCR寄存器组。

       紧接着是寄存器地址，用17指示，由于功能寄存器有128K地址，17位正好能寻址。

       再下来8位Write data or Staff Bits的意思是说，如果当前为写操作，则为数据，否则8位为填充位。无意义。

       最后7位为CRC校验码。最后一位为结束位0。

       对于CMD52的Response是48位，命令格式如下：

 

       总结下，CMD52是由HOST发往DEVICE的，它必须有DEVICE返回来的Response。 CMD52不需要占用DAT线，读写的数据是通过CMD52或者Response来传送。每次CMD52只能读或者写一个byte．

 

CMD53命令：

CMD52每次只能读写一个字节，因为有了CMD53对读写进行了扩展，CMD53允许每次读写多个字节或者多个块(BLOCK)。CMD53的命令格式如下：

       第一位是1,为开始位，然后是一位方向位，总是1，代表方向为HOST向DEVICE设备传送，其后6位为命令号，这里是110101b，用十进制表示为53，CMD53的名字也由此而来。

       然后是1位的读写标志。接着是3位功能号，这个同CMD52都是相同的。Block　Mode如果1代表是块传输模式，否则为字节传输模式。

       OP Code为操作位，如果是0，代表数据往固定的位置读写，如果1代表是地质增量读写。例如，对地址0固定读写16个字节，相当于16次读写的地址0，而对地址0增量读写16个字节，相当于读写0~15地址的数据。

       然后是17位的地址寄存器，可以寻址到128K字节的地址，然后是9位的读写的计数，对于字节读取，读写大小就是这个计数，而对于块读写，读写的大小是计数乘以块的大小。

       随后的7位为CRC校验码。最后一位为1。

       当读写操作是块操作的时候，块的大小是可以通过设置FBR中的相关寄存器来设置。

       同CMD52命令不同的是，CMD53没有返回的命令的，这里判断是否DEVICE设备读写完毕是需要驱动里面自己判断的，一般有2个方法，1.设置相应的读写完毕中断。如果DEVICE设备读写完毕，则对HOST设备发送中断。2.HOST设备主动查询DEVICE设备是否读写完毕，可以通过CMD命令是否有返回来判断是否DEVICE是否读写完毕。

驱动：

以SDIO为例其会采用mmc_attach_sdio来实现驱动和设备的匹配，其本质还是根据sdio_bus的匹配规则来实现匹配。在mmc_attach_sdio中首先是mmc匹配一个bus，即采用何种bus来进行mmc bus来处理host。在这里需要理解一点就是在SDIO中，对于SD卡存储器mmc为实体设备，而对于非SD卡存储器，如SDIO接口的设备，则mmc则表征为bus，这个比较重要。除了mmc bus外还存在SDIO_BUS。

int mmc_attach_sdio(struct mmc_host *host,u32 ocr)

{

         interr;

         inti, funcs;

         structmmc_card *card;

         mmc_attach_bus(host,&mmc_sdio_ops); --host匹配一条mmc bus

         card= mmc_alloc_card(host, NULL); --申请一个card实体，类似于总线设备。

         card->type= MMC_TYPE_SDIO;

         card->sdio_funcs= funcs;

         host->card= card;

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

                   sdio_init_func(host->card,i + 1);

         }

         mmc_release_host(host);

         mmc_add_card(host->card);

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

                   sdio_add_func(host->card->sdio_func[i]);      

}

         return0;

}

比较难以理解的是func，这个东东其实是一个实体设备的封装，可以认为其是一个设备。

struct sdio_func *sdio_alloc_func(structmmc_card *card)

{

         structsdio_func *func;

         func= kzalloc(sizeof(struct sdio_func), GFP_KERNEL);

         func->card= card;

         device_initialize(&func->dev);

         func->dev.parent= &card->dev;  --很明显card设备为sdio设备的父设备。

         func->dev.bus= &sdio_bus_type;

         func->dev.release= sdio_release_func;

         returnfunc;

}

上面的code一目了然，其就是具体设备实体的封装，其bus类型为sdio_bus. sdio_init_func仅仅是初始化一个设备，而并没有register。在sdio_add_func实现设备的register，同理就是card实体，在mmc_add_card之前并没有注册，在mmc_add_card函数中才实现设备的注册。

到此设备注册也就完成了，其实sdio总线在形式上类似于usb bus，为什么呢？编写过usb驱动的童鞋们应该知道，编写usb驱动仅仅是编写驱动的加载，并没有具体加载设备实体，导致很多童鞋的困惑，为什么没有设备的加载，其实在usb设备插入时，会动态的创建一个usb设备实体，在usb设备实体创建完成后，根据不同设备id调用相匹配的驱动。而SDIO设备设备也是一样的。上面的code比较混乱，总是让人看不出具体的设备的加载。其实在上面的code中，其中包括了mmc host的驱动。

三.驱动加载

我们还是以SDIO驱动为例，注册一个SDIO驱动会调用下面的函数。

int sdio_register_driver(struct sdio_driver*drv)

{

         drv->drv.name= drv->name;

         drv->drv.bus= &sdio_bus_type;

         returndriver_register(&drv->drv);

}

其实很好理解sdio_driver其实是driver的封装，并且该driver的bus为sdio_bus_type。这个设备的驱动很简单。那来看sdio_driver结构

struct sdio_driver{

         char*name; --驱动名称

         conststruct sdio_device_id *id_table;  --驱动设备ID

         int(*probe)(struct sdio_func *, const struct sdio_device_id *);

         void(*remove)(struct sdio_func *);

         structdevice_driver drv;

};

id_table很熟悉吧，嘿嘿在usb的驱动中如何将设备和驱动匹配就是根据这个东西。在SDIO中也是根据该id_table来进行设备和驱动的匹配。

四.驱动和设备匹配

在介绍了设备注册和驱动注册后，那来看这两个是怎样匹配的。记住SDIO驱动之上有两条总线一个mmc bus 一个是SDIO bus。

先来看mmc bus的match

static int mmc_bus_match(struct device *dev,struct device_driver *drv)

{

         return1;

}

这个很省事，直接就是1.

那在看sdio bus 的match

static int sdio_bus_match(struct device *dev,struct device_driver *drv)

{

         structsdio_func *func = dev_to_sdio_func(dev);

         structsdio_driver *sdrv = to_sdio_driver(drv);

         if(sdio_match_device(func, sdrv))

                   return1;

         return0;

}

通过查看上面的具体code的实现你就会发现就是根据id_table来实现设备和驱动的匹配。

五.probe

不管在设备注册还是驱动注册时，如果发现存在对应的设备和驱动则会调用对应的驱动。不过记住一点是均会先调用mmc bus的probe其次是sdio bus的probe。其实现的过程与platfrom类似，不多加赘述。

六.总结

SDIO说白了还是一种总线，其本质还是离不开驱动和设备这两者，如果有usb驱动的经验则会很好的理解SDIO总线的驱动。在linux内核是可以触类旁通的

- sdio_register_driver()：向系统注册sdio接口驱动，调用以后，系统会触发sdio设备id检测，如果设备id和接口驱动里.id_table里定义的id一致，则系统调用probe函数。
1. 可以在DibBridgeTargetModuleInit()里调用，这样insmod之后，驱动接口即被注册（设备id被注册），有相应设备插入则probe会被调用（此种做法参考LinuxKernelSdioMx28）
2. 也可以在sdio初始化时调用，这样设备插入时，probe不会被调用，只有在sdio初始化，sdio_register_driver()被调用时，系统才会重新检测设备id，并调用probe。（此种做法好处是，模块初始化不涉及何种设备，具有更好的通用性。参考LinuxKernelSdioMx53）