Changes between Version 34 and Version 35 of io_operations

Timestamp:

Nov 22, 2017, 6:10:02 PM (6 years ago)

Author:

alain

Comment:

--

io_operations

@@ -107 +107 @@
 handler, running on the selected core, to select the relevant ISR (Interrupt Service Routine) to be executed.
 
-This PIC device handles the four following types of interrupts:
+This PIC device handles four types of interrupts detailed below :
  1.  '''EXT_IRQ''' (External IRQ) generated by the external (shared) peripherals.
  1. '''INT_IRQ''' (Internal IRQ) generated by the internal (replicated) peripherals.
- 1. '''TIM_IRQ''' (Timer IRQ) generated by the timers (one timer per core).
- 1. '''IPI_IRQ''' (Inter Processor IRQ) generated by software (one IPI per core).
+ 1. '''TIM_IRQ''' (Timer IRQ) used for context switch by the timers (one timer per core).
+ 1. '''IPI_IRQ''' (Inter Processor IRQ) forced remote scheduling (one IPI per core).
 
 This generic PIC device is supposed to be implemented as a ''distributed'' hardware infrastructure containing two types of hardware components:
- * The IOPIC component (one single component in I/O cluster) interfaces the externals IRQs (one IRQ per channel) to the PIC infrastructure
+ * The IOPIC component (one single component in I/O cluster) interfaces the externals IRQs (one IRQ per channel) to the PIC infrastructure.
  * The LAPIC components (one component per cluster) interfaces the PIC infrastructure to the local cores in a given cluster.
 
@@ -121 +121 @@
 Each external IRQ is identified by an '''irq_id''' index, used as an identifier by the kernel. For a given hardware architecture, this index is defined - for each external device channel - by the ''arch_info'' file describing the architecture, and is registered by the kernel in the '''iopic_input''' structure, that is a global variable replicated in all clusters, allocated in the ''kernel_init.c'' file.
 
-The actual interrupt routing is statically defined during the PIC device initialization, by the architecture specific PIC driver,
-using the ''dev_pic_bind_irq()'' function. This function statically links the EXT_IRQ identified by its irq_id to the core running the server thread associated to the external device channel that is the source of the EXT_IRQ. 
+The interrupt routing is statically defined during the PIC device initialization, by the architecture specific PIC driver,
+using the ''dev_pic_bind_irq()'' function. This function statically links the EXT_IRQ identified by its irq_id to the core running the server thread associated to the external device channel that is the source of the EXT_IRQ. As the external devices server threads are distributed on all cores in all clusters, the corresponding IRQs are routed to all relevant clusters. 
 
 === 2) INT_IRQ ===
 
-Each internal IRQ is identified by an '''irq_id''' index, used as an identifier by the kernel. For a given hardware architecture, this  index is defined - for each internal device channel - by the ''arch_info'' file describing the architecture, and is registered by the kernel in the '''lapic_input''' structure, that is a global variable defined in all clusters.
+Each internal IRQ is identified by an '''irq_id''' index, used as an identifier by the kernel. For a given hardware architecture, this  index is defined - for each internal device channel - by the ''arch_info'' file describing the architecture, and is registered by the kernel in the local '''lapic_input''' structure, that is a global variable defined in each cluster.
 
-The actual interrupt routing is local : For an internal peripheral, the server thread is always placed on a local core. The INT_IRQ, identified by its irq_id, is statically linked to the local core running the server thread by the ''dev_pic_bind_irq()'' function.  
+The interrupt routing is local : For an internal peripheral, the server thread is always placed on a local core. The INT_IRQ, identified by its irq_id, is statically linked to the local core running the server thread by the ''dev_pic_bind_irq()'' function.  
 
 === 3) TIM_IRQ ===
@@ -138 +138 @@
 === 4) IPI IRQ ===
 
-To reduce various synchronisation mechanisms, ALMOS-MKH uses IPIs (Inter Processor Interrupt) : Any kernel instance, running on any corein any cluster can send an IPI to any other core in the architecture. An IPI is handled as a special interrupt by the target core, and simply forces a scheduling on the target core. 
+To reduce various synchronisation mechanisms, ALMOS-MKH uses IPIs (Inter Processor Interrupt) : Any kernel instance, running on any corein any cluster can send an IPI to any other core in the architecture, using a remote write access to the relevant register in the PIC infrastructure. An IPI is handled as a special interrupt by the target core, and simply forces a scheduling on the target core. 
 
 == H) Implementations ==
 
-=== - TSAR_MIPS32 architecture ===
+=== 1. TSAR_MIPS32 architecture ===
 
 In the TASR_MIPS32 architecture, the IOPIC external controller provides two services:
- 1. It translate each IRQ identified by its '''irq_id''' to a write transactions to a specific mailbox contained in a local LAPIC controller, for a given core in a given cluster.
+ 1. It translate each EXT_IRQ identified by its '''irq_id''' to a write transactions to a specific mailbox contained in a local LAPIC controller, for a given core in a given cluster.
  1. It allows the kernel to selectively enable/disable any external IRQ identified by its '''irq_id''' index.
 
@@ -155 +155 @@
 The actual numbers of events of each type supported by a given XCU component are defined in the XCU_CONFIG register of the XCU component, and cannot be larger than the SOCLIB_MAX_HWI, SOCLIB_MAX_WTI, SOCLIB_MAX_PTI constants defined in the '' soclib_pic.h'' file.
 
-===  X86_64 architecture === 
+===  2. X86_64 architecture ===