From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Brandon Philips <brandon@ifup.org>
Cc: v4l-dvb-maintainer@linuxtv.org, video4linux-list@redhat.com
Subject: Re: [PATCH 7 of 9] vivi: Simplify the vivi driver and avoid deadlocks
Date: Fri, 28 Mar 2008 15:34:42 -0300 [thread overview]
Message-ID: <20080328153442.58b2c108@gaivota> (raw)
In-Reply-To: <304e0a371d12f77e1575.1206699518@localhost>
Hi Brandon,
I'll try to test the patch series. They seems fine to my eyes, on a first look.
I have just some comments about patch 7/9.
> Also, is anyone using videobuf-vmalloc besides vivi? The current videobuf API
> feels over extended trying to take on the task of a second backend type.
The only current driver at the tree using videobuf-vmalloc is vivi.
There's another driver using it at tm6000 driver, not merged yet [1].
On Fri, 28 Mar 2008 03:18:38 -0700
Brandon Philips <brandon@ifup.org> wrote:
> --- a/linux/drivers/media/video/vivi.c
> +++ b/linux/drivers/media/video/vivi.c
> @@ -5,6 +5,7 @@
> * Mauro Carvalho Chehab <mchehab--a.t--infradead.org>
> * Ted Walther <ted--a.t--enumera.com>
> * John Sokol <sokol--a.t--videotechnology.com>
> + * Brandon Philips <brandon@ifup.org>
This is under copyright (2006), as if you were one of the authors of the
original driver. Also, I prefer if you add a short line bellow your copyright
for the job you've done on the driver. Something like:
+ *
+ * Copyright (c) 2008 by Brandon Philips <brandon@ifup.org>
+ * - Fix bad locks and cleans up streaming code
> -static int restart_video_queue(struct vivi_dmaqueue *dma_q)
> -{
...
> -}
While the restart and timeout code is not needed on vivi driver, IMO, we should
keep it, since the main reason for this driver is to be a reference code.
This kind of code is important on real drivers, since the IRQ's may not be called
for some reason. On cx88 and on saa7134, this happens on several situations[2].
Without a timeout, the driver will wait forever to receive a buffer.
This task is also needed by tm6000 driver, for the same reasons.
[1] Available at: http://linuxtv.org/hg/~mchehab/tm6010
[2] For example, I suffered an issue yesterday with my machine, that I believe
to be caused by an excess of power consumption. The effect is that cx88 weren't
generating DMA interrupts, if I loaded my machine with 3 pci boards. The
removal of one board made the cx88 board to work again. I'll test today again
with a newer power supply. Without the timeout code, the player would just
hang, waiting forever for some data at the video buffer.
Cheers,
Mauro
--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
next prev parent reply other threads:[~2008-03-28 18:35 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-28 10:18 [PATCH 0 of 9] videobuf fixes Brandon Philips
2008-03-28 10:18 ` [PATCH 1 of 9] soc_camera: Introduce a spinlock for use with videobuf Brandon Philips
2008-03-28 20:53 ` Guennadi Liakhovetski
2008-03-29 3:59 ` Brandon Philips
2008-04-04 13:46 ` [PATCH] soc-camera: use a spinlock for videobuffer queue Guennadi Liakhovetski
2008-04-04 20:17 ` Brandon Philips
2008-03-28 10:18 ` [PATCH 2 of 9] videobuf: Require spinlocks for all videobuf users Brandon Philips
2008-03-28 10:18 ` [PATCH 3 of 9] videobuf: Wakeup queues after changing the state to ERROR Brandon Philips
2008-03-28 10:18 ` [PATCH 4 of 9] videobuf: Simplify videobuf_waiton logic and possibly avoid missed wakeup Brandon Philips
2008-03-28 10:18 ` [PATCH 5 of 9] videobuf-vmalloc.c: Remove buf_release from videobuf_vm_close Brandon Philips
2008-03-28 10:18 ` [PATCH 6 of 9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure Brandon Philips
[not found] ` <20080405131236.7c083554@gaivota>
[not found] ` <20080406080011.GA3596@plankton.ifup.org>
[not found] ` <20080407183226.703217fc@gaivota>
[not found] ` <20080408152238.GA8438@plankton.public.utexas.edu>
2008-04-08 18:40 ` Mauro Carvalho Chehab
[not found] ` <c8b4dbe10804081306xb1e8f91q64d1e6d18d3d2531@mail.gmail.com>
2008-04-08 20:50 ` Mauro Carvalho Chehab
[not found] ` <c8b4dbe10804090626l6b2b10d9p1c22e02dfe2850fe@mail.gmail.com>
2008-04-09 20:42 ` Mauro Carvalho Chehab
[not found] ` <20080408204514.GA6844@plankton.public.utexas.edu>
2008-04-08 21:37 ` Mauro Carvalho Chehab
[not found] ` <20080415021558.GA22068@plankton.ifup.org>
2008-04-15 14:10 ` Mauro Carvalho Chehab
2008-03-28 10:18 ` [PATCH 7 of 9] vivi: Simplify the vivi driver and avoid deadlocks Brandon Philips
2008-03-28 18:34 ` Mauro Carvalho Chehab [this message]
2008-03-29 5:35 ` Brandon Philips
2008-03-31 19:35 ` Mauro Carvalho Chehab
2008-03-28 10:18 ` [PATCH 8 of 9] videobuf: Avoid deadlock with QBUF and bring up to spec for empty queue Brandon Philips
2008-03-28 10:18 ` [PATCH 9 of 9] videobuf-dma-sg.c: Avoid NULL dereference and add comment about backwards compatibility Brandon Philips
2008-03-28 19:09 ` [PATCH 0 of 9] videobuf fixes Mauro Carvalho Chehab
2008-03-29 5:25 ` Brandon Philips
2008-03-29 22:49 ` Vanessa Ezekowitz
2008-03-31 18:35 ` Mauro Carvalho Chehab
2008-03-31 19:26 ` Brandon Philips
2008-03-31 21:31 ` Mauro Carvalho Chehab
2008-04-01 3:11 ` Brandon Philips
2008-04-01 20:49 ` Mauro Carvalho Chehab
2008-04-02 18:54 ` Brandon Philips
2008-04-02 20:06 ` Mauro Carvalho Chehab
2008-04-02 18:56 ` Brandon Philips
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=20080328153442.58b2c108@gaivota \
--to=mchehab@infradead.org \
--cc=brandon@ifup.org \
--cc=v4l-dvb-maintainer@linuxtv.org \
--cc=video4linux-list@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox