歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
您现在的位置: Linux教程網 >> UnixLinux >  >> Linux編程 >> Linux編程

基於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子系統解讀(二)http://www.linuxidc.com/Linux/2012-08/68404.htm

第三部分,該文將對SPI設備驅動,也稱protocol 驅動,進行講解。
基於S3C2440的嵌入式Linux驅動——SPI子系統解讀(三)http://www.linuxidc.com/Linux/2012-08/68405.htm

第四部分,通過SPI設備驅動留給用戶層的API,我們將從上到下描述數據是如何通過SPI的protocol 驅動,由bitbang中轉,最後由master驅動將數據傳輸出去。

基於S3C2440的嵌入式Linux驅動——SPI子系統解讀(四)http://www.linuxidc.com/Linux/2012-08/68406.htm

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. };  
Copyright © Linux教程網 All Rights Reserved