10 files changed, 339 insertions, 389 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 73060819ed99..438277800103 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -159,8 +159,6 @@ hayes-esp.txt
         - info on using the Hayes ESP serial driver.
 highuid.txt
         - notes on the change from 16 bit to 32 bit user/group IDs.
-hpet.txt
-        - High Precision Event Timer Driver for Linux.
 timers/
         - info on the timer related topics
 hw_random.txt
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 3d2d0c29f027..cc8093c15cf5 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -287,14 +287,6 @@ Who:	Glauber Costa <gcosta@redhat.com>
 
 ---------------------------
 
-What:   old style serial driver for ColdFire (CONFIG_SERIAL_COLDFIRE)
-When:   2.6.28
-Why:    This driver still uses the old interface and has been replaced
-        by CONFIG_SERIAL_MCF.
-Who:    Sebastian Siewior <sebastian@breakpoint.cc>
-
----------------------------
-
 What:   /sys/o2cb symlink
 When:   January 2010
 Why:    /sys/fs/o2cb is the proper location for this information - /sys/o2cb
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 0d5394920a31..eb154ef36c2a 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -32,9 +32,9 @@ Mailing list: linux-ext4@vger.kernel.org
     you will need to merge your changes with the version from e2fsprogs
     1.41.x.
 
-  - Create a new filesystem using the ext4dev filesystem type:
+  - Create a new filesystem using the ext4 filesystem type:
 
-        # mke2fs -t ext4dev /dev/hda1
+        # mke2fs -t ext4 /dev/hda1
 
     Or configure an existing ext3 filesystem to support extents and set
     the test_fs flag to indicate that it's ok for an in-development
@@ -47,13 +47,13 @@ Mailing list: linux-ext4@vger.kernel.org
 
         # tune2fs -I 256 /dev/hda1
 
