6 files changed, 827 insertions, 23 deletions

diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX
index 461481dfb7c3..7dc0695a8f90 100644
--- a/Documentation/RCU/00-INDEX
+++ b/Documentation/RCU/00-INDEX
@@ -16,6 +16,8 @@ RTFP.txt
         - List of RCU papers (bibliography) going back to 1980.
 torture.txt
         - RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
+trace.txt
+        - CONFIG_RCU_TRACE debugfs files and formats
 UP.txt
         - RCU on Uniprocessor Systems
 whatisRCU.txt
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt
new file mode 100644
index 000000000000..068848240a8b
--- /dev/null
+++ b/Documentation/RCU/trace.txt
@@ -0,0 +1,413 @@
+CONFIG_RCU_TRACE debugfs Files and Formats
+
+
+The rcupreempt and rcutree implementations of RCU provide debugfs trace
+output that summarizes counters and state.  This information is useful for
+debugging RCU itself, and can sometimes also help to debug abuses of RCU.
+Note that the rcuclassic implementation of RCU does not provide debugfs
+trace output.
+
+The following sections describe the debugfs files and formats for
+preemptable RCU (rcupreempt) and hierarchical RCU (rcutree).
+
+
+Preemptable RCU debugfs Files and Formats
+
+This implementation of RCU provides three debugfs files under the
+top-level directory RCU: rcu/rcuctrs (which displays the per-CPU
+counters used by preemptable RCU) rcu/rcugp (which displays grace-period
+counters), and rcu/rcustats (which internal counters for debugging RCU).
+
+The output of "cat rcu/rcuctrs" looks as follows:
+
+CPU last cur F M
+  0    5  -5 0 0
+  1   -1   0 0 0
+  2    0   1 0 0
+  3    0   1 0 0
+  4    0   1 0 0
+  5    0   1 0 0
+  6    0   2 0 0
+  7    0  -1 0 0
+  8    0   1 0 0
+ggp = 26226, state = waitzero
+
+The per-CPU fields are as follows:
+
+o       "CPU" gives the CPU number.  Offline CPUs are not displayed.
+
+o       "last" gives the value of the counter that is being decremented
+        for the current grace period phase.  In the example above,
+        the counters sum to 4, indicating that there are still four
+        RCU read-side critical sections still running that started
+        before the last counter flip.
+
+o       "cur" gives the value of the counter that is currently being
+        both incremented (by rcu_read_lock()) and decremented (by
+        rcu_read_unlock()).  In the example above, the counters sum to
+        1, indicating that there is only one RCU read-side critical section
+        still running that started after the last counter flip.
+
+o       "F" indicates whether RCU is waiting for this CPU to acknowledge
+        a counter flip.  In the above example, RCU is not waiting on any,
+        which is consistent with the state being "waitzero" rather than
+        "waitack".
+
+o       "M" indicates whether RCU is waiting for this CPU to execute a
+        memory barrier.  In the above example, RCU is not waiting on any,
+        which is consistent with the state being "waitzero" rather than
+        "waitmb".
+
+o       "ggp" is the global grace-period counter.
+
+o       "state" is the RCU state, which can be one of the following:
+
+        o       "idle": there is no grace period in progress.
+
+        o       "waitack": RCU just incremented the global grace-period
+                counter, which has the effect of reversing the roles of
+                the "last" and "cur" counters above, and is waiting for
+                all the CPUs to acknowledge the flip.  Once the flip has
+                been acknowledged, CPUs will no longer be incrementing
+                what are now the "last" counters, so that their sum will
+                decrease monotonically down to zero.
+
+        o       "waitzero": RCU is waiting for the sum of the "last" counters
+                to decrease to zero.
+
+        o       "waitmb": RCU is waiting for each CPU to execute a memory
+                barrier, which ensures that instructions from a given CPU's
+                last RCU read-side critical section cannot be reordered
+                with instructions following the memory-barrier instruction.
+
+The output of "cat rcu/rcugp" looks as follows:
+
+oldggp=48870  newggp=48873
+
+Note that reading from this file provokes a synchronize_rcu().  The
+"oldggp" value is that of "ggp" from rcu/rcuctrs above, taken before
+executing the synchronize_rcu(), and the "newggp" value is also the
+"ggp" value, but taken after the synchronize_rcu() command returns.
+
+
+The output of "cat rcu/rcugp" looks as follows:
+
+na=1337955 nl=40 wa=1337915 wl=44 da=1337871 dl=0 dr=1337871 di=1337871
+1=50989 e1=6138 i1=49722 ie1=82 g1=49640 a1=315203 ae1=265563 a2=49640
+z1=1401244 ze1=1351605 z2=49639 m1=5661253 me1=5611614 m2=49639
+
+These are counters tracking internal preemptable-RCU events, however,
+some of them may be useful for debugging algorithms using RCU.  In
+particular, the "nl", "wl", and "dl" values track the number of RCU
+callbacks in various states.  The fields are as follows:
+
+o       "na" is the total number of RCU callbacks that have been enqueued
+        since boot.
+
+o       "nl" is the number of RCU callbacks waiting for the previous
+        grace period to end so that they can start waiting on the next
+        grace period.
+
+o       "wa" is the total number of RCU callbacks that have started waiting
+        for a grace period since boot.  "na" should be roughly equal to
+        "nl" plus "wa".
+
+o       "wl" is the number of RCU callbacks currently waiting for their
+        grace period to end.
+
+o       "da" is the total number of RCU callbacks whose grace periods
+        have completed since boot.  "wa" should be roughly equal to
+        "wl" plus "da".
+
+o       "dr" is the total number of RCU callbacks that have been removed
+        from the list of callbacks ready to invoke.  "dr" should be roughly
+        equal to "da".
+
+o       "di" is the total number of RCU callbacks that have been invoked
+        since boot.  "di" should be roughly equal to "da", though some
+        early versions of preemptable RCU had a bug so that only the
+        last CPU's count of invocations was displayed, rather than the
+        sum of all CPU's counts.
+
+o       "1" is the number of calls to rcu_try_flip().  This should be
+        roughly equal to the sum of "e1", "i1", "a1", "z1", and "m1"
+        described below.  In other words, the number of times that
+        the state machine is visited should be equal to the sum of the
+        number of times that each state is visited plus the number of
+        times that the state-machine lock acquisition failed.
+
+o       "e1" is the number of times that rcu_try_flip() was unable to
+        acquire the fliplock.
+
+o       "i1" is the number of calls to rcu_try_flip_idle().
+
+o       "ie1" is the number of times rcu_try_flip_idle() exited early
+        due to the calling CPU having no work for RCU.
+
+o       "g1" is the number of times that rcu_try_flip_idle() decided
+        to start a new grace period.  "i1" should be roughly equal to
+        "ie1" plus "g1".
+
+o       "a1" is the number of calls to rcu_try_flip_waitack().
+
+o       "ae1" is the number of times that rcu_try_flip_waitack() found
+        that at least one CPU had not yet acknowledge the new grace period
+        (AKA "counter flip").
+
+o       "a2" is the number of time rcu_try_flip_waitack() found that
+        all CPUs had acknowledged.  "a1" should be roughly equal to
+        "ae1" plus "a2".  (This particular output was collected on
+        a 128-CPU machine, hence the smaller-than-usual fraction of
+        calls to rcu_try_flip_waitack() finding all CPUs having already
+        acknowledged.)
+
+o       "z1" is the number of calls to rcu_try_flip_waitzero().
+
+o       "ze1" is the number of times that rcu_try_flip_waitzero() found
+        that not all of the old RCU read-side critical sections had
+        completed.
+
+o       "z2" is the number of times that rcu_try_flip_waitzero() finds
+        the sum of the counters equal to zero, in other words, that
+        all of the old RCU read-side critical sections had completed.
+        The value of "z1" should be roughly equal to "ze1" plus
+        "z2".
+
+o       "m1" is the number of calls to rcu_try_flip_waitmb().
+
+o       "me1" is the number of times that rcu_try_flip_waitmb() finds
+        that at least one CPU has not yet executed a memory barrier.
+
+o       "m2" is the number of times that rcu_try_flip_waitmb() finds that
+        all CPUs have executed a memory barrier.
+
+
+Hierarchical RCU debugfs Files and Formats
+
+This implementation of RCU provides three debugfs files under the
+top-level directory RCU: rcu/rcudata (which displays fields in struct
+rcu_data), rcu/rcugp (which displays grace-period counters), and
+rcu/rcuhier (which displays the struct rcu_node hierarchy).
+
+The output of "cat rcu/rcudata" looks as follows:
+
+rcu:
+  0 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=1 rp=3c2a dt=23301/73 dn=2 df=1882 of=0 ri=2126 ql=2 b=10
+  1 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=3 rp=39a6 dt=78073/1 dn=2 df=1402 of=0 ri=1875 ql=46 b=10
+  2 c=4010 g=4010 pq=1 pqc=4010 qp=0 rpfq=-5 rp=1d12 dt=16646/0 dn=2 df=3140 of=0 ri=2080 ql=0 b=10
+  3 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=2b50 dt=21159/1 dn=2 df=2230 of=0 ri=1923 ql=72 b=10
+  4 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1644 dt=5783/1 dn=2 df=3348 of=0 ri=2805 ql=7 b=10
+  5 c=4012 g=4013 pq=0 pqc=4011 qp=1 rpfq=3 rp=1aac dt=5879/1 dn=2 df=3140 of=0 ri=2066 ql=10 b=10
+  6 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=ed8 dt=5847/1 dn=2 df=3797 of=0 ri=1266 ql=10 b=10
+  7 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1fa2 dt=6199/1 dn=2 df=2795 of=0 ri=2162 ql=28 b=10
+rcu_bh:
+  0 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-145 rp=21d6 dt=23301/73 dn=2 df=0 of=0 ri=0 ql=0 b=10
+  1 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-170 rp=20ce dt=78073/1 dn=2 df=26 of=0 ri=5 ql=0 b=10
+  2 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-83 rp=fbd dt=16646/0 dn=2 df=28 of=0 ri=4 ql=0 b=10
+  3 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-105 rp=178c dt=21159/1 dn=2 df=28 of=0 ri=2 ql=0 b=10
+  4 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-30 rp=b54 dt=5783/1 dn=2 df=32 of=0 ri=0 ql=0 b=10
+  5 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-29 rp=df5 dt=5879/1 dn=2 df=30 of=0 ri=3 ql=0 b=10
+  6 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-28 rp=788 dt=5847/1 dn=2 df=32 of=0 ri=0 ql=0 b=10
+  7 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-53 rp=1098 dt=6199/1 dn=2 df=30 of=0 ri=3 ql=0 b=10
+
+The first section lists the rcu_data structures for rcu, the second for
+rcu_bh.  Each section has one line per CPU, or eight for this 8-CPU system.
+The fields are as follows:
+
+o       The number at the beginning of each line is the CPU number.
+        CPUs numbers followed by an exclamation mark are offline,
+        but have been online at least once since boot.  There will be
+        no output for CPUs that have never been online, which can be
+        a good thing in the surprisingly common case where NR_CPUS is
+        substantially larger than the number of actual CPUs.
+
+o       "c" is the count of grace periods that this CPU believes have
+        completed.  CPUs in dynticks idle mode may lag quite a ways
+        behind, for example, CPU 4 under "rcu" above, which has slept
+        through the past 25 RCU grace periods.  It is not unusual to
+        see CPUs lagging by thousands of grace periods.
+
+o       "g" is the count of grace periods that this CPU believes have
+        started.  Again, CPUs in dynticks idle mode may lag behind.
+        If the "c" and "g" values are equal, this CPU has already
+        reported a quiescent state for the last RCU grace period that
+        it is aware of, otherwise, the CPU believes that it owes RCU a
+        quiescent state.
+
+o       "pq" indicates that this CPU has passed through a quiescent state
+        for the current grace period.  It is possible for "pq" to be
+        "1" and "c" different than "g", which indicates that although
+        the CPU has passed through a quiescent state, either (1) this
+        CPU has not yet reported that fact, (2) some other CPU has not
+        yet reported for this grace period, or (3) both.
+
+o       "pqc" indicates which grace period the last-observed quiescent
+        state for this CPU corresponds to.  This is important for handling
+        the race between CPU 0 reporting an extended dynticks-idle
+        quiescent state for CPU 1 and CPU 1 suddenly waking up and
+        reporting its own quiescent state.  If CPU 1 was the last CPU
+        for the current grace period, then the CPU that loses this race
+        will attempt to incorrectly mark CPU 1 as having checked in for
+        the next grace period!
+
+o       "qp" indicates that RCU still expects a quiescent state from
+        this CPU.
+
+o       "rpfq" is the number of rcu_pending() calls on this CPU required
+        to induce this CPU to invoke force_quiescent_state().
+
+o       "rp" is low-order four hex digits of the count of how many times
+        rcu_pending() has been invoked on this CPU.
+
+o       "dt" is the current value of the dyntick counter that is incremented
+        when entering or leaving dynticks idle state, either by the
+        scheduler or by irq.  The number after the "/" is the interrupt
+        nesting depth when in dyntick-idle state, or one greater than
+        the interrupt-nesting depth otherwise.
+
+        This field is displayed only for CONFIG_NO_HZ kernels.
+
+o       "dn" is the current value of the dyntick counter that is incremented
+        when entering or leaving dynticks idle state via NMI.  If both
+        the "dt" and "dn" values are even, then this CPU is in dynticks
+        idle mode and may be ignored by RCU.  If either of these two
+        counters is odd, then RCU must be alert to the possibility of
+        an RCU read-side critical section running on this CPU.
+
+        This field is displayed only for CONFIG_NO_HZ kernels.
+
+o       "df" is the number of times that some other CPU has forced a
+        quiescent state on behalf of this CPU due to this CPU being in
+        dynticks-idle state.
+
+        This field is displayed only for CONFIG_NO_HZ kernels.
+
+o       "of" is the number of times that some other CPU has forced a
+        quiescent state on behalf of this CPU due to this CPU being
+        offline.  In a perfect world, this might neve happen, but it
+        turns out that offlining and onlining a CPU can take several grace
+        periods, and so there is likely to be an extended period of time
+        when RCU believes that the CPU is online when it really is not.
+        Please note that erring in the other direction (RCU believing a
+        CPU is offline when it is really alive and kicking) is a fatal
+        error, so it makes sense to err conservatively.
+
+o       "ri" is the number of times that RCU has seen fit to send a
+        reschedule IPI to this CPU in order to get it to report a
+        quiescent state.
+
+o       "ql" is the number of RCU callbacks currently residing on
+        this CPU.  This is the total number of callbacks, regardless
+        of what state they are in (new, waiting for grace period to
+        start, waiting for grace period to end, ready to invoke).
+
+o       "b" is the batch limit for this CPU.  If more than this number
+        of RCU callbacks is ready to invoke, then the remainder will
+        be deferred.
+
+
+The output of "cat rcu/rcugp" looks as follows:
+
+rcu: completed=33062  gpnum=33063
+rcu_bh: completed=464  gpnum=464
+
+Again, this output is for both "rcu" and "rcu_bh".  The fields are
+taken from the rcu_state structure, and are as follows:
+
+o       "completed" is the number of grace periods that have completed.
+        It is comparable to the "c" field from rcu/rcudata in that a
+        CPU whose "c" field matches the value of "completed" is aware
+        that the corresponding RCU grace period has completed.
+
+o       "gpnum" is the number of grace periods that have started.  It is
+        comparable to the "g" field from rcu/rcudata in that a CPU
+        whose "g" field matches the value of "gpnum" is aware that the
+        corresponding RCU grace period has started.
+
+        If these two fields are equal (as they are for "rcu_bh" above),
+        then there is no grace period in progress, in other words, RCU
+        is idle.  On the other hand, if the two fields differ (as they
+        do for "rcu" above), then an RCU grace period is in progress.
+
+
+The output of "cat rcu/rcuhier" looks as follows, with very long lines:
+
+c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
+1/1 0:127 ^0    
+3/3 0:35 ^0    0/0 36:71 ^1    0/0 72:107 ^2    0/0 108:127 ^3    
+3/3f 0:5 ^0    2/3 6:11 ^1    0/0 12:17 ^2    0/0 18:23 ^3    0/0 24:29 ^4    0/0 30:35 ^5    0/0 36:41 ^0    0/0 42:47 ^1    0/0 48:53 ^2    0/0 54:59 ^3    0/0 60:65 ^4    0/0 66:71 ^5    0/0 72:77 ^0    0/0 78:83 ^1    0/0 84:89 ^2    0/0 90:95 ^3    0/0 96:101 ^4    0/0 102:107 ^5    0/0 108:113 ^0    0/0 114:119 ^1    0/0 120:125 ^2    0/0 126:127 ^3    
+rcu_bh:
+c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
+0/1 0:127 ^0    
+0/3 0:35 ^0    0/0 36:71 ^1    0/0 72:107 ^2    0/0 108:127 ^3    
+0/3f 0:5 ^0    0/3 6:11 ^1    0/0 12:17 ^2    0/0 18:23 ^3    0/0 24:29 ^4    0/0 30:35 ^5    0/0 36:41 ^0    0/0 42:47 ^1    0/0 48:53 ^2    0/0 54:59 ^3    0/0 60:65 ^4    0/0 66:71 ^5    0/0 72:77 ^0    0/0 78:83 ^1    0/0 84:89 ^2    0/0 90:95 ^3    0/0 96:101 ^4    0/0 102:107 ^5    0/0 108:113 ^0    0/0 114:119 ^1    0/0 120:125 ^2    0/0 126:127 ^3
+
+This is once again split into "rcu" and "rcu_bh" portions.  The fields are
+as follows:
+
+o       "c" is exactly the same as "completed" under rcu/rcugp.
+
+o       "g" is exactly the same as "gpnum" under rcu/rcugp.
+
+o       "s" is the "signaled" state that drives force_quiescent_state()'s
+        state machine.
+
+o       "jfq" is the number of jiffies remaining for this grace period
+        before force_quiescent_state() is invoked to help push things
+        along.  Note that CPUs in dyntick-idle mode thoughout the grace
+        period will not report on their own, but rather must be check by
+        some other CPU via force_quiescent_state().
+
+o       "j" is the low-order four hex digits of the jiffies counter.
+        Yes, Paul did run into a number of problems that turned out to
+        be due to the jiffies counter no longer counting.  Why do you ask?
+
+o       "nfqs" is the number of calls to force_quiescent_state() since
+        boot.
+
+o       "nfqsng" is the number of useless calls to force_quiescent_state(),
+        where there wasn't actually a grace period active.  This can
+        happen due to races.  The number in parentheses is the difference
+        between "nfqs" and "nfqsng", or the number of times that
+        force_quiescent_state() actually did some real work.
+
+o       "fqlh" is the number of calls to force_quiescent_state() that
+        exited immediately (without even being counted in nfqs above)
+        due to contention on ->fqslock.
+
+o       Each element of the form "1/1 0:127 ^0" represents one struct
+        rcu_node.  Each line represents one level of the hierarchy, from
+        root to leaves.  It is best to think of the rcu_data structures
+        as forming yet another level after the leaves.  Note that there
+        might be either one, two, or three levels of rcu_node structures,
+        depending on the relationship between CONFIG_RCU_FANOUT and
+        CONFIG_NR_CPUS.
+        
+        o       The numbers separated by the "/" are the qsmask followed
+                by the qsmaskinit.  The qsmask will have one bit
+                set for each entity in the next lower level that
+                has not yet checked in for the current grace period.
+                The qsmaskinit will have one bit for each entity that is
+                currently expected to check in during each grace period.
+                The value of qsmaskinit is assigned to that of qsmask
+                at the beginning of each grace period.
+
+                For example, for "rcu", the qsmask of the first entry
+                of the lowest level is 0x14, meaning that we are still
+                waiting for CPUs 2 and 4 to check in for the current
+                grace period.
+
+        o       The numbers separated by the ":" are the range of CPUs
+                served by this struct rcu_node.  This can be helpful
+                in working out how the hierarchy is wired together.
+
+                For example, the first entry at the lowest level shows
+                "0:5", indicating that it covers CPUs 0 through 5.
+
+        o       The number after the "^" indicates the bit in the
+                next higher level rcu_node structure that this
+                rcu_node structure corresponds to.
+
+                For example, the first entry at the lowest level shows
+                "^0", indicating that it corresponds to bit zero in
+                the first entry at the middle level.
diff --git a/Documentation/arm/pxa/mfp.txt b/Documentation/arm/pxa/mfp.txt
new file mode 100644
index 000000000000..a179e5bc02c9
--- /dev/null
+++ b/Documentation/arm/pxa/mfp.txt
@@ -0,0 +1,286 @@
+                 MFP Configuration for PXA2xx/PXA3xx Processors
+
+                        Eric Miao <eric.miao@marvell.com>
+
+MFP stands for Multi-Function Pin, which is the pin-mux logic on PXA3xx and
+later PXA series processors.  This document describes the existing MFP API,
+and how board/platform driver authors could make use of it.
+
+ Basic Concept
+===============
+
+Unlike the GPIO alternate function settings on PXA25x and PXA27x, a new MFP
+mechanism is introduced from PXA3xx to completely move the pin-mux functions
+out of the GPIO controller. In addition to pin-mux configurations, the MFP
+also controls the low power state, driving strength, pull-up/down and event
+detection of each pin.  Below is a diagram of internal connections between
+the MFP logic and the remaining SoC peripherals:
+
+ +--------+
+ |        |--(GPIO19)--+
+ |  GPIO  |            |
+ |        |--(GPIO...) |
+ +--------+            |
+                       |       +---------+
+ +--------+            +------>|         |
+ |  PWM2  |--(PWM_OUT)-------->|   MFP   |
+ +--------+            +------>|         |-------> to external PAD
+                       | +---->|         |
+ +--------+            | | +-->|         |
+ |  SSP2  |---(TXD)----+ | |   +---------+
+ +--------+              | |
+                         | |
+ +--------+              | |
+ | Keypad |--(MKOUT4)----+ |
+ +--------+                |
+                           |
+ +--------+                |
+ |  UART2 |---(TXD)--------+
+ +--------+
+
+NOTE: the external pad is named as MFP_PIN_GPIO19, it doesn't necessarily
+mean it's dedicated for GPIO19, only as a hint that internally this pin
+can be routed from GPIO19 of the GPIO controller.
+
+To better understand the change from PXA25x/PXA27x GPIO alternate function
+to this new MFP mechanism, here are several key points:
+
+  1. GPIO controller on PXA3xx is now a dedicated controller, same as other
+     internal controllers like PWM, SSP and UART, with 128 internal signals
+     which can be routed to external through one or more MFPs (e.g. GPIO<0>
+     can be routed through either MFP_PIN_GPIO0 as well as MFP_PIN_GPIO0_2,
+     see arch/arm/mach-pxa/mach/include/mfp-pxa300.h)
+
+  2. Alternate function configuration is removed from this GPIO controller,
+     the remaining functions are pure GPIO-specific, i.e.
+
+       - GPIO signal level control
+       - GPIO direction control
+       - GPIO level change detection
+
+  3. Low power state for each pin is now controlled by MFP, this means the
+     PGSRx registers on PXA2xx are now useless on PXA3xx
+
+  4. Wakeup detection is now controlled by MFP, PWER does not control the
+     wakeup from GPIO(s) any more, depending on the sleeping state, ADxER
+     (as defined in pxa3xx-regs.h) controls the wakeup from MFP
+
+NOTE: with such a clear separation of MFP and GPIO, by GPIO<xx> we normally
+mean it is a GPIO signal, and by MFP<xxx> or pin xxx, we mean a physical
+pad (or ball).
+
+ MFP API Usage
+===============
+
+For board code writers, here are some guidelines:
+
+1. include ONE of the following header files in your <board>.c:
+
+   - #include <mach/mfp-pxa25x.h>
+   - #include <mach/mfp-pxa27x.h>
+   - #include <mach/mfp-pxa300.h>
+   - #include <mach/mfp-pxa320.h>
+   - #include <mach/mfp-pxa930.h>
+
+   NOTE: only one file in your <board>.c, depending on the processors used,
+   because pin configuration definitions may conflict in these file (i.e.
+   same name, different meaning and settings on different processors). E.g.
+   for zylonite platform, which support both PXA300/PXA310 and PXA320, two
+   separate files are introduced: zylonite_pxa300.c and zylonite_pxa320.c
+   (in addition to handle MFP configuration differences, they also handle
+   the other differences between the two combinations).
+
+   NOTE: PXA300 and PXA310 are almost identical in pin configurations (with
+   PXA310 supporting some additional ones), thus the difference is actually
+   covered in a single mfp-pxa300.h.
+
+2. prepare an array for the initial pin configurations, e.g.:
+
+   static unsigned long mainstone_pin_config[] __initdata = {
+        /* Chip Select */
+        GPIO15_nCS_1,
+
+        /* LCD - 16bpp Active TFT */
+        GPIOxx_TFT_LCD_16BPP,
+        GPIO16_PWM0_OUT,        /* Backlight */
+
+        /* MMC */
+        GPIO32_MMC_CLK,
+        GPIO112_MMC_CMD,
+        GPIO92_MMC_DAT_0,
+        GPIO109_MMC_DAT_1,
+        GPIO110_MMC_DAT_2,
+        GPIO111_MMC_DAT_3,
+
+        ...
+
+        /* GPIO */
+        GPIO1_GPIO | WAKEUP_ON_EDGE_BOTH,
+   };
+
+   a) once the pin configurations are passed to pxa{2xx,3xx}_mfp_config(),
+   and written to the actual registers, they are useless and may discard,
+   adding '__initdata' will help save some additional bytes here.
+
+   b) when there is only one possible pin configurations for a component,
+   some simplified definitions can be used, e.g. GPIOxx_TFT_LCD_16BPP on
+   PXA25x and PXA27x processors
+
+   c) if by board design, a pin can be configured to wake up the system
+   from low power state, it can be 'OR'ed with any of:
+
+      WAKEUP_ON_EDGE_BOTH
+      WAKEUP_ON_EDGE_RISE
+      WAKEUP_ON_EDGE_FALL
+      WAKEUP_ON_LEVEL_HIGH - specifically for enabling of keypad GPIOs,
+
+   to indicate that this pin has the capability of wake-up the system,
+   and on which edge(s). This, however, doesn't necessarily mean the
+   pin _will_ wakeup the system, it will only when set_irq_wake() is
+   invoked with the corresponding GPIO IRQ (GPIO_IRQ(xx) or gpio_to_irq())
+   and eventually calls gpio_set_wake() for the actual register setting.
+
+   d) although PXA3xx MFP supports edge detection on each pin, the
+   internal logic will only wakeup the system when those specific bits
+   in ADxER registers are set, which can be well mapped to the
+   corresponding peripheral, thus set_irq_wake() can be called with 
+   the peripheral IRQ to enable the wakeup.
+
+
+ MFP on PXA3xx
+===============
+
+Every external I/O pad on PXA3xx (excluding those for special purpose) has
+one MFP logic associated, and is controlled by one MFP register (MFPR).
+
+The MFPR has the following bit definitions (for PXA300/PXA310/PXA320):
+
+ 31                        16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
+  +-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+  |         RESERVED        |PS|PU|PD|  DRIVE |SS|SD|SO|EC|EF|ER|--| AF_SEL |
+  +-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+  Bit 3:   RESERVED
+  Bit 4:   EDGE_RISE_EN - enable detection of rising edge on this pin
+  Bit 5:   EDGE_FALL_EN - enable detection of falling edge on this pin
+  Bit 6:   EDGE_CLEAR   - disable edge detection on this pin
+  Bit 7:   SLEEP_OE_N   - enable outputs during low power modes
+  Bit 8:   SLEEP_DATA   - output data on the pin during low power modes
+  Bit 9:   SLEEP_SEL    - selection control for low power modes signals
+  Bit 13:  PULLDOWN_EN  - enable the internal pull-down resistor on this pin
+  Bit 14:  PULLUP_EN    - enable the internal pull-up resistor on this pin
+  Bit 15:  PULL_SEL     - pull state controlled by selected alternate function
+                          (0) or by PULL{UP,DOWN}_EN bits (1)
+
+  Bit 0 - 2: AF_SEL - alternate function selection, 8 possibilities, from 0-7
+  Bit 10-12: DRIVE  - drive strength and slew rate
+                        0b000 - fast 1mA
+                        0b001 - fast 2mA
+                        0b002 - fast 3mA
+                        0b003 - fast 4mA
+                        0b004 - slow 6mA
+                        0b005 - fast 6mA
+                        0b006 - slow 10mA
+                        0b007 - fast 10mA
+
+ MFP Design for PXA2xx/PXA3xx
+==============================
+
+Due to the difference of pin-mux handling between PXA2xx and PXA3xx, a unified
+MFP API is introduced to cover both series of processors.
+
+The basic idea of this design is to introduce definitions for all possible pin
+configurations, these definitions are processor and platform independent, and
+the actual API invoked to convert these definitions into register settings and
+make them effective there-after.
+
+  Files Involved
+  --------------
+
+  - arch/arm/mach-pxa/include/mach/mfp.h
+  
+  for
+    1. Unified pin definitions - enum constants for all configurable pins
+    2. processor-neutral bit definitions for a possible MFP configuration
+
+  - arch/arm/mach-pxa/include/mach/mfp-pxa3xx.h
+
+  for PXA3xx specific MFPR register bit definitions and PXA3xx common pin
+  configurations
+
+  - arch/arm/mach-pxa/include/mach/mfp-pxa2xx.h
+
+  for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations
+
+  - arch/arm/mach-pxa/include/mach/mfp-pxa25x.h
+    arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
+    arch/arm/mach-pxa/include/mach/mfp-pxa300.h
+    arch/arm/mach-pxa/include/mach/mfp-pxa320.h
+    arch/arm/mach-pxa/include/mach/mfp-pxa930.h
+
+  for processor specific definitions
+
+  - arch/arm/mach-pxa/mfp-pxa3xx.c
+  - arch/arm/mach-pxa/mfp-pxa2xx.c
+
+  for implementation of the pin configuration to take effect for the actual
+  processor.
+
+  Pin Configuration
+  -----------------
+
+  The following comments are copied from mfp.h (see the actual source code
+  for most updated info)
+  
+  /*
+   * a possible MFP configuration is represented by a 32-bit integer
+   *
+   * bit  0.. 9 - MFP Pin Number (1024 Pins Maximum)
+   * bit 10..12 - Alternate Function Selection
+   * bit 13..15 - Drive Strength
+   * bit 16..18 - Low Power Mode State
+   * bit 19..20 - Low Power Mode Edge Detection
+   * bit 21..22 - Run Mode Pull State
+   *
+   * to facilitate the definition, the following macros are provided
+   *
+   * MFP_CFG_DEFAULT - default MFP configuration value, with
+   *              alternate function = 0,
+   *              drive strength = fast 3mA (MFP_DS03X)
+   *              low power mode = default
+   *              edge detection = none
+   *
+   * MFP_CFG    - default MFPR value with alternate function
+   * MFP_CFG_DRV        - default MFPR value with alternate function and
+   *              pin drive strength
+   * MFP_CFG_LPM        - default MFPR value with alternate function and
+   *              low power mode
+   * MFP_CFG_X  - default MFPR value with alternate function,
+   *              pin drive strength and low power mode
+   */
+
+   Examples of pin configurations are:
+
+   #define GPIO94_SSP3_RXD              MFP_CFG_X(GPIO94, AF1, DS08X, FLOAT)
+
+   which reads GPIO94 can be configured as SSP3_RXD, with alternate function
+   selection of 1, driving strength of 0b101, and a float state in low power
+   modes.
+
+   NOTE: this is the default setting of this pin being configured as SSP3_RXD
+   which can be modified a bit in board code, though it is not recommended to
+   do so, simply because this default setting is usually carefully encoded,
+   and is supposed to work in most cases.
+
+  Register Settings
+  -----------------
+
+   Register settings on PXA3xx for a pin configuration is actually very
+   straight-forward, most bits can be converted directly into MFPR value
+   in a easier way. Two sets of MFPR values are calculated: the run-time
+   ones and the low power mode ones, to allow different settings.
+
+   The conversion from a generic pin configuration to the actual register
+   settings on PXA2xx is a bit complicated: many registers are involved,
+   including GAFRx, GPDRx, PGSRx, PWER, PKWR, PFER and PRER. Please see
+   mfp-pxa2xx.c for how the conversion is made.
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 4dbb8be1c991..3c5434c83daf 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -914,7 +914,7 @@ I/O scheduler, a.k.a. elevator, is implemented in two layers.  Generic dispatch
 queue and specific I/O schedulers.  Unless stated otherwise, elevator is used
 to refer to both parts and I/O scheduler to specific I/O schedulers.
 
