Re: [GIT PATCHES FOR 2.6.35] videobuf refactoring
On Friday 23 April 2010 08:08:01 Mauro Carvalho Chehab wrote:
> Hans Verkuil wrote:
> > The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
> > Jonathan Corbet (1):
> > V4L/DVB: ov7670: silence some compiler warnings
> >
> > are available in the git repository at:
> >
> > git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf
> >
> > Hans Verkuil (8):
> > v4l videobuf: remove unused mmap callback.
> > v4l videobuf: remove mmap_free callback
> > v4l videobuf: remove unused is_mmapped field
> > v4l videobuf: use struct videobuf_buffer * instead of void * for
> > videobuf_alloc
> > v4l videobuf: rename .vmalloc to .vaddr
> > v4l videobuf: rename videobuf_queue_to_vmalloc to
> > videobuf_queue_to_vaddr
> > v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper
> > v4l videobuf: move video_copy_to_user and copy_stream to core.
> >
> > drivers/media/video/videobuf-core.c | 95 +++-
> > drivers/media/video/videobuf-dma-contig.c | 109 +++
> > drivers/media/video/videobuf-dma-sg.c | 139
> > -
> > drivers/media/video/videobuf-dvb.c|2 +-
> > drivers/media/video/videobuf-vmalloc.c| 104 ++
> > include/media/videobuf-core.h | 29 ++-
> > 6 files changed, 137 insertions(+), 341 deletions(-)
> >
> > Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi.
> > The tests were done with userptr, mmap and read().
> >
> > There is a lot more that needs to be done, but this is a good start.
>
> I got this error when testing the patches with a saa7134 card:
>
> [ 9171.989707] ===
> [ 9171.992696] [ INFO: possible circular locking dependency detected ]
> [ 9171.992696] 2.6.33 #3
> [ 9171.992696] ---
> [ 9171.992696] xawtv/13330 is trying to acquire lock:
> [ 9171.992696] (&mm->mmap_sem){++}, at: []
> videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
> [ 9171.992696]
> [ 9171.992696] but task is already holding lock:
> [ 9171.992696] (&q->vb_lock){+.+.+.}, at: []
> videobuf_read_one+0x3f/0x340 [videobuf_core]
> [ 9171.992696]
> [ 9171.992696] which lock already depends on the new lock.
> [ 9171.992696]
> [ 9171.992696]
> [ 9171.992696] the existing dependency chain (in reverse order) is:
> [ 9171.992696]
> [ 9171.992696] -> #1 (&q->vb_lock){+.+.+.}:
> [ 9171.992696][] __lock_acquire+0xd1d/0x1220
> [ 9171.992696][] lock_acquire+0x8d/0x100
> [ 9171.992696][] __mutex_lock_common+0x4c/0x370
> [ 9171.992696][] mutex_lock_nested+0x3f/0x50
> [ 9171.992696][] videobuf_mmap_mapper+0x39/0xf0
> [videobuf_core]
> [ 9171.992696][] video_mmap+0x29/0x40 [saa7134]
> [ 9171.992696][] v4l2_mmap+0x3b/0x40 [videodev]
> [ 9171.992696][] mmap_region+0x342/0x480
> [ 9171.992696][] do_mmap_pgoff+0x25f/0x300
> [ 9171.992696][] sys_mmap_pgoff+0x199/0x1c0
> [ 9171.992696][] sysenter_do_call+0x12/0x38
> [ 9171.992696]
> [ 9171.992696] -> #0 (&mm->mmap_sem){++}:
> [ 9171.992696][] __lock_acquire+0xfbf/0x1220
> [ 9171.992696][] lock_acquire+0x8d/0x100
> [ 9171.992696][] down_read+0x4e/0x60
> [ 9171.992696][] videobuf_dma_init_user+0x30/0x70
> [videobuf_dma_sg]
> [ 9171.992696][] __videobuf_iolock+0xc4/0x110
> [videobuf_dma_sg]
> [ 9171.992696][] videobuf_iolock+0x33/0x80 [videobuf_core]
> [ 9171.992696][] buffer_prepare+0x1d6/0x230 [saa7134]
> [ 9171.992696][] videobuf_read_one+0x176/0x340
> [videobuf_core]
> [ 9171.992696][] video_read+0x8b/0xc0 [saa7134]
> [ 9171.992696][] v4l2_read+0x5d/0x70 [videodev]
> [ 9171.992696][] vfs_read+0x9f/0x190
> [ 9171.992696][] sys_read+0x42/0x70
> [ 9171.992696][] sysenter_do_call+0x12/0x38
> [ 9171.992696]
> [ 9171.992696] other info that might help us debug this:
> [ 9171.992696]
> [ 9171.992696] 1 lock held by xawtv/13330:
> [ 9171.992696] #0: (&q->vb_lock){+.+.+.}, at: []
> videobuf_read_one+0x3f/0x340 [videobuf_core]
> [ 9171.992696]
> [ 9171.992696] stack backtrace:
> [ 9171.992696] Pid: 13330, comm: xawtv Tainted: G C 2.6.33 #3
> [ 9171.992696] Call Trace:
> [ 9171.992696] [] ? printk+0x1d/0x22
> [ 9171.992696] [] print_circular_bug+0xc2/0xd0
> [ 9171.992696] [] __lock_acquire+0xfbf/0x1220
> [ 9171.992696] [] lock_acquire+0x8d/0x100
> [ 9171.992696] [] ? videobuf_dma_init_user+0x30/0x70
> [videobuf_dma_sg]
> [ 9171.992696] [] down_read+0x4e/0x60
> [ 9171.992696] [] ? videobuf_dma_init_user+0x30/0x70
> [videobuf_dma_sg]
> [ 9171.992696] [] videobuf_dma_init_user+0x30/0x70
> [videobuf_dma_sg]
> [ 9171.992696] [] __videobuf_iolock+0xc4/0x110 [videobuf_dma_sg]
> [ 9171.992696] [] ? videobuf_dma_free+0x62/0xb0 [videobuf_dma_sg]
>
Re: [GIT PATCHES FOR 2.6.35] videobuf refactoring
Hans Verkuil wrote:
> The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d:
> Jonathan Corbet (1):
> V4L/DVB: ov7670: silence some compiler warnings
>
> are available in the git repository at:
>
> git://linuxtv.org/hverkuil/v4l-dvb-videobuf.git videobuf
>
> Hans Verkuil (8):
> v4l videobuf: remove unused mmap callback.
> v4l videobuf: remove mmap_free callback
> v4l videobuf: remove unused is_mmapped field
> v4l videobuf: use struct videobuf_buffer * instead of void * for
> videobuf_alloc
> v4l videobuf: rename .vmalloc to .vaddr
> v4l videobuf: rename videobuf_queue_to_vmalloc to
> videobuf_queue_to_vaddr
> v4l videobuf: add videobuf_buffer *buf as argument to mmap_mapper
> v4l videobuf: move video_copy_to_user and copy_stream to core.
>
> drivers/media/video/videobuf-core.c | 95 +++-
> drivers/media/video/videobuf-dma-contig.c | 109 +++
> drivers/media/video/videobuf-dma-sg.c | 139
> -
> drivers/media/video/videobuf-dvb.c|2 +-
> drivers/media/video/videobuf-vmalloc.c| 104 ++
> include/media/videobuf-core.h | 29 ++-
> 6 files changed, 137 insertions(+), 341 deletions(-)
>
> Tested with cx88-blackbird, bttv, saa7134-empress, dvb-ttpci, vivi.
> The tests were done with userptr, mmap and read().
>
> There is a lot more that needs to be done, but this is a good start.
I got this error when testing the patches with a saa7134 card:
[ 9171.989707] ===
[ 9171.992696] [ INFO: possible circular locking dependency detected ]
[ 9171.992696] 2.6.33 #3
[ 9171.992696] ---
[ 9171.992696] xawtv/13330 is trying to acquire lock:
[ 9171.992696] (&mm->mmap_sem){++}, at: []
videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696]
[ 9171.992696] but task is already holding lock:
[ 9171.992696] (&q->vb_lock){+.+.+.}, at: []
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] which lock already depends on the new lock.
[ 9171.992696]
[ 9171.992696]
[ 9171.992696] the existing dependency chain (in reverse order) is:
[ 9171.992696]
[ 9171.992696] -> #1 (&q->vb_lock){+.+.+.}:
[ 9171.992696][] __lock_acquire+0xd1d/0x1220
[ 9171.992696][] lock_acquire+0x8d/0x100
[ 9171.992696][] __mutex_lock_common+0x4c/0x370
[ 9171.992696][] mutex_lock_nested+0x3f/0x50
[ 9171.992696][] videobuf_mmap_mapper+0x39/0xf0
[videobuf_core]
[ 9171.992696][] video_mmap+0x29/0x40 [saa7134]
[ 9171.992696][] v4l2_mmap+0x3b/0x40 [videodev]
[ 9171.992696][] mmap_region+0x342/0x480
[ 9171.992696][] do_mmap_pgoff+0x25f/0x300
[ 9171.992696][] sys_mmap_pgoff+0x199/0x1c0
[ 9171.992696][] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] -> #0 (&mm->mmap_sem){++}:
[ 9171.992696][] __lock_acquire+0xfbf/0x1220
[ 9171.992696][] lock_acquire+0x8d/0x100
[ 9171.992696][] down_read+0x4e/0x60
[ 9171.992696][] videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696][] __videobuf_iolock+0xc4/0x110
[videobuf_dma_sg]
[ 9171.992696][] videobuf_iolock+0x33/0x80 [videobuf_core]
[ 9171.992696][] buffer_prepare+0x1d6/0x230 [saa7134]
[ 9171.992696][] videobuf_read_one+0x176/0x340 [videobuf_core]
[ 9171.992696][] video_read+0x8b/0xc0 [saa7134]
[ 9171.992696][] v4l2_read+0x5d/0x70 [videodev]
[ 9171.992696][] vfs_read+0x9f/0x190
[ 9171.992696][] sys_read+0x42/0x70
[ 9171.992696][] sysenter_do_call+0x12/0x38
[ 9171.992696]
[ 9171.992696] other info that might help us debug this:
[ 9171.992696]
[ 9171.992696] 1 lock held by xawtv/13330:
[ 9171.992696] #0: (&q->vb_lock){+.+.+.}, at: []
videobuf_read_one+0x3f/0x340 [videobuf_core]
[ 9171.992696]
[ 9171.992696] stack backtrace:
[ 9171.992696] Pid: 13330, comm: xawtv Tainted: G C 2.6.33 #3
[ 9171.992696] Call Trace:
[ 9171.992696] [] ? printk+0x1d/0x22
[ 9171.992696] [] print_circular_bug+0xc2/0xd0
[ 9171.992696] [] __lock_acquire+0xfbf/0x1220
[ 9171.992696] [] lock_acquire+0x8d/0x100
[ 9171.992696] [] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [] down_read+0x4e/0x60
[ 9171.992696] [] ? videobuf_dma_init_user+0x30/0x70
[videobuf_dma_sg]
[ 9171.992696] [] videobuf_dma_init_user+0x30/0x70 [videobuf_dma_sg]
[ 9171.992696] [] __videobuf_iolock+0xc4/0x110 [videobuf_dma_sg]
[ 9171.992696] [] ? videobuf_dma_free+0x62/0xb0 [videobuf_dma_sg]
[ 9171.992696] [] ? trace_hardirqs_on+0xb/0x10
[ 9171.992696] [] ? __videobuf_iolock+0x0/0x110 [videobuf_dma_sg]
[ 9171.992696] [] videobuf_iolock+0x33/0x80 [videobuf_core]
[ 9171.992696] [] ? saa7134_dma_free+0x4e/0x70 [saa7134]
[ 9171.992696] [] buffer_prepare+0x1d6/0x230 [s
Re: tm6000: Patch that will fixed analog video (tested on tm5600)
its a tm6010 chipset. I guess there might still be some missing initialisation in the mainstream codes. I think Stefan Ringel have that and he is working on the analog code as well. We will probably have to wait for him. If you have the full usb snoop data, I will consider looking into it but its a very long tedious process and working without the device will be difficult. On Fri, Apr 23, 2010 at 12:23 PM, George Tellalov wrote: > On Fri, Apr 23, 2010 at 10:05:25AM +0800, Bee Hock Goh wrote: >> George, >> >> Which device are you using? >> > > A Hauppauge HVR-900H (usb id 2040:6600). > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] IR/imon: convert to ir-core protocol change handling
Drop the imon driver's internal protocol definitions in favor of using
those provided by ir-core. Should make ir-keytable Just Work for
switching protocol on the fly on the imon devices that support both the
native imon remotes and mce remotes.
The imon-no-pad-stabilize pseudo-protocol was dropped as a protocol, and
converted to a separate modprobe option (which it probably should have
been in the first place). On the TODO list is to convert this to an as yet
unwritten protocol-specific options framework.
While the mce remotes obviously map to IR_TYPE_RC6, I've yet to look at
what the actual ir signals from the native imon remotes are, so for the
moment, imon native ir is mapped to IR_TYPE_OTHER. Nailing it down more
accurately is also on the TODO list.
Signed-off-by: Jarod Wilson
---
drivers/media/IR/imon.c| 151 ++--
drivers/media/IR/keymaps/rc-imon-mce.c |4 +-
drivers/media/IR/keymaps/rc-imon-pad.c |3 +-
3 files changed, 69 insertions(+), 89 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index d941b98..b65c31a 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -127,8 +127,7 @@ struct imon_context {
u32 kc; /* current input keycode */
u32 last_keycode; /* last reported input keycode */
- u8 ir_protocol; /* iMON or MCE (RC6) IR protocol? */
- u8 ir_proto_mask; /* supported IR protocol mask */
+ u64 ir_type;/* iMON or MCE (RC6) IR protocol? */
u8 mce_toggle_bit; /* last mce toggle bit */
bool release_code; /* some keys send a release code */
@@ -174,20 +173,6 @@ enum {
};
enum {
- IMON_IR_PROTOCOL_AUTO = 0x0,
- IMON_IR_PROTOCOL_MCE= 0x1,
- IMON_IR_PROTOCOL_IMON = 0x2,
- IMON_IR_PROTOCOL_IMON_NOPAD = 0x4,
-};
-
-enum {
- IMON_IR_PROTO_MASK_NONE = 0x0,
- IMON_IR_PROTO_MASK_MCE = IMON_IR_PROTOCOL_MCE,
- IMON_IR_PROTO_MASK_IMON = IMON_IR_PROTOCOL_IMON |
- IMON_IR_PROTOCOL_IMON_NOPAD,
-};
-
-enum {
IMON_KEY_IMON = 0,
IMON_KEY_MCE= 1,
IMON_KEY_PANEL = 2,
@@ -330,12 +315,10 @@ module_param(display_type, int, S_IRUGO);
MODULE_PARM_DESC(display_type, "Type of attached display. 0=autodetect, "
"1=vfd, 2=lcd, 3=vga, 4=none (default: autodetect)");
-/* IR protocol: native iMON, Windows MCE (RC-6), or iMON w/o PAD stabilize */
-static int ir_protocol;
-module_param(ir_protocol, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(ir_protocol, "Which IR protocol to use. 0=auto-detect, "
-"1=Windows Media Center Ed. (RC-6), 2=iMON native, "
-"4=iMON w/o PAD stabilize (default: auto-detect)");
+static int pad_stabilize = 1;
+module_param(pad_stabilize, int, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(pad_stabilize, "Apply stabilization algorithm to iMON PAD "
+"presses in arrow key mode. 0=disable, 1=enable (default).");
/*
* In certain use cases, mouse mode isn't really helpful, and could actually
@@ -1007,72 +990,67 @@ static void imon_touch_display_timeout(unsigned long
data)
* really just RC-6), but only one or the other at a time, as the signals
* are decoded onboard the receiver.
*/
-static void imon_set_ir_protocol(struct imon_context *ictx)
+int imon_ir_change_protocol(void *priv, u64 ir_type)
{
int retval;
+ struct imon_context *ictx = priv;
struct device *dev = ictx->dev;
+ bool pad_mouse;
unsigned char ir_proto_packet[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x86 };
- if (ir_protocol && !(ir_protocol & ictx->ir_proto_mask))
+ if (!(ir_type & ictx->props->allowed_protos))
dev_warn(dev, "Looks like you're trying to use an IR protocol "
"this device does not support\n");
- switch (ir_protocol) {
- case IMON_IR_PROTOCOL_AUTO:
- if (ictx->product == 0xffdc) {
- if (ictx->ir_proto_mask & IMON_IR_PROTO_MASK_MCE) {
- ir_proto_packet[0] = 0x01;
- ictx->ir_protocol = IMON_IR_PROTOCOL_MCE;
- ictx->pad_mouse = 0;
- init_timer(&ictx->itimer);
- ictx->itimer.data = (unsigned long)ictx;
- ictx->itimer.function = imon_mce_timeout;
- } else {
- ictx->ir_protocol = IMON_IR_PROTOCOL_IMON;
- ictx->pad_mouse = 1;
- }
- }
- break;
- case IMON_IR_PROTOCOL_MCE:
+ switch (ir_type) {
+ case IR_TYPE_RC6:
dev_dbg(dev, "Configuring IR receiver for MCE protocol\n");
Re: [PATCH 3/3] ir-core: add imon driver
On Thu, Apr 22, 2010 at 10:36:06AM -0300, Mauro Carvalho Chehab wrote: > Jarod Wilson wrote: > > On Tue, Apr 20, 2010 at 06:22:36PM -0300, Mauro Carvalho Chehab wrote: > >> Em Fri, 16 Apr 2010 17:29:02 -0400 > >> Jarod Wilson escreveu: > >> > >>> This is a new driver for the SoundGraph iMON and Antec Veris IR/display > >>> devices commonly found in many home theater pc cases and as after-market > >>> case additions. > >> > >>> +/* IR protocol: native iMON, Windows MCE (RC-6), or iMON w/o PAD > >>> stabilize */ > >>> +static int ir_protocol; > >>> +module_param(ir_protocol, int, S_IRUGO | S_IWUSR); > >>> +MODULE_PARM_DESC(ir_protocol, "Which IR protocol to use. 0=auto-detect, " > >>> + "1=Windows Media Center Ed. (RC-6), 2=iMON native, " > >>> + "4=iMON w/o PAD stabilize (default: auto-detect)"); > >>> + > >> You don't need this. Let's the protocol to be adjustable via sysfs. All > >> you need to do is > >> to use the set_protocol callbacks with something like: > >> > >> props->allowed_protos = IR_TYPE_RC6 | IR_TYPE_; > >> props->change_protocol = imon_ir_change_protocol; > >> > >> You can see an example of such implementation at > >> drivers/media/video/em28xx-em28xx-input.c. > >> Look for em28xx_ir_change_protocol() function. > > > > Working on it now... I'm about 95% of the way there, just need to sort out > > one last little bit... > > Good! Patch coming momentarily. Nice to submit one that actually removes more lines than it adds... :) > >> That's said, I'm not sure what would be better way to map IR_TYPE_ >> protocol>. Maybe we > >> can just use IR_TYPE_OTHER. > >> > >> So, basically, we'll have: > >> > >>IR_TYPE_OTHER | IR_TYPE_RC6 - auto-detected between RC-6 and iMON > >>IR_TYPE_OTHER - iMON proprietary protocol > >>IR_TYPE_RC6 - RC-6 protocol > >> > >> > >> By doing this, the userspace application ir-keycode will already be able > >> to handle the > >> IR protocol. > > > > I'm going to go with IR_TYPE_OTHER for the iMON native proto for now. To > > be honest, I don't have a clue what the actual IR protocol looks like... I > > should try one of my iMON remotes w/an mce transceiver to see if I can > > figure it out... > > It would be a good idea to get the real protocol, instead of using OTHER. > Maybe one of the > already-existing decoders may be able to catch it, if you use a raw decoder > device. On the TODO list, probably after porting the mceusb driver to ir-core, which I can then use for this very purpose. > >> I'm not sure how to map the "PAD stablilize" case, but it seems that the > >> better would be to > >> add a sysfs node for it, at sys/class/rc/rc0. There are other cases where > >> some protocols > >> may require some adjustments, so I'm thinking on having some > >> protocol-specific properties there. > > > > For the moment, I'm dropping the ir_protocol modparam and adding a > > pad_stabilize one. It was a hack to have it as a protocol, all it really > > needs to do is bypass a function when processing the pad signals. Can > > convert it to something more standard once we have a standard for > > protocol-specific properties. (The pad_thresh modparam is probably a > > similar case). > > Yes. Suggestions/patches for those protocol-specific parameters are welcome ;) Going to keep it in mind while starting to port more lirc drivers, thinking maybe ideas will emerge after looking at the needs of multiple drivers. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: V4L2 and Media controller mini-summit in Helsinki 14.--16. June --- PLEASE REGISTER!
> -Original Message- > From: Sakari Ailus [mailto:sakari.ai...@nokia.com] > Sent: Thursday, April 22, 2010 7:48 PM > To: Hans Verkuil; Laurent Pinchart; David Cohen; Koskipaa Antti (Nokia- > D/Helsinki); 'vimarsh.zut...@nokia.com'; Pawel Osciak; Marek Szyprowski; > linux-media@vger.kernel.org; Aguirre, Sergio; Hans de Goede; Hiremath, > Vaibhav; Karicheri, Muralidharan; Guennadi Liakhovetski; Mauro Carvalho > Chehab; Zhang, Xiaolin; Penda, Naveen Kumar > Subject: Re: V4L2 and Media controller mini-summit in Helsinki 14.--16. June > --- PLEASE REGISTER! > > Hello all, > > Sakari Ailus wrote: > > Hello everyone, > > > > I'm glad to announce Nokia will be hosting a V4L2 and Media controller > > mini-summit in Helsinki, Finland from 14th to 16th June --- that's from > > Monday to Wednesday. The event replaces the V4L2 Media Controller > > mini-summit in Oslo in April / May proposed by Hans Verkuil. Just the > > location is different; Hans is still responsible for the technical > content. > > And many thanks to Hans for doing this! Without him, this mini-summit > would not be possible. > > > Hans' original posting is available here: > > > > http://www.mail-archive.com/linux- > me...@vger.kernel.org/msg15526.html> > > > > The participation to the event is free of charge and open for anyone. > > However, we do have a limited number of seats but I'm very trustful > > everyone will be able to fit in. I'd like to ask the participants to > > sign up by sending me mail telling they want to participate. > > A few things related to practical arrangements. > > There seems to be a largish conference in Helsinki just at the time > we're having our V4L2 mini-summit and this is the reason it is quite > difficult to book hotel rooms here. We have a quota reservation for the > V4L2 mini-summit between 2010-06-12 -- 2010-06-18 which expires > 2010-05-12 (just a bit over two weeks!). After this it may be very > difficult to find rooms, depending on the activity of a certain volcano > in Iceland, though. > > Even if you are not absolutely certain of your participation, please > inform me you're interested and I'll send you the hotel reservation > information. Cancelling the reservation without extra fee is possible > (and not difficult at all). [Hiremath, Vaibhav] Sakari, I am working on all logistics for attending this mini-summit, and if everything goes as planned I will be attending this mini-summit. Thanks, Vaibhav > > Please also tell if you're happy with being publicly (in this list that > is) listed as a participant to the meeting or not. Otherwise the > assumption is "yes". :) > > Sincerely, > > -- > Sakari Ailus > sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tm6000: Patch that will fixed analog video (tested on tm5600)
On Fri, Apr 23, 2010 at 10:05:25AM +0800, Bee Hock Goh wrote: > George, > > Which device are you using? > A Hauppauge HVR-900H (usb id 2040:6600). -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help needed in understanding v4l2_device_call_all
Mauro,
Thanks.
Previously, I have done some limited test and it seem that
xc2028_signal seem to be getting the correct registered value for the
detected a signal locked.
Since I am now able to get video working(though somewhat limited since
it still crashed if i change channel from mythtv), i will be spending
more time to look getting a lock on the signal.
Is line 139,140,155,156 needed? Its slowing down the loading of
firmware and it working for me with the additional register setting.
138 if (addr == dev->tuner_addr << 1) {
139 tm6000_set_reg(dev, 0x32, 0,0);
140 tm6000_set_reg(dev, 0x33, 0,0);
141 }
142 if (i2c_debug >= 2)
143 for (byte = 0; byte < msgs[i].len; byte++)
144 printk(" %02x", msgs[i].buf[byte]);
145 } else {
146 /* write bytes */
147 if (i2c_debug >= 2)
148 for (byte = 0; byte < msgs[i].len; byte++)
149 printk(" %02x", msgs[i].buf[byte]);
150 rc = tm6000_i2c_send_regs(dev, addr, msgs[i].buf[0],
151 msgs[i].buf + 1, msgs[i].len - 1);
152
153 if (addr == dev->tuner_addr << 1) {
154 tm6000_set_reg(dev, 0x32, 0,0);
155 tm6000_set_reg(dev, 0x33, 0,0);
On Fri, Apr 23, 2010 at 4:35 AM, Mauro Carvalho Chehab
wrote:
> Bee Hock Goh wrote:
>> Hi,
>>
>> I am trying to understand how the subdev function are triggered when I
>> use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on
>> tm600-video.
>
> It calls tuner-core.c code, with g_tuner command. tuner-core
> checks what's the used tuner and, in the case of tm6000, calls the
> corresponding
> function at tuner-xc2028. This is implemented on tuner_g_tuner() function.
>
> The function basically does some sanity checks, and some common tuner code,
> but
> the actual implementation is handled by some callbacks that the driver needs
> to
> define (get_afc, get_status, is_stereo, has_signal). In general, drivers use
> get_status for it:
> fe_tuner_ops->get_status(&t->fe, &tuner_status);
>
>
> You will find a good example of how to implement such code at tuner-simple
> simple_get_status() function.
>
> In the case of tuner-xc2028, we never found a way for it to properly report
> the
> status of the tuner lock. That's why this function is not implemented on the
> driver.
>
>> How am i able to link the callback from the tuner_xc2028 function?
>
> The callback is used by tuner-xc2028 when it detects the need of changing the
> firmware (or when the firmware is not loaded yet, or when you select a
> standard
> that it is not supported by the current firmware).
>
> Basically, xc2028 driver will use the callback that was set previously via:
>
> v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_config, &xc2028_cfg);
>
>
>>
>> Please help me to understand or directly me to any documentation that
>> I can read up?
>>
>> thanks,
>> Hock.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
>
> Cheers,
> Mauro
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tm6000: Patch that will fixed analog video (tested on tm5600)
George, Which device are you using? I have introduced a number of manual registers settings in the tm6000 codes which might be specific to my device and its a pure duplication from usb snooping which is not suitable to be introduce to the mainstream codes. On Fri, Apr 23, 2010 at 4:20 AM, George Tellalov wrote: > On Thu, Apr 22, 2010 at 01:14:39PM +0800, Bee Hock Goh wrote: >> Dear all, >> >> Anyone who have a tm6000 compatible analog device, please do try out this >> patch. >> >> Its working for me on a tm5600 using mplayer. It can be compile >> against the latest hg tree. >> > > Here's what I get using mplayer: > > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) > BUG: unable to handle kernel paging request at 00800200 > IP: [] tm6000_irq_callback+0x32a/0x886 [tm6000] > PGD 5de26067 PUD 5d50d067 PMD 0 > Oops: 0002 [#1] SMP > last sysfs file: /sys/devices/platform/abituguru.224/temp3_input > CPU 0 > Pid: 0, comm: swapper Tainted: G C 2.6.33 #1 AV8 (VIA K8T800P-8237)/ > RIP: 0010:[] [] > tm6000_irq_callback+0x32a/0x886 [tm6000] > RSP: 0018:880001803cc8 EFLAGS: 00010006 > RAX: 0004 RBX: 8800425df800 RCX: 0003 > RDX: 8800425df800 RSI: 880042612c00 RDI: 00800200 > RBP: 8800425df800 R08: R09: 0002 > R10: 8800425df800 R11: 814af69b R12: 8800425dfe9c > R13: 880042612c00 R14: 00b4 R15: 00b4 > FS: 459cb950() GS:88000180() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 00800200 CR3: 5d548000 CR4: 06f0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process swapper (pid: 0, threadinfo 8160, task 81648020) > Stack: > 81248064 88005f911000 88005d683750 > <0> 880001803d80 000ca800 880042612ffd 88020001 > <0> 8123420d 5593 d392d818d757d33e 00040003 > Call Trace: > > [] ? tcp_v4_do_rcv+0x19b/0x346 > [] ? __inet_lookup_established+0x43/0x245 > [] ? usb_hcd_giveback_urb+0x76/0xa9 [usbcore] > [] ? ehci_urb_done+0x6b/0x7b [ehci_hcd] > [] ? ehci_work+0x3ec/0x78d [ehci_hcd] > [] ? ehci_irq+0x18f/0x1ba [ehci_hcd] > [] ? usb_hcd_irq+0x39/0x7e [usbcore] > [] ? handle_IRQ_event+0x58/0x126 > [] ? handle_fasteoi_irq+0x78/0xaf > [] ? handle_irq+0x17/0x1f > [] ? do_IRQ+0x57/0xbd > [] ? ret_from_intr+0x0/0x11 > > [] ? native_safe_halt+0x2/0x3 > [] ? default_idle+0x34/0x51 > [] ? cpu_idle+0xa2/0xda > [] ? early_idt_handler+0x0/0x71 > [] ? start_kernel+0x3e5/0x3f1 > [] ? x86_64_start_kernel+0xf9/0x106 > Code: b8 04 00 00 00 f3 a4 4c 89 ee 48 8b 94 24 98 00 00 00 b1 04 2b 8a a0 06 > 00 00 8b ba 9c 06 00 00 48 03 bc 24 b8 00 00 00 48 63 c9 a4 2b 82 a0 06 > 00 00 48 98 49 01 c5 eb 63 41 80 7d 03 47 74 > RIP [] tm6000_irq_callback+0x32a/0x886 [tm6000] > RSP > CR2: 00800200 > ---[ end trace e0d33b74978ba13e ]--- > Kernel panic - not syncing: Fatal exception in interrupt > Pid: 0, comm: swapper Tainted: G D C 2.6.33 #1 > Call Trace: > [] ? panic+0x86/0x14b > [] ? crash_kexec+0xf8/0x101 > [] ? up+0xe/0x37 > [] ? kmsg_dump+0xa6/0x13e > [] ? oops_end+0xa6/0xb3 > [] ? no_context+0x1f2/0x201 > [] ? __bad_area_nosemaphore+0x1ad/0x1d1 > [] ? tcp_packet+0xc56/0xc99 [nf_conntrack] > [] ? bictcp_cong_avoid+0x12/0x247 > [] ? usb_hcd_submit_urb+0x7f5/0x8eb [usbcore] > [] ? page_fault+0x25/0x30 > [] ? tm6000_irq_callback+0x32a/0x886 [tm6000] > [] ? tm6000_irq_callback+0x11b/0x886 [tm6000] > [] ? tcp_v4_do_rcv+0x19b/0x346 > [] ? __inet_lookup_established+0x43/0x245 > [] ? usb_hcd_giveback_urb+0x76/0xa9 [usbcore] > [] ? ehci_urb_done+0x6b/0x7b [ehci_hcd] > [] ? ehci_work+0x3ec/0x78d [ehci_hcd] > [] ? ehci_irq+0x18f/0x1ba [ehci_hcd] > [] ? usb_hcd_irq+0x39/0x7e [usbcore] > [] ? handle_IRQ_event+0x58/0x126 > [] ? handle_fasteoi_irq+0x78/0xaf > [] ? handle_irq+0x17/0x1f > [] ? do_IRQ+0x57/0xbd > [] ? ret_from_intr+0x0/0x
How to use git development trees
Hi, A few developers asked me how I'm working with the git trees for development. So, I decided to write a few quick notes about it at the wiki: http://linuxtv.org/wiki/index.php/Using_a_git_driver_development_tree I also added the script I use to remove the modules from the memory. Based on my own experience, using the Git tree instead of Mercurial speed up my development time when working with IR, especially since I had to touch at the input system core, to add two new ioctls. As input core is not at the Mercurial, if I was using the old way, I would have to deal with both mercurial and upstream trees. The drawback of doing a full compilation of the upstream kernel is not bad for me, since I always test the latest kernel anyway. Of course, other people may have different experiences. That's why we're keep supporting the mercurial trees ;) Btw, in order to help developers to work with git, I'm trying to preserve the git tree with the latest stable Linus kernel version (currently, 2.6.33), plus the v4l-dvb new drivers. So, I intend to backport from upstream only with 2.6.34. PS.: with respect to the pending patches, I was abroad last week, and I'm currently with a very high volume of patches, some requiring lots of tests. My intention is to merge the great majority of the patches until the end of this weekend. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tm6000 fix i2c
Hi
Rework I2C for read word from connected devices, now it works well.
Add new functions for read/write blocks.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c Fri Apr 23 04:23:03 2010 +1000
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include "compat.h"
#include "tm6000.h"
@@ -45,11 +46,39 @@
printk(KERN_DEBUG "%s at %s: " fmt, \
dev->name, __FUNCTION__ , ##args); } while (0)
+static void tm6000_i2c_reset(struct tm6000_core *dev)
+{
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 0);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 1);
+ msleep(15);
+}
+
static int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr,
__u8 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf, len);
+ int rc;
+ unsigned int tsleep;
+
+ if (!buf || len < 1 || len > 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg << 8, 0, buf, len);
+
+ if (rc < 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = ((len * 200) + 200 + 1000) / 1000;
+ msleep(tsleep);
+
+ /* release mutex */
+ return rc;
}
/* Generic read - doesn't work fine with 16bit registers */
@@ -59,22 +88,30 @@
int rc;
u8 b[2];
- if ((dev->caps.has_zl10353) && (dev->demod_addr << 1 == addr) && (reg %
2 == 0)) {
+ if (!buf || len < 1 || len > 64)
+ return -1;
+
+ /* capture mutex */
+ if ((dev->caps.has_zl10353) && (dev->demod_addr << 1 == addr)
+ && (reg % 2 == 0)) {
/*
* Workaround an I2C bug when reading from zl10353
*/
reg -= 1;
len += 1;
- rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, b, len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg << 8, 0, b, len);
*buf = b[1];
} else {
- rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg << 8, 0, buf,
len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg << 8, 0, buf, len);
}
+ /* release mutex */
return rc;
}
@@ -85,8 +122,106 @@
static int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr,
__u16 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+ int rc;
+ unsigned char ureg;
+
+ if (!buf || len != 2)
+ return -1;
+
+ /* capture mutex */
+ ureg = reg & 0xFF;
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | (reg & 0xFF00), 0, &ureg, 1);
+
+ if (rc < 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ msleep(1400 / 1000);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
+ reg, 0, buf, len);
+
+ if (rc < 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* release mutex */
+ return rc;
+}
+
+static int tm6000_i2c_read_sequence(struct tm6000_core *dev, unsigned char
addr,
+ __u16 reg, char *buf, int len)
+{
+ int rc;
+
+ if (!buf || len < 1 || len > 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
+ reg, 0, buf, len);
+ /* release mutex */
+ return rc;
+}
+
+static int tm6000_i2c_write_sequence(struct tm6000_core *dev,
+ unsigned char addr, __u16 reg, char *buf,
+ int len)
+{
+ int rc;
+ unsigned int
Re: DViCo Dual Fusion Express (cx23885) remote control issue
On Fri, 23 Apr 2010, Timothy D. Lenz wrote: > On 4/22/2010 6:11 AM, Daniel O'Connor wrote: > > On Thu, 15 Apr 2010, Daniel O'Connor wrote: > >> I haven't delved much further yet (planning to printf my way > >> through the probe routines) as I am a Linux kernel noob (plenty of > >> FreeBSD experience though!). > > > > I found that it is intermittent with no pattern I can determine. > > > > When it doesn't work the probe routine is not called, but I am not > > sure how i2c_register_driver decides to call the probe routine. > > > > Does anyone have an idea what the cause could be? Or at least > > somewhere to start looking :) > > A patch was posted that was suposed to be merged that fixed the ir > problem, at least for me. Though my problem was not intermittent. The > patch worked for me. Now if I could just get both tuners to keep > working Hmm do you have a subject line or message ID I can search for? I haven't found any problems with tuners not working although I don't often fire them both up at once. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: Help needed in understanding v4l2_device_call_all
Bee Hock Goh wrote: > Hi, > > I am trying to understand how the subdev function are triggered when I > use v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_tuner,t) on > tm600-video. It calls tuner-core.c code, with g_tuner command. tuner-core checks what's the used tuner and, in the case of tm6000, calls the corresponding function at tuner-xc2028. This is implemented on tuner_g_tuner() function. The function basically does some sanity checks, and some common tuner code, but the actual implementation is handled by some callbacks that the driver needs to define (get_afc, get_status, is_stereo, has_signal). In general, drivers use get_status for it: fe_tuner_ops->get_status(&t->fe, &tuner_status); You will find a good example of how to implement such code at tuner-simple simple_get_status() function. In the case of tuner-xc2028, we never found a way for it to properly report the status of the tuner lock. That's why this function is not implemented on the driver. > How am i able to link the callback from the tuner_xc2028 function? The callback is used by tuner-xc2028 when it detects the need of changing the firmware (or when the firmware is not loaded yet, or when you select a standard that it is not supported by the current firmware). Basically, xc2028 driver will use the callback that was set previously via: v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_config, &xc2028_cfg); > > Please help me to understand or directly me to any documentation that > I can read up? > > thanks, > Hock. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tm6000: Patch that will fixed analog video (tested on tm5600)
On Thu, Apr 22, 2010 at 01:14:39PM +0800, Bee Hock Goh wrote: > Dear all, > > Anyone who have a tm6000 compatible analog device, please do try out this > patch. > > Its working for me on a tm5600 using mplayer. It can be compile > against the latest hg tree. > Here's what I get using mplayer: tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) BUG: unable to handle kernel paging request at 00800200 IP: [] tm6000_irq_callback+0x32a/0x886 [tm6000] PGD 5de26067 PUD 5d50d067 PMD 0 Oops: 0002 [#1] SMP last sysfs file: /sys/devices/platform/abituguru.224/temp3_input CPU 0 Pid: 0, comm: swapper Tainted: G C 2.6.33 #1 AV8 (VIA K8T800P-8237)/ RIP: 0010:[] [] tm6000_irq_callback+0x32a/0x886 [tm6000] RSP: 0018:880001803cc8 EFLAGS: 00010006 RAX: 0004 RBX: 8800425df800 RCX: 0003 RDX: 8800425df800 RSI: 880042612c00 RDI: 00800200 RBP: 8800425df800 R08: R09: 0002 R10: 8800425df800 R11: 814af69b R12: 8800425dfe9c R13: 880042612c00 R14: 00b4 R15: 00b4 FS: 459cb950() GS:88000180() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 00800200 CR3: 5d548000 CR4: 06f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process swapper (pid: 0, threadinfo 8160, task 81648020) Stack: 81248064 88005f911000 88005d683750 <0> 880001803d80 000ca800 880042612ffd 88020001 <0> 8123420d 5593 d392d818d757d33e 00040003 Call Trace: [] ? tcp_v4_do_rcv+0x19b/0x346 [] ? __inet_lookup_established+0x43/0x245 [] ? usb_hcd_giveback_urb+0x76/0xa9 [usbcore] [] ? ehci_urb_done+0x6b/0x7b [ehci_hcd] [] ? ehci_work+0x3ec/0x78d [ehci_hcd] [] ? ehci_irq+0x18f/0x1ba [ehci_hcd] [] ? usb_hcd_irq+0x39/0x7e [usbcore] [] ? handle_IRQ_event+0x58/0x126 [] ? handle_fasteoi_irq+0x78/0xaf [] ? handle_irq+0x17/0x1f [] ? do_IRQ+0x57/0xbd [] ? ret_from_intr+0x0/0x11 [] ? native_safe_halt+0x2/0x3 [] ? default_idle+0x34/0x51 [] ? cpu_idle+0xa2/0xda [] ? early_idt_handler+0x0/0x71 [] ? start_kernel+0x3e5/0x3f1 [] ? x86_64_start_kernel+0xf9/0x106 Code: b8 04 00 00 00 f3 a4 4c 89 ee 48 8b 94 24 98 00 00 00 b1 04 2b 8a a0 06 00 00 8b ba 9c 06 00 00 48 03 bc 24 b8 00 00 00 48 63 c9 a4 2b 82 a0 06 00 00 48 98 49 01 c5 eb 63 41 80 7d 03 47 74 RIP [] tm6000_irq_callback+0x32a/0x886 [tm6000] RSP CR2: 00800200 ---[ end trace e0d33b74978ba13e ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 0, comm: swapper Tainted: G D C 2.6.33 #1 Call Trace: [] ? panic+0x86/0x14b [] ? crash_kexec+0xf8/0x101 [] ? up+0xe/0x37 [] ? kmsg_dump+0xa6/0x13e [] ? oops_end+0xa6/0xb3 [] ? no_context+0x1f2/0x201 [] ? __bad_area_nosemaphore+0x1ad/0x1d1 [] ? tcp_packet+0xc56/0xc99 [nf_conntrack] [] ? bictcp_cong_avoid+0x12/0x247 [] ? usb_hcd_submit_urb+0x7f5/0x8eb [usbcore] [] ? page_fault+0x25/0x30 [] ? tm6000_irq_callback+0x32a/0x886 [tm6000] [] ? tm6000_irq_callback+0x11b/0x886 [tm6000] [] ? tcp_v4_do_rcv+0x19b/0x346 [] ? __inet_lookup_established+0x43/0x245 [] ? usb_hcd_giveback_urb+0x76/0xa9 [usbcore] [] ? ehci_urb_done+0x6b/0x7b [ehci_hcd] [] ? ehci_work+0x3ec/0x78d [ehci_hcd] [] ? ehci_irq+0x18f/0x1ba [ehci_hcd] [] ? usb_hcd_irq+0x39/0x7e [usbcore] [] ? handle_IRQ_event+0x58/0x126 [] ? handle_fasteoi_irq+0x78/0xaf [] ? handle_irq+0x17/0x1f [] ? do_IRQ+0x57/0xbd [] ? ret_from_intr+0x0/0x11 [] ? native_safe_halt+0x2/0x3 [] ? default_idle+0x34/0x51 [] ? cpu_idle+0xa2/0xda [] ? early_idt_handler+0x0/0x71 [] ? start_kernel+0x3e5/0x3f1 [] ? x86_64_start_kernel+0xf9/0x106 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Apr 22 19:00:21 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14592:b438301e588f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1f96716187774be265c59a713fb570810e3a15c7 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DViCo Dual Fusion Express (cx23885) remote control issue
On 4/22/2010 6:11 AM, Daniel O'Connor wrote: On Thu, 15 Apr 2010, Daniel O'Connor wrote: I haven't delved much further yet (planning to printf my way through the probe routines) as I am a Linux kernel noob (plenty of FreeBSD experience though!). I found that it is intermittent with no pattern I can determine. When it doesn't work the probe routine is not called, but I am not sure how i2c_register_driver decides to call the probe routine. Does anyone have an idea what the cause could be? Or at least somewhere to start looking :) Thanks. A patch was posted that was suposed to be merged that fixed the ir problem, at least for me. Though my problem was not intermittent. The patch worked for me. Now if I could just get both tuners to keep working -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
anysee e30 suspend->resume causes wrong profiling of card.
The anysee driver works correctly from cold boot and reinsertion of the device,
however, after a suspend resume cycle (S3), the device suddenly is initated as
dvb-t as where it was dvb-c before. Yes this is a combo device, so dvb T and C,
but why does the profiling in anysee.c not handle this case? Obviously the
following snippet produces a false positive on warm boot and resume:
/* Zarlink ZL10353 DVB-T demod inside of Samsung DNOS404ZH103A NIM */
adap->fe = dvb_attach(zl10353_attach, &anysee_zl10353_config,
&adap->dev->i2c_adap);
if (adap->fe != NULL) {
state->tuner = DVB_PLL_THOMSON_DTT7579;
info("mine: case 2");
return 0;
}
I've looked through the rest of the code and by no means am I a developer but,
isn't the problem that on warm boots the register of the anysee device doesn't
hold the right value in combination with a combo device? because in all the
other cases when profiling for different kind of device like the e30c the
register is put in a different state before probing for the demuxer.
In the meantime I have commented out the above snippet, which results in a
works-for-me. But it isn't a nice solution for the average/new linux user
wanting to build a htpc with a anysee combo device.
Tested with ubuntu-lucid module, further tested/compiled with the HG repo.
ps I'm new with mailing lists, is this the right place to post for the anysee
driver?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx25821-video-upstream.c: Added severity to printk calls
Signed-off-by: Ricardo Maraschini
--- a/linux/drivers/staging/cx25821/cx25821-video-upstream.cSun Apr 18
11:12:11 2010 -0300
+++ b/linux/drivers/staging/cx25821/cx25821-video-upstream.cTue Apr 20
11:21:17 2010 -0300
@@ -257,7 +257,7 @@
if (!dev->_is_running) {
printk
- ("cx25821: No video file is currently running so return!\n");
+ (KERN_INFO "cx25821: No video file is currently running so
return!\n");
return;
}
/* Disable RISC interrupts */
@@ -345,19 +345,19 @@
if (IS_ERR(myfile)) {
const int open_errno = -PTR_ERR(myfile);
- printk("%s(): ERROR opening file(%s) with errno = %d!\n",
+ printk(KERN_ERR "%s(): ERROR opening file(%s) with errno =
%d!\n",
__func__, dev->_filename, open_errno);
return PTR_ERR(myfile);
} else {
if (!(myfile->f_op)) {
- printk("%s: File has no file operations registered!",
+ printk(KERN_ERR "%s: File has no file operations
registered!",
__func__);
filp_close(myfile, NULL);
return -EIO;
}
if (!myfile->f_op->read) {
- printk("%s: File has no READ operations registered!",
+ printk(KERN_ERR "%s: File has no READ operations
registered!",
__func__);
filp_close(myfile, NULL);
return -EIO;
@@ -410,7 +410,7 @@
container_of(work, struct cx25821_dev, _irq_work_entry);
if (!dev) {
- printk("ERROR %s(): since container_of(work_struct) FAILED!\n",
+ printk(KERN_ERR "ERROR %s(): since container_of(work_struct)
FAILED!\n",
__func__);
return;
}
@@ -436,12 +436,12 @@
if (IS_ERR(myfile)) {
const int open_errno = -PTR_ERR(myfile);
- printk("%s(): ERROR opening file(%s) with errno = %d!\n",
+ printk(KERN_ERR "%s(): ERROR opening file(%s) with errno =
%d!\n",
__func__, dev->_filename, open_errno);
return PTR_ERR(myfile);
} else {
if (!(myfile->f_op)) {
- printk("%s: File has no file operations registered!",
+ printk(KERN_ERR "%s: File has no file operations
registered!",
__func__);
filp_close(myfile, NULL);
return -EIO;
@@ -449,7 +449,7 @@
if (!myfile->f_op->read) {
printk
- ("%s: File has no READ operations registered!
Returning.",
+ (KERN_ERR "%s: File has no READ operations
registered! Returning.",
__func__);
filp_close(myfile, NULL);
return -EIO;
@@ -525,7 +525,7 @@
if (!dev->_dma_virt_addr) {
printk
- ("cx25821: FAILED to allocate memory for Risc buffer!
Returning.\n");
+ (KERN_ERR "cx25821: FAILED to allocate memory for Risc
buffer! Returning.\n");
return -ENOMEM;
}
@@ -546,7 +546,7 @@
if (!dev->_data_buf_virt_addr) {
printk
- ("cx25821: FAILED to allocate memory for data buffer!
Returning.\n");
+ (KERN_ERR "cx25821: FAILED to allocate memory for data
buffer! Returning.\n");
return -ENOMEM;
}
@@ -641,20 +641,20 @@
} else {
if (status & FLD_VID_SRC_UF)
printk
- ("%s: Video Received Underflow Error Interrupt!\n",
+ (KERN_ERR "%s: Video Received Underflow Error
Interrupt!\n",
__func__);
if (status & FLD_VID_SRC_SYNC)
- printk("%s: Video Received Sync Error Interrupt!\n",
+ printk(KERN_ERR "%s: Video Received Sync Error
Interrupt!\n",
__func__);
if (status & FLD_VID_SRC_OPC_ERR)
- printk("%s: Video Received OpCode Error Interrupt!\n",
+ printk(KERN_ERR "%s: Video Received OpCode Error
Interrupt!\n",
__func__);
}
if (dev->_file_status == END_OF_FILE) {
- printk("cx25821: EOF Channel 1 Framecount = %d\n",
+ printk(KERN_ERR "cx25821: EOF Channel 1 Framecount = %d\n",
dev->_frame_count);
return -1;
}
@@ -794,7 +794,7 @@
int str_length = 0;
if (dev->_is_running) {
- printk("Video Channel is
[PULL] soc-camera fixes for 2.6.34
Hi Mauro One more patch has been added to the two, I earlier announced. This time I've incorporated all acked- and tested-by's;) The following changes since commit 40358c8b5380604ac2507be2fac0c9bbd3e02b73: Hans Verkuil (1): V4L/DVB: saa7146: fix regression of the av7110/budget-av driver are available in the git repository at: git://linuxtv.org/gliakhovetski/soc-camera.git fixes Dan Carpenter (1): video: testing unsigned for less than 0 Stefan Herbrechtsmeier (1): pxa_camera: move fifo reset direct before dma start Uwe Kleine-König (1): V4L/DVB: mx1-camera: compile fix arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h |8 +++- drivers/media/video/mx1_camera.c |8 +++- drivers/media/video/pxa_camera.c | 11 ++- drivers/media/video/sh_mobile_ceu_camera.c |2 +- 4 files changed, 17 insertions(+), 12 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
switching DVB-C DVB-T on frontend using DVB API V5
Hello, I'm trying to develop a DVB frontend adapter driver using the DVB API V5. I found updated documentation on http://carfax.org.uk/kdoc/media/pt02.html -1- Is there another place were up to date documentation for API V5 is available because I couldn't find it on LinuxTv.org -2- The frontend chipset of the card supports DVB-C, DVB-T. Can the DVB API be used to switch the chip from DVB-T to DVB-C and vice versa. Can this be done with FE_SET_PROPERTY and DTV_DELIVERY_SYSTEM? How is writing this property (DTV_DELIVERY_SYSTEM) handled in the kernel? DTV_DELIVERY_SYSTEM: Read the type of delivery system. Values are defined in fe_delivery_system_t. It is not clear what the effect of writing this property is. Thanks in advance, Regards, Rob van de Voort Disclaimer: The information contained in this email, including any attachments is confidential and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Divis 16 Channel DVR
Has anyone heard of or had any luck with a Divis 16 channel DVR? It has a Philips SAA7146 chip set but I can't find any information on how to install the driver extension to the SAA7146 driver for this specific card. The serial number on the card is MPG8CH 0423 - 274. Bill -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
subscribe -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L2 and Media controller mini-summit in Helsinki 14.--16. June --- PLEASE REGISTER!
Hello all, Sakari Ailus wrote: > Hello everyone, > > I'm glad to announce Nokia will be hosting a V4L2 and Media controller > mini-summit in Helsinki, Finland from 14th to 16th June --- that's from > Monday to Wednesday. The event replaces the V4L2 Media Controller > mini-summit in Oslo in April / May proposed by Hans Verkuil. Just the > location is different; Hans is still responsible for the technical content. And many thanks to Hans for doing this! Without him, this mini-summit would not be possible. > Hans' original posting is available here: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg15526.html> > > The participation to the event is free of charge and open for anyone. > However, we do have a limited number of seats but I'm very trustful > everyone will be able to fit in. I'd like to ask the participants to > sign up by sending me mail telling they want to participate. A few things related to practical arrangements. There seems to be a largish conference in Helsinki just at the time we're having our V4L2 mini-summit and this is the reason it is quite difficult to book hotel rooms here. We have a quota reservation for the V4L2 mini-summit between 2010-06-12 -- 2010-06-18 which expires 2010-05-12 (just a bit over two weeks!). After this it may be very difficult to find rooms, depending on the activity of a certain volcano in Iceland, though. Even if you are not absolutely certain of your participation, please inform me you're interested and I'll send you the hotel reservation information. Cancelling the reservation without extra fee is possible (and not difficult at all). Please also tell if you're happy with being publicly (in this list that is) listed as a participant to the meeting or not. Otherwise the assumption is "yes". :) Sincerely, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ir-core: add imon driver
Jarod Wilson wrote: > On Tue, Apr 20, 2010 at 06:22:36PM -0300, Mauro Carvalho Chehab wrote: >> Em Fri, 16 Apr 2010 17:29:02 -0400 >> Jarod Wilson escreveu: >> >>> This is a new driver for the SoundGraph iMON and Antec Veris IR/display >>> devices commonly found in many home theater pc cases and as after-market >>> case additions. >> >>> +/* IR protocol: native iMON, Windows MCE (RC-6), or iMON w/o PAD stabilize >>> */ >>> +static int ir_protocol; >>> +module_param(ir_protocol, int, S_IRUGO | S_IWUSR); >>> +MODULE_PARM_DESC(ir_protocol, "Which IR protocol to use. 0=auto-detect, " >>> +"1=Windows Media Center Ed. (RC-6), 2=iMON native, " >>> +"4=iMON w/o PAD stabilize (default: auto-detect)"); >>> + >> You don't need this. Let's the protocol to be adjustable via sysfs. All you >> need to do is >> to use the set_protocol callbacks with something like: >> >> props->allowed_protos = IR_TYPE_RC6 | IR_TYPE_; >> props->change_protocol = imon_ir_change_protocol; >> >> You can see an example of such implementation at >> drivers/media/video/em28xx-em28xx-input.c. >> Look for em28xx_ir_change_protocol() function. > > Working on it now... I'm about 95% of the way there, just need to sort out > one last little bit... Good! >> That's said, I'm not sure what would be better way to map IR_TYPE_> protocol>. Maybe we >> can just use IR_TYPE_OTHER. >> >> So, basically, we'll have: >> >> IR_TYPE_OTHER | IR_TYPE_RC6 - auto-detected between RC-6 and iMON >> IR_TYPE_OTHER - iMON proprietary protocol >> IR_TYPE_RC6 - RC-6 protocol >> >> >> By doing this, the userspace application ir-keycode will already be able to >> handle the >> IR protocol. > > I'm going to go with IR_TYPE_OTHER for the iMON native proto for now. To > be honest, I don't have a clue what the actual IR protocol looks like... I > should try one of my iMON remotes w/an mce transceiver to see if I can > figure it out... It would be a good idea to get the real protocol, instead of using OTHER. Maybe one of the already-existing decoders may be able to catch it, if you use a raw decoder device. >> I'm not sure how to map the "PAD stablilize" case, but it seems that the >> better would be to >> add a sysfs node for it, at sys/class/rc/rc0. There are other cases where >> some protocols >> may require some adjustments, so I'm thinking on having some >> protocol-specific properties there. > > For the moment, I'm dropping the ir_protocol modparam and adding a > pad_stabilize one. It was a hack to have it as a protocol, all it really > needs to do is bypass a function when processing the pad signals. Can > convert it to something more standard once we have a standard for > protocol-specific properties. (The pad_thresh modparam is probably a > similar case). Yes. Suggestions/patches for those protocol-specific parameters are welcome ;) >> Except for that, the patch looked sane to my eyes. So, I'll add it on my >> tree and wait for a >> latter patch from you addressing the protocol control. > > Good deal, I'm working off the v4l-dvb git tree now, hope to have > something a bit later tonight or tomorrow. Ok. -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DViCo Dual Fusion Express (cx23885) remote control issue
On Thu, 15 Apr 2010, Daniel O'Connor wrote: > I haven't delved much further yet (planning to printf my way through > the probe routines) as I am a Linux kernel noob (plenty of FreeBSD > experience though!). I found that it is intermittent with no pattern I can determine. When it doesn't work the probe routine is not called, but I am not sure how i2c_register_driver decides to call the probe routine. Does anyone have an idea what the cause could be? Or at least somewhere to start looking :) Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
RE: [PATCH] v4l: videobuf: qbuf now uses relevant v4l2_buffer fields for OUTPUT types
>Laurent Pinchart wrote: >On Thursday 22 April 2010 11:24:52 Pawel Osciak wrote: >> >Laurent Pinchart wrote: >> >> According to the V4L2 specification, applications set bytesused, field >> >> and timestamp fields of struct v4l2_buffer when the buffer is intended >> >> for output and memory type is MMAP. This adds proper copying of those >> >> values to videobuf_buffer so drivers can use them. >> > >> >Why only for the MMAP memory type ? Don't drivers need the information for >> >USERPTR buffers as well ? >> >> It is only mentioned for the MMAP memory type: >> http://linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html >> #vidioc-qbuf although it would make sense to do this for USERPTR as well. >> Maybe I am trying too hard to stay 100% faithful to the documentation, I >> guess it should be corrected as well then? > >This wouldn't be the first time the spec is wrong :-) I'd like other people's >opinion on this, but I think we should fix the spec and copy the values for >both MMAP and USERPTR. Yes, same here. Thanks for pointing that up. I really have to stop treating the spec as it was somehow sacred :) Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 2/3] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR
Hi,
>Laurent Pinchart
>On Wednesday 21 April 2010 13:39:44 Pawel Osciak wrote:
>> @@ -679,23 +682,20 @@ int videobuf_dqbuf(struct videobuf_queue *q,
>> switch (buf->state) {
>> case VIDEOBUF_ERROR:
>> dprintk(1, "dqbuf: state is error\n");
>> -retval = -EIO;
>> -CALL(q, sync, q, buf);
>> -buf->state = VIDEOBUF_IDLE;
>> break;
>> case VIDEOBUF_DONE:
>> dprintk(1, "dqbuf: state is done\n");
>> -CALL(q, sync, q, buf);
>> -buf->state = VIDEOBUF_IDLE;
>> break;
>> default:
>> dprintk(1, "dqbuf: state invalid\n");
>> retval = -EINVAL;
>> goto done;
>> }
>> -list_del(&buf->stream);
>> -memset(b, 0, sizeof(*b));
>> +CALL(q, sync, q, buf);
>> videobuf_status(q, b, buf, q->type);
>> +list_del(&buf->stream);
>> +buf->state = VIDEOBUF_IDLE;
>> +b->flags &= ~V4L2_BUF_FLAG_DONE;
>
>We do you clear the done flag here ?
>
The DONE flag is supposed to be cleared when dequeuing, but should
be set when querying:
"When this flag is set, the buffer is currently on the outgoing queue,
ready to be dequeued from the driver. Drivers set or clear this flag
when the VIDIOC_QUERYBUF ioctl is called. After calling the VIDIOC_QBUF
or VIDIOC_DQBUF it is always cleared."
videobuf_status() is used for both QUERYBUF and DQBUF and making both
work properly is not very straightforward without losing
VIDEOBUF_DONE/VIDEOBUF_ERROR distinction (it becomes more clear when you
analyze both cases).
My previous patch was doing it the other way around, but Hans' version
seemed shorter and cleaner.
Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9t031: preserve output format on VIDIOC_S_CROP
On Thu, 22 Apr 2010, Valentin Longchamp wrote: > Guennadi Liakhovetski wrote: > > On Wed, 14 Apr 2010, Guennadi Liakhovetski wrote: > > > > > Interpretation of the V4L2 API specification, according to which the > > > VIDIOC_S_CROP ioctl for capture devices shall set the input window and > > > preserve the scales, thus possibly changing the output window, seems to be > > > incorrect. Switch to using a more intuitive definition, i.e., to > > > preserving the output format while changing scales. > > > > > > Signed-off-by: Guennadi Liakhovetski > > > --- > > > > > > Val, I do not have any mt9t031 hardware any more, could you, please, test > > > this patch and verify, that it does indeed do, what's described above? > > > > There hasn't been any replies to this, so, I presume, this patch cannot be > > tested at present. Therefore I'm going to leave it out of my pull requests > > until it gets tested somehow. > > Sorry Guennadi, the testing is on my todo-list, but I am getting nearer to the > end of my thesis and I really am very busy at the moment. I hope I can give it > a spin on a mt9t031 in the coming weeks. Np, we can push it out with the next development cycle, noone is complaining, so, noone actually has a problem with the present version either, I just would prefer to get it fixed, but it's not urgent. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] v4l: videobuf: qbuf now uses relevant v4l2_buffer fields for OUTPUT types
Hi Pawel, On Thursday 22 April 2010 11:24:52 Pawel Osciak wrote: > >Laurent Pinchart wrote: > >> According to the V4L2 specification, applications set bytesused, field > >> and timestamp fields of struct v4l2_buffer when the buffer is intended > >> for output and memory type is MMAP. This adds proper copying of those > >> values to videobuf_buffer so drivers can use them. > > > >Why only for the MMAP memory type ? Don't drivers need the information for > >USERPTR buffers as well ? > > It is only mentioned for the MMAP memory type: > http://linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html > #vidioc-qbuf although it would make sense to do this for USERPTR as well. > Maybe I am trying too hard to stay 100% faithful to the documentation, I > guess it should be corrected as well then? This wouldn't be the first time the spec is wrong :-) I'd like other people's opinion on this, but I think we should fix the spec and copy the values for both MMAP and USERPTR. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] v4l: videobuf: qbuf now uses relevant v4l2_buffer fields for OUTPUT types
Hi Laurent, >Laurent Pinchart wrote: >> According to the V4L2 specification, applications set bytesused, field and >> timestamp fields of struct v4l2_buffer when the buffer is intended for >> output and memory type is MMAP. This adds proper copying of those values >> to videobuf_buffer so drivers can use them. > >Why only for the MMAP memory type ? Don't drivers need the information for >USERPTR buffers as well ? > It is only mentioned for the MMAP memory type: http://linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html#vidioc-qbuf although it would make sense to do this for USERPTR as well. Maybe I am trying too hard to stay 100% faithful to the documentation, I guess it should be corrected as well then? Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9t031: preserve output format on VIDIOC_S_CROP
Guennadi Liakhovetski wrote:
On Wed, 14 Apr 2010, Guennadi Liakhovetski wrote:
Interpretation of the V4L2 API specification, according to which the
VIDIOC_S_CROP ioctl for capture devices shall set the input window and
preserve the scales, thus possibly changing the output window, seems to be
incorrect. Switch to using a more intuitive definition, i.e., to
preserving the output format while changing scales.
Signed-off-by: Guennadi Liakhovetski
---
Val, I do not have any mt9t031 hardware any more, could you, please, test
this patch and verify, that it does indeed do, what's described above?
There hasn't been any replies to this, so, I presume, this patch cannot be
tested at present. Therefore I'm going to leave it out of my pull requests
until it gets tested somehow.
Sorry Guennadi, the testing is on my todo-list, but I am getting nearer
to the end of my thesis and I really am very busy at the moment. I hope
I can give it a spin on a mt9t031 in the coming weeks.
Val
Thanks
Guennadi
diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
index a9061bf..a604fa0 100644
--- a/drivers/media/video/mt9t031.c
+++ b/drivers/media/video/mt9t031.c
@@ -63,6 +63,8 @@
struct mt9t031 {
struct v4l2_subdev subdev;
struct v4l2_rect rect; /* Sensor window */
+ unsigned int out_width;
+ unsigned int out_height;
int model; /* V4L2_IDENT_MT9T031* codes from v4l2-chip-ident.h */
u16 xskip;
u16 yskip;
@@ -284,6 +286,26 @@ static u16 mt9t031_skip(s32 *source, s32 target, s32 max)
return skip;
}
+static u16 mt9t031_skip_out(s32 *source, s32 *target)
+{
+ unsigned int skip;
+
+ if (*source < *target + *target / 2) {
+ *target = *source;
+ return 1;
+ }
+
+ skip = (*source + *target / 2) / *target;
+ if (skip > 8) {
+ skip = 8;
+ *target = (*source + 4) / 8;
+ }
+ /* We try to preserve input, but with division we have to adjust it too
*/
+ *source = *target * skip;
+
+ return skip;
+}
+
/* rect is the sensor rectangle, the caller guarantees parameter validity */
static int mt9t031_set_params(struct i2c_client *client,
struct v4l2_rect *rect, u16 xskip, u16 yskip)
@@ -393,6 +415,7 @@ static int mt9t031_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
struct v4l2_rect rect = a->c;
struct i2c_client *client = sd->priv;
struct mt9t031 *mt9t031 = to_mt9t031(client);
+ u16 xskip, yskip;
rect.width = ALIGN(rect.width, 2);
rect.height = ALIGN(rect.height, 2);
@@ -403,7 +426,10 @@ static int mt9t031_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
soc_camera_limit_side(&rect.top, &rect.height,
MT9T031_ROW_SKIP, MT9T031_MIN_HEIGHT, MT9T031_MAX_HEIGHT);
- return mt9t031_set_params(client, &rect, mt9t031->xskip, mt9t031->yskip);
+ xskip = mt9t031_skip_out(&rect.width, &mt9t031->out_width);
+ yskip = mt9t031_skip_out(&rect.height, &mt9t031->out_height);
+
+ return mt9t031_set_params(client, &rect, xskip, yskip);
}
static int mt9t031_g_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
@@ -437,8 +463,8 @@ static int mt9t031_g_fmt(struct v4l2_subdev *sd,
struct i2c_client *client = sd->priv;
struct mt9t031 *mt9t031 = to_mt9t031(client);
- mf->width = mt9t031->rect.width / mt9t031->xskip;
- mf->height = mt9t031->rect.height / mt9t031->yskip;
+ mf->width= mt9t031->out_width;
+ mf->height = mt9t031->out_height;
mf->code = V4L2_MBUS_FMT_SBGGR10_1X10;
mf->colorspace = V4L2_COLORSPACE_SRGB;
mf->field= V4L2_FIELD_NONE;
@@ -455,8 +481,9 @@ static int mt9t031_s_fmt(struct v4l2_subdev *sd,
struct v4l2_rect rect = mt9t031->rect;
/*
-* try_fmt has put width and height within limits.
-* S_FMT: use binning and skipping for scaling
+* try_fmt has put width and height within limits. Note: when converting
+* to a generic v4l2-subdev driver, try_fmt will have to be called
+* explicitly. S_FMT: use binning and skipping for scaling.
*/
xskip = mt9t031_skip(&rect.width, mf->width, MT9T031_MAX_WIDTH);
yskip = mt9t031_skip(&rect.height, mf->height, MT9T031_MAX_HEIGHT);
@@ -464,6 +491,9 @@ static int mt9t031_s_fmt(struct v4l2_subdev *sd,
mf->code = V4L2_MBUS_FMT_SBGGR10_1X10;
mf->colorspace = V4L2_COLORSPACE_SRGB;
+ mt9t031->out_width = mf->width;
+ mt9t031->out_height = mf->height;
+
/* mt9t031_set_params() doesn't change width and height */
return mt9t031_set_params(client, &rect, xskip, yskip);
}
@@ -807,6 +837,9 @@ static int mt9t031_probe(struct i2c_client *client,
mt9t031->rect.width = MT9T031_MAX_WIDTH;
mt9t031->rect.height = MT9T031_MAX_HEIGHT;
+ mt9t031->out_width = MT9T031_MAX
Re: [PATCH] v4l: videobuf: qbuf now uses relevant v4l2_buffer fields for OUTPUT types
Hi Pawel,
On Wednesday 21 April 2010 11:44:27 Pawel Osciak wrote:
> According to the V4L2 specification, applications set bytesused, field and
> timestamp fields of struct v4l2_buffer when the buffer is intended for
> output and memory type is MMAP. This adds proper copying of those values
> to videobuf_buffer so drivers can use them.
Why only for the MMAP memory type ? Don't drivers need the information for
USERPTR buffers as well ?
> Signed-off-by: Pawel Osciak
> Signed-off-by: Kyungmin Park
> ---
> drivers/media/video/videobuf-core.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/videobuf-core.c
> b/drivers/media/video/videobuf-core.c index 63d7043..e573ca7 100644
> --- a/drivers/media/video/videobuf-core.c
> +++ b/drivers/media/video/videobuf-core.c
> @@ -549,6 +549,13 @@ int videobuf_qbuf(struct videobuf_queue *q, struct
> v4l2_buffer *b) "but buffer addr is zero!\n");
> goto done;
> }
> + if (q->type == V4L2_BUF_TYPE_VIDEO_OUTPUT
> + || q->type == V4L2_BUF_TYPE_VBI_OUTPUT
> + || q->type == V4L2_BUF_TYPE_SLICED_VBI_OUTPUT) {
> + buf->size = b->bytesused;
> + buf->field = b->field;
> + buf->ts = b->timestamp;
> + }
> break;
> case V4L2_MEMORY_USERPTR:
> if (b->length < buf->bsize) {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR
Hi Pawel,
On Wednesday 21 April 2010 13:39:44 Pawel Osciak wrote:
> From: Hans Verkuil
>
> For recoverable stream errors dqbuf() now returns 0 and the error flag
> is set instead of returning EIO.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/video/videobuf-core.c | 16
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/video/videobuf-core.c
> b/drivers/media/video/videobuf-core.c index 63d7043..1cf084f 100644
> --- a/drivers/media/video/videobuf-core.c
> +++ b/drivers/media/video/videobuf-core.c
> @@ -286,8 +286,10 @@ static void videobuf_status(struct videobuf_queue *q,
> struct v4l2_buffer *b, case VIDEOBUF_ACTIVE:
> b->flags |= V4L2_BUF_FLAG_QUEUED;
> break;
> - case VIDEOBUF_DONE:
> case VIDEOBUF_ERROR:
> + b->flags |= V4L2_BUF_FLAG_ERROR;
> + /* fall through */
> + case VIDEOBUF_DONE:
> b->flags |= V4L2_BUF_FLAG_DONE;
> break;
> case VIDEOBUF_NEEDS_INIT:
> @@ -668,6 +670,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
>
> MAGIC_CHECK(q->int_ops->magic, MAGIC_QTYPE_OPS);
>
> + memset(b, 0, sizeof(*b));
> mutex_lock(&q->vb_lock);
>
> retval = stream_next_buffer(q, &buf, nonblocking);
> @@ -679,23 +682,20 @@ int videobuf_dqbuf(struct videobuf_queue *q,
> switch (buf->state) {
> case VIDEOBUF_ERROR:
> dprintk(1, "dqbuf: state is error\n");
> - retval = -EIO;
> - CALL(q, sync, q, buf);
> - buf->state = VIDEOBUF_IDLE;
> break;
> case VIDEOBUF_DONE:
> dprintk(1, "dqbuf: state is done\n");
> - CALL(q, sync, q, buf);
> - buf->state = VIDEOBUF_IDLE;
> break;
> default:
> dprintk(1, "dqbuf: state invalid\n");
> retval = -EINVAL;
> goto done;
> }
> - list_del(&buf->stream);
> - memset(b, 0, sizeof(*b));
> + CALL(q, sync, q, buf);
> videobuf_status(q, b, buf, q->type);
> + list_del(&buf->stream);
> + buf->state = VIDEOBUF_IDLE;
> + b->flags &= ~V4L2_BUF_FLAG_DONE;
We do you clear the done flag here ?
> done:
> mutex_unlock(&q->vb_lock);
> return retval;
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] soc-camera updates, VOU and AK881x video output drivers
Hi Mauro The following changes since commit 1f96716187774be265c59a713fb570810e3a15c7: Mauro Carvalho Chehab (1): Revert "V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices" are available in the git repository at: git://linuxtv.org/gliakhovetski/soc-camera.git devel Guennadi Liakhovetski (6): sh_mobile_ceu_camera.c: preserve output window on VIDIOC_S_CROP soc-camera: update comment sh_mobile_ceu_camera.c: update documentation to reflect the new cropping videobuf-dma-contig.c: simplify pointer dereference V4L: SuperH Video Output Unit (VOU) driver V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM Documentation/video4linux/sh_mobile_ceu_camera.txt | 80 +- drivers/media/video/Kconfig| 13 + drivers/media/video/Makefile |4 + drivers/media/video/ak881x.c | 368 + drivers/media/video/sh_mobile_ceu_camera.c | 601 drivers/media/video/sh_vou.c | 1476 drivers/media/video/soc_camera.c |3 +- drivers/media/video/videobuf-dma-contig.c |6 +- include/media/ak881x.h | 25 + include/media/sh_vou.h | 34 + include/media/v4l2-chip-ident.h|4 + 11 files changed, 2268 insertions(+), 346 deletions(-) create mode 100644 drivers/media/video/ak881x.c create mode 100644 drivers/media/video/sh_vou.c create mode 100644 include/media/ak881x.h create mode 100644 include/media/sh_vou.h Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [stable] [PATCH v2] V4L/DVB: budget: Oops: "BUG: unable to handle kernel NULL pointer dereference"
Greg KH writes: > Any reason why this patch isn't in Linus's tree yet? Not to my knowledge. Anyone? I must admit that I do not entirely understand the flow of bugfix patches for V4L/DVB. There doesn't seem to be any collection point for those, only a git tree for development and a mercurial tree for a backported version of the development tree. Is that correct, or is the reason this patch isn't merged that I missed something here? I do note that MAINTAINERS point to git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git but this tree doesn't seem to be actually used? No bugfixes for any part of the subsystem in 2.5 months seems unlikely... Sorry if I've missed this in any of the V4L development docs. I'd really appreciate it if anyone pointed me in the right direction. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mt9t031: preserve output format on VIDIOC_S_CROP
On Wed, 14 Apr 2010, Guennadi Liakhovetski wrote:
> Interpretation of the V4L2 API specification, according to which the
> VIDIOC_S_CROP ioctl for capture devices shall set the input window and
> preserve the scales, thus possibly changing the output window, seems to be
> incorrect. Switch to using a more intuitive definition, i.e., to
> preserving the output format while changing scales.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> Val, I do not have any mt9t031 hardware any more, could you, please, test
> this patch and verify, that it does indeed do, what's described above?
There hasn't been any replies to this, so, I presume, this patch cannot be
tested at present. Therefore I'm going to leave it out of my pull requests
until it gets tested somehow.
Thanks
Guennadi
>
> diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c
> index a9061bf..a604fa0 100644
> --- a/drivers/media/video/mt9t031.c
> +++ b/drivers/media/video/mt9t031.c
> @@ -63,6 +63,8 @@
> struct mt9t031 {
> struct v4l2_subdev subdev;
> struct v4l2_rect rect; /* Sensor window */
> + unsigned int out_width;
> + unsigned int out_height;
> int model; /* V4L2_IDENT_MT9T031* codes from v4l2-chip-ident.h */
> u16 xskip;
> u16 yskip;
> @@ -284,6 +286,26 @@ static u16 mt9t031_skip(s32 *source, s32 target, s32 max)
> return skip;
> }
>
> +static u16 mt9t031_skip_out(s32 *source, s32 *target)
> +{
> + unsigned int skip;
> +
> + if (*source < *target + *target / 2) {
> + *target = *source;
> + return 1;
> + }
> +
> + skip = (*source + *target / 2) / *target;
> + if (skip > 8) {
> + skip = 8;
> + *target = (*source + 4) / 8;
> + }
> + /* We try to preserve input, but with division we have to adjust it too
> */
> + *source = *target * skip;
> +
> + return skip;
> +}
> +
> /* rect is the sensor rectangle, the caller guarantees parameter validity */
> static int mt9t031_set_params(struct i2c_client *client,
> struct v4l2_rect *rect, u16 xskip, u16 yskip)
> @@ -393,6 +415,7 @@ static int mt9t031_s_crop(struct v4l2_subdev *sd, struct
> v4l2_crop *a)
> struct v4l2_rect rect = a->c;
> struct i2c_client *client = sd->priv;
> struct mt9t031 *mt9t031 = to_mt9t031(client);
> + u16 xskip, yskip;
>
> rect.width = ALIGN(rect.width, 2);
> rect.height = ALIGN(rect.height, 2);
> @@ -403,7 +426,10 @@ static int mt9t031_s_crop(struct v4l2_subdev *sd, struct
> v4l2_crop *a)
> soc_camera_limit_side(&rect.top, &rect.height,
>MT9T031_ROW_SKIP, MT9T031_MIN_HEIGHT, MT9T031_MAX_HEIGHT);
>
> - return mt9t031_set_params(client, &rect, mt9t031->xskip,
> mt9t031->yskip);
> + xskip = mt9t031_skip_out(&rect.width, &mt9t031->out_width);
> + yskip = mt9t031_skip_out(&rect.height, &mt9t031->out_height);
> +
> + return mt9t031_set_params(client, &rect, xskip, yskip);
> }
>
> static int mt9t031_g_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
> @@ -437,8 +463,8 @@ static int mt9t031_g_fmt(struct v4l2_subdev *sd,
> struct i2c_client *client = sd->priv;
> struct mt9t031 *mt9t031 = to_mt9t031(client);
>
> - mf->width = mt9t031->rect.width / mt9t031->xskip;
> - mf->height = mt9t031->rect.height / mt9t031->yskip;
> + mf->width = mt9t031->out_width;
> + mf->height = mt9t031->out_height;
> mf->code= V4L2_MBUS_FMT_SBGGR10_1X10;
> mf->colorspace = V4L2_COLORSPACE_SRGB;
> mf->field = V4L2_FIELD_NONE;
> @@ -455,8 +481,9 @@ static int mt9t031_s_fmt(struct v4l2_subdev *sd,
> struct v4l2_rect rect = mt9t031->rect;
>
> /*
> - * try_fmt has put width and height within limits.
> - * S_FMT: use binning and skipping for scaling
> + * try_fmt has put width and height within limits. Note: when converting
> + * to a generic v4l2-subdev driver, try_fmt will have to be called
> + * explicitly. S_FMT: use binning and skipping for scaling.
>*/
> xskip = mt9t031_skip(&rect.width, mf->width, MT9T031_MAX_WIDTH);
> yskip = mt9t031_skip(&rect.height, mf->height, MT9T031_MAX_HEIGHT);
> @@ -464,6 +491,9 @@ static int mt9t031_s_fmt(struct v4l2_subdev *sd,
> mf->code= V4L2_MBUS_FMT_SBGGR10_1X10;
> mf->colorspace = V4L2_COLORSPACE_SRGB;
>
> + mt9t031->out_width = mf->width;
> + mt9t031->out_height = mf->height;
> +
> /* mt9t031_set_params() doesn't change width and height */
> return mt9t031_set_params(client, &rect, xskip, yskip);
> }
> @@ -807,6 +837,9 @@ static int mt9t031_probe(struct i2c_client *client,
> mt9t031->rect.width = MT9T031_MAX_WIDTH;
> mt9t031->rect.height= MT9T031_MAX_HEIGHT;
>
> + mt9t031->out_width = MT9T031_MAX_WIDTH;
> + mt9t031->out_height = MT9T031_MAX_HEIGHT;
> +
> /*
RE: [PATCH v1 1/2] v4l: videobuf: Add support for out-of-order buffer dequeuing.
Responding to my own e-mail here, but I just realized one little thing.
>Pawel Osciak wrote:
[snip]
>+void videobuf_buf_finish(struct videobuf_queue *q, struct videobuf_buffer *vb)
>+{
>+ unsigned long flags;
>+
>+ spin_lock_irqsave(&q->vb_done_lock, flags);
>+ list_add_tail(&vb->done_list, &q->vb_done_list);
>+ spin_unlock_irqrestore(&q->vb_done_lock, flags);
>+
>+ spin_lock_irqsave(q->irqlock, flags);
>+ wake_up(&vb->done);
>+ wake_up_interruptible(&q->vb_done_wait);
>+ spin_unlock_irqrestore(q->irqlock, flags);
>+}
>+EXPORT_SYMBOL_GPL(videobuf_buf_finish);
There is a slight problem here if this function is not called from an interrupt
context (which is the case usually though). irqlock is not held for a period of
time and vb could potentially become NULL. So a recheck against vb == NULL is
required; alternatively the function could be called by driver while holding
the irqlock the whole time. So not really a problem, just a thing to point out.
Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
