SOURCES: kernel-desktop-preempt-rt.patch - patch-2.6.17-rc6-rt3
sparky
sparky at pld-linux.org
Sun Jun 11 22:00:39 CEST 2006
Author: sparky Date: Sun Jun 11 20:00:39 2006 GMT
Module: SOURCES Tag: HEAD
---- Log message:
- patch-2.6.17-rc6-rt3
---- Files affected:
SOURCES:
kernel-desktop-preempt-rt.patch (1.5 -> 1.6)
---- Diffs:
================================================================
Index: SOURCES/kernel-desktop-preempt-rt.patch
diff -u SOURCES/kernel-desktop-preempt-rt.patch:1.5 SOURCES/kernel-desktop-preempt-rt.patch:1.6
--- SOURCES/kernel-desktop-preempt-rt.patch:1.5 Sat May 27 15:51:50 2006
+++ SOURCES/kernel-desktop-preempt-rt.patch Sun Jun 11 22:00:33 2006
@@ -5,7 +5,7 @@
@@ -10,7 +10,8 @@ DOCBOOKS := wanbook.xml z8530book.xml mc
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
procfs-guide.xml writing_usb_driver.xml \
- sis900.xml kernel-api.xml journal-api.xml lsm.xml usb.xml \
+ kernel-api.xml journal-api.xml lsm.xml usb.xml \
- gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml
+ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
+ genericirq.xml
@@ -16,7 +16,7 @@
===================================================================
--- /dev/null
+++ linux/Documentation/DocBook/genericirq.tmpl
-@@ -0,0 +1,560 @@
+@@ -0,0 +1,474 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
@@ -47,11 +47,11 @@
+ </authorgroup>
+
+ <copyright>
-+ <year>2005</year>
++ <year>2005-2006</year>
+ <holder>Thomas Gleixner</holder>
+ </copyright>
+ <copyright>
-+ <year>2005</year>
++ <year>2005-2006</year>
+ <holder>Ingo Molnar</holder>
+ </copyright>
+
@@ -89,16 +89,17 @@
+ <title>Introduction</title>
+ <para>
+ The generic interrupt handling layer is designed to provide a
-+ complete abstraction of interrupt handling for device drivers
-+ and is able to handle all different types of interrupt controller
-+ hardware. Device drivers use generic API function to request, enable,
++ complete abstraction of interrupt handling for device drivers.
++ It is able to handle all the different types of interrupt controller
++ hardware. Device drivers use generic API functions to request, enable,
+ disable and free interrupts. The drivers do not have to know anything
-+ about interrupt hardware, so they can be used on different hardware
++ about interrupt hardware details, so they can be used on different
+ platforms without code changes.
+ </para>
+ <para>
-+ This documentation is provided for developers who want to implement
-+ architecture interrupt support based on the Generic IRQ handling layer.
++ This documentation is provided to developers who want to implement
++ an interrupt subsystem based for their architecture, with the help
++ of the generic IRQ handling layer.
+ </para>
+ </chapter>
+
@@ -106,19 +107,13 @@
+ <title>Rationale</title>
+ <para>
+ The original implementation of interrupt handling in Linux is using
-+ the __do_IRQ() super-handler, which must be able to deal with every
-+ type of interrupt logic. This is achieved by an 'interrupt type'
-+ structure and runtime flags to handle special cases.
-+ Furthermore the superhandler assumed a certain type of interrupt
-+ handling hardware and turned out to be not capable of handling all
-+ kind of interrupt controller hardware which can be found through
-+ the architectures. The all in one approach also adds unnecessary
-+ complexity for every user.
++ the __do_IRQ() super-handler, which is able to deal with every
++ type of interrupt logic.
+ </para>
+ <para>
+ Originally, Russell King identified different types of handlers to
+ build a quite universal set for the ARM interrupt handler
-+ implementation in Linux 2.5/2.6. He distiguished between:
++ implementation in Linux 2.5/2.6. He distinguished between:
+ <itemizedlist>
+ <listitem><para>Level type</para></listitem>
+ <listitem><para>Edge type</para></listitem>
@@ -131,53 +126,58 @@
+ </itemizedlist>
+ </para>
+ <para>
-+ This split implementation of handlers allows to optimize the flow
-+ of the interrupt handling for each specific interrupt type.
-+ This reduces complexitiy in that particular code path and allows
-+ the optimized handling of a given type.
++ This split implementation of highlevel IRQ handlers allows us to
++ optimize the flow of the interrupt handling for each specific
++ interrupt type. This reduces complexity in that particular codepath
++ and allows the optimized handling of a given type.
+ </para>
+ <para>
-+ The original general implementation uses interrupt_type structures
-+ to differentiate the flow control in the super-handler. This
-+ leads to a mix of flow logic and code related to hardware details.
-+ Russell Kings ARM implementation which replaced the type by a chip
-+ abstraction did the mix the other way around.
++ The original general IRQ implementation used hw_interrupt_type
++ structures and their ->ack(), ->end() [etc.] callbacks to
++ differentiate the flow control in the super-handler. This leads to
++ a mix of flow logic and lowlevel hardware logic, and it also leads
++ to unnecessary code duplication: for example in i386, there is a
++ ioapic_level_irq and a ioapic_edge_irq irq-type which share many
++ of the lowlevel details but have different flow handling.
+ </para>
+ <para>
-+ The natural conclusion was a clean seperation of the 'type flow'
-+ and the 'chip'. Analysing a couple of architecture implementations
-+ reveals that many of them can use a generic set of 'type flow'
-+ implementations and only need to add the chip level specific code.
-+ The seperation is also valuable for the (sub)architectures,
-+ which need specific quirks in the type flow itself, because it
-+ provides a more transparent design.
++ A more natural abstraction is the clean separation of the
++ 'irq flow' and the 'chip details'.
+ </para>
+ <para>
-+ Each interrupt type implementation has assigned its own flow
-+ handler, which should be normally one of the generic
-+ implementations. The flow handler implementation makes it
-+ simple to provide demultiplexing handlers which can be found in
-+ embedded platforms on various architectures.
++ Analysing a couple of architecture's IRQ subsystem implementations
++ reveals that most of them can use a generic set of 'irq flow'
++ methods and only need to add the chip level specific code.
++ The separation is also valuable for (sub)architectures
++ which need specific quirks in the irq flow itself but not in the
++ chip-details - and thus provides a more transparent IRQ subsystem
++ design.
+ </para>
+ <para>
-+ The seperation makes the generic interrupt handling more flexible
-+ and extensible. An (sub)architecture can use a generic type flow
-+ implementation for e.g. 'level type' interrupts and add a
-+ (sub)architecture specific 'edge type' implementation.
++ Each interrupt descriptor is assigned its own highlevel flow
++ handler, which is normally one of the generic
++ implementations. (This highlevel flow handler implementation also
++ makes it simple to provide demultiplexing handlers which can be
++ found in embedded platforms on various architectures.)
++ </para>
++ <para>
++ The separation makes the generic interrupt handling layer more
++ flexible and extensible. For example, an (sub)architecture can
++ use a generic irq-flow implementation for 'level type' interrupts
++ and add a (sub)architecture specific 'edge type' implementation.
+ </para>
+ <para>
+ To make the transition to the new model easier and prevent the
-+ breakage of existing implementations the __do_IRQ() super-handler
++ breakage of existing implementations, the __do_IRQ() super-handler
+ is still available. This leads to a kind of duality for the time
-+ being. Over time the new model should achieve a homogeneous
-+ implementation scheme over all architectures with enhanced
-+ maintainability and cleanliness.
++ being. Over time the new model should be used in more and more
++ architectures, as it enables smaller and cleaner IRQ subsystems.
+ </para>
+ </chapter>
+ <chapter id="bugs">
+ <title>Known Bugs And Assumptions</title>
+ <para>
-+ None (hopefully).
++ None (knock on wood).
+ </para>
+ </chapter>
+
@@ -187,37 +187,26 @@
+ There are three main levels of abstraction in the interrupt code:
+ <orderedlist>
+ <listitem><para>Highlevel driver API</para></listitem>
-+ <listitem><para>Abstract interrupt type</para></listitem>
++ <listitem><para>Highlevel IRQ flow handlers</para></listitem>
+ <listitem><para>Chiplevel hardware encapsulation</para></listitem>
+ </orderedlist>
+ </para>
-+ <para>
-+ The seperation of interrupt type and chip level functionality
-+ provides the most flexible design. This implementation can handle
-+ all kinds of interrupt hardware and the necessary workarounds for
-+ the interrupt types without the need of redundant implementations.
-+ The seperation handles also edge and level type interrupts
-+ on the same hardware chip.
-+ </para>
+ <sect1>
+ <title>Interrupt control flow</title>
+ <para>
-+ Each interrupt is described by an interrupt description structure
++ Each interrupt is described by an interrupt descriptor structure
+ irq_desc. The interrupt is referenced by an 'unsigned int' numeric
+ value which selects the corresponding interrupt decription structure
-+ in the description structures array.
-+ The description structure contains status information and pointers
-+ to the interrupt type structure and the interrupt chip structure
++ in the descriptor structures array.
++ The descriptor structure contains status information and pointers
++ to the interrupt flow method and the interrupt chip structure
+ which are assigned to this interrupt.
+ </para>
+ <para>
+ Whenever an interrupt triggers, the lowlevel arch code calls into
-+ the generic interrupt code by calling desc->handler->handle_irq().
-+ This highlevel IRQ handling function only uses other
-+ desc->handler primitives which describe the control flow operation
-+ necessary for the interrupt type. These operations are calling
-+ the chip primitives referenced by the assigned chip description
-+ structure.
++ the generic interrupt code by calling desc->handle_irq().
++ This highlevel IRQ handling function only uses desc->chip primitives
++ referenced by the assigned chip descriptor structure.
+ </para>
+ </sect1>
+ <sect1>
@@ -241,36 +230,27 @@
+ </para>
+ </sect1>
+ <sect1>
-+ <title>Abstract interrupt type</title>
++ <title>Highlevel IRQ flow handlers</title>
+ <para>
-+ The 'interrupt type' (struct irq_type) abstraction mainly consists of
-+ methods which implement the 'interrupt handling flow'. The generic
-+ layer provides a set of pre-defined types:
++ The generic layer provides a set of pre-defined irq-flow methods:
+ <itemizedlist>
-+ <listitem><para>default_level_type</para></listitem>
-+ <listitem><para>default_edge_type</para></listitem>
-+ <listitem><para>default_simple_type</para></listitem>
-+ <listitem><para>default_percpu_type</para></listitem>
++ <listitem><para>handle_level_irq</para></listitem>
++ <listitem><para>handle_edge_irq</para></listitem>
++ <listitem><para>handle_simple_irq</para></listitem>
++ <listitem><para>handle_percpu_irq</para></listitem>
+ </itemizedlist>
-+ The default type implementations use the generic type handlers.
-+ <itemizedlist>
-+ <listitem><para>handle_level_type</para></listitem>
-+ <listitem><para>handle_edge_type</para></listitem>
-+ <listitem><para>handle_simple_type</para></listitem>
-+ <listitem><para>handle_percpu_type</para></listitem>
-+ </itemizedlist>
-+ The interrupt types (either predefined or architecture specific) are
-+ assigned to specific interrupts by the architecture either during
-+ bootup or during device initialization.
++ The interrupt flow handlers (either predefined or architecture
++ specific) are assigned to specific interrupts by the architecture
++ either during bootup or during device initialization.
+ </para>
+ <sect2>
-+ <title>Default type implementations</title>
++ <title>Default flow implementations</title>
+ <sect3>
+ <title>Helper functions</title>
+ <para>
+ The helper functions call the chip primitives and
-+ are used by the default type implementations.
-+ Following helper functions are implemented (simplified excerpt):
++ are used by the default flow implementations.
++ The following helper functions are implemented (simplified excerpt):
+ <programlisting>
+default_enable(irq)
+{
@@ -279,7 +259,8 @@
+
+default_disable(irq)
+{
-+ desc->chip->mask(irq);
++ if (!delay_disable(irq))
++ desc->chip->mask(irq);
+}
+
+default_ack(irq)
@@ -301,138 +282,76 @@
+{
+}
+
-+default_set_type(irq, type)
-+{
-+ if (desc->chip->set_type) {
-+ if (desc->chip->set_type(irq, type))
-+ return NULL;
-+ }
-+
-+ return default_handler for type;
-+}
+ </programlisting>
+ </para>
+ </sect3>
-+ <sect3>
-+ <title>Default Level IRQ type</title>
-+ <para>
-+ The default Level IRQ type implements the functions
-+ <simplelist type="horiz" columns="2">
-+ <member>enable</member><member>default_enable</member>
-+ <member>disable</member><member>default_disable</member>
-+ <member>start</member><member>default_mask_ack</member>
-+ <member>end</member><member>default_enable</member>
-+ <member>handle_irq</member><member>handle_level_irq</member>
-+ <member>set_type</member><member>default_set_type</member>
-+ </simplelist>
-+ </para>
-+ </sect3>
-+ <sect3>
-+ <title>Default Edge IRQ type</title>
-+ <para>
-+ The default Edge IRQ type implements the functions
-+ <simplelist type="horiz" columns="2">
-+ <member>enable</member><member>default_enable</member>
-+ <member>disable</member><member>default_disable</member>
-+ <member>start</member><member>default_ack</member>
-+ <member>hold</member><member>default_mask_ack</member>
-+ <member>end</member><member>noop</member>
-+ <member>handle_irq</member><member>handle_edge_irq</member>
-+ <member>set_type</member><member>default_set_type</member>
-+ </simplelist>
-+ </para>
-+ </sect3>
-+ <sect3>
-+ <title>Default simple IRQ type</title>
-+ <para>
-+ The default simple IRQ type implements the functions
-+ <simplelist type="horiz" columns="2">
-+ <member>enable</member><member>noop</member>
-+ <member>disable</member><member>noop</member>
-+ <member>handle_irq</member><member>handle_simple_irq</member>
-+ </simplelist>
-+ </para>
-+ </sect3>
-+ <sect3>
-+ <title>Default per CPU IRQ type</title>
-+ <para>
-+ The default per CPU IRQ type implements the functions
-+ <simplelist type="horiz" columns="2">
-+ <member>enable</member><member>default_enable</member>
-+ <member>disable</member><member>default_disable</member>
-+ <member>start</member><member>default_ack</member>
-+ <member>end</member><member>default_enable</member>
-+ <member>handle_irq</member><member>handle_percpu_irq</member>
-+ </simplelist>
-+ </para>
-+ </sect3>
+ </sect2>
+ <sect2>
-+ <title>Default type handler implementations</title>
++ <title>Default flow handler implementations</title>
+ <sect3>
-+ <title>Default Level IRQ type handler</title>
++ <title>Default Level IRQ flow handler</title>
+ <para>
-+ handle_level_type provides a generic implementation
-+ for level type interrupts.
++ handle_level_irq provides a generic implementation
++ for level-triggered interrupts.
+ </para>
+ <para>
-+ Following control flow is implemented (simplified excerpt):
++ The following control flow is implemented (simplified excerpt):
+ <programlisting>
-+desc->handler->start();
++desc->chip->start();
+handle_IRQ_event(desc->action);
-+desc->handler->end();
++desc->chip->end();
+ </programlisting>
+ </para>
+ </sect3>
+ <sect3>
-+ <title>Default Edge IRQ type handler</title>
++ <title>Default Edge IRQ flow handler</title>
+ <para>
-+ handle_edge_type provides a generic implementation
-+ for edge type interrupts.
++ handle_edge_irq provides a generic implementation
++ for edge-triggered interrupts.
+ </para>
+ <para>
-+ Following control flow is implemented (simplified excerpt):
++ The following control flow is implemented (simplified excerpt):
+ <programlisting>
+if (desc->status & running) {
-+ desc->handler->hold();
++ desc->chip->hold();
+ desc->status |= pending | masked;
+ return;
+}
-+desc->handler->start();
++desc->chip->start();
+desc->status |= running;
+do {
+ if (desc->status & masked)
-+ desc->handler->enable();
++ desc->chip->enable();
+ desc-status &= ~pending;
+ handle_IRQ_event(desc->action);
+} while (status & pending);
+desc-status &= ~running;
-+desc->handler->end();
++desc->chip->end();
+ </programlisting>
+ </para>
+ </sect3>
+ <sect3>
-+ <title>Default simple IRQ type handler</title>
++ <title>Default simple IRQ flow handler</title>
+ <para>
-+ handle_simple_type provides a generic implementation
-+ for simple type interrupts.
++ handle_simple_irq provides a generic implementation
++ for simple interrupts.
+ </para>
+ <para>
-+ Note: The simple type handler does not call any
++ Note: The simple flow handler does not call any
+ handler/chip primitives.
+ </para>
+ <para>
-+ Following control flow is implemented (simplified excerpt):
++ The following control flow is implemented (simplified excerpt):
+ <programlisting>
+handle_IRQ_event(desc->action);
+ </programlisting>
+ </para>
+ </sect3>
+ <sect3>
-+ <title>Default per CPU type handler</title>
++ <title>Default per CPU flow handler</title>
+ <para>
-+ handle_percpu_type provides a generic implementation
-+ for per CPU type interrupts.
++ handle_percpu_irq provides a generic implementation
++ for per CPU interrupts.
+ </para>
+ <para>
+ Per CPU interrupts are only available on SMP and
@@ -440,59 +359,52 @@
+ locking.
+ </para>
+ <para>
-+ Following control flow is implemented (simplified excerpt):
++ The following control flow is implemented (simplified excerpt):
+ <programlisting>
-+desc->handler->start();
++desc->chip->start();
+handle_IRQ_event(desc->action);
-+desc->handler->end();
++desc->chip->end();
+ </programlisting>
+ </para>
+ </sect3>
+ </sect2>
+ <sect2>
-+ <title>Architecture specific type implementation</title>
-+ <para>
-+ If an architecture needs to implement its own type structures, then
-+ the following primitives have to be implemented:
-+ <itemizedlist>
-+ <listitem><para>handle_irq() - The handle_irq function pointer should preferably point to
-+ one of the generic type handler functions</para></listitem>
-+ <listitem><para>startup() - Optional</para></listitem>
-+ <listitem><para>shutdown() - Optional</para></listitem>
-+ <listitem><para>enable()</para></listitem>
-+ <listitem><para>disable()</para></listitem>
-+ <listitem><para>start()</para></listitem>
-+ <listitem><para>hold() - For edge type interupts only</para></listitem>
-+ <listitem><para>end()</para></listitem>
-+ <listitem><para>set_type - Optional</para></listitem>
-+ <listitem><para>set_affinity - SMP only</para></listitem>
-+ </itemizedlist>
-+ </para>
-+ </sect2>
-+ <sect2>
+ <title>Quirks and optimizations</title>
+ <para>
+ The generic functions are intended for 'clean' architectures and chips,
+ which have no platform-specific IRQ handling quirks. If an architecture
+ needs to implement quirks on the 'flow' level then it can do so by
-+ overriding the irqtype. This is also done for compatibility reasons, as
-+ most architectures use irqtypes only at the moment.
++ overriding the highlevel irq-flow handler.
+ </para>
++ </sect2>
++ <sect2>
++ <title>Delayed interrupt disable</title>
+ <para>
-+ An architecture could implement all of its IRQ logic via pushing
-+ chip handling details into the irqtype's ->start()/->end()/->hold()
-+ functions. This is only recommended when the underlying primitives
-+ are pure chip primitives without additional quirks. The direct pointer
-+ to the chip functions reduces the indirection level by one.
++ This per interrupt selectable feature, which was introduced by Russell
++ King in the ARM interrupt implementation, does not mask an interrupt
++ at the hardware level when disable_irq() is called. The interrupt is
++ kept enabled and is masked in the flow handler when an interrupt event
++ happens. This prevents losing edge interrupts on hardware which does
++ not store an edge interrupt event while the interrupt is disabled at
++ the hardware level. When an interrupt arrives while the IRQ_DISABLED
++ flag is set, then the interrupt is masked at the hardware level and
++ the IRQ_PENDING bit is set. When the interrupt is re-enabled by
++ enable_irq() the pending bit is checked and if it is set, the
++ interrupt is resent either via hardware or by a software resend
++ mechanism. (It's necessary to enable CONFIG_HARDIRQS_SW_RESEND when
++ you want to use the delayed interrupt disable feature and your
++ hardware is not capable of retriggering an interrupt.)
++ The delayed interrupt disable can be runtime enabled, per interrupt,
++ by setting the IRQ_DELAYED_DISABLE flag in the irq_desc status field.
+ </para>
+ </sect2>
+ </sect1>
+ <sect1>
+ <title>Chiplevel hardware encapsulation</title>
+ <para>
-+ The chip level hardware description structure irq_chip
++ The chip level hardware descriptor structure irq_chip
+ contains all the direct chip relevant functions, which
-+ can be utilized by the irq_type implementations.
++ can be utilized by the irq flow implementations.
+ <itemizedlist>
+ <listitem><para>ack()</para></listitem>
+ <listitem><para>mask_ack() - Optional, recommended for performance</para></listitem>
@@ -517,16 +429,16 @@
+ </para>
+ <para>
+ This handler turned out to be not suitable for all
-+ interrupt hardware and was therefor reimplemented with split
++ interrupt hardware and was therefore reimplemented with split
+ functionality for egde/level/simple/percpu interrupts. This is not
-+ only a functional optimization. It also shortenes code pathes for
++ only a functional optimization. It also shortens code paths for
+ interrupts.
+ </para>
+ <para>
+ To make use of the split implementation, replace the call to
-+ __do_IRQ by a call to desc->handler->handle_irq() and associate
-+ the appropriate handler function to desc->handler->handle_irq().
-+ In most cases the generic type and handler implementations should
++ __do_IRQ by a call to desc->chip->handle_irq() and associate
++ the appropriate handler function to desc->chip->handle_irq().
++ In most cases the generic handler implementations should
+ be sufficient.
+ </para>
+ </chapter>
@@ -556,6 +468,7 @@
+ which are exported.
+ </para>
+!Ekernel/irq/manage.c
++!Ekernel/irq/chip.c
+ </chapter>
+
+ <chapter id="intfunctions">
@@ -564,6 +477,7 @@
+ This chapter contains the autogenerated documentation of the internal functions.
+ </para>
+!Ikernel/irq/handle.c
++!Ikernel/irq/chip.c
+ </chapter>
+
+ <chapter id="credits">
@@ -801,37 +715,11 @@
synchronize_net
synchronize_sched
synchronize_rcu
-Index: linux/Documentation/feature-removal-schedule.txt
-===================================================================
---- linux.orig/Documentation/feature-removal-schedule.txt
-+++ linux/Documentation/feature-removal-schedule.txt
-@@ -32,21 +32,6 @@ Who: Adrian Bunk <bunk at stusta.de>
-
- ---------------------------
-
--What: RCU API moves to EXPORT_SYMBOL_GPL
--When: April 2006
--Files: include/linux/rcupdate.h, kernel/rcupdate.c
--Why: Outside of Linux, the only implementations of anything even
-- vaguely resembling RCU that I am aware of are in DYNIX/ptx,
-- VM/XA, Tornado, and K42. I do not expect anyone to port binary
-- drivers or kernel modules from any of these, since the first two
-- are owned by IBM and the last two are open-source research OSes.
-- So these will move to GPL after a grace period to allow
-- people, who might be using implementations that I am not aware
-- of, to adjust to this upcoming change.
--Who: Paul E. McKenney <paulmck at us.ibm.com>
--
-----------------------------
--
- What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
- When: November 2005
- Why: Deprecated in favour of the new ioctl-based rawiso interface, which is
Index: linux/Documentation/kernel-parameters.txt
===================================================================
--- linux.orig/Documentation/kernel-parameters.txt
+++ linux/Documentation/kernel-parameters.txt
<<Diff was trimmed, longer than 597 lines>>
---- CVS-web:
http://cvs.pld-linux.org/SOURCES/kernel-desktop-preempt-rt.patch?r1=1.5&r2=1.6&f=u
More information about the pld-cvs-commit
mailing list