---

yaml
---
r: 201537
b: refs/heads/master
c: cb86ae9
h: refs/heads/master
i:
  201535: a33193c
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 23f5cace4f858ddf40eb0ee77b984d329fd23518
+refs/heads/master: cb86ae95a0168be2acc6c48b1671ffaba1e5e39e

trunk/.gitignore

@@ -28,6 +28,7 @@ modules.builtin
 *.gz
 *.bz2
 *.lzma
+*.lzo
 *.patch
 *.gcno
 

trunk/Documentation/.gitignore

@@ -0,0 +1,7 @@
+filesystems/dnotify_test
+laptops/dslm
+timers/hpet_example
+vm/hugepage-mmap
+vm/hugepage-shm
+vm/map_hugetlb
+

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

@@ -133,46 +133,6 @@ Description:
 		The symbolic link points to the PCI device sysfs entry of the
 		Physical Function this device associates with.
 
-
-What:		/sys/bus/pci/slots/...
-Date:		April 2005 (possibly older)
-KernelVersion:	2.6.12 (possibly older)
-Contact:	linux-pci@vger.kernel.org
-Description:
-		When the appropriate driver is loaded, it will create a
-		directory per claimed physical PCI slot in
-		/sys/bus/pci/slots/.  The names of these directories are
-		specific to the driver, which in turn, are specific to the
-		platform, but in general, should match the label on the
-		machine's physical chassis.
-
-		The drivers that can create slot directories include the
-		PCI hotplug drivers, and as of 2.6.27, the pci_slot driver.
-
-		The slot directories contain, at a minimum, a file named
-		'address' which contains the PCI bus:device:function tuple.
-		Other files may appear as well, but are specific to the
-		driver.
-
-What:		/sys/bus/pci/slots/.../function[0-7]
-Date:		March 2010
-KernelVersion:	2.6.35
-Contact:	linux-pci@vger.kernel.org
-Description:
-		If PCI slot directories (as described above) are created,
-		and the physical slot is actually populated with a device,
-		symbolic links in the slot directory pointing to the
-		device's PCI functions are created as well.
-
-What:		/sys/bus/pci/devices/.../slot
-Date:		March 2010
-KernelVersion:	2.6.35
-Contact:	linux-pci@vger.kernel.org
-Description:
-		If PCI slot directories (as described above) are created,
-		a symbolic link pointing to the slot directory will be
-		created as well.
-
 What:		/sys/bus/pci/slots/.../module
 Date:		June 2009
 Contact:	linux-pci@vger.kernel.org

trunk/Documentation/DocBook/drm.tmpl

@@ -389,7 +389,7 @@
       </para>
       <para>
 	If your driver supports memory management (it should!), you'll
-	need to set that up at load time as well.  How you intialize
+	need to set that up at load time as well.  How you initialize
 	it depends on which memory manager you're using, TTM or GEM.
       </para>
       <sect3>
@@ -399,7 +399,7 @@
 	  aperture space for graphics devices. TTM supports both UMA devices
 	  and devices with dedicated video RAM (VRAM), i.e. most discrete
 	  graphics devices.  If your device has dedicated RAM, supporting
-	  TTM is desireable.  TTM also integrates tightly with your
+	  TTM is desirable.  TTM also integrates tightly with your
 	  driver specific buffer execution function.  See the radeon
 	  driver for examples.
 	</para>
@@ -443,7 +443,7 @@
 	  likely eventually calling ttm_bo_global_init and
 	  ttm_bo_global_release, respectively.  Also like the previous
 	  object, ttm_global_item_ref is used to create an initial reference
-	  count for the TTM, which will call your initalization function.
+	  count for the TTM, which will call your initialization function.
 	</para>
       </sect3>
       <sect3>
@@ -557,7 +557,7 @@ void intel_crt_init(struct drm_device *dev)
 	  CRT connector and encoder combination is created.  A device
 	  specific i2c bus is also created, for fetching EDID data and
 	  performing monitor detection.  Once the process is complete,
-	  the new connector is regsitered with sysfs, to make its
+	  the new connector is registered with sysfs, to make its
 	  properties available to applications.
 	</para>
 	<sect4>
@@ -581,12 +581,12 @@ void intel_crt_init(struct drm_device *dev)
 	<para>
 	  For each encoder, CRTC and connector, several functions must
 	  be provided, depending on the object type.  Encoder objects
-	  need should provide a DPMS (basically on/off) function, mode fixup
+	  need to provide a DPMS (basically on/off) function, mode fixup
 	  (for converting requested modes into native hardware timings),
 	  and prepare, set and commit functions for use by the core DRM
 	  helper functions.  Connector helpers need to provide mode fetch and
 	  validity functions as well as an encoder matching function for
