|
@@ -245,13 +245,38 @@ static long v4l2_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
|
|
|
if (vdev->lock)
|
|
|
mutex_unlock(vdev->lock);
|
|
|
} else if (vdev->fops->ioctl) {
|
|
|
- /* TODO: convert all drivers to unlocked_ioctl */
|
|
|
+ /* This code path is a replacement for the BKL. It is a major
|
|
|
+ * hack but it will have to do for those drivers that are not
|
|
|
+ * yet converted to use unlocked_ioctl.
|
|
|
+ *
|
|
|
+ * There are two options: if the driver implements struct
|
|
|
+ * v4l2_device, then the lock defined there is used to
|
|
|
+ * serialize the ioctls. Otherwise the v4l2 core lock defined
|
|
|
+ * below is used. This lock is really bad since it serializes
|
|
|
+ * completely independent devices.
|
|
|
+ *
|
|
|
+ * Both variants suffer from the same problem: if the driver
|
|
|
+ * sleeps, then it blocks all ioctls since the lock is still
|
|
|
+ * held. This is very common for VIDIOC_DQBUF since that
|
|
|
+ * normally waits for a frame to arrive. As a result any other
|
|
|
+ * ioctl calls will proceed very, very slowly since each call
|
|
|
+ * will have to wait for the VIDIOC_QBUF to finish. Things that
|
|
|
+ * should take 0.01s may now take 10-20 seconds.
|
|
|
+ *
|
|
|
+ * The workaround is to *not* take the lock for VIDIOC_DQBUF.
|
|
|
+ * This actually works OK for videobuf-based drivers, since
|
|
|
+ * videobuf will take its own internal lock.
|
|
|
+ */
|
|
|
static DEFINE_MUTEX(v4l2_ioctl_mutex);
|
|
|
+ struct mutex *m = vdev->v4l2_dev ?
|
|
|
+ &vdev->v4l2_dev->ioctl_lock : &v4l2_ioctl_mutex;
|
|
|
|
|
|
- mutex_lock(&v4l2_ioctl_mutex);
|
|
|
+ if (cmd != VIDIOC_DQBUF && mutex_lock_interruptible(m))
|
|
|
+ return -ERESTARTSYS;
|
|
|
if (video_is_registered(vdev))
|
|
|
ret = vdev->fops->ioctl(filp, cmd, arg);
|
|
|
- mutex_unlock(&v4l2_ioctl_mutex);
|
|
|
+ if (cmd != VIDIOC_DQBUF)
|
|
|
+ mutex_unlock(m);
|
|
|
} else
|
|
|
ret = -ENOTTY;
|
|
|
|