diff options
Diffstat (limited to 'Documentation/video4linux')
| -rw-r--r-- | Documentation/video4linux/CARDLIST.au0828 | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.bttv | 1 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.cx23885 | 4 | ||||
| -rw-r--r-- | Documentation/video4linux/CARDLIST.saa7134 | 1 | ||||
| -rw-r--r-- | Documentation/video4linux/cpia2_overview.txt | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/stv680.txt | 2 | ||||
| -rw-r--r-- | Documentation/video4linux/v4l2-framework.txt | 73 |
7 files changed, 47 insertions, 38 deletions
diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 index 7b59e953c4bf..a8a65753e544 100644 --- a/Documentation/video4linux/CARDLIST.au0828 +++ b/Documentation/video4linux/CARDLIST.au0828 @@ -3,4 +3,4 @@ 2 -> Hauppauge HVR850 (au0828) [2040:7240] 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281] - 5 -> Hauppauge Woodbury (au0828) [2040:8200] + 5 -> Hauppauge Woodbury (au0828) [05e1:0480,2040:8200] diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index b753906c7183..581f666a76cf 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -159,3 +159,4 @@ 158 -> Geovision GV-800(S) (slave) [800b:763d,800c:763d,800d:763d] 159 -> ProVideo PV183 [1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540] 160 -> Tongwei Video Technology TD-3116 [f200:3116] +161 -> Aposonic W-DVR [0279:0228] diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index f316d1816fcd..652aecd13199 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -18,7 +18,7 @@ 17 -> NetUP Dual DVB-S2 CI [1b55:2a2c] 18 -> Hauppauge WinTV-HVR1270 [0070:2211] 19 -> Hauppauge WinTV-HVR1275 [0070:2215,0070:221d,0070:22f2] - 20 -> Hauppauge WinTV-HVR1255 [0070:2251,0070:2259,0070:22f1] + 20 -> Hauppauge WinTV-HVR1255 [0070:2251,0070:22f1] 21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295,0070:2299,0070:229d,0070:22f0,0070:22f3,0070:22f4,0070:22f5] 22 -> Mygica X8506 DMB-TH [14f1:8651] 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] @@ -33,3 +33,5 @@ 32 -> MPX-885 33 -> Mygica X8507 [14f1:8502] 34 -> TerraTec Cinergy T PCIe Dual [153b:117e] + 35 -> TeVii S471 [d471:9022] + 36 -> Hauppauge WinTV-HVR1255 [0070:2259] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 34f3b330e5f4..94d9025aa82d 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -188,3 +188,4 @@ 187 -> Beholder BeholdTV 503 FM [5ace:5030] 188 -> Sensoray 811/911 [6000:0811,6000:0911] 189 -> Kworld PC150-U [17de:a134] +190 -> Asus My Cinema PS3-100 [1043:48cd] diff --git a/Documentation/video4linux/cpia2_overview.txt b/Documentation/video4linux/cpia2_overview.txt index a6e53665216b..ad6adbedfe50 100644 --- a/Documentation/video4linux/cpia2_overview.txt +++ b/Documentation/video4linux/cpia2_overview.txt @@ -35,4 +35,4 @@ the camera. There are three modes for this. Block mode requests a number of contiguous registers. Random mode reads or writes random registers with a tuple structure containing address/value pairs. The repeat mode is only used by VP4 to load a firmware patch. It contains a starting address and -a sequence of bytes to be written into a gpio port.
\ No newline at end of file +a sequence of bytes to be written into a gpio port. diff --git a/Documentation/video4linux/stv680.txt b/Documentation/video4linux/stv680.txt index 4f8946f32f51..e3de33645308 100644 --- a/Documentation/video4linux/stv680.txt +++ b/Documentation/video4linux/stv680.txt @@ -50,4 +50,4 @@ The latest info on this driver can be found at: http://personal.clt.bellsouth.net/~kjsisson or at http://stv0680-usb.sourceforge.net -Any questions to me can be send to: kjsisson@bellsouth.net
\ No newline at end of file +Any questions to me can be send to: kjsisson@bellsouth.net diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 1f5905270050..89318be6c1d2 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -594,6 +594,15 @@ You should also set these fields: unlocked_ioctl file operation is called this lock will be taken by the core and released afterwards. See the next section for more details. +- queue: a pointer to the struct vb2_queue associated with this device node. + If queue is non-NULL, and queue->lock is non-NULL, then queue->lock is + used for the queuing ioctls (VIDIOC_REQBUFS, CREATE_BUFS, QBUF, DQBUF, + QUERYBUF, PREPARE_BUF, STREAMON and STREAMOFF) instead of the lock above. + That way the vb2 queuing framework does not have to wait for other ioctls. + This queue pointer is also used by the vb2 helper functions to check for + queuing ownership (i.e. is the filehandle calling it allowed to do the + operation). + - prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY. If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device. If you want to have a separate priority state per (group of) device node(s), @@ -647,47 +656,43 @@ manually set the struct media_entity type and name fields. A reference to the entity will be automatically acquired/released when the video device is opened/closed. -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 unlocked_ioctl, but you can disable locking for -selected ioctls by calling: - - void v4l2_disable_ioctl_locking(struct video_device *vdev, unsigned int cmd); - -E.g.: v4l2_disable_ioctl_locking(vdev, VIDIOC_DQBUF); +ioctls and locking +------------------ -You have to call this before you register the video_device. +The V4L core provides optional locking services. The main service is the +lock field in struct video_device, which is a pointer to a mutex. If you set +this pointer, then that will be used by unlocked_ioctl to serialize all ioctls. -Particularly with USB drivers where certain commands such as setting controls -can take a long time you may want to do your own locking for the buffer queuing -ioctls. +If you are using the videobuf2 framework, then there is a second lock that you +can set: video_device->queue->lock. If set, then this lock will be used instead +of video_device->lock to serialize all queuing ioctls (see the previous section +for the full list of those ioctls). -If you want still finer-grained locking then you have to set mutex_lock to NULL -and do you own locking completely. +The advantage of using a different lock for the queuing ioctls is that for some +drivers (particularly USB drivers) certain commands such as setting controls +can take a long time, so you want to use a separate lock for the buffer queuing +ioctls. That way your VIDIOC_DQBUF doesn't stall because the driver is busy +changing the e.g. exposure of the webcam. -It is up to the driver developer to decide which method to use. However, if -your driver has high-latency operations (for example, changing the exposure -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. +Of course, you can always do all the locking yourself by leaving both lock +pointers at NULL. -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 -also waits in the code, then you should do the same to allow other processes -to access the device node while the first process is waiting for something. +If you use the old videobuf then you must pass the video_device 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 also waits in the code, then you should do the same to allow other +processes to access the device node while the first process is waiting for +something. In the case of videobuf2 you will need to implement the wait_prepare and -wait_finish callbacks to unlock/lock if applicable. In particular, if you use -the lock in struct video_device then you must unlock/lock this mutex in -wait_prepare and wait_finish. - -The implementation of a hotplug disconnect should also take the lock before -calling v4l2_device_disconnect. +wait_finish callbacks to unlock/lock if applicable. If you use the queue->lock +pointer, then you can use the helper functions vb2_ops_wait_prepare/finish. + +The implementation of a hotplug disconnect should also take the lock from +video_device before calling v4l2_device_disconnect. If you are also using +video_device->queue->lock, then you have to first lock video_device->queue->lock +followed by video_device->lock. That way you can be sure no ioctl is running +when you call v4l2_device_disconnect. video_device registration ------------------------- |