基于S3C2440的嵌入式Linux驱动——SPI子系统解读（一）

基于S3C2440的嵌入式Linux驱动——SPI子系统解读（一）

本文将介绍SPI子系统。内核版本为2.6.30。如有错误欢迎指正。

预备知识要求：1.SPI总线

2. platfrom平台

3. sysfs子系统

4. 阅读过LDD3第3，5，6，7，9，10，11章的内容。

NOTE：如果没有看过LDD3的相关内容，直接看内核源码将非常吃力！！！

PC主机：Ubuntu 和 RedHat 9.0

目标板：TQ2440开发板 cpu:s3c2440 linux内核:2.6.30

0.引言

本系列文章对Linux设备模型中的SPI子系统进行讲解。SPI子系统的讲解将分为4个部分。

第一部分，即本篇文章，将对SPI子系统整体进行描述，同时给出SPI的相关数据结构，最后描述SPI总线的注册。

第二部分，该文将对SPI的主控制器(master)驱动进行描述。            
基于S3C2440的嵌入式Linux驱动——SPI子系统解读（二）

第三部分，该文将对SPI设备驱动，也称protocol 驱动，进行讲解。
基于S3C2440的嵌入式Linux驱动——SPI子系统解读（三）

第四部分，通过SPI设备驱动留给用户层的API，我们将从上到下描述数据是如何通过SPI的protocol 驱动，由bitbang中转，最后由master驱动将数据传输出去。

基于S3C2440的嵌入式Linux驱动——SPI子系统解读（四）

1.SPI子系统综述

SPI子系统从上到下分为：spi设备驱动层，核心层和master驱动层。其中master驱动抽象出spi控制器的相关操作，而spi设备驱动层抽象出了用户空间API。

platform_device结构中描述了SPI控制器的相关资源，同时在板级信息中将会添加spi设备的相关信息。master驱动将以platform_driver形式体现出来，也就是说

在主控制器(master)和主控制器驱动将挂载到platform总线上。platform_driver的probe函数中将注册spi_master，同时将会获取在板级信息中添加的spi设备，将该

信息转换成spi_device，然后注册spi_device到spi总线上。spi_driver结构用于描述spi设备驱动，也将挂载到spi总线上。连同spi_driver一起注册的是字符设备，该

字符设备将提供5个API给用户空间。通过API，用户空间可以执行半双工读、半双工写和全双工读写。

2. SPI的相关数据结构

这里将介绍内核所用到的关键数据结构，还有些结构将在用到时加以说明。

2.1 spi_master

该结构用于描述SOC的SPI控制器，S3C2440共有两个SPI控制器。

1. /** 
2.  * struct spi_master - interface to SPI master controller 
3.  * @dev: device interface to this driver 
4.  * @bus_num: board-specific (and often SOC-specific) identifier for a 
5.  *  given SPI controller. 
6.  * @num_chipselect: chipselects are used to distinguish individual 
7.  *  SPI slaves, and are numbered from zero to num_chipselects. 
8.  *  each slave has a chipselect signal, but it's common that not 
9.  *  every chipselect is connected to a slave. 
10.  * @dma_alignment: SPI controller constraint on DMA buffers alignment. 
11.  * @setup: updates the device mode and clocking records used by a 
12.  *  device's SPI controller; protocol code may call this.  This 
13.  *  must fail if an unrecognized or unsupported mode is requested. 
14.  *  It's always safe to call this unless transfers are pending on 
15.  *  the device whose settings are being modified. 
16.  * @transfer: adds a message to the controller's transfer queue. 
17.  * @cleanup: frees controller-specific state 
18.  * 
19.  * Each SPI master controller can communicate with one or more @spi_device 
20.  * children.  These make a small bus, sharing MOSI, MISO and SCK signals 
21.  * but not chip select signals.  Each device may be configured to use a 
22.  * different clock rate, since those shared signals are ignored unless 
23.  * the chip is selected. 
24.  * 
25.  * The driver for an SPI controller manages access to those devices through 
26.  * a queue of spi_message transactions, copying data between CPU memory and 
27.  * an SPI slave device.  For each such message it queues, it calls the 
28.  * message's completion function when the transaction completes. 
29.  */  
30. struct spi_master {  
31.     struct device   dev;  
32.   
33.     /* other than negative (== assign one dynamically), bus_num is fully 
34.      * board-specific.  usually that simplifies to being SOC-specific. 
35.      * example:  one SOC has three SPI controllers, numbered 0..2, 
36.      * and one board's schematics might show it using SPI-2.  software 
37.      * would normally use bus_num=2 for that controller. 
38.      */  
39.     s16         bus_num;  
40.   
41.     /* chipselects will be integral to many controllers; some others 
42.      * might use board-specific GPIOs. 
43.      */  
44.     u16         num_chipselect; //该值不能为0，否则会注册失败   
45.   
46.     /* some SPI controllers pose alignment requirements on DMAable 
47.      * buffers; let protocol drivers know about these requirements. 
48.      */  
49.     u16         dma_alignment;  
50.   
51.     /* Setup mode and clock, etc (spi driver may call many times). 
52.      * 
53.      * IMPORTANT:  this may be called when transfers to another 
54.      * device are active.  DO NOT UPDATE SHARED REGISTERS in ways 
55.      * which could break those transfers. 
56.      */  
57.     int         (*setup)(struct spi_device *spi);  
58.   
59.     /* bidirectional bulk transfers 
60.      * 
61.      * + The transfer() method may not sleep; its main role is 
62.      *   just to add the message to the queue. 
63.      * + For now there's no remove-from-queue operation, or 
64.      *   any other request management 
65.      * + To a given spi_device, message queueing is pure fifo 
66.      * 
67.      * + The master's main job is to process its message queue, 
68.      *   selecting a chip then transferring data 
69.      * + If there are multiple spi_device children, the i/o queue 
70.      *   arbitration algorithm is unspecified (round robin, fifo, 
71.      *   priority, reservations, preemption, etc) 
72.      * 
73.      * + Chipselect stays active during the entire message 
74.      *   (unless modified by spi_transfer.cs_change != 0). 
75.      * + The message transfers use clock and SPI mode parameters 
76.      *   previously established by setup() for this device 
77.      */  
78.     int         (*transfer)(struct spi_device *spi,  
79.                         struct spi_message *mesg);  
80.   
81.     /* called on release() to free memory provided by spi_master */  
82.     void            (*cleanup)(struct spi_device *spi);  
83. };