-    (Note: we currently do not have tools to convert an ext4dev
+    (Note: we currently do not have tools to convert an ext4
     filesystem back to ext3; so please do not do try this on production
     filesystems.)
 
   - Mounting:
 
-        # mount -t ext4dev /dev/hda1 /wherever
+        # mount -t ext4 /dev/hda1 /wherever
 
   - When comparing performance with other filesystems, remember that
     ext3/4 by default offers higher data integrity guarantees than most.
@@ -177,6 +177,11 @@ barrier=<0|1(*)>	This enables/disables the use of write barriers in
                         your disks are battery-backed in one way or another,
                         disabling barriers may safely improve performance.
 
+inode_readahead=n       This tuning parameter controls the maximum
+                        number of inode table blocks that ext4's inode
+                        table readahead algorithm will pre-read into
+                        the buffer cache.  The default value is 32 blocks.
+
 orlov           (*)     This enables the new Orlov block allocator. It is
                         enabled by default.
 
@@ -218,6 +223,11 @@ errors=remount-ro(*)	Remount the filesystem read-only on an error.
 errors=continue         Keep going on a filesystem error.
 errors=panic            Panic and halt the machine if an error occurs.
 
+data_err=ignore(*)      Just print an error message if an error occurs
+                        in a file data buffer in ordered mode.
+data_err=abort          Abort the journal if an error occurs in a file
+                        data buffer in ordered mode.
+
 grpid                   Give objects the same group ID as their creator.
 bsdgroups
 
@@ -252,6 +262,7 @@ stripe=n		Number of filesystem blocks that mballoc will try
 delalloc        (*)     Deferring block allocation until write-out time.
 nodelalloc              Disable delayed allocation. Blocks are allocation
                         when data is copied from user to page cache.
+
 Data Mode
 =========
 There are 3 different data modes:
diff --git a/Documentation/filesystems/fiemap.txt b/Documentation/filesystems/fiemap.txt
new file mode 100644
index 000000000000..1e3defcfe50b
--- /dev/null
+++ b/Documentation/filesystems/fiemap.txt
@@ -0,0 +1,228 @@
+============
+Fiemap Ioctl
+============
+
+The fiemap ioctl is an efficient method for userspace to get file
+extent mappings. Instead of block-by-block mapping (such as bmap), fiemap
+returns a list of extents.
+
+
+Request Basics
+--------------
+
+A fiemap request is encoded within struct fiemap:
+
+struct fiemap {
+        __u64   fm_start;        /* logical offset (inclusive) at
+                                  * which to start mapping (in) */
+        __u64   fm_length;       /* logical length of mapping which
+                                  * userspace cares about (in) */
+        __u32   fm_flags;        /* FIEMAP_FLAG_* flags for request (in/out) */
+        __u32   fm_mapped_extents; /* number of extents that were
+                                    * mapped (out) */
+        __u32   fm_extent_count; /* size of fm_extents array (in) */
+        __u32   fm_reserved;
+        struct fiemap_extent fm_extents[0]; /* array of mapped extents (out) */
+};
+
+
+fm_start, and fm_length specify the logical range within the file
+which the process would like mappings for. Extents returned mirror
+those on disk - that is, the logical offset of the 1st returned extent
+may start before fm_start, and the range covered by the last returned
+extent may end after fm_length. All offsets and lengths are in bytes.
+
+Certain flags to modify the way in which mappings are looked up can be
+set in fm_flags. If the kernel doesn't understand some particular
+flags, it will return EBADR and the contents of fm_flags will contain
+the set of flags which caused the error. If the kernel is compatible
+with all flags passed, the contents of fm_flags will be unmodified.
+It is up to userspace to determine whether rejection of a particular
+flag is fatal to it's operation. This scheme is intended to allow the
+fiemap interface to grow in the future but without losing
+compatibility with old software.
+
+fm_extent_count specifies the number of elements in the fm_extents[] array
+that can be used to return extents.  If fm_extent_count is zero, then the
+fm_extents[] array is ignored (no extents will be returned), and the
+fm_mapped_extents count will hold the number of extents needed in
+fm_extents[] to hold the file's current mapping.  Note that there is
+nothing to prevent the file from changing between calls to FIEMAP.
+
+The following flags can be set in fm_flags:
+
+* FIEMAP_FLAG_SYNC
+If this flag is set, the kernel will sync the file before mapping extents.
+
+* FIEMAP_FLAG_XATTR
+If this flag is set, the extents returned will describe the inodes
+extended attribute lookup tree, instead of it's data tree.
+
+
+Extent Mapping
+--------------
+
+Extent information is returned within the embedded fm_extents array
+which userspace must allocate along with the fiemap structure. The
+number of elements in the fiemap_extents[] array should be passed via
+fm_extent_count. The number of extents mapped by kernel will be
+returned via fm_mapped_extents. If the number of fiemap_extents
+allocated is less than would be required to map the requested range,
+the maximum number of extents that can be mapped in the fm_extent[]
+array will be returned and fm_mapped_extents will be equal to
+fm_extent_count. In that case, the last extent in the array will not
+complete the requested range and will not have the FIEMAP_EXTENT_LAST
+flag set (see the next section on extent flags).
+
+Each extent is described by a single fiemap_extent structure as
+returned in fm_extents.
+
+struct fiemap_extent {
+        __u64   fe_logical;  /* logical offset in bytes for the start of
+                              * the extent */
+        __u64   fe_physical; /* physical offset in bytes for the start
+                              * of the extent */
+        __u64   fe_length;   /* length in bytes for the extent */
+        __u64   fe_reserved64[2];
+        __u32   fe_flags;    /* FIEMAP_EXTENT_* flags for this extent */
+        __u32   fe_reserved[3];
+};
+
+All offsets and lengths are in bytes and mirror those on disk.  It is valid
+for an extents logical offset to start before the request or it's logical
+length to extend past the request.  Unless FIEMAP_EXTENT_NOT_ALIGNED is
+returned, fe_logical, fe_physical, and fe_length will be aligned to the
+block size of the file system.  With the exception of extents flagged as
+FIEMAP_EXTENT_MERGED, adjacent extents will not be merged.
+
+The fe_flags field contains flags which describe the extent returned.
+A special flag, FIEMAP_EXTENT_LAST is always set on the last extent in
+the file so that the process making fiemap calls can determine when no
+more extents are available, without having to call the ioctl again.
+
+Some flags are intentionally vague and will always be set in the
+presence of other more specific flags. This way a program looking for
+a general property does not have to know all existing and future flags
+which imply that property.
+
+For example, if FIEMAP_EXTENT_DATA_INLINE or FIEMAP_EXTENT_DATA_TAIL
+are set, FIEMAP_EXTENT_NOT_ALIGNED will also be set. A program looking
+for inline or tail-packed data can key on the specific flag. Software
+which simply cares not to try operating on non-aligned extents
+however, can just key on FIEMAP_EXTENT_NOT_ALIGNED, and not have to
+worry about all present and future flags which might imply unaligned
+data. Note that the opposite is not true - it would be valid for
+FIEMAP_EXTENT_NOT_ALIGNED to appear alone.
+
+* FIEMAP_EXTENT_LAST
+This is the last extent in the file. A mapping attempt past this
+extent will return nothing.
+
+* FIEMAP_EXTENT_UNKNOWN
+The location of this extent is currently unknown. This may indicate
+the data is stored on an inaccessible volume or that no storage has
+been allocated for the file yet.
+
+* FIEMAP_EXTENT_DELALLOC
+  - This will also set FIEMAP_EXTENT_UNKNOWN.
+Delayed allocation - while there is data for this extent, it's
+physical location has not been allocated yet.
+
+* FIEMAP_EXTENT_ENCODED
+This extent does not consist of plain filesystem blocks but is
+encoded (e.g. encrypted or compressed).  Reading the data in this
+extent via I/O to the block device will have undefined results.
+
+Note that it is *always* undefined to try to update the data
+in-place by writing to the indicated location without the
+assistance of the filesystem, or to access the data using the
+information returned by the FIEMAP interface while the filesystem
+is mounted.  In other words, user applications may only read the
+extent data via I/O to the block device while the filesystem is
+unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is
+clear; user applications must not try reading or writing to the
+filesystem via the block device under any other circumstances.
+
+* FIEMAP_EXTENT_DATA_ENCRYPTED
+  - This will also set FIEMAP_EXTENT_ENCODED
+The data in this extent has been encrypted by the file system.
+
+* FIEMAP_EXTENT_NOT_ALIGNED
+Extent offsets and length are not guaranteed to be block aligned.
+
+* FIEMAP_EXTENT_DATA_INLINE
+  This will also set FIEMAP_EXTENT_NOT_ALIGNED
+Data is located within a meta data block.
+
+* FIEMAP_EXTENT_DATA_TAIL
+  This will also set FIEMAP_EXTENT_NOT_ALIGNED
+Data is packed into a block with data from other files.
+
+* FIEMAP_EXTENT_UNWRITTEN
+Unwritten extent - the extent is allocated but it's data has not been
+initialized.  This indicates the extent's data will be all zero if read
+through the filesystem but the contents are undefined if read directly from
+the device.
+
+* FIEMAP_EXTENT_MERGED
+This will be set when a file does not support extents, i.e., it uses a block
+based addressing scheme.  Since returning an extent for each block back to
+userspace would be highly inefficient, the kernel will try to merge most
+adjacent blocks into 'extents'.
+
+
+VFS -> File System Implementation
+---------------------------------
+
+File systems wishing to support fiemap must implement a ->fiemap callback on
+their inode_operations structure. The fs ->fiemap call is responsible for
+defining it's set of supported fiemap flags, and calling a helper function on
+each discovered extent:
+
+struct inode_operations {
+       ...
+
+       int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start,
+                     u64 len);
+
+->fiemap is passed struct fiemap_extent_info which describes the
+fiemap request:
+
+struct fiemap_extent_info {
+        unsigned int fi_flags;          /* Flags as passed from user */
+        unsigned int fi_extents_mapped; /* Number of mapped extents */
+        unsigned int fi_extents_max;    /* Size of fiemap_extent array */
+        struct fiemap_extent *fi_extents_start; /* Start of fiemap_extent array */
+};
+
+It is intended that the file system should not need to access any of this
+structure directly.
+
+
+Flag checking should be done at the beginning of the ->fiemap callback via the
+fiemap_check_flags() helper:
+
+int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);
+
+The struct fieinfo should be passed in as recieved from ioctl_fiemap(). The
+set of fiemap flags which the fs understands should be passed via fs_flags. If
+fiemap_check_flags finds invalid user flags, it will place the bad values in
+fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from
+fiemap_check_flags(), it should immediately exit, returning that error back to
+ioctl_fiemap().
+
+
+For each extent in the request range, the file system should call
+the helper function, fiemap_fill_next_extent():
+
+int fiemap_fill_next_extent(struct fiemap_extent_info *info, u64 logical,
+                            u64 phys, u64 len, u32 flags, u32 dev);
+
+fiemap_fill_next_extent() will use the passed values to populate the
+next free extent in the fm_extents array. 'General' extent flags will
+automatically be set from specific flags on behalf of the calling file
+system so that the userspace API is not broken.
+
+fiemap_fill_next_extent() returns 0 on success, and 1 when the
+user-supplied fm_extents array is full. If an error is encountered
+while copying the extent to user memory, -EFAULT will be returned.
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index f566ad9bcb7b..b488edad743c 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -923,45 +923,44 @@ CPUs.
 The   "procs_blocked" line gives  the  number of  processes currently blocked,
 waiting for I/O to complete.
 
