| commit | e0fadfd34dda2205b296b8826acfaaf4df2e022f | |
| author | Aidan Thornton <makosoft@googlemail.com> | |
| Sun, 13 Apr 2008 17:56:02 +0000 (13 14:56 -0300) | ||
| committer | Mauro Carvalho Chehab <mchehab@infradead.org> | |
| Thu, 24 Apr 2008 17:08:47 +0000 (24 14:08 -0300) | ||
| tree | 2c061c373e64f4c0ee3209f7b70a6db9ca5df3be | treesnapshot (tar.gz zip) |
| parent | e74153d44a57d9445fb1dfad7c3accbec6d4a873 | commitdiff |
V4L/DVB (7548): Various fixes for the em28xx videobuf code
- Aborting buffer_filled if no-one's waiting on the waitqueue probably isn't
what we want, since just because no-one's waiting for it now doesn't mean they
wouldn't dequeue it in time. (vivi gets away with this, possibly because it
can fill each buffer much faster.)
- The first BUG_ON(lencopy <= 0); really isn't worth causing a kernel panic
over, especially since there are some reasons why it could trigger in normal use.
- The top and botom frames are actually the wrong way around.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
- Aborting buffer_filled if no-one's waiting on the waitqueue probably isn't
what we want, since just because no-one's waiting for it now doesn't mean they
wouldn't dequeue it in time. (vivi gets away with this, possibly because it
can fill each buffer much faster.)
- The first BUG_ON(lencopy <= 0); really isn't worth causing a kernel panic
over, especially since there are some reasons why it could trigger in normal use.
- The top and botom frames are actually the wrong way around.
Signed-off-by: Aidan Thornton <makosoft@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
| drivers/media/video/em28xx/em28xx-video.c | diffblobblamehistory |