[media] v4l2-framework.txt: update the core lock documentation

  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.

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);

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