---

yaml
---
r: 310581
b: refs/heads/master
c: 063e047
h: refs/heads/master
i:
  310579: 1a87b09
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 03d8f5408235bfd2781142458e0c0671530e74e7
+refs/heads/master: 063e04776172f93b16a5eefd5661a340c1126513

trunk/.mailmap

@@ -113,5 +113,3 @@ Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
 Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
 Takashi YOSHII <takashi.yoshii.zj@renesas.com>
 Yusuke Goda <goda.yusuke@renesas.com>
-Gustavo Padovan <gustavo@las.ic.unicamp.br>
-Gustavo Padovan <padovan@profusion.mobi>

trunk/Documentation/ABI/testing/sysfs-block-rssd

@@ -6,21 +6,13 @@ Description:    This is a read-only file. Dumps below driver information and
                 hardware registers.
                     - S ACTive
                     - Command Issue
+                    - Allocated
                     - Completed
                     - PORT IRQ STAT
                     - HOST IRQ STAT
-                    - Allocated
-                    - Commands in Q
 
 What:           /sys/block/rssd*/status
 Date:           April 2012
 KernelVersion:  3.4
 Contact:        Asai Thambi S P <asamymuthupa@micron.com>
-Description:    This is a read-only file. Indicates the status of the device.
-
-What:           /sys/block/rssd*/flags
-Date:           May 2012
-KernelVersion:  3.5
-Contact:        Asai Thambi S P <asamymuthupa@micron.com>
-Description:    This is a read-only file. Dumps the flags in port and driver
-                data structure
+Description:   This is a read-only file. Indicates the status of the device.

trunk/Documentation/ABI/testing/sysfs-bus-rbd

@@ -65,11 +65,11 @@ snap_*
 Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
 -------------------------------------------------------------
 
-snap_id
+id
 
 	The rados internal snapshot id assigned for this snapshot
 
-snap_size
+size
 
 	The size of the image when this snapshot was taken.
 

trunk/Documentation/ABI/testing/sysfs-class-mtd

@@ -123,54 +123,3 @@ Description:
 		half page, or a quarter page).
 
 		In the case of ECC NOR, it is the ECC block size.
-
-What:		/sys/class/mtd/mtdX/ecc_strength
-Date:		April 2012
-KernelVersion:	3.4
-Contact:	linux-mtd@lists.infradead.org
-Description:
-		Maximum number of bit errors that the device is capable of
-		correcting within each region covering an ecc step.  This will
-		always be a non-negative integer.  Note that some devices will
-		have multiple ecc steps within each writesize region.
-
-		In the case of devices lacking any ECC capability, it is 0.
-
-What:		/sys/class/mtd/mtdX/bitflip_threshold
-Date:		April 2012
-KernelVersion:	3.4
-Contact:	linux-mtd@lists.infradead.org
-Description:
-		This allows the user to examine and adjust the criteria by which
-		mtd returns -EUCLEAN from mtd_read().  If the maximum number of
-		bit errors that were corrected on any single region comprising
-		an ecc step (as reported by the driver) equals or exceeds this
-		value, -EUCLEAN is returned.  Otherwise, absent an error, 0 is
-		returned.  Higher layers (e.g., UBI) use this return code as an
-		indication that an erase block may be degrading and should be
-		scrutinized as a candidate for being marked as bad.
-
-		The initial value may be specified by the flash device driver.
-		If not, then the default value is ecc_strength.
-
-		The introduction of this feature brings a subtle change to the
-		meaning of the -EUCLEAN return code.  Previously, it was
-		interpreted to mean simply "one or more bit errors were
-		corrected".  Its new interpretation can be phrased as "a
-		dangerously high number of bit errors were corrected on one or
-		more regions comprising an ecc step".  The precise definition of
-		"dangerously high" can be adjusted by the user with
-		bitflip_threshold.  Users are discouraged from doing this,
-		however, unless they know what they are doing and have intimate
-		knowledge of the properties of their device.  Broadly speaking,
-		bitflip_threshold should be low enough to detect genuine erase
-		block degradation, but high enough to avoid the consequences of
-		a persistent return value of -EUCLEAN on devices where sticky
-		bitflips occur.  Note that if bitflip_threshold exceeds
-		ecc_strength, -EUCLEAN is never returned by mtd_read().
-		Conversely, if bitflip_threshold is zero, -EUCLEAN is always
-		returned, absent a hard error.
-
-		This is generally applicable only to NAND flash devices with ECC
-		capability.  It is ignored on devices lacking ECC capability;
-		i.e., devices for which ecc_strength is zero.

trunk/Documentation/CodingStyle

