Doug / smarc-fsl-linux-kernel

Download as
Browse Code ยป

Commit 43599f31ab93bc2c17db615be20ce56261392292

Authored by Hans Verkuil
Committed by Mauro Carvalho Chehab
1 parent 0fb6ec6b1c
Exists in master and in 6 other branches imx_3.10.17_1.0.1_ga, imx_3.10.53_1.1.0_ga, imx_3.14.28_1.0.0_ga, smarc-imx_3.10.53_1.1.0_ga, smarc-imx_3.14.28_1.0.0_ga, smarc-l5.0.0_1.0.0-ga

[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>

Showing 1 changed file with 11 additions and 0 deletions Side-by-side Diff

Documentation/video4linux/v4l2-framework.txt
Diff comments   View file @ 43599f3
... ... @@ -612,12 +612,23 @@
612 612 will be either a top-level mutex or a mutex per device node. If you want
613 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 621 If a lock is specified then all file operations will be serialized on that
616 622 lock. If you use videobuf then you must pass the same lock to the videobuf
617 623 queue initialize function: if videobuf has to wait for a frame to arrive, then
618 624 it will temporarily unlock the lock and relock it afterwards. If your driver
619 625 also waits in the code, then you should do the same to allow other processes
620 626 to access the device node while the first process is waiting for something.
  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.
621 632  
622 633 The implementation of a hotplug disconnect should also take the lock before
623 634 calling v4l2_device_disconnect.