+
 1.9 Ext4 file system parameters
 ------------------------------
-Ext4 file system have one directory per partition under /proc/fs/ext4/
-# ls /proc/fs/ext4/hdc/
-group_prealloc  max_to_scan  mb_groups  mb_history  min_to_scan  order2_req
-stats  stream_req
-
-mb_groups:
-This file gives the details of multiblock allocator buddy cache of free blocks
-
-mb_history:
-Multiblock allocation history.
-
-stats:
-This file indicate whether the multiblock allocator should start collecting
-statistics. The statistics are shown during unmount
-
-group_prealloc:
-The multiblock allocator normalize the block allocation request to
-group_prealloc filesystem blocks if we don't have strip value set.
-The stripe value can be specified at mount time or during mke2fs.
-
-max_to_scan:
-How long multiblock allocator can look for a best extent (in found extents)
 
-min_to_scan:
-How long multiblock allocator  must look for a best extent
+Information about mounted ext4 file systems can be found in
+/proc/fs/ext4.  Each mounted filesystem will have a directory in
+/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
+/proc/fs/ext4/dm-0).   The files in each per-device directory are shown
+in Table 1-10, below.
 
-order2_req:
-Multiblock allocator use  2^N search using buddies only for requests greater
-than or equal to order2_req. The request size is specfied in file system
-blocks. A value of 2 indicate only if the requests are greater than or equal
-to 4 blocks.
+Table 1-10: Files in /proc/fs/ext4/<devname>
+..............................................................................
+ File            Content                                        
+ mb_groups       details of multiblock allocator buddy cache of free blocks
+ mb_history      multiblock allocation history
+ stats           controls whether the multiblock allocator should start
+                 collecting statistics, which are shown during the unmount
+ group_prealloc  the multiblock allocator will round up allocation
+                 requests to a multiple of this tuning parameter if the
+                 stripe size is not set in the ext4 superblock
+ max_to_scan     The maximum number of extents the multiblock allocator
+                 will search to find the best extent
+ min_to_scan     The minimum number of extents the multiblock allocator
+                 will search to find the best extent
+ order2_req      Tuning parameter which controls the minimum size for 
+                 requests (as a power of 2) where the buddy cache is
+                 used
+ stream_req      Files which have fewer blocks than this tunable
+                 parameter will have their blocks allocated out of a
+                 block group specific preallocation pool, so that small
+                 files are packed closely together.  Each large file
+                 will have its blocks allocated out of its own unique
+                 preallocation pool.
+inode_readahead  Tuning parameter which controls the maximum number of
+                 inode table blocks that ext4's inode table readahead
+                 algorithm will pre-read into the buffer cache
+..............................................................................
 