-	  returing an ideal encoder for a given connector.  The core
+	  returning an ideal encoder for a given connector.  The core
 	  connector functions include a DPMS callback, (deprecated)
 	  save/restore routines, detection, mode probing, property handling,
 	  and cleanup functions.

trunk/Documentation/DocBook/v4l/v4l2.xml

@@ -58,7 +58,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
 </contrib>
 	<affiliation>
 	  <address>
-	    <email>awalls@radix.net</email>
+	    <email>awalls@md.metrocast.net</email>
 	  </address>
 	</affiliation>
       </author>

trunk/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml

@@ -53,8 +53,10 @@ input</refpurpose>
 automatically, similar to sensing the video standard. To do so, applications
 call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
 &v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
-returned in the preset field of &v4l2-dv-preset;. When detection is not
-possible or fails, the value V4L2_DV_INVALID is returned.</para>
+returned in the preset field of &v4l2-dv-preset;. If the preset could not be
+detected because there was no signal, or the signal was unreliable, or the
+signal did not map to a supported preset, then the value V4L2_DV_INVALID is
+returned.</para>
   </refsect1>
 
   <refsect1>

trunk/Documentation/acpi/apei/einj.txt

@@ -0,0 +1,59 @@
+			APEI Error INJection
+			~~~~~~~~~~~~~~~~~~~~
+
+EINJ provides a hardware error injection mechanism
+It is very useful for debugging and testing of other APEI and RAS features.
+
+To use EINJ, make sure the following are enabled in your kernel
+configuration:
+
+CONFIG_DEBUG_FS
+CONFIG_ACPI_APEI
+CONFIG_ACPI_APEI_EINJ
+
+The user interface of EINJ is debug file system, under the
+directory apei/einj. The following files are provided.
+
+- available_error_type
+  Reading this file returns the error injection capability of the
+  platform, that is, which error types are supported. The error type
+  definition is as follow, the left field is the error type value, the
+  right field is error description.
+
+    0x00000001	Processor Correctable
+    0x00000002	Processor Uncorrectable non-fatal
+    0x00000004	Processor Uncorrectable fatal
+    0x00000008  Memory Correctable
+    0x00000010  Memory Uncorrectable non-fatal
+    0x00000020  Memory Uncorrectable fatal
+    0x00000040	PCI Express Correctable
+    0x00000080	PCI Express Uncorrectable fatal
+    0x00000100	PCI Express Uncorrectable non-fatal
+    0x00000200	Platform Correctable
+    0x00000400	Platform Uncorrectable non-fatal
+    0x00000800	Platform Uncorrectable fatal
+
+  The format of file contents are as above, except there are only the
+  available error type lines.
+
+- error_type
+  This file is used to set the error type value. The error type value
+  is defined in "available_error_type" description.
+
+- error_inject
+  Write any integer to this file to trigger the error
+  injection. Before this, please specify all necessary error
+  parameters.
+
+- param1
+  This file is used to set the first error parameter value. Effect of
+  parameter depends on error_type specified. For memory error, this is
+  physical memory address.
+
+- param2
+  This file is used to set the second error parameter value. Effect of
+  parameter depends on error_type specified. For memory error, this is
+  physical memory address mask.
+
+For more information about EINJ, please refer to ACPI specification
+version 4.0, section 17.5.

trunk/Documentation/arm/Samsung-S3C24XX/GPIO.txt

@@ -12,6 +12,8 @@ Introduction
   of the s3c2410 GPIO system, please read the Samsung provided
   data-sheet/users manual to find out the complete list.
 
+  See Documentation/arm/Samsung/GPIO.txt for the core implemetation.
+
 
 GPIOLIB
 -------
@@ -24,8 +26,60 @@ GPIOLIB
   listed below will be removed (they may be marked as __deprecated
   in the near future).
 
