---

yaml --- r: 362718 b: refs/heads/master c: 72a763d h: refs/heads/master v: v3
git-mirror · Apr 10, 2013 · 42e1f75 · 42e1f75
1 parent c466ff8
commit 42e1f75
Show file tree

Hide file tree

Showing 4,820 changed files with 66,412 additions and 176,747 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 60d509fa6a9c4653a86ad830e4c4b30360b23f0e
+refs/heads/master: 72a763d805a48ac8c0bf48fdb510e84c12de51fe
diff --git a/trunk/CREDITS b/trunk/CREDITS
@@ -953,11 +953,11 @@ S: Blacksburg, Virginia 24061
 S: USA
 
 N: Randy Dunlap
-E: rdunlap@infradead.org
-W: http://www.infradead.org/~rdunlap/
+E: rdunlap@xenotime.net
+W: http://www.xenotime.net/linux/linux.html
+W: http://www.linux-usb.org
 D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
 D: x86 SMP, ACPI, bootflag hacking
-D: documentation, builds
 S: (ask for current address)
 S: USA
 
@@ -1510,14 +1510,6 @@ D: Natsemi ethernet
 D: Cobalt Networks (x86) support
 D: This-and-That
 
-N: Mark M. Hoffman
-E: mhoffman@lightlink.com
-D: asb100, lm93 and smsc47b397 hardware monitoring drivers
-D: hwmon subsystem core
-D: hwmon subsystem maintainer
-D: i2c-sis96x and i2c-stub SMBus drivers
-S: USA
-
 N: Dirk Hohndel
 E: hohndel@suse.de
 D: The XFree86[tm] Project

diff --git a/trunk/Documentation/00-INDEX b/trunk/Documentation/00-INDEX
@@ -299,8 +299,6 @@ memory-hotplug.txt
 	- Hotpluggable memory support, how to use and current status.
 memory.txt
 	- info on typical Linux memory problems.
-metag/
-	- directory with info about Linux on Meta architecture.
 mips/
 	- directory with info about Linux on MIPS architecture.
 misc-devices/

diff --git a/trunk/Documentation/ABI/testing/sysfs-bus-fcoe b/trunk/Documentation/ABI/testing/sysfs-bus-fcoe
@@ -1,53 +1,14 @@
-What:		/sys/bus/fcoe/
-Date:		August 2012
-KernelVersion:	TBD
-Contact:	Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
-Description:	The FCoE bus. Attributes in this directory are control interfaces.
-Attributes:
-
-	ctlr_create: 'FCoE Controller' instance creation interface. Writing an
-		     <ifname> to this file will allocate and populate sysfs with a
-		     fcoe_ctlr_device (ctlr_X). The user can then configure any
-		     per-port settings and finally write to the fcoe_ctlr_device's
-		     'start' attribute to begin the kernel's discovery and login
-		     process.
-
-	ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
-		       fcoe_ctlr_device's sysfs name to this file will log the
-		       fcoe_ctlr_device out of the fabric or otherwise connected
-		       FCoE devices. It will also free all kernel memory allocated
-		       for this fcoe_ctlr_device and any structures associated
-		       with it, this includes the scsi_host.
-
-What:		/sys/bus/fcoe/devices/ctlr_X
+What:		/sys/bus/fcoe/ctlr_X
 Date:		March 2012
 KernelVersion:	TBD
 Contact:	Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
-Description:	'FCoE Controller' instances on the fcoe bus.
-		The FCoE Controller now has a three stage creation process.
-		1) Write interface name to ctlr_create 2) Configure the FCoE
-		Controller (ctlr_X) 3) Enable the FCoE Controller to begin
-		discovery and login. The FCoE Controller is destroyed by
-		writing it's name, i.e. ctlr_X to the ctlr_delete file.
-
+Description:	'FCoE Controller' instances on the fcoe bus
 Attributes:
 
 	fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
 			  this value will change the dev_loss_tmo for all
 			  FCFs discovered by this controller.
 
-	mode:		  Display or change the FCoE Controller's mode. Possible
-			  modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
-			  is started in 'Fabric' mode then FIP FCF discovery is
-			  initiated and ultimately a fabric login is attempted.
-			  If a FCoE Controller is started in 'VN2VN' mode then
-			  FIP VN2VN discovery and login is performed. A FCoE
-			  Controller only supports one mode at a time.
-
-	enabled:	  Whether an FCoE controller is enabled or disabled.
-			  0 if disabled, 1 if enabled. Writing either 0 or 1
-			  to this file will enable or disable the FCoE controller.
-
 	lesb/link_fail:   Link Error Status Block (LESB) link failure count.
 
 	lesb/vlink_fail:  Link Error Status Block (LESB) virtual link
@@ -65,7 +26,7 @@ Attributes:
 
 Notes: ctlr_X (global increment starting at 0)
 