-stream_req:
-Files smaller than stream_req are served by the stream allocator, whose
-purpose is to pack requests as close each to other as possible to
-produce smooth I/O traffic. Avalue of 16 indicate that file smaller than 16
-filesystem block size will use group based preallocation.
 
 ------------------------------------------------------------------------------
 Summary
@@ -1332,13 +1331,6 @@ determine whether or not they are still functioning properly.
 Because the NMI watchdog shares registers with oprofile, by disabling the NMI
 watchdog, oprofile may have more registers to utilize.
 
-maps_protect
-------------
-
-Enables/Disables the protection of the per-process proc entries "maps" and
-"smaps".  When enabled, the contents of these files are visible only to
-readers that are allowed to ptrace() the given process.
-
 msgmni
 ------
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 2ca9c8f8c8d8..2443f5bb4364 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -658,11 +658,12 @@ and is between 256 and 4096 characters. It is defined in the file
         earlyprintk=    [X86-32,X86-64,SH,BLACKFIN]
                         earlyprintk=vga
                         earlyprintk=serial[,ttySn[,baudrate]]
+                        earlyprintk=dbgp
 
                         Append ",keep" to not disable it when the real console
                         takes over.
 
-                        Only vga or serial at a time, not both.
+                        Only vga or serial or usb debug port at a time.
 
                         Currently only ttyS0 and ttyS1 are supported.
 
