Changes between Version 26 and Version 27 of io_operations

Timestamp:

Nov 7, 2016, 1:08:21 PM (8 years ago)

Author:

alain

Comment:

--

io_operations

@@ -35 +35 @@
 || PIC     || ext   || External Interrupt controller || [wiki:pic_device_api pic_api] ||
 || ICU     || int    || Internal Interrupt Controller  || [wiki:icu_device_api icu_api] ||
+
+To signal the completion of an I/O operation, ALMOS-MK defines three types of interrupts :
+ * '''HWI''' : The HardWare Interrupt are physical signals connection one peripheral IRQ to an internal (ICU) or external (PIC) interrupt controller.
+ * '''WTI''' : The Write Triggered Interrupt are mailboxes implemented in the distributed ICU component to support software IPI (Inter Processor Interrupt), or to route external peripheral IRQ from the PIC component to the client core through a specific ICU.
+ * '''PTI''' : The Programmable Timer Interrupt are implemented in the distributed ICU to support periodical interrupts used by the preemptive context swich mechanism. 
+
+WARNING: The two PIC (external) and ICU (internal) devices in the list defined above have a special role: they do NOT perform I/O operations, but are used as configurable interrupt routers to dynamically link a peripheral channel interrupt to a given core. Therefore, the functions defined by the ICU and PIC APIs are service functions, called by the other devices functions. These ICU and PIC functions don't use the waiting queue implemented in the generic device descriptor, but call directly the ICU or PIC drivers. 
 
 == C) Devices Descriptors Placement ==
@@ -88 +95 @@
 == F) Implementation ==
 
-It is worth noting that this general I/O operation mechanism involves generally three clusters (client cluster / server cluster / IO cluster), but does not use any RPC: 
+This general I/O operation mechanism involves generally three clusters (client cluster / server cluster / IO cluster), but does not use any RPC: 
  * To post a new command in the waiting queue of a given (remote) device descriptor, the client thread uses only few remote accesses to be registered in the distributed XLIST rooted in the server cluster.
  * To launch the I/O operation on the (remote) peripheral, the server thread uses only remote accesses to the physical registers located in the I/O cluster.