[PATCH v2 1/3] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors
This flag is intended to indicate streaming errors, which might have
resulted in corrupted video data in the buffer, but the buffer can still
be reused and streaming may continue.
Setting this flag and returning 0 is different from returning EIO. The
latter should now indicate more serious (unrecoverable) errors.
This patch also solves a problem with the ioctl handling code in
vl42-ioctl.c, which does not copy buffer identification data back to the
userspace when EIO is returned, so there is no way for applications
to discover on which buffer the operation failed in such cases.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/videodev2.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 418dacf..e9222e8 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -550,6 +550,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */
#define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */
#define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */
+/* Buffer is ready, but the data contained within is corrupted.
+ * Always set together with V4L2_BUF_FLAG_DONE (for backward compatibility). */
+#define V4L2_BUF_FLAG_ERROR0x0040
#define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */
#define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */
--
1.7.0.31.g1df487
--
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 v2 2/3] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR
On Wednesday 31 March 2010 11:32:26 Pawel Osciak wrote:
For recoverable stream errors dqbuf() now returns 0 and the error flag
is set instead of returning EIO.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf-core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 63d7043..a9cfab6 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -665,6 +665,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
{
struct videobuf_buffer *buf = NULL;
int retval;
+ int err_flag = 0;
MAGIC_CHECK(q-int_ops-magic, MAGIC_QTYPE_OPS);
@@ -679,7 +680,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
switch (buf-state) {
case VIDEOBUF_ERROR:
dprintk(1, dqbuf: state is error\n);
- retval = -EIO;
+ err_flag = V4L2_BUF_FLAG_ERROR;
CALL(q, sync, q, buf);
buf-state = VIDEOBUF_IDLE;
break;
@@ -696,6 +697,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
list_del(buf-stream);
memset(b, 0, sizeof(*b));
videobuf_status(q, b, buf, q-type);
+ b-flags |= err_flag;
done:
mutex_unlock(q-vb_lock);
return retval;
I think we need to modify videobuf_status as well: if the buffer is in state
VIDEOBUF_ERROR, then videobuf_status should set both the DONE and ERROR flags.
And the dqbuf code can be simplified a bit as well if we do that:
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index bb0a1c8..29726d8 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -273,8 +273,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:
@@ -654,6 +656,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);
@@ -665,23 +668,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;
done:
mutex_unlock(q-vb_lock);
(Signed-off-by: Hans Verkuil hverk...@xs4all.nl)
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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
stv0903bab i2c-repeater question
Hello maillist! I am integrating frontend with dvb-demux driver of one device called mdemux. The frontend includes following parts: - stv0903bab demodulator - stv6110a tuner - lnbp21 power supply controller stv6110a is connected to i2c bus via stv0903's repeater. My question is about setting up i2c repeater frequency divider (I2CRPT register). stv0903 datasheet says that the speed of the i2c repeater obtained by dividing the internal chip frequency (that is, 135 MHz) budget.c driver uses value STV090x_RPTLEVEL_16 for this divider. But 135*10^6/16 is still too high to be valid i2c freq. Please explain where I'm wrong. Does the base frequency really equals to 135 Mhz? Thanks. -- Sergey -- 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
cx88 remote control event device
Hi Andrzej, Last year, you submitted a fix for the cx88 remote control not behaving properly on some cards. The fix works fine for me and lets me use my remote control, and I am very grateful for this. However, I have noticed (using powertop) that the cx88 driver is waking up the kernel 1250 times per second to handle the remote control. I understand that it is needed for proper operation when the remote control is in use. What I do not understand is why it still happens when nobody uses the remote control. Even when no application has the event device node opened, polling still happens. Can't we have the cx88 driver poll the remote control only when the device node is opened? I believe this would save some power by allowing the CPU to stay in higher C states. Thanks, -- Jean Delvare -- 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: DM1105: could not attach frontend 195d:1105
A little update on the matter. These cards are broken! It seems that the card is designed for a different NIM than what is actually on the cards. The worst problem is 3.3V power supply for the digital portion of the NIM. This powers the 3.3V IO on the Si2109, and it is unconnected! This effectively disables all the IO that is not open drain like i2c. That is why you will not get any 22khz tone from these cards. Luckily, I think I have found a way to fix it. The card is now tuning, and the 22khz tone is working. The LNB voltage is a little high, but that can be fixed by adding or replacing a resistor. I have not tried to watch TV yet, so I am not certain if it is at all possible to get these cards into working order. I will try the fix on a couple of boards and test them, and if it is successful, I will post a howto on the v4l wiki. Be warned though, it will involve the use of a soldering iron. Hendrik Skarpeid wrote: Igor M. Liplianin wrote: On 3 марта 2010 18:42:42 Hendrik Skarpeid wrote: Igor M. Liplianin wrote: Now to find GPIO's for LNB power control and ... watch TV :) Yep. No succesful tuning at the moment. There might also be an issue with the reset signal and writing to GPIOCTR, as the module at the moment loads succesfully only once. As far as I can make out, the LNB power control is probably GPIO 16 and 17, not sure which is which, and how they work. GPIO15 is wired to tuner #reset New patch to test I think the LNB voltage may be a little to high on my card, 14.5V and 20V. I would be a little more happy if they were 14 and 19, 13 and 18 would be perfect. Anyways, as Igor pointet out, I don't have any signal from the LNB, checked with another tuner card. It's a quad LNB, and the other outputs are fine. Maybe it's' toasted from to high supply voltage! I little word of warning then. Anyways, here's my tweaked 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
Re: CX23102 (Polaris?)
On Tue, 2010-03-30 at 22:50 -0600, Rich wrote: I have a ez grabber with a CX23102 windows calls it Polaris. Ubuntu 9.10 does not find it. Is there a driver for this part? Rich, (Be advised, I generally don't respond to personal emails on linux driver issues. I prefer to keep conversations public, so I'm Cc:-ing the linux-media list.) 1. Yes, there is a driver: the cx231xx module with the cx25840 module as a major supporting module. 2. The cx231xx module only has card definitions for a couple of Conexant reference designs. Defintions to support your board would need to be added to the driver before it would work. 3. Looking at the cx231xx code paths in the cx25840 module, I suspect that module may need some tweaking too. 4. If you need support for this board, and you don't want to make the patches yourself, please build a page at the V4L-DVB wiki, and provide a. USB ID information b. A list of chips on the board c. pictures of both sides of the board if you can. Also you will most likely need to get a board in the hands of developer who has time. 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
Patch regarding EyeTV Diversity
Hi, I wanted to know what happened to the patch adding support for the EyeTV Diversity: http://www.linuxtv.org/pipermail/linux-dvb/2009-February/031804.html Patrick said he applied it, but it seems it never appeared upstream? http://www.linuxtv.org/pipermail/linux-dvb/2009-February/031813.html I couldn't find any further traces. I can rebase and resend if you are interested? Kind regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH] s2255drv: video_device_alloc call not checked fix
# HG changeset patch
# User Dean Anderson d...@sensoray.com
# Date 1270045856 25200
# Node ID 2ab296deae938864b06b29cc224eb4b670ae3aa9
# Parent 18586e4ac3ed5972dac2015600f8c21e26c0fc16
s2255drv: video_device allocation fix
From: Dean Anderson d...@sensoray.com
call to video_device_alloc was not being checked in probe function.
code simplified and uses video_device inside device structure.
Priority: high
Signed-off-by: Dean Anderson d...@sensoray.com
diff -r 18586e4ac3ed -r 2ab296deae93 linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Mon Mar 29 15:11:18 2010 -0700
+++ b/linux/drivers/media/video/s2255drv.c Wed Mar 31 07:30:56 2010 -0700
@@ -224,6 +224,7 @@
struct s2255_fmt; /*forward declaration */
struct s2255_dev {
+ struct video_device vdev[MAX_CHANNELS];
int frames;
struct mutexlock;
struct mutexopen_lock;
@@ -233,7 +234,6 @@
u8 read_endpoint;
struct s2255_dmaqueue vidq[MAX_CHANNELS];
- struct video_device *vdev[MAX_CHANNELS];
struct timer_list timer;
struct s2255_fw *fw_data;
struct s2255_pipeinfo pipe;
@@ -719,10 +719,10 @@
if (fh-fmt == NULL)
return -EINVAL;
- if ((fh-width norm_minw(fh-dev-vdev[fh-channel])) ||
- (fh-width norm_maxw(fh-dev-vdev[fh-channel])) ||
- (fh-height norm_minh(fh-dev-vdev[fh-channel])) ||
- (fh-height norm_maxh(fh-dev-vdev[fh-channel]))) {
+ if ((fh-width norm_minw(fh-dev-vdev[fh-channel])) ||
+ (fh-width norm_maxw(fh-dev-vdev[fh-channel])) ||
+ (fh-height norm_minh(fh-dev-vdev[fh-channel])) ||
+ (fh-height norm_maxh(fh-dev-vdev[fh-channel]))) {
dprintk(4, invalid buffer prepare\n);
return -EINVAL;
}
@@ -896,7 +896,7 @@
int is_ntsc;
is_ntsc =
- (dev-vdev[fh-channel]-current_norm V4L2_STD_NTSC) ? 1 : 0;
+ (dev-vdev[fh-channel].current_norm V4L2_STD_NTSC) ? 1 : 0;
fmt = format_by_fourcc(f-fmt.pix.pixelformat);
@@ -1029,9 +1029,9 @@
fh-height = f-fmt.pix.height;
fh-vb_vidq.field = f-fmt.pix.field;
fh-type = f-type;
- norm = norm_minw(fh-dev-vdev[fh-channel]);
- if (fh-width norm_minw(fh-dev-vdev[fh-channel])) {
- if (fh-height norm_minh(fh-dev-vdev[fh-channel])) {
+ norm = norm_minw(fh-dev-vdev[fh-channel]);
+ if (fh-width norm_minw(fh-dev-vdev[fh-channel])) {
+ if (fh-height norm_minh(fh-dev-vdev[fh-channel])) {
if (fh-dev-cap_parm[fh-channel].capturemode
V4L2_MODE_HIGHQUALITY) {
fh-mode.scale = SCALE_4CIFSI;
@@ -1755,7 +1755,7 @@
video_device_node_name(vdev));
lock_kernel();
for (i = 0; i MAX_CHANNELS; i++)
- if (dev-vdev[i] == vdev) {
+ if (dev-vdev[i] == vdev) {
cur_channel = i;
break;
}
@@ -1985,7 +1985,6 @@
static void s2255_video_device_release(struct video_device *vdev)
{
struct s2255_dev *dev = video_get_drvdata(vdev);
- video_device_release(vdev);
kref_put(dev-kref, s2255_destroy);
return;
}
@@ -2012,19 +2011,18 @@
dev-vidq[i].dev = dev;
dev-vidq[i].channel = i;
/* register 4 video devices */
- dev-vdev[i] = video_device_alloc();
- memcpy(dev-vdev[i], template, sizeof(struct video_device));
- dev-vdev[i]-parent = dev-interface-dev;
- video_set_drvdata(dev-vdev[i], dev);
+ memcpy(dev-vdev[i], template, sizeof(struct video_device));
+ dev-vdev[i].parent = dev-interface-dev;
+ video_set_drvdata(dev-vdev[i], dev);
if (video_nr == -1)
- ret = video_register_device(dev-vdev[i],
+ ret = video_register_device(dev-vdev[i],
VFL_TYPE_GRABBER,
video_nr);
else
- ret = video_register_device(dev-vdev[i],
+ ret = video_register_device(dev-vdev[i],
VFL_TYPE_GRABBER,
cur_nr + i);
- video_set_drvdata(dev-vdev[i], dev);
+ video_set_drvdata(dev-vdev[i], dev);
if (ret != 0) {
dev_err(dev-udev-dev,
@@ -2721,8 +2719,8 @@
return 0;
errorV4L:
for (i = 0; i MAX_CHANNELS; i++)
- if (dev-vdev[i] video_is_registered(dev-vdev[i]))
- video_unregister_device(dev-vdev[i]);
+ if
[PATCH] s2255drv: removal of big kernel lock
# HG changeset patch
# User Dean Anderson d...@sensoray.com
# Date 1270046291 25200
# Node ID c72bdc8732abc0cf7bc376babfd06b2d999bdcf4
# Parent 2ab296deae938864b06b29cc224eb4b670ae3aa9
s2255drv: removal of BKL
From: Dean Anderson d...@sensoray.com
big kernel lock removed from open function.
v4l2 code does not require locking the open function except
to check asynchronous firmware load state, which is protected
by a mutex
Priority: normal
Signed-off-by: Dean Anderson d...@sensoray.com
diff -r 2ab296deae93 -r c72bdc8732ab linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Wed Mar 31 07:30:56 2010 -0700
+++ b/linux/drivers/media/video/s2255drv.c Wed Mar 31 07:38:11 2010 -0700
@@ -1753,7 +1753,6 @@
int state;
dprintk(1, s2255: open called (dev=%s)\n,
video_device_node_name(vdev));
- lock_kernel();
for (i = 0; i MAX_CHANNELS; i++)
if (dev-vdev[i] == vdev) {
cur_channel = i;
@@ -1769,7 +1768,6 @@
switch (state) {
case S2255_FW_DISCONNECTING:
mutex_unlock(dev-open_lock);
- unlock_kernel();
return -ENODEV;
case S2255_FW_FAILED:
s2255_dev_err(dev-udev-dev,
@@ -1809,30 +1807,24 @@
break;
case S2255_FW_FAILED:
printk(KERN_INFO 2255 firmware load failed.\n);
- unlock_kernel();
return -ENODEV;
case S2255_FW_DISCONNECTING:
printk(KERN_INFO %s: disconnecting\n, __func__);
- unlock_kernel();
return -ENODEV;
case S2255_FW_LOADED_DSPWAIT:
case S2255_FW_NOTLOADED:
printk(KERN_INFO %s: firmware not loaded yet
please try again later\n,
__func__);
- unlock_kernel();
return -EAGAIN;
default:
printk(KERN_INFO %s: unknown state\n, __func__);
- unlock_kernel();
return -EFAULT;
}
/* allocate + initialize per filehandle data */
fh = kzalloc(sizeof(*fh), GFP_KERNEL);
- if (NULL == fh) {
- unlock_kernel();
+ if (NULL == fh)
return -ENOMEM;
- }
file-private_data = fh;
fh-dev = dev;
fh-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
@@ -1860,7 +1852,6 @@
fh-type,
V4L2_FIELD_INTERLACED,
sizeof(struct s2255_buffer), fh);
- unlock_kernel();
return 0;
}
--
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: stv0903bab i2c-repeater question
Hi Sergey, Am 31.03.2010 12:14, schrieb Sergey Mironov: Hello maillist! I am integrating frontend with dvb-demux driver of one device called mdemux. The frontend includes following parts: - stv0903bab demodulator - stv6110a tuner - lnbp21 power supply controller stv6110a is connected to i2c bus via stv0903's repeater. My question is about setting up i2c repeater frequency divider (I2CRPT register). stv0903 datasheet says that the speed of the i2c repeater obtained by dividing the internal chip frequency (that is, 135 MHz) budget.c driver uses value STV090x_RPTLEVEL_16 for this divider. But 135*10^6/16 is still too high to be valid i2c freq. Please explain where I'm wrong. Does the base frequency really equals to 135 Mhz? Thanks. The frequency divider in I2CRPT controls the speed of the I2C repeater HW unit inside the STV0903. The I2C clock itself has the same speed as the one that is used to access the STV0903. The repeater basically just routes the signals from one bus to the other and needs a higher internal frequency to do that properly. That is the frequency you set up with I2CRPT. Regards Andreas -- 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] s2255drv: cleanup of debug messages
# HG changeset patch
# User Dean Anderson d...@sensoray.com
# Date 1270056198 25200
# Node ID db81e2f83909ee79dcca8496ceeda2653775e60a
# Parent 0690e4e1d81e785af1a5f06a13573dcf2cc5cb0c
s2255drv: cleanup of debug messages
From: Dean Anderson d...@sensoray.com
Priority: normal
Signed-off-by: Dean Anderson d...@sensoray.com
diff -r 0690e4e1d81e -r db81e2f83909 linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Wed Mar 31 09:30:44 2010 -0700
+++ b/linux/drivers/media/video/s2255drv.c Wed Mar 31 10:23:18 2010 -0700
@@ -57,10 +57,14 @@
#include linux/usb.h
#include compat.h
+#define S2255_MAJOR_VERSION1
+#define S2255_MINOR_VERSION19
+#define S2255_RELEASE 0
+#define S2255_VERSION KERNEL_VERSION(S2255_MAJOR_VERSION, \
+ S2255_MINOR_VERSION, \
+ S2255_RELEASE)
#define FIRMWARE_FILE_NAME f2255usb.bin
-
-
/* default JPEG quality */
#define S2255_DEF_JPEG_QUAL 50
/* vendor request in */
@@ -310,13 +314,6 @@
/* Need DSP version 5+ for video status feature */
#define S2255_MIN_DSP_STATUS 5
#define S2255_MIN_DSP_COLORFILTER 8
-#define S2255_MAJOR_VERSION1
-#define S2255_MINOR_VERSION18
-#define S2255_RELEASE 0
-#define S2255_VERSION KERNEL_VERSION(S2255_MAJOR_VERSION, \
- S2255_MINOR_VERSION, \
- S2255_RELEASE)
-
#define S2255_NORMS(V4L2_STD_PAL | V4L2_STD_NTSC)
/* private V4L2 controls */
@@ -503,7 +500,7 @@
static void s2255_timer(unsigned long user_data)
{
struct s2255_fw *data = (struct s2255_fw *)user_data;
- dprintk(100, s2255 timer\n);
+ dprintk(100, %s\n, __func__);
if (usb_submit_urb(data-fw_urb, GFP_ATOMIC) 0) {
printk(KERN_ERR s2255: can't submit urb\n);
atomic_set(data-fw_state, S2255_FW_FAILED);
@@ -525,7 +522,7 @@
struct s2255_fw *data = urb-context;
struct usb_device *udev = urb-dev;
int len;
- dprintk(100, udev %p urb %p, udev, urb);
+ dprintk(100, %s: udev %p urb %p, __func__, udev, urb);
if (urb-status) {
dev_err(udev-dev, URB failed with status %d\n, urb-status);
atomic_set(data-fw_state, S2255_FW_FAILED);
@@ -571,8 +568,8 @@
data-fw_loaded += len;
} else {
atomic_set(data-fw_state, S2255_FW_LOADED_DSPWAIT);
+ dprintk(100, %s: firmware upload complete\n, __func__);
}
- dprintk(100, 2255 complete done\n);
return;
}
@@ -583,9 +580,7 @@
struct s2255_buffer *buf;
unsigned long flags = 0;
int rc = 0;
- dprintk(2, wakeup: %p channel: %d\n, dma_q, chn);
spin_lock_irqsave(dev-slock, flags);
-
if (list_empty(dma_q-active)) {
dprintk(1, No active queue to serve\n);
rc = -1;
@@ -593,13 +588,11 @@
}
buf = list_entry(dma_q-active.next,
struct s2255_buffer, vb.queue);
-
list_del(buf-vb.queue);
do_gettimeofday(buf-vb.ts);
- dprintk(100, [%p/%d] wakeup\n, buf, buf-vb.i);
s2255_fillbuff(dev, buf, dma_q-channel, jpgsize);
wake_up(buf-vb.done);
- dprintk(2, wakeup [buf/i] [%p/%d]\n, buf, buf-vb.i);
+ dprintk(2, %s: [buf/i] [%p/%d]\n, __func__, buf, buf-vb.i);
unlock:
spin_unlock_irqrestore(dev-slock, flags);
return 0;
@@ -608,7 +601,6 @@
static const struct s2255_fmt *format_by_fourcc(int fourcc)
{
unsigned int i;
-
for (i = 0; i ARRAY_SIZE(formats); i++) {
if (-1 == formats[i].fourcc)
continue;
@@ -741,7 +733,6 @@
buf-vb.height = fh-height;
buf-vb.field = field;
-
if (VIDEOBUF_NEEDS_INIT == buf-vb.state) {
rc = videobuf_iolock(vq, buf-vb, NULL);
if (rc 0)
@@ -761,9 +752,7 @@
struct s2255_fh *fh = vq-priv_data;
struct s2255_dev *dev = fh-dev;
struct s2255_dmaqueue *vidq = dev-vidq[fh-channel];
-
dprintk(1, %s\n, __func__);
-
buf-vb.state = VIDEOBUF_QUEUED;
list_add_tail(buf-vb.queue, vidq-active);
}
@@ -909,10 +898,8 @@
if (field == V4L2_FIELD_ANY)
b_any_field = 1;
- dprintk(4, try format %d \n, is_ntsc);
- /* supports 3 sizes. see s2255drv.h */
- dprintk(50, width test %d, height %d\n,
- f-fmt.pix.width, f-fmt.pix.height);
+ dprintk(50, %s NTSC: %d suggested width: %d, height: %d\n,
+ __func__, is_ntsc, f-fmt.pix.width, f-fmt.pix.height);
if (is_ntsc) {
/* NTSC */
if (f-fmt.pix.height = NUM_LINES_1CIFS_NTSC * 2) {
@@ -967,29 +954,24 @@
}
}
if (f-fmt.pix.width =
Re: GIGABYTE U8000-RH Analog source support ?
2010/3/31 Fernando P. García fernandoparedesgar...@gmail.com: May you elaborate about the huge undertaking Fernando. The issue is the dvb-usb framework on which the dib0700 driver is built has absolutely no support for analog. Adding support for a new bridge (both raw video and PCM audio) is on the order of 100 hours of work for somebody who knows what they are doing. It includes adding all the V4L2 hooks and ioctls(), reverse engineering the format of the delivered video, inserting the video into videobuf, reverse engineering how audio is provided by the hardware (and how it is controlled), and creating an ALSA driver to handle the audio feed. Oh, and then you have to debug all the edge cases. I did it for the au0828 bridge, and I'm in the middle of doing it for the ngene bridge. It's a royal PITA and at this point no developer is willing to invest the time/energy to do it for free. 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: cx88 remote control event device
Hi Jean, Jean Delvare wrote: Hi Andrzej, Last year, you submitted a fix for the cx88 remote control not behaving properly on some cards. The fix works fine for me and lets me use my remote control, and I am very grateful for this. However, I have noticed (using powertop) that the cx88 driver is waking up the kernel 1250 times per second to handle the remote control. I understand that it is needed for proper operation when the remote control is in use. What I do not understand is why it still happens when nobody uses the remote control. Even when no application has the event device node opened, polling still happens. Can't we have the cx88 driver poll the remote control only when the device node is opened? I believe this would save some power by allowing the CPU to stay in higher C states. The IR can be used even when nobody is opening the /dev/video device, as it is an input device that can be used to control other things, including the start of the video application. That's said, it makes sense to only enable the polling when the /dev/input/event device is opened. Btw, the same polling logic is also present on bttv and saa7134 drivers. As I'm doing a large IR rework, with the addition of the IR core subsystem, and the patch for handing the open/close is very simple, I've already wrote a patch for saa7134, on my IR tree: http://git.linuxtv.org/mchehab/ir.git?a=commitdiff;h=2b1d3acdb48266f05b82923b8db06e6c7ada0c72 The change itself is very simple, although I've added some additional checks to avoid the risk of having an IRQ while IR is disabled. I have one cx88 board on my IR test machine (although I need to find the IR sensor for the board I'm using there). If I find one that works, I'll try later to write a similar code to cx88. -- 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: cx88 remote control event device
Mauro Carvalho Chehab wrote: Hi Jean, Jean Delvare wrote: Hi Andrzej, Last year, you submitted a fix for the cx88 remote control not behaving properly on some cards. The fix works fine for me and lets me use my remote control, and I am very grateful for this. However, I have noticed (using powertop) that the cx88 driver is waking up the kernel 1250 times per second to handle the remote control. I understand that it is needed for proper operation when the remote control is in use. What I do not understand is why it still happens when nobody uses the remote control. Even when no application has the event device node opened, polling still happens. Can't we have the cx88 driver poll the remote control only when the device node is opened? I believe this would save some power by allowing the CPU to stay in higher C states. The IR can be used even when nobody is opening the /dev/video device, as it is an input device that can be used to control other things, including the start of the video application. That's said, it makes sense to only enable the polling when the /dev/input/event device is opened. Btw, the same polling logic is also present on bttv and saa7134 drivers. As I'm doing a large IR rework, with the addition of the IR core subsystem, and the patch for handing the open/close is very simple, I've already wrote a patch for saa7134, on my IR tree: http://git.linuxtv.org/mchehab/ir.git?a=commitdiff;h=2b1d3acdb48266f05b82923b8db06e6c7ada0c72 The change itself is very simple, although I've added some additional checks to avoid the risk of having an IRQ while IR is disabled. I have one cx88 board on my IR test machine (although I need to find the IR sensor for the board I'm using there). If I find one that works, I'll try later to write a similar code to cx88. Btw, I found one sensor here and started working with it. With the new code, cx88 is generating lots of missing ticks. My IR debug log is full of those messages: [ 3276.764939] cx88[0] IR: Missed ticks 15 [ 3276.768999] cx88[0] IR: Missed ticks 3 [ 3276.772323] cx88[0] IR: Missed ticks 3 [ 3276.789027] cx88[0] IR: Missed ticks 15 [ 3276.793085] cx88[0] IR: Missed ticks 3 [ 3276.796409] cx88[0] IR: Missed ticks 3 [ 3276.813025] cx88[0] IR: Missed ticks 15 [ 3276.816347] cx88[0] IR: Missed ticks 3 [ 3276.816347] cx88[0] IR: Missed ticks 3 [ 3276.837011] cx88[0] IR: Missed ticks 15 [ 3276.840339] cx88[0] IR: Missed ticks 3 [ 3276.845028] cx88[0] IR: Missed ticks 3 [ 3276.861019] cx88[0] IR: Missed ticks 15 [ 3276.864342] cx88[0] IR: Missed ticks 3 [ 3276.869089] cx88[0] IR: Missed ticks 3 This doesn't seem right, especially since this test machine is in text mode, and there's nothing running there. -- 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: cx88 remote control event device
Hi Mauro, On Wed, 31 Mar 2010 14:46:37 -0300, Mauro Carvalho Chehab wrote: Hi Jean, Jean Delvare wrote: Hi Andrzej, Last year, you submitted a fix for the cx88 remote control not behaving properly on some cards. The fix works fine for me and lets me use my remote control, and I am very grateful for this. However, I have noticed (using powertop) that the cx88 driver is waking up the kernel 1250 times per second to handle the remote control. I understand that it is needed for proper operation when the remote control is in use. What I do not understand is why it still happens when nobody uses the remote control. Even when no application has the event device node opened, polling still happens. Can't we have the cx88 driver poll the remote control only when the device node is opened? I believe this would save some power by allowing the CPU to stay in higher C states. The IR can be used even when nobody is opening the /dev/video device, as it is an input device that can be used to control other things, including the start of the video application. That's said, it makes sense to only enable the polling when the /dev/input/event device is opened. Sorry for not being clear originally; this is exactly what I meant. Btw, the same polling logic is also present on bttv and saa7134 drivers. As I'm doing a large IR rework, with the addition of the IR core subsystem, and the patch for handing the open/close is very simple, I've already wrote a patch for saa7134, on my IR tree: http://git.linuxtv.org/mchehab/ir.git?a=commitdiff;h=2b1d3acdb48266f05b82923b8db06e6c7ada0c72 The change itself is very simple, although I've added some additional checks to avoid the risk of having an IRQ while IR is disabled. Looks very good, nice to see someone is already working on the problem. I have one cx88 board on my IR test machine (although I need to find the IR sensor for the board I'm using there). If I find one that works, I'll try later to write a similar code to cx88. Thanks, -- Jean Delvare -- 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: GIGABYTE U8000-RH Analog source support ?
So it needs 2.5 weeks, how much per hour do you estimate? Blessings. On Wed, Mar 31, 2010 at 1:45 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: 2010/3/31 Fernando P. García fernandoparedesgar...@gmail.com: May you elaborate about the huge undertaking Fernando. The issue is the dvb-usb framework on which the dib0700 driver is built has absolutely no support for analog. Adding support for a new bridge (both raw video and PCM audio) is on the order of 100 hours of work for somebody who knows what they are doing. It includes adding all the V4L2 hooks and ioctls(), reverse engineering the format of the delivered video, inserting the video into videobuf, reverse engineering how audio is provided by the hardware (and how it is controlled), and creating an ALSA driver to handle the audio feed. Oh, and then you have to debug all the edge cases. I did it for the au0828 bridge, and I'm in the middle of doing it for the ngene bridge. It's a royal PITA and at this point no developer is willing to invest the time/energy to do it for free. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- Fernando P. García, http://www.develcuy.com +51 1 9 8991 7871, Calle Santa Catalina Ancha #377, Cusco - Perú ** Before printing this message, please consider your commitment with the environment, taking care of it depends on you. ** Antes de imprimir este mensaje piensa en tu compromiso con el medio ambiente, protegerlo depende de tí. -- 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] s2255drv: v4l2 device added
On Wednesday 31 March 2010 18:34:39 Dean A. wrote:
# HG changeset patch
# User Dean Anderson d...@sensoray.com
# Date 1270053044 25200
# Node ID 0690e4e1d81e785af1a5f06a13573dcf2cc5cb0c
# Parent c72bdc8732abc0cf7bc376babfd06b2d999bdcf4
s2255drv: adding v4l2_device structure. video_register_device cleanup
From: Dean Anderson d...@sensoray.com
adding v4l2_device structure.
if one video_register_device call fails, allows use of other devices
or channels.
That's not correct. There is only one v4l2_device per USB device. And the
first argument should be dev-interface-dev, not dev-udev-dev.
When you register the video device node you shouldn't set vdev[i]-parent
anymore, instead point vdev[i]-v4l2_dev to the v4l2_device struct.
Regards,
Hans
Priority: normal
Signed-off-by: Dean Anderson d...@sensoray.com
diff -r c72bdc8732ab -r 0690e4e1d81e linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.cWed Mar 31 07:38:11 2010 -0700
+++ b/linux/drivers/media/video/s2255drv.cWed Mar 31 09:30:44 2010 -0700
@@ -51,6 +51,7 @@
#include linux/smp_lock.h
#include media/videobuf-vmalloc.h
#include media/v4l2-common.h
+#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include linux/vmalloc.h
#include linux/usb.h
@@ -77,7 +78,6 @@
#define S2255_DEF_BUFS 16
#define S2255_SETMODE_TIMEOUT 500
#define S2255_VIDSTATUS_TIMEOUT 350
-#define MAX_CHANNELS 4
#define S2255_MARKER_FRAME cpu_to_le32(0x2255DA4AL)
#define S2255_MARKER_RESPONSEcpu_to_le32(0x2255ACACL)
#define S2255_RESPONSE_SETMODE cpu_to_le32(0x01)
@@ -225,6 +225,8 @@
struct s2255_dev {
struct video_device vdev[MAX_CHANNELS];
+ struct v4l2_device v4l2_dev[MAX_CHANNELS];
+ int channels; /* number of channels registered */
int frames;
struct mutexlock;
struct mutexopen_lock;
@@ -1753,7 +1755,8 @@
int state;
dprintk(1, s2255: open called (dev=%s)\n,
video_device_node_name(vdev));
- for (i = 0; i MAX_CHANNELS; i++)
+
+ for (i = 0; i dev-channels; i++)
if (dev-vdev[i] == vdev) {
cur_channel = i;
break;
@@ -1994,7 +1997,11 @@
int ret;
int i;
int cur_nr = video_nr;
-
+ for (i = 0; i MAX_CHANNELS; i++) {
+ ret = v4l2_device_register(dev-udev-dev, dev-v4l2_dev[i]);
+ if (ret)
+ goto unreg_v4l2;
+ }
/* initialize all video 4 linux */
/* register 4 video devices */
for (i = 0; i MAX_CHANNELS; i++) {
@@ -2014,16 +2021,29 @@
VFL_TYPE_GRABBER,
cur_nr + i);
video_set_drvdata(dev-vdev[i], dev);
-
- if (ret != 0) {
+ if (ret) {
dev_err(dev-udev-dev,
failed to register video device!\n);
- return ret;
+ break;
}
+ dev-channels++;
+ v4l2_info(dev-v4l2_dev[i], V4L2 device registered as %s\n,
+ video_device_node_name(dev-vdev[i]));
+
}
+
printk(KERN_INFO Sensoray 2255 V4L driver Revision: %d.%d\n,
S2255_MAJOR_VERSION,
S2255_MINOR_VERSION);
+ /* if no channels registered, return error and probe will fail*/
+ if (dev-channels == 0)
+ return ret;
+ if (dev-channels != MAX_CHANNELS)
+ printk(KERN_WARNING s2255: Not all channels available.\n);
+ return 0;
+unreg_v4l2:
+ for (i-- ; i 0; i--)
+ v4l2_device_unregister(dev-v4l2_dev[i]);
return ret;
}
@@ -2705,13 +2725,9 @@
/* loads v4l specific */
retval = s2255_probe_v4l(dev);
if (retval)
- goto errorV4L;
+ goto errorBOARDINIT;
dev_info(interface-dev, Sensoray 2255 detected\n);
return 0;
-errorV4L:
- for (i = 0; i MAX_CHANNELS; i++)
- if (video_is_registered(dev-vdev[i]))
- video_unregister_device(dev-vdev[i]);
errorBOARDINIT:
s2255_board_shutdown(dev);
errorFWMARKER:
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: cx88 remote control event device
Jean Delvare wrote: Looks very good, nice to see someone is already working on the problem. Ok, just added there the patches for cx88 IR also. It should be noticed that, by default, the input event is enabled just after register, at least on Fedora 12. Probably udev/hal is doing it. I haven't check how to disable this behavior yet. This can be useful for those that don't want to spend power/battery or loose performance due to IR polling, or that just don't use IR. Probably, some rule using the new /sys/class/rc is enough. If you find some time to change this behavior, I'd appreciate if you could update our wiki and send me a link. Btw, don't trust yet on the rcrcv0 node there - I'll likely rename it to rc/rx0, for the first IR receiver device, and use rc/tx0, when we add there some code for IR transmitter devices. -- 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: [PATCH] s2255drv: v4l2 device added
You are correct. Please withdraw this
patch(https://patchwork.kernel.org/patch/89985/).
Regards,
Hans Verkuil wrote:
On Wednesday 31 March 2010 18:34:39 Dean A. wrote:
# HG changeset patch
# User Dean Anderson d...@sensoray.com
# Date 1270053044 25200
# Node ID 0690e4e1d81e785af1a5f06a13573dcf2cc5cb0c
# Parent c72bdc8732abc0cf7bc376babfd06b2d999bdcf4
s2255drv: adding v4l2_device structure. video_register_device cleanup
From: Dean Anderson d...@sensoray.com
adding v4l2_device structure.
if one video_register_device call fails, allows use of other devices
or channels.
That's not correct. There is only one v4l2_device per USB device. And the
first argument should be dev-interface-dev, not dev-udev-dev.
When you register the video device node you shouldn't set vdev[i]-parent
anymore, instead point vdev[i]-v4l2_dev to the v4l2_device struct.
Regards,
Hans
Priority: normal
Signed-off-by: Dean Anderson d...@sensoray.com
diff -r c72bdc8732ab -r 0690e4e1d81e linux/drivers/media/video/s2255drv.c
--- a/linux/drivers/media/video/s2255drv.c Wed Mar 31 07:38:11 2010 -0700
+++ b/linux/drivers/media/video/s2255drv.c Wed Mar 31 09:30:44 2010 -0700
@@ -51,6 +51,7 @@
#include linux/smp_lock.h
#include media/videobuf-vmalloc.h
#include media/v4l2-common.h
+#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include linux/vmalloc.h
#include linux/usb.h
@@ -77,7 +78,6 @@
#define S2255_DEF_BUFS 16
#define S2255_SETMODE_TIMEOUT 500
#define S2255_VIDSTATUS_TIMEOUT 350
-#define MAX_CHANNELS 4
#define S2255_MARKER_FRAME cpu_to_le32(0x2255DA4AL)
#define S2255_MARKER_RESPONSE cpu_to_le32(0x2255ACACL)
#define S2255_RESPONSE_SETMODE cpu_to_le32(0x01)
@@ -225,6 +225,8 @@
struct s2255_dev {
struct video_device vdev[MAX_CHANNELS];
+ struct v4l2_device v4l2_dev[MAX_CHANNELS];
+ int channels; /* number of channels registered */
int frames;
struct mutexlock;
struct mutexopen_lock;
@@ -1753,7 +1755,8 @@
int state;
dprintk(1, s2255: open called (dev=%s)\n,
video_device_node_name(vdev));
- for (i = 0; i MAX_CHANNELS; i++)
+
+ for (i = 0; i dev-channels; i++)
if (dev-vdev[i] == vdev) {
cur_channel = i;
break;
@@ -1994,7 +1997,11 @@
int ret;
int i;
int cur_nr = video_nr;
-
+ for (i = 0; i MAX_CHANNELS; i++) {
+ ret = v4l2_device_register(dev-udev-dev, dev-v4l2_dev[i]);
+ if (ret)
+ goto unreg_v4l2;
+ }
/* initialize all video 4 linux */
/* register 4 video devices */
for (i = 0; i MAX_CHANNELS; i++) {
@@ -2014,16 +2021,29 @@
VFL_TYPE_GRABBER,
cur_nr + i);
video_set_drvdata(dev-vdev[i], dev);
-
- if (ret != 0) {
+ if (ret) {
dev_err(dev-udev-dev,
failed to register video device!\n);
- return ret;
+ break;
}
+ dev-channels++;
+ v4l2_info(dev-v4l2_dev[i], V4L2 device registered as %s\n,
+ video_device_node_name(dev-vdev[i]));
+
}
+
printk(KERN_INFO Sensoray 2255 V4L driver Revision: %d.%d\n,
S2255_MAJOR_VERSION,
S2255_MINOR_VERSION);
+ /* if no channels registered, return error and probe will fail*/
+ if (dev-channels == 0)
+ return ret;
+ if (dev-channels != MAX_CHANNELS)
+ printk(KERN_WARNING s2255: Not all channels available.\n);
+ return 0;
+unreg_v4l2:
+ for (i-- ; i 0; i--)
+ v4l2_device_unregister(dev-v4l2_dev[i]);
return ret;
}
@@ -2705,13 +2725,9 @@
/* loads v4l specific */
retval = s2255_probe_v4l(dev);
if (retval)
- goto errorV4L;
+ goto errorBOARDINIT;
dev_info(interface-dev, Sensoray 2255 detected\n);
return 0;
-errorV4L:
- for (i = 0; i MAX_CHANNELS; i++)
- if (video_is_registered(dev-vdev[i]))
- video_unregister_device(dev-vdev[i]);
errorBOARDINIT:
s2255_board_shutdown(dev);
errorFWMARKER:
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.791 / Virus Database: 271.1.1/2781 - Release Date: 03/30/10 23:32:00
--
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:Wed Mar 31 19:00:18 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14536:a539e5b68945 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 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: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS 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: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS 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: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS 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: WARNINGS 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: webcam problem after suspend/hibernate
Hi, Do you mean the dmesg output ? A full dmesg is included in this address : http://pastebin.com/8XU619Uk Not in all suspend/hibernate the problem comes, only in some of them and this included dmesg output is just after a non working case of webcam fault. I also have found this in `/var/log/messages | grep uvcvideo` Mar 31 00:31:16 linux-l365 kernel: [399905.714743] usbcore: deregistering interface driver uvcvideo Mar 31 00:31:24 linux-l365 kernel: [399914.121386] uvcvideo: Found UVC 1.00 device LG Webcam (0c45:62c0) Mar 31 00:31:24 linux-l365 kernel: [399914.135661] usbcore: registered new interface driver uvcvideo and in `cat /proc/modules | grep uvcvideo` uvcvideo 65900 0 - Live 0xfa386000 videodev 39168 1 uvcvideo, Live 0xf8244000 v4l1_compat 16004 2 uvcvideo,videodev, Live 0xf822f000 And thanks in advance for you help. On Wed, Mar 31, 2010 at 1:25 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Mohamed, On Tuesday 30 March 2010 23:55:38 Mohamed Ikbel Boulabiar wrote: Hi, After suspend/resume, I have my webcam no more working. The /dev/video0 file still exist, but the webcam won't be used until I do this : rmmod uvcvideo modprobe uvcvideo (2.6.31.8-0.1) This is may be caused by a bug somewhere. These are more information about my hardware : I have Microdia webcam `lsusb` Bus 001 Device 004: ID 0c45:62c0 Microdia Sonix USB 2.0 Camera on openSUSE 11.2 `uname -a` Linux linux-l365 2.6.31.8-0.1-desktop #1 SMP PREEMPT 2009-12-15 23:55:40 +0100 i686 i686 i386 GNU/Linux `hwinfo --usb` : USB 00.0: Unclassified device [Created at usb.122] UDI: /org/freedesktop/Hal/devices/usb_device_c45_62c0_1_3_2_1_7_if0_logicaldev_ input Unique ID: Uc5H.F0c0EBqBP10 Parent ID: k4bc.9T1GDCLyFd9 SysFS ID: /devices/pci:00/:00:1d.7/usb1/1-4/1-4:1.0 SysFS BusID: 1-4:1.0 Hardware Class: unknown Model: Microdia LG Webcam Hotplug: USB Vendor: usb 0x0c45 Microdia Device: usb 0x62c0 LG Webcam Revision: 32.17 Serial ID: 1.3.2.1.7 Driver: uvcvideo Driver Modules: uvcvideo Device File: /dev/input/event8 Device Files: /dev/input/event8, /dev/char/13:72, /dev/input/by-id/usb-LG_Innotek_LG_Webcam_1.3.2.1.7-event-if00, /dev/input/by-path/pci-:00:1d.7-usb-0:4:1.0-event Device Number: char 13:72 Speed: 480 Mbps Module Alias: usb:v0C45p62C0d3217dcEFdsc02dp01ic0Eisc01ip00 Driver Info #0: Driver Status: uvcvideo is active Driver Activation Cmd: modprobe uvcvideo Config Status: cfg=no, avail=yes, need=no, active=unknown Attached to: #4 (Hub) If there is a scenario you propose me to do to detect from where comes the problem, I can apply it. Could you please post the messages printed by the uvcvideo driver and USB core to the kernel log when you suspend and resume your system ? Thanks. -- 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 v2 1/2] v4l: Add V4L2_CID_IRIS_ABSOLUTE and V4L2_CID_IRIS_RELATIVE controls
Hi Frank,
On Friday 19 March 2010 16:26:12 Frank Schaefer wrote:
Laurent Pinchart schrieb:
Those control, as their names imply, control the camera aperture
settings.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/v4l/compat.xml | 11 +++
Documentation/DocBook/v4l/controls.xml| 19 +++
Documentation/DocBook/v4l/videodev2.h.xml |3 +++
include/linux/videodev2.h |3 +++
4 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/Documentation/DocBook/v4l/compat.xml
b/Documentation/DocBook/v4l/compat.xml index b9dbdf9..854235b 100644
--- a/Documentation/DocBook/v4l/compat.xml
+++ b/Documentation/DocBook/v4l/compat.xml
@@ -2332,6 +2332,17 @@ more information./para
/listitem
/orderedlist
/section
+section
+ titleV4L2 in Linux 2.6.34/title
+ orderedlist
+ listitem
+ paraAdded
+constantV4L2_CID_IRIS_ABSOLUTE/constant and
+constantV4L2_CID_IRIS_RELATIVE/constant controls to the
+ link linkend=camera-controlsCamera controls class/link.
+ /para
+ /listitem
+ /orderedlist
/section
section id=other
diff --git a/Documentation/DocBook/v4l/controls.xml
b/Documentation/DocBook/v4l/controls.xml index f464506..e47999d 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1825,6 +1825,25 @@ wide-angle direction. The zoom speed unit is
driver-specific./entry
rowentry/entry/row
row
+ entry
spanname=idconstantV4L2_CID_IRIS_ABSOLUTE/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control sets the
+camera's aperture to the specified value. The unit is undefined.
+Larger values open the iris wider, smaller values close it./entry
+ /row
+ rowentry/entry/row
+
+ row
+ entry
spanname=idconstantV4L2_CID_IRIS_RELATIVE/constantnbsp;/entry
+ entryinteger/entry
+ /rowrowentry spanname=descrThis control modifies the
+camera's aperture by the specified amount. The unit is undefined.
+Positive values open the iris one step further, negative values close
+it one step further. This is a write-only control./entry
+ /row
+ rowentry/entry/row
+
+ row
entry
spanname=idconstantV4L2_CID_PRIVACY/constantnbsp;/entry
entryboolean/entry
/rowrowentry spanname=descrPrevent video from being acquired
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml
b/Documentation/DocBook/v4l/videodev2.h.xml index 0683259..c18dfeb
100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -1271,6 +1271,9 @@ enum link
linkend=v4l2-exposure-auto-typev4l2_exposure_auto_type/link {
#define V4L2_CID_PRIVACY
(V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_IRIS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+17) +#define V4L2_CID_IRIS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+18) +
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX |
0x900) #define V4L2_CID_FM_TX_CLASS
(V4L2_CTRL_CLASS_FM_TX | 1)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 3c26560..c9d2120 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1277,6 +1277,9 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+#define V4L2_CID_IRIS_ABSOLUTE
(V4L2_CID_CAMERA_CLASS_BASE+17)
+#define V4L2_CID_IRIS_RELATIVE
(V4L2_CID_CAMERA_CLASS_BASE+18)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX
| 1)
Please also add proper titles to v4l2_ctrl_get_name() in v4l2-common.c.
Very good point. I'll resubmit the patches.
--
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] Fix default state Beholder H6 tuner.
Hi Dimitry,
Am Mittwoch, den 31.03.2010, 13:14 +1000 schrieb Dmitri Belimov:
Hi Hermann
Hi,
Am Dienstag, den 30.03.2010, 16:02 +1000 schrieb Dmitri Belimov:
Hi
The hybrid tuner FMD1216MEX_MK3 after cold start has disabled IF.
This tuner has internal I2C switch. This switch switch I2C bus
between DVB-T and IF part. Default state is DVB-T. When module
saa7134 is load it can't find IF tda9887 and disable analog TV mode.
This patch set internal I2C switch of the tuner to IF by send
special value to the tuner as for receive analog TV from low band.
It can be usefule for other cards.
I didn't set configure a tuner by a tuner model because this tuner
can has different I2C address. May be we can do it later after
discuss for more robust support a tuners.
just as a reminder. It is the same for the FMD1216ME hybrid MK3.
After every boot, analog mode fails with missing tda9887.
Currently, after tuner modules are not independent anymore, one has to
reload the saa7134 driver once.
Relevant code in tuner.core.c.
case TUNER_PHILIPS_FMD1216ME_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
buffer[2] = 0x9c;
buffer[3] = 0x60;
i2c_master_send(c, buffer, 4);
mdelay(1);
buffer[2] = 0x86;
buffer[3] = 0x54;
i2c_master_send(c, buffer, 4);
if (!dvb_attach(simple_tuner_attach, t-fe,
t-i2c-adapter, t-i2c-addr,
t-type)) goto attach_failed;
break;
That is good. I'll try add case TUNER_PHILIPS_FMD1216MEX_MK3 here and test.
This is much better.
it wont work for any what I can tell.
We were forced into such an universal looking solution, but it was
broken only a short time later.
I for sure don't say that this time, late 2005, it was in anyway
perfect, too much random on module load orders and also duplicate
address stuff around meanwhile.
But, however, it seems to be blocked for a global attempt within the
current schemes too.
Cheers,
Hermann
With my best regards, Dmitry.
Hermann
diff -r 1ef0265456c8
linux/drivers/media/video/saa7134/saa7134-cards.c ---
a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri Mar
26 00:54:18 2010 -0300 +++
b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun Mar
28 08:21:10 2010 -0400 @@ -7450,6 +7450,21 @@ } break;
}
+ case SAA7134_BOARD_BEHOLD_H6:
+ {
+ u8 data[] = { 0x09, 0x9f, 0x86, 0x11};
+ struct i2c_msg msg = {.addr = 0x61, .flags =
0, .buf = data,
+ .len =
sizeof(data)}; +
+ /* The tuner TUNER_PHILIPS_FMD1216MEX_MK3 after
hardware*/
+ /* start has disabled IF and enabled DVB-T. When
saa7134*/
+ /* scan I2C devices it not detect IF tda9887 and
can`t */
+ /* watch TV without software reboot. For solve
this problem */
+ /* switch the tuner to analog TV mode
manually. */
+ if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
+ printk(KERN_WARNING
+ %s: Unable to enable IF of
the tuner.\n,
+dev-name);
+ break;
+ }
} /* switch() */
/* initialize tuner */
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
d.beli...@gmail.com
With my best regards, Dmitry.
--
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] Fix default state Beholder H6 tuner.
Hi Hermann
Hi Dimitry,
Am Mittwoch, den 31.03.2010, 13:14 +1000 schrieb Dmitri Belimov:
Hi Hermann
Hi,
Am Dienstag, den 30.03.2010, 16:02 +1000 schrieb Dmitri Belimov:
Hi
The hybrid tuner FMD1216MEX_MK3 after cold start has disabled
IF. This tuner has internal I2C switch. This switch switch I2C
bus between DVB-T and IF part. Default state is DVB-T. When
module saa7134 is load it can't find IF tda9887 and disable
analog TV mode.
This patch set internal I2C switch of the tuner to IF by send
special value to the tuner as for receive analog TV from low
band. It can be usefule for other cards.
I didn't set configure a tuner by a tuner model because this
tuner can has different I2C address. May be we can do it later
after discuss for more robust support a tuners.
just as a reminder. It is the same for the FMD1216ME hybrid MK3.
After every boot, analog mode fails with missing tda9887.
Currently, after tuner modules are not independent anymore, one
has to reload the saa7134 driver once.
Relevant code in tuner.core.c.
case TUNER_PHILIPS_FMD1216ME_MK3:
buffer[0] = 0x0b;
buffer[1] = 0xdc;
buffer[2] = 0x9c;
buffer[3] = 0x60;
i2c_master_send(c, buffer, 4);
mdelay(1);
buffer[2] = 0x86;
buffer[3] = 0x54;
i2c_master_send(c, buffer, 4);
if (!dvb_attach(simple_tuner_attach, t-fe,
t-i2c-adapter, t-i2c-addr,
t-type)) goto attach_failed;
break;
That is good. I'll try add case TUNER_PHILIPS_FMD1216MEX_MK3 here
and test. This is much better.
it wont work for any what I can tell.
We were forced into such an universal looking solution, but it was
broken only a short time later.
I for sure don't say that this time, late 2005, it was in anyway
perfect, too much random on module load orders and also duplicate
address stuff around meanwhile.
But, however, it seems to be blocked for a global attempt within the
current schemes too.
Yes. Not worked. My patch is good for our customers right now. But when this
subsystem is ready we can switch
to use it.
With my best regards, Dmitry.
Cheers,
Hermann
With my best regards, Dmitry.
Hermann
diff -r 1ef0265456c8
linux/drivers/media/video/saa7134/saa7134-cards.c ---
a/linux/drivers/media/video/saa7134/saa7134-cards.c Fri
Mar 26 00:54:18 2010 -0300 +++
b/linux/drivers/media/video/saa7134/saa7134-cards.c Sun
Mar 28 08:21:10 2010 -0400 @@ -7450,6 +7450,21 @@ } break;
}
+ case SAA7134_BOARD_BEHOLD_H6:
+ {
+ u8 data[] = { 0x09, 0x9f, 0x86, 0x11};
+ struct i2c_msg msg = {.addr = 0x61, .flags =
0, .buf = data,
+ .len =
sizeof(data)}; +
+ /* The tuner TUNER_PHILIPS_FMD1216MEX_MK3 after
hardware*/
+ /* start has disabled IF and enabled DVB-T.
When saa7134*/
+ /* scan I2C devices it not detect IF tda9887
and can`t */
+ /* watch TV without software reboot. For solve
this problem */
+ /* switch the tuner to analog TV mode
manually. */
+ if (i2c_transfer(dev-i2c_adap, msg, 1) != 1)
+ printk(KERN_WARNING
+ %s: Unable to enable IF
of the tuner.\n,
+ dev-name);
+ break;
+ }
} /* switch() */
/* initialize tuner */
Signed-off-by: Beholder Intl. Ltd. Dmitry Belimov
d.beli...@gmail.com
With my best regards, Dmitry.
--
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] What are the goals for the architecture of an in-kernel IR system?
David Härdeman wrote: On Sun, Mar 28, 2010 at 09:51:17PM -0300, Mauro Carvalho Chehab wrote: I spoke too soon... removing the index causes a problem at the read ioctl: there's no way to retrieve just the non-sparsed values. There's one solution that would allow both read/write and compat to work nicely, but the API would become somewhat asymmetrical: At get (EVIOCGKEYCODEBIG): use index/len as input and keycode/scancode as output; At set (EVIOCSKEYCODEBIG): use scancode/keycode/len as input (and, optionally, index as output). This was exactly the approach I had in mind when I suggested using indexes. Doesn't work perfectly. The asymmetry has a side effect on the internal logic: EVIOCGKEYCODEBIG should be implemented with a pseudo-code like: kt_entry = getkeycodebig_from_index(index); EVIOCSKEYCODEBIG should be implemented with a pseudo-code like: kt_entry = getkeycodebig_from_scan(scan, len); old_key = kt_entry-keycode; kt_entry-keycode = newkey; if (setkeycodebig(kt_entry) == 0) keyup(old_key); As you see, the input parameters for the getkeycodebig*() are different. So, this approach requires 3 ops instead of 2. Yet, as scancode-keycode is needed anyway, this doesn't actually hurts. I just added the patches that implement those two ioctls on my IR development tree. I tested only the original EVIOCGKEYCODE/EVIOSGKEYCODE and calling a clear_table function using EVIOCSKEYCODEBIG via emulation. My next step is to test the remaining ir-keytable functions via emulation, and then implement the *BIG ioctls at ir-core, for testing. I haven't test yet the *keycode*default methods. After having it fully tested, I'll submit the complete input ioctl patch via ML. -- 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: genius islim 310 webcam test
On Wed, 31 Mar 2010 07:56:59 +0200 Németh Márton nm...@freemail.hu wrote: The next thing is that you need to learn how to compile the Linux kernel from source code. There is a description for Ubuntu at https://help.ubuntu.com/community/Kernel/Compile . After you are able to compile and install your new kernel, you can try to apply the patch in this email, recompile the kernel, install the kernel and the modules, unload the gspca_pac7302 kernel module (rmmod gspca_pac7302), and then plug the webcam in order it can load the new kernel module. When you were successful with these steps you'll see new messages in the output of dmesg command. Please send this output also. Hello Németh and Sergei, I think the patch is not needed because it just gives the vend:prod which is already known by lsusb. On the other hand, compiling a full kernel is not needed with a small tarball distribution as the one I have in my page (actual gspca-2.9.10). Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: genius islim 310 webcam test
Jean-Francois Moine írta: On Wed, 31 Mar 2010 07:56:59 +0200 Németh Márton nm...@freemail.hu wrote: The next thing is that you need to learn how to compile the Linux kernel from source code. There is a description for Ubuntu at https://help.ubuntu.com/community/Kernel/Compile . After you are able to compile and install your new kernel, you can try to apply the patch in this email, recompile the kernel, install the kernel and the modules, unload the gspca_pac7302 kernel module (rmmod gspca_pac7302), and then plug the webcam in order it can load the new kernel module. When you were successful with these steps you'll see new messages in the output of dmesg command. Please send this output also. Hello Németh and Sergei, I think the patch is not needed because it just gives the vend:prod which is already known by lsusb. To avoid misunderstandings, the patch I sent is not just printing the USB vendor ID and product ID but also really enables the pac7302 gspca subdriver to actually work with the newly added USB IDs. On the other hand, compiling a full kernel is not needed with a small tarball distribution as the one I have in my page (actual gspca-2.9.10). This is also a possible way to go, the important thing is that a kernel module has to be built and the previous version of gspca_pac7302 kernel module has to be replaced with the newly built one. Regards, Márton Németh -- 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 1/2] v4l: Add memory-to-memory device helper framework for videobuf.
Andy Walls [mailto:awa...@md.metrocast.net] wrote:
I didn't do a full review (I have no time lately), but I noticed this:
+static void v4l2_m2m_try_schedule(struct v4l2_m2m_ctx *m2m_ctx)
+{
+struct v4l2_m2m_dev *m2m_dev;
[...]
+v4l2_m2m_try_run(m2m_dev);
+}
[...]
+void v4l2_m2m_job_finish(struct v4l2_m2m_dev *m2m_dev,
+ struct v4l2_m2m_ctx *m2m_ctx)
+{
[...]
+ v4l2_m2m_try_schedule(m2m_ctx);
+v4l2_m2m_try_run(m2m_dev);
+}
I assume it is not bad, but was it your intention to have an addtitonal
call to v4l2_m2m_try_run() ?
Thanks for noticing that, but yes, this is intentional. Simplifies the code
a bit and will work properly.
Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland RD 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] V4L/DVB: mx1-camera: compile fix
On Sun, Mar 28, 2010 at 10:12:06PM +0200, Guennadi Liakhovetski wrote: On Sat, 27 Mar 2010, Uwe Kleine-König wrote: This fixes a regression of 7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old names) Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Sascha, I need your ack to pull this via my tree. Here we go: Acked-by: Sascha Hauer s.ha...@pengutronix.de Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v2 0/3] Fix DQBUF behavior for recoverable streaming errors
Hello, this is the second version of a series that introduces a V4L2_BUF_FLAG_ERROR flag for recoverable stream errors. It allows applications to gracefully recover in case of such errors instead of losing the buffer or having to guess its index. Changes since v1: - the new flag is not returned along with V4L2_BUF_FLAG_DONE (I misinterpreted the docs previously) This series contains: [PATCH v2 1/3] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors [PATCH v2 2/3] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR [PATCH v2 3/3] v4l: Add documentation for the new error flag Best regards -- Pawel Osciak Linux Platform Group Samsung Poland RD 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
[PATCH v2 2/3] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR
For recoverable stream errors dqbuf() now returns 0 and the error flag
is set instead of returning EIO.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf-core.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 63d7043..a9cfab6 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -665,6 +665,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
{
struct videobuf_buffer *buf = NULL;
int retval;
+ int err_flag = 0;
MAGIC_CHECK(q-int_ops-magic, MAGIC_QTYPE_OPS);
@@ -679,7 +680,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
switch (buf-state) {
case VIDEOBUF_ERROR:
dprintk(1, dqbuf: state is error\n);
- retval = -EIO;
+ err_flag = V4L2_BUF_FLAG_ERROR;
CALL(q, sync, q, buf);
buf-state = VIDEOBUF_IDLE;
break;
@@ -696,6 +697,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
list_del(buf-stream);
memset(b, 0, sizeof(*b));
videobuf_status(q, b, buf, q-type);
+ b-flags |= err_flag;
done:
mutex_unlock(q-vb_lock);
return retval;
--
1.7.0.31.g1df487
--
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 v2 3/3] v4l: Add documentation for the new error flag
Add documentation for V4L2_BUF_FLAG_ERROR. Signed-off-by: Pawel Osciak p.osc...@samsung.com --- Documentation/DocBook/v4l/io.xml | 10 ++ Documentation/DocBook/v4l/vidioc-qbuf.xml | 14 -- 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/v4l/io.xml b/Documentation/DocBook/v4l/io.xml index e870330..1bc2057 100644 --- a/Documentation/DocBook/v4l/io.xml +++ b/Documentation/DocBook/v4l/io.xml @@ -702,6 +702,16 @@ They can be both cleared however, then the buffer is in dequeued state, in the application domain to say so./entry /row row + entryconstantV4L2_BUF_FLAG_ERROR/constant/entry + entry0x0040/entry + entryWhen this flag is set, the buffer has been dequeued + sucessfully, although the data might have been corrupted. + This is recoverable, streaming may continue as normal and + the buffer may be reused normally. + Drivers set this flag when the constantVIDIOC_DQBUF/constant + ioctl is called./entry + /row + row entryconstantV4L2_BUF_FLAG_KEYFRAME/constant/entry entry0x0008/entry entryDrivers set or clear this flag when calling the diff --git a/Documentation/DocBook/v4l/vidioc-qbuf.xml b/Documentation/DocBook/v4l/vidioc-qbuf.xml index b843bd7..ab691eb 100644 --- a/Documentation/DocBook/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/v4l/vidioc-qbuf.xml @@ -111,7 +111,11 @@ from the driver's outgoing queue. They just set the and structfieldreserved/structfield fields of a v4l2-buffer; as above, when constantVIDIOC_DQBUF/constant is called with a pointer to this structure the driver fills the -remaining fields or returns an error code./para +remaining fields or returns an error code. The driver may also set +constantV4L2_BUF_FLAG_ERROR/constant in the structfieldflags/structfield +field. It indicates a non-critical (recoverable) streaming error. In such case +the application may continue as normal, but should be aware that data in the +dequeued buffer might be corrupted./para paraBy default constantVIDIOC_DQBUF/constant blocks when no buffer is in the outgoing queue. When the @@ -158,7 +162,13 @@ enqueue a user pointer buffer./para paraconstantVIDIOC_DQBUF/constant failed due to an internal error. Can also indicate temporary problems like signal loss. Note the driver might dequeue an (empty) buffer despite -returning an error, or even stop capturing./para +returning an error, or even stop capturing. Reusing such buffer may be unsafe +though and its details (e.g. structfieldindex/structfield) may not be +returned either. It is recommended that drivers indicate recoverable errors +by setting the constantV4L2_BUF_FLAG_ERROR/constant and returning 0 instead. +In that case the application should be able to safely reuse the buffer and +continue streaming. + /para /listitem /varlistentry /variablelist -- 1.7.0.31.g1df487 -- 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