@@ -1231,6 +1232,29 @@ and is between 256 and 4096 characters. It is defined in the file
                                  or
                                  memmap=0x10000$0x18690000
 
+        memory_corruption_check=0/1 [X86]
+                        Some BIOSes seem to corrupt the first 64k of
+                        memory when doing things like suspend/resume.
+                        Setting this option will scan the memory
+                        looking for corruption.  Enabling this will
+                        both detect corruption and prevent the kernel
+                        from using the memory being corrupted.
+                        However, its intended as a diagnostic tool; if
+                        repeatable BIOS-originated corruption always
+                        affects the same memory, you can use memmap=
+                        to prevent the kernel from using that memory.
+
+        memory_corruption_check_size=size [X86]
+                        By default it checks for corruption in the low
+                        64k, making this memory unavailable for normal
+                        use.  Use this parameter to scan for
+                        corruption in more or less memory.
+
+        memory_corruption_check_period=seconds [X86]
+                        By default it checks for corruption every 60
+                        seconds.  Use this parameter to check at some
+                        other rate.  0 disables periodic checking.
+
         memtest=        [KNL,X86] Enable memtest
                         Format: <integer>
                         range: 0,4 : pattern number
@@ -1428,6 +1452,12 @@ and is between 256 and 4096 characters. It is defined in the file
 
         nolapic_timer   [X86-32,APIC] Do not use the local APIC timer.
 
+        nox2apic        [X86-64,APIC] Do not enable x2APIC mode.
+
+        x2apic_phys     [X86-64,APIC] Use x2apic physical mode instead of
+                        default x2apic cluster mode on platforms
+                        supporting x2apic.
+
         noltlbs         [PPC] Do not use large page/tlb entries for kernel
                         lowmem mapping on PPC40x.
 
diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
index b54cb5048dfa..87a7c07ab658 100644
--- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl
@@ -5073,8 +5073,7 @@ struct _snd_pcm_runtime {
       with <constant>SNDRV_DMA_TYPE_CONTINUOUS</constant> type and the
       <function>snd_dma_continuous_data(GFP_KERNEL)</function> device pointer,
       where <constant>GFP_KERNEL</constant> is the kernel allocation flag to
-      use.  For the SBUS, <constant>SNDRV_DMA_TYPE_SBUS</constant> and
-      <function>snd_dma_sbus_data(sbus_dev)</function> are used instead.
+      use.
       For the PCI scatter-gather buffers, use
       <constant>SNDRV_DMA_TYPE_DEV_SG</constant> with
       <function>snd_dma_pci_data(pci)</function>
diff --git a/Documentation/sparc/sbus_drivers.txt b/Documentation/sparc/sbus_drivers.txt
deleted file mode 100644
index eb1e28ad8822..000000000000
--- a/Documentation/sparc/sbus_drivers.txt
+++ /dev/null
@@ -1,309 +0,0 @@
-
-                Writing SBUS Drivers
-
-            David S. Miller (davem@redhat.com)
-
-        The SBUS driver interfaces of the Linux kernel have been
-revamped completely for 2.4.x for several reasons.  Foremost were
-performance and complexity concerns.  This document details these
-new interfaces and how they are used to write an SBUS device driver.
-
-        SBUS drivers need to include <asm/sbus.h> to get access
-to functions and structures described here.
-
-                Probing and Detection
-
-        Each SBUS device inside the machine is described by a
-structure called "struct sbus_dev".  Likewise, each SBUS bus
-found in the system is described by a "struct sbus_bus".  For
-each SBUS bus, the devices underneath are hung in a tree-like
-fashion off of the bus structure.
-
-        The SBUS device structure contains enough information
-for you to implement your device probing algorithm and obtain
-the bits necessary to run your device.  The most commonly
-used members of this structure, and their typical usage,
-will be detailed below.
-
-        Here is a piece of skeleton code for performing a device
-probe in an SBUS driver under Linux:
-
-        static int __devinit mydevice_probe_one(struct sbus_dev *sdev)
-        {
-                struct mysdevice *mp = kzalloc(sizeof(*mp), GFP_KERNEL);
-
-                if (!mp)
-                        return -ENODEV;
-
-                ...
-                dev_set_drvdata(&sdev->ofdev.dev, mp);
-                return 0;
-                ...
-        }
-
-        static int __devinit mydevice_probe(struct of_device *dev,
-                                            const struct of_device_id *match)
-        {
-                struct sbus_dev *sdev = to_sbus_device(&dev->dev);
-
-                return mydevice_probe_one(sdev);
-        }
-
-        static int __devexit mydevice_remove(struct of_device *dev)
-        {
-                struct sbus_dev *sdev = to_sbus_device(&dev->dev);
-                struct mydevice *mp = dev_get_drvdata(&dev->dev);
-
-                return mydevice_remove_one(sdev, mp);
-        }
-
-        static struct of_device_id mydevice_match[] = {
-                {
-                        .name = "mydevice",
-                },
-                {},
-        };
-
-        MODULE_DEVICE_TABLE(of, mydevice_match);
-
-        static struct of_platform_driver mydevice_driver = {
-                .match_table    = mydevice_match,
-                .probe          = mydevice_probe,
-                .remove         = __devexit_p(mydevice_remove),
-                .driver         = {
-                        .name           = "mydevice",
-                },
-        };
-
-        static int __init mydevice_init(void)
-        {
-                return of_register_driver(&mydevice_driver, &sbus_bus_type);
-        }
-
-        static void __exit mydevice_exit(void)
-        {
-                of_unregister_driver(&mydevice_driver);
-        }
-
-        module_init(mydevice_init);
-        module_exit(mydevice_exit);
-
-        The mydevice_match table is a series of entries which
-describes what SBUS devices your driver is meant for.  In the
-simplest case you specify a string for the 'name' field.  Every
-SBUS device with a 'name' property matching your string will
-be passed one-by-one to your .probe method.
-
-        You should store away your device private state structure
-pointer in the drvdata area so that you can retrieve it later on
-in your .remove method.
-
-        Any memory allocated, registers mapped, IRQs registered,
-etc. must be undone by your .remove method so that all resources
-of your device are released by the time it returns.
-
-        You should _NOT_ use the for_each_sbus(), for_each_sbusdev(),
-and for_all_sbusdev() interfaces.  They are deprecated, will be
-removed, and no new driver should reference them ever.
-
-                Mapping and Accessing I/O Registers
-
-        Each SBUS device structure contains an array of descriptors
-which describe each register set. We abuse struct resource for that.
-They each correspond to the "reg" properties provided by the OBP firmware.
-
-        Before you can access your device's registers you must map
-them.  And later if you wish to shutdown your driver (for module
-unload or similar) you must unmap them.  You must treat them as
-a resource, which you allocate (map) before using and free up
-(unmap) when you are done with it.
-
-        The mapping information is stored in an opaque value
-typed as an "unsigned long".  This is the type of the return value
-of the mapping interface, and the arguments to the unmapping
-interface.  Let's say you want to map the first set of registers.
-Perhaps part of your driver software state structure looks like:
-
-        struct mydevice {
-                unsigned long control_regs;
-           ...
-                struct sbus_dev *sdev;
-           ...
-        };
-
-        At initialization time you then use the sbus_ioremap
-interface to map in your registers, like so:
-
-        static void init_one_mydevice(struct sbus_dev *sdev)
-        {
-                struct mydevice *mp;
-                ...
-
-                mp->control_regs = sbus_ioremap(&sdev->resource[0], 0,
-                                        CONTROL_REGS_SIZE, "mydevice regs");
-                if (!mp->control_regs) {
-                        /* Failure, cleanup and return. */
-                }
-        }
-
-        Second argument to sbus_ioremap is an offset for
-cranky devices with broken OBP PROM. The sbus_ioremap uses only
-a start address and flags from the resource structure.
-Therefore it is possible to use the same resource to map
-several sets of registers or even to fabricate a resource
-structure if driver gets physical address from some private place.
-This practice is discouraged though. Use whatever OBP PROM
-provided to you.
-
-        And here is how you might unmap these registers later at
-driver shutdown or module unload time, using the sbus_iounmap
-interface:
-
-        static void mydevice_unmap_regs(struct mydevice *mp)
-        {
-                sbus_iounmap(mp->control_regs, CONTROL_REGS_SIZE);
-        }
-
-        Finally, to actually access your registers there are 6
-interface routines at your disposal.  Accesses are byte (8 bit),
-word (16 bit), or longword (32 bit) sized.  Here they are:
-
-        u8 sbus_readb(unsigned long reg)                /* read byte */
-        u16 sbus_readw(unsigned long reg)               /* read word */
-        u32 sbus_readl(unsigned long reg)               /* read longword */
-        void sbus_writeb(u8 value, unsigned long reg)   /* write byte */
-        void sbus_writew(u16 value, unsigned long reg)  /* write word */
-        void sbus_writel(u32 value, unsigned long reg)  /* write longword */
-
-        So, let's say your device has a control register of some sort
-at offset zero.  The following might implement resetting your device:
-
-        #define CONTROL         0x00UL
-
-        #define CONTROL_RESET   0x00000001      /* Reset hardware */
-
-        static void mydevice_reset(struct mydevice *mp)
-        {
-                sbus_writel(CONTROL_RESET, mp->regs + CONTROL);
-        }
-
-        Or perhaps there is a data port register at an offset of
-16 bytes which allows you to read bytes from a fifo in the device:
-
-        #define DATA            0x10UL
-
-        static u8 mydevice_get_byte(struct mydevice *mp)
-        {
-                return sbus_readb(mp->regs + DATA);
-        }
-
-        It's pretty straightforward, and clueful readers may have
-noticed that these interfaces mimick the PCI interfaces of the
-Linux kernel.  This was not by accident.
-
-        WARNING:
-
-                DO NOT try to treat these opaque register mapping
-                values as a memory mapped pointer to some structure
-                which you can dereference.
-
-                It may be memory mapped, it may not be.  In fact it
-                could be a physical address, or it could be the time
-                of day xor'd with 0xdeadbeef.  :-)
-
-                Whatever it is, it's an implementation detail.  The
-                interface was done this way to shield the driver
-                author from such complexities.
-
-                        Doing DVMA
-
-        SBUS devices can perform DMA transactions in a way similar
-to PCI but dissimilar to ISA, e.g. DMA masters supply address.
-In contrast to PCI, however, that address (a bus address) is
-translated by IOMMU before a memory access is performed and therefore
-it is virtual. Sun calls this procedure DVMA.
-
-        Linux supports two styles of using SBUS DVMA: "consistent memory"
-and "streaming DVMA". CPU view of consistent memory chunk is, well,
-consistent with a view of a device. Think of it as an uncached memory.
-Typically this way of doing DVMA is not very fast and drivers use it
-mostly for control blocks or queues. On some CPUs we cannot flush or
-invalidate individual pages or cache lines and doing explicit flushing
-over ever little byte in every control block would be wasteful.
-
-Streaming DVMA is a preferred way to transfer large amounts of data.
-This process works in the following way:
-1. a CPU stops accessing a certain part of memory,
-   flushes its caches covering that memory;
-2. a device does DVMA accesses, then posts an interrupt;
-3. CPU invalidates its caches and starts to access the memory.
-
-A single streaming DVMA operation can touch several discontiguous
-regions of a virtual bus address space. This is called a scatter-gather
-DVMA.
-
-[TBD: Why do not we neither Solaris attempt to map disjoint pages
-into a single virtual chunk with the help of IOMMU, so that non SG
-DVMA masters would do SG? It'd be very helpful for RAID.]
-
-        In order to perform a consistent DVMA a driver does something
-like the following:
-
-        char *mem;              /* Address in the CPU space */
-        u32 busa;               /* Address in the SBus space */
-
-        mem = (char *) sbus_alloc_consistent(sdev, MYMEMSIZE, &busa);
-
-        Then mem is used when CPU accesses this memory and u32
-is fed to the device so that it can do DVMA. This is typically
-done with an sbus_writel() into some device register.
-
-        Do not forget to free the DVMA resources once you are done:
-
-        sbus_free_consistent(sdev, MYMEMSIZE, mem, busa);
-
-        Streaming DVMA is more interesting. First you allocate some
-memory suitable for it or pin down some user pages. Then it all works
-like this:
-
-        char *mem = argumen1;
-        unsigned int size = argument2;
-        u32 busa;               /* Address in the SBus space */
-
-        *mem = 1;               /* CPU can access */
-        busa = sbus_map_single(sdev, mem, size);
-        if (busa == 0) .......
-
-        /* Tell the device to use busa here */
-        /* CPU cannot access the memory without sbus_dma_sync_single() */
-
-        sbus_unmap_single(sdev, busa, size);
-        if (*mem == 0) ....     /* CPU can access again */
-
-        It is possible to retain mappings and ask the device to
-access data again and again without calling sbus_unmap_single.
-However, CPU caches must be invalidated with sbus_dma_sync_single
-before such access.
-
-[TBD but what about writeback caches here... do we have any?]
-
-        There is an equivalent set of functions doing the same thing
-only with several memory segments at once for devices capable of
-scatter-gather transfers. Use the Source, Luke.
-
-                        Examples
-
-        drivers/net/sunhme.c
-        This is a complicated driver which illustrates many concepts
-discussed above and plus it handles both PCI and SBUS boards.
-
-        drivers/scsi/esp.c
-        Check it out for scatter-gather DVMA.
-
-        drivers/sbus/char/bpp.c
-        A non-DVMA device.
-
-        drivers/net/sunlance.c
-        Lance driver abuses consistent mappings for data transfer.
-It is a nifty trick which we do not particularly recommend...
-Just check it out and know that it's legal.
diff --git a/Documentation/timers/00-INDEX b/Documentation/timers/00-INDEX
new file mode 100644
index 000000000000..397dc35e1323
--- /dev/null
+++ b/Documentation/timers/00-INDEX
@@ -0,0 +1,10 @@
+00-INDEX
+        - this file
+highres.txt
+        - High resolution timers and dynamic ticks design notes
+hpet.txt
+        - High Precision Event Timer Driver for Linux
+hrtimers.txt
+        - subsystem for high-resolution kernel timers
+timer_stats.txt
+        - timer usage statistics
diff --git a/Documentation/hpet.txt b/Documentation/timers/hpet.txt
index 6ad52d9dad6c..e7c09abcfab4 100644
--- a/Documentation/hpet.txt
+++ b/Documentation/timers/hpet.txt
@@ -1,21 +1,32 @@
                 High Precision Event Timer Driver for Linux
 
-The High Precision Event Timer (HPET) hardware is the future replacement
-for the 8254 and Real Time Clock (RTC) periodic timer functionality.
-Each HPET can have up to 32 timers.  It is possible to configure the
-first two timers as legacy replacements for 8254 and RTC periodic timers.
-A specification done by Intel and Microsoft can be found at
-<http://www.intel.com/technology/architecture/hpetspec.htm>.
+The High Precision Event Timer (HPET) hardware follows a specification
+by Intel and Microsoft which can be found at
+
+        http://www.intel.com/technology/architecture/hpetspec.htm
+
+Each HPET has one fixed-rate counter (at 10+ MHz, hence "High Precision")
+and up to 32 comparators.  Normally three or more comparators are provided,
+each of which can generate oneshot interupts and at least one of which has
+additional hardware to support periodic interrupts.  The comparators are
+also called "timers", which can be misleading since usually timers are
+independent of each other ... these share a counter, complicating resets.
+
+HPET devices can support two interrupt routing modes.  In one mode, the
+comparators are additional interrupt sources with no particular system
+role.  Many x86 BIOS writers don't route HPET interrupts at all, which
+prevents use of that mode.  They support the other "legacy replacement"
+mode where the first two comparators block interrupts from 8254 timers
+and from the RTC.
 
 The driver supports detection of HPET driver allocation and initialization
 of the HPET before the driver module_init routine is called.  This enables
 platform code which uses timer 0 or 1 as the main timer to intercept HPET
 initialization.  An example of this initialization can be found in
-arch/i386/kernel/time_hpet.c.
+arch/x86/kernel/hpet.c.
 
-The driver provides two APIs which are very similar to the API found in
-the rtc.c driver.  There is a user space API and a kernel space API.
-An example user space program is provided below.
+The driver provides a userspace API which resembles the API found in the
+RTC driver framework.  An example user space program is provided below.
 
 #include <stdio.h>
 #include <stdlib.h>
@@ -286,15 +297,3 @@ out:
 
         return;
 }
-
-The kernel API has three interfaces exported from the driver:
-
-        hpet_register(struct hpet_task *tp, int periodic)
-        hpet_unregister(struct hpet_task *tp)
-        hpet_control(struct hpet_task *tp, unsigned int cmd, unsigned long arg)
-
-The kernel module using this interface fills in the ht_func and ht_data
-members of the hpet_task structure before calling hpet_register.
-hpet_control simply vectors to the hpet_ioctl routine and has the same
-commands and respective arguments as the user API.  hpet_unregister
-is used to terminate usage of the HPET timer reserved by hpet_register.