-Block layer implements generic dispatch queue in ll_rw_blk.c and elevator.c.
+Block layer implements generic dispatch queue in block/*.c.
 The generic dispatch queue is responsible for properly ordering barrier
 requests, requeueing, handling non-fs requests and all other subtleties.
 
@@ -926,8 +926,8 @@ be built inside the kernel.  Each queue can choose different one and can also
 change to another one dynamically.
 
 A block layer call to the i/o scheduler follows the convention elv_xxx(). This
-calls elevator_xxx_fn in the elevator switch (drivers/block/elevator.c). Oh,
-xxx and xxx might not match exactly, but use your imagination. If an elevator
+calls elevator_xxx_fn in the elevator switch (block/elevator.c). Oh, xxx
+and xxx might not match exactly, but use your imagination. If an elevator
 doesn't implement a function, the switch does nothing or some minimal house
 keeping work.
 
diff --git a/Documentation/fb/pxafb.txt b/Documentation/fb/pxafb.txt
index db9b8500b43b..d143a0a749f9 100644
--- a/Documentation/fb/pxafb.txt
+++ b/Documentation/fb/pxafb.txt
@@ -5,9 +5,13 @@ The driver supports the following options, either via
 options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
 
 For example:
-        modprobe pxafb options=mode:640x480-8,passive
+        modprobe pxafb options=vmem:2M,mode:640x480-8,passive
 or on the kernel command line
-        video=pxafb:mode:640x480-8,passive
+        video=pxafb:vmem:2M,mode:640x480-8,passive
+
+vmem: VIDEO_MEM_SIZE
+        Amount of video memory to allocate (can be suffixed with K or M
+        for kilobytes or megabytes)
 
 mode:XRESxYRES[-BPP]
         XRES == LCCR1_PPL + 1
@@ -52,3 +56,87 @@ outputen:POLARITY
 pixclockpol:POLARITY
         pixel clock polarity
         0 => falling edge, 1 => rising edge
+
+
+Overlay Support for PXA27x and later LCD controllers
+====================================================
+
+  PXA27x and later processors support overlay1 and overlay2 on-top of the
+  base framebuffer (although under-neath the base is also possible). They
+  support palette and no-palette RGB formats, as well as YUV formats (only
+  available on overlay2). These overlays have dedicated DMA channels and
+  behave in a similar way as a framebuffer.
+
+  However, there are some differences between these overlay framebuffers
+  and normal framebuffers, as listed below:
+
+  1. overlay can start at a 32-bit word aligned position within the base
+     framebuffer, which means they have a start (x, y). This information
+     is encoded into var->nonstd (no, var->xoffset and var->yoffset are
+     not for such purpose).
+
+  2. overlay framebuffer is allocated dynamically according to specified
+     'struct fb_var_screeninfo', the amount is decided by:
+
+        var->xres_virtual * var->yres_virtual * bpp
+
+     bpp = 16 -- for RGB565 or RGBT555
+         = 24 -- for YUV444 packed
+         = 24 -- for YUV444 planar
+         = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
+         = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
+
+     NOTE:
+
+     a. overlay does not support panning in x-direction, thus
+        var->xres_virtual will always be equal to var->xres
+
+     b. line length of overlay(s) must be on a 32-bit word boundary,
+        for YUV planar modes, it is a requirement for the component
+        with minimum bits per pixel,  e.g. for YUV420, Cr component
+        for one pixel is actually 2-bits, it means the line length
+        should be a multiple of 16-pixels
+
+     c. starting horizontal position (XPOS) should start on a 32-bit
+        word boundary, otherwise the fb_check_var() will just fail.
+
+     d. the rectangle of the overlay should be within the base plane,
+        otherwise fail
+
+     Applications should follow the sequence below to operate an overlay
+     framebuffer:
+
+         a. open("/dev/fb[1-2]", ...)
+         b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
+         c. modify 'var' with desired parameters:
+            1) var->xres and var->yres
+            2) larger var->yres_virtual if more memory is required,
+               usually for double-buffering
+            3) var->nonstd for starting (x, y) and color format
+            4) var->{red, green, blue, transp} if RGB mode is to be used
+         d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
+         e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
+         f. mmap
+         g. ...
+
+  3. for YUV planar formats, these are actually not supported within the
+     framebuffer framework, application has to take care of the offsets
+     and lengths of each component within the framebuffer.
+
+  4. var->nonstd is used to pass starting (x, y) position and color format,
+     the detailed bit fields are shown below:
+
+    31                23  20         10          0
+     +-----------------+---+----------+----------+
+     |  ... unused ... |FOR|   XPOS   |   YPOS   |
+     +-----------------+---+----------+----------+
+
+     FOR  - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
+            0 - RGB
+            1 - YUV444 PACKED
+            2 - YUV444 PLANAR
+            3 - YUV422 PLANAR
+            4 - YUR420 PLANAR
+
+     XPOS - starting horizontal position
+     YPOS - starting vertical position
diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt
index 4ba4664ce5c3..9cb9138f7a79 100644
--- a/Documentation/lockstat.txt
+++ b/Documentation/lockstat.txt
@@ -71,35 +71,50 @@ Look at the current lock statistics:
 
 # less /proc/lock_stat
 
-01 lock_stat version 0.2
+01 lock_stat version 0.3
 02 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 03                               class name    con-bounces    contentions   waittime-min   waittime-max waittime-total    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total
 04 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 05
-06               &inode->i_data.tree_lock-W:            15          21657           0.18     1093295.30 11547131054.85             58          10415           0.16          87.51        6387.60
-07               &inode->i_data.tree_lock-R:             0              0           0.00           0.00           0.00          23302         231198           0.25           8.45       98023.38
-08               --------------------------
-09                 &inode->i_data.tree_lock              0          [<ffffffff8027c08f>] add_to_page_cache+0x5f/0x190
-10
-11 ...............................................................................................................................................................................................
-12
-13                              dcache_lock:          1037           1161           0.38          45.32         774.51           6611         243371           0.15         306.48       77387.24
-14                              -----------
-15                              dcache_lock            180          [<ffffffff802c0d7e>] sys_getcwd+0x11e/0x230
-16                              dcache_lock            165          [<ffffffff802c002a>] d_alloc+0x15a/0x210
-17                              dcache_lock             33          [<ffffffff8035818d>] _atomic_dec_and_lock+0x4d/0x70
-18                              dcache_lock              1          [<ffffffff802beef8>] shrink_dcache_parent+0x18/0x130
+06                          &mm->mmap_sem-W:           233            538 18446744073708       22924.27      607243.51           1342          45806           1.71        8595.89     1180582.34
+07                          &mm->mmap_sem-R:           205            587 18446744073708       28403.36      731975.00           1940         412426           0.58      187825.45     6307502.88
+08                          ---------------
+09                            &mm->mmap_sem            487          [<ffffffff8053491f>] do_page_fault+0x466/0x928
+10                            &mm->mmap_sem            179          [<ffffffff802a6200>] sys_mprotect+0xcd/0x21d
+11                            &mm->mmap_sem            279          [<ffffffff80210a57>] sys_mmap+0x75/0xce
+12                            &mm->mmap_sem             76          [<ffffffff802a490b>] sys_munmap+0x32/0x59
+13                          ---------------
+14                            &mm->mmap_sem            270          [<ffffffff80210a57>] sys_mmap+0x75/0xce
+15                            &mm->mmap_sem            431          [<ffffffff8053491f>] do_page_fault+0x466/0x928
+16                            &mm->mmap_sem            138          [<ffffffff802a490b>] sys_munmap+0x32/0x59
+17                            &mm->mmap_sem            145          [<ffffffff802a6200>] sys_mprotect+0xcd/0x21d
+18
+19 ...............................................................................................................................................................................................
+20
+21                              dcache_lock:           621            623           0.52         118.26        1053.02           6745          91930           0.29         316.29      118423.41
+22                              -----------
+23                              dcache_lock            179          [<ffffffff80378274>] _atomic_dec_and_lock+0x34/0x54
+24                              dcache_lock            113          [<ffffffff802cc17b>] d_alloc+0x19a/0x1eb
+25                              dcache_lock             99          [<ffffffff802ca0dc>] d_rehash+0x1b/0x44
+26                              dcache_lock            104          [<ffffffff802cbca0>] d_instantiate+0x36/0x8a
+27                              -----------
+28                              dcache_lock            192          [<ffffffff80378274>] _atomic_dec_and_lock+0x34/0x54
+29                              dcache_lock             98          [<ffffffff802ca0dc>] d_rehash+0x1b/0x44
+30                              dcache_lock             72          [<ffffffff802cc17b>] d_alloc+0x19a/0x1eb
+31                              dcache_lock            112          [<ffffffff802cbca0>] d_instantiate+0x36/0x8a
 
 This excerpt shows the first two lock class statistics. Line 01 shows the
 output version - each time the format changes this will be updated. Line 02-04
-show the header with column descriptions. Lines 05-10 and 13-18 show the actual
+show the header with column descriptions. Lines 05-18 and 20-31 show the actual
 statistics. These statistics come in two parts; the actual stats separated by a
-short separator (line 08, 14) from the contention points.
+short separator (line 08, 13) from the contention points.
 
-The first lock (05-10) is a read/write lock, and shows two lines above the
+The first lock (05-18) is a read/write lock, and shows two lines above the
 short separator. The contention points don't match the column descriptors,
-they have two: contentions and [<IP>] symbol.
+they have two: contentions and [<IP>] symbol. The second set of contention
+points are the points we're contending with.
 
+The integer part of the time values is in us.
 
 View the top contending locks: