PCI总线使用INTA#、INTB#、INTC#和INTD#信号向处理器发出中断请求。这些中断请求信号为低电平有效,并与处理器的中断控制器连接。在PCI体系结构中,这些中断信号属于边带信号(Sideband Signals),PCI总线规范并没有明确规定在一个处理器系统中如何使用这些信号,因为这些信号对于PCI总线是可选信号。PCI设备还可以使用MSI机制向处理器提交中断请求,而不使用这组中断信号。有关MSI机制的详细说明见第8章。
不同的处理器使用的中断控制器不同,如x86处理器使用APIC(Advanced Programmable Interrupt Controller)中断控制器,而PowerPC处理器使用MPIC(Multiprocessor Interrupt Controller)中断控制器。这些中断控制器都提供了一些外部中断请求引脚IRQ_PINx#。外部设备,包括PCI设备可以使用这些引脚向处理器提交中断请求。
但是PCI总线规范没有规定PCI设备的INTx信号如何与中断控制器的IRQ_PINx#信号相连,这为系统软件的设计带来了一定的困难,为此系统软件使用中断路由表存放PCI设备的INTx信号与中断控制器的连接关系。在x86处理器系统中,BIOS可以提供这个中断路由表,而在PowerPC处理器中Firmware也可以提供这个中断路由表。
在一些简单的嵌入式处理器系统中,Firmware并没有提供中断路由表,此时系统软件开发者需要事先了解PCI设备的INTx信号与中断控制器的连接关系。此时外部设备与中断控制器的连接关系由硬件设计人员指定。
我们假设在一个处理器系统中,共有3个PCI插槽(分别为PCI插槽A、B和C),这些PCI插槽与中断控制器的IRQ_PINx引脚(分别为IRQW#、IRQX#、IRQY#和IRQZ#)可以按照图1‑5所示的拓扑结构进行连接。
在一个处理器系统中,多数PCI设备仅使用INTA#信号,很少使用INTB#和INTC#信号,而INTD#信号更是极少使用。在PCI总线中,PCI设备配置空间的Interrupt Pin寄存器记录该设备究竟使用哪个INTx信号,该寄存器的详细介绍见第2.3.2节。
在PCI总线中,INTx信号属于边带信号。所谓边带信号是指这些信号在PCI总线中是可选信号,而且只能在一个处理器系统的内部使用,并不能离开这个处理器环境。PCI桥也不会处理这些边带信号。这给PCI设备将中断请求发向处理器带来了一些困难,特别是给挂接在PCI桥之下的PCI设备进行中断请求带来了一些麻烦。
在一些嵌入式处理器系统中,这个问题较易解决。因为嵌入式处理器系统很清楚在当前系统中存在多少个PCI设备,这些PCI设备使用了哪些中断资源。在多数嵌入式处理器系统中,PCI设备的数量小于中断控制器提供的外部中断请求引脚数,而且在嵌入式系统中,多数PCI设备仅使用INTA#信号提交中断请求。
在这类处理器系统中,可能并不含有PCI桥,因而PCI设备的中断请求信号与中断控制器的连接关系较易确定。而在这类处理器系统中,即便存在PCI桥,来自PCI桥之下的PCI设备的中断请求也较易处理。
在多数情况下,嵌入式处理器系统使用的PCI设备仅使用INTA#信号进行中断请求,所以只要将这些INTA#信号挂接到中断控制器的独立IRQ_PIN#引脚上即可。这样每一个PCI设备都可以独占一个单独的中断引脚。
而在x86处理器系统中,这个问题需要BIOS参与来解决。在x86处理器系统中,有许多PCI插槽,处理器系统并不知道在这些插槽上将要挂接哪些PCI设备,而且也并不知道这些PCI设备到底需不需要使用所有的INTx#信号线。因此x86处理器系统必须要对各种情况进行处理。
x86处理器系统还经常使用PCI桥进行PCI总线扩展,扩展出来的PCI总线还可能挂接一些PCI插槽,这些插槽上INTx#信号仍然需要处理。PCI桥规范并没有要求桥片传递其下PCI设备的中断请求。事实上多数PCI桥也没有为下游PCI总线提供中断引脚INTx#,管理其下游总线的PCI设备。但是PCI桥规范推荐使用表1‑3建立下游PCI设备的INTx信号与上游PCI总线INTx信号之间的映射关系。
表1‑3 PCI设备INTx#信号与PCI总线INTx#信号的映射关系
设备号 |
PCI设备的INTx#信号 |
PCI总线的INTx#信号 |
0, 4, 8, 12, 16, 20, 24, 28 |
INTA# |
INTA# |
INTB# |
INTB# | |
INTC# |
INTC# | |
INTD# |
INTD# | |
1, 5, 9, 13, 17, 21, 25, 29 |
INTA# |
INTB# |
INTB# |
INTC# | |
INTC# |
INTD# | |
INTD# |
INTA# | |
2, 6, 10, 14, 18, 22, 26, 30 |
INTA# |
INTC# |
INTB# |
INTD# | |
INTC# |
INTA# | |
INTD# |
INTB# | |
3, 7, 11, 15, 19, 23, 27, 31 |
INTA# |
INTD# |
INTB# |
INTA# | |
INTC# |
INTB# | |
INTD# |
INTC# |
我们举例说明该表的含义。在PCI桥下游总线上的PCI设备,如果其设备号为0,那么这个设备的INTA#引脚将和PCI总线的INTA#引脚相连;如果其设备号为1,其INTA#引脚将和PCI总线的INTB#引脚相连;如果其设备号为2,其INTA#引脚将和PCI总线的INTC#引脚相连;如果其设备号为3,其INTA#引脚将和PCI总线的INTD#引脚相连。
在x86处理器系统中,由BIOS或者APCI表记录PCI总线的INTA~D#信号与中断控制器之间的映射关系,保存这个映射关系的数据结构也被称为中断路由表。大多数BIOS使用表1‑3中的映射关系,这也是绝大多数BIOS支持的方式。如果在一个x86处理器系统中,PCI桥下游总线的PCI设备使用的中断映射关系与此不同,那么系统软件程序员需要改动BIOS中的中断路由表。
BIOS初始化代码根据中断路由表中的信息,可以将PCI设备使用的中断向量号写入到该PCI设备配置空间的Interrupt Line register寄存器中,该寄存器将在第2.3.2节中介绍。
在PCI总线中,INTx信号是一个异步信号。所谓异步是指INTx信号的传递并不与PCI总线的数据传送同步,即INTx信号的传递与PCI设备使用的CLK#信号无关。这个“异步”信号给系统软件的设计带来了一定的麻烦。
系统软件程序员需要注意“异步”这种事件,因为几乎所有“异步”事件都会带来系统的“同步”问题。以图1‑1为例,当PCI设备11使用DMA写方式,将一组数据写入存储器时,该设备在最后一个数据离开PCI设备11的发送FIFO时,会认为DMA写操作已经完成。此时这个设备将通过INTx信号,通知处理器DMA写操作完成。
此时处理器(驱动程序的中断服务例程)需要注意,因为INTx信号是一个异步信号,当处理器收到INTx信号时,并不意味着PCI设备11已经将数据写入存储器中,因为PCI设备11的数据传递需要通过PCI桥1和HOST主桥,最终才能到达存储器控制器。
而INTx信号是“异步”发送给处理器的,PCI总线并不知道这个“异步”事件何时被处理。很有可能处理器已经接收到INTx信号,开始执行中断处理程序时,该PCI设备还没有完全将数据写入存储器。
因为“PCI设备向处理器提交中断请求”与“将数据写入存储器”分别使用了两个不同的路径,处理器系统无法保证哪个信息率先到达。从而在处理器系统中存在“中断同步”的问题,PCI总线提供了以下两种方法解决这个同步问题。
(1) PCI设备保证在数据到达目的地之后,再提交中断请求。
显然这种方法不仅加大了硬件的开销,而且也不容易实现。如果PCI设备采用Posted写总线事务,PCI设备无法单纯通过硬件逻辑判断数据什么时候写入到存储器。此时为了保证数据到达目的地后,PCI设备才能提交中断请求,PCI设备需要使用“读刷新”的方法保证数据可以到达目的地,其方法如下。
PCI设备在提交中断请求之前,向DMA写的数据区域发出一个读请求,这个读请求总线事务将被PCI设备转换为读完成总线事务,当PCI设备收到这个读完成总线事务后,再向处理器提交中断请求。PCI总线的“序”机制保证这个存储器读请求,会将DMA数据最终写入存储器,有关PCI序的详细说明见第9.3节。
PCI总线规范要求HOST主桥和PCI桥必须保证这种读操作可以刷新写操作。但问题是,没有多少芯片设计者愿意提供这种机制,因为这将极大地增加他们的设计难度。除此之外,使用这种方法也将增加中断请求的延时。
(2) 中断服务例程使用“读刷新”方法。
中断服务例程在使用“PCI设备写入存储器”的这些数据之前,需要对这个PCI设备进行读操作。这个读操作也可以强制将数据最终写入存储器,实际上是将数据写到存储器控制器中。这种方法利用了PCI总线的传送序规则,这种方法与第1种方法基本相同,只是使用这种方法使用软件方式,而第1种方式使用硬件方式。第9.3节将详细介绍这个读操作如何将数据刷新到存储器中。
第2种方法也是绝大多数处理器系统采用的方法。程序员在书写中断服务例程时,往往都是先读取PCI设备的中断状态寄存器,判断中断产生原因之后,才对PCI设备写入的数据进行操作。这个读取中断状态寄存器的过程,一方面可以获得设备的中断状态,另一方面是保证DMA写的数据最终到达存储器。如果驱动程序不这样做,就可能产生数据完整性问题。产生这种数据完整性问题的原因是INTx这个异步信号。
这里也再次提醒系统程序员注意PCI总线的“异步”中断所带来的数据完整性问题。在一个操作系统中,即便中断处理程序没有首先读取PCI设备的寄存器,也多半不会出现问题,因为在操作系统中,一个PCI设备从提交中断到处理器开始执行设备的中断服务例程,所需要的时间较长,处理器系统基本上可以保证此时数据已经写入存储器。
但是如果系统程序员不这样做,这个驱动程序依然有Bug存在,尽管这个Bug因为各种机缘巧合,始终不能够暴露出来,而一旦这些Bug被暴露出来将难以定位。为此系统程序员务必要重视设计中出现的每一个实现细节,当然仅凭谨慎小心是远远不够的,因为重视细节的前提是充分理解这些细节。
PCI总线V2.2规范还定义了一种新的中断机制,即MSI中断机制。MSI中断机制采用存储器写总线事务向处理器系统提交中断请求,其实现机制是向HOST处理器指定的一个存储器地址写指定的数据。这个存储器地址一般是中断控制器规定的某段存储器地址范围,而且数据也是事先安排好的数据,通常含有中断向量号。
HOST主桥会将MSI这个特殊的存储器写总线事务进一步翻译为中断请求,提交给处理器。目前PCIe和PCI-X设备必须支持MSI中断机制,但是PCI设备并不一定都支持MSI中断机制。
目前MSI中断机制虽然在PCIe总线上已经成为主流,但是在PCI设备中并不常用。即便是支持MSI中断机制的PCI设备,在设备驱动程序的实现中也很少使用这种机制。首先PCI设备具有INTx#信号可以传递中断,而且这种中断传送方式在PCI总线中根深蒂固。其次PCI总线是一个共享总线,传递MSI中断需要占用PCI总线的带宽,需要进行总线仲裁等一系列过程,远没有使用INTx#信号线直接。
但是使用MSI中断机制可以取消PCI总线这个INTx#边带信号,可以解决使用INTx中断机制所带来的数据完整性问题。而更为重要的是,PCI设备使用MSI中断机制,向处理器系统提交中断请求的同时,还可以通知处理器系统产生该中断的原因,即通过不同中断向量号表示中断请求的来源。当处理器系统执行中断服务例程时,不需要读取PCI设备的中断状态寄存器,获得中断请求的来源,从而在一定程度上提高了中断处理的效率。本书将在第8章详细介绍MSI中断机制。
文章评论(0条评论)
登录后参与讨论