-What:		/sys/bus/fcoe/devices/fcf_X
+What:		/sys/bus/fcoe/fcf_X
 Date:		March 2012
 KernelVersion:	TBD
 Contact:	Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org

diff --git a/trunk/Documentation/ABI/testing/sysfs-platform-msi-laptop b/trunk/Documentation/ABI/testing/sysfs-platform-msi-laptop
diff --git a/trunk/Documentation/DMA-API-HOWTO.txt b/trunk/Documentation/DMA-API-HOWTO.txt
@@ -488,10 +488,9 @@ will invoke the generic mapping error check interface. Doing so will ensure
 that the mapping code will work correctly on all dma implementations without
 any dependency on the specifics of the underlying implementation. Using the
 returned address without checking for errors could result in failures ranging
-from panics to silent data corruption. A couple of examples of incorrect ways
-to check for errors that make assumptions about the underlying dma
-implementation are as follows and these are applicable to dma_map_page() as
-well.
+from panics to silent data corruption. Couple of example of incorrect ways to
+check for errors that make assumptions about the underlying dma implementation
+are as follows and these are applicable to dma_map_page() as well.
 
 Incorrect example 1:
 	dma_addr_t dma_handle;
@@ -752,7 +751,7 @@ Example 1:
 		dma_unmap_single(dma_handle1);
 	map_error_handling1:
 
-Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
+Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
 	    mapping error is detected in the middle)
 
 	dma_addr_t dma_addr;

diff --git a/trunk/Documentation/DocBook/device-drivers.tmpl b/trunk/Documentation/DocBook/device-drivers.tmpl
@@ -227,7 +227,7 @@ X!Isound/sound_firmware.c
   <chapter id="uart16x50">
      <title>16x50 UART Driver</title>
 !Edrivers/tty/serial/serial_core.c
-!Edrivers/tty/serial/8250/8250_core.c
+!Edrivers/tty/serial/8250/8250.c
   </chapter>
 
   <chapter id="fbdev">

diff --git a/trunk/Documentation/DocBook/drm.tmpl b/trunk/Documentation/DocBook/drm.tmpl
@@ -743,10 +743,6 @@ char *date;</synopsis>
           These two operations are mandatory for GEM drivers that support DRM
           PRIME.
         </para>
-        <sect4>
-          <title>DRM PRIME Helper Functions Reference</title>
-!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
-        </sect4>
       </sect3>
       <sect3 id="drm-gem-objects-mapping">
         <title>GEM Objects Mapping</title>
@@ -982,25 +978,10 @@ int max_width, max_height;</synopsis>
         If the parameters are deemed valid, drivers then create, initialize and
         return an instance of struct <structname>drm_framebuffer</structname>.
         If desired the instance can be embedded in a larger driver-specific
