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]@<adress>,其中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.释放中断号

---