5-設備樹_中斷

設備樹：

• 是描述硬件信息的asiII文本文件，其書寫符合人類思維習慣。

歷史：

• 在linux更新維護過程中，linux創始人linus發現在收到arm平臺負責人的維護郵件後，提出了linux內核中由來已久存在的問題。
  即硬件代碼在linux內核中，管理無序混亂，冗餘，效率低。提出借鑑powerPC架構的FDT機制，來描述硬件。由此在linux3.0以後的版本
  引入了設備樹的概念。其中比較顯著的特點，設備樹是以外部參數的形式將硬件信息導入內核。

關鍵詞：

• 1.DTC 是編譯設備樹的小工具
• 2.DTS 是描述硬件信息的asiII文本文件
• 3.DTB 是編譯後的二進制文件，可被bootloader識別並解析
• 4.DTSI 類似頭文件，描述平臺共性

設備樹的內容：

• 1.節點：是描述某個具體設備或參數

  • 1.1根節點 每個平臺設備樹，有且只有一個根節點，根節點包含所有子節點，根節點以“/”命名
  • 1.2子節點：子節點可互相包含，命名方式是[name]@,其中name爲必寫項，adress爲可寫項，一般adress
    寫的話，如果該設備有地址，就寫該設備地址，沒有寫序號。
  • 1.3子節點描述的設備類型：
    
    • 1.3.1 CPU
    • 1.3.2 內存
    • 1.3.3 總線和橋
    • 1.3.4 gpio控制器
    • 1.3.5 中斷控制器
    • 1.3.6 clk時鐘
    • 1.3.7 外設

• 2.屬性 是描述節點的特性。屬性的表現形式爲name=value，其中name的含義和value的含義由具體相關平臺給出。

• 2.1屬性的值的類型：
  
  • 1.u32
  • 2.u64
  • 3.字符串
  • 4.字符串數組
  • 5.結構體
  • 6.結構體數組
  • 7.phandle值
• 2.1重要屬性：
  
  • 1.compatible： 其值爲字符串，兼容性。是設備樹和驅動匹配的標識
  • 2.reg： 描述節點的地址資源屬性。其值爲結構體數組，一般以adress size成組出現。
  • 3.#adress-cells： 規定子節點的reg的value值的adress的個數，其值爲u32
  • 4.#size-cells：規定子節點的reg的value值的size的個數，其值爲u32
  • 5.interrupts： 描述節點的中斷源，其值的含義需查看相關文檔，其值爲結構體數組，
  • 6.intrerupt-parent: 描述節點的父中斷節點。其爲phandle值，表現<&標號>，實際是一個u32
  • 7.interrupt-controller： 描述節點爲中斷控制器，其值爲空值。
  • 8.interrupt-cells:描述子中斷節點的interrupts屬性的value的cell個數。其值爲u32，它只能在擁有interrupt-controller屬性的節點出現。

中斷： 當cpu遇到突發事件，轉而去處理突發事件，處理完成後，返回到正常狀態

中斷按來源分類：

• 外部中斷
• 內部中斷

按可屏蔽：

• 可屏蔽中斷
• 不可屏蔽中斷

按入口地址：

• 向量中斷（硬件提供入口地址）和非向量中斷（軟件提供入口地址）

---

ARM平臺支持GIC中斷控制器：

• GIC所支持的中斷類型：
  
  • 1.PPI：私有中斷，中斷必須綁定一個固定CPU核，當處理該中斷時，必須由綁定的CPU核處理
  • 2.SPI：共享中斷，中斷的處理可被任意的CPU核處理
  • 3.SWI：軟中斷，用於處理核間通信和調度。

             ------------------------------------------------
     內核  --|-  cpu -----  GIC---------中斷控制器 ........---|---外設
             -------------------------------------------------
          soc內部

---

中斷編程：

• 1.申請中斷號

**
 *  request_threaded_irq - allocate an interrupt line
 *  @irq: Interrupt line to allocate
 *  @handler: Function to be called when the IRQ occurs.
 *  @irqflags: Interrupt type flags
 *  @devname: An ascii name for the claiming device
 *  @dev_id: A cookie passed back to the handler function
 *
 *  This call allocates interrupt resources and enables the
 *  interrupt line and IRQ handling. From the point this
 *  call is made your handler function may be invoked. Since
 *  your handler function must clear any interrupt the board
 *  raises, you must take care both to initialise your hardware
 *  and to set up the interrupt handler in the right order.
 *
 *  If you want to set up a threaded irq handler for your device
 *  then you need to supply @handler and @thread_fn. @handler is
 *  still called in hard interrupt context and has to check
 *  whether the interrupt originates from the device. If yes it
 *  needs to disable the interrupt on the device and return
 *  IRQ_WAKE_THREAD which will wake up the handler thread and run
 *  @thread_fn. This split handler design is necessary to support
 *  shared interrupts.
 *
 *  Dev_id must be globally unique. Normally the address of the
 *  device data structure is used as the cookie. Since the handler
 *  receives this value it makes sense to use it.
 *
 *  If your interrupt is shared you must pass a non NULL dev_id
 *  as this is required when freeing the interrupt.
 *
 *  Flags:
 *
 *  IRQF_SHARED     Interrupt is shared
 *  IRQF_TRIGGER_*      Specify active edge(s) or level
 *
 */
static inline int __must_check
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags, const char *name, void *dev)

---

extern void free_irq(unsigned int, void *);

2.釋放中斷號

---