aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/video4linux
diff options
context:
space:
mode:
authorHans Verkuil <hans.verkuil@cisco.com>2011-11-07 10:44:28 -0500
committerMauro Carvalho Chehab <mchehab@redhat.com>2011-11-25 12:07:54 -0500
commit43599f31ab93bc2c17db615be20ce56261392292 (patch)
tree302f2662707f8411bb5001b20baeb8ae2d7f3f05 /Documentation/video4linux
parent0fb6ec6b1c185a1d99bf238880cc265d72ab111b (diff)
[media] v4l2 framework doc: clarify locking
high-latency devices. Thanks to Hans de Goede for our discussions on this topic. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Thanks-to: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/video4linux')
-rw-r--r--Documentation/video4linux/v4l2-framework.txt11
1 files changed, 11 insertions, 0 deletions
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index f8dcabf7852..659b2ba12a4 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -612,6 +612,12 @@ You can set a pointer to a mutex_lock in struct video_device. Usually this
612will be either a top-level mutex or a mutex per device node. If you want 612will be either a top-level mutex or a mutex per device node. If you want
613finer-grained locking then you have to set it to NULL and do you own locking. 613finer-grained locking then you have to set it to NULL and do you own locking.
614 614
615It is up to the driver developer to decide which method to use. However, if
616your driver has high-latency operations (for example, changing the exposure
617of a USB webcam might take a long time), then you might be better off with
618doing your own locking if you want to allow the user to do other things with
619the device while waiting for the high-latency command to finish.
620
615If a lock is specified then all file operations will be serialized on that 621If a lock is specified then all file operations will be serialized on that
616lock. If you use videobuf then you must pass the same lock to the videobuf 622lock. If you use videobuf then you must pass the same lock to the videobuf
617queue initialize function: if videobuf has to wait for a frame to arrive, then 623queue initialize function: if videobuf has to wait for a frame to arrive, then
@@ -619,6 +625,11 @@ it will temporarily unlock the lock and relock it afterwards. If your driver
619also waits in the code, then you should do the same to allow other processes 625also waits in the code, then you should do the same to allow other processes
620to access the device node while the first process is waiting for something. 626to access the device node while the first process is waiting for something.
621 627
628In the case of videobuf2 you will need to implement the wait_prepare and
629wait_finish callbacks to unlock/lock if applicable. In particular, if you use
630the lock in struct video_device then you must unlock/lock this mutex in
631wait_prepare and wait_finish.
632
622The implementation of a hotplug disconnect should also take the lock before 633The implementation of a hotplug disconnect should also take the lock before
623calling v4l2_device_disconnect. 634calling v4l2_device_disconnect.
624 635