---

yaml --- r: 360527 b: refs/heads/master c: 6cae06e h: refs/heads/master i: 360525: 89d84a9 360523: 9a6aa5f 360519: 4291c0a 360511: 42de1c3 v: v3
git-mirror · Feb 24, 2013 · 10c4140 · 10c4140
1 parent cd40467
commit 10c4140
Show file tree

Hide file tree

Showing 4,231 changed files with 70,868 additions and 176,092 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: a7c1120d2dcc83691bafa034d98f70285757e826
+refs/heads/master: 6cae06e603339f99334bc6b276e2ac619cf0d476
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/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/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/DocBook/media/dvb/dvbapi.xml b/trunk/Documentation/DocBook/media/dvb/dvbapi.xml
@@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
 
 
 <title>LINUX DVB API</title>
-<subtitle>Version 5.10</subtitle>
+<subtitle>Version 5.8</subtitle>
 <!-- ADD THE CHAPTERS HERE -->
   <chapter id="dvb_introdution">
     &sub-intro;