-	structure. Drivers must fill its <structfield>width</structfield>,
-	<structfield>height</structfield>, <structfield>pitches</structfield>,
-        <structfield>offsets</structfield>, <structfield>depth</structfield>,
-        <structfield>bits_per_pixel</structfield> and
-        <structfield>pixel_format</structfield> fields from the values passed
-        through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
-        should call the <function>drm_helper_mode_fill_fb_struct</function>
-        helper function to do so.
-      </para>
-
-      <para>
-	The initailization of the new framebuffer instance is finalized with a
-	call to <function>drm_framebuffer_init</function> which takes a pointer
-	to DRM frame buffer operations (struct
-	<structname>drm_framebuffer_funcs</structname>). Note that this function
-	publishes the framebuffer and so from this point on it can be accessed
-	concurrently from other threads. Hence it must be the last step in the
-	driver's framebuffer initialization sequence. Frame buffer operations
-	are
+        structure. The new instance is initialized with a call to
+        <function>drm_framebuffer_init</function> which takes a pointer to DRM
+        frame buffer operations (struct
+        <structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
         <itemizedlist>
           <listitem>
             <synopsis>int (*create_handle)(struct drm_framebuffer *fb,
@@ -1041,16 +1022,16 @@ int max_width, max_height;</synopsis>
         </itemizedlist>
       </para>
       <para>
-	The lifetime of a drm framebuffer is controlled with a reference count,
-	drivers can grab additional references with
-	<function>drm_framebuffer_reference</function> </para> and drop them
-	again with <function>drm_framebuffer_unreference</function>. For
-	driver-private framebuffers for which the last reference is never
-	dropped (e.g. for the fbdev framebuffer when the struct
-	<structname>drm_framebuffer</structname> is embedded into the fbdev
-	helper struct) drivers can manually clean up a framebuffer at module
-	unload time with
-	<function>drm_framebuffer_unregister_private</function>.
+        After initializing the <structname>drm_framebuffer</structname>
+        instance drivers must fill its <structfield>width</structfield>,
+        <structfield>height</structfield>, <structfield>pitches</structfield>,
+        <structfield>offsets</structfield>, <structfield>depth</structfield>,
+        <structfield>bits_per_pixel</structfield> and
+        <structfield>pixel_format</structfield> fields from the values passed
+        through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
+        should call the <function>drm_helper_mode_fill_fb_struct</function>
+        helper function to do so.
+      </para>
     </sect2>
     <sect2>
       <title>Output Polling</title>
@@ -1062,22 +1043,6 @@ int max_width, max_height;</synopsis>
         operation.
       </para>
     </sect2>
-    <sect2>
-      <title>Locking</title>
-      <para>
-        Beside some lookup structures with their own locking (which is hidden
-	behind the interface functions) most of the modeset state is protected
-	by the <code>dev-&lt;mode_config.lock</code> mutex and additionally
-	per-crtc locks to allow cursor updates, pageflips and similar operations
-	to occur concurrently with background tasks like output detection.
-	Operations which cross domains like a full modeset always grab all
-	locks. Drivers there need to protect resources shared between crtcs with
-	additional locking. They also need to be careful to always grab the
-	relevant crtc locks if a modset functions touches crtc state, e.g. for
-	load detection (which does only grab the <code>mode_config.lock</code>
-	to allow concurrent screen updates on live crtcs).
-      </para>
-    </sect2>
   </sect1>
 
   <!-- Internals: kms initialization and cleanup -->
@@ -1160,12 +1125,6 @@ int max_width, max_height;</synopsis>
             without waiting for rendering or page flip to complete and must block
             any new rendering to the frame buffer until the page flip completes.
           </para>
-          <para>
-            If a page flip can be successfully scheduled the driver must set the
-            <code>drm_crtc-&lt;fb</code> field to the new framebuffer pointed to
-            by <code>fb</code>. This is important so that the reference counting
-            on framebuffers stays balanced.
-          </para>
           <para>
             If a page flip is already pending, the
             <methodname>page_flip</methodname> operation must return
@@ -1650,10 +1609,6 @@ void intel_crt_init(struct drm_device *dev)
         make its properties available to applications.
       </para>
     </sect2>
-    <sect2>
-      <title>KMS API Functions</title>
-!Edrivers/gpu/drm/drm_crtc.c
-    </sect2>
   </sect1>
 
   <!-- Internals: kms helper functions -->
@@ -2149,18 +2104,13 @@ void intel_crt_init(struct drm_device *dev)
       <title>fbdev Helper Functions Reference</title>
 !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
 !Edrivers/gpu/drm/drm_fb_helper.c
-!Iinclude/drm/drm_fb_helper.h
     </sect2>
     <sect2>
       <title>Display Port Helper Functions Reference</title>
 !Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
 !Iinclude/drm/drm_dp_helper.h
 !Edrivers/gpu/drm/drm_dp_helper.c
     </sect2>
-    <sect2>
-      <title>EDID Helper Functions Reference</title>
-!Edrivers/gpu/drm/drm_edid.c
-    </sect2>
   </sect1>
 
   <!-- Internals: vertical blanking -->

diff --git a/trunk/Documentation/EDID/HOWTO.txt b/trunk/Documentation/EDID/HOWTO.txt
@@ -28,30 +28,11 @@ Makefile environment are given here.
 To create binary EDID and C source code files from the existing data
 material, simply type "make".
 
-If you want to create your own EDID file, copy the file 1024x768.S,
-replace the settings with your own data and add a new target to the
-Makefile. Please note that the EDID data structure expects the timing
-values in a different way as compared to the standard X11 format.
-
-X11:
-HTimings:  hdisp hsyncstart hsyncend htotal
-VTimings:  vdisp vsyncstart vsyncend vtotal
-
-EDID:
-#define XPIX hdisp
-#define XBLANK htotal-hdisp
-#define XOFFSET hsyncstart-hdisp
-#define XPULSE hsyncend-hsyncstart
-
-#define YPIX vdisp
-#define YBLANK vtotal-vdisp
-#define YOFFSET (63+(vsyncstart-vdisp))
-#define YPULSE (63+(vsyncend-vsyncstart))
-
-The CRC value in the last line
+If you want to create your own EDID file, copy the file 1024x768.S and
+replace the settings with your own data. The CRC value in the last line
   #define CRC 0x55
-also is a bit tricky. After a first version of the binary data set is
-created, it must be checked with the "edid-decode" utility which will
+is a bit tricky. After a first version of the binary data set is
+created, it must be be checked with the "edid-decode" utility which will
 most probably complain about a wrong CRC. Fortunately, the utility also
 displays the correct CRC which must then be inserted into the source
 file. After the make procedure is repeated, the EDID data set is ready