---

yaml
---
r: 187879
b: refs/heads/master
c: c13f3d3
h: refs/heads/master
i:
  187877: 83baf51
  187875: 2eb2289
  187871: f5ebde9
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 90a6501f94aedd7fb40f5556334843194fb598be
+refs/heads/master: c13f3d378f77ce3176628ade452b0e461242faf3

trunk/Documentation/ABI/testing/sysfs-power

@@ -101,16 +101,3 @@ Description:
 
 		CAUTION: Using it will cause your machine's real-time (CMOS)
 		clock to be set to a random invalid time after a resume.
-
-What:		/sys/power/pm_async
-Date:		January 2009
-Contact:	Rafael J. Wysocki <rjw@sisk.pl>
-Description:
-		The /sys/power/pm_async file controls the switch allowing the
-		user space to enable or disable asynchronous suspend and resume
-		of devices.  If enabled, this feature will cause some device
-		drivers' suspend and resume callbacks to be executed in parallel
-		with each other and with the main suspend thread.  It is enabled
-		if this file contains "1", which is the default.  It may be
-		disabled by writing "0" to this file, in which case all devices
-		will be suspended and resumed synchronously.

trunk/Documentation/DocBook/v4l/io.xml

@@ -589,8 +589,7 @@ number of a video input as in &v4l2-input; field
 	    <entry></entry>
 	    <entry>A place holder for future extensions and custom
 (driver defined) buffer types
-<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
-should set this to 0.</entry>
+<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry>
 	  </row>
 	</tbody>
       </tgroup>

trunk/Documentation/DocBook/v4l/vidioc-qbuf.xml

@@ -54,10 +54,12 @@ to enqueue an empty (capturing) or filled (output) buffer in the
 driver's incoming queue. The semantics depend on the selected I/O
 method.</para>
 
-    <para>To enqueue a buffer applications set the <structfield>type</structfield>
-field of a &v4l2-buffer; to the same buffer type as was previously used
-with &v4l2-format; <structfield>type</structfield> and &v4l2-requestbuffers;
-<structfield>type</structfield>. Applications must also set the
+    <para>To enqueue a <link linkend="mmap">memory mapped</link>
+buffer applications set the <structfield>type</structfield> field of a
+&v4l2-buffer; to the same buffer type as previously &v4l2-format;
+<structfield>type</structfield> and &v4l2-requestbuffers;
+<structfield>type</structfield>, the <structfield>memory</structfield>
+field to <constant>V4L2_MEMORY_MMAP</constant> and the
 <structfield>index</structfield> field. Valid index numbers range from
 zero to the number of buffers allocated with &VIDIOC-REQBUFS;
 (&v4l2-requestbuffers; <structfield>count</structfield>) minus one. The
@@ -68,19 +70,8 @@ intended for output (<structfield>type</structfield> is
 <constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>) applications must also
 initialize the <structfield>bytesused</structfield>,
 <structfield>field</structfield> and
-<structfield>timestamp</structfield> fields, see <xref
-linkend="buffer" /> for details.
-Applications must also set <structfield>flags</structfield> to 0. If a driver
-supports capturing from specific video inputs and you want to specify a video
-input, then <structfield>flags</structfield> should be set to
-<constant>V4L2_BUF_FLAG_INPUT</constant> and the field
-<structfield>input</structfield> must be initialized to the desired input.
-The <structfield>reserved</structfield> field must be set to 0.
-</para>
-
-    <para>To enqueue a <link linkend="mmap">memory mapped</link>
-buffer applications set the <structfield>memory</structfield>
-field to <constant>V4L2_MEMORY_MMAP</constant>. When
+<structfield>timestamp</structfield> fields. See <xref
+	linkend="buffer" /> for details. When
 <constant>VIDIOC_QBUF</constant> is called with a pointer to this
 structure the driver sets the
 <constant>V4L2_BUF_FLAG_MAPPED</constant> and