@@ -671,9 +671,8 @@ ones already enabled by DEBUG.
 		Chapter 14: Allocating memory
 
 The kernel provides the following general purpose memory allocators:
-kmalloc(), kzalloc(), kmalloc_array(), kcalloc(), vmalloc(), and
-vzalloc().  Please refer to the API documentation for further information
-about them.
+kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc().  Please refer to
+the API documentation for further information about them.
 
 The preferred form for passing a size of a struct is the following:
 
@@ -687,17 +686,6 @@ Casting the return value which is a void pointer is redundant. The conversion
 from void pointer to any other pointer type is guaranteed by the C programming
 language.
 
-The preferred form for allocating an array is the following:
-
-	p = kmalloc_array(n, sizeof(...), ...);
-
-The preferred form for allocating a zeroed array is the following:
-
-	p = kcalloc(n, sizeof(...), ...);
-
-Both forms check for overflow on the allocation size n * sizeof(...),
-and return NULL if that occurred.
-
 
 		Chapter 15: The inline disease
 

trunk/Documentation/DocBook/mtdnand.tmpl

@@ -1119,6 +1119,8 @@ in this page</entry>
 		These constants are defined in nand.h. They are ored together to describe
 		the chip functionality.
      		<programlisting>
+/* Chip can not auto increment pages */
+#define NAND_NO_AUTOINCR	0x00000001
 /* Buswitdh is 16 bit */
 #define NAND_BUSWIDTH_16	0x00000002
 /* Device supports partial programming without padding */

trunk/Documentation/arm/OMAP/DSS

@@ -47,51 +47,6 @@ flexible way to enable non-common multi-display configuration. In addition to
 modelling the hardware overlays, omapdss supports virtual overlays and overlay
 managers. These can be used when updating a display with CPU or system DMA.
 
-omapdss driver support for audio
---------------------------------
-There exist several display technologies and standards that support audio as
-well. Hence, it is relevant to update the DSS device driver to provide an audio
-interface that may be used by an audio driver or any other driver interested in
-the functionality.
-
-The audio_enable function is intended to prepare the relevant
-IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
-some IP, enabling companion chips, etc). It is intended to be called before
-audio_start. The audio_disable function performs the reverse operation and is
-intended to be called after audio_stop.
-
-While a given DSS device driver may support audio, it is possible that for
-certain configurations audio is not supported (e.g., an HDMI display using a
-VESA video timing). The audio_supported function is intended to query whether
-the current configuration of the display supports audio.
-
-The audio_config function is intended to configure all the relevant audio
-parameters of the display. In order to make the function independent of any
-specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
-is to contain all the required parameters for audio configuration. At the
-moment, such structure contains pointers to IEC-60958 channel status word
-and CEA-861 audio infoframe structures. This should be enough to support
-HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
-
-The audio_enable/disable, audio_config and audio_supported functions could be
-implemented as functions that may sleep. Hence, they should not be called
-while holding a spinlock or a readlock.
-
-The audio_start/audio_stop function is intended to effectively start/stop audio
-playback after the configuration has taken place. These functions are designed
-to be used in an atomic context. Hence, audio_start should return quickly and be
-called only after all the needed resources for audio playback (audio FIFOs,
-DMA channels, companion chips, etc) have been enabled to begin data transfers.
-audio_stop is designed to only stop the audio transfers. The resources used
-for playback are released using audio_disable.
-
-The enum omap_dss_audio_state may be used to help the implementations of
-the interface to keep track of the audio state. The initial state is _DISABLED;
-then, the state transitions to _CONFIGURED, and then, when it is ready to
-play audio, to _ENABLED. The state _PLAYING is used when the audio is being
-rendered.
-
-
 Panel and controller drivers
 ----------------------------
 
@@ -201,7 +156,6 @@ timings		Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
 		"pal" and "ntsc"
 panel_name
 tear_elim	Tearing elimination 0=off, 1=on
-output_type	Output type (video encoder only): "composite" or "svideo"
 
 There are also some debugfs files at <debugfs>/omapdss/ which show information
 about clocks and registers.

trunk/Documentation/device-mapper/thin-provisioning.txt

@@ -287,17 +287,6 @@ iii) Messages
 	the current transaction id is when you change it with this
 	compare-and-swap message.
 
-    reserve_metadata_snap
-
-        Reserve a copy of the data mapping btree for use by userland.
-        This allows userland to inspect the mappings as they were when
-        this message was executed.  Use the pool's status command to
-        get the root block associated with the metadata snapshot.
-
-    release_metadata_snap
-
-        Release a previously reserved copy of the data mapping btree.
-
 'thin' target
 -------------