| Message ID | 515f84cc1e6e33f647610f1bda154127944e6b52.1421115389.git.shuahkh@osg.samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Shuah, On Mon, Jan 12, 2015 at 9:56 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote: > au0828 does video and vbi buffer timeout handling to prevent > applications such as tvtime from hanging by ensuring that the > video frames continue to be delivered even when the ITU-656 > input isn't receiving any data. This work-around is complex > as it introduces set and clear timer code paths in start/stop > streaming, and close interfaces. However, tvtime will hang > without the following tvtime change: I'm confused. When we last debated whether this patch would be accepted, the last message from Mauro said the following: > That means that we'll need to keep holding such timeout code for > years, until all distros update to a new tvtime, of course assuming > that this is the only one application with such issue. In other words, the timeout code has to stay in there since otherwise it will cause ABI breakage. It's great that Hans has submitted a patch to improve tvtime, and over the next couple of years that patch might actually start to appear in distributions. That unfortunately doesn't change the fact that everybody who updates their kernel (or has it updated for them as part of their distribution) will go from "works fine" to "completely broken". The driver was working before the VB2 conversion, so if there is now instability then it's likely that some bug was introduced during the conversion to VB2. Simply ripping out the timeout code seems like the wrong approach to addressing a regression likely caused by your own VB2 conversion patch. Devin
On 01/12/2015 09:44 PM, Devin Heitmueller wrote: > Hi Shuah, > > On Mon, Jan 12, 2015 at 9:56 PM, Shuah Khan <shuahkh@osg.samsung.com> wrote: >> au0828 does video and vbi buffer timeout handling to prevent >> applications such as tvtime from hanging by ensuring that the >> video frames continue to be delivered even when the ITU-656 >> input isn't receiving any data. This work-around is complex >> as it introduces set and clear timer code paths in start/stop >> streaming, and close interfaces. However, tvtime will hang >> without the following tvtime change: > > I'm confused. When we last debated whether this patch would be > accepted, the last message from Mauro said the following: > >> That means that we'll need to keep holding such timeout code for >> years, until all distros update to a new tvtime, of course assuming >> that this is the only one application with such issue. > > In other words, the timeout code has to stay in there since otherwise > it will cause ABI breakage. It's great that Hans has submitted a > patch to improve tvtime, and over the next couple of years that patch > might actually start to appear in distributions. That unfortunately > doesn't change the fact that everybody who updates their kernel (or > has it updated for them as part of their distribution) will go from > "works fine" to "completely broken". > > The driver was working before the VB2 conversion, so if there is now > instability then it's likely that some bug was introduced during the > conversion to VB2. Simply ripping out the timeout code seems like the > wrong approach to addressing a regression likely caused by your own > VB2 conversion patch. > I couldn't reproduce what I was seeing when I did patch v2 series work. What I noticed was that I was seeing a few too many green screens and I had to re-tune xawtv when the timeout code is in place. My thinking was that this timeout handling could be introducing blank green frames when there is no need. However, I can't reproduce the problem on 3.19-rc4 base which is what I am using to test the changes to the patch series. Hence, I am not positive if the timeout code indeed was doing anything bad. I am seeing tvtime hangs without the timeout. I am fine with this patch not going. It does make the code cleaner and also reduces buffer handling during streaming. However, there is a clear regression to tvtime. thanks, -- Shuah
> I couldn't reproduce what I was seeing when I did patch v2 series > work. What I noticed was that I was seeing a few too many green screens > and I had to re-tune xawtv when the timeout code is in place. My > thinking was that this timeout handling could be introducing blank > green frames when there is no need. However, I can't reproduce the > problem on 3.19-rc4 base which is what I am using to test the changes > to the patch series. Hence, I am not positive if the timeout code > indeed was doing anything bad. IIRC, the timer was set for 40ms, so if a complete video frame doesn't arrive within that interval we generate a green frame. It was never really intended to have perfect clocking (i.e. 29.97 FPS), but is really just there to prevent the tvtime user interface from blocking indefinitely. If you weren't seeing it in the V2 series, then I guess you fixed whatever bug was present in V1. > I am seeing tvtime hangs without the timeout. I am fine with this > patch not going. It does make the code cleaner and also reduces > buffer handling during streaming. However, there is a clear regression > to tvtime. Correct. I think everybody agrees that the timer code is ugly and it would be cleaner if it wasn't needed - except it clearly is needed to prevent regressions in tvtime. All that said, I'm quite excited to see the driver converted to VB2. Nice job! Devin
diff --git a/drivers/media/usb/au0828/au0828-video.c b/drivers/media/usb/au0828/au0828-video.c index e427913..08b1e96 100644 --- a/drivers/media/usb/au0828/au0828-video.c +++ b/drivers/media/usb/au0828/au0828-video.c @@ -592,15 +592,6 @@ static inline int au0828_isoc_copy(struct au0828_dev *dev, struct urb *urb) outp = NULL; else outp = vb2_plane_vaddr(&buf->vb, 0); - - /* As long as isoc traffic is arriving, keep - resetting the timer */ - if (dev->vid_timeout_running) - mod_timer(&dev->vid_timeout, - jiffies + (HZ / 10)); - if (dev->vbi_timeout_running) - mod_timer(&dev->vbi_timeout, - jiffies + (HZ / 10)); } if (buf != NULL) { @@ -803,15 +794,9 @@ int au0828_start_analog_streaming(struct vb2_queue *vq, unsigned int count) return rc; } - if (vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) { + if (vq->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_stream, 1); - dev->vid_timeout_running = 1; - mod_timer(&dev->vid_timeout, jiffies + (HZ / 10)); - } else if (vq->type == V4L2_BUF_TYPE_VBI_CAPTURE) { - dev->vbi_timeout_running = 1; - mod_timer(&dev->vbi_timeout, jiffies + (HZ / 10)); - } } dev->streaming_users++; return rc; @@ -850,9 +835,6 @@ static void au0828_stop_streaming(struct vb2_queue *vq) (AUVI_INPUT(i).audio_setup)(dev, 0); } spin_unlock_irqrestore(&dev->slock, flags); - - dev->vid_timeout_running = 0; - del_timer_sync(&dev->vid_timeout); } void au0828_stop_vbi_streaming(struct vb2_queue *vq) @@ -881,9 +863,6 @@ void au0828_stop_vbi_streaming(struct vb2_queue *vq) vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR); } spin_unlock_irqrestore(&dev->slock, flags); - - dev->vbi_timeout_running = 0; - del_timer_sync(&dev->vbi_timeout); } static struct vb2_ops au0828_video_qops = { @@ -916,56 +895,6 @@ void au0828_analog_unregister(struct au0828_dev *dev) mutex_unlock(&au0828_sysfs_lock); } -/* This function ensures that video frames continue to be delivered even if - the ITU-656 input isn't receiving any data (thereby preventing applications - such as tvtime from hanging) */ -static void au0828_vid_buffer_timeout(unsigned long data) -{ - struct au0828_dev *dev = (struct au0828_dev *) data; - struct au0828_dmaqueue *dma_q = &dev->vidq; - struct au0828_buffer *buf; - unsigned char *vid_data; - unsigned long flags = 0; - - spin_lock_irqsave(&dev->slock, flags); - - buf = dev->isoc_ctl.buf; - if (buf != NULL) { - vid_data = vb2_plane_vaddr(&buf->vb, 0); - memset(vid_data, 0x00, buf->length); /* Blank green frame */ - buffer_filled(dev, dma_q, buf); - } - get_next_buf(dma_q, &buf); - - if (dev->vid_timeout_running == 1) - mod_timer(&dev->vid_timeout, jiffies + (HZ / 10)); - - spin_unlock_irqrestore(&dev->slock, flags); -} - -static void au0828_vbi_buffer_timeout(unsigned long data) -{ - struct au0828_dev *dev = (struct au0828_dev *) data; - struct au0828_dmaqueue *dma_q = &dev->vbiq; - struct au0828_buffer *buf; - unsigned char *vbi_data; - unsigned long flags = 0; - - spin_lock_irqsave(&dev->slock, flags); - - buf = dev->isoc_ctl.vbi_buf; - if (buf != NULL) { - vbi_data = vb2_plane_vaddr(&buf->vb, 0); - memset(vbi_data, 0x00, buf->length); - vbi_buffer_filled(dev, dma_q, buf); - } - vbi_get_next_buf(dma_q, &buf); - - if (dev->vbi_timeout_running == 1) - mod_timer(&dev->vbi_timeout, jiffies + (HZ / 10)); - spin_unlock_irqrestore(&dev->slock, flags); -} - static int au0828_v4l2_open(struct file *filp) { struct au0828_dev *dev = video_drvdata(filp); @@ -1002,7 +931,6 @@ static int au0828_v4l2_close(struct file *filp) { int ret; struct au0828_dev *dev = video_drvdata(filp); - struct video_device *vdev = video_devdata(filp); dprintk(1, "%s called std_set %d dev_state %d stream users %d users %d\n", @@ -1010,17 +938,6 @@ static int au0828_v4l2_close(struct file *filp) dev->streaming_users, dev->users); mutex_lock(&dev->lock); - if (vdev->vfl_type == VFL_TYPE_GRABBER && dev->vid_timeout_running) { - /* Cancel timeout thread in case they didn't call streamoff */ - dev->vid_timeout_running = 0; - del_timer_sync(&dev->vid_timeout); - } else if (vdev->vfl_type == VFL_TYPE_VBI && - dev->vbi_timeout_running) { - /* Cancel timeout thread in case they didn't call streamoff */ - dev->vbi_timeout_running = 0; - del_timer_sync(&dev->vbi_timeout); - } - if (dev->dev_state == DEV_DISCONNECTED) goto end; @@ -1614,11 +1531,6 @@ void au0828_v4l2_suspend(struct au0828_dev *dev) } } } - - if (dev->vid_timeout_running) - del_timer_sync(&dev->vid_timeout); - if (dev->vbi_timeout_running) - del_timer_sync(&dev->vbi_timeout); } void au0828_v4l2_resume(struct au0828_dev *dev) @@ -1632,11 +1544,6 @@ void au0828_v4l2_resume(struct au0828_dev *dev) au0828_init_tuner(dev); } - if (dev->vid_timeout_running) - mod_timer(&dev->vid_timeout, jiffies + (HZ / 10)); - if (dev->vbi_timeout_running) - mod_timer(&dev->vbi_timeout, jiffies + (HZ / 10)); - /* If we were doing ac97 instead of i2s, it would go here...*/ au0828_i2s_init(dev); @@ -1806,14 +1713,6 @@ int au0828_analog_register(struct au0828_dev *dev, INIT_LIST_HEAD(&dev->vidq.active); INIT_LIST_HEAD(&dev->vbiq.active); - dev->vid_timeout.function = au0828_vid_buffer_timeout; - dev->vid_timeout.data = (unsigned long) dev; - init_timer(&dev->vid_timeout); - - dev->vbi_timeout.function = au0828_vbi_buffer_timeout; - dev->vbi_timeout.data = (unsigned long) dev; - init_timer(&dev->vbi_timeout); - dev->width = NTSC_STD_W; dev->height = NTSC_STD_H; dev->field_size = dev->width * dev->height; diff --git a/drivers/media/usb/au0828/au0828.h b/drivers/media/usb/au0828/au0828.h index eb15187..9dac92e 100644 --- a/drivers/media/usb/au0828/au0828.h +++ b/drivers/media/usb/au0828/au0828.h @@ -221,11 +221,6 @@ struct au0828_dev { unsigned int frame_count; unsigned int vbi_frame_count; - struct timer_list vid_timeout; - int vid_timeout_running; - struct timer_list vbi_timeout; - int vbi_timeout_running; - int users; int streaming_users;
au0828 does video and vbi buffer timeout handling to prevent applications such as tvtime from hanging by ensuring that the video frames continue to be delivered even when the ITU-656 input isn't receiving any data. This work-around is complex as it introduces set and clear timer code paths in start/stop streaming, and close interfaces. However, tvtime will hang without the following tvtime change: 'tvtime: don't block indefinitely waiting for frames' with this change to remove timeout, if there is no valid video data. Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com> --- drivers/media/usb/au0828/au0828-video.c | 103 +------------------------------- drivers/media/usb/au0828/au0828.h | 5 -- 2 files changed, 1 insertion(+), 107 deletions(-)