Re: av7110 and budget_av are broken!
Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! -- 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: av7110 and budget_av are broken!
Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! Regards, Hans 'still stuck in San Francisco' Verkuil -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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/master] V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
Hello Mauro, Mauro Carvalho Chehab wrote: Subject: V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices Author: Klaus Schmidinger klaus.schmidin...@tvdr.de Date:Sun Apr 11 06:12:52 2010 -0300 I wonder why this patch was applied without any modification. It seems like, as Manu pointed out, the flag should really indicate support for Turbo-FEC modes rather than just 8PSK (which is already a subset of FE_CAN_2G_MODULATION). Btw., there is also no FE_CAN_APSK_16, FE_CAN_APSK_32 or FE_CAN_DQPSK. Also, I'm unsure how to instruct a driver whether to choose Turbo-FEC mode or not in case it supports both DVB-S2 and what's used in the US. Third, it was stated that cx24116's support for Turbo-FEC was untested and probably unsupported. So I'd vote for reverting this patch until these issues are cleared. If my assumptions above are correct, my proposal is to rename the flag to FE_CAN_TURBO_FEC (as Manu proposed earlier) and remove it from cx24116.c. 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
RE: [PATCH v4 1/2] v4l: Add memory-to-memory device helper framework for videobuf.
-Original Message-
From: Pawel Osciak [mailto:p.osc...@samsung.com]
Sent: Monday, April 19, 2010 6:00 PM
To: linux-media@vger.kernel.org
Cc: p.osc...@samsung.com; m.szyprow...@samsung.com;
kyungmin.p...@samsung.com; Hiremath, Vaibhav
Subject: [PATCH v4 1/2] v4l: Add memory-to-memory device helper framework
for videobuf.
A mem-to-mem device is a device that uses memory buffers passed by
userspace applications for both their source and destination data. This
is different from existing drivers, which utilize memory buffers for either
input or output, but not both.
In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type.
Examples of such devices would be: image 'resizers', 'rotators',
'colorspace converters', etc.
This patch adds a separate Kconfig sub-menu for mem-to-mem devices as well.
[Hiremath, Vaibhav] Some minor comments (which just came across now) -
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig| 14 +
drivers/media/video/Makefile |2 +
drivers/media/video/v4l2-mem2mem.c | 632
include/media/v4l2-mem2mem.h | 201
4 files changed, 849 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/v4l2-mem2mem.c
create mode 100644 include/media/v4l2-mem2mem.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f8fc865..5fd041e 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -45,6 +45,10 @@ config VIDEO_TUNER
tristate
depends on MEDIA_TUNER
+config V4L2_MEM2MEM_DEV
+ tristate
+ depends on VIDEOBUF_GEN
+
#
# Multimedia Video device configuration
#
@@ -1107,3 +,13 @@ config USB_S2255
endif # V4L_USB_DRIVERS
endif # VIDEO_CAPTURE_DRIVERS
+
+menuconfig V4L_MEM2MEM_DRIVERS
+ bool Memory-to-memory multimedia devices
+ depends on VIDEO_V4L2
+ default n
+ ---help---
+ Say Y here to enable selecting drivers for V4L devices that
+ use system memory for both source and destination buffers, as
opposed
+ to capture and output drivers, which use memory buffers for just
+ one of those.
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index b88b617..e974680 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -117,6 +117,8 @@ obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o
obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o
obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o
+obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+
obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
diff --git a/drivers/media/video/v4l2-mem2mem.c b/drivers/media/video/v4l2-
mem2mem.c
new file mode 100644
index 000..eee9514
--- /dev/null
+++ b/drivers/media/video/v4l2-mem2mem.c
@@ -0,0 +1,632 @@
+/*
+ * Memory-to-memory device framework for Video for Linux 2 and videobuf.
+ *
+ * Helper functions for devices that use videobuf buffers for both their
+ * source and destination.
+ *
+ * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * Pawel Osciak, p.osc...@samsung.com
+ * Marek Szyprowski, m.szyprow...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+#include linux/module.h
+#include linux/sched.h
+#include linux/slab.h
[Hiremath, Vaibhav] Add one line here.
+#include media/videobuf-core.h
+#include media/v4l2-mem2mem.h
+
+MODULE_DESCRIPTION(Mem to mem device framework for videobuf);
+MODULE_AUTHOR(Pawel Osciak, p.osc...@samsung.com);
+MODULE_LICENSE(GPL);
+
+static bool debug;
+module_param(debug, bool, 0644);
+
+#define dprintk(fmt, arg...) \
+ do {\
+ if (debug) \
+ printk(KERN_DEBUG %s: fmt, __func__, ## arg);\
+ } while (0)
+
+
+/* Instance is already queued on the job_queue */
+#define TRANS_QUEUED (1 0)
+/* Instance is currently running in hardware */
+#define TRANS_RUNNING(1 1)
+
+
+/* Offset base for buffers on the destination queue - used to distinguish
+ * between source and destination buffers when mmapping - they receive the
same
+ * offsets but for different queues */
+#define DST_QUEUE_OFF_BASE (1 30)
+
+
+/**
+ * struct v4l2_m2m_dev - per-device context
+ * @curr_ctx:currently running instance
+ * @job_queue: instances queued to run
+ * @job_spinlock:protects
RE: [PATCH v4 2/2] v4l: Add a mem-to-mem videobuf framework test device.
-Original Message-
From: Pawel Osciak [mailto:p.osc...@samsung.com]
Sent: Monday, April 19, 2010 6:00 PM
To: linux-media@vger.kernel.org
Cc: p.osc...@samsung.com; m.szyprow...@samsung.com;
kyungmin.p...@samsung.com; Hiremath, Vaibhav
Subject: [PATCH v4 2/2] v4l: Add a mem-to-mem videobuf framework test
device.
This is a virtual device driver for testing the memory-to-memory framework.
This virtual device uses in-memory buffers for both its source and
destination.
It is capable of multi-instance, multi-buffer-per-transaction operation
(via the mem2mem framework).
[Hiremath, Vaibhav] Some minor comments -
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig | 14 +
drivers/media/video/Makefile |1 +
drivers/media/video/mem2mem_testdev.c | 1050
+
3 files changed, 1065 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/mem2mem_testdev.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 5fd041e..9a306a6 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1121,3 +1121,17 @@ menuconfig V4L_MEM2MEM_DRIVERS
use system memory for both source and destination buffers, as
opposed
to capture and output drivers, which use memory buffers for just
one of those.
+
+if V4L_MEM2MEM_DRIVERS
+
+config VIDEO_MEM2MEM_TESTDEV
+ tristate Virtual test device for mem2mem framework
+ depends on VIDEO_DEV VIDEO_V4L2
+ select VIDEOBUF_VMALLOC
+ select V4L2_MEM2MEM_DEV
+ default n
+ ---help---
+ This is a virtual test device for the memory-to-memory driver
+ framework.
+
+endif # V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index e974680..2fa3c13 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
+obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_OMAP2)+= omap2cam.o
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
new file mode 100644
index 000..d6e6ca9
--- /dev/null
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -0,0 +1,1050 @@
+/*
+ * A virtual v4l2-mem2mem example device.
+ *
+ * This is a virtual device driver for testing mem-to-mem videobuf
framework.
+ * It simulates a device that uses memory buffers for both source and
+ * destination, processes the data and issues an irq (simulated by a
timer).
+ * The device is capable of multi-instance, multi-buffer-per-transaction
+ * operation (via the mem2mem framework).
+ *
+ * Copyright (c) 2009-2010 Samsung Electronics Co., Ltd.
+ * Pawel Osciak, p.osc...@samsung.com
+ * Marek Szyprowski, m.szyprow...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+#include linux/module.h
+#include linux/delay.h
+#include linux/fs.h
+#include linux/version.h
+#include linux/timer.h
+#include linux/sched.h
+
+#include linux/platform_device.h
+#include media/v4l2-mem2mem.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf-vmalloc.h
+
+#define MEM2MEM_TEST_MODULE_NAME mem2mem-testdev
+
+MODULE_DESCRIPTION(Virtual device for mem2mem framework testing);
+MODULE_AUTHOR(Pawel Osciak, p.osc...@samsung.com);
+MODULE_LICENSE(GPL);
+
+
+#define MIN_W 32
+#define MIN_H 32
+#define MAX_W 640
+#define MAX_H 480
+#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */
+
+/* Flags that indicate a format can be used for capture/output */
+#define MEM2MEM_CAPTURE (1 0)
+#define MEM2MEM_OUTPUT (1 1)
+
+#define MEM2MEM_NAME m2m-testdev
+
+/* Per queue */
+#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
+/* In bytes, per queue */
+#define MEM2MEM_VID_MEM_LIMIT(16 * 1024 * 1024)
+
+/* Default transaction time in msec */
+#define MEM2MEM_DEF_TRANSTIME1000
+/* Default number of buffers per transaction */
+#define MEM2MEM_DEF_TRANSLEN 1
+#define MEM2MEM_COLOR_STEP (0xff 4)
+#define MEM2MEM_NUM_TILES8
+
+#define dprintk(dev, fmt, arg...) \
+ v4l2_dbg(1, 1, dev-v4l2_dev, %s: fmt, __func__, ## arg)
+
+
+void m2mtest_dev_release(struct device *dev)
+{}
+
+static struct platform_device m2mtest_pdev = {
+ .name = MEM2MEM_NAME,
+ .dev.release= m2mtest_dev_release,
+};
+
+struct m2mtest_fmt {
+ char
[PATCH] SH: add Video Output Unit and AK8813 video encoder support on ecovec
Ecovec uses the AK8813 video envoder similarly to the ms7724se platform with
the only difference, that on ecovec GPIOs are used for resetting and powering
up and down the chip.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
This patch extends the SuperH VOU / AK881x patch series:
http://thread.gmane.org/gmane.linux.ports.sh.devel/7751/focus=7753
arch/sh/boards/mach-ecovec24/setup.c | 78 ++
1 files changed, 78 insertions(+), 0 deletions(-)
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index 6c13b92..6f5697f 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -771,6 +771,51 @@ static struct platform_device irda_device = {
.resource = irda_resources,
};
+#include media/ak881x.h
+#include media/sh_vou.h
+
+struct ak881x_pdata ak881x_pdata = {
+ .flags = AK881X_IF_MODE_SLAVE,
+};
+
+static struct i2c_board_info ak8813 = {
+ I2C_BOARD_INFO(ak8813, 0x20),
+ .platform_data = ak881x_pdata,
+};
+
+struct sh_vou_pdata sh_vou_pdata = {
+ .bus_fmt= SH_VOU_BUS_8BIT,
+ .flags = SH_VOU_HSYNC_LOW | SH_VOU_VSYNC_LOW,
+ .board_info = ak8813,
+ .i2c_adap = 0,
+ .module_name= ak881x,
+};
+
+static struct resource sh_vou_resources[] = {
+ [0] = {
+ .start = 0xfe96,
+ .end= 0xfe962043,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = 55,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device vou_device = {
+ .name = sh-vou,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(sh_vou_resources),
+ .resource = sh_vou_resources,
+ .dev= {
+ .platform_data = sh_vou_pdata,
+ },
+ .archdata = {
+ .hwblk_id = HWBLK_VOU,
+ },
+};
+
static struct platform_device *ecovec_devices[] __initdata = {
heartbeat_device,
nor_flash_device,
@@ -792,6 +837,7 @@ static struct platform_device *ecovec_devices[] __initdata
= {
camera_devices[2],
fsi_device,
irda_device,
+ vou_device,
};
#ifdef CONFIG_I2C
@@ -1175,6 +1221,38 @@ static int __init arch_setup(void)
i2c_register_board_info(1, i2c1_devices,
ARRAY_SIZE(i2c1_devices));
+ /* VOU */
+ gpio_request(GPIO_FN_DV_D15, NULL);
+ gpio_request(GPIO_FN_DV_D14, NULL);
+ gpio_request(GPIO_FN_DV_D13, NULL);
+ gpio_request(GPIO_FN_DV_D12, NULL);
+ gpio_request(GPIO_FN_DV_D11, NULL);
+ gpio_request(GPIO_FN_DV_D10, NULL);
+ gpio_request(GPIO_FN_DV_D9, NULL);
+ gpio_request(GPIO_FN_DV_D8, NULL);
+ gpio_request(GPIO_FN_DV_CLKI, NULL);
+ gpio_request(GPIO_FN_DV_CLK, NULL);
+ gpio_request(GPIO_FN_DV_VSYNC, NULL);
+ gpio_request(GPIO_FN_DV_HSYNC, NULL);
+
+ /* AK8813 power / reset sequence */
+ gpio_request(GPIO_PTG4, NULL);
+ gpio_request(GPIO_PTU3, NULL);
+ /* Reset */
+ gpio_direction_output(GPIO_PTG4, 0);
+ /* Power down */
+ gpio_direction_output(GPIO_PTU3, 1);
+
+ udelay(10);
+
+ /* Power up, reset */
+ gpio_set_value(GPIO_PTU3, 0);
+
+ udelay(10);
+
+ /* Remove reset */
+ gpio_set_value(GPIO_PTG4, 1);
+
return platform_add_devices(ecovec_devices,
ARRAY_SIZE(ecovec_devices));
}
--
1.6.2.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
Re: [linux-media] Re: [git:v4l-dvb/master] V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
On 04/21/10 09:58, Andreas Oberritter wrote: Hello Mauro, Mauro Carvalho Chehab wrote: Subject: V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices Author: Klaus Schmidinger klaus.schmidin...@tvdr.de Date:Sun Apr 11 06:12:52 2010 -0300 I wonder why this patch was applied without any modification. It seems like, as Manu pointed out, the flag should really indicate support for Turbo-FEC modes rather than just 8PSK (which is already a subset of FE_CAN_2G_MODULATION). Btw., there is also no FE_CAN_APSK_16, FE_CAN_APSK_32 or FE_CAN_DQPSK. Also, I'm unsure how to instruct a driver whether to choose Turbo-FEC mode or not in case it supports both DVB-S2 and what's used in the US. Third, it was stated that cx24116's support for Turbo-FEC was untested and probably unsupported. So I'd vote for reverting this patch until these issues are cleared. If my assumptions above are correct, my proposal is to rename the flag to FE_CAN_TURBO_FEC (as Manu proposed earlier) and remove it from cx24116.c. That's what I was intending to do - time permitting ;-) I was also surprised that the patch got applied, since I was in the middle of discussing this with Manu... Klaus -- 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 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.
Hello.
Thanks for the comments.
On Tue, 2010-04-20 at 21:33 +0200, ext Jonathan Corbet wrote:
On Tue, 20 Apr 2010 18:20:05 +0300
Matti J. Aaltonen matti.j.aalto...@nokia.com wrote:
This is a parent driver for two child drivers: the V4L2 driver and
the ALSA codec driver. The MFD part provides the I2C communication
to the device and the state handling.
So I was taking a quick look at this; it mostly looks OK (though I wonder
about all those symbol exports - does all that stuff need to be in the
Some functions get called from both child drivers/modules, but some
stuff could probably be moved from the core to either of the children.
Should I actually do that?
core?). One thing caught my eye, though:
+int wl1273_fm_rds_off(struct wl1273_core *core)
+{
+ struct device *dev = core-i2c_dev-dev;
+ int r;
+
+ if (core-mode == WL1273_MODE_TX)
+ return 0;
+
+ wait_for_completion_timeout(core-busy, msecs_to_jiffies(1000));
The use of a completion here looks like a mistake to me. This isn't a
normal pattern, and I'm not quite sure what you're trying to do. Here,
also, you're ignoring the return value, so you don't know if completion
was signaled or not.
Yes that wait_for_completion is a mistake.
If you look in functions like:
+int wl1273_fm_set_rx_freq(struct wl1273_core *core, unsigned int freq)
+{
[...]
+ INIT_COMPLETION(core-busy);
+ r = wl1273_fm_write_cmd(core, WL1273_TUNER_MODE_SET,
+ TUNER_MODE_PRESET);
+ if (r) {
+ complete(core-busy);
+ goto err;
+ }
What will prevent multiple threads from doing INIT_COMPLETION()
simultaneously? It looks racy to me. What happens if multiple
threads try to wait simultaneously on the completion?
OK, looking further, you're not using it for mutual exclusion. In fact,
you're not using anything for mutual exclusion; how do you prevent
concurrent access to the hardware registers?
I have mutexes everywhere that function is called from. My aim was to
have the mutexes in the interface functions. So that the radio use is
serialized on as high a level as possible.
What I would suggest you do is remove the completion in favor of a wait
queue which the interrupt handler can use to signal that something has
completed. You can then use wait_event() to wait for a wakeup and test
that the specific condition you are waiting for has come to pass.
Do you agree with my explanation? Or should I switch to using wait
queue?
Cheers,
Matti
jon
--
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 v4 1/2] v4l: Add memory-to-memory device helper framework for videobuf.
Hi,
thanks for the review. My responses below.
Hiremath, Vaibhav hvaib...@ti.com wrote:
-Original Message-
From: Pawel Osciak [mailto:p.osc...@samsung.com]
Sent: Monday, April 19, 2010 6:00 PM
To: linux-media@vger.kernel.org
Cc: p.osc...@samsung.com; m.szyprow...@samsung.com;
kyungmin.p...@samsung.com; Hiremath, Vaibhav
Subject: [PATCH v4 1/2] v4l: Add memory-to-memory device helper framework
for videobuf.
[Hiremath, Vaibhav] Add one line here.
Ok...
[snip]
+/**
+ * v4l2_m2m_querybuf() - multi-queue-aware QUERYBUF multiplexer
+ *
+ * See v4l2_m2m_mmap() documentation for details.
+ */
+int v4l2_m2m_querybuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
+ struct v4l2_buffer *buf)
+{
+ struct videobuf_queue *vq;
+ int ret;
+
+ vq = v4l2_m2m_get_vq(m2m_ctx, buf-type);
+ ret = videobuf_querybuf(vq, buf);
+
+ if (buf-memory == V4L2_MEMORY_MMAP
+ vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ buf-m.offset += DST_QUEUE_OFF_BASE;
+ }
[Hiremath, Vaibhav] Don't you think we should check for ret value also here?
Should it be something -
if (!ret buf-memory == V4L2_MEMORY_MMAP
vq-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
buf-m.offset += DST_QUEUE_OFF_BASE;
}
I think it should stay like this. The offset should never be different
depending on whether an error is being reported or not. The unmodified offset
could confuse userspace applications or even conflict with the other buffer
type (although in case of errors userspace should not be using those offsets
anyway).
[snip]
+/**
+ * v4l2_m2m_dqbuf() - dequeue a source or destination buffer, depending on
+ * the type
+ */
+int v4l2_m2m_dqbuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
+struct v4l2_buffer *buf)
+{
+ struct videobuf_queue *vq;
+
+ vq = v4l2_m2m_get_vq(m2m_ctx, buf-type);
[Hiremath, Vaibhav] Does it make sense to check the return value here?
Well, videobuf does not check it either. I mean, it would be important if
there was a possibility that userspace passes malicious data. But a NULL
here would mean a driver error.
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] v4l: videobuf: qbuf now uses relevant v4l2_buffer fields for OUTPUT types
According to the V4L2 specification, applications set bytesused, field and
timestamp fields of struct v4l2_buffer when the buffer is intended for
output and memory type is MMAP. This adds proper copying of those values
to videobuf_buffer so drivers can use them.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf-core.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 63d7043..e573ca7 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -549,6 +549,13 @@ int videobuf_qbuf(struct videobuf_queue *q, struct
v4l2_buffer *b)
but buffer addr is zero!\n);
goto done;
}
+ if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT
+ || q-type == V4L2_BUF_TYPE_VBI_OUTPUT
+ || q-type == V4L2_BUF_TYPE_SLICED_VBI_OUTPUT) {
+ buf-size = b-bytesused;
+ buf-field = b-field;
+ buf-ts = b-timestamp;
+ }
break;
case V4L2_MEMORY_USERPTR:
if (b-length buf-bsize) {
--
1.7.1.rc1.12.ga601
--
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: av7110 and budget_av are broken!
On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote: Am 22.3.2010 20:34, schrieb e9hack: Am 20.3.2010 22:37, schrieb Hans Verkuil: On Saturday 20 March 2010 17:03:01 e9hack wrote: OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my VDR does start, currently I've no chance to determine which module is load first, but it works. If I unload all modules and load it again, I've no problem. In this case, the modules for the budget card is load first and the modules for the FF loads as second one. Ping!! It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] pxa_camera: move fifo reset direct before dma start
On Tue, 20 Apr 2010 19:36:13 +0200 Robert Jarzmik robert.jarz...@free.fr wrote: Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Robert, what do you think? Are you still working with PXA camera? Hi Guennadi, Yes, I'm still working with pxa_camera :) About the patch, I have a very good feeling about it. I have not tested it, but it looks good to me. I'll assume Stefan has tested it, and if you want it, please take my : Acked-by: Robert Jarzmik robert.jarz...@free.fr FWIW, Tested-by: Antonio Ospite osp...@studenti.unina.it It works on Motorola A780: pxa_camera + mt9m111 The first picture is now ok. Thanks Stefan. Ciao ciao, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 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? A: Top-posting. Q: What is the most annoying thing in e-mail? pgpENhnPlZIeK.pgp Description: PGP signature
[PATCH v3 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
Signed-off-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 15d80f7..b417bd5 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -551,6 +551,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.1.rc1.12.ga601
--
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 v3 2/3] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR
From: Hans Verkuil hverk...@xs4all.nl
For recoverable stream errors dqbuf() now returns 0 and the error flag
is set instead of returning EIO.
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
drivers/media/video/videobuf-core.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 63d7043..1cf084f 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -286,8 +286,10 @@ static void videobuf_status(struct videobuf_queue *q,
struct v4l2_buffer *b,
case VIDEOBUF_ACTIVE:
b-flags |= V4L2_BUF_FLAG_QUEUED;
break;
- case VIDEOBUF_DONE:
case VIDEOBUF_ERROR:
+ b-flags |= V4L2_BUF_FLAG_ERROR;
+ /* fall through */
+ case VIDEOBUF_DONE:
b-flags |= V4L2_BUF_FLAG_DONE;
break;
case VIDEOBUF_NEEDS_INIT:
@@ -668,6 +670,7 @@ int videobuf_dqbuf(struct videobuf_queue *q,
MAGIC_CHECK(q-int_ops-magic, MAGIC_QTYPE_OPS);
+ memset(b, 0, sizeof(*b));
mutex_lock(q-vb_lock);
retval = stream_next_buffer(q, buf, nonblocking);
@@ -679,23 +682,20 @@ int videobuf_dqbuf(struct videobuf_queue *q,
switch (buf-state) {
case VIDEOBUF_ERROR:
dprintk(1, dqbuf: state is error\n);
- retval = -EIO;
- CALL(q, sync, q, buf);
- buf-state = VIDEOBUF_IDLE;
break;
case VIDEOBUF_DONE:
dprintk(1, dqbuf: state is done\n);
- CALL(q, sync, q, buf);
- buf-state = VIDEOBUF_IDLE;
break;
default:
dprintk(1, dqbuf: state invalid\n);
retval = -EINVAL;
goto done;
}
- list_del(buf-stream);
- memset(b, 0, sizeof(*b));
+ CALL(q, sync, q, buf);
videobuf_status(q, b, buf, q-type);
+ list_del(buf-stream);
+ buf-state = VIDEOBUF_IDLE;
+ b-flags = ~V4L2_BUF_FLAG_DONE;
done:
mutex_unlock(q-vb_lock);
return retval;
--
1.7.1.rc1.12.ga601
--
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 v3 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 Signed-off-by: Kyungmin Park kyungmin.p...@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..2669b8b 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.1.rc1.12.ga601 -- 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 v3 0/3] Fix DQBUF behavior for recoverable streaming errors
Hello, this is the third 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 v2: - replaced the second patch of the series with Hans' version This series contains: [PATCH v3 1/3] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors [PATCH v3 2/3] v4l: videobuf: Add support for V4L2_BUF_FLAG_ERROR [PATCH v3 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
saa7146 troubles
I have a saa7146 card but I'm not sure the maker 02:0c.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Device 434a:4343 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at ff7ffc00 (32-bit, non-prefetchable) [size=512] 02:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Device 434a:4343 Flags: bus master, medium devsel, latency 32, IRQ 11 Memory at ff7ff800 (32-bit, non-prefetchable) [size=512] the card isn't working and nothing is showing up as /dev/video It looks like dmesg mentions something about a video capture card but I'm not sure what to make of it ... [ 448.141499] Linux video capture interface: v2.0 What driver do I need to install to get this to work? Do you have another recomendation for a card that just works. I need it to have vga. Bill -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/master] V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices
Andreas Oberritter wrote: Hello Mauro, Mauro Carvalho Chehab wrote: Subject: V4L/DVB: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices Author: Klaus Schmidinger klaus.schmidin...@tvdr.de Date:Sun Apr 11 06:12:52 2010 -0300 I wonder why this patch was applied without any modification. It seems like, as Manu pointed out, the flag should really indicate support for Turbo-FEC modes rather than just 8PSK (which is already a subset of FE_CAN_2G_MODULATION). It is partially due to Patchwork's fault, plus my hurry of trying to handle my long queue after returning for a one week trip. Unfortunately, the patchwork xml support only provides the patch on the mbox format, stripping all the patch history, just like if you click at the mbox link on the patch: https://patchwork.kernel.org/patch/91888/mbox/ So, the patch comments appear as: From patchwork Sun Apr 11 09:12:52 2010 Content-Type: text/plain; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices Date: Sun, 11 Apr 2010 09:12:52 - From: Klaus Schmidinger klaus.schmidin...@tvdr.de X-Patchwork-Id: 91888 Message-Id: 4bc19294.4010...@tvdr.de To: linux-media@vger.kernel.org The enum fe_caps provides flags that allow an application to detect whether a device is capable of handling various modulation types etc. A flag for detecting PSK_8, however, is missing. This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though. Signed-off-by: Klaus Schmidinger klaus.schmidin...@tvdr.de Tested-by: Derek Kelly user@gmail.com Acked-by: Manu Abraham m...@linuxtv.org I generally take a look at the full patch history at the email, but, as the last tag was an ack, and no nacked-by: tags were added on the patch, I assumed that the patch were fine to apply. People should not add a formal acked-by tag if the patch is not ready yet to be committed. I've submitted an email to patchwork ML asking for they to fix this bad behavior. Let's see if this could be corrected on newer versions of the tool. Btw., there is also no FE_CAN_APSK_16, FE_CAN_APSK_32 or FE_CAN_DQPSK. Also, I'm unsure how to instruct a driver whether to choose Turbo-FEC mode or not in case it supports both DVB-S2 and what's used in the US. Third, it was stated that cx24116's support for Turbo-FEC was untested and probably unsupported. Btw, the DocBook describing the FE_CAN features (frontend.xml) is outdated. I suggest to add the remaining features there, to keep the specs updated. So I'd vote for reverting this patch until these issues are cleared. Ok, I'll do it. If my assumptions above are correct, my proposal is to rename the flag to FE_CAN_TURBO_FEC (as Manu proposed earlier) and remove it from cx24116.c. Regards, Andreas -- 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
16 Channel Capture Card Recommendation
I have a Phillips SAA7146 capture card that I can't seem to get working. Does anyone have a recommendation for a 16 channel capture card that works out of the box? Bill -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tm6000: firmware
Am 21.04.2010 06:45, schrieb Mauro Carvalho Chehab: Em Thu, 15 Apr 2010 21:28:39 +0200 Stefan Ringel stefan.rin...@arcor.de escreveu: Am 15.04.2010 19:14, schrieb Mauro Carvalho Chehab: Em 15-04-2010 07:37, Stefan Ringel escreveu: Am 14.04.2010 23:06, schrieb Mauro Carvalho Chehab: Em 14-04-2010 11:41, Stefan Ringel escreveu: Am 14.04.2010 19:44, schrieb Mauro Carvalho Chehab: Hi Stefan, Em 14-04-2010 09:26, Stefan Ringel escreveu: Hi Mauro, Can you added these three firmwares? The third is into archive file, because I'm extracted for an user (Bee Hock Goh). Sorry, but for us to put the firmwares at the server and/or add them at linux-firmware git tree, we need to get the distribution rights from the manufacturer, as described on: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission So, we need Xceive's ack, in order to add the firmware files somewhere. That's why currently we're using the procedure described on the comments at the extraction tool: Documentation/video4linux/extract_xc3028.pl Cheers, Mauro OK. In the archive is the modified extract_xc3028 tool for tm6000-xc3028.fw . Is that useful? Yes, but: 1) Please, send it as a patch, with the proper SOB; 2) From a diff I did here: - my $sourcefile = UDXTTM6000.sys; - my $hash = cb9deb5508a5e150af2880f5b0066d78; - my $outfile = tm6000-xc3028.fw; + my $sourcefile = hcw85bda.sys; + my $hash = 0e44dbf63bb0169d57446aec21881ff2; + my $outfile = xc3028-v27.fw; This version works with another *.sys file. The proper way is to check for the hash, and use the proper logic, based on the provided sys file; 3) Please document where to get the UDXTTTM6000.sys file at the comments; 4) tm6000-xc3028.fw is a really bad name. It made sense only during the development of tuner-xc2028.c, since, on that time, it seemed that tm6000 had a different firmware version. In fact, the first devices appeared with v 1.e firmware. So, a proper name for that version would be xc3028-v1e.fw. We should rename it to be consistent. The firmware name is was you write in tm6000-card.c file and yes it can renamed. This firmware work in tm5600 and tm6000 sticks where the firmware v2.7 or v3.6 not works. The version isn't v1.e , it is v2.4 see log file from Bee Hock Goh ( Ok. then, please send me a patch renaming the firmware used by this card as xc3028-v24.fw. I won't be able to apply any patch until next week (I'm currently abroad for the Collaboration Summit). http://www.mail-archive.com/linux-media@vger.kernel.org/msg17378.html ). It is not clear what version is provided with this version. Is it v3.6? On a few cases, we've seen some modified versions of XC3028 firmwares shipped with some specific board. Is it the case? With respect to your patch, you need to add some logic to decide to generate either v2.4 or v2.7, based on the *.sys checksum code. So, instead of just renaming things, the proper solution is to create two sub-routines: one for v2.7 and another for v2.4, and decide to use either one, based on the checksum of the *.sys file. I have generated new the patch. Much better! Yet: +verify($sourcefile_24, $hash_24); + verify($sourcefile_27, $hash_27); + + open INFILE, $sourcefile_24; + main_firmware_24($outfile_24, $name_24, $version_24, $nr_desc_24); + close INFILE; + + open INFILE, $sourcefile_27; + main_firmware_27($outfile_27, $name_27, $version_27, $nr_desc_27); close INFILE; } Users shouldn't be forced to download both files, as just one file is needed for a given device. So, instead, the tool should test if the file exists, and handle only the found file(s). OK. -- Stefan Ringel stefan.rin...@arcor.de --- usr/src/src/tm6010/v4l-dvb/linux/Documentation/video4linux/extract_xc3028.pl 2010-03-27 13:14:22.215564668 +0100 +++ home/stefan/Downloads/tm6000-xc3028/extract_xc3028.pl 2010-04-21 17:09:22.591574944 +0200 @@ -5,12 +5,18 @@ # # In order to use, you need to: # 1) Download the windows driver with something like: +# Version 2.4 +# wget http://www.twinhan.com/files/AW/BDA T/20080303_V1.0.6.7.zip +# or wget http://www.stefanringel.de/pub/20080303_V1.0.6.7.zip +# Version 2.7 # wget http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip -# 2) Extract the file hcw85bda.sys from the zip into the current dir: +# 2) Extract the files from the zip into the current dir: +# unzip -j
Re: tm6000: firmware
Am 21.04.2010 18:04, schrieb Mauro Carvalho Chehab: Em Wed, 21 Apr 2010 17:15:55 +0200 Stefan Ringel stefan.rin...@arcor.de escreveu: Am 21.04.2010 06:45, schrieb Mauro Carvalho Chehab: Em Thu, 15 Apr 2010 21:28:39 +0200 Stefan Ringel stefan.rin...@arcor.de escreveu: Am 15.04.2010 19:14, schrieb Mauro Carvalho Chehab: Em 15-04-2010 07:37, Stefan Ringel escreveu: Am 14.04.2010 23:06, schrieb Mauro Carvalho Chehab: Em 14-04-2010 11:41, Stefan Ringel escreveu: Am 14.04.2010 19:44, schrieb Mauro Carvalho Chehab: Hi Stefan, Em 14-04-2010 09:26, Stefan Ringel escreveu: Hi Mauro, Can you added these three firmwares? The third is into archive file, because I'm extracted for an user (Bee Hock Goh). Sorry, but for us to put the firmwares at the server and/or add them at linux-firmware git tree, we need to get the distribution rights from the manufacturer, as described on: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission So, we need Xceive's ack, in order to add the firmware files somewhere. That's why currently we're using the procedure described on the comments at the extraction tool: Documentation/video4linux/extract_xc3028.pl Cheers, Mauro OK. In the archive is the modified extract_xc3028 tool for tm6000-xc3028.fw . Is that useful? Yes, but: 1) Please, send it as a patch, with the proper SOB; 2) From a diff I did here: - my $sourcefile = UDXTTM6000.sys; - my $hash = cb9deb5508a5e150af2880f5b0066d78; - my $outfile = tm6000-xc3028.fw; + my $sourcefile = hcw85bda.sys; + my $hash = 0e44dbf63bb0169d57446aec21881ff2; + my $outfile = xc3028-v27.fw; This version works with another *.sys file. The proper way is to check for the hash, and use the proper logic, based on the provided sys file; 3) Please document where to get the UDXTTTM6000.sys file at the comments; 4) tm6000-xc3028.fw is a really bad name. It made sense only during the development of tuner-xc2028.c, since, on that time, it seemed that tm6000 had a different firmware version. In fact, the first devices appeared with v 1.e firmware. So, a proper name for that version would be xc3028-v1e.fw. We should rename it to be consistent. The firmware name is was you write in tm6000-card.c file and yes it can renamed. This firmware work in tm5600 and tm6000 sticks where the firmware v2.7 or v3.6 not works. The version isn't v1.e , it is v2.4 see log file from Bee Hock Goh ( Ok. then, please send me a patch renaming the firmware used by this card as xc3028-v24.fw. I won't be able to apply any patch until next week (I'm currently abroad for the Collaboration Summit). http://www.mail-archive.com/linux-media@vger.kernel.org/msg17378.html ). It is not clear what version is provided with this version. Is it v3.6? On a few cases, we've seen some modified versions of XC3028 firmwares shipped with some specific board. Is it the case? With respect to your patch, you need to add some logic to decide to generate either v2.4 or v2.7, based on the *.sys checksum code. So, instead of just renaming things, the proper solution is to create two sub-routines: one for v2.7 and another for v2.4, and decide to use either one, based on the checksum of the *.sys file. I have generated new the patch. Much better! Yet: +verify($sourcefile_24, $hash_24); + verify($sourcefile_27, $hash_27); + + open INFILE, $sourcefile_24; + main_firmware_24($outfile_24, $name_24, $version_24, $nr_desc_24); + close INFILE; + + open INFILE, $sourcefile_27; + main_firmware_27($outfile_27, $name_27, $version_27, $nr_desc_27); close INFILE; } Users shouldn't be forced to download both files, as just one file is needed for a given device. So, instead, the tool should test if the file exists, and handle only the found file(s). OK. OK. Could you please send your Signed-off-by? Cheers, Mauro. Ah, right. Signed-off-by: Stefan Ringel stefan.rin...@arcor.de -- Stefan Ringel stefan.rin...@arcor.de --- usr/src/src/tm6010/v4l-dvb/linux/Documentation/video4linux/extract_xc3028.pl 2010-03-27 13:14:22.215564668 +0100 +++ home/stefan/Downloads/tm6000-xc3028/extract_xc3028.pl 2010-04-21
[PATCH v1 1/2] v4l: videobuf: Add support for out-of-order buffer dequeuing.
Drivers can now finish processing on and return video buffers in
an arbitrary order. Before this patch, this was possible in a FIFO order
only. This is useful e.g. for video codecs, which often need to hold some
buffers (e.g. keyframes) for longer periods of time than others.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/videobuf-core.c | 160 +++---
include/media/videobuf-core.h |9 ++
2 files changed, 117 insertions(+), 52 deletions(-)
diff --git a/drivers/media/video/videobuf-core.c
b/drivers/media/video/videobuf-core.c
index 77899ca..ea5fd39 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -95,6 +95,27 @@ int videobuf_waiton(struct videobuf_buffer *vb, int
non_blocking, int intr)
}
EXPORT_SYMBOL_GPL(videobuf_waiton);
+int videobuf_has_consumers(struct videobuf_queue *q)
+{
+ return waitqueue_active(q-vb_done_wait);
+}
+EXPORT_SYMBOL_GPL(videobuf_has_consumers);
+
+void videobuf_buf_finish(struct videobuf_queue *q, struct videobuf_buffer *vb)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(q-vb_done_lock, flags);
+ list_add_tail(vb-done_list, q-vb_done_list);
+ spin_unlock_irqrestore(q-vb_done_lock, flags);
+
+ spin_lock_irqsave(q-irqlock, flags);
+ wake_up(vb-done);
+ wake_up_interruptible(q-vb_done_wait);
+ spin_unlock_irqrestore(q-irqlock, flags);
+}
+EXPORT_SYMBOL_GPL(videobuf_buf_finish);
+
int videobuf_iolock(struct videobuf_queue *q, struct videobuf_buffer *vb,
struct v4l2_framebuffer *fbuf)
{
@@ -153,7 +174,10 @@ void videobuf_queue_core_init(struct videobuf_queue *q,
mutex_init(q-vb_lock);
init_waitqueue_head(q-wait);
+ init_waitqueue_head(q-vb_done_wait);
INIT_LIST_HEAD(q-stream);
+ INIT_LIST_HEAD(q-vb_done_list);
+ spin_lock_init(q-vb_done_lock);
}
EXPORT_SYMBOL_GPL(videobuf_queue_core_init);
@@ -217,6 +241,7 @@ void videobuf_queue_cancel(struct videobuf_queue *q)
wake_up_all(q-bufs[i]-done);
}
}
+ wake_up_all(q-vb_done_wait);
spin_unlock_irqrestore(q-irqlock, flags);
/* free all buffers + clear queue */
@@ -603,67 +628,81 @@ done:
EXPORT_SYMBOL_GPL(videobuf_qbuf);
/* Locking: Caller holds q-vb_lock */
-static int stream_next_buffer_check_queue(struct videobuf_queue *q, int
noblock)
+static int wait_for_buffer(struct videobuf_queue *q, int nonblocking)
{
- int retval;
+ int retval = 0;
checks:
if (!q-streaming) {
- dprintk(1, next_buffer: Not streaming\n);
+ dprintk(1, Not streaming\n);
retval = -EINVAL;
- goto done;
+ goto end;
}
- if (list_empty(q-stream)) {
- if (noblock) {
+ /*
+* Buffers may be added to vb_done_list without holding the vb_lock,
+* but removal is performed only while holding both vb_lock and the
+* vb_done_lock spinlock. Thus we can be sure that as long as we hold
+* vb_lock, the list will remain not empty if this check succeeds.
+*/
+ if (list_empty(q-vb_done_list)) {
+ if (nonblocking) {
+ dprintk(1, Nonblocking and no buffers to dequeue\n);
retval = -EAGAIN;
- dprintk(2, next_buffer: no buffers to dequeue\n);
- goto done;
- } else {
- dprintk(2, next_buffer: waiting on buffer\n);
-
- /* Drop lock to avoid deadlock with qbuf */
- mutex_unlock(q-vb_lock);
-
- /* Checking list_empty and streaming is safe without
-* locks because we goto checks to validate while
-* holding locks before proceeding */
- retval = wait_event_interruptible(q-wait,
- !list_empty(q-stream) || !q-streaming);
- mutex_lock(q-vb_lock);
-
- if (retval)
- goto done;
-
- goto checks;
+ goto end;
}
- }
- retval = 0;
+ /*
+* We are streaming and nonblocking, wait for another buffer to
+* become ready or for streamoff. vb_lock is released to allow
+* streamoff and qbuf in parallel.
+*/
+ mutex_unlock(q-vb_lock);
+ /*
+* Although the mutex is released here, we will be reevaluating
+* both conditions again after reacquiring it.
+*/
+ retval = wait_event_interruptible(q-vb_done_wait,
+ !list_empty(q-vb_done_list) ||
[PATCH/RFC v1 0/2] Add support for out-of-order buffer dequeuing
Hello,
this patch adds support for dequeuing video buffers out-of-order, i.e. not
in a FIFO order.
It is closely related to my previous RFC, to which no responses were given
(much to my disappointment, as an insight into what others think of the done
waitqueues in videobuf_buffer could potentially shed a new light on the issue):
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/17904
==
Current behavior
==
Currently, videobuf stores all the buffers passed from the userspace
on its stream list. They are inserted to it in the same order as
they are queued by the userspace.
When dequeuing/polling, the next (i.e. first queued) buffer from that list
is always used. In result, it is not possible to dequeue other buffers from
the stream queue first. If an another buffer is marked as finished by the
driver, it is not returned before all the buffers that have been queued
earlier, even if it takes more time for them to finish.
The videobuf_buffer structure includes a done waitqueue, on which we are
expected to sleep while waiting for each particular buffer to finish being
processed. The usefulness of having a separate waitqueue for every buffer
has been questioned in my previous RFC. As there was no response, I am
beginning to assume that there is no one who would like to speak in favor
of keeping them, although I am not removing them in this patch.
Dequeuing
videobuf_dqbuf() takes the next (i.e. first) buffer from the stream list and
checks the state member of videobuf_buffer to determine whether it has
already been marked as done (VIDEOBUF_DONE) or an error has occurred
(indicated by VIDEOBUF_ERROR state). If neither is true, we go to sleep on
that buffer's waitqueue.
Drivers mark buffers as done by:
1. setting their state to one of those constants and
2. waking up all processes sleeping on the done waitqueue.
Polling
videobuf_poll_stream() also takes the first buffer (if available) from
the stream list and behaves in a similar fashion to dqbuf.
Both dqbuf and poll do not check or return buffers other than the first
one. Even if a driver marks other buffers as finished first, they will not be
used (polled/dequeued) before their predecessors.
V4L2 API
From the point of view of V4L2 API, no particular order of buffers is
specified. Applications are expected to check the index in struct v4l2_buffer
in order to determine which buffer has been dequeued.
==
This patch
==
Rationale
Although FIFO is enough for most hardware, it is essential for some types of
devices, particularly video codecs, to allow dequeuing buffers in an arbitrary
order. Video codecs may need to hold some buffers (reference frames) for longer
periods of time than others.
Moreover, even if not required, introducing such an ability may improve
performance of applications that utilize devices which have different
processing times for different buffers.
A different matter is that, in my opinion, exposing the nuts and bolts of
waking up processes sleeping on done waitqueues to drivers is slightly
inelegant and a bit too verbose. The drivers should be marking the buffers
as done with a more abstract call and not be exposed to the inner workings of
videobuf.
Finally, current situation ties up drivers to videobuf behavior a bit too
much in my opinion, as indicated in the videobuf_has_consumers() example below.
Changes
This patch adds the ability to return any buffer that has already been marked
as finished. Buffers are dequeued in FIFO order, but not based on the order
in which they were queued, but in the order in which the driver has marked
them as done instead.
This results in two main advantages:
1. Buffers are returned to userspace as soon as drivers finish with them
(although curretnly drivers usually do return them in the same order as
queued).
2. Out-of-order dequeuing becomes possible for drivers that require such an
ability.
Two exported functions are introduced in this patch:
1. videobuf_has_consumers()
Returns 1 when userspace is waiting for buffers.
To achieve this in the previous version, a driver had to take the first
buffer that has been queued and check whether its done waitqueue is active.
An example from vivi:
627spin_lock_irqsave(dev-slock, flags);
628if (list_empty(dma_q-active)) {
629dprintk(dev, 1, No active queue to serve\n);
630goto unlock;
631}
632
633buf = list_entry(dma_q-active.next,
634 struct vivi_buffer, vb.queue);
635
636/* Nobody is waiting on this buffer, return */
637if (!waitqueue_active(buf-vb.done))
638goto unlock;
(...)
650unlock:
651spin_unlock_irqrestore(dev-slock, flags);
This worked,
[PATCH v1 2/2] v4l: vivi: adapt to out-of-order buffer dequeuing in videobuf.
Make vivi use new videobuf helpers for finishing processing a buffer and
checking for consumers.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/vivi.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index cdbe703..4a91761 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -630,13 +630,13 @@ static void vivi_thread_tick(struct vivi_fh *fh)
goto unlock;
}
- buf = list_entry(dma_q-active.next,
-struct vivi_buffer, vb.queue);
-
- /* Nobody is waiting on this buffer, return */
- if (!waitqueue_active(buf-vb.done))
+ if (!videobuf_has_consumers(fh-vb_vidq)) {
+ dprintk(dev, 1, No consumers\n);
goto unlock;
+ }
+ buf = list_entry(dma_q-active.next,
+struct vivi_buffer, vb.queue);
list_del(buf-vb.queue);
do_gettimeofday(buf-vb.ts);
@@ -645,11 +645,12 @@ static void vivi_thread_tick(struct vivi_fh *fh)
vivi_fillbuff(fh, buf);
dprintk(dev, 1, filled buffer %p\n, buf);
- wake_up(buf-vb.done);
- dprintk(dev, 2, [%p/%d] wakeup\n, buf, buf-vb. i);
-unlock:
spin_unlock_irqrestore(dev-slock, flags);
+ videobuf_buf_finish(fh-vb_vidq, buf-vb);
return;
+
+unlock:
+ spin_unlock_irqrestore(dev-slock, flags);
}
#define frames_to_ms(frames) \
--
1.7.1.rc1.12.ga601
--
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
Issue loading SAA7134 module
I've got a couple of boxes that have two no-name 8-chip SAA713X cards. Both have the same issue: the kernel will only set up the first eight on one board and only two on the second. It leaves the other six unusable with error -23. I am unable to figure out what that means. Sample dmesg as follows. More (/proc/ioports, /proc/interrupts, etc) can be posted if requested. Tried kernels 2.6.18 and 2.6.33.2 on CentOS 5.4 and Fedora 11 fully updated. The module is loaded as card=0. The following is output for chips 11 through 16. saa7130[10]: subsystem: 1131:, board: UNKNOWN/GENERIC [card=0,autodetected] saa7130[10]: board init: gpio is 1 saa7130[10]: Huh, no eeprom present (err=-5)? saa7130[10]: can't register video device saa7134: probe of :05:0f.0 failed with error -23 Thanks in advance, Donald Bailey -- 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 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.
On Wed, 21 Apr 2010 12:29:00 +0300 m7aalton matti.j.aalto...@nokia.com wrote: So I was taking a quick look at this; it mostly looks OK (though I wonder about all those symbol exports - does all that stuff need to be in the Some functions get called from both child drivers/modules, but some stuff could probably be moved from the core to either of the children. Should I actually do that? Depends. If it's truly only useful to a single child device, the code probably belongs there, without an export. If it's truly a core function, in that (1) it's applicable to multiple devices, or (2) it can't be implemented without exposing stuff you want to keep private to the core, then it should stay in the core. What I would suggest you do is remove the completion in favor of a wait queue which the interrupt handler can use to signal that something has completed. You can then use wait_event() to wait for a wakeup and test that the specific condition you are waiting for has come to pass. Do you agree with my explanation? Or should I switch to using wait queue? My belief is that the code would be cleaner with a wait queue; that's the normal pattern for implementing this kind of logic. I'll stop here, though; if others want to take it upstream with the completion, I'll not scream about it. Thanks, jon -- 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 Apr 21 19:00:18 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14592:b438301e588f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1f96716187774be265c59a713fb570810e3a15c7 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/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: cx5000 default auto sleep mode
On 4/14/2010 9:39 PM, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 11:44 PM, Andy Wallsawa...@md.metrocast.net wrote: On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Not really. DViCo Fusion dual digital tv card. One side of the card would yield black video screen when starting a digital capture sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm not sure there was a causal relationship. I hypothesized that one side of the dual-tuner was going stupid or one of the two channels used in the cx23885 was getting confused. I was looking at how to narrow the problem down to cx23885 chip or xc5000 tuner, or s5h14xx demod when I noted the power managment module option for the xc5000. I suggested Tim try it. It was dumb luck that my guess actually made his symptoms go away. That's all I know. We did have a similar issue with the PCTV 800i. Basically, the GPIO definition was improperly defined for the xc5000 reset callback. As a result, it was strobing the reset on both the xc5000 *and* the s5h1411, which would then cause the s5h1411's hardware state to not match the driver state. After multiple round trips with the hardware engineer at PCTV, I finally concluded that there actually wasn't a way to strobe the reset without screwing up the demodulator, which prompted me to disable the xc5000 reset callback (see cx88-cards:2944). My guess is that the reset GPIO definition for that board is wrong (a problem exposed by this change), or that it's resetting the s5h1411 as well. Devin Are any of the logs usefull? -- 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: Need Info
Hi, Any suggestions? Thanks On Mon, Apr 19, 2010 at 7:18 PM, linux newbie linux.newbi...@gmail.com wrote: Hi, It is observed that Lifecam transfer type is Isochronous and ISP1362 driver does not support this. Is there any driver patch that supports Isochronous transfer?? Please help me in this regard. Thanks linux newbie wrote: Hi, On my embedded PXA255 platform, we have working USB module. ISP1362 is the controller. Recently we want to integrate Microsoft Lifecam Cinema webcam and want to take still images. Linux kernel is 2.6.26.3 and we enabled V4L2 and UVC class drivers. On plugging the Cam and querying the proc and sys file system, I can able to view cam details. I want to capture the frame (preferably in jpeg) and write to a file. Is there any example code for that? I went through the below web page http://v4l2spec.bytesex.org/spec/capture-example.html, but if you can suggest some more example, it will be of great help to me. Thanks -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-requ...@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ir-core: add imon driver
On Tue, Apr 20, 2010 at 06:22:36PM -0300, Mauro Carvalho Chehab wrote: Em Fri, 16 Apr 2010 17:29:02 -0400 Jarod Wilson ja...@redhat.com escreveu: This is a new driver for the SoundGraph iMON and Antec Veris IR/display devices commonly found in many home theater pc cases and as after-market case additions. +/* IR protocol: native iMON, Windows MCE (RC-6), or iMON w/o PAD stabilize */ +static int ir_protocol; +module_param(ir_protocol, int, S_IRUGO | S_IWUSR); +MODULE_PARM_DESC(ir_protocol, Which IR protocol to use. 0=auto-detect, +1=Windows Media Center Ed. (RC-6), 2=iMON native, +4=iMON w/o PAD stabilize (default: auto-detect)); + You don't need this. Let's the protocol to be adjustable via sysfs. All you need to do is to use the set_protocol callbacks with something like: props-allowed_protos = IR_TYPE_RC6 | IR_TYPE_imon protocol; props-change_protocol = imon_ir_change_protocol; You can see an example of such implementation at drivers/media/video/em28xx-em28xx-input.c. Look for em28xx_ir_change_protocol() function. Working on it now... I'm about 95% of the way there, just need to sort out one last little bit... That's said, I'm not sure what would be better way to map IR_TYPE_imon protocol. Maybe we can just use IR_TYPE_OTHER. So, basically, we'll have: IR_TYPE_OTHER | IR_TYPE_RC6 - auto-detected between RC-6 and iMON IR_TYPE_OTHER - iMON proprietary protocol IR_TYPE_RC6 - RC-6 protocol By doing this, the userspace application ir-keycode will already be able to handle the IR protocol. I'm going to go with IR_TYPE_OTHER for the iMON native proto for now. To be honest, I don't have a clue what the actual IR protocol looks like... I should try one of my iMON remotes w/an mce transceiver to see if I can figure it out... I'm not sure how to map the PAD stablilize case, but it seems that the better would be to add a sysfs node for it, at sys/class/rc/rc0. There are other cases where some protocols may require some adjustments, so I'm thinking on having some protocol-specific properties there. For the moment, I'm dropping the ir_protocol modparam and adding a pad_stabilize one. It was a hack to have it as a protocol, all it really needs to do is bypass a function when processing the pad signals. Can convert it to something more standard once we have a standard for protocol-specific properties. (The pad_thresh modparam is probably a similar case). Except for that, the patch looked sane to my eyes. So, I'll add it on my tree and wait for a latter patch from you addressing the protocol control. Good deal, I'm working off the v4l-dvb git tree now, hope to have something a bit later tonight or tomorrow. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue loading SAA7134 module
Am Mittwoch, den 21.04.2010, 13:22 -0300 schrieb Donald Bailey: I've got a couple of boxes that have two no-name 8-chip SAA713X cards. Both have the same issue: the kernel will only set up the first eight on one board and only two on the second. It leaves the other six unusable with error -23. I am unable to figure out what that means. Sample dmesg as follows. More (/proc/ioports, /proc/interrupts, etc) can be posted if requested. Tried kernels 2.6.18 and 2.6.33.2 on CentOS 5.4 and Fedora 11 fully updated. The module is loaded as card=0. The following is output for chips 11 through 16. saa7130[10]: subsystem: 1131:, board: UNKNOWN/GENERIC [card=0,autodetected] saa7130[10]: board init: gpio is 1 saa7130[10]: Huh, no eeprom present (err=-5)? saa7130[10]: can't register video device saa7134: probe of :05:0f.0 failed with error -23 Due to some unknown bug we have ;), it likely works only perfectly with unidentified devices with more than 128 saa713x chips in a single PCI slot. Read on the wiki, about how to add a new device, and feel free to improve it. China is going totally mad. (or is it from somewhere else?) Cheers, Hermann -- 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
tm6000: Patch that will fixed analog video (tested on tm5600)
Dear all,
Anyone who have a tm6000 compatible analog device, please do try out this patch.
Its working for me on a tm5600 using mplayer. It can be compile
against the latest hg tree.
diff -r a539e5b68945 linux/drivers/staging/tm6000/tm6000-video.c
--- a/linux/drivers/staging/tm6000/tm6000-video.c Sat Mar 27 23:09:47
2010 -0300
+++ b/linux/drivers/staging/tm6000/tm6000-video.c Thu Apr 22 13:08:19
2010 +0800
@@ -157,7 +157,7 @@
/* Cleans up buffer - Usefull for testing for frame/URB loss */
outp = videobuf_to_vmalloc((*buf)-vb);
- memset(outp, 0, (*buf)-vb.size);
+// memset(outp, 0, (*buf)-vb.size);
#endif
return;
@@ -291,7 +291,8 @@
start_line=line;
last_field=field;
}
- last_line=line;
+ if (cmd == TM6000_URB_MSG_VIDEO)
+ last_line=line;
pktsize = TM6000_URB_MSG_LEN;
} else {
@@ -502,7 +503,7 @@
unsigned long copied;
get_next_buf(dma_q, buf);
- if (!buf)
+ if (buf)
outp = videobuf_to_vmalloc(buf-vb);
if (!outp)
--
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
