花了一天，边玩边看，把这个系列看完了。感叹确实卢俊前辈对于gic的掌握程度。
肯定很多的东西看了就忘了，这是正常的，在以后如果有用到的话，再回过头来，结合实践应该会映像深刻。
1、波形
以下以gic600与cpu interface之间传递的包，来说明，他们之间是如何通信的。这里以波形进行介绍。这样比较直观。
一、downstream control命令包
gic600发送downstream control命令包给cpu interface。命令包的数据为0。
downstream control包格式如下：
解释如下：
从表中可以解析，gic600告诉cpu interface做如下配置：
- VL设置为0，表示vINTID位宽是16bit
- PL设置为0，表示pINTID位宽是16bit
- RSS设置为1，表示SGI的aff0，支持0-15
- DS设置为0，表示支持两种secure模式
cpu interface接收到该命令包后，回一个downstream control acknowledge响应包。包格式如下：
upstream control命令包，设置PMR
cpu interface给gic600发送upstream control命令包，数据为f8。设置PMR。
该包的格式如下：
对于f8，解析如下：
cpu interface告诉gic600，当前的ICC_PMR_EL1值设置为f8，也就是将来优先级比这个低的，gic600就不要发送中断给cpu interface。
gic600收到upstream control命令包后，回upstream control acknowledge包，格式如下：
二、upstream control命令包，设置group enable
cpu interface给gic600发送upstream control命令包，数据为1。设置group enable。
对于数据1，解析如下：
cpu interface告诉gic600，将grou0的中断使能，group1的secure和non-secure中断不使能。
gic600收到upstream control命令包后，回upstream control acknowledge包，格式如下：
三、set命令包，发送中断
gic600发送set命令包给cpu interface。数据为20。
set命令包格式如下：
gic600向cpu interface发送了一个中断：
- Grp为0，Mod为0，表示中断属于group0中断组
- ID length为0，表示INTID位宽为16bit
- Priority为0x48，表示中断优先级
- INTID为0x20，表示中断号为32（SPI中断从32开始）
cpu interface收到该set命令后，发现不能处理该中断，因此发送release响应包，并且INTID指定刚刚gic600发送的中断号。
该release响应包的各个参数解释如下：
gic600收到cpu interface的release响应包后，知道之前发送的中断，不能得到cpu interface的响应，在之后，会重新发送该中断。
这里为什么cpu interface不能处理该中断，而是要回release响应包。原因在于中断优先级不符合要求。
对于ICC_PMR_EL1寄存器，gicv3 spec描述如下：
对于中断，gic架构，最多使用8个bit，来表示中断优先级。当然8个bit可以全用，也可以只用一部分，所以架构提供了5种配置方式。设计可以根据自己的需要，选择一种配置即可。
对于使用的bit不一样，对应的中断优先级值不一样。比如对于使用5个bit，那么就是[7:3]，共32种中断优先级。这个选择多少个bit，是硬件决定好了，软件是不能更改的。
软件可以设置这个寄存器，来表示，符合要求的优先级，可以被cpu响应。优先级值越小，表示优先级越高。
假设这个时候，软件往这个寄存器写了8，表示优先级高于8的，都不能被core响应。
假设设计，使用[7:3]，表示中断优先级。
此时，发送了优先级为0x48的中断，按照[7:3]bit，进行选择，得到中断优先级为9，高于设置的8，因此这个中断不能被core响应，所以cpu interface直接给gic600回release响应。
四、set命令包，发送中断
gic600发送set命令包给cpu interface。数据为21。
gic600向cpu interface发送了一个中断：
- Grp为0，Mod为0，表示中断属于group0中断组
- ID length为0，表示INTID位宽为16bit
- Priority为0x38，表示中断优先级
- INTID为0x21，表示中断号为33
cpu interface接收到set命令包，将中断发送给core，core响应中断，读取icc_iar寄存器，表示对该中断认可。中断被core认可后，cpu interface就会给gic600回activate命令包，表示core认可了该中断。gic600就可以把该中断状态，更新为active或者active and pending状态。
activate就命令包格式如下：
各个域解析如下：
五、deactivate命令包，无效中断
core在处理完中断后，会写ICC_EOIR0_EL1或者ICC_EOIR1_EL1寄存器，来无效中断，cpu interface接受core的这个写操作，会向gic600发送deactivate命令包，表示core对中断处理完毕。
deactivate命令包，格式如下；
各个域解析如下:
gic600收到cpu interfae发送的deactivate命令后，将自己内部对该中断维护的状态，修改为pending 或者 inactive。
（作者不愧是搞芯片验证的，这也太硬件了，这里直接为了整个系列的完整性，所以就把这个部分也看了一下，虽然没有什么映像，但是还是感觉这个玩意很神奇。）
2、总结
GIC，是arm为了实现复杂的中断控制，而定义的一套架构。版本也历经了多个变化，从最初的GICv1到现在最新的GICv4。每一个新的版本，都增加了一些新的功能。
目前最新的GIC-600 IP，支持GICv4。
不过从GICv3开始，架构就和之前的架构，变化就比较大了。
一、变化一：cpu interface
下图是GICv2架构，cpu interface是实现在gic内部，而且gic的寄存器，都是memory-mapped方式访问。
下图是GICv3架构，cpu interface从gic内部剥离，实现在PE的内部。并且将cpu interface的寄存器，提供了系统寄存器访问方式，从而实现中断的快速响应。
二、变化二：core的标识
GICv3中，对于core的标识，使用了属性层次的方式，来进行标识，从而可以支持更多的core。
而GICv2中，支持最大8个core。（这对服务器是不够的）
三、变化三：消息中断
GICv3中，加入了LPI中断类型，来实现消息中断。并且提供了ITS，来实现中断的转换。
（这种手段可以当外设想增加中断时，不需要增加物理的中断连线）
四、变化四：SGI处理
对于SGI的处理，有如下的变化。
（这个部分需要好好了解一下GICv2的中断完成和Gicv3d的区别！！！）
五、总结
gicv3/v4，架构，比gicv2架构，增加了很多的特性，从而支持更复杂的中断管理，支持更多的cpu。
自此，本系列博文到此就要结束了，基本上，除了虚拟中断的相关内容，我将GIC的内容都进行了介绍。希望大家看完这系列博文，能够对GIC有所认识。当初，自己也是看了很多的文档，外加上代码，才对这个理解的。
后面，如果我有去了解过虚拟中断，会在写一系列博文，来介绍虚拟中断。
参考链接：
https://zhuanlan.zhihu.com/p/198962986（牛牛牛！！！）
