diff options
author | Hans Verkuil <hans.verkuil@cisco.com> | 2011-11-07 10:44:28 -0500 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2011-11-25 12:07:54 -0500 |
commit | 43599f31ab93bc2c17db615be20ce56261392292 (patch) | |
tree | 302f2662707f8411bb5001b20baeb8ae2d7f3f05 /Documentation/video4linux/v4l2-framework.txt | |
parent | 0fb6ec6b1c185a1d99bf238880cc265d72ab111b (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/v4l2-framework.txt')
-rw-r--r-- | Documentation/video4linux/v4l2-framework.txt | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f8dcabf7852c..659b2ba12a4f 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 | |||
612 | will be either a top-level mutex or a mutex per device node. If you want | 612 | will be either a top-level mutex or a mutex per device node. If you want |
613 | finer-grained locking then you have to set it to NULL and do you own locking. | 613 | finer-grained locking then you have to set it to NULL and do you own locking. |
614 | 614 | ||
615 | It is up to the driver developer to decide which method to use. However, if | ||
616 | your driver has high-latency operations (for example, changing the exposure | ||
617 | of a USB webcam might take a long time), then you might be better off with | ||
618 | doing your own locking if you want to allow the user to do other things with | ||
619 | the device while waiting for the high-latency command to finish. | ||
620 | |||
615 | If a lock is specified then all file operations will be serialized on that | 621 | If a lock is specified then all file operations will be serialized on that |
616 | lock. If you use videobuf then you must pass the same lock to the videobuf | 622 | lock. If you use videobuf then you must pass the same lock to the videobuf |
617 | queue initialize function: if videobuf has to wait for a frame to arrive, then | 623 | queue 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 | |||
619 | also waits in the code, then you should do the same to allow other processes | 625 | also waits in the code, then you should do the same to allow other processes |
620 | to access the device node while the first process is waiting for something. | 626 | to access the device node while the first process is waiting for something. |
621 | 627 | ||
628 | In the case of videobuf2 you will need to implement the wait_prepare and | ||
629 | wait_finish callbacks to unlock/lock if applicable. In particular, if you use | ||
630 | the lock in struct video_device then you must unlock/lock this mutex in | ||
631 | wait_prepare and wait_finish. | ||
632 | |||
622 | The implementation of a hotplug disconnect should also take the lock before | 633 | The implementation of a hotplug disconnect should also take the lock before |
623 | calling v4l2_device_disconnect. | 634 | calling v4l2_device_disconnect. |
624 | 635 | ||