| Message ID | b83cf780636a80aec53e3b7e8f101645049e94f3.1411397045.git.shuahkh@osg.samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Devin, On 09/22/2014 01:21 PM, Devin Heitmueller wrote: > Hi Shuah, > > What about G_INPUT and G_TUNER? Consider the following use case, which is > entirely legal in the V4L2 API: Did you mean G_INPUT and G_STD here? I didn't see G_TUNER mentioned below in the use-case. I didn't know this use-case, I did notice ENUM_INPUT getting called in a loop during testing. I think I didn't run into this because I changed the au0828: vidioc_g_tuner to hold the lock as it does a tuner init and messes up the tuner when it is in use by dvb. But, that doesn't cover this use-case for other drivers. So I need to make more changes to cover it. Thanks for pointing this out. > > 1. Program opens /dev/video0 > 2. Program calls G_INPUT/G_STD and sees that the appropriate input and > standard are already set, since all devices have a default input at > initialization > 3. Program never calls S_INPUT, S_STD, or S_TUNER > 4. Program goes into a loop calling ENUM_INPUT, waiting until it returns > the input as having signal lock > 5. When signal lock is seen, program calls STREAMON. I am missing vb2 streamon change to hold the tuner in this patch set. Without that change vb2 work isn't complete. Unfortunately I don't have hybrid hardware that uses a vb2 driver. > > In the above case, you would be actively using the au8522 video decoder but > not holding the lock, so thr DVB device can be opened and screw everything > up. Likewise if the DVB device were in use and such a program were run, it > wouls break. > I think this use-case will be covered with changes to vb2 streamon to check and hold tuner. I am thinking it might not be necessary to change g_tuner, g_std, g_input and enum_input at v4l2-core level. Does that sounds right?? thanks, -- Shuah
Hello Shuah, >> What about G_INPUT and G_TUNER? Consider the following use case, which is >> entirely legal in the V4L2 API: > > Did you mean G_INPUT and G_STD here? I didn't see G_TUNER mentioned > below in the use-case. It can be either ENUM_INPUT or G_TUNER. Both return status information that requires communication with the video decoder chip and/or tuner. It's probably worth mentioning that ENUMINPUT isn't like the other ENUM_ calls in that it doesn't return a static list without talking to the driver - it contains a field (called .status) which actually needs to talk to the hardware in order to populate it. >> 1. Program opens /dev/video0 >> 2. Program calls G_INPUT/G_STD and sees that the appropriate input and >> standard are already set, since all devices have a default input at >> initialization >> 3. Program never calls S_INPUT, S_STD, or S_TUNER >> 4. Program goes into a loop calling ENUM_INPUT, waiting until it returns >> the input as having signal lock >> 5. When signal lock is seen, program calls STREAMON. > > I am missing vb2 streamon change to hold the tuner in this patch set. > Without that change vb2 work isn't complete. Unfortunately I don't > have hybrid hardware that uses a vb2 driver. I don't think you quite understood my concern. The concern is that in the use case above I'm actively using the tuner *before* VIDIOC_STREAMON is called. Hence from a locking standpoint you probably don't want to allow the DVB device to take control of the tuner. >> >> In the above case, you would be actively using the au8522 video decoder but >> not holding the lock, so thr DVB device can be opened and screw everything >> up. Likewise if the DVB device were in use and such a program were run, it >> wouls break. >> > > I think this use-case will be covered with changes to vb2 streamon > to check and hold tuner. I am thinking it might not be necessary to > change g_tuner, g_std, g_input and enum_input at v4l2-core level. > Does that sounds right?? The more I think about it, the less confident I am that you actually can take a fine-grained locking approach without adding additional ioctls to make it explicit. When is the tuner unlocked? Is it when the filehandle is closed? If so, then the the following script would behave in an unexpected manner: #!/bin/sh while [ 1 ]; do v4l2-ctl -n # Some code to parse the output and see if the "status" field for current input shows no signal # If status shows as locked break done v4l2-ctl --stream-mmap=500 --stream-to=/tmp/foo.bin In the above case I'm actively using the tuner but not holding the lock most of the time, so a separate process can grab the DVB device between calls to "v4l2-ctl -n". However if you're keeping the device locked until STREAMOFF, then you'll break all sorts of applications which might just close the filehandle without calling STREAMOFF, and hence you'll have cases where the tuner is left locked in analog mode *forever*, preventing apps from using it in digital mode. Without adding a new ioctl to lock/unlock the analog side of the device, there is no real way to deal with this perfectly legal use case. The downside of that of course is that applications would have to be modified in order for the locking to be used, and the default would have to be to not do locking in order to preserve backward compatibility with existing applications. What other ioctls have we not thought of? I think there is an argument to be made that we're being too aggressive in trying to control the locking based on the ioctls called. It might make sense to simplify the approach to lock on when the device is opened, and unlock when closed. This avoids the complexity of trying to figure out *which* ioctls we need to set the lock on (which likely varies on a per device basis anyway), at the cost of not allowing the device to be used when something has the filehandle opened for the other side of the device (the behavior of which is currently undefined in the spec). I know there are concerns that some apps might leave the FD open even when done using it, but that seems like a less likely case than properly handling fine-grained locking (causing unexpected behavior for the applications that don't expect -EBUSY to be returned after the device has been successfully opened). We can always start with coarse locking on open/close, and do finer grained locking down the road if needed - or simply change the currently undefined behavior in the spec to say that you have to close the device handle before attempting to open the other side of the device. On a related note, you should be testing with MythTV - none of the applications you are currently testing with support both analog *and* digital, so you are not seeing all the race conditions that can occur when you close one side of the device and then *immediately* open the other side. In particular, there is a known race that occurs when closing the DVB device and then opening the V4L device, because the DVB frontend shuts down the tuner asynchronously after the close() call returns to userland. Exiting one application and starting another provides plenty of time for the close() logic to be run, so you're missing all the race conditions. Devin
Hi Devin/Mauro/Hans, Summarizing the discussion on v4l to keep others on this thread in the loop. Please see below: Hans! Could you please take a look and see if it raises any red flags for you. On 09/23/2014 08:17 AM, Devin Heitmueller wrote: > > We can always start with coarse locking on open/close, and do finer > grained locking down the road if needed - or simply change the > currently undefined behavior in the spec to say that you have to close > the device handle before attempting to open the other side of the > device. > I share the same concerns about fine grain locking approach that requires changes to various v4l2 ioctls to hold the token. My concern with the current approach is that we won't be able to find all the v4l paths to secure. During my testing, it is clear that several applications don't seem to check ioctls return codes and even if one of the ioctls returns -EBUSY, applications keep calling other ioctls instead of exiting with device busy condition. Compared to the current approach, holding lock in open and releasing it in close is cleaner with predictable failure conditions. It is lot easier to maintain. In addition, this approach keeps it same as the dvb core token hold approach as outlined below. dvb on the other hand is easier with its clean entry and exit points. In the case of dvb, the lock is held when the device is opened in read/write mode before dvb front-end thread gets started and released when thread exits. I discussed this a couple of times in the past during development for this current patch series. The concern has been that a number of currently supported use-cases will break with the simpler approach to lock when v4l device is opened and unlock when it is closed. As we discussed this morning and agreed on giving the simpler approach a try first keeping the finer grain locking option open for revisit. This would be acceptable provided the token code is tested on existing apps, including mythtv, kradio, gnome-radio. In addition to releasing the token at device close, release the token if an app decides to use S_PRIORITY to release the streaming ownership e. g. V4L2_PRIORITY_BACKGROUND Devin recommended testing on devices that have an encoder to cover the cases where there are multiple /dev/videoX nodes tied to the same tuner. Please check if I captured it correctly. I can get started on the simpler approach and see where it takes us. I have to change the v4l2 and driver v4l2 patches. dvb and the rest can stay the same. thanks, -- Shuah
Hi Shuah, Here is my review... On 09/22/2014 05:00 PM, Shuah Khan wrote: > Changes to v4l2-core to hold tuner token in v4l2 ioctl that change > the tuner modes, and reset the token from fh exit. The changes are > limited to vb2 calls that disrupt digital stream. vb1 changes are > made in the driver. The following ioctls are changed: > > S_INPUT, S_OUTPUT, S_FMT, S_TUNER, S_MODULATOR, S_FREQUENCY, S_MODULATOR doesn't need to take a token. Certainly not a tuner token, since it is a modulator, not a tuner. There aren't many modulator drivers, and none of them have different modes. The same is true for S_OUTPUT: it deals with outputs, so it has nothing to do with tuners since those are for input. > S_STD, S_HW_FREQ_SEEK: > > - hold tuner in shared analog mode before calling appropriate > ops->vidioc_s_* > - return leaving tuner in shared mode. > - Note that S_MODULATOR is now implemented in the core > previously FCN. > > QUERYSTD: > - hold tuner in shared analog mode before calling > ops->vidioc_querystd > - return after calling put tuner - this simply decrements the > owners. Leaves tuner in shared analog mode if owners > 0 I would handle QUERYSTD the same as the ones in the first group. It's a fair assumption that once you call QUERYSTD you expect to switch the tuner to analog mode and keep it there. I'm missing STREAMON in this list as well. With regards to G_TUNER and ENUM_INPUT, I will reply to the post that discusses that topic. > > v4l2_fh_exit: > - resets the media tuner token. A simple put token could leave > the token in shared mode. The nature of analog token holds > is unbalanced requiring a reset to clear it. Nack on the reset. It should just put the tuner token. The way it should work is that whenever an ioctl is issued that needs to take a tuner token, then it should check if the filehandle already has a token. If not, then take the token if possible. If it has, then check if the token is in the right mode and continue if that's the case, otherwise return EBUSY. I don't think it can ever be in the wrong mode, but it doesn't hurt to check. Or do WARN_ON or something like that. This way each filehandle will take a token only once, and it is released when the filehandle is closed. You do need to store in struct v4l2_fh whether or not a token was obtained so the v4l2_fh_exit knows to release it. Almost all drivers support v4l2_fh by now, so I wouldn't bother with drivers that don't support v4l2_fh. > > Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> > --- > drivers/media/v4l2-core/v4l2-fh.c | 16 ++++++ > drivers/media/v4l2-core/v4l2-ioctl.c | 96 +++++++++++++++++++++++++++++++++- > 2 files changed, 110 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/v4l2-core/v4l2-fh.c b/drivers/media/v4l2-core/v4l2-fh.c > index c97067a..81ce3f9 100644 > --- a/drivers/media/v4l2-core/v4l2-fh.c > +++ b/drivers/media/v4l2-core/v4l2-fh.c > @@ -25,7 +25,10 @@ > #include <linux/bitops.h> > #include <linux/slab.h> > #include <linux/export.h> > +#include <linux/device.h> > +#include <linux/media_tknres.h> > #include <media/v4l2-dev.h> > +#include <media/v4l2-device.h> > #include <media/v4l2-fh.h> > #include <media/v4l2-event.h> > #include <media/v4l2-ioctl.h> > @@ -92,6 +95,19 @@ void v4l2_fh_exit(struct v4l2_fh *fh) > { > if (fh->vdev == NULL) > return; > + > + if (fh->vdev->dev_parent) { > + enum media_tkn_mode mode; > + > + mode = (fh->vdev->vfl_type == V4L2_TUNER_RADIO) ? > + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; > + /* reset the token - the nature of token get in > + analog mode is shared and unbalanced. There is > + no clear start and stop, so shared token might > + never get cleared */ > + media_reset_shared_tuner_tkn(fh->vdev->dev_parent, mode); As mentioned above, this should just be a put, not a reset. > + } > + > v4l2_event_unsubscribe_all(fh); > fh->vdev = NULL; > } > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c > index d15e167..9e1f042 100644 > --- a/drivers/media/v4l2-core/v4l2-ioctl.c > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c > @@ -17,6 +17,7 @@ > #include <linux/types.h> > #include <linux/kernel.h> > #include <linux/version.h> > +#include <linux/media_tknres.h> > > #include <linux/videodev2.h> > > @@ -1003,6 +1004,37 @@ static void v4l_sanitize_format(struct v4l2_format *fmt) > sizeof(fmt->fmt.pix) - offset); > } > > +static int v4l_get_tuner_tkn(struct video_device *vfd, > + enum v4l2_tuner_type type) > +{ > + int ret = 0; > + > + if (vfd->dev_parent) { > + enum media_tkn_mode mode; > + > + mode = (type == V4L2_TUNER_RADIO) ? > + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; > + ret = media_get_shared_tuner_tkn(vfd->dev_parent, mode); > + if (ret) > + dev_info(vfd->dev_parent, > + "%s: Tuner is busy\n", __func__); > + } > + dev_dbg(vfd->dev_parent, "%s: No token?? %d\n", __func__, ret); Shouldn't this be in a 'else'? Now the 'No token' message is also printed when media_get_shared_tuner_tkn got the tuner. > + return ret; > +} > + > +static void v4l_put_tuner_tkn(struct video_device *vfd, > + enum v4l2_tuner_type type) > +{ > + if (vfd->dev_parent) { > + enum media_tkn_mode mode; > + > + mode = (type == V4L2_TUNER_RADIO) ? > + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; > + media_put_tuner_tkn(vfd->dev_parent, mode); > + } > +} > + > static int v4l_querycap(const struct v4l2_ioctl_ops *ops, > struct file *file, void *fh, void *arg) > { > @@ -1022,12 +1054,24 @@ static int v4l_querycap(const struct v4l2_ioctl_ops *ops, > static int v4l_s_input(const struct v4l2_ioctl_ops *ops, > struct file *file, void *fh, void *arg) > { > + struct video_device *vfd = video_devdata(file); > + int ret = 0; > + > + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); > + if (ret) > + return ret; > return ops->vidioc_s_input(file, fh, *(unsigned int *)arg); > } > > static int v4l_s_output(const struct v4l2_ioctl_ops *ops, > struct file *file, void *fh, void *arg) > { > + struct video_device *vfd = video_devdata(file); > + int ret = 0; > + > + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); > + if (ret) > + return ret; > return ops->vidioc_s_output(file, fh, *(unsigned int *)arg); > } As mentioned, tuner tokens make no sense for s_output. > > @@ -1236,6 +1280,10 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops, > bool is_tx = vfd->vfl_dir != VFL_DIR_RX; > int ret; > > + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); > + if (ret) > + return ret; > + > v4l_sanitize_format(p); > > switch (p->type) { > @@ -1415,9 +1463,13 @@ static int v4l_s_tuner(const struct v4l2_ioctl_ops *ops, > { > struct video_device *vfd = video_devdata(file); > struct v4l2_tuner *p = arg; > + int ret; > > p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ? > V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; > + ret = v4l_get_tuner_tkn(vfd, p->type); > + if (ret) > + return ret; > return ops->vidioc_s_tuner(file, fh, p); > } > > @@ -1433,6 +1485,26 @@ static int v4l_g_modulator(const struct v4l2_ioctl_ops *ops, > return err; > } > > +static int v4l_s_modulator(const struct v4l2_ioctl_ops *ops, > + struct file *file, void *fh, void *arg) > +{ > + struct video_device *vfd = video_devdata(file); > + struct v4l2_fh *vfh = > + test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags) ? fh : NULL; > + > + if (vfh != NULL) { > + int ret; > + enum v4l2_tuner_type type; > + > + type = (vfd->vfl_type == VFL_TYPE_RADIO) ? > + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; > + ret = v4l_get_tuner_tkn(vfd, type); > + if (ret) > + return ret; > + } > + return ops->vidioc_s_modulator(file, fh, arg); > +} Again, tuner tokens make no sense for a modulator. > + > static int v4l_g_frequency(const struct v4l2_ioctl_ops *ops, > struct file *file, void *fh, void *arg) > { > @@ -1453,6 +1525,7 @@ static int v4l_s_frequency(const struct v4l2_ioctl_ops *ops, > struct video_device *vfd = video_devdata(file); > const struct v4l2_frequency *p = arg; > enum v4l2_tuner_type type; > + int ret; > > if (vfd->vfl_type == VFL_TYPE_SDR) { > if (p->type != V4L2_TUNER_ADC && p->type != V4L2_TUNER_RF) > @@ -1462,6 +1535,9 @@ static int v4l_s_frequency(const struct v4l2_ioctl_ops *ops, > V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; > if (type != p->type) > return -EINVAL; > + ret = v4l_get_tuner_tkn(vfd, type); > + if (ret) > + return ret; > } > return ops->vidioc_s_frequency(file, fh, p); > } > @@ -1508,11 +1584,16 @@ static int v4l_s_std(const struct v4l2_ioctl_ops *ops, > { > struct video_device *vfd = video_devdata(file); > v4l2_std_id id = *(v4l2_std_id *)arg, norm; > + int ret = 0; > > norm = id & vfd->tvnorms; > if (vfd->tvnorms && !norm) /* Check if std is supported */ > return -EINVAL; > > + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); > + if (ret) > + return ret; > + > /* Calls the specific handler */ > return ops->vidioc_s_std(file, fh, norm); > } > @@ -1522,7 +1603,11 @@ static int v4l_querystd(const struct v4l2_ioctl_ops *ops, > { > struct video_device *vfd = video_devdata(file); > v4l2_std_id *p = arg; > + int ret = 0; > > + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); > + if (ret) > + return ret; > /* > * If no signal is detected, then the driver should return > * V4L2_STD_UNKNOWN. Otherwise it should return tvnorms with > @@ -1532,7 +1617,9 @@ static int v4l_querystd(const struct v4l2_ioctl_ops *ops, > * their efforts to improve the standards detection. > */ > *p = vfd->tvnorms; > - return ops->vidioc_querystd(file, fh, arg); > + ret = ops->vidioc_querystd(file, fh, arg); > + v4l_put_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); No put needed. > + return ret; > } > > static int v4l_s_hw_freq_seek(const struct v4l2_ioctl_ops *ops, > @@ -1541,6 +1628,7 @@ static int v4l_s_hw_freq_seek(const struct v4l2_ioctl_ops *ops, > struct video_device *vfd = video_devdata(file); > struct v4l2_hw_freq_seek *p = arg; > enum v4l2_tuner_type type; > + int ret; > > /* s_hw_freq_seek is not supported for SDR for now */ > if (vfd->vfl_type == VFL_TYPE_SDR) > @@ -1550,6 +1638,9 @@ static int v4l_s_hw_freq_seek(const struct v4l2_ioctl_ops *ops, > V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; > if (p->type != type) > return -EINVAL; > + ret = v4l_get_tuner_tkn(vfd, type); > + if (ret) > + return ret; > return ops->vidioc_s_hw_freq_seek(file, fh, p); > } > > @@ -2217,7 +2308,8 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = { > IOCTL_INFO_STD(VIDIOC_G_AUDOUT, vidioc_g_audout, v4l_print_audioout, 0), > IOCTL_INFO_STD(VIDIOC_S_AUDOUT, vidioc_s_audout, v4l_print_audioout, INFO_FL_PRIO), > IOCTL_INFO_FNC(VIDIOC_G_MODULATOR, v4l_g_modulator, v4l_print_modulator, INFO_FL_CLEAR(v4l2_modulator, index)), > - IOCTL_INFO_STD(VIDIOC_S_MODULATOR, vidioc_s_modulator, v4l_print_modulator, INFO_FL_PRIO), > + IOCTL_INFO_FNC(VIDIOC_S_FREQUENCY, v4l_s_modulator, > + v4l_print_frequency, INFO_FL_PRIO), Huh? S_MODULATOR is removed and a duplicate S_FREQUENCY is added? > IOCTL_INFO_FNC(VIDIOC_G_FREQUENCY, v4l_g_frequency, v4l_print_frequency, INFO_FL_CLEAR(v4l2_frequency, tuner)), > IOCTL_INFO_FNC(VIDIOC_S_FREQUENCY, v4l_s_frequency, v4l_print_frequency, INFO_FL_PRIO), > IOCTL_INFO_FNC(VIDIOC_CROPCAP, v4l_cropcap, v4l_print_cropcap, INFO_FL_CLEAR(v4l2_cropcap, type)), > BTW, I still haven't seen how you are going to handle snd-usb-audio. I want to see how that is going to be handled before I will Ack anything. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Shuah, On 09/23/2014 10:46 PM, Shuah Khan wrote: > Hi Devin/Mauro/Hans, > > Summarizing the discussion on v4l to keep others on this > thread in the loop. Please see below: > > Hans! Could you please take a look and see if it raises > any red flags for you. > > On 09/23/2014 08:17 AM, Devin Heitmueller wrote: > >> >> We can always start with coarse locking on open/close, and do finer >> grained locking down the road if needed - or simply change the >> currently undefined behavior in the spec to say that you have to close >> the device handle before attempting to open the other side of the >> device. >> > > I share the same concerns about fine grain locking approach that > requires changes to various v4l2 ioctls to hold the token. My > concern with the current approach is that we won't be able to find > all the v4l paths to secure. During my testing, it is clear that > several applications don't seem to check ioctls return codes and > even if one of the ioctls returns -EBUSY, applications keep calling > other ioctls instead of exiting with device busy condition. Let's be realistic: if an application doesn't test for error codes, then that's the problem of the application. Also, EBUSY will only be returned if someone else is holding the tuner in a different mode. And that didn't work anyway (and probably in worse ways too if the driver would forcefully change the tuner mode). So I really don't see a problem with this. > > Compared to the current approach, holding lock in open and releasing > it in close is cleaner with predictable failure conditions. It is lot > easier to maintain. In addition, this approach keeps it same as the > dvb core token hold approach as outlined below. Absolutely not an option for v4l2. You should always be able to open a v4l2 device, regardless of the tuner mode or any other mode. The only exception is a radio tuner device: that should take the tuner on open. I think this is a very unfortunate design and I wish that that could be dropped. One thing that we haven't looked at at all is what should be done if the current input is not a tuner but a composite or S-Video input. It is likely (I would have to test this to be sure) that you can capture from a DVB tuner and at the same time from an S-Video input without any problems. By taking the tuner token unconditionally this would become impossible. But doing this right will require more work. BTW, what happens if the analog video part of a hybrid board doesn't have a tuner but only S-Video/Composite inputs? I think I've seen such boards actually. I would have to dig through my collection though. > > dvb on the other hand is easier with its clean entry and exit points. > In the case of dvb, the lock is held when the device is opened in > read/write mode before dvb front-end thread gets started and released > when thread exits. > > I discussed this a couple of times in the past during development > for this current patch series. The concern has been that a number of > currently supported use-cases will break with the simpler approach > to lock when v4l device is opened and unlock when it is closed. > > As we discussed this morning and agreed on giving the simpler > approach a try first keeping the finer grain locking option > open for revisit. This would be acceptable provided the token > code is tested on existing apps, including mythtv, kradio, > gnome-radio. Nack from me. Taking a tuner token should only happen when the device actually needs the tuner. For DVB that's easy, since whenever you open the frontend you *know* you want the tuner. But that's much more difficult for V4L2 since there are so many combinations, including many that don't need a tuner at all such as HDMI, Composite etc. inputs. > > In addition to releasing the token at device close, release the token > if an app decides to use S_PRIORITY to release the streaming ownership > e. g. V4L2_PRIORITY_BACKGROUND S_PRIORITY has nothing to do with tuner ownership. If there is a real need to release the token at another time than on close (and I don't see such a need), then make a new ioctl. Let's not overload S_PRIO with an unrelated action. > > Devin recommended testing on devices that have an encoder to cover > the cases where there are multiple /dev/videoX nodes tied to the > same tuner. Good examples are cx23885 (already vb2) and cx88 (the vb2 patches have been posted, but not yet merged). It shouldn't be too hard to find hardware based on those chipsets. > > Please check if I captured it correctly. I can get started on the > simpler approach and see where it takes us. I have to change the > v4l2 and driver v4l2 patches. dvb and the rest can stay the same. As mentioned, Nack for the simpler approach from me. That's simply too simple :-) Note: I'm travelling and attending a conference, so my availability for the rest of the week will probably be limited. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/24/2014 05:57 AM, Hans Verkuil wrote: > Hi Shuah, > > Here is my review... > > On 09/22/2014 05:00 PM, Shuah Khan wrote: >> Changes to v4l2-core to hold tuner token in v4l2 ioctl that change >> the tuner modes, and reset the token from fh exit. The changes are >> limited to vb2 calls that disrupt digital stream. vb1 changes are >> made in the driver. The following ioctls are changed: >> >> S_INPUT, S_OUTPUT, S_FMT, S_TUNER, S_MODULATOR, S_FREQUENCY, > > S_MODULATOR doesn't need to take a token. Certainly not a tuner token, > since it is a modulator, not a tuner. There aren't many modulator drivers, > and none of them have different modes. > > The same is true for S_OUTPUT: it deals with outputs, so it has nothing > to do with tuners since those are for input. ok I will remove these. I will have to check why I added S_OUTPUT - maybe au0828 does something in its vidioc_ If it does something it can be handled in the driver. S_MODULATOR can go - I kept adding ioctls as I detected them to cause problems, and this might have been one of the ones I added as the first set. > >> S_STD, S_HW_FREQ_SEEK: >> >> - hold tuner in shared analog mode before calling appropriate >> ops->vidioc_s_* >> - return leaving tuner in shared mode. >> - Note that S_MODULATOR is now implemented in the core >> previously FCN. >> >> QUERYSTD: >> - hold tuner in shared analog mode before calling >> ops->vidioc_querystd >> - return after calling put tuner - this simply decrements the >> owners. Leaves tuner in shared analog mode if owners > 0 > > I would handle QUERYSTD the same as the ones in the first group. > It's a fair assumption that once you call QUERYSTD you expect to > switch the tuner to analog mode and keep it there. > > I'm missing STREAMON in this list as well. Yes on STREAMON. ok I will make the changes. Do you want to see STREAMON changes in vb1 or vb2? In our previous discussion, we decides to make the STERANON changes in vb2 layer and handle vb1 in the driver. > > With regards to G_TUNER and ENUM_INPUT, I will reply to the post that > discusses that topic. > >> >> v4l2_fh_exit: >> - resets the media tuner token. A simple put token could leave >> the token in shared mode. The nature of analog token holds >> is unbalanced requiring a reset to clear it. > > Nack on the reset. It should just put the tuner token. > > The way it should work is that whenever an ioctl is issued that needs to > take a tuner token, then it should check if the filehandle already has a > token. If not, then take the token if possible. If it has, then check if > the token is in the right mode and continue if that's the case, otherwise > return EBUSY. I don't think it can ever be in the wrong mode, but it > doesn't hurt to check. Or do WARN_ON or something like that. Yes that would work. Thanks. > > This way each filehandle will take a token only once, and it is released > when the filehandle is closed. > > You do need to store in struct v4l2_fh whether or not a token was obtained > so the v4l2_fh_exit knows to release it. > > Almost all drivers support v4l2_fh by now, so I wouldn't bother with > drivers > that don't support v4l2_fh. ok. au0828 calls fh_exit() from its close routine and then does a tuner reset later. I did change the driver close to handle this case. > >> >> Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> >> --- >> drivers/media/v4l2-core/v4l2-fh.c | 16 ++++++ >> drivers/media/v4l2-core/v4l2-ioctl.c | 96 >> +++++++++++++++++++++++++++++++++- >> 2 files changed, 110 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/v4l2-core/v4l2-fh.c >> b/drivers/media/v4l2-core/v4l2-fh.c >> index c97067a..81ce3f9 100644 >> --- a/drivers/media/v4l2-core/v4l2-fh.c >> +++ b/drivers/media/v4l2-core/v4l2-fh.c >> @@ -25,7 +25,10 @@ >> #include <linux/bitops.h> >> #include <linux/slab.h> >> #include <linux/export.h> >> +#include <linux/device.h> >> +#include <linux/media_tknres.h> >> #include <media/v4l2-dev.h> >> +#include <media/v4l2-device.h> >> #include <media/v4l2-fh.h> >> #include <media/v4l2-event.h> >> #include <media/v4l2-ioctl.h> >> @@ -92,6 +95,19 @@ void v4l2_fh_exit(struct v4l2_fh *fh) >> { >> if (fh->vdev == NULL) >> return; >> + >> + if (fh->vdev->dev_parent) { >> + enum media_tkn_mode mode; >> + >> + mode = (fh->vdev->vfl_type == V4L2_TUNER_RADIO) ? >> + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; >> + /* reset the token - the nature of token get in >> + analog mode is shared and unbalanced. There is >> + no clear start and stop, so shared token might >> + never get cleared */ >> + media_reset_shared_tuner_tkn(fh->vdev->dev_parent, mode); > > As mentioned above, this should just be a put, not a reset. ok on that. > >> + } >> + >> v4l2_event_unsubscribe_all(fh); >> fh->vdev = NULL; >> } >> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c >> b/drivers/media/v4l2-core/v4l2-ioctl.c >> index d15e167..9e1f042 100644 >> --- a/drivers/media/v4l2-core/v4l2-ioctl.c >> +++ b/drivers/media/v4l2-core/v4l2-ioctl.c >> @@ -17,6 +17,7 @@ >> #include <linux/types.h> >> #include <linux/kernel.h> >> #include <linux/version.h> >> +#include <linux/media_tknres.h> >> >> #include <linux/videodev2.h> >> >> @@ -1003,6 +1004,37 @@ static void v4l_sanitize_format(struct >> v4l2_format *fmt) >> sizeof(fmt->fmt.pix) - offset); >> } >> >> +static int v4l_get_tuner_tkn(struct video_device *vfd, >> + enum v4l2_tuner_type type) >> +{ >> + int ret = 0; >> + >> + if (vfd->dev_parent) { >> + enum media_tkn_mode mode; >> + >> + mode = (type == V4L2_TUNER_RADIO) ? >> + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; >> + ret = media_get_shared_tuner_tkn(vfd->dev_parent, mode); >> + if (ret) >> + dev_info(vfd->dev_parent, >> + "%s: Tuner is busy\n", __func__); >> + } >> + dev_dbg(vfd->dev_parent, "%s: No token?? %d\n", __func__, ret); > > Shouldn't this be in a 'else'? Now the 'No token' message is also > printed when > media_get_shared_tuner_tkn got the tuner. Yes it should have been. > >> + return ret; >> +} >> + >> +static void v4l_put_tuner_tkn(struct video_device *vfd, >> + enum v4l2_tuner_type type) >> +{ >> + if (vfd->dev_parent) { >> + enum media_tkn_mode mode; >> + >> + mode = (type == V4L2_TUNER_RADIO) ? >> + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; >> + media_put_tuner_tkn(vfd->dev_parent, mode); >> + } >> +} >> + >> static int v4l_querycap(const struct v4l2_ioctl_ops *ops, >> struct file *file, void *fh, void *arg) >> { >> @@ -1022,12 +1054,24 @@ static int v4l_querycap(const struct >> v4l2_ioctl_ops *ops, >> static int v4l_s_input(const struct v4l2_ioctl_ops *ops, >> struct file *file, void *fh, void *arg) >> { >> + struct video_device *vfd = video_devdata(file); >> + int ret = 0; >> + >> + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); >> + if (ret) >> + return ret; >> return ops->vidioc_s_input(file, fh, *(unsigned int *)arg); >> } >> >> static int v4l_s_output(const struct v4l2_ioctl_ops *ops, >> struct file *file, void *fh, void *arg) >> { >> + struct video_device *vfd = video_devdata(file); >> + int ret = 0; >> + >> + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); >> + if (ret) >> + return ret; >> return ops->vidioc_s_output(file, fh, *(unsigned int *)arg); >> } > > As mentioned, tuner tokens make no sense for s_output. Right. ack on that. > >> >> @@ -1236,6 +1280,10 @@ static int v4l_s_fmt(const struct >> v4l2_ioctl_ops *ops, >> bool is_tx = vfd->vfl_dir != VFL_DIR_RX; >> int ret; >> >> + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); >> + if (ret) >> + return ret; >> + >> v4l_sanitize_format(p); >> >> switch (p->type) { >> @@ -1415,9 +1463,13 @@ static int v4l_s_tuner(const struct >> v4l2_ioctl_ops *ops, >> { >> struct video_device *vfd = video_devdata(file); >> struct v4l2_tuner *p = arg; >> + int ret; >> >> p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ? >> V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; >> + ret = v4l_get_tuner_tkn(vfd, p->type); >> + if (ret) >> + return ret; >> return ops->vidioc_s_tuner(file, fh, p); >> } >> >> @@ -1433,6 +1485,26 @@ static int v4l_g_modulator(const struct >> v4l2_ioctl_ops *ops, >> return err; >> } >> >> +static int v4l_s_modulator(const struct v4l2_ioctl_ops *ops, >> + struct file *file, void *fh, void *arg) >> +{ >> + struct video_device *vfd = video_devdata(file); >> + struct v4l2_fh *vfh = >> + test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags) ? fh : NULL; >> + >> + if (vfh != NULL) { >> + int ret; >> + enum v4l2_tuner_type type; >> + >> + type = (vfd->vfl_type == VFL_TYPE_RADIO) ? >> + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; >> + ret = v4l_get_tuner_tkn(vfd, type); >> + if (ret) >> + return ret; >> + } >> + return ops->vidioc_s_modulator(file, fh, arg); >> +} > > Again, tuner tokens make no sense for a modulator. Yes. Will fix it. > >> + >> static int v4l_g_frequency(const struct v4l2_ioctl_ops *ops, >> struct file *file, void *fh, void *arg) >> { >> @@ -1453,6 +1525,7 @@ static int v4l_s_frequency(const struct >> v4l2_ioctl_ops *ops, >> struct video_device *vfd = video_devdata(file); >> const struct v4l2_frequency *p = arg; >> enum v4l2_tuner_type type; >> + int ret; >> >> if (vfd->vfl_type == VFL_TYPE_SDR) { >> if (p->type != V4L2_TUNER_ADC && p->type != V4L2_TUNER_RF) >> @@ -1462,6 +1535,9 @@ static int v4l_s_frequency(const struct >> v4l2_ioctl_ops *ops, >> V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; >> if (type != p->type) >> return -EINVAL; >> + ret = v4l_get_tuner_tkn(vfd, type); >> + if (ret) >> + return ret; >> } >> return ops->vidioc_s_frequency(file, fh, p); >> } >> @@ -1508,11 +1584,16 @@ static int v4l_s_std(const struct >> v4l2_ioctl_ops *ops, >> { >> struct video_device *vfd = video_devdata(file); >> v4l2_std_id id = *(v4l2_std_id *)arg, norm; >> + int ret = 0; >> >> norm = id & vfd->tvnorms; >> if (vfd->tvnorms && !norm) /* Check if std is supported */ >> return -EINVAL; >> >> + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); >> + if (ret) >> + return ret; >> + >> /* Calls the specific handler */ >> return ops->vidioc_s_std(file, fh, norm); >> } >> @@ -1522,7 +1603,11 @@ static int v4l_querystd(const struct >> v4l2_ioctl_ops *ops, >> { >> struct video_device *vfd = video_devdata(file); >> v4l2_std_id *p = arg; >> + int ret = 0; >> >> + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); >> + if (ret) >> + return ret; >> /* >> * If no signal is detected, then the driver should return >> * V4L2_STD_UNKNOWN. Otherwise it should return tvnorms with >> @@ -1532,7 +1617,9 @@ static int v4l_querystd(const struct >> v4l2_ioctl_ops *ops, >> * their efforts to improve the standards detection. >> */ >> *p = vfd->tvnorms; >> - return ops->vidioc_querystd(file, fh, arg); >> + ret = ops->vidioc_querystd(file, fh, arg); >> + v4l_put_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); > > No put needed. ok - will fix it. > >> + return ret; >> } >> >> static int v4l_s_hw_freq_seek(const struct v4l2_ioctl_ops *ops, >> @@ -1541,6 +1628,7 @@ static int v4l_s_hw_freq_seek(const struct >> v4l2_ioctl_ops *ops, >> struct video_device *vfd = video_devdata(file); >> struct v4l2_hw_freq_seek *p = arg; >> enum v4l2_tuner_type type; >> + int ret; >> >> /* s_hw_freq_seek is not supported for SDR for now */ >> if (vfd->vfl_type == VFL_TYPE_SDR) >> @@ -1550,6 +1638,9 @@ static int v4l_s_hw_freq_seek(const struct >> v4l2_ioctl_ops *ops, >> V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; >> if (p->type != type) >> return -EINVAL; >> + ret = v4l_get_tuner_tkn(vfd, type); >> + if (ret) >> + return ret; >> return ops->vidioc_s_hw_freq_seek(file, fh, p); >> } >> >> @@ -2217,7 +2308,8 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = { >> IOCTL_INFO_STD(VIDIOC_G_AUDOUT, vidioc_g_audout, >> v4l_print_audioout, 0), >> IOCTL_INFO_STD(VIDIOC_S_AUDOUT, vidioc_s_audout, >> v4l_print_audioout, INFO_FL_PRIO), >> IOCTL_INFO_FNC(VIDIOC_G_MODULATOR, v4l_g_modulator, >> v4l_print_modulator, INFO_FL_CLEAR(v4l2_modulator, index)), >> - IOCTL_INFO_STD(VIDIOC_S_MODULATOR, vidioc_s_modulator, >> v4l_print_modulator, INFO_FL_PRIO), >> + IOCTL_INFO_FNC(VIDIOC_S_FREQUENCY, v4l_s_modulator, >> + v4l_print_frequency, INFO_FL_PRIO), > > Huh? S_MODULATOR is removed and a duplicate S_FREQUENCY is added? Oops. This is a mistake. Actually I don't think I need this at all based on your earlier comment on S_MODULATOR. I will remove this. > >> IOCTL_INFO_FNC(VIDIOC_G_FREQUENCY, v4l_g_frequency, >> v4l_print_frequency, INFO_FL_CLEAR(v4l2_frequency, tuner)), >> IOCTL_INFO_FNC(VIDIOC_S_FREQUENCY, v4l_s_frequency, >> v4l_print_frequency, INFO_FL_PRIO), >> IOCTL_INFO_FNC(VIDIOC_CROPCAP, v4l_cropcap, v4l_print_cropcap, >> INFO_FL_CLEAR(v4l2_cropcap, type)), >> > > BTW, I still haven't seen how you are going to handle snd-usb-audio. I > want to > see how that is going to be handled before I will Ack anything. > Yes. Agreed. I will get the snd-usb-audio changes in before I send out the next version. thanks, -- Shuah
On 09/24/2014 05:57 AM, Hans Verkuil wrote: > Hi Shuah, > > Here is my review... > > On 09/22/2014 05:00 PM, Shuah Khan wrote: >> Changes to v4l2-core to hold tuner token in v4l2 ioctl that change >> the tuner modes, and reset the token from fh exit. The changes are >> limited to vb2 calls that disrupt digital stream. vb1 changes are >> made in the driver. The following ioctls are changed: >> >> S_INPUT, S_OUTPUT, S_FMT, S_TUNER, S_MODULATOR, S_FREQUENCY, > > S_MODULATOR doesn't need to take a token. Certainly not a tuner token, > since it is a modulator, not a tuner. There aren't many modulator drivers, > and none of them have different modes. > > The same is true for S_OUTPUT: it deals with outputs, so it has nothing > to do with tuners since those are for input. > >> S_STD, S_HW_FREQ_SEEK: >> >> - hold tuner in shared analog mode before calling appropriate >> ops->vidioc_s_* >> - return leaving tuner in shared mode. >> - Note that S_MODULATOR is now implemented in the core >> previously FCN. >> >> QUERYSTD: >> - hold tuner in shared analog mode before calling >> ops->vidioc_querystd >> - return after calling put tuner - this simply decrements the >> owners. Leaves tuner in shared analog mode if owners > 0 > > I would handle QUERYSTD the same as the ones in the first group. > It's a fair assumption that once you call QUERYSTD you expect to > switch the tuner to analog mode and keep it there. > > I'm missing STREAMON in this list as well. > > With regards to G_TUNER and ENUM_INPUT, I will reply to the post that > discusses that topic. Hans, Didn't see you address G_TUNER and ENUM_INPUT in your other response. Hope I didn't miss it. thanks, -- Shuah
On 09/24/2014 06:25 AM, Hans Verkuil wrote: > Hi Shuah, > > > Let's be realistic: if an application doesn't test for error codes, > then that's the problem of the application. Also, EBUSY will only be > returned if someone else is holding the tuner in a different mode. > And that didn't work anyway (and probably in worse ways too if the > driver would forcefully change the tuner mode). > > So I really don't see a problem with this. > I didn't have high hopes you would agree to the simpler approach. :) >> >> Compared to the current approach, holding lock in open and releasing >> it in close is cleaner with predictable failure conditions. It is lot >> easier to maintain. In addition, this approach keeps it same as the >> dvb core token hold approach as outlined below. > > Absolutely not an option for v4l2. You should always be able to open > a v4l2 device, regardless of the tuner mode or any other mode. > > The only exception is a radio tuner device: that should take the tuner > on open. I think this is a very unfortunate design and I wish that that > could be dropped. Right this is another problem that needs to be addressed in the user-space. > > One thing that we haven't looked at at all is what should be done if > the current input is not a tuner but a composite or S-Video input. > > It is likely (I would have to test this to be sure) that you can capture > from a DVB tuner and at the same time from an S-Video input without any > problems. By taking the tuner token unconditionally this would become > impossible. But doing this right will require more work. > > BTW, what happens if the analog video part of a hybrid board doesn't have > a tuner but only S-Video/Composite inputs? I think I've seen such boards > actually. I would have to dig through my collection though. > I would recommend trying to bound the problems that need to be solved for the first phase of this media token feature. If we don't we will never be done with it. :) I would propose the first step as addressing dvb and v4l2 conflicts and include snd-usb-audio so there is confidence that the media token approach can span non-media drivers. I am currently testing with tvtime, xawtv, vlc, and kaffeine. I am planning to add kradio for snd-usb-audio work for the next round of patches. > > S_PRIORITY has nothing to do with tuner ownership. If there is a real need > to release the token at another time than on close (and I don't see > such a need), then make a new ioctl. Let's not overload S_PRIO with an > unrelated action. This is not an issue for fine grained approach since simpler approach is nacked. i.e Mauro suggested changing S_PRIORITY as another place to release it if we were to go with simple appraoch (open/close). > >> >> Devin recommended testing on devices that have an encoder to cover >> the cases where there are multiple /dev/videoX nodes tied to the >> same tuner. > > Good examples are cx23885 (already vb2) and cx88 (the vb2 patches have > been posted, but not yet merged). It shouldn't be too hard to find > hardware based on those chipsets. > Please see my bounding the problem comment. Can these devices wait until the second phase. We have multiple combinations with hardware features, applications. The way I am designing the media token is if driver doesn't create the token, no change in the dvb-core, v4l2-core behavior. It is not required that driver must create a token to allow evolving driver support and hardware support as we go. thanks, -- Shuah
On 09/24/2014 05:57 PM, Shuah Khan wrote: > On 09/24/2014 06:25 AM, Hans Verkuil wrote: >> Hi Shuah, >> >> >> Let's be realistic: if an application doesn't test for error codes, >> then that's the problem of the application. Also, EBUSY will only be >> returned if someone else is holding the tuner in a different mode. >> And that didn't work anyway (and probably in worse ways too if the >> driver would forcefully change the tuner mode). >> >> So I really don't see a problem with this. >> > > I didn't have high hopes you would agree to the simpler approach. :) > >>> >>> Compared to the current approach, holding lock in open and releasing >>> it in close is cleaner with predictable failure conditions. It is lot >>> easier to maintain. In addition, this approach keeps it same as the >>> dvb core token hold approach as outlined below. >> >> Absolutely not an option for v4l2. You should always be able to open >> a v4l2 device, regardless of the tuner mode or any other mode. >> >> The only exception is a radio tuner device: that should take the tuner >> on open. I think this is a very unfortunate design and I wish that that >> could be dropped. > > Right this is another problem that needs to be addressed in the > user-space. This is however out-of-scope for your project. For radio devices you can just take the tuner token on open. BTW, the tuner token in v4l2 should *only* be taken if there actually is a tuner. Luckily that's very easy to test for: struct v4l2_ioctl_ops will have a non-NULL vidioc_s_tuner field. > >> >> One thing that we haven't looked at at all is what should be done if >> the current input is not a tuner but a composite or S-Video input. >> >> It is likely (I would have to test this to be sure) that you can capture >> from a DVB tuner and at the same time from an S-Video input without any >> problems. By taking the tuner token unconditionally this would become >> impossible. But doing this right will require more work. >> >> BTW, what happens if the analog video part of a hybrid board doesn't have >> a tuner but only S-Video/Composite inputs? I think I've seen such boards >> actually. I would have to dig through my collection though. >> > > I would recommend trying to bound the problems that need to be solved > for the first phase of this media token feature. If we don't we will > never be done with it. :) I want to think about this myself (i.e. non-tuner inputs) and do some testing as well. I'll get back to this when I know more myself. > > I would propose the first step as addressing dvb and v4l2 conflicts > and include snd-usb-audio so there is confidence that the media token > approach can span non-media drivers. Certainly. > I am currently testing with tvtime, xawtv, vlc, and kaffeine. I am > planning to add kradio for snd-usb-audio work for the next round of > patches. > >> >> S_PRIORITY has nothing to do with tuner ownership. If there is a real need >> to release the token at another time than on close (and I don't see >> such a need), then make a new ioctl. Let's not overload S_PRIO with an >> unrelated action. > > This is not an issue for fine grained approach since simpler approach > is nacked. i.e Mauro suggested changing S_PRIORITY as another place > to release it if we were to go with simple appraoch (open/close). > >> >>> >>> Devin recommended testing on devices that have an encoder to cover >>> the cases where there are multiple /dev/videoX nodes tied to the >>> same tuner. >> >> Good examples are cx23885 (already vb2) and cx88 (the vb2 patches have >> been posted, but not yet merged). It shouldn't be too hard to find >> hardware based on those chipsets. >> > > Please see my bounding the problem comment. Can these devices wait until > the second phase. We have multiple combinations with hardware features, > applications. The way I am designing the media token is if driver > doesn't create the token, no change in the dvb-core, v4l2-core behavior. > It is not required that driver must create a token to allow evolving > driver support and hardware support as we go. From what I know I don't think these types of devices will pose any problem for this approach. However, in general you should consider all sorts of combinations and see if the design will still work for those. You don't want to have to redesign it later just because you ignored a particular type of device. Which I why I want to see the snd-usb-audio work first, since I think that's probably the most complex part of the whole design. And I do think you should try to get one of those cards (cx88 or cx23885 based). They are common, they are complex and have hybrid tuners, sometimes with radio support as well. You can probably get some of them fairly cheaply on ebay. These are good cards to test with, if not now then in the near future. My philosophy is that you can never have too much hardware :-) Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hans, On Wednesday 24 September 2014 14:25:59 Hans Verkuil wrote: > On 09/23/2014 10:46 PM, Shuah Khan wrote: > > Hi Devin/Mauro/Hans, > > > > Summarizing the discussion on v4l to keep others on this > > thread in the loop. Please see below: > > > > Hans! Could you please take a look and see if it raises > > any red flags for you. > > > > On 09/23/2014 08:17 AM, Devin Heitmueller wrote: > >> We can always start with coarse locking on open/close, and do finer > >> grained locking down the road if needed - or simply change the > >> currently undefined behavior in the spec to say that you have to close > >> the device handle before attempting to open the other side of the > >> device. > > > > I share the same concerns about fine grain locking approach that > > requires changes to various v4l2 ioctls to hold the token. My > > concern with the current approach is that we won't be able to find > > all the v4l paths to secure. During my testing, it is clear that > > several applications don't seem to check ioctls return codes and > > even if one of the ioctls returns -EBUSY, applications keep calling > > other ioctls instead of exiting with device busy condition. > > Let's be realistic: if an application doesn't test for error codes, > then that's the problem of the application. Also, EBUSY will only be > returned if someone else is holding the tuner in a different mode. > And that didn't work anyway (and probably in worse ways too if the > driver would forcefully change the tuner mode). > > So I really don't see a problem with this. I somehow agree, but I believe for this to work we need to offer applications with a way to find out about the constraints associated with the shared tuner. We can't expect userspace to properly deal with errors if they can't find out from information exposed by the kernel how to deal with them. From an end-user point of view, a dialog box saying EBUSY is pretty much useless if we can't tell the user that they can't watch TV on their XYZ DVB device because the radio device ABC is currently in use. > > Compared to the current approach, holding lock in open and releasing > > it in close is cleaner with predictable failure conditions. It is lot > > easier to maintain. In addition, this approach keeps it same as the > > dvb core token hold approach as outlined below. > > Absolutely not an option for v4l2. You should always be able to open > a v4l2 device, regardless of the tuner mode or any other mode. > > The only exception is a radio tuner device: that should take the tuner > on open. I think this is a very unfortunate design and I wish that that > could be dropped. > > One thing that we haven't looked at at all is what should be done if > the current input is not a tuner but a composite or S-Video input. > > It is likely (I would have to test this to be sure) that you can capture > from a DVB tuner and at the same time from an S-Video input without any > problems. By taking the tuner token unconditionally this would become > impossible. But doing this right will require more work. > > BTW, what happens if the analog video part of a hybrid board doesn't have > a tuner but only S-Video/Composite inputs? I think I've seen such boards > actually. I would have to dig through my collection though. > > > dvb on the other hand is easier with its clean entry and exit points. > > In the case of dvb, the lock is held when the device is opened in > > read/write mode before dvb front-end thread gets started and released > > when thread exits. > > > > I discussed this a couple of times in the past during development > > for this current patch series. The concern has been that a number of > > currently supported use-cases will break with the simpler approach > > to lock when v4l device is opened and unlock when it is closed. > > > > As we discussed this morning and agreed on giving the simpler > > approach a try first keeping the finer grain locking option > > open for revisit. This would be acceptable provided the token > > code is tested on existing apps, including mythtv, kradio, > > gnome-radio. > > Nack from me. Taking a tuner token should only happen when the device > actually needs the tuner. For DVB that's easy, since whenever you open > the frontend you *know* you want the tuner. > > But that's much more difficult for V4L2 since there are so many > combinations, including many that don't need a tuner at all such as HDMI, > Composite etc. inputs. > > > In addition to releasing the token at device close, release the token > > if an app decides to use S_PRIORITY to release the streaming ownership > > e. g. V4L2_PRIORITY_BACKGROUND > > S_PRIORITY has nothing to do with tuner ownership. If there is a real need > to release the token at another time than on close (and I don't see > such a need), then make a new ioctl. Let's not overload S_PRIO with an > unrelated action. > > > Devin recommended testing on devices that have an encoder to cover > > the cases where there are multiple /dev/videoX nodes tied to the > > same tuner. > > Good examples are cx23885 (already vb2) and cx88 (the vb2 patches have > been posted, but not yet merged). It shouldn't be too hard to find > hardware based on those chipsets. > > > Please check if I captured it correctly. I can get started on the > > simpler approach and see where it takes us. I have to change the > > v4l2 and driver v4l2 patches. dvb and the rest can stay the same. > > As mentioned, Nack for the simpler approach from me. That's simply > too simple :-) > > Note: I'm travelling and attending a conference, so my availability for > the rest of the week will probably be limited.
diff --git a/drivers/media/v4l2-core/v4l2-fh.c b/drivers/media/v4l2-core/v4l2-fh.c index c97067a..81ce3f9 100644 --- a/drivers/media/v4l2-core/v4l2-fh.c +++ b/drivers/media/v4l2-core/v4l2-fh.c @@ -25,7 +25,10 @@ #include <linux/bitops.h> #include <linux/slab.h> #include <linux/export.h> +#include <linux/device.h> +#include <linux/media_tknres.h> #include <media/v4l2-dev.h> +#include <media/v4l2-device.h> #include <media/v4l2-fh.h> #include <media/v4l2-event.h> #include <media/v4l2-ioctl.h> @@ -92,6 +95,19 @@ void v4l2_fh_exit(struct v4l2_fh *fh) { if (fh->vdev == NULL) return; + + if (fh->vdev->dev_parent) { + enum media_tkn_mode mode; + + mode = (fh->vdev->vfl_type == V4L2_TUNER_RADIO) ? + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; + /* reset the token - the nature of token get in + analog mode is shared and unbalanced. There is + no clear start and stop, so shared token might + never get cleared */ + media_reset_shared_tuner_tkn(fh->vdev->dev_parent, mode); + } + v4l2_event_unsubscribe_all(fh); fh->vdev = NULL; } diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index d15e167..9e1f042 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -17,6 +17,7 @@ #include <linux/types.h> #include <linux/kernel.h> #include <linux/version.h> +#include <linux/media_tknres.h> #include <linux/videodev2.h> @@ -1003,6 +1004,37 @@ static void v4l_sanitize_format(struct v4l2_format *fmt) sizeof(fmt->fmt.pix) - offset); } +static int v4l_get_tuner_tkn(struct video_device *vfd, + enum v4l2_tuner_type type) +{ + int ret = 0; + + if (vfd->dev_parent) { + enum media_tkn_mode mode; + + mode = (type == V4L2_TUNER_RADIO) ? + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; + ret = media_get_shared_tuner_tkn(vfd->dev_parent, mode); + if (ret) + dev_info(vfd->dev_parent, + "%s: Tuner is busy\n", __func__); + } + dev_dbg(vfd->dev_parent, "%s: No token?? %d\n", __func__, ret); + return ret; +} + +static void v4l_put_tuner_tkn(struct video_device *vfd, + enum v4l2_tuner_type type) +{ + if (vfd->dev_parent) { + enum media_tkn_mode mode; + + mode = (type == V4L2_TUNER_RADIO) ? + MEDIA_MODE_RADIO : MEDIA_MODE_ANALOG; + media_put_tuner_tkn(vfd->dev_parent, mode); + } +} + static int v4l_querycap(const struct v4l2_ioctl_ops *ops, struct file *file, void *fh, void *arg) { @@ -1022,12 +1054,24 @@ static int v4l_querycap(const struct v4l2_ioctl_ops *ops, static int v4l_s_input(const struct v4l2_ioctl_ops *ops, struct file *file, void *fh, void *arg) { + struct video_device *vfd = video_devdata(file); + int ret = 0; + + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); + if (ret) + return ret; return ops->vidioc_s_input(file, fh, *(unsigned int *)arg); } static int v4l_s_output(const struct v4l2_ioctl_ops *ops, struct file *file, void *fh, void *arg) { + struct video_device *vfd = video_devdata(file); + int ret = 0; + + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); + if (ret) + return ret; return ops->vidioc_s_output(file, fh, *(unsigned int *)arg); } @@ -1236,6 +1280,10 @@ static int v4l_s_fmt(const struct v4l2_ioctl_ops *ops, bool is_tx = vfd->vfl_dir != VFL_DIR_RX; int ret; + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); + if (ret) + return ret; + v4l_sanitize_format(p); switch (p->type) { @@ -1415,9 +1463,13 @@ static int v4l_s_tuner(const struct v4l2_ioctl_ops *ops, { struct video_device *vfd = video_devdata(file); struct v4l2_tuner *p = arg; + int ret; p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; + ret = v4l_get_tuner_tkn(vfd, p->type); + if (ret) + return ret; return ops->vidioc_s_tuner(file, fh, p); } @@ -1433,6 +1485,26 @@ static int v4l_g_modulator(const struct v4l2_ioctl_ops *ops, return err; } +static int v4l_s_modulator(const struct v4l2_ioctl_ops *ops, + struct file *file, void *fh, void *arg) +{ + struct video_device *vfd = video_devdata(file); + struct v4l2_fh *vfh = + test_bit(V4L2_FL_USES_V4L2_FH, &vfd->flags) ? fh : NULL; + + if (vfh != NULL) { + int ret; + enum v4l2_tuner_type type; + + type = (vfd->vfl_type == VFL_TYPE_RADIO) ? + V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; + ret = v4l_get_tuner_tkn(vfd, type); + if (ret) + return ret; + } + return ops->vidioc_s_modulator(file, fh, arg); +} + static int v4l_g_frequency(const struct v4l2_ioctl_ops *ops, struct file *file, void *fh, void *arg) { @@ -1453,6 +1525,7 @@ static int v4l_s_frequency(const struct v4l2_ioctl_ops *ops, struct video_device *vfd = video_devdata(file); const struct v4l2_frequency *p = arg; enum v4l2_tuner_type type; + int ret; if (vfd->vfl_type == VFL_TYPE_SDR) { if (p->type != V4L2_TUNER_ADC && p->type != V4L2_TUNER_RF) @@ -1462,6 +1535,9 @@ static int v4l_s_frequency(const struct v4l2_ioctl_ops *ops, V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; if (type != p->type) return -EINVAL; + ret = v4l_get_tuner_tkn(vfd, type); + if (ret) + return ret; } return ops->vidioc_s_frequency(file, fh, p); } @@ -1508,11 +1584,16 @@ static int v4l_s_std(const struct v4l2_ioctl_ops *ops, { struct video_device *vfd = video_devdata(file); v4l2_std_id id = *(v4l2_std_id *)arg, norm; + int ret = 0; norm = id & vfd->tvnorms; if (vfd->tvnorms && !norm) /* Check if std is supported */ return -EINVAL; + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); + if (ret) + return ret; + /* Calls the specific handler */ return ops->vidioc_s_std(file, fh, norm); } @@ -1522,7 +1603,11 @@ static int v4l_querystd(const struct v4l2_ioctl_ops *ops, { struct video_device *vfd = video_devdata(file); v4l2_std_id *p = arg; + int ret = 0; + ret = v4l_get_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); + if (ret) + return ret; /* * If no signal is detected, then the driver should return * V4L2_STD_UNKNOWN. Otherwise it should return tvnorms with @@ -1532,7 +1617,9 @@ static int v4l_querystd(const struct v4l2_ioctl_ops *ops, * their efforts to improve the standards detection. */ *p = vfd->tvnorms; - return ops->vidioc_querystd(file, fh, arg); + ret = ops->vidioc_querystd(file, fh, arg); + v4l_put_tuner_tkn(vfd, V4L2_TUNER_ANALOG_TV); + return ret; } static int v4l_s_hw_freq_seek(const struct v4l2_ioctl_ops *ops, @@ -1541,6 +1628,7 @@ static int v4l_s_hw_freq_seek(const struct v4l2_ioctl_ops *ops, struct video_device *vfd = video_devdata(file); struct v4l2_hw_freq_seek *p = arg; enum v4l2_tuner_type type; + int ret; /* s_hw_freq_seek is not supported for SDR for now */ if (vfd->vfl_type == VFL_TYPE_SDR) @@ -1550,6 +1638,9 @@ static int v4l_s_hw_freq_seek(const struct v4l2_ioctl_ops *ops, V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV; if (p->type != type) return -EINVAL; + ret = v4l_get_tuner_tkn(vfd, type); + if (ret) + return ret; return ops->vidioc_s_hw_freq_seek(file, fh, p); } @@ -2217,7 +2308,8 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = { IOCTL_INFO_STD(VIDIOC_G_AUDOUT, vidioc_g_audout, v4l_print_audioout, 0), IOCTL_INFO_STD(VIDIOC_S_AUDOUT, vidioc_s_audout, v4l_print_audioout, INFO_FL_PRIO), IOCTL_INFO_FNC(VIDIOC_G_MODULATOR, v4l_g_modulator, v4l_print_modulator, INFO_FL_CLEAR(v4l2_modulator, index)), - IOCTL_INFO_STD(VIDIOC_S_MODULATOR, vidioc_s_modulator, v4l_print_modulator, INFO_FL_PRIO), + IOCTL_INFO_FNC(VIDIOC_S_FREQUENCY, v4l_s_modulator, + v4l_print_frequency, INFO_FL_PRIO), IOCTL_INFO_FNC(VIDIOC_G_FREQUENCY, v4l_g_frequency, v4l_print_frequency, INFO_FL_CLEAR(v4l2_frequency, tuner)), IOCTL_INFO_FNC(VIDIOC_S_FREQUENCY, v4l_s_frequency, v4l_print_frequency, INFO_FL_PRIO), IOCTL_INFO_FNC(VIDIOC_CROPCAP, v4l_cropcap, v4l_print_cropcap, INFO_FL_CLEAR(v4l2_cropcap, type)),
Changes to v4l2-core to hold tuner token in v4l2 ioctl that change the tuner modes, and reset the token from fh exit. The changes are limited to vb2 calls that disrupt digital stream. vb1 changes are made in the driver. The following ioctls are changed: S_INPUT, S_OUTPUT, S_FMT, S_TUNER, S_MODULATOR, S_FREQUENCY, S_STD, S_HW_FREQ_SEEK: - hold tuner in shared analog mode before calling appropriate ops->vidioc_s_* - return leaving tuner in shared mode. - Note that S_MODULATOR is now implemented in the core previously FCN. QUERYSTD: - hold tuner in shared analog mode before calling ops->vidioc_querystd - return after calling put tuner - this simply decrements the owners. Leaves tuner in shared analog mode if owners > 0 v4l2_fh_exit: - resets the media tuner token. A simple put token could leave the token in shared mode. The nature of analog token holds is unbalanced requiring a reset to clear it. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> --- drivers/media/v4l2-core/v4l2-fh.c | 16 ++++++ drivers/media/v4l2-core/v4l2-ioctl.c | 96 +++++++++++++++++++++++++++++++++- 2 files changed, 110 insertions(+), 2 deletions(-)