Merge tag 'v3.6-rc2' into drm-intel-next

Backmerge Linux 3.6-rc2 to resolve a few funny conflicts before we put
even more madness on top:

- drivers/gpu/drm/i915/i915_irq.c: Just a spurious WARN removed in
  -fixes, that has been changed in a variable-rename in -next, too.

- drivers/gpu/drm/i915/intel_ringbuffer.c: -next remove scratch_addr
  (since all their users have been extracted in another fucntion),
  -fixes added another user for a hw workaroudn.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

1 files changed, 5 insertions, 5 deletions

diff --git a/include/linux/pipe_fs_i.h b/include/linux/pipe_fs_i.h
index e1ac1ce16fb..ad1a427b526 100644
--- a/include/linux/pipe_fs_i.h
+++ b/include/linux/pipe_fs_i.h
@@ -86,11 +86,9 @@ struct pipe_buf_operations {
 	 * mapping or not. The atomic map is faster, however you can't take
 	 * page faults before calling ->unmap() again. So if you need to eg
 	 * access user data through copy_to/from_user(), then you must get
-	 * a non-atomic map. ->map() uses the KM_USER0 atomic slot for
-	 * atomic maps, so you can't map more than one pipe_buffer at once
-	 * and you have to be careful if mapping another page as source
-	 * or destination for a copy (IOW, it has to use something else
-	 * than KM_USER0).
+	 * a non-atomic map. ->map() uses the kmap_atomic slot for
+	 * atomic maps, you have to be careful if mapping another page as
+	 * source or destination for a copy.
 	 */
 	void * (*map)(struct pipe_inode_info *, struct pipe_buffer *, int);
 
@@ -162,4 +160,6 @@ void generic_pipe_buf_release(struct pipe_inode_info *, struct pipe_buffer *);
 long pipe_fcntl(struct file *, unsigned int, unsigned long arg);
 struct pipe_inode_info *get_pipe_info(struct file *file);
 
+int create_pipe_files(struct file **, int);
+
 #endif