裝置樹：

• 是描述硬體資訊的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.釋放中斷號