All of lore.kernel.org
 help / color / mirror / Atom feed
From: dean <dean@sensoray.com>
To: Mike Isely <isely@isely.net>
Cc: linux-media@vger.kernel.org,
	Mauro Carvalho Chehab <mchehab@infradead.org>
Subject: Re: [PATCH] s2255drv: Don't conditionalize video buffer completion on waiting processes
Date: Wed, 23 Sep 2009 16:23:27 -0700	[thread overview]
Message-ID: <4ABAADEF.1030309@sensoray.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0909231603210.29815@cnc.isely.net>

This seems ok.  This portion of code was based on vivi.c, so that might 
be checked also.



Mike Isely wrote:
> # HG changeset patch
> # User Mike Isely <isely@pobox.com>
> # Date 1253739604 18000
> # Node ID 522a74147753ba59c7f45e368439928090a286f2
> # Parent  e349075171ddf939381fad432c23c1269abc4899
> s2255drv: Don't conditionalize video buffer completion on waiting processes
>
> From: Mike Isely <isely@pobox.com>
>
> The s2255 driver had logic which aborted processing of a video frame
> if there was no process waiting on the video buffer in question.  That
> simply doesn't work when the application is doing things in an
> asynchronous manner.  If the application went to the trouble to queue
> the buffer in the first place, then the driver should always attempt
> to complete it - even if the application at that moment has its
> attention turned elsewhere.  Applications which always blocked waiting
> for I/O on the capture device would not have been affected by this.
> Applications which *mostly* blocked waiting for I/O on the capture
> device probably only would have been somewhat affected (frame lossage,
> at a rate which goes up as the application blocks less).  Applications
> which never blocked on the capture device (e.g. polling only) however
> would never have been able to receive any video frames, since in that
> case this "is anyone waiting on this?" check on the buffer never would
> have evalutated true.  This patch just deletes that harmful check
> against the buffer's wait queue.
>
> Priority: high
>
> Signed-off-by: Mike Isely <isely@pobox.com>
>
> diff -r e349075171dd -r 522a74147753 linux/drivers/media/video/s2255drv.c
> --- a/linux/drivers/media/video/s2255drv.c	Mon Sep 21 10:42:22 2009 -0500
> +++ b/linux/drivers/media/video/s2255drv.c	Wed Sep 23 16:00:04 2009 -0500
> @@ -599,11 +599,6 @@
>  	buf = list_entry(dma_q->active.next,
>  			 struct s2255_buffer, vb.queue);
>  
> -	if (!waitqueue_active(&buf->vb.done)) {
> -		/* no one active */
> -		rc = -1;
> -		goto unlock;
> -	}
>  	list_del(&buf->vb.queue);
>  	do_gettimeofday(&buf->vb.ts);
>  	dprintk(100, "[%p/%d] wakeup\n", buf, buf->vb.i);
>
>
>   


  reply	other threads:[~2009-09-24  3:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-23 21:06 [PATCH] s2255drv: Don't conditionalize video buffer completion on waiting processes Mike Isely
2009-09-23 23:23 ` dean [this message]
2009-09-24  4:45   ` Mike Isely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ABAADEF.1030309@sensoray.com \
    --to=dean@sensoray.com \
    --cc=isely@isely.net \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.