Re: av7110 and budget_av are broken!

2010-04-21 Thread e9hack
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!

2010-04-21 Thread Hans Verkuil

 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

2010-04-21 Thread Andreas Oberritter
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.

2010-04-21 Thread Hiremath, Vaibhav


 -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.

2010-04-21 Thread Hiremath, Vaibhav

 -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

2010-04-21 Thread Guennadi Liakhovetski
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

2010-04-21 Thread Klaus Schmidinger
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.

2010-04-21 Thread m7aalton
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.

2010-04-21 Thread Pawel Osciak
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

2010-04-21 Thread Pawel Osciak
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!

2010-04-21 Thread Oliver Endriss
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

2010-04-21 Thread Antonio Ospite
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


Re: [PATCH] pxa_camera: move fifo reset direct before dma start

2010-04-21 Thread Jonathan Cameron
On 04/21/10 11:06, Antonio Ospite wrote:
 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
 
Excellent, I'm not in a position to test right now, but glad
to see this issue cleaned up.

Jonathan
--
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 1/3] v4l: Add a new ERROR flag for DQBUF after recoverable streaming errors

2010-04-21 Thread Pawel Osciak
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

2010-04-21 Thread Pawel Osciak
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

2010-04-21 Thread Pawel Osciak
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

2010-04-21 Thread Pawel Osciak
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

2010-04-21 Thread Bill Purcell
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

2010-04-21 Thread Mauro Carvalho Chehab
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

2010-04-21 Thread Bill Purcell
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

2010-04-21 Thread Stefan Ringel
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

2010-04-21 Thread Stefan Ringel
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.

2010-04-21 Thread Pawel Osciak
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

2010-04-21 Thread Pawel Osciak
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.

2010-04-21 Thread Pawel Osciak
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

2010-04-21 Thread 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

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.

2010-04-21 Thread Jonathan Corbet
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

2010-04-21 Thread Hans Verkuil
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

2010-04-21 Thread Timothy D. Lenz



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

2010-04-21 Thread linux newbie
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

2010-04-21 Thread Jarod Wilson
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

2010-04-21 Thread hermann pitton

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)

2010-04-21 Thread Bee Hock Goh
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