Re: SNR status for demods
Just ping up old thread since I updated that list. On 18.03.2009 04:45, Devin Heitmueller wrote: Hello all, I have updated my compiled list of the various demods and how they currently report SNR info (including feedback from people in the last round). http://www.devinheitmueller.com/snr.txt I updated that list up to that day: http://palosaari.fi/linux/v4l-dvb/snr_2012-05-21.txt Here's how you can help out: If you are a maintainer for a device in this list, please let me know so I can update the document. If you are the maintainer and somebody else's name is listed by the device, please do not take offense to this (it's probably just an error on my part [please email and correct me]). If you have specs for a device in this list where the format is currently unknown, please let me know as this will be helpful in identifying which demods we can get accurate information for. If you know something about how SNR is currently reported by the driver, and it is not reflected in this list, please let me know and I will update the document. All of the above information will be helpful once a format has been decided on, so we can pull together and finally get a consistent interface. Thank you for your time, Devin Basically, but not every case, there seems to be 3 different way: 1) return raw register value without any calculation 2) 0.1 dB 3) scaled to 0-0x using some formula Very many drivers seems to do some dB handling even finally scaling it to some value. regards Antti -- http://palosaari.fi/ -- 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
Warning in omap_vout.c
(Repost, this time without using HTML. My mailer switches to HTML once in a while for no reason. Very annoying.) The daily build has this warning: v4l-dvb-git/drivers/media/video/omap/omap_vout.c: In function ‘omapvid_init’: v4l-dvb-git/drivers/media/video/omap/omap_vout.c:381:17: warning: ‘mode’ may be used uninitialized in this function [-Wuninitialized] v4l-dvb-git/drivers/media/video/omap/omap_vout.c:331:23: note: ‘mode’ was declared here Can someone check this? The problem is that video_mode_to_dss_mode() has a 'case 0:' that never sets the mode. I suspect that the case 0 can be removed so that it goes to the default case. Can someone verify this? Regards, Hans -- 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
Warning in cx24110: how to fix?
I'm getting this warning in the daily build:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c: In function
‘cx24110_read_ucblocks’:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c:520:40: warning: value
computed is not used [-Wunused-value]
It comes from this code:
static int cx24110_read_ucblocks(struct dvb_frontend* fe, u32* ucblocks)
{
struct cx24110_state *state = fe-demodulator_priv;
if(cx24110_readreg(state,0x10)0x40) {
/* the RS error counter has finished one counting window */
cx24110_writereg(state,0x10,0x60); /* select the byer reg */
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
cx24110_writereg(state,0x10,0x70); /* select the bler reg */
state-lastbler=cx24110_readreg(state,0x12)|
(cx24110_readreg(state,0x13)8)|
(cx24110_readreg(state,0x14)16);
cx24110_writereg(state,0x10,0x20); /* start new count window */
}
*ucblocks = state-lastbler;
return 0;
}
This is the offending code:
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
Is there a reason these registers are read without storing their value?
Or is it a bug?
Regards,
Hans
--
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
[GIT PULL FIXES FOR 3.5]: gspca radio fixes
Hi Mauro et al, Here is a bunch of fixes for gspca and a couple of fixes for good old radio support :) The following changes since commit abed623ca59a7d1abed6c4e7459be03e25a90a1e: [media] radio-sf16fmi: add support for SF16-FMD (2012-05-20 16:10:05 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.5 for you to fetch changes up to fd27a1221e9e01d221d255f9159c7006fb2308b6: gspca_ov534: make AGC and AWB controls independent (2012-05-22 09:23:58 +0200) Antonio Ospite (1): gspca_ov534: make AGC and AWB controls independent Hans de Goede (9): radio/si470x: Add support for the Axentia ALERT FM USB Receiver snd_tea575x: Report correct frequency range for EU/US versus JA models snd_tea575x: Make the module using snd_tea575x the fops owner snd_tea575x: set_freq: update cached freq to the actual achieved frequency bttv: Use btv-has_radio rather then the card info when registering the tuner bttv: Remove unused needs_tvaudio card variable bttv: The Hauppauge 61334 needs the msp3410 to do radio demodulation gspca_pac7311: Correct number of controls gscpa_sn9c20x: Move clustering of controls to after error checking drivers/hid/hid-core.c|1 + drivers/hid/hid-ids.h |3 + drivers/media/radio/radio-maxiradio.c |2 +- drivers/media/radio/radio-sf16fmr2.c |2 +- drivers/media/radio/si470x/radio-si470x-usb.c |2 + drivers/media/video/bt8xx/bttv-cards.c| 84 ++--- drivers/media/video/bt8xx/bttv-driver.c |5 ++ drivers/media/video/bt8xx/bttv.h |1 - drivers/media/video/bt8xx/bttvp.h |1 + drivers/media/video/gspca/ov534.c | 31 + drivers/media/video/gspca/pac7311.c |2 +- drivers/media/video/gspca/sn9c20x.c | 24 --- include/sound/tea575x-tuner.h |3 +- sound/i2c/other/tea575x-tuner.c | 21 --- sound/pci/es1968.c|2 +- sound/pci/fm801.c |4 +- 16 files changed, 56 insertions(+), 132 deletions(-) Regards, Hans -- 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
Problems with the gspca_ov519 driver
Hello, I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5). As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to vb2. I don't know what it means. Can someone take care of the bug, or should I consider the camera 'non working' in linux? Thank you, Lluís. -- 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: Warning in omap_vout.c
On Tue, May 22, 2012 at 14:54:45, Hans Verkuil wrote: (Repost, this time without using HTML. My mailer switches to HTML once in a while for no reason. Very annoying.) The daily build has this warning: v4l-dvb-git/drivers/media/video/omap/omap_vout.c: In function 'omapvid_init': v4l-dvb-git/drivers/media/video/omap/omap_vout.c:381:17: warning: 'mode' may be used uninitialized in this function [-Wuninitialized] v4l-dvb-git/drivers/media/video/omap/omap_vout.c:331:23: note: 'mode' was declared here Can someone check this? The problem is that video_mode_to_dss_mode() has a 'case 0:' that never sets the mode. I suspect that the case 0 can be removed so that it goes to the default case. Can someone verify this? Thanks Hans for bringing my attention to this. I had submitted patch sometime back, then after couldn't able to follow up on it. http://markmail.org/thread/uuv4szdy47bjgzvh I will check on this. Thanks, Vaibhav -- 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: Warning in cx24110: how to fix?
Hans Verkuil hverk...@xs4all.nl wrote
I'm getting this warning in the daily build:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c: In function
‘cx24110_read_ucblocks’:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c:520:40: warning:
value computed is not used [-Wunused-value]
It comes from this code:
static int cx24110_read_ucblocks(struct dvb_frontend* fe, u32*
ucblocks)
{
struct cx24110_state *state = fe-demodulator_priv;
if(cx24110_readreg(state,0x10)0x40) {
/* the RS error counter has finished one counting window */
cx24110_writereg(state,0x10,0x60); /* select the byer reg */
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
cx24110_writereg(state,0x10,0x70); /* select the bler reg */
state-lastbler=cx24110_readreg(state,0x12)|
(cx24110_readreg(state,0x13)8)|
(cx24110_readreg(state,0x14)16);
cx24110_writereg(state,0x10,0x20); /* start new count window */
}
*ucblocks = state-lastbler;
return 0;
}
This is the offending code:
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
Is there a reason these registers are read without storing their value?
Or is it a bug?
Regards,
Hans
--
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
I would guess the safest thing to do is still perform the registers reads.
Will adding a (void) cast to the beginning of the statement work?
Regards,
Andy
--
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: Warning in cx24110: how to fix?
On Tue 22 May 2012 13:06:25 Andy Walls wrote:
Hans Verkuil hverk...@xs4all.nl wrote
I'm getting this warning in the daily build:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c: In function
‘cx24110_read_ucblocks’:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c:520:40: warning:
value computed is not used [-Wunused-value]
It comes from this code:
static int cx24110_read_ucblocks(struct dvb_frontend* fe, u32*
ucblocks)
{
struct cx24110_state *state = fe-demodulator_priv;
if(cx24110_readreg(state,0x10)0x40) {
/* the RS error counter has finished one counting window */
cx24110_writereg(state,0x10,0x60); /* select the byer reg */
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
cx24110_writereg(state,0x10,0x70); /* select the bler reg */
state-lastbler=cx24110_readreg(state,0x12)|
(cx24110_readreg(state,0x13)8)|
(cx24110_readreg(state,0x14)16);
cx24110_writereg(state,0x10,0x20); /* start new count window */
}
*ucblocks = state-lastbler;
return 0;
}
This is the offending code:
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
Is there a reason these registers are read without storing their value?
Or is it a bug?
Regards,
Hans
--
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
I would guess the safest thing to do is still perform the registers reads.
Will adding a (void) cast to the beginning of the statement work?
Sure, that will work. But I just wonder if anyone actually knows *why* this
is done in this way. It would be nice to have a comment here describing the
reason (if there is one, of course).
Regards,
Hans
--
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: [RFC 05/13] v4l: vb2-dma-contig: add support for DMABUF exporting
Hi Laurent,
Sorry for the late reply.
Thank you very much for noticing the issue.
+static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv)
+{
+ struct vb2_dc_buf *buf = buf_priv;
+ struct dma_buf *dbuf;
+
+ if (buf-dma_buf)
+ return buf-dma_buf;
Can't there be a race condition here if the user closes the DMABUF file
handle before vb2 core calls dma_buf_fd() ?
The user cannot access the file until it is associated with a file
descriptor. How can the user close it? Could you give me a more detailed
description of this potential race condition?
Let's assume the V4L2 buffer has already been exported once. buf-dma_buf is
set to a non-NULL value, and the application has an open file handle for the
buffer. The application then tries to export the buffer a second time.
vb2_dc_get_dmabuf() gets called, checks buf-dma_buf and returns it as it's
non-NULL. Right after that, before the vb2 core calls dma_buf_fd() on the
struct dma_buf, the application closes the file handle to the exported
buffer.
The struct dma_buf object gets freed, as the reference count drops to 0.
I am not sure if reference counter drops to 0 in this case. Notice that after
first dma_buf_export the dma_buf's refcnt is 1, after first dma_buf_fd it goes
to 2. After closing a file handle the refcnt drops back to 1 so the file
(and dma_buf) is not released. Therefore IMO there no dangling pointer issue.
However it looks that there is a circular reference between vb2_dc_buf and
dma_buf.
vb2_dc_buf::dma_buf is pointing to dma_buf with reference taken at
dma_buf_export.
On the other hand the dma_buf-priv is pointing to vb2_dc_buf with reference
taken at atomic_inc(buf-refcount) in vb2_dc_get_dmabuf.
The circular reference leads into resource leakage.
The problem could be fixed by dropping caching of dma_buf pointer.
The new dma_buf would be created and exported at every export event.
The dma_buf_put would be called in vb2_expbuf just after
successful dma_buf_fd.
Do you have any ideas how I could deal with resource leakage/dangling problems
without creating a new dma_buf instance at every export event?
Regards,
Tomasz Stanislawski
vb2 core will then try to call dma_buf_fd() on a dma_buf object that has been
freed.
+ /* dmabuf keeps reference to vb2 buffer */
+ atomic_inc(buf-refcount);
+ dbuf = dma_buf_export(buf, vb2_dc_dmabuf_ops, buf-size, 0);
+ if (IS_ERR(dbuf)) {
+ atomic_dec(buf-refcount);
+ return NULL;
+ }
+
+ buf-dma_buf = dbuf;
+
+ return dbuf;
+}
--
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: Warning in cx24110: how to fix?
Hans Verkuil hverk...@xs4all.nl wrote:
On Tue 22 May 2012 13:06:25 Andy Walls wrote:
Hans Verkuil hverk...@xs4all.nl wrote
I'm getting this warning in the daily build:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c: In function
‘cx24110_read_ucblocks’:
v4l-dvb-git/drivers/media/dvb/frontends/cx24110.c:520:40: warning:
value computed is not used [-Wunused-value]
It comes from this code:
static int cx24110_read_ucblocks(struct dvb_frontend* fe, u32*
ucblocks)
{
struct cx24110_state *state = fe-demodulator_priv;
if(cx24110_readreg(state,0x10)0x40) {
/* the RS error counter has finished one counting window
*/
cx24110_writereg(state,0x10,0x60); /* select the byer reg
*/
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
cx24110_writereg(state,0x10,0x70); /* select the bler reg
*/
state-lastbler=cx24110_readreg(state,0x12)|
(cx24110_readreg(state,0x13)8)|
(cx24110_readreg(state,0x14)16);
cx24110_writereg(state,0x10,0x20); /* start new count window
*/
}
*ucblocks = state-lastbler;
return 0;
}
This is the offending code:
cx24110_readreg(state, 0x12) |
(cx24110_readreg(state, 0x13) 8) |
(cx24110_readreg(state, 0x14) 16);
Is there a reason these registers are read without storing their
value?
Or is it a bug?
Regards,
Hans
--
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
I would guess the safest thing to do is still perform the registers
reads.
Will adding a (void) cast to the beginning of the statement work?
Sure, that will work. But I just wonder if anyone actually knows *why*
this
is done in this way. It would be nice to have a comment here describing
the
reason (if there is one, of course).
Regards,
Hans
I wouldn't agonize over it.
Assume the reads have the side effect of reseting the byer (byte error rate?)
counter before it rolls over.
The likely case is that nothing bad will happpen if you don't read that
register. A worse case is that by not reading that register, the other
measurment/count registers won't read properly.
Regards,
Andy
--
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: [git:v4l-dvb/for_v3.5] [media] au0828: Add USB ID used by many dongles
I'm glad that we were able to add support for additional devices, but
this device is not in fact the Hauppauge Woodbury that it claims to
be -- I think it would be a better idea to copy the
AU0828_BOARD_HAUPPAUGE_WOODBURY configuration into a new structure,
rename it to something more appropriate, and use that instead.
-Mike
On Sun, May 20, 2012 at 9:30 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] au0828: Add USB ID used by many dongles
Author: Ismael Luceno ismael.luc...@gmail.com
Date: Fri May 11 02:14:51 2012 -0300
Tested with Yfeng 680 ATV dongle.
Signed-off-by: Ismael Luceno ismael.luc...@gmail.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
drivers/media/video/au0828/au0828-cards.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
---
http://git.linuxtv.org/media_tree.git?a=commitdiff;h=e2b710bfde37dcc5e5c55fe09e640c1a218a81a2
diff --git a/drivers/media/video/au0828/au0828-cards.c
b/drivers/media/video/au0828/au0828-cards.c
index 1c6015a..e3fe9a6 100644
--- a/drivers/media/video/au0828/au0828-cards.c
+++ b/drivers/media/video/au0828/au0828-cards.c
@@ -325,6 +325,8 @@ struct usb_device_id au0828_usb_id_table[] = {
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
{ USB_DEVICE(0x2040, 0x7281),
.driver_info = AU0828_BOARD_HAUPPAUGE_HVR950Q_MXL },
+ { USB_DEVICE(0x05e1, 0x0480),
+ .driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
{ USB_DEVICE(0x2040, 0x8200),
.driver_info = AU0828_BOARD_HAUPPAUGE_WOODBURY },
{ USB_DEVICE(0x2040, 0x7260),
___
linuxtv-commits mailing list
linuxtv-comm...@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits
--
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: SNR status for demods
Il 22/05/2012 11:09, Antti Palosaari ha scritto: Basically, but not every case, there seems to be 3 different way: 1) return raw register value without any calculation 2) 0.1 dB 3) scaled to 0-0x using some formula Very many drivers seems to do some dB handling even finally scaling it to some value. regards Antti Another one (from staging): as102-fe.c:Pierrick Hascoet, Devin Heitmuellerlinear MER I can provide a trivial patch to convert it to the more common 0.1 dB format, if you think it's useful. This note comes from the driver: /* * Note: * - in AS102 SNR=MER * - the SNR will be returned in linear terms, i.e. not in dB * - the accuracy equals ±2dB for a SNR range from 4dB to 30dB * - the accuracy is 2dB for SNR values outside this range */ Regards, Gianluca -- 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] dma-buf: add get_dma_buf()
Hi, I think I discovered an interesting issue with dma_buf. I found out that dma_buf_fd does not increase reference count for dma_buf::file. This leads to potential kernel crash triggered by user space. Please, take a look on the scenario below: The applications spawns two thread. One of them is exporting DMABUF. Thread I | Thread II | Comments ---+---+--- dbuf = dma_buf_export | | dma_buf is creates, refcount is 1 fd = dma_buf_fd(dbuf) | | assume fd is set to 42, refcount is still 1 | close(42)| The file descriptor is closed asynchronously, dbuf's refcount drops to 0 | dma_buf_release | dbuf structure is freed, dbuf becomes a dangling pointer int size = dbuf-size; | | the dbuf is dereferenced, causing a kernel crash ---+---+--- I think that the problem could be fixed in two ways. a) forcing driver developer to call get_dma_buf just before calling dma_buf_fd. b) increasing dma_buf-file's reference count at dma_buf_fd I prefer solution (b) because it prevents symmetry between dma_buf_fd and close. I mean that dma_buf_fd increases reference count, close decreases it. What is your opinion about the issue? Regards, Tomasz Stanislawski On 03/16/2012 05:04 PM, Rob Clark wrote: From: Rob Clark r...@ti.com Works in a similar way to get_file(), and is needed in cases such as when the exporter needs to also keep a reference to the dmabuf (that is later released with a dma_buf_put()), and possibly other similar cases. Signed-off-by: Rob Clark r...@ti.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: Problems with the gspca_ov519 driver
Hi, This bug also causes the camera to crash when changing fps in guvcview, uvc devices (at least all the ones I tested) require the stream to be restarted for fps to change, so in the case of this driver after STREAMOFF the camera just becomes unresponsive. Regards, Paulo 2012/5/22 Lluís Batlle i Rossell vi...@viric.name: Hello, I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5). As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to vb2. I don't know what it means. Can someone take care of the bug, or should I consider the camera 'non working' in linux? Thank you, Lluís. -- 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 -- 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] dma-buf: add get_dma_buf()
On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote: Hi, I think I discovered an interesting issue with dma_buf. I found out that dma_buf_fd does not increase reference count for dma_buf::file. This leads to potential kernel crash triggered by user space. Please, take a look on the scenario below: The applications spawns two thread. One of them is exporting DMABUF. Thread I | Thread II | Comments ---+---+--- dbuf = dma_buf_export | | dma_buf is creates, refcount is 1 fd = dma_buf_fd(dbuf) | | assume fd is set to 42, refcount is still 1 | close(42)| The file descriptor is closed asynchronously, dbuf's refcount drops to 0 | dma_buf_release | dbuf structure is freed, dbuf becomes a dangling pointer int size = dbuf-size; | | the dbuf is dereferenced, causing a kernel crash ---+---+--- I think that the problem could be fixed in two ways. a) forcing driver developer to call get_dma_buf just before calling dma_buf_fd. b) increasing dma_buf-file's reference count at dma_buf_fd I prefer solution (b) because it prevents symmetry between dma_buf_fd and close. I mean that dma_buf_fd increases reference count, close decreases it. What is your opinion about the issue? I guess most exporters would like to hang onto the exported dma_buf a bit and hence need a reference (e.g. to cache the dma_buf as long as the underlying buffer object exists). So I guess we can change the semantics of dma_buf_fd from transferring the reference you currently have (and hence forbidding any further access by the caller) to grabbing a reference of it's on for the fd that is created. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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: Problems with the gspca_ov519 driver
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non working'
in linux?
We talked about this on irc, attached it a patch which should fix this, feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void *priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags = ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
Re: [PATCH] dma-buf: add get_dma_buf()
On 05/22/2012 04:32 PM, Daniel Vetter wrote: On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote: Hi, I think I discovered an interesting issue with dma_buf. I found out that dma_buf_fd does not increase reference count for dma_buf::file. This leads to potential kernel crash triggered by user space. Please, take a look on the scenario below: The applications spawns two thread. One of them is exporting DMABUF. Thread I | Thread II | Comments ---+---+--- dbuf = dma_buf_export | | dma_buf is creates, refcount is 1 fd = dma_buf_fd(dbuf) | | assume fd is set to 42, refcount is still 1 | close(42)| The file descriptor is closed asynchronously, dbuf's refcount drops to 0 | dma_buf_release | dbuf structure is freed, dbuf becomes a dangling pointer int size = dbuf-size; | | the dbuf is dereferenced, causing a kernel crash ---+---+--- I think that the problem could be fixed in two ways. a) forcing driver developer to call get_dma_buf just before calling dma_buf_fd. b) increasing dma_buf-file's reference count at dma_buf_fd I prefer solution (b) because it prevents symmetry between dma_buf_fd and close. I mean that dma_buf_fd increases reference count, close decreases it. What is your opinion about the issue? I guess most exporters would like to hang onto the exported dma_buf a bit and hence need a reference (e.g. to cache the dma_buf as long as the underlying buffer object exists). So I guess we can change the semantics of dma_buf_fd from transferring the reference you currently have (and hence forbidding any further access by the caller) to grabbing a reference of it's on for the fd that is created. -Daniel Hi Daniel, Would it be simpler, safer and more intuitive if dma_buf_fd increased dmabuf-file's reference counter? Regards, Tomasz Stanislawski -- 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] dma-buf: add get_dma_buf()
On Tue, May 22, 2012 at 5:00 PM, Tomasz Stanislawski t.stanisl...@samsung.com wrote: On 05/22/2012 04:32 PM, Daniel Vetter wrote: On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote: Hi, I think I discovered an interesting issue with dma_buf. I found out that dma_buf_fd does not increase reference count for dma_buf::file. This leads to potential kernel crash triggered by user space. Please, take a look on the scenario below: The applications spawns two thread. One of them is exporting DMABUF. Thread I | Thread II | Comments ---+---+--- dbuf = dma_buf_export | | dma_buf is creates, refcount is 1 fd = dma_buf_fd(dbuf) | | assume fd is set to 42, refcount is still 1 | close(42) | The file descriptor is closed asynchronously, dbuf's refcount drops to 0 | dma_buf_release | dbuf structure is freed, dbuf becomes a dangling pointer int size = dbuf-size; | | the dbuf is dereferenced, causing a kernel crash ---+---+--- I think that the problem could be fixed in two ways. a) forcing driver developer to call get_dma_buf just before calling dma_buf_fd. b) increasing dma_buf-file's reference count at dma_buf_fd I prefer solution (b) because it prevents symmetry between dma_buf_fd and close. I mean that dma_buf_fd increases reference count, close decreases it. What is your opinion about the issue? I guess most exporters would like to hang onto the exported dma_buf a bit and hence need a reference (e.g. to cache the dma_buf as long as the underlying buffer object exists). So I guess we can change the semantics of dma_buf_fd from transferring the reference you currently have (and hence forbidding any further access by the caller) to grabbing a reference of it's on for the fd that is created. -Daniel Hi Daniel, Would it be simpler, safer and more intuitive if dma_buf_fd increased dmabuf-file's reference counter? That's actually what I wanted to say. Message seems to have been lost in transit ;-) -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch -- 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] dma-buf: add get_dma_buf()
On Tue, May 22, 2012 at 4:05 PM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, May 22, 2012 at 5:00 PM, Tomasz Stanislawski t.stanisl...@samsung.com wrote: On 05/22/2012 04:32 PM, Daniel Vetter wrote: On Tue, May 22, 2012 at 03:47:12PM +0200, Tomasz Stanislawski wrote: Hi, I think I discovered an interesting issue with dma_buf. I found out that dma_buf_fd does not increase reference count for dma_buf::file. This leads to potential kernel crash triggered by user space. Please, take a look on the scenario below: The applications spawns two thread. One of them is exporting DMABUF. Thread I | Thread II | Comments ---+---+--- dbuf = dma_buf_export | | dma_buf is creates, refcount is 1 fd = dma_buf_fd(dbuf) | | assume fd is set to 42, refcount is still 1 | close(42) | The file descriptor is closed asynchronously, dbuf's refcount drops to 0 | dma_buf_release | dbuf structure is freed, dbuf becomes a dangling pointer int size = dbuf-size; | | the dbuf is dereferenced, causing a kernel crash ---+---+--- I think that the problem could be fixed in two ways. a) forcing driver developer to call get_dma_buf just before calling dma_buf_fd. b) increasing dma_buf-file's reference count at dma_buf_fd I prefer solution (b) because it prevents symmetry between dma_buf_fd and close. I mean that dma_buf_fd increases reference count, close decreases it. What is your opinion about the issue? I guess most exporters would like to hang onto the exported dma_buf a bit and hence need a reference (e.g. to cache the dma_buf as long as the underlying buffer object exists). So I guess we can change the semantics of dma_buf_fd from transferring the reference you currently have (and hence forbidding any further access by the caller) to grabbing a reference of it's on for the fd that is created. -Daniel Hi Daniel, Would it be simpler, safer and more intuitive if dma_buf_fd increased dmabuf-file's reference counter? That's actually what I wanted to say. Message seems to have been lost in transit ;-) Now I've thought about it and Tomasz has pointed it out I agree, Now we just have to work out when to drop that reference, which I don't see anyone addressing :-) I love lifetime rules. Dave. -- 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: Problems with the gspca_ov519 driver
Is this over linux 3.4 mainline? Because I can't get the patch applied over it.
Regards,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and
after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF
also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of
gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non
working'
in linux?
We talked about this on irc, attached it a patch which should fix this,
feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void
*priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void
*priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags = ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
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 0/2] s5p-mfc: added encoder support for end of stream handling
Those patches add end of stream handling for s5p-mfc encoder. The first patch was sent already to the list as RFC, but the discussion ended without any decision. This patch adds new v4l2_buffer flag V4L2_BUF_FLAG_EOS. Below short description of this change. s5p_mfc is a mem-to-mem MPEG/H263/H264 encoder and it requires that the last incoming frame must be processed differently, it means the information about the end of the stream driver should receive NOT LATER than the last V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer. Common practice of sending empty buffer to indicate end-of-stream do not work in such case. Setting V4L2_BUF_FLAG_EOS flag for the last V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer seems to be the most straightforward solution here. V4L2_BUF_FLAG_EOS flag should be used by application if driver requires it and it should be set only on V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffers. The second patch implements end-of-stream handling in s5p-mfc. Comments are welcome Andrzej Hajda -- 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 1/2] v4l: added V4L2_BUF_FLAG_EOS flag indicating the last frame in the stream
Some devices requires indicator if the buffer is the last one in the stream.
Applications and drivers can use this flag in such case.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/DocBook/media/v4l/io.xml |7 +++
Documentation/DocBook/media/v4l/vidioc-qbuf.xml |2 ++
include/linux/videodev2.h |1 +
3 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/io.xml
b/Documentation/DocBook/media/v4l/io.xml
index fd6aca2..dcbf1e0 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -956,6 +956,13 @@ Typically applications shall use this flag for output
buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
in which case caches have not been used./entry
/row
+ row
+ entryconstantV4L2_BUF_FLAG_EOS/constant/entry
+ entry0x2000/entry
+ entryApplication should set this flag in the output buffer
+in order to inform the driver about the last frame of the stream. Some
+drivers may require it to properly finish processing the stream./entry
+ /row
/tbody
/tgroup
/table
diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
index 9caa49a..ad49f7d 100644
--- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
@@ -76,6 +76,8 @@ supports capturing from specific video inputs and you want to
specify a video
input, then structfieldflags/structfield should be set to
constantV4L2_BUF_FLAG_INPUT/constant and the field
structfieldinput/structfield must be initialized to the desired input.
+Some drivers expects applications set constantV4L2_BUF_FLAG_EOS/constant
+flag on the last buffer of the stream.
The structfieldreserved/structfield field must be set to 0. When using
the link linkend=planar-apismulti-planar API/link, the
structfieldm.planes/structfield field must contain a userspace pointer
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 370d111..e44a7cd 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -676,6 +676,7 @@ struct v4l2_buffer {
/* Cache handling flags */
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
+#define V4L2_BUF_FLAG_EOS 0x2000 /* The last buffer in the stream */
/*
* O V E R L A Y P R E V I E W
--
1.7.0.4
--
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 2/2] s5p-mfc: added encoder support for end of stream handling
s5p-mfc encoder after receiving buffer with flag V4L2_BUF_FLAG_EOS
will put all buffers cached in device into capture queue.
It will indicate end of encoded stream by providing empty buffer.
Signed-off-by: Andrzej Hajda a.ha...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-mfc/s5p_mfc.c | 44 +
drivers/media/video/s5p-mfc/s5p_mfc_enc.c | 13 ++--
drivers/media/video/s5p-mfc/s5p_mfc_opr.c | 33 -
3 files changed, 72 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
b/drivers/media/video/s5p-mfc/s5p_mfc.c
index 9bb68e7..fed8f55 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc.c
@@ -539,6 +539,45 @@ static void s5p_mfc_handle_init_buffers(struct s5p_mfc_ctx
*ctx,
}
}
+static void s5p_mfc_handle_complete(struct s5p_mfc_ctx *ctx,
+unsigned int reason, unsigned int err)
+{
+ struct s5p_mfc_dev *dev = ctx-dev;
+ struct s5p_mfc_buf *mb_entry;
+ unsigned long flags;
+
+ mfc_debug(2, Stream completed);
+
+ s5p_mfc_clear_int_flags(dev);
+ ctx-int_type = reason;
+ ctx-int_err = err;
+
+ spin_lock_irqsave(dev-irqlock, flags);
+ ctx-state = MFCINST_FINISHED;
+
+ if (!list_empty(ctx-dst_queue)) {
+ mb_entry = list_entry(ctx-dst_queue.next, struct s5p_mfc_buf,
+ list);
+ list_del(mb_entry-list);
+ ctx-dst_queue_cnt--;
+ vb2_set_plane_payload(mb_entry-b, 0, 0);
+ vb2_buffer_done(mb_entry-b, VB2_BUF_STATE_DONE);
+ }
+
+ spin_unlock_irqrestore(dev-irqlock, flags);
+ if (ctx-dst_queue_cnt == 0) {
+ spin_lock(dev-condlock);
+ clear_bit(ctx-num, dev-ctx_work_bits);
+ spin_unlock(dev-condlock);
+ }
+
+ if (test_and_clear_bit(0, dev-hw_lock) == 0)
+ BUG();
+
+ s5p_mfc_clock_off();
+ wake_up(ctx-queue);
+}
+
/* Interrupt processing */
static irqreturn_t s5p_mfc_irq(int irq, void *priv)
{
@@ -614,6 +653,11 @@ static irqreturn_t s5p_mfc_irq(int irq, void *priv)
case S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET:
s5p_mfc_handle_init_buffers(ctx, reason, err);
break;
+
+ case S5P_FIMV_R2H_CMD_ENC_COMPLETE_RET:
+ s5p_mfc_handle_complete(ctx, reason, err);
+ break;
+
default:
mfc_debug(2, Unknown int reason\n);
s5p_mfc_clear_int_flags(dev);
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
index acedb20..8dec186 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_enc.c
@@ -584,7 +584,7 @@ static int s5p_mfc_ctx_ready(struct s5p_mfc_ctx *ctx)
return 1;
/* context is ready to encode remain frames */
if (ctx-state == MFCINST_FINISHING
- ctx-src_queue_cnt = 1 ctx-dst_queue_cnt = 1)
+ ctx-dst_queue_cnt = 1)
return 1;
mfc_debug(2, ctx is not ready\n);
return 0;
@@ -1715,15 +1715,8 @@ static void s5p_mfc_buf_queue(struct vb2_buffer *vb)
mfc_buf = ctx-src_bufs[vb-v4l2_buf.index];
mfc_buf-used = 0;
spin_lock_irqsave(dev-irqlock, flags);
- if (vb-v4l2_planes[0].bytesused == 0) {
- mfc_debug(1, change state to FINISHING\n);
- ctx-state = MFCINST_FINISHING;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
- cleanup_ref_queue(ctx);
- } else {
- list_add_tail(mfc_buf-list, ctx-src_queue);
- ctx-src_queue_cnt++;
- }
+ list_add_tail(mfc_buf-list, ctx-src_queue);
+ ctx-src_queue_cnt++;
spin_unlock_irqrestore(dev-irqlock, flags);
} else {
mfc_err(unsupported buffer type (%d)\n, vq-type);
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_opr.c
b/drivers/media/video/s5p-mfc/s5p_mfc_opr.c
index e6217cb..4bcf93f 100644
--- a/drivers/media/video/s5p-mfc/s5p_mfc_opr.c
+++ b/drivers/media/video/s5p-mfc/s5p_mfc_opr.c
@@ -1081,8 +1081,14 @@ int s5p_mfc_encode_one_frame(struct s5p_mfc_ctx *ctx)
else if (ctx-src_fmt-fourcc == V4L2_PIX_FMT_NV12MT)
mfc_write(dev, 3, S5P_FIMV_ENC_MAP_FOR_CUR);
s5p_mfc_set_shared_buffer(ctx);
- mfc_write(dev, (S5P_FIMV_CH_FRAME_START 16 0x7) |
- (ctx-inst_no), S5P_FIMV_SI_CH0_INST_ID);
+
+ if (ctx-state == MFCINST_FINISHING)
+ mfc_write(dev, ((S5P_FIMV_CH_LAST_FRAME S5P_FIMV_CH_MASK)
+ S5P_FIMV_CH_SHIFT) | (ctx-inst_no), S5P_FIMV_SI_CH0_INST_ID);
+
Re: [Q] vb2 userptr: struct vb2_ops::buf_cleanup() is called without buf_init()
Hi Guennadi, (CC'ing Pawel and Marek) On Monday 21 May 2012 10:30:19 Guennadi Liakhovetski wrote: Hi A recent report http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/47594 has revealed the following asymmetry in how videobuf2 functions: as is also documented in videobuf2-core.h, the user's struct vb2_ops::buf_init() method in the MMAP case is called after allocating the respective buffer, which happens at REQBUFS time, in the USERPTR case it is called after acquiring a new buffer at QBUF time. If the allocation in MMAP case fails, the respective buffer simply doesn't get created. However, if acquiring a new USERPTR buffer at QBUF time fails, the buffer object remains on the queue, but the user-provided .buf_init() method is not called for it. When the queue is destroyed, the user's .buf_cleanup() method is called on an uninitialised buffer. This is exactly the reason for the BUG() in the above referenced report. Therefore my question: is this videobuf2-core behaviour really correct and we should be prepared in .buf_cleanup() to process uninitialised buffers, or should the videobuf2-core be adjusted? From a driver's point of view, it would make sense not to call .buf_cleanup() if .buf_init() hasn't been called. Otherwise each driver would need to check whether the buffer has been initialized, which would lead to code duplication. A new buffer state would help tracking this in the vb2 core. I haven't tried to implement it though, so I might be underestimating the effort. -- 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: Problems with the gspca_ov519 driver
Hi,
On 05/22/2012 05:27 PM, Lluís Batlle i Rossell wrote:
Is this over linux 3.4 mainline? Because I can't get the patch applied over it.
No it is against:
http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5
But it should be trivial to backport, the patch is only 3 lines.
Regards,
Hans
Regards,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non working'
in linux?
We talked about this on irc, attached it a patch which should fix this, feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goedehdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goedehdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void *priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags= ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
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
--
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: RFC: V4L2 API and radio devices with multiple tuners
Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : On 19.05.2012 21:20, Hans de Goede wrote: Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. For DVB API we changed just opposite direction - from multi-frontend to single-frontend. I think one device per one standard is good choice. If I understand Hans correctly, he suggests to use two tuners on a *single* radio device node, much like a single video device nodes can have multiple video inputs. So I think you agree with Hans, and so do I. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: Problems with the gspca_ov519 driver
On Tue, May 22, 2012 at 06:28:18PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 05:27 PM, Lluís Batlle i Rossell wrote:
Is this over linux 3.4 mainline? Because I can't get the patch applied over
it.
No it is against:
http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5
But it should be trivial to backport, the patch is only 3 lines.
I tried to, but I couldn't find any match for
video_drvdata. I'll check again.
Thank you.
Regards,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and
after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF
also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of
gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non
working'
in linux?
We talked about this on irc, attached it a patch which should fix this,
feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goedehdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goedehdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void
*priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void
*priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags= ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
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
--
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: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue May 22 19:00:11 CEST 2012 git hash:abed623ca59a7d1abed6c4e7459be03e25a90a1e gcc version: i686-linux-gcc (GCC) 4.6.3 host hardware:x86_64 host os: 3.3-6.slh.2-amd64 linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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: Problems with the gspca_ov519 driver
On Tue, May 22, 2012 at 06:28:18PM +0200, Hans de Goede wrote:
On 05/22/2012 05:27 PM, Lluís Batlle i Rossell wrote:
Is this over linux 3.4 mainline? Because I can't get the patch applied over
it.
No it is against:
http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5
But it should be trivial to backport, the patch is only 3 lines.
Hello,
I ported your patch to 3.4, and it works for me. I can stream off and on as I
can with other cameras.
Thank you,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and
after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF
also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of
gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non
working'
in linux?
We talked about this on irc, attached it a patch which should fix this,
feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goedehdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goedehdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void
*priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void
*priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags= ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
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
--
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: [GIT PULL for 3.3-rc1] media updates
Hi Laurent,
On Mon, Apr 30, 2012 at 1:23 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Wednesday 25 April 2012 17:12:49 Geert Uytterhoeven wrote:
On Sun, Jan 15, 2012 at 14:41, Mauro Carvalho Chehab wrote:
Laurent Pinchart (18):
[media] uvcvideo: Move fields from uvc_buffer::buf to uvc_buffer
[media] uvcvideo: Use videobuf2-vmalloc
It seems these change (3d95e932573c316ad56b8e2f283e26de0b9c891c
resp. 6998b6fb4b1c8f320adeee938d399c4d8dcc90e2) broke the
build for nommu a while ago, as uvc_queue_get_unmapped_area() was not
or was incorrectly updated:
drivers/media/video/uvc/uvc_queue.c:254:23: error: 'struct
uvc_video_queue' has no member named 'count'
drivers/media/video/uvc/uvc_queue.c:255:18: error: 'struct
uvc_video_queue' has no member named 'buffer'
drivers/media/video/uvc/uvc_queue.c:256:19: error: 'struct vb2_buffer'
has no member named 'm'
drivers/media/video/uvc/uvc_queue.c:259:16: error: 'struct
uvc_video_queue' has no member named 'count'
drivers/media/video/uvc/uvc_queue.c:263:23: error: 'buf' undeclared
(first use in this function)
Cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/6171077/
My bad, and thanks for the report. The following patch should fix this. Do you
have a NOMMU system to test it on ?
No, I don't.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] scatterlist: add sg_alloc_table_from_pages function
On Mon, 21 May 2012 16:01:50 +0200
Tomasz Stanislawski t.stanisl...@samsung.com wrote:
+int sg_alloc_table_from_pages(struct sg_table *sgt,
+ struct page **pages, unsigned int n_pages,
+ unsigned long offset, unsigned long size,
+ gfp_t gfp_mask)
I guess a 32-bit n_pages is OK. A 16TB IO seems enough ;)
Do you think that 'unsigned long' for offset is too big?
Ad n_pages. Assuming that Moore's law holds it will take
circa 25 years before the limit of 16 TB is reached :) for
high-end scatterlist operations.
Or I can change the type of n_pages to 'unsigned long' now at
no cost :).
By then it will be Someone Else's Problem ;)
+{
+ unsigned int chunks;
+ unsigned int i;
erk, please choose a different name for this. When a C programmer sees
i, he very much assumes it has type int. Making it unsigned causes
surprise.
And don't rename it to u! Let's give it a nice meaningful name. pageno?
The problem is that 'i' is a natural name for a loop counter.
It's also the natural name for an integer. If a C programmer sees i,
he thinks int. It's a Fortran thing ;)
AFAIK, in the kernel code developers try to avoid Hungarian notation.
A name of a variable should reflect its purpose, not its type.
I can change the name of 'i' to 'pageno' and 'j' to 'pageno2' (?)
but I think it will make the code less reliable.
Well, one could do something radical such as using p.
--
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
HVR1600 and Centos 6.2 x86_64 -- Strange Behavior
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear LinuxTv and AtRpms Communities:
In the most recent three kernels {2.6.32-220.7.1 ;
2.6.32-220.13.1 ; 2.6.32-220.17.1} released for CentOS 6.2 I have
experienced what can only be described as a strange behavior of the
V4L kernel modules with the Hauppage HVR 1600 Card. If I reboot the
PC in question {HP Pavillion Elite M9040n} I will lose sound on the
Analog TV Tuner. If I Power off the PC, leave it off for 30-60
seconds and start it back up then I have sound with the Analog TV
Tuner every time. Not sure what is causing this, but thought the
condition was worth sharing.
The uname -a response is :
Linux mythbox.ladodomain 2.6.32-220.17.1.el6.x86_64 #1 SMP Wed May
16 00:01:37 BST 2012 x86_64 x86_64 x86_64 GNU/Linux
I am presently using the following modules:
Name: lirc-kmdl-2.6.32-220.17.1.el6 Relocations: (not
relocatable) Version : 0.9.0
Vendor: ATrpms.net Release : 89.el6
Build Date: Thu 17 May 2012 06:08:44 PM EDT Install Date: Mon 21
May 2012 04:26:24 PM EDT Build Host: flocki.atrpms.net Group
: System Environment/Kernel Source RPM:
lirc-0.9.0-89.el6.src.rpm Size: 261184
License: GPL Signature : DSA/SHA1, Thu 17 May 2012 06:08:45 PM
EDT, Key ID 508ce5e666534c2b Packager: ATrpms
http://ATrpms.net/ Summary : The Linux Infrared Remote
Control (LIRC) kernel drivers Description : LIRC is the Linux
Infrared Remote Control package.
This package contains the lirc kernel modules for the Linux kernel
package: kernel-2.6.32-220.17.1.el6.x86_64.x86_64.rpm. Name
: nvidia-graphics295.20-kmdl-2.6.32-220.17.1.el6 Relocations: (not
relocatable) Version : 295.20
Vendor: ATrpms.net Release : 142.el6
Build Date: Thu 17 May 2012 08:33:01 PM EDT Install Date: Mon 21
May 2012 04:26:12 PM EDT Build Host: flocki.atrpms.net Group
: System Environment/Kernel Source RPM:
nvidia-graphics295.20-295.20-142.el6.src.rpm Size: 17003384
License: NVIDIA, distributable Signature : DSA/SHA1, Thu 17 May
2012 08:33:05 PM EDT, Key ID 508ce5e666534c2b Packager: ATrpms
http://ATrpms.net/ URL :
http://www.nvidia.com/object/linux_display_ia32_295.20 Summary
: Kernel module for NVIDIA graphics architecture support
Description : NVIDIA Architecture support for systems with updated
or custom kernels.
This package contains the nvidia-graphics295.20 kernel modules for
the Linux kernel package:
kernel-2.6.32-220.17.1.el6.x86_64.x86_64.rpm. Name:
video4linux-kmdl-2.6.32-220.17.1.el6 Relocations: (not
relocatable) Version : 2024_223432
Vendor: ATrpms.net Release : 99.el6
Build Date: Fri 18 May 2012 05:29:53 AM EDT Install Date: Mon 21
May 2012 04:29:55 PM EDT Build Host: flocki.atrpms.net Group
: System Environment/Kernel Source RPM:
video4linux-2024_223432-99.el6.src.rpm Size: 13962448
License: GPLv2 Signature : DSA/SHA1, Fri 18 May 2012 05:29:57 AM
EDT, Key ID 508ce5e666534c2b Packager: ATrpms
http://ATrpms.net/ URL : http://linuxtv.org/v4lwiki/
Summary : kernel modules for V4L2 drivers Description :
This package contains the video4linux kernel modules for the Linux
kernel package: kernel-2.6.32-220.17.1.el6.x86_64.x86_64.rpm.
Sincerely,
Bob Lightfoot
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPu/g8AAoJEKqgpLIhfz3X/l0IAIUNiPa1CvD1msWC/eYVoizn
lra3mT2mHFJBUWWnBWzCZ1F/cDvzkcVaB95adHMUqDLPNLBYVOIV36XYMKhWuUWv
ydaikkcNeUFQviZBZgqz5u/R54hlQP3vgVA5oChrYIItWUFtTFDeqPCsjkmKVBlk
sIeQzF7rOMCuvutk/nD4on2kZPZcmd4mTkSpGiVv7I+6Kk+qPXYY9C48NSX599TM
GQOd1pkbVMsV/A7nnRsMTCNROYBOS+K4KP0bA6ewKKl+wmwtoJfyCCkeh5g7unIr
7rSIWy0JRTCsA6joGMXPHsf4pFlJ78sXFU/KOTpUzJ1bF4VCXy0gxwjdkCVm4pE=
=p0ZF
-END PGP SIGNATURE-
--
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 0/6] snd_tea575x: Various patches
On Sunday 20 May 2012 03:25:25 Hans de Goede wrote: Hi All, This patch series contains various patches for the tea575x driver to prepare for adding support for the Griffin radioSHARK device. The 6th patch adds support for tuning AM, which depends on the discussions surrounding the v4l2 API and radio devices with multiple tuners. I plan to add patches 1-5 to my next pull request to Mauro, I will leave patch 6 out until the API discussion is done. I tested the patches with FM-only card (SF16-FMD2) and haven't found any problems. -- Ondrej Zary -- 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: HVR1600 and Centos 6.2 x86_64 -- Strange Behavior
On Tue, May 22, 2012 at 4:34 PM, Bob Lightfoot boblf...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear LinuxTv and AtRpms Communities:
In the most recent three kernels {2.6.32-220.7.1 ;
2.6.32-220.13.1 ; 2.6.32-220.17.1} released for CentOS 6.2 I have
experienced what can only be described as a strange behavior of the
V4L kernel modules with the Hauppage HVR 1600 Card. If I reboot the
PC in question {HP Pavillion Elite M9040n} I will lose sound on the
Analog TV Tuner. If I Power off the PC, leave it off for 30-60
seconds and start it back up then I have sound with the Analog TV
Tuner every time. Not sure what is causing this, but thought the
condition was worth sharing.
Could you please clarify which HVR-1600 board you have (e.g. the PCI
ID)? I suspect we're probably not resetting the audio processor
properly, but I would need to know exactly which board you have in
order to check that.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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: RFC: V4L2 API and radio devices with multiple tuners
Hi, On 05/22/2012 06:26 PM, Rémi Denis-Courmont wrote: Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : On 19.05.2012 21:20, Hans de Goede wrote: Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. For DVB API we changed just opposite direction - from multi-frontend to single-frontend. I think one device per one standard is good choice. If I understand Hans correctly, he suggests to use two tuners on a *single* radio device node, much like a single video device nodes can have multiple video inputs. So I think you agree with Hans, and so do I. Correct, although the plan has changed in the mean time to model the 1 tuner as 1 tuner, and extend the v4l2 tuner API to deal with a tuner which can tune multiple bands. Which seems the best way forward :) Regards, Hans -- 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: RFC: V4L2 API and radio devices with multiple tuners
On Tue May 22 2012 22:45:44 Hans de Goede wrote: Hi, On 05/22/2012 06:26 PM, Rémi Denis-Courmont wrote: Le samedi 19 mai 2012 21:36:23 Antti Palosaari, vous avez écrit : On 19.05.2012 21:20, Hans de Goede wrote: Currently the V4L2 API does not allow for radio devices with more then 1 tuner, which is a bit of a historical oversight, since many radio devices have 2 tuners/demodulators 1 for FM and one for AM. Trying to model this as 1 tuner really does not work well, as they have 2 completely separate frequency bands they handle, as well as different properties (the FM part usually is stereo capable, the AM part is not). It is important to realize here that usually the AM/FM tuners are part of 1 chip, and often have only 1 frequency register which is used in both AM/FM modes. IOW it more or less is one tuner, but with 2 modes, and from a V4L2 API pov these modes are best modeled as 2 tuners. This is at least true for the radio-cadet card and the tea575x, which are the only 2 AM capable radio devices we currently know about. For DVB API we changed just opposite direction - from multi-frontend to single-frontend. I think one device per one standard is good choice. If I understand Hans correctly, he suggests to use two tuners on a *single* radio device node, much like a single video device nodes can have multiple video inputs. So I think you agree with Hans, and so do I. Correct, although the plan has changed in the mean time to model the 1 tuner as 1 tuner, and extend the v4l2 tuner API to deal with a tuner which can tune multiple bands. Which seems the best way forward :) FYI: the ADS Cadet board is also tea5757 based (no surprise there). I've put up a picture of the board here: http://hverkuil.home.xs4all.nl/ADS%20Cadet%20RDX-1187.jpg Regards, Hans -- 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: Problems with the gspca_ov519 driver
On Tue, 22 May 2012 16:39:17 +0200 Hans de Goede hdego...@redhat.com wrote: On 05/22/2012 04:08 PM, Paulo Assis wrote: Hi, This bug also causes the camera to crash when changing fps in guvcview, uvc devices (at least all the ones I tested) require the stream to be restarted for fps to change, so in the case of this driver after STREAMOFF the camera just becomes unresponsive. [...] 2012/5/22 Lluís Batlle i Rossellvi...@viric.name: Hello, I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5). [...] We talked about this on irc, attached it a patch which should fix this, feedback appreciated. Thanks HdG. Paulo, this seems to fix the problem I too was having when changing the framerate on ov534 with guvcview. IIRC, from a previous investigation, I've been experiencing this since commit f7059ea, which in fact removes the lines HdG added back, but I didn't put too much effort in investigating the exact cause, sorry. For the record the guvcview error messages were: VIDIOC_QBUF - Unable to queue buffer: Invalid argument Could not grab image (select timeout): Resource temporarily unavailable I feel I can add a: Tested-by: Antonio Ospite osp...@studenti.unina.it I can backport the change to older kernels and even CC linux-stable if you think it is appropriate, that's the least I can do to expiate for knowing about a bug/regression and not hunting its cause hard enough. HdG maybe you could mention f7059ea in the commit message of this fix if you can confirm the problem was introduced there. Regards, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- 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: HVR1600 and Centos 6.2 x86_64 -- Strange Behavior
Devin Heitmueller dheitmuel...@kernellabs.com wrote:
On Tue, May 22, 2012 at 4:34 PM, Bob Lightfoot boblf...@gmail.com
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear LinuxTv and AtRpms Communities:
In the most recent three kernels {2.6.32-220.7.1 ;
2.6.32-220.13.1 ; 2.6.32-220.17.1} released for CentOS 6.2 I have
experienced what can only be described as a strange behavior of the
V4L kernel modules with the Hauppage HVR 1600 Card. If I reboot the
PC in question {HP Pavillion Elite M9040n} I will lose sound on the
Analog TV Tuner. If I Power off the PC, leave it off for 30-60
seconds and start it back up then I have sound with the Analog TV
Tuner every time. Not sure what is causing this, but thought the
condition was worth sharing.
Could you please clarify which HVR-1600 board you have (e.g. the PCI
ID)? I suspect we're probably not resetting the audio processor
properly, but I would need to know exactly which board you have in
order to check that.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.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
Also, if you not done so already, verify that it is not a sound card playback
issue. Make a recording when you suspect the HVR1600 is not capturing sound.
Then play the recording when you know your sound is working.
Also, does audio line in with Svideo or CVBS exhibit the same symptoms?
I had to go through a good bit of trial and error to get the CX23418's APU to
capture audio reliably after boot up, so I am reluctant to mess with that
unless needed.
We will want to try to narrow the problem down to one of the analog tuner,
integrated CX25843, or APU.
Regards,
Andy
--
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
[media-ctl PATCH v3 0/4] New selection format and compose support
Hi Laurent, Update: since v2: - Use parenthesis in crop display I've updated the two first patches from the previous set as discussed. There are two new that change the selection target names to correspond the latest developments. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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
[media-ctl PATCH v3 2/4] Compose rectangle support for libv4l2subdev
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
src/main.c | 14 ++
src/options.c|6 --
src/v4l2subdev.c | 32 +++-
3 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/src/main.c b/src/main.c
index 5d88b46..0b94f2a 100644
--- a/src/main.c
+++ b/src/main.c
@@ -77,6 +77,20 @@ static void v4l2_subdev_print_format(struct media_entity
*entity,
printf(\n\t\t crop:(%u,%u)/%ux%u, rect.left, rect.top,
rect.width, rect.height);
+ ret = v4l2_subdev_get_selection(entity, rect, pad,
+ V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS,
+ which);
+ if (ret == 0)
+ printf(\n\t\t compose.bounds:%u,%u/%ux%u,
+ rect.left, rect.top, rect.width, rect.height);
+
+ ret = v4l2_subdev_get_selection(entity, rect, pad,
+ V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL,
+ which);
+ if (ret == 0)
+ printf(\n\t\t compose:%u,%u/%ux%u,
+ rect.left, rect.top, rect.width, rect.height);
+
printf(]);
}
diff --git a/src/options.c b/src/options.c
index 46f6bef..8e80bd0 100644
--- a/src/options.c
+++ b/src/options.c
@@ -56,12 +56,14 @@ static void usage(const char *argv0, int verbose)
printf(\tv4l2= pad, '[', v4l2-cfgs ']' ;\n);
printf(\tv4l2-cfgs = v4l2-cfg [ ',' v4l2-cfg ] ;\n);
printf(\tv4l2-cfg= v4l2-mbusfmt | v4l2-crop\n);
- printf(\t | v4l2 frame interval ;\n);
+ printf(\t | v4l2-compose | v4l2 frame interval
;\n);
printf(\tv4l2-mbusfmt= 'fmt:', fcc, '/', size ;\n);
printf(\tpad = entity, ':', pad number ;\n);
printf(\tentity = entity number | ( '\', entity name,
'\' ) ;\n);
printf(\tsize= width, 'x', height ;\n);
- printf(\tv4l2-crop = 'crop:(', left, ',', top, ')/', size
;\n);
+ printf(\tv4l2-crop = 'crop:', v4l2-rectangle ;\n);
+ printf(\tv4l2-compose= 'compose:', v4l2-rectangle ;\n);
+ printf(\tv4l2-rectangle = '(', left, ',', top, ')/', size ;\n);
printf(\tv4l2 frame interval = '@', numerator, '/', denominator ;\n);
printf(where the fields are\n);
printf(\tentity number Entity numeric identifier\n);
diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
index cf7c1ca..297e9d5 100644
--- a/src/v4l2subdev.c
+++ b/src/v4l2subdev.c
@@ -325,8 +325,8 @@ static int strhazit(const char *str, const char **p)
static struct media_pad *v4l2_subdev_parse_pad_format(
struct media_device *media, struct v4l2_mbus_framefmt *format,
- struct v4l2_rect *crop, struct v4l2_fract *interval, const char *p,
- char **endp)
+ struct v4l2_rect *crop, struct v4l2_rect *compose,
+ struct v4l2_fract *interval, const char *p, char **endp)
{
struct media_pad *pad;
char *end;
@@ -373,6 +373,15 @@ static struct media_pad *v4l2_subdev_parse_pad_format(
continue;
}
+ if (!strhazit(compose:, p)) {
+ ret = v4l2_subdev_parse_rectangle(compose, p, end);
+ if (ret 0)
+ return NULL;
+
+ for (p = end; isspace(*p); p++);
+ continue;
+ }
+
if (*p == '@') {
ret = v4l2_subdev_parse_frame_interval(interval, ++p,
end);
if (ret 0)
@@ -486,30 +495,35 @@ static int v4l2_subdev_parse_setup_format(struct
media_device *media,
struct v4l2_mbus_framefmt format = { 0, 0, 0 };
struct media_pad *pad;
struct v4l2_rect crop = { -1, -1, -1, -1 };
+ struct v4l2_rect compose = crop;
struct v4l2_fract interval = { 0, 0 };
unsigned int i;
char *end;
int ret;
- pad = v4l2_subdev_parse_pad_format(media, format, crop, interval,
- p, end);
+ pad = v4l2_subdev_parse_pad_format(media, format, crop, compose,
+ interval, p, end);
if (pad == NULL) {
media_dbg(media, Unable to parse format\n);
return -EINVAL;
}
- if (pad-flags MEDIA_PAD_FL_SOURCE) {
- ret = set_selection(pad, V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL,
crop);
+ if (pad-flags MEDIA_PAD_FL_SINK) {
+ ret = set_format(pad, format);
if (ret 0)
return ret;
}
- ret = set_format(pad, format);
+ ret = set_selection(pad, V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL, crop);
if (ret 0)
return ret;
- if (pad-flags
[media-ctl PATCH v3 1/4] New, more flexible syntax for format
More flexible and extensible syntax for format which allows better usage
of the selection API.
Continue supporting the old syntax but remove the documentation for it. It
was not supported in an official release and its use is thus deprecated.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
src/main.c | 17 +++--
src/options.c| 27 +-
src/v4l2subdev.c | 97 --
3 files changed, 95 insertions(+), 46 deletions(-)
diff --git a/src/main.c b/src/main.c
index 53964e4..5d88b46 100644
--- a/src/main.c
+++ b/src/main.c
@@ -59,15 +59,24 @@ static void v4l2_subdev_print_format(struct media_entity
*entity,
if (ret != 0)
return;
- printf([%s %ux%u, v4l2_subdev_pixelcode_to_string(format.code),
- format.width, format.height);
+ printf(\t\t[fmt:%s/%ux%u,
+ v4l2_subdev_pixelcode_to_string(format.code),
+ format.width, format.height);
+
+ ret = v4l2_subdev_get_selection(entity, rect, pad,
+ V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS,
+ which);
+ if (ret == 0)
+ printf(\n\t\t crop.bounds:(%u,%u)/%ux%u, rect.left, rect.top,
+ rect.width, rect.height);
ret = v4l2_subdev_get_selection(entity, rect, pad,
V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL,
which);
if (ret == 0)
- printf( (%u,%u)/%ux%u, rect.left, rect.top,
+ printf(\n\t\t crop:(%u,%u)/%ux%u, rect.left, rect.top,
rect.width, rect.height);
+
printf(]);
}
@@ -252,7 +261,7 @@ static void media_print_topology_text(struct media_device
*media)
for (j = 0; j entity-info.pads; j++) {
struct media_pad *pad = entity-pads[j];
- printf(\tpad%u: %s , j,
media_pad_type_to_string(pad-flags));
+ printf(\tpad%u: %s\n, j,
media_pad_type_to_string(pad-flags));
if (media_entity_type(entity) ==
MEDIA_ENT_T_V4L2_SUBDEV)
v4l2_subdev_print_format(entity, j,
V4L2_SUBDEV_FORMAT_ACTIVE);
diff --git a/src/options.c b/src/options.c
index 60cf6d5..46f6bef 100644
--- a/src/options.c
+++ b/src/options.c
@@ -37,8 +37,8 @@ static void usage(const char *argv0, int verbose)
printf(%s [options] device\n, argv0);
printf(-d, --device devMedia device name (default: %s)\n,
MEDIA_DEVNAME_DEFAULT);
printf(-e, --entity name Print the device name associated with
the given entity\n);
- printf(-f, --set-formatComma-separated list of formats to
setup\n);
- printf(--get-format padPrint the active format on a given
pad\n);
+ printf(-V, --set-v4l2 v4l2 Comma-separated list of formats to
setup\n);
+ printf(--get-v4l2 pad Print the active format on a given
pad\n);
printf(-h, --help Show verbose help and exit\n);
printf(-i, --interactive Modify links interactively\n);
printf(-l, --links Comma-separated list of links
descriptors to setup\n);
@@ -52,13 +52,17 @@ static void usage(const char *argv0, int verbose)
printf(\n);
printf(Links and formats are defined as\n);
- printf(\tlink= pad, '-', pad, '[', flags, ']' ;\n);
- printf(\tformat = pad, '[', fcc, ' ', size, [ ' ', crop ], [
' ', '@', frame interval ], ']' ;\n);
- printf(\tpad = entity, ':', pad number ;\n);
- printf(\tentity = entity number | ( '\', entity name, '\' )
;\n);
- printf(\tsize= width, 'x', height ;\n);
- printf(\tcrop= '(', left, ',', top, ')', '/', size ;\n);
- printf(\tframe interval = numerator, '/', denominator ;\n);
+ printf(\tlink= pad, '-', pad, '[', flags, ']' ;\n);
+ printf(\tv4l2= pad, '[', v4l2-cfgs ']' ;\n);
+ printf(\tv4l2-cfgs = v4l2-cfg [ ',' v4l2-cfg ] ;\n);
+ printf(\tv4l2-cfg= v4l2-mbusfmt | v4l2-crop\n);
+ printf(\t | v4l2 frame interval ;\n);
+ printf(\tv4l2-mbusfmt= 'fmt:', fcc, '/', size ;\n);
+ printf(\tpad = entity, ':', pad number ;\n);
+ printf(\tentity = entity number | ( '\', entity name,
'\' ) ;\n);
+ printf(\tsize= width, 'x', height ;\n);
+ printf(\tv4l2-crop = 'crop:(', left, ',', top, ')/', size
;\n);
+ printf(\tv4l2 frame interval = '@', numerator, '/', denominator ;\n);
printf(where the fields are\n);
printf(\tentity number Entity numeric identifier\n);
printf(\tentity name Entity name (string) \n);
@@ -77,7 +81,9 @@ static void usage(const char
[media-ctl PATCH v3 3/4] Drop _ACTUAL from selection target names
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- src/main.c |4 ++-- src/v4l2subdev.c |8 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/main.c b/src/main.c index 0b94f2a..c279dea 100644 --- a/src/main.c +++ b/src/main.c @@ -71,7 +71,7 @@ static void v4l2_subdev_print_format(struct media_entity *entity, rect.width, rect.height); ret = v4l2_subdev_get_selection(entity, rect, pad, - V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL, + V4L2_SUBDEV_SEL_TGT_CROP, which); if (ret == 0) printf(\n\t\t crop:(%u,%u)/%ux%u, rect.left, rect.top, @@ -85,7 +85,7 @@ static void v4l2_subdev_print_format(struct media_entity *entity, rect.left, rect.top, rect.width, rect.height); ret = v4l2_subdev_get_selection(entity, rect, pad, - V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL, + V4L2_SUBDEV_SEL_TGT_COMPOSE, which); if (ret == 0) printf(\n\t\t compose:%u,%u/%ux%u, diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c index 297e9d5..3914bd7 100644 --- a/src/v4l2subdev.c +++ b/src/v4l2subdev.c @@ -128,7 +128,7 @@ int v4l2_subdev_get_selection(struct media_entity *entity, *rect = u.sel.r; return 0; } - if (errno != ENOTTY || target != V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL) + if (errno != ENOTTY || target != V4L2_SUBDEV_SEL_TGT_CROP) return -errno; memset(u.crop, 0, sizeof(u.crop)); @@ -168,7 +168,7 @@ int v4l2_subdev_set_selection(struct media_entity *entity, *rect = u.sel.r; return 0; } - if (errno != ENOTTY || target != V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL) + if (errno != ENOTTY || target != V4L2_SUBDEV_SEL_TGT_CROP) return -errno; memset(u.crop, 0, sizeof(u.crop)); @@ -514,11 +514,11 @@ static int v4l2_subdev_parse_setup_format(struct media_device *media, return ret; } - ret = set_selection(pad, V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL, crop); + ret = set_selection(pad, V4L2_SUBDEV_SEL_TGT_CROP, crop); if (ret 0) return ret; - ret = set_selection(pad, V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL, compose); + ret = set_selection(pad, V4L2_SUBDEV_SEL_TGT_COMPOSE, compose); if (ret 0) return ret; -- 1.7.2.5 -- 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
V4L2 error with HVR-1600 TV Tuner
Summary: TV tuner was tested with mplayer, xawtv, and Mythtv. None of them worked. mplayer and xawtv both report an ioctl error originating from V4l2. Hardware and Driver Details: Platform: Debian 6.0.5 on AMD64 with kernel 2.6.32 TV tuner: Hauppauge HVR 1600 identified with a TCL M30WTP-4N-E chip. The code labelled on the tuner matches that one. Driver: Debian contained an outdated driver (cx18 couldn't identify id 168, which is the chip described above). Installing the latest driver from linuxtv.org fixed that problem. Symptoms and Testing: -v4l2-ctl works. I'm able to set frequencies, standard (e.g.: ntsc-m), and input (e.g.: S-video). -mplayer /dev/video0 works when tuner properties are set properly (i.e.: appropriate frequency, standard, and input) -mplayer tv:// ... crashes with an V4L2 ioctl error. Setting driver=v4l didn't produce the same error, but that didn't work either due to some incompatibility. mplayer tv:// didn't crash when setting driver=dummy. -xawtv also crashes with a V4L2 ioctl error. Please advise whether additional information (e.g.: dmesg, lspci outputs) is needed to identify and/or correct the problem. Steph -- 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
