设备树：
- 是描述硬件信息的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属性的节点出现。
- 1.compatible： 其值为字符串，兼容性。是设备树和驱动匹配的标识
中断： 当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 *);