@@ -90,25 +81,28 @@ structure the driver sets the
 &EINVAL;.</para>
 
     <para>To enqueue a <link linkend="userp">user pointer</link>
-buffer applications set the <structfield>memory</structfield>
-field to <constant>V4L2_MEMORY_USERPTR</constant>, the
+buffer applications set the <structfield>type</structfield> field of a
+&v4l2-buffer; to the same buffer type as previously &v4l2-format;
+<structfield>type</structfield> and &v4l2-requestbuffers;
+<structfield>type</structfield>, the <structfield>memory</structfield>
+field to <constant>V4L2_MEMORY_USERPTR</constant> and the
 <structfield>m.userptr</structfield> field to the address of the
-buffer and <structfield>length</structfield> to its size.
+buffer and <structfield>length</structfield> to its size. When the
+buffer is intended for output additional fields must be set as above.
 When <constant>VIDIOC_QBUF</constant> is called with a pointer to this
 structure the driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant>
 flag and clears the <constant>V4L2_BUF_FLAG_MAPPED</constant> and
 <constant>V4L2_BUF_FLAG_DONE</constant> flags in the
 <structfield>flags</structfield> field, or it returns an error code.
 This ioctl locks the memory pages of the buffer in physical memory,
 they cannot be swapped out to disk. Buffers remain locked until
-dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is
+dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl are
 called, or until the device is closed.</para>
 
     <para>Applications call the <constant>VIDIOC_DQBUF</constant>
 ioctl to dequeue a filled (capturing) or displayed (output) buffer
 from the driver's outgoing queue. They just set the
-<structfield>type</structfield>, <structfield>memory</structfield>
-and <structfield>reserved</structfield>
+<structfield>type</structfield> and <structfield>memory</structfield>
 fields of a &v4l2-buffer; as above, when <constant>VIDIOC_DQBUF</constant>
 is called with a pointer to this structure the driver fills the
 remaining fields or returns an error code.</para>

trunk/Documentation/DocBook/v4l/vidioc-querybuf.xml

@@ -54,13 +54,12 @@ buffer at any time after buffers have been allocated with the
 &VIDIOC-REQBUFS; ioctl.</para>
 
     <para>Applications set the <structfield>type</structfield> field
