SOURCES: kernel-desktop-preempt-rt.patch - up to patch-2.6.18-rt7
sparky
sparky at pld-linux.org
Mon Nov 6 21:03:30 CET 2006
Author: sparky Date: Mon Nov 6 20:03:30 2006 GMT
Module: SOURCES Tag: HEAD
---- Log message:
- up to patch-2.6.18-rt7
---- Files affected:
SOURCES:
kernel-desktop-preempt-rt.patch (1.16 -> 1.17)
---- Diffs:
================================================================
Index: SOURCES/kernel-desktop-preempt-rt.patch
diff -u SOURCES/kernel-desktop-preempt-rt.patch:1.16 SOURCES/kernel-desktop-preempt-rt.patch:1.17
--- SOURCES/kernel-desktop-preempt-rt.patch:1.16 Mon Jul 31 13:37:17 2006
+++ SOURCES/kernel-desktop-preempt-rt.patch Mon Nov 6 21:03:24 2006
@@ -1,996 +1,757 @@
-Index: linux/Documentation/DocBook/Makefile
-===================================================================
---- linux.orig/Documentation/DocBook/Makefile
-+++ linux/Documentation/DocBook/Makefile
-@@ -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 \
- 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
-
- ###
- # The build process is as follows (targets):
-Index: linux/Documentation/DocBook/genericirq.tmpl
-===================================================================
---- /dev/null
-+++ linux/Documentation/DocBook/genericirq.tmpl
-@@ -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" []>
-+
-+<book id="Generic-IRQ-Guide">
-+ <bookinfo>
-+ <title>Linux generic IRQ handling</title>
-+
-+ <authorgroup>
-+ <author>
-+ <firstname>Thomas</firstname>
-+ <surname>Gleixner</surname>
-+ <affiliation>
-+ <address>
-+ <email>tglx at linutronix.de</email>
-+ </address>
-+ </affiliation>
-+ </author>
-+ <author>
-+ <firstname>Ingo</firstname>
-+ <surname>Molnar</surname>
-+ <affiliation>
-+ <address>
-+ <email>mingo at elte.hu</email>
-+ </address>
-+ </affiliation>
-+ </author>
-+ </authorgroup>
-+
-+ <copyright>
-+ <year>2005-2006</year>
-+ <holder>Thomas Gleixner</holder>
-+ </copyright>
-+ <copyright>
-+ <year>2005-2006</year>
-+ <holder>Ingo Molnar</holder>
-+ </copyright>
-+
-+ <legalnotice>
-+ <para>
-+ This documentation is free software; you can redistribute
-+ it and/or modify it under the terms of the GNU General Public
-+ License version 2 as published by the Free Software Foundation.
-+ </para>
-+
-+ <para>
-+ This program is distributed in the hope that it will be
-+ useful, but WITHOUT ANY WARRANTY; without even the implied
-+ warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-+ See the GNU General Public License for more details.
-+ </para>
-+
-+ <para>
-+ You should have received a copy of the GNU General Public
-+ License along with this program; if not, write to the Free
-+ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-+ MA 02111-1307 USA
-+ </para>
-+
-+ <para>
-+ For more details see the file COPYING in the source
-+ distribution of Linux.
-+ </para>
-+ </legalnotice>
-+ </bookinfo>
-+
-+<toc></toc>
-+
-+ <chapter id="intro">
-+ <title>Introduction</title>
-+ <para>
-+ The generic interrupt handling layer is designed to provide a
-+ 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 details, so they can be used on different
-+ platforms without code changes.
-+ </para>
-+ <para>
-+ 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>
-+
-+ <chapter id="rationale">
-+ <title>Rationale</title>
-+ <para>
-+ The original implementation of interrupt handling in Linux is using
-+ 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 distinguished between:
-+ <itemizedlist>
-+ <listitem><para>Level type</para></listitem>
-+ <listitem><para>Edge type</para></listitem>
-+ <listitem><para>Simple type</para></listitem>
-+ </itemizedlist>
-+ In the SMP world of the __do_IRQ() super-handler another type
-+ was identified:
-+ <itemizedlist>
-+ <listitem><para>Per CPU type</para></listitem>
-+ </itemizedlist>
-+ </para>
-+ <para>
-+ 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 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>
-+ A more natural abstraction is the clean separation of the
-+ 'irq flow' and the 'chip details'.
-+ </para>
-+ <para>
-+ 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>
-+ 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
-+ is still available. This leads to a kind of duality for the time
-+ 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 (knock on wood).
-+ </para>
-+ </chapter>
-+
-+ <chapter id="Abstraction">
-+ <title>Abstraction layers</title>
-+ <para>
-+ There are three main levels of abstraction in the interrupt code:
-+ <orderedlist>
-+ <listitem><para>Highlevel driver API</para></listitem>
-+ <listitem><para>Highlevel IRQ flow handlers</para></listitem>
-+ <listitem><para>Chiplevel hardware encapsulation</para></listitem>
-+ </orderedlist>
-+ </para>
-+ <sect1>
-+ <title>Interrupt control flow</title>
-+ <para>
-+ 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 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->handle_irq().
-+ This highlevel IRQ handling function only uses desc->chip primitives
-+ referenced by the assigned chip descriptor structure.
-+ </para>
-+ </sect1>
-+ <sect1>
-+ <title>Highlevel Driver API</title>
-+ <para>
-+ The highlevel Driver API consists of following functions:
-+ <itemizedlist>
-+ <listitem><para>request_irq()</para></listitem>
-+ <listitem><para>free_irq()</para></listitem>
-+ <listitem><para>disable_irq()</para></listitem>
-+ <listitem><para>enable_irq()</para></listitem>
-+ <listitem><para>disable_irq_nosync() (SMP only)</para></listitem>
-+ <listitem><para>synchronize_irq() (SMP only)</para></listitem>
-+ <listitem><para>set_irq_type()</para></listitem>
-+ <listitem><para>set_irq_wake()</para></listitem>
-+ <listitem><para>set_irq_data()</para></listitem>
-+ <listitem><para>set_irq_chip()</para></listitem>
-+ <listitem><para>set_irq_chip_data()</para></listitem>
-+ </itemizedlist>
-+ See the autogenerated function documentation for details.
-+ </para>
-+ </sect1>
-+ <sect1>
-+ <title>Highlevel IRQ flow handlers</title>
-+ <para>
-+ The generic layer provides a set of pre-defined irq-flow methods:
-+ <itemizedlist>
-+ <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 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 flow implementations</title>
-+ <sect3>
-+ <title>Helper functions</title>
-+ <para>
-+ The helper functions call the chip primitives and
-+ are used by the default flow implementations.
-+ The following helper functions are implemented (simplified excerpt):
-+ <programlisting>
-+default_enable(irq)
-+{
-+ desc->chip->unmask(irq);
-+}
-+
-+default_disable(irq)
-+{
-+ if (!delay_disable(irq))
-+ desc->chip->mask(irq);
-+}
-+
-+default_ack(irq)
-+{
-+ chip->ack(irq);
-+}
-+
-+default_mask_ack(irq)
-+{
-+ if (chip->mask_ack) {
-+ chip->mask_ack(irq);
-+ } else {
-+ chip->mask(irq);
-+ chip->ack(irq);
-+ }
-+}
-+
-+noop(irq)
-+{
-+}
-+
-+ </programlisting>
-+ </para>
-+ </sect3>
-+ </sect2>
-+ <sect2>
-+ <title>Default flow handler implementations</title>
-+ <sect3>
-+ <title>Default Level IRQ flow handler</title>
-+ <para>
-+ handle_level_irq provides a generic implementation
-+ for level-triggered interrupts.
-+ </para>
-+ <para>
-+ The following control flow is implemented (simplified excerpt):
-+ <programlisting>
-+desc->chip->start();
-+handle_IRQ_event(desc->action);
-+desc->chip->end();
-+ </programlisting>
-+ </para>
-+ </sect3>
-+ <sect3>
-+ <title>Default Edge IRQ flow handler</title>
-+ <para>
-+ handle_edge_irq provides a generic implementation
-+ for edge-triggered interrupts.
-+ </para>
-+ <para>
-+ The following control flow is implemented (simplified excerpt):
-+ <programlisting>
-+if (desc->status & running) {
-+ desc->chip->hold();
-+ desc->status |= pending | masked;
-+ return;
-+}
-+desc->chip->start();
-+desc->status |= running;
-+do {
-+ if (desc->status & masked)
-+ desc->chip->enable();
-+ desc-status &= ~pending;
-+ handle_IRQ_event(desc->action);
-+} while (status & pending);
-+desc-status &= ~running;
-+desc->chip->end();
-+ </programlisting>
-+ </para>
-+ </sect3>
-+ <sect3>
-+ <title>Default simple IRQ flow handler</title>
-+ <para>
-+ handle_simple_irq provides a generic implementation
-+ for simple interrupts.
-+ </para>
-+ <para>
-+ Note: The simple flow handler does not call any
-+ handler/chip primitives.
-+ </para>
-+ <para>
-+ The following control flow is implemented (simplified excerpt):
-+ <programlisting>
-+handle_IRQ_event(desc->action);
-+ </programlisting>
-+ </para>
-+ </sect3>
-+ <sect3>
-+ <title>Default per CPU flow handler</title>
-+ <para>
-+ handle_percpu_irq provides a generic implementation
-+ for per CPU interrupts.
-+ </para>
-+ <para>
-+ Per CPU interrupts are only available on SMP and
-+ the handler provides a simplified version without
-+ locking.
-+ </para>
-+ <para>
-+ The following control flow is implemented (simplified excerpt):
-+ <programlisting>
-+desc->chip->start();
-+handle_IRQ_event(desc->action);
-+desc->chip->end();
-+ </programlisting>
-+ </para>
-+ </sect3>
-+ </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 highlevel irq-flow handler.
-+ </para>
-+ </sect2>
-+ <sect2>
-+ <title>Delayed interrupt disable</title>
-+ <para>
-+ 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 descriptor structure irq_chip
-+ contains all the direct chip relevant functions, which
-+ can be utilized by the irq flow implementations.
-+ <itemizedlist>
-+ <listitem><para>ack()</para></listitem>
-+ <listitem><para>mask_ack() - Optional, recommended for performance</para></listitem>
-+ <listitem><para>mask()</para></listitem>
-+ <listitem><para>unmask()</para></listitem>
-+ <listitem><para>retrigger() - Optional</para></listitem>
-+ <listitem><para>set_type() - Optional</para></listitem>
-+ <listitem><para>set_wake() - Optional</para></listitem>
-+ </itemizedlist>
-+ These primitives are strictly intended to mean what they say: ack means
-+ ACK, masking means masking of an IRQ line, etc. It is up to the flow
-+ handler(s) to use these basic units of lowlevel functionality.
-+ </para>
-+ </sect1>
-+ </chapter>
-+
-+ <chapter id="doirq">
-+ <title>__do_IRQ entry point</title>
-+ <para>
-+ The original implementation __do_IRQ() is an alternative entry
-+ point for all types of interrupts.
-+ </para>
-+ <para>
-+ This handler turned out to be not suitable for all
-+ interrupt hardware and was therefore reimplemented with split
-+ functionality for egde/level/simple/percpu interrupts. This is not
-+ 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->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>
-+
-+ <chapter id="locking">
-+ <title>Locking on SMP</title>
-+ <para>
-+ The locking of chip registers is up to the architecture that
-+ defines the chip primitives. There is a chip->lock field that can be used
-+ for serialization, but the generic layer does not touch it. The per-irq
-+ structure is protected via desc->lock, by the generic layer.
-+ </para>
-+ </chapter>
-+ <chapter id="structs">
-+ <title>Structures</title>
-+ <para>
-+ This chapter contains the autogenerated documentation of the structures which are
-+ used in the generic IRQ layer.
-+ </para>
-+!Iinclude/linux/irq.h
-+ </chapter>
-+
-+ <chapter id="pubfunctions">
-+ <title>Public Functions Provided</title>
-+ <para>
-+ This chapter contains the autogenerated documentation of the kernel API functions
-+ which are exported.
-+ </para>
-+!Ekernel/irq/manage.c
-+!Ekernel/irq/chip.c
-+ </chapter>
-+
-+ <chapter id="intfunctions">
-+ <title>Internal Functions Provided</title>
-+ <para>
-+ This chapter contains the autogenerated documentation of the internal functions.
-+ </para>
-+!Ikernel/irq/handle.c
-+!Ikernel/irq/chip.c
-+ </chapter>
-+
-+ <chapter id="credits">
-+ <title>Credits</title>
-+ <para>
-+ The following people have contributed to this document:
-+ <orderedlist>
-+ <listitem><para>Thomas Gleixner<email>tglx at linutronix.de</email></para></listitem>
-+ <listitem><para>Ingo Molnar<email>mingo at elte.hu</email></para></listitem>
-+ </orderedlist>
-+ </para>
-+ </chapter>
-+</book>
-Index: linux/Documentation/RCU/proc.txt
+Index: linux/Documentation/hrtimer/highres.txt
===================================================================
--- /dev/null
-+++ linux/Documentation/RCU/proc.txt
-@@ -0,0 +1,207 @@
-+/proc Filesystem Entries for RCU
++++ linux/Documentation/hrtimer/highres.txt
+@@ -0,0 +1,249 @@
++High resolution timers and dynamic ticks design notes
++-----------------------------------------------------
+
++Further information can be found in the paper of the OLS 2006 talk "hrtimers
++and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
++be found on the OLS website:
++http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf
+
-+CONFIG_RCU_STATS
++The slides to this talk are available from:
++http://tglx.de/projects/hrtimers/ols2006-hrtimers.pdf
+
-+The CONFIG_RCU_STATS config option is available only in conjunction with
-+CONFIG_PREEMPT_RCU. It makes four /proc entries available, namely: rcuctrs,
-+rcuptrs, rcugp, and rcustats.
++The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the
++changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the
++design of the Linux time(r) system before hrtimers and other building blocks
++got merged into mainline.
+
-+/proc/rcuctrs
++Note: the paper and the slides are talking about "clock event source", while we
++switched to the name "clock event devices" in meantime.
+
-+ CPU last cur
-+ 0 1 1
-+ 1 1 1
-+ 2 1 1
-+ 3 0 2
-+ ggp = 230725
++The design contains the following basic building blocks:
+
-+This displays the number of processes that started RCU read-side critical
-+sections on each CPU. In absence of preemption, the "last" and "cur"
-+counts for a given CPU will always sum to one. Therefore, in the example
-+output above, each CPU has started one RCU read-side critical section
-+that was later preempted. The "last" column counts RCU read-side critical
-+sections that started prior to the last counter flip, while the "cur"
-+column counts critical sections that started after the last counter flip.
++- hrtimer base infrastructure
++- timeofday and clock source management
++- clock event management
++- high resolution timer functionality
++- dynamic ticks
+
-+The "ggp" count is a count of the number of counter flips since boot.
-+Since this is shown as an odd number, the "cur" counts are stored in
-+the zero-th element of each of the per-CPU arrays, and the "last" counts
-+are stored in the first element of each of the per-CPU arrays.
-+
-+
-+/proc/rcuptrs
-+
-+ nl=c04c7160/c04c7960 nt=c04c72d0
-+ wl=c04c7168/c04c794c wt=c04c72bc dl=c04c7170/00000000 dt=c04c7170
-+
-+This displays the head and tail of each of CONFIG_PREEMPT_RCU's three
-+callback lists. This will soon change to display this on a per-CPU
-+basis, since each CPU will soon have its own set of callback lists.
-+In the example above, the "next" list header is located at hex address
-+0xc04c7160, the first element on the list at hex address 0xc04c7960,
-+and the last element on the list at hex address 0xc04c72d0. The "wl="
-+and "wt=" output is similar for the "wait" list, and the "dl=" and "dt="
-+output for the "done" list. The "done" list is normally emptied very
-+quickly after being filled, so will usually be empty as shown above.
-+Note that the tail pointer points into the list header in this case.
-+
-+Callbacks are placed in the "next" list by call_rcu(), moved to the
-+"wait" list after the next counter flip, and moved to the "done" list
-+on the counter flip after that. Once on the "done" list, the callbacks
-+are invoked.
-+
-+
-+/proc/rcugp
-+
-+ oldggp=241419 newggp=241421
-+
-+This entry invokes synchronize_rcu() and prints out the number of counter
-+flips since boot before and after the synchronize_rcu(). These two
-+numbers will always differ by at least two. Unless RCU is broken. ;-)
+
++hrtimer base infrastructure
++---------------------------
+
-+/proc/rcustats
++The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of
++the base implementation are covered in Documentation/hrtimer/hrtimer.txt. See
++also figure #2 (OLS slides p. 15)
+
<<Diff was trimmed, longer than 597 lines>>
---- CVS-web:
http://cvs.pld-linux.org/SOURCES/kernel-desktop-preempt-rt.patch?r1=1.16&r2=1.17&f=u
More information about the pld-cvs-commit
mailing list