-  - s3c2410_gpio_getpin
-  - s3c2410_gpio_setpin
+  The following functions now either have a s3c_ specific variant
+  or are merged into gpiolib. See the definitions in
+  arch/arm/plat-samsung/include/plat/gpio-cfg.h:
+
+  s3c2410_gpio_setpin()		gpio_set_value() or gpio_direction_output()
+  s3c2410_gpio_getpin()		gpio_get_value() or gpio_direction_input()
+  s3c2410_gpio_getirq()		gpio_to_irq()
+  s3c2410_gpio_cfgpin()		s3c_gpio_cfgpin()
+  s3c2410_gpio_getcfg()		s3c_gpio_getcfg()
+  s3c2410_gpio_pullup()		s3c_gpio_setpull()
+
+
+GPIOLIB conversion
+------------------
+
+If you need to convert your board or driver to use gpiolib from the exiting
+s3c2410 api, then here are some notes on the process.
+
+1) If your board is exclusively using an GPIO, say to control peripheral
+   power, then it will require to claim the gpio with gpio_request() before
+   it can use it.
+
+   It is recommended to check the return value, with at least WARN_ON()
+   during initialisation.
+
+2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()
+   as they have the same arguments, and can either take the pin specific
+   values, or the more generic special-function-number arguments.
+
+3) s3c2410_gpio_pullup() changs have the problem that whilst the 
+   s3c2410_gpio_pullup(x, 1) can be easily translated to the
+   s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
+   are not so easy.
+
+   The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case
+   of some of the devices, a pull-down) and as such the new API distinguishes
+   between the UP and DOWN case. There is currently no 'just turn on' setting
+   which may be required if this becomes a problem.
+
+4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call
+   does not implicitly configure the relevant gpio to output. The gpio
+   direction should be changed before using gpio_set_value().
+
+5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin
+   has been set to input. It is currently unknown what the behaviour is
+   when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
+   would return the value the pin is supposed to be outputting).
+
+6) s3c2410_gpio_getirq() should be directly replacable with the
+   gpio_to_irq() call.
+
+The s3c2410_gpio and gpio_ calls have always operated on the same gpio
+numberspace, so there is no problem with converting the gpio numbering
+between the calls.
 
 
 Headers
@@ -54,6 +108,11 @@ PIN Numbers
   eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
   the GPIO functions which pin is to be used.
 
+  With the conversion to gpiolib, there is no longer a direct conversion
+  from gpio pin number to register base address as in earlier kernels. This
+  is due to the number space required for newer SoCs where the later
+  GPIOs are not contiguous.
+
 
 Configuring a pin
 -----------------
@@ -71,6 +130,8 @@ Configuring a pin
    which would turn GPA(0) into the lowest Address line A0, and set
    GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
 
+   The s3c_gpio_cfgpin() call is a functional replacement for this call.
+
 
 Reading the current configuration
 ---------------------------------
@@ -82,6 +143,9 @@ Reading the current configuration
   The return value will be from the same set of values which can be
   passed to s3c2410_gpio_cfgpin().
 
+  The s3c_gpio_getcfg() call should be a functional replacement for
+  this call.
+
 
 Configuring a pull-up resistor
 ------------------------------
@@ -95,6 +159,10 @@ Configuring a pull-up resistor
   Where the to value is zero to set the pull-up off, and 1 to enable
   the specified pull-up. Any other values are currently undefined.
 
+  The s3c_gpio_setpull() offers similar functionality, but with the
+  ability to encode whether the pull is up or down. Currently there
+  is no 'just on' state, so up or down must be selected.
+
 
 Getting the state of a PIN
 --------------------------
@@ -106,6 +174,9 @@ Getting the state of a PIN
   This will return either zero or non-zero. Do not count on this
   function returning 1 if the pin is set.
 
+  This call is now implemented by the relevant gpiolib calls, convert
+  your board or driver to use gpiolib.
+
 
 Setting the state of a PIN
 --------------------------
@@ -117,6 +188,9 @@ Setting the state of a PIN
   Which sets the given pin to the value. Use 0 to write 0, and 1 to
   set the output to 1.
 
+  This call is now implemented by the relevant gpiolib calls, convert
+  your board or driver to use gpiolib.
+
 
 Getting the IRQ number associated with a PIN
 --------------------------------------------
@@ -128,6 +202,9 @@ Getting the IRQ number associated with a PIN
 
   Note, not all pins have an IRQ.
 
+  This call is now implemented by the relevant gpiolib calls, convert
+  your board or driver to use gpiolib.
+
 
 Authour
 -------

trunk/Documentation/arm/Samsung-S3C24XX/Overview.txt

@@ -8,10 +8,16 @@ Introduction
 
   The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
   by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
-  S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
+  S3C2412, S3C2413, S3C2416 S3C2440, S3C2442, S3C2443 and S3C2450 devices
+  are supported.
 
   Support for the S3C2400 and S3C24A0 series are in progress.
 
+  The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
+  included under the arch/arm/mach-s3c2416 directory. Note, whilst core
+  support for these SoCs is in, work on some of the extra peripherals
+  and extra interrupts is still ongoing.
+
 
 Configuration
 -------------
@@ -209,6 +215,13 @@ GPIO
   Newer kernels carry GPIOLIB, and support is being moved towards
   this with some of the older support in line to be removed.
 
+  As of v2.6.34, the move towards using gpiolib support is almost
+  complete, and very little of the old calls are left.
+
+  See Documentation/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific
+  support and Documentation/arm/Samsung/GPIO.txt for the core Samsung
+  implementation.
+
 
 Clock Management
 ----------------