linux设备树中断绑定cpu,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.释放中断号