All of lore.kernel.org
 help / color / mirror / Atom feed
From: brandon@ifup.org
To: mchehab@infradead.org
Cc: video4linux-list@redhat.com, v4l-dvb-maintainer@linuxtv.org
Subject: [patch 0/9] videobuf fixes 2.6.25
Date: Fri, 28 Mar 2008 02:39:44 -0700	[thread overview]
Message-ID: <20080328093944.278994792@ifup.org> (raw)

Hello-

The following set fixes problems I discovered while tracking down bugs in both
vivi and videobuf.  Hopefully most of these can make it into 2.6.25 since they
all seem pretty critical.

Please take a good look at the set and test if possible.  Particularly:
  [RFC] videobuf: Avoid deadlock with QBUF

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. 

Thanks,

	Brandon

-- 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

             reply	other threads:[~2008-03-28  9:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-28  9:39 brandon [this message]
2008-03-28  9:39 ` [patch 1/9] soc_camera: Introduce a spinlock for use with videobuf brandon
2008-03-28  9:39 ` [patch 2/9] videobuf: Require spinlocks for all videobuf users brandon
2008-03-28  9:39 ` [patch 3/9] videobuf: Wakeup queues after changing the state to ERROR brandon
2008-03-28  9:39 ` [patch 4/9] videobuf: Simplify videobuf_waiton logic and possibly avoid missed wakeup brandon
2008-03-28  9:39 ` [patch 5/9] videobuf-vmalloc.c: Remove buf_release from videobuf_vm_close brandon
2008-03-28  9:39 ` [patch 6/9] videobuf-vmalloc.c: Fix hack of postponing mmap on remap failure brandon
2008-03-28  9:39 ` [patch 7/9] vivi: Simplify the vivi driver and avoid deadlocks brandon
2008-03-28  9:39 ` [patch 8/9] videobuf: Avoid deadlock with QBUF and bring up to spec for empty queue brandon
2008-03-28  9:39 ` [patch 9/9] videobuf-dma-sg.c: Avoid NULL dereference and add comment about backwards compatibility brandon

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=20080328093944.278994792@ifup.org \
    --to=brandon@ifup.org \
    --cc=mchehab@infradead.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 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.