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>[EMAIL PROTECTED]</email> -+ </address> -+ </affiliation> -+ </author> -+ <author> -+ <firstname>Ingo</firstname> -+ <surname>Molnar</surname> -+ <affiliation> -+ <address> -+ <email>[EMAIL PROTECTED]</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>[EMAIL PROTECTED]</email></para></listitem> -+ <listitem><para>Ingo Molnar<email>[EMAIL PROTECTED]</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 _______________________________________________ pld-cvs-commit mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