-    of a &v4l2-buffer; to the same buffer type as was previously used with
+    of a &v4l2-buffer; to the same buffer type as previously
 &v4l2-format; <structfield>type</structfield> and &v4l2-requestbuffers;
 <structfield>type</structfield>, and the <structfield>index</structfield>
     field. Valid index numbers range from zero
 to the number of buffers allocated with &VIDIOC-REQBUFS;
     (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.
-The <structfield>reserved</structfield> field should to set to 0.
 After calling <constant>VIDIOC_QUERYBUF</constant> with a pointer to
     this structure drivers return an error code or fill the rest of
 the structure.</para>
@@ -69,8 +68,8 @@ the structure.</para>
 <constant>V4L2_BUF_FLAG_MAPPED</constant>,
 <constant>V4L2_BUF_FLAG_QUEUED</constant> and
 <constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The
-<structfield>memory</structfield> field will be set to the current
-I/O method, the <structfield>m.offset</structfield>
+<structfield>memory</structfield> field will be set to
+<constant>V4L2_MEMORY_MMAP</constant>, the <structfield>m.offset</structfield>
 contains the offset of the buffer from the start of the device memory,
 the <structfield>length</structfield> field its size. The driver may
 or may not set the remaining fields and flags, they are meaningless in

trunk/Documentation/DocBook/v4l/vidioc-reqbufs.xml

@@ -54,23 +54,23 @@ I/O. Memory mapped buffers are located in device memory and must be
 allocated with this ioctl before they can be mapped into the
 application's address space. User buffers are allocated by
 applications themselves, and this ioctl is merely used to switch the
-driver into user pointer I/O mode and to setup some internal structures.</para>
+driver into user pointer I/O mode.</para>
 
-    <para>To allocate device buffers applications initialize all
-fields of the <structname>v4l2_requestbuffers</structname> structure.
+    <para>To allocate device buffers applications initialize three
+fields of a <structname>v4l2_requestbuffers</structname> structure.
 They set the <structfield>type</structfield> field to the respective
 stream or buffer type, the <structfield>count</structfield> field to
-the desired number of buffers, <structfield>memory</structfield>
-must be set to the requested I/O method and the reserved array
-must be zeroed. When the ioctl
-is called with a pointer to this structure the driver will attempt to allocate
-the requested number of buffers and it stores the actual number
+the desired number of buffers, and <structfield>memory</structfield>
+must be set to <constant>V4L2_MEMORY_MMAP</constant>. When the ioctl
+is called with a pointer to this structure the driver attempts to
+allocate the requested number of buffers and stores the actual number
 allocated in the <structfield>count</structfield> field. It can be
 smaller than the number requested, even zero, when the driver runs out
-of free memory. A larger number is also possible when the driver requires
-more buffers to function correctly. For example video output requires at least two buffers,
+of free memory. A larger number is possible when the driver requires
+more buffers to function correctly.<footnote>
+	<para>For example video output requires at least two buffers,
 one displayed and one filled by the application.</para>
-    <para>When the I/O method is not supported the ioctl
+	</footnote> When memory mapping I/O is not supported the ioctl
 returns an &EINVAL;.</para>
 
     <para>Applications can call <constant>VIDIOC_REQBUFS</constant>
@@ -81,6 +81,14 @@ in progress, an implicit &VIDIOC-STREAMOFF;. <!-- mhs: I see no
 reason why munmap()ping one or even all buffers must imply
 streamoff.--></para>
 
+    <para>To negotiate user pointer I/O, applications initialize only
+the <structfield>type</structfield> field and set
+<structfield>memory</structfield> to
+<constant>V4L2_MEMORY_USERPTR</constant>. When the ioctl is called
+with a pointer to this structure the driver prepares for user pointer
+I/O, when this I/O method is not supported the ioctl returns an
+&EINVAL;.</para>
+
     <table pgwide="1" frame="none" id="v4l2-requestbuffers">
       <title>struct <structname>v4l2_requestbuffers</structname></title>
       <tgroup cols="3">
@@ -89,7 +97,9 @@ streamoff.--></para>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>count</structfield></entry>
-	    <entry>The number of buffers requested or granted.</entry>
+	    <entry>The number of buffers requested or granted. This
+field is only used when <structfield>memory</structfield> is set to
+<constant>V4L2_MEMORY_MMAP</constant>.</entry>
 	  </row>
 	  <row>
 	    <entry>&v4l2-buf-type;</entry>
@@ -110,7 +120,7 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
 	    <entry><structfield>reserved</structfield>[2]</entry>
 	    <entry>A place holder for future extensions and custom
 (driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and
-higher. This array should be zeroed by applications.</entry>
+higher.</entry>
 	  </row>
 	</tbody>
       </tgroup>

trunk/Documentation/RCU/00-INDEX

@@ -6,22 +6,16 @@ checklist.txt
 	- Review Checklist for RCU Patches
 listRCU.txt
 	- Using RCU to Protect Read-Mostly Linked Lists
-lockdep.txt
-	- RCU and lockdep checking
 NMI-RCU.txt
 	- Using RCU to Protect Dynamic NMI Handlers
-rcubarrier.txt
-	- RCU and Unloadable Modules
-rculist_nulls.txt
-	- RCU list primitives for use with SLAB_DESTROY_BY_RCU
 rcuref.txt
 	- Reference-count design for elements of lists/arrays protected by RCU
 rcu.txt
 	- RCU Concepts
+rcubarrier.txt
+	- Unloading modules that use RCU callbacks
 RTFP.txt
 	- List of RCU papers (bibliography) going back to 1980.
-stallwarn.txt
-	- RCU CPU stall warnings (CONFIG_RCU_CPU_STALL_DETECTOR)
 torture.txt
 	- RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
 trace.txt

trunk/Documentation/RCU/RTFP.txt

@@ -25,10 +25,10 @@ to be referencing the data structure.  However, this mechanism was not
 optimized for modern computer systems, which is not surprising given
 that these overheads were not so expensive in the mid-80s.  Nonetheless,
 passive serialization appears to be the first deferred-destruction
-mechanism to be used in production.  Furthermore, the relevant patent
-has lapsed, so this approach may be used in non-GPL software, if desired.
-(In contrast, implementation of RCU is permitted only in software licensed
-under either GPL or LGPL.  Sorry!!!)
+mechanism to be used in production.  Furthermore, the relevant patent has
+lapsed, so this approach may be used in non-GPL software, if desired.
+(In contrast, use of RCU is permitted only in software licensed under
+GPL.  Sorry!!!)
 
 In 1990, Pugh [Pugh90] noted that explicitly tracking which threads
 were reading a given data structure permitted deferred free to operate
@@ -150,18 +150,6 @@ preemptible RCU [PaulEMcKenney2007PreemptibleRCU], and the three-part
 LWN "What is RCU?" series [PaulEMcKenney2007WhatIsRCUFundamentally,
 PaulEMcKenney2008WhatIsRCUUsage, and PaulEMcKenney2008WhatIsRCUAPI].
 
-2008 saw a journal paper on real-time RCU [DinakarGuniguntala2008IBMSysJ],
-a history of how Linux changed RCU more than RCU changed Linux
-[PaulEMcKenney2008RCUOSR], and a design overview of hierarchical RCU
-[PaulEMcKenney2008HierarchicalRCU].
-
-2009 introduced user-level RCU algorithms [PaulEMcKenney2009MaliciousURCU],
-which Mathieu Desnoyers is now maintaining [MathieuDesnoyers2009URCU]
-[MathieuDesnoyersPhD].  TINY_RCU [PaulEMcKenney2009BloatWatchRCU] made
-its appearance, as did expedited RCU [PaulEMcKenney2009expeditedRCU].
-The problem of resizeable RCU-protected hash tables may now be on a path
-to a solution [JoshTriplett2009RPHash].
-
 Bibtex Entries
 
 @article{Kung80
@@ -742,11 +730,6 @@ Revised:
 "
 }
 
-#
-#	"What is RCU?" LWN series.
-#
-########################################################################
-
 @article{DinakarGuniguntala2008IBMSysJ
 ,author="D. Guniguntala and P. E. McKenney and J. Triplett and J. Walpole"
 ,title="The read-copy-update mechanism for supporting real-time applications on shared-memory multiprocessor systems with {Linux}"
@@ -837,39 +820,3 @@ Revised:
 	Uniprocessor assumptions allow simplified RCU implementation.
 "
 }
-
-@unpublished{PaulEMcKenney2009expeditedRCU
-,Author="Paul E. McKenney"
-,Title="[{PATCH} -tip 0/3] expedited 'big hammer' {RCU} grace periods"
-,month="June"
-,day="25"
-,year="2009"
-,note="Available:
-\url{http://lkml.org/lkml/2009/6/25/306}
-[Viewed August 16, 2009]"
-,annotation="
-	First posting of expedited RCU to be accepted into -tip.
-"
-}
-
-@unpublished{JoshTriplett2009RPHash
-,Author="Josh Triplett"
-,Title="Scalable concurrent hash tables via relativistic programming"
-,month="September"
-,year="2009"
-,note="Linux Plumbers Conference presentation"
-,annotation="
-	RP fun with hash tables.
-"
-}
-
-@phdthesis{MathieuDesnoyersPhD
-, title  = "Low-Impact Operating System Tracing"
-, author = "Mathieu Desnoyers"
-, school = "Ecole Polytechnique de Montr\'{e}al"
-, month  = "December"
-, year   = 2009
-,note="Available:
-\url{http://www.lttng.org/pub/thesis/desnoyers-dissertation-2009-12.pdf}
-[Viewed December 9, 2009]"
-}