--- /dev/null
+There are four different interruptsystems currently supported (well
+only three, really) in the kernel. They are all mutual exclusive:
+
+1 Default
+
+ Requires no kernel compiletime options to be set in the
+ config-file. The default interrupt system is characterized by
+ never fiddling with the interrupt levels during service of
+ interrupts. Drivers that want to can explicitly schedule
+ softint or VBL callbacks, but that is all.
+
+2 LEV6_DEFER
+
+ Requires "options LEV6_DEFER" to be specified in the kernel
+ config-file. This will defer level 6 interrupts to level 4 by
+ temporarily blocking level 6 interrupts via the Amiga custom
+ interrupt controller and set the AUD3 interrupt bit in that
+ same chip. This will imply a level 4 interrupt to be
+ schudled. In that handler after the level 6 interrupt has
+ been serviced, IPL 6 is unblocked again. This will have
+ positive effect on interrupts coming in at IPL 5, specifically
+ the serial recieve interrupt. A potential trouble area is
+ audio when using that fourth channel, that is something to
+ check when someone gets the time. This clever hack was done
+ by Markus Wild.
+
+3 IPL_REMAP_1
+
+ Enabled by "options IPL_REMAP_1" in the config-file. With the
+ arrival of ISA-bus bridges, it became appearant that
+ interrupts at level 6 must be rescheduleable to *any* IPL. In
+ order to not be intrusive on existing ISA code a scheme
+ inspired by Markus Wild's LEV6_DEFER were designed by Niklas
+ Hallqvist <niklas@appli.se>. Every Amiga-native driver for
+ devices at IPL 6 need to register a mapped IPL at which it
+ wants its interrupts to be serviced. At interrupt time the
+ level 6 interrupts get blocked just like in LEV6_DEFER, and
+ then the system will loop through the interrupt levels from
+ high to low IPL servicing the highest interrupt scheduled.
+ There is special care taken to interrupts coming in while
+ already at some IPL above zero.
+
+4 IPL_REMAP_2
+
+ This system isn't yet ready, there are only hooks for it yet.
+ It is an experiment meant to address the performance problems
+ of IPL_REMAP_1 and ISA-drivers needing fast handling, like
+ fast serial devices.
+++ /dev/null
-There are four different interruptsystems currently supported (well
-only three, really) in the kernel. They are all mutual exclusive:
-
-1 Default
-
- Requires no kernel compiletime options to be set in the
- config-file. The default interrupt system is characterized by
- never fiddling with the interrupt levels during service of
- interrupts. Drivers that want to can explicitly schedule
- softint or VBL callbacks, but that is all.
-
-2 LEV6_DEFER
-
- Requires "options LEV6_DEFER" to be specified in the kernel
- config-file. This will defer level 6 interrupts to level 4 by
- temporarily blocking level 6 interrupts via the Amiga custom
- interrupt controller and set the AUD3 interrupt bit in that
- same chip. This will imply a level 4 interrupt to be
- schudled. In that handler after the level 6 interrupt has
- been serviced, IPL 6 is unblocked again. This will have
- positive effect on interrupts coming in at IPL 5, specifically
- the serial recieve interrupt. A potential trouble area is
- audio when using that fourth channel, that is something to
- check when someone gets the time. This clever hack was done
- by Markus Wild.
-
-3 IPL_REMAP_1
-
- Enabled by "options IPL_REMAP_1" in the config-file. With the
- arrival of ISA-bus bridges, it became appearant that
- interrupts at level 6 must be rescheduleable to *any* IPL. In
- order to not be intrusive on existing ISA code a scheme
- inspired by Markus Wild's LEV6_DEFER were designed by Niklas
- Hallqvist <niklas@appli.se>. Every Amiga-native driver for
- devices at IPL 6 need to register a mapped IPL at which it
- wants its interrupts to be serviced. At interrupt time the
- level 6 interrupts get blocked just like in LEV6_DEFER, and
- then the system will loop through the interrupt levels from
- high to low IPL servicing the highest interrupt scheduled.
- There is special care taken to interrupts coming in while
- already at some IPL above zero.
-
-4 IPL_REMAP_2
-
- This system isn't yet ready, there are only hooks for it yet.
- It is an experiment meant to address the performance problems
- of IPL_REMAP_1 and ISA-drivers needing fast handling, like
- fast serial devices.