---

yaml
---
r: 306404
b: refs/heads/master
c: 74f22c4
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: a299e407b9ef356bf14fbb49793dc026877440df
+refs/heads/master: 74f22c48640cf39df1f9cbf4fac07f5fcd365a48

trunk/Documentation/video4linux/v4l2-framework.txt

@@ -590,8 +590,8 @@ You should also set these fields:
   future!), then set this to your v4l2_ioctl_ops struct.
 
 - lock: leave to NULL if you want to do all the locking in the driver.
-  Otherwise you give it a pointer to a struct mutex_lock and before any
-  of the v4l2_file_operations is called this lock will be taken by the
+  Otherwise you give it a pointer to a struct mutex_lock and before the
+  unlocked_ioctl file operation is called this lock will be taken by the
   core and released afterwards. See the next section for more details.
 
 - prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY.
@@ -652,8 +652,8 @@ v4l2_file_operations and locking
 
 You can set a pointer to a mutex_lock in struct video_device. Usually this
 will be either a top-level mutex or a mutex per device node. By default this
-lock will be used for each file operation and ioctl, but you can disable
-locking for selected ioctls by calling:
+lock will be used for unlocked_ioctl, but you can disable locking for
+selected ioctls by calling:
 
 	void v4l2_dont_use_lock(struct video_device *vdev, unsigned int cmd);
 
@@ -674,7 +674,7 @@ of a USB webcam might take a long time), then you might be better off with
 doing your own locking if you want to allow the user to do other things with
 the device while waiting for the high-latency command to finish.
 
-If a lock is specified then all file operations will be serialized on that
+If a lock is specified then all ioctl commands will be serialized on that
 lock. If you use videobuf then you must pass the same lock to the videobuf
 queue initialize function: if videobuf has to wait for a frame to arrive, then
 it will temporarily unlock the lock and relock it afterwards. If your driver