[PATCHv5] mx2_camera: Add soc_camera support for i.MX25/i.MX27

2010-07-01 Thread Baruch Siach
This is the soc_camera support developed by Sascha Hauer for the i.MX27.  Alan
Carvalho de Assis modified the original driver to get it working on more recent
kernels. I modified it further to add support for i.MX25. This driver has been
tested on i.MX25 and i.MX27 based platforms.

Signed-off-by: Baruch Siach bar...@tkos.co.il
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Changes v4 - v5
Comments from Uwe Kleine-König:

Enclose mx27 DMA related stuff in #ifdefs since the dma-mx1-mx2.h is no 
longer accessible to mx25 builds

s/MX2_VIDEO/VIDEO_MX2_HOSTSUPPORT/

Changes v3 - v4
Address more comments from Guennadi Liakhovetski, including:

* Fix the double trigger handling of mx27 eMMA

* Add a FIXME comment in the code of eMMA overflow handling

Changes v2 - v3
Address more comments from Guennadi Liakhovetski.

Applied part of Sashca's patch that I forgot in v2.

Changes v1 - v2
Addressed the comments of Guennadi Liakhovetski except from the following:

1. The mclk_get_divisor implementation, since I don't know what this code 
   is good for

2. mx2_videobuf_release should not set pcdev-active on i.MX27, because 
   mx27_camera_frame_done needs this pointer

3. In mx27_camera_emma_buf_init I don't know the meaning of those hard 
   coded magic numbers

Applied i.MX27 fixes from Sascha.

 arch/arm/plat-mxc/include/mach/memory.h  |4 +-
 arch/arm/plat-mxc/include/mach/mx2_cam.h |   46 +
 drivers/media/video/Kconfig  |   13 +
 drivers/media/video/Makefile |1 +
 drivers/media/video/mx2_camera.c | 1513 ++
 5 files changed, 1575 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
 create mode 100644 drivers/media/video/mx2_camera.c

diff --git a/arch/arm/plat-mxc/include/mach/memory.h 
b/arch/arm/plat-mxc/include/mach/memory.h
index c4b40c3..849d891 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -44,12 +44,12 @@
  */
 #define CONSISTENT_DMA_SIZE SZ_8M
 
-#elif defined(CONFIG_MX1_VIDEO)
+#elif defined(CONFIG_MX1_VIDEO) || defined(CONFIG_VIDEO_MX2_HOSTSUPPORT)
 /*
  * Increase size of DMA-consistent memory region.
  * This is required for i.MX camera driver to capture at least four VGA frames.
  */
 #define CONSISTENT_DMA_SIZE SZ_4M
-#endif /* CONFIG_MX1_VIDEO */
+#endif /* CONFIG_MX1_VIDEO || CONFIG_MX2_VIDEO */
 
 #endif /* __ASM_ARCH_MXC_MEMORY_H__ */
diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h 
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
new file mode 100644
index 000..3c080a3
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -0,0 +1,46 @@
+/*
+ * mx2-cam.h - i.MX27/i.MX25 camera driver header file
+ *
+ * Copyright (C) 2003, Intel Corporation
+ * Copyright (C) 2008, Sascha Hauer s.ha...@pengutronix.de
+ * Copyright (C) 2010, Baruch Siach bar...@tkos.co.il
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#ifndef __MACH_MX2_CAM_H_
+#define __MACH_MX2_CAM_H_
+
+#define MX2_CAMERA_SWAP16  (1  0)
+#define MX2_CAMERA_EXT_VSYNC   (1  1)
+#define MX2_CAMERA_CCIR(1  2)
+#define MX2_CAMERA_CCIR_INTERLACE  (1  3)
+#define MX2_CAMERA_HSYNC_HIGH  (1  4)
+#define MX2_CAMERA_GATED_CLOCK (1  5)
+#define MX2_CAMERA_INV_DATA(1  6)
+#define MX2_CAMERA_PCLK_SAMPLE_RISING  (1  7)
+#define MX2_CAMERA_PACK_DIR_MSB(1  8)
+
+/**
+ * struct mx2_camera_platform_data - optional platform data for mx2_camera
+ * @flags: any combination of MX2_CAMERA_*
+ * @clk: clock rate of the csi block / 2
+ */
+struct mx2_camera_platform_data {
+   unsigned long flags;
+   unsigned long clk;
+};
+
+#endif /* __MACH_MX2_CAM_H_ */
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..27e2acc 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -969,6 +969,19 @@ config VIDEO_OMAP2
---help---
  This is a v4l2 driver for the TI OMAP2 camera capture interface
 
+config VIDEO_MX2_HOSTSUPPORT
+bool
+
+config VIDEO_MX2
+   tristate i.MX27/i.MX25 Camera Sensor Interface driver
+   depends on VIDEO_DEV  SOC_CAMERA  (MACH_MX27 || 

Re: [linux-dvb] TeVii S470 in mythtv - diseqc problems

2010-07-01 Thread OM Ugarcina
Hello Hans,

Much thanks for your advice . I have done that options setting  and it
helped with my other issues . I have just worked out this problem . It
was connected with the changing of the DVBS card that I used for years
with a new DVBS2 and Mythtv . I thought that it was the drivers issue
- but it is not . My apologies to the DVB developers ( sorry Igor for
doubting ) . The issue is that Mythtv when dealing with DVBS2 card
will need to access an additional parameter from the dtv_multiplex
table which is mod_sys . In my mod_sys column  there was only 1 ,
instead of a proper setting such as DVB-S . After updating the table
, mythtv was able to execute a tune properly .


Best Regards

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


What utility to use to scan dvbs2 transponders

2010-07-01 Thread OM Ugarcina
Hello Guys

What is the tool of choice to use to scan dvbs2 satellites ? I tried
dvbscan but it only picked up dvbs transponders , the dvbs2 ones it
failed to tune . I saw that there used to be this utility scan-s2 ,
but looks like it was abandoned a couple of years ago and has not been
maintained since . So how do you guys do a transponder scan for dvbs2
?

Best Regards
Milorad
--
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: Status of the patches under review (85 patches) and some misc notes about the devel procedures

2010-07-01 Thread Bjørn Mork
Mauro Carvalho Chehab mche...@redhat.com writes:


 My original idea were to send one of such emails per week, 

Nearly two months has passed since this message.  I apologize if I
missed something, but I have not seen another status update. Is it just
me?

Anyway, since the last status I've seen, 2.6.34 has been released, the
2.6.35 merge window has been open and then closed, and a number of new
patches have been collected in 
https://patchwork.kernel.org/project/linux-media/list/
, many of which seem rather trivial.

Any chance of a new status update anytime soon?  I'm particularily
interested in getting a forced status change on any patch which was
under review at the time of the last status message.  I believe it's
reasonable to expect two months review to be more than enough.  If
the patches are found unacceptable, then it's much better to have them
rejected with a please fix foo and resubmit than the current total
silence called review.


Thanks,
Bjørn

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCHv5] mx2_camera: Add soc_camera support for i.MX25/i.MX27

2010-07-01 Thread Uwe Kleine-König
On Thu, Jul 01, 2010 at 02:03:19PM +0300, Baruch Siach wrote:
 This is the soc_camera support developed by Sascha Hauer for the i.MX27.  Alan
 Carvalho de Assis modified the original driver to get it working on more 
 recent
 kernels. I modified it further to add support for i.MX25. This driver has been
 tested on i.MX25 and i.MX27 based platforms.
 
 Signed-off-by: Baruch Siach bar...@tkos.co.il
 Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
 Changes v4 - v5
 Comments from Uwe Kleine-König:
 
 Enclose mx27 DMA related stuff in #ifdefs since the dma-mx1-mx2.h is no 
 longer accessible to mx25 builds
 
 s/MX2_VIDEO/VIDEO_MX2_HOSTSUPPORT/
 
 Changes v3 - v4
 Address more comments from Guennadi Liakhovetski, including:
 
 * Fix the double trigger handling of mx27 eMMA
 
 * Add a FIXME comment in the code of eMMA overflow handling
 
 Changes v2 - v3
 Address more comments from Guennadi Liakhovetski.
 
 Applied part of Sashca's patch that I forgot in v2.
 
 Changes v1 - v2
 Addressed the comments of Guennadi Liakhovetski except from the following:
 
 1. The mclk_get_divisor implementation, since I don't know what this code 
is good for
 
 2. mx2_videobuf_release should not set pcdev-active on i.MX27, because 
mx27_camera_frame_done needs this pointer
 
 3. In mx27_camera_emma_buf_init I don't know the meaning of those hard 
coded magic numbers
 
 Applied i.MX27 fixes from Sascha.
 
  arch/arm/plat-mxc/include/mach/memory.h  |4 +-
  arch/arm/plat-mxc/include/mach/mx2_cam.h |   46 +
  drivers/media/video/Kconfig  |   13 +
  drivers/media/video/Makefile |1 +
  drivers/media/video/mx2_camera.c | 1513 
 ++
  5 files changed, 1575 insertions(+), 2 deletions(-)
  create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
  create mode 100644 drivers/media/video/mx2_camera.c
 
 diff --git a/arch/arm/plat-mxc/include/mach/memory.h 
 b/arch/arm/plat-mxc/include/mach/memory.h
 index c4b40c3..849d891 100644
 --- a/arch/arm/plat-mxc/include/mach/memory.h
 +++ b/arch/arm/plat-mxc/include/mach/memory.h
 @@ -44,12 +44,12 @@
   */
  #define CONSISTENT_DMA_SIZE SZ_8M
  
 -#elif defined(CONFIG_MX1_VIDEO)
 +#elif defined(CONFIG_MX1_VIDEO) || defined(CONFIG_VIDEO_MX2_HOSTSUPPORT)
  /*
   * Increase size of DMA-consistent memory region.
   * This is required for i.MX camera driver to capture at least four VGA 
 frames.
   */
  #define CONSISTENT_DMA_SIZE SZ_4M
 -#endif /* CONFIG_MX1_VIDEO */
 +#endif /* CONFIG_MX1_VIDEO || CONFIG_MX2_VIDEO */
s/CONFIG_MX2_VIDEO/CONFIG_VIDEO_MX2_HOSTSUPPORT/ please

  #endif /* __ASM_ARCH_MXC_MEMORY_H__ */
 diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h 
 b/arch/arm/plat-mxc/include/mach/mx2_cam.h
 new file mode 100644
 index 000..3c080a3
 --- /dev/null
 +++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
Do you expect users of this header other than your driver?  If not you
can fold it into the latter.

[...snip...]

 diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
 index bdbc9d3..27e2acc 100644
 --- a/drivers/media/video/Kconfig
 +++ b/drivers/media/video/Kconfig
 @@ -969,6 +969,19 @@ config VIDEO_OMAP2
   ---help---
 This is a v4l2 driver for the TI OMAP2 camera capture interface
  
 +config VIDEO_MX2_HOSTSUPPORT
 +bool
 +
 +config VIDEO_MX2
 + tristate i.MX27/i.MX25 Camera Sensor Interface driver
 + depends on VIDEO_DEV  SOC_CAMERA  (MACH_MX27 || ARCH_MX25)
 + select VIDEOBUF_DMA_CONTIG
CONTIG?

[...snap...]

 diff --git a/drivers/media/video/mx2_camera.c 
 b/drivers/media/video/mx2_camera.c
 new file mode 100644
 index 000..98c93fa
 --- /dev/null
 +++ b/drivers/media/video/mx2_camera.c
 @@ -0,0 +1,1513 @@

[...snip...]

 +static int __devexit mx2_camera_remove(struct platform_device *pdev)
 +{
 + struct soc_camera_host *soc_host = to_soc_camera_host(pdev-dev);
 + struct mx2_camera_dev *pcdev = container_of(soc_host,
 + struct mx2_camera_dev, soc_host);
 + struct resource *res;
 +
 + clk_put(pcdev-clk_csi);
 +#ifdef CONFIG_MACH_MX27
 + if (cpu_is_mx27())
 + imx_dma_free(pcdev-dma);
 +#endif /* CONFIG_MACH_MX27 */
 + free_irq(pcdev-irq_csi, pcdev);
 + if (mx27_camera_emma(pcdev))
 + free_irq(pcdev-irq_emma, pcdev);
 +
 + soc_camera_host_unregister(pcdev-soc_host);
 +
 + iounmap(pcdev-base_csi);
 +
 + if (mx27_camera_emma(pcdev)) {
 + clk_disable(pcdev-clk_emma);
 + clk_put(pcdev-clk_emma);
 + iounmap(pcdev-base_emma);
 + res = pcdev-res_emma;
 + release_mem_region(res-start, resource_size(res));
 + }
 +
 + res = pcdev-res_csi;
 + release_mem_region(res-start, resource_size(res));
 +
 + kfree(pcdev);
 +
 + dev_info(pdev-dev, MX2 Camera driver unloaded\n);
 +
 + return 0;
 +}
 +
 +static struct platform_driver 

RFCl libv4l2 plugin API

2010-07-01 Thread Hans de Goede

Hi All,

RFC: a plugin API for libv4l2
=

During the Plumbers conference in 2009 various parties expresse interest
in adding a plugin API to libv4l2. Some hardware can do some
processing steps in hardware, but this needs to be setup from userspace
and sometimes still need some regulation from userspace as streaming
happens, hardware specific libv4l2 plugins could be a solution here.

During the v4l summit in Helsinki this was discussed further and a
simple and very generic plugin API was pitched. This is a first draft
specification for this API.


Basic libv4l2 principles


The basic unit libv4l2's API deals with is a /dev/video node represented
by a fd. A libv4l2 plugin will sit in between libv4l2 itself and the
actual /dev/video device node a fd refers to. It will be called each time
libv4l2 wants to do an operation (read/write/ioctl/mmap/munmap) on the
actual /dev/video node in question. When called the plugin can then choose
to do one of the following:
1. Pass the call unmodified to the fd, and return the return value unmodifed
   (iow do nothing)
2. Modify some arguments in the call and pass it through
3. Modify the return(ed) value(s) of a passed through call
4. Not do any operation on the fd at all but instead completely fake it
   (which opens the possibility for fake v4l devices)

Note that:
1. A plugin may decide between 1. - 4. on a per call basis depending on the
operations arguments and / or state. This esp. is important with the ioctl
operation where a plugin may want to intercept some ioctls but not all
2. If a plugin always wants to pass all calls through for a certain
operation, it is allowed to simply not define a callback function for that
operation
3. As libv4l2 does some faking itself esp. when it comes to format
conversion a single libv4l2 call may result in multiple calls to the plugin,
or to none at all.

So to summarize the above: Anything goes :)


libv4l2 plugin loading
--

A libv4l2 plugin is a .so file which lives under /usr/lib[64]/libv4l/plugins.
This .so file defines a single symbol: libv4l2_plugin. This symbol is a
(constant) libv4l_plugin_data struct, which contains pointers to all the
callbacks the plugin wants to install.

libv4l2 plugin loading begins with the application using libv4l2 doing a
v4l2_open() for example v4l2_open(foobar, O_RDWR); When this happens
libv4l2 will dlopen all files found under /usr/lib[64]/libv4l/plugins 1 at a
time and call open callback passing through the applications parameters
unmodified. If a plugin is relevant for the specified device node, it can
indicate so by returning a value other then -1 from the open callback
(usually the result of an actual open call on the device node). If it
is not relevant for this specific video node it should return -1.

As soon as a plugin returns another value then -1 plugin loading stops
and that plugins callbacks are called for all operations on the /dev/video#
node in question. This means that plugins cannot be stacked!

Note that a plugin is bound to a specific fd, this way if there is for
example a system with a SOC connected camera and an external usb camera, the
SOC specific plugin will only be involved when an application is talking to
the SOC connected camera and not when the app talks to the USB webcam.

Note that a plugin is bound to a specific fd not to a device node! IOW it is
possible for a plugin to return not -1 from its open callback when called
on /dev/video0 with O_RDWR, and to return -1 when called on /dev/video0 with
O_RDONLY. Then its callbacks will only get called when operations are done
on the video node though the RW fd, and not when operations are done on the
same node through the RD_ONLY fd. This is not a good idea! It is only meant
to emphasize the binding of a plugin to the fd, rather then to a specific
device node.


libv4l2 plugins and private data


libv4l2 plugins should *never* use any global variables. All data should be
bound to the specific fd to which the plugin is bound. This ensures that for
example a plugin for a specific type of usb webcam will also work when 2
identical cameras are plugged into a system (and both are used from the same
process).

A libv4l2 plugin can register plugin private data using:
void libv4l2_set_plugindata(int fd, void *plugin_data);

And can get this data out of libv4l2 again inside a callback using:
void *libv4l2_get_plugindata(int fd);

Note that a plugin should call libv4l2_set_plugindata only once per fd !
Calling it a second time will overwrite the previous value. The logical
place to use libv4l2_set_plugindata is from the plugin's open callback.


libv4l2-plugin.h


/* Plugin callback function struct */
struct libv4l2_plugin_data {
int (*open)(const char *file, int oflag, ...);
int (*close)(int fd);
int (*ioctl)(int fd, unsigned long int request, ...);
ssize_t (*read)(int fd, void 

Re: [PATCHv5] mx2_camera: Add soc_camera support for i.MX25/i.MX27

2010-07-01 Thread Baruch Siach
Hi Uwe,

On Thu, Jul 01, 2010 at 02:28:03PM +0200, Uwe Kleine-König wrote:
 On Thu, Jul 01, 2010 at 02:03:19PM +0300, Baruch Siach wrote:
  This is the soc_camera support developed by Sascha Hauer for the i.MX27.  
  Alan
  Carvalho de Assis modified the original driver to get it working on more 
  recent
  kernels. I modified it further to add support for i.MX25. This driver has 
  been
  tested on i.MX25 and i.MX27 based platforms.
  
  Signed-off-by: Baruch Siach bar...@tkos.co.il
  Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
  Changes v4 - v5
  Comments from Uwe Kleine-König:
  
  Enclose mx27 DMA related stuff in #ifdefs since the dma-mx1-mx2.h is no 
  longer accessible to mx25 builds
  
  s/MX2_VIDEO/VIDEO_MX2_HOSTSUPPORT/
  
  Changes v3 - v4
  Address more comments from Guennadi Liakhovetski, including:
  
  * Fix the double trigger handling of mx27 eMMA
  
  * Add a FIXME comment in the code of eMMA overflow handling
  
  Changes v2 - v3
  Address more comments from Guennadi Liakhovetski.
  
  Applied part of Sashca's patch that I forgot in v2.
  
  Changes v1 - v2
  Addressed the comments of Guennadi Liakhovetski except from the 
  following:
  
  1. The mclk_get_divisor implementation, since I don't know what this 
  code 
 is good for
  
  2. mx2_videobuf_release should not set pcdev-active on i.MX27, because 
 mx27_camera_frame_done needs this pointer
  
  3. In mx27_camera_emma_buf_init I don't know the meaning of those hard 
 coded magic numbers
  
  Applied i.MX27 fixes from Sascha.
  
   arch/arm/plat-mxc/include/mach/memory.h  |4 +-
   arch/arm/plat-mxc/include/mach/mx2_cam.h |   46 +
   drivers/media/video/Kconfig  |   13 +
   drivers/media/video/Makefile |1 +
   drivers/media/video/mx2_camera.c | 1513 
  ++
   5 files changed, 1575 insertions(+), 2 deletions(-)
   create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
   create mode 100644 drivers/media/video/mx2_camera.c
  
  diff --git a/arch/arm/plat-mxc/include/mach/memory.h 
  b/arch/arm/plat-mxc/include/mach/memory.h
  index c4b40c3..849d891 100644
  --- a/arch/arm/plat-mxc/include/mach/memory.h
  +++ b/arch/arm/plat-mxc/include/mach/memory.h
  @@ -44,12 +44,12 @@
*/
   #define CONSISTENT_DMA_SIZE SZ_8M
   
  -#elif defined(CONFIG_MX1_VIDEO)
  +#elif defined(CONFIG_MX1_VIDEO) || defined(CONFIG_VIDEO_MX2_HOSTSUPPORT)
   /*
* Increase size of DMA-consistent memory region.
* This is required for i.MX camera driver to capture at least four VGA 
  frames.
*/
   #define CONSISTENT_DMA_SIZE SZ_4M
  -#endif /* CONFIG_MX1_VIDEO */
  +#endif /* CONFIG_MX1_VIDEO || CONFIG_MX2_VIDEO */
 s/CONFIG_MX2_VIDEO/CONFIG_VIDEO_MX2_HOSTSUPPORT/ please

Oops. Will fix.

   #endif /* __ASM_ARCH_MXC_MEMORY_H__ */
  diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h 
  b/arch/arm/plat-mxc/include/mach/mx2_cam.h
  new file mode 100644
  index 000..3c080a3
  --- /dev/null
  +++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
 Do you expect users of this header other than your driver?  If not you
 can fold it into the latter.

This header contains mx2_camera_platform_data. Platform code needs this.

 [...snip...]
 
  diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
  index bdbc9d3..27e2acc 100644
  --- a/drivers/media/video/Kconfig
  +++ b/drivers/media/video/Kconfig
  @@ -969,6 +969,19 @@ config VIDEO_OMAP2
  ---help---
This is a v4l2 driver for the TI OMAP2 camera capture interface
   
  +config VIDEO_MX2_HOSTSUPPORT
  +bool
  +
  +config VIDEO_MX2
  +   tristate i.MX27/i.MX25 Camera Sensor Interface driver
  +   depends on VIDEO_DEV  SOC_CAMERA  (MACH_MX27 || ARCH_MX25)
  +   select VIDEOBUF_DMA_CONTIG
 CONTIG?

This selects the physically contiguous DMA implementation of the videobuf API.  
See drivers/media/video/videobuf-dma-contig.c.

 [...snap...]
 
  diff --git a/drivers/media/video/mx2_camera.c 
  b/drivers/media/video/mx2_camera.c
  new file mode 100644
  index 000..98c93fa
  --- /dev/null
  +++ b/drivers/media/video/mx2_camera.c
  @@ -0,0 +1,1513 @@
 
 [...snip...]
 
  +static int __devexit mx2_camera_remove(struct platform_device *pdev)
  +{
  +   struct soc_camera_host *soc_host = to_soc_camera_host(pdev-dev);
  +   struct mx2_camera_dev *pcdev = container_of(soc_host,
  +   struct mx2_camera_dev, soc_host);
  +   struct resource *res;
  +
  +   clk_put(pcdev-clk_csi);
  +#ifdef CONFIG_MACH_MX27
  +   if (cpu_is_mx27())
  +   imx_dma_free(pcdev-dma);
  +#endif /* CONFIG_MACH_MX27 */
  +   free_irq(pcdev-irq_csi, pcdev);
  +   if (mx27_camera_emma(pcdev))
  +   free_irq(pcdev-irq_emma, pcdev);
  +
  +   soc_camera_host_unregister(pcdev-soc_host);
  +
  +   iounmap(pcdev-base_csi);
  +
  +   if (mx27_camera_emma(pcdev)) {
  +   clk_disable(pcdev-clk_emma);
  +   

Re: [PATCHv5] mx2_camera: Add soc_camera support for i.MX25/i.MX27

2010-07-01 Thread Guennadi Liakhovetski
Hi Uwe

On Thu, 1 Jul 2010, Uwe Kleine-König wrote:

  diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
  index bdbc9d3..27e2acc 100644
  --- a/drivers/media/video/Kconfig
  +++ b/drivers/media/video/Kconfig
  @@ -969,6 +969,19 @@ config VIDEO_OMAP2
  ---help---
This is a v4l2 driver for the TI OMAP2 camera capture interface
   
  +config VIDEO_MX2_HOSTSUPPORT
  +bool
  +
  +config VIDEO_MX2
  +   tristate i.MX27/i.MX25 Camera Sensor Interface driver
  +   depends on VIDEO_DEV  SOC_CAMERA  (MACH_MX27 || ARCH_MX25)
  +   select VIDEOBUF_DMA_CONTIG
 CONTIG?

What exactly was your question here?

  diff --git a/drivers/media/video/mx2_camera.c 
  b/drivers/media/video/mx2_camera.c
  new file mode 100644
  index 000..98c93fa
  --- /dev/null
  +++ b/drivers/media/video/mx2_camera.c
  @@ -0,0 +1,1513 @@
 
 [...snip...]

  +static struct platform_driver mx2_camera_driver = {
  +   .driver = {
  +   .name   = MX2_CAM_DRV_NAME,
 I'm always unsure if you need
 
   .owner  = THIS_MODULE,
 
 here.

It is not needed in this case. See the owner field in struct 
soc_camera_host_ops mx2_soc_camera_host_ops.

But that's not the reason why I'm replying. What I didn't like in these 
your reviews, was the fact, that this driver has been submitted a number 
of times to the arm-kernel ML, it has mx2 in its subject, so, you had 
enough chances to review it, just like Sascha did. Instead, you review it 
now, making the author create new versions of his patch. You have been 
asked for advise, because this patch potentially collided with other your 
patches, your help in resolving this question is appreciated. But then you 
suddenly decide to review the whole patch... Several of my patches have 
been treated similarly in the past, so, I know how annoying it is to have 
to re-iterate them because at v5 someone suddenly decided to take part in 
the patch review process too...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PULL] http://kernellabs.com/hg/~mkrufky/k2c2

2010-07-01 Thread Michael Krufky
Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for:

- cx23885: add support for new model revisions of the HVR12xx board family

 Documentation/video4linux/CARDLIST.cx23885  |6 -
 drivers/media/video/cx23885/cx23885-cards.c |   40 ++
 2 files changed, 43 insertions(+), 3 deletions(-)

Cheers,

Mike
--
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: [PATCHv5] mx2_camera: Add soc_camera support for i.MX25/i.MX27

2010-07-01 Thread Uwe Kleine-König
Hi Guennadi,

On Thu, Jul 01, 2010 at 04:23:23PM +0200, Guennadi Liakhovetski wrote:
   +config VIDEO_MX2
   + tristate i.MX27/i.MX25 Camera Sensor Interface driver
   + depends on VIDEO_DEV  SOC_CAMERA  (MACH_MX27 || ARCH_MX25)
   + select VIDEOBUF_DMA_CONTIG
  CONTIG?
 
 What exactly was your question here?
I thought it to be a mistyped CONFIG, I was wrong.
 
   diff --git a/drivers/media/video/mx2_camera.c 
   b/drivers/media/video/mx2_camera.c
   new file mode 100644
   index 000..98c93fa
   --- /dev/null
   +++ b/drivers/media/video/mx2_camera.c
   @@ -0,0 +1,1513 @@
  
  [...snip...]
 
   +static struct platform_driver mx2_camera_driver = {
   + .driver = {
   + .name   = MX2_CAM_DRV_NAME,
  I'm always unsure if you need
  
  .owner  = THIS_MODULE,
  
  here.
 
 It is not needed in this case. See the owner field in struct 
 soc_camera_host_ops mx2_soc_camera_host_ops.
 
 But that's not the reason why I'm replying. What I didn't like in these 
 your reviews, was the fact, that this driver has been submitted a number 
 of times to the arm-kernel ML, it has mx2 in its subject, so, you had 
 enough chances to review it, just like Sascha did. Instead, you review it 
 now, making the author create new versions of his patch. You have been 
 asked for advise, because this patch potentially collided with other your 
 patches, your help in resolving this question is appreciated. But then you 
 suddenly decide to review the whole patch... Several of my patches have 
 been treated similarly in the past, so, I know how annoying it is to have 
 to re-iterate them because at v5 someone suddenly decided to take part in 
 the patch review process too...
OK it might annoying but still I cannot understand why this is a reason to
lament.  I don't necessarily feel part of the intended audience for each
patch on LAKML that contains mx2 in it's subject, still less if the
patch changes very little in arch/arm/{plat-mxc,arch-mx*} as Baruch's
patch does.  Now he cc:d me and I had a look and even took the time to
point out the things that I noticed.  From my POV a late reviewer is
better than getting code in that is less optimal.  And let me point out
that reviewing sequentially is more efficient in the sum---at least for
the reviewers.

So should I ignore patches that are say already  v3?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Beneficial Business Proposal Contact Email=(johnga...@mail2consultant.com)

2010-07-01 Thread Spencer J. Condie
Good Day,
I am Mr. John Galvan a staff of a private offshore bank (AIG Private Bank) 
United Kingdom office. I am pleased to get across to you for a very urgent and 
profitable business proposal of (£15,500,000.00 Pounds Sterlings) which I 
believe will profit the both of us after  completion. Get back to me via my 
private email if you are interested.
Contact me Via (johnga...@mail2consultant.com)
 I will send to you the full details on how the business will be executed and 
also note that you will receive 40% of the above mentioned amount if you agree 
to help me execute this business.
 
Best Regards,
spencen J.Condie (I AM SECRETARY TO MR JOHN GALVAN)


 NOTICE: This email message is for the sole use of the intended recipient(s) 
and may contain confidential and privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, please contact the sender by reply email and destroy all 
copies of the original message.


--
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/DVB: v4l2-dev: fix memory leak

2010-07-01 Thread Anatolij Gustschin
Since commit b4028437876866aba4747a655ede00f892089e14
the 'driver_data' field resides in device's struct device_private
which may be allocated by dev_set_drvdata() if device_private
struct was not allocated previously.

dev_set_drvdata() is used in video_set_drvdata() to set
the driver's private data pointer in v4l2 drivers. Setting
the private data _before_ registering the v4l2 device results
in a memory leak since __video_register_device() also calls
video_set_drvdata(), but after zeroing the device structure.
Thus, the reference to the previously allocated device_private
struct goes lost and a new device_private will be allocated.

All v4l drivers which call video_set_drvdata() _before_
calling video_register_device() are affected. The patch fixes
__video_register_device() to preserve previously allocated
device_private reference.

Caught by kmemleak.

Signed-off-by: Anatolij Gustschin ag...@denx.de
---
 drivers/media/video/v4l2-dev.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 0ca7ec9..9e89bf6 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -410,7 +410,7 @@ static int __video_register_device(struct video_device 
*vdev, int type, int nr,
int minor_offset = 0;
int minor_cnt = VIDEO_NUM_DEVICES;
const char *name_base;
-   void *priv = video_get_drvdata(vdev);
+   void *priv = vdev-dev.p;
 
/* A minor value of -1 marks this video device as never
   having been registered */
@@ -536,9 +536,9 @@ static int __video_register_device(struct video_device 
*vdev, int type, int nr,
 
/* Part 4: register the device with sysfs */
memset(vdev-dev, 0, sizeof(vdev-dev));
-   /* The memset above cleared the device's drvdata, so
+   /* The memset above cleared the device's device_private, so
   put back the copy we made earlier. */
-   video_set_drvdata(vdev, priv);
+   vdev-dev.p = priv;
vdev-dev.class = video_class;
vdev-dev.devt = MKDEV(VIDEO_MAJOR, vdev-minor);
if (vdev-parent)
-- 
1.7.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2010-07-01 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:Thu Jul  1 19:00:18 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14993:9652f85e688a
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400
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-armv5: WARNINGS
linux-2.6.35-rc1-armv5: ERRORS
linux-2.6.32.6-armv5-davinci: OK
linux-2.6.33-armv5-davinci: OK
linux-2.6.34-armv5-davinci: WARNINGS
linux-2.6.35-rc1-armv5-davinci: ERRORS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-armv5-ixp: WARNINGS
linux-2.6.35-rc1-armv5-ixp: ERRORS
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-armv5-omap2: OK
linux-2.6.34-armv5-omap2: WARNINGS
linux-2.6.35-rc1-armv5-omap2: ERRORS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.17-i686: ERRORS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-i686: OK
linux-2.6.34-i686: WARNINGS
linux-2.6.35-rc1-i686: ERRORS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-m32r: WARNINGS
linux-2.6.35-rc1-m32r: ERRORS
linux-2.6.32.6-mips: OK
linux-2.6.33-mips: OK
linux-2.6.34-mips: WARNINGS
linux-2.6.35-rc1-mips: ERRORS
linux-2.6.32.6-powerpc64: OK
linux-2.6.33-powerpc64: OK
linux-2.6.34-powerpc64: WARNINGS
linux-2.6.35-rc1-powerpc64: ERRORS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.17-x86_64: ERRORS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-x86_64: OK
linux-2.6.34-x86_64: WARNINGS
linux-2.6.35-rc1-x86_64: ERRORS
linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
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: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.7-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.7-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


FusionHDTV7 Dual express vs WinTV-HVR-2250?

2010-07-01 Thread Timothy D. Lenz
I am looking to get another card to replace a fusionhdtv7 that died. 
After spending more then a year trying to get a problem pined down, it 
turns out the card was deffective. I tried contacting the company, There 
seems to be no mention of warranty period on the box, in the manual or 
on the web site. It may be there, But I didn't find it. The company 
hasn't responded. Hauppauge cards have proven to be good and well 
supported by linux and now I see the 2250 has driver support and may 
even get support for the analog side. People in the AVS forum seem to 
think the tuner used in the fusion are among the best, better then the 
LG 6th gen. What I'd like to know is how these two cards stand up to 
each other, both for their tuners and overall. It will be used in a 
computer along side a HVR-1800, and a nexus-s, though I would like to 
replace the nexus with a dual s/s2 at some point or add one since new 
cards are PCIe and the nexus is PCI. I have a limited number of free 
PCIe slots, so I am only looking at multi tuner cards.

--
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: em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver

2010-07-01 Thread Douglas Schilling Landgraf
Hi,

On Wed, Jun 30, 2010 at 4:16 PM, Torsten Krah
tk...@fachschaft.imn.htwk-leipzig.de wrote:
 Am Dienstag, 29. Juni 2010 schrieben Sie:
 Could you please verify if you have  the module i2c-dev loaded?

 Yes it is.


 Example:

 #lsmod | grep i2c_dev
 i2c_dev                 6976  0
 i2c_core               21104  11
 i2c_dev,lgdt330x,tuner_xc2028,tuner,tvp5150,saa7115,em28xx,v4l2_common,vide
 odev,tveeprom,i2c_i801

 #lsmod | grep i2c
 i2c_dev                 4970  0
 i2c_algo_bit            5028  1 radeon



 If yes, please give us the output of:

 #i2cdetect -l
 i2c-0   smbus           SMBus I801 adapter at ece0              SMBus
 adapter i2c-1   smbus           em28xx
 #0                               SMBus adapter ^ here my device/driver

 Thats the output:

 # i2cdetect -l
 i2c-0   i2c                                                     I2C adapter



 Basically, in your case the tool is not able to recognize your device
 by i2cdetect.This may happen because i2c_dev module was not able to
 load?

 Its loaded.

 If the module is not loaded, please load it manually and give a new try.

 Did that but still no success.


 I did right now a test with i2c-tools 3.0.0 and 3.0.2.
 http://dl.lm-sensors.org/i2c-tools/releases/

 I am using version 3.0.2.


 Let us know the results.


 Did what you told but still no success using the tool - any other hints or
 things i can do?

humm, not really :-/ Are you sure em28xx/device get loaded when your
device is plugged?

A good test:

- unplug your device
- dmesg -c  (clear the dmesg)
- plug your device
- check your dmesg, see if there is any error or message and please
send to us the output.
- lsmod could help also.
- if it's ok, load the i2c modules

What's the message of rewirte_eeprom.pl? The same as Throsten?

@Thorsten, in my case never needed to load modprobed i2c-smbus also.
That's why rewrite_eeprom failed to you, the script is not looking
to load this module. Thanks for the feedback.

Cheers
Douglas
--
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] Terratec Cinergy 250 PCI support

2010-07-01 Thread hermann pitton
Hi Jean-Michel,

Am Mittwoch, den 30.06.2010, 00:02 +0200 schrieb Jean-Michel Grimaldi:
 Hi Hermann,
 
 Thanks for your answer. Do you mean I should add an entry with .name =
 name_comp1, .vmux = 3, .amux = LINE1 ?
 
 Should I remove the svideo entry, given that the card (which can be
 seen at [1]) only has a (proprietary) composite jack? However there
 seems to exist another card with the same name Terratec Cinergy 250
 PCI but different connectors : [2]
 
 What do you think? Should I just add a composite entry and leave the
 svideo as it is?
 
 Jean-Michel
 
 [1] http://www.arminformatique.fr/images/TerraTec%20Cinergy%20250%
 20PCI.jpg
 [2] http://www.notebookland.hu/shop
 +TERRATEC-CINERGY-250-PCI-TERRATEC-TV-tuner_29849_49


there is also a low profile PCI card.

http://www.terratec.net/de/produkte/bilder/img/2195346_5f78fcd0d7.png
http://www.terratec.net/de/produkte/bilder/produkt_bilder_de_4387.html

Without any such device in my possession and without sufficient testing
and reports, hard to tell.

Do you have the known subsystem 153b:1160 ?

For that one from http://www.bttv-gallery.de

chips: saa7131e, KS008, 8275ac1
pcb: TV-7131 Ver:B
:00:0b.0 Multimedia controller: Philips Semiconductors SAA7133 Audio+video 
broadcast decoder (rev d0)
Subsystem: TERRATEC Electronic GmbH: Unknown device 1160
saa7130/34: v4l2 driver version 0.2.14 loaded
ACPI: PCI interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ 19
saa7133[0]: found at :00:0b.0, rev: 208, irq: 19, latency: 32, mmio: 
0xdfffb800
saa7133[0]: subsystem: 153b:1160, board: UNKNOWN/GENERIC [card=0,autodetected]
saa7133[0]: board init: gpio is 40
saa7133[0]: i2c eeprom 00: 3b 15 60 11 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[0]: i2c eeprom 10: 00 00 20 00 ff 20 ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 01 00 9c ff ff ff ff
saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 40: ff 22 00 c2 96 00 01 30 ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

from INF:
; History:
; 16-Sep-04 FMB 1st version
; 24-Sep-04 FMB changed name from Cinergy 250 TV to Cinergy 250 PCI
...
; 13-Apr-05 FMB v.1.3.2.2 - added option for forced hardware configuration
; 09-May-05 FMB v.1.3.2.0 - added KW driver (modified for IR)
; 24-May-05 FMB v.1.3.2.0 - added registry entry for GPIO config
[TerraTec] 
; Cinergy 250 PCI (SAA7134)
%Cinergy.DeviceDesc%=3xHybrid,PCI\VEN_1131DEV_7134SUBSYS_1160153B
; Cinergy 250 PCI (SAA7135)
%Cinergy.DeviceDesc%=3xHybrid,PCI\VEN_1131DEV_7133SUBSYS_1160153B
...
; Customization
; Setting FM radio of the Silicon tuner via SIF (GPIO 21 in use/ 5.5MHz)
HKR, Audio, FM Radio IF,0x00010001,0x729555
[ForceHWConfig.AddReg]
HKR, I2C Devices, Force Registry Settings,0x00010001,1

HKR, AudioDecoder, Tuner Channel   ,0x00010001,1
HKR, AudioDecoder, CVBS Channel,0x00010001,3
HKR, AudioDecoder, SVHS Channel,0x00010001,3
HKR, AudioDecoder, FM Radio Channel,0x00010001,1

; maps user setting to hardware video input
HKR, VideoDecoder, Tuner Channel   ,0x00010001,1
HKR, VideoDecoder, CVBS Channel,0x00010001,3
HKR, VideoDecoder, SVHS Channel,0x00010001,8
HKR, VideoDecoder, FM Radio Channel,0x00010001,1

; Set GPIOs to output, required for TV/Radio switching
HKR, GPIO, Config, 0x00010001, 0x

; I2C Device settings
HKR, I2C Devices, Number of I2C Devices,0x00010001,1

; FMB NOTE: old prototype with TDA8275
;HKR, I2C Devices, Device 0, Data1,0x00010001,0x14,0x00,0x00,0x00   
   ; Tuner ID
; FMB NOTE: new prototype with TDA8275A
HKR, I2C Devices, Device 0, Data1,0x00010001,0x22,0x00,0x00,0x00
   ; Tuner ID
HKR, I2C Devices, Device 0, Data3,0x00010001,0x96,0x00,0x00,0x00
   ; Tuner IF PLL slave addr.
Cinergy.DeviceDesc  = Cinergy 250 PCI Capture ; Device Manager strings

For that one, Composite vmux = 3, S-Video vmux=8, for both amux = LINE2
and it has analog FM radio support.

For my experience, if we can't auto detect any difference between those,
to treat such cards as the same until some difference shows up, is still
a way to go. Hm, seems some are without radio support.

If our auto detection fails, more hidden methods as PCI subsystem IDs or
eeprom contents might be in use to identfy OEM stuff these days like
undocumented checksums, then we can at least identify different devices
physically and can disable our failing auto detection and point to card
numbers.

A S-Video connector has only four pins, but we find regularly so called
break out connectors there, which can cover all sort of in- and outputs.

Cards can look extremely different, not only concerning connectors, but
might be still functional in the same for the inputs. There are a lot of
examples.

On some cards the yellow input connector is used 

[PATCH v2 0/2] IR: add initial IR transmit support

2010-07-01 Thread Jarod Wilson
To enable IR transmit support in the mceusb driver, I need to add just
three callbacks to achieve feature-parity with IR transmit using the old
lirc_mceusb driver. This series adds those callbacks to ir-core's
ir_dev_props struct, then wires them up for the mceusb driver.

At the moment, we have no native interface for transmitting IR, but a
later patchset to add legacy lirc device interface support provides a
means to transmit IR using this ir-core implementation.

[PATCH 1/2] IR: add tx callbacks to ir-core
[PATCH 2/2] IR/mceusb: add and wire up tx callback functions

Patches are against the linuxtv staging/rc tree, but will probably apply
elsewhere as well.

v2: the mceusb driver no longer makes a copy_from_user() call to pull in
its tx data buffer, it will be provided by whatever is providing the tx
data, be that an in-kernel IR encoder or a forthcoming lirc bridge driver
plugin, which gets *its* data from userspace using copy_from_user().

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


[PATCH v2 1/2] IR: add tx callbacks to ir-core

2010-07-01 Thread Jarod Wilson
v2: incoming IR buffer now an int pointer, and not fed from userspace.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 include/media/ir-core.h |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/include/media/ir-core.h b/include/media/ir-core.h
index ad1303f..513e60d 100644
--- a/include/media/ir-core.h
+++ b/include/media/ir-core.h
@@ -47,15 +47,21 @@ enum rc_driver_type {
  * is opened.
  * @close: callback to allow drivers to disable polling/irq when IR input 
device
  * is opened.
+ * @s_tx_mask: set transmitter mask (for devices with multiple tx outputs)
+ * @s_tx_carrier: set transmit carrier frequency
+ * @tx_ir: transmit IR
  */
 struct ir_dev_props {
enum rc_driver_type driver_type;
unsigned long   allowed_protos;
u32 scanmask;
-   void*priv;
+   void*priv;
int (*change_protocol)(void *priv, u64 ir_type);
int (*open)(void *priv);
void(*close)(void *priv);
+   int (*s_tx_mask)(void *priv, u32 mask);
+   int (*s_tx_carrier)(void *priv, u32 carrier);
+   int (*tx_ir)(void *priv, int *txbuf, u32 n);
 };
 
 struct ir_input_dev {
-- 
1.7.0.1


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


[PATCH v2 2/2] IR/mceusb: add and wire up tx callback functions

2010-07-01 Thread Jarod Wilson
v2: userspace buffer copy moved out of driver and into lirc bridge
driver

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/IR/mceusb.c |  148 ++---
 1 files changed, 138 insertions(+), 10 deletions(-)

diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index f3c736c..c6c0375 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -15,10 +15,6 @@
  * Jon Smirl, which included enhancements and simplifications to the
  * incoming IR buffer parsing routines.
  *
- * TODO:
- * - add rc-core transmit support, once available
- * - enable support for forthcoming ir-lirc-codec interface
- *
  *
  * 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
@@ -51,7 +47,6 @@
 #define DRIVER_NAMEmceusb
 
 #define USB_BUFLEN 32  /* USB reception buffer length */
-#define IRBUF_SIZE 256 /* IR work buffer length */
 #define USB_CTRL_MSG_SZ2   /* Size of usb ctrl msg on gen1 hw */
 #define MCE_G1_INIT_MSGS 40/* Init messages on gen1 hw to throw out */
 
@@ -263,14 +258,13 @@ struct mceusb_dev {
u32 reserved:28;
} flags;
 
-   /* handle sending (init strings) */
+   /* transmit support */
int send_flags;
-   int carrier;
+   u32 carrier;
+   unsigned char tx_mask;
 
char name[128];
char phys[64];
-
-   unsigned char tx_mask;
 };
 
 /*
@@ -520,6 +514,91 @@ static void mce_sync_in(struct mceusb_dev *ir, unsigned 
char *data, int size)
mce_request_packet(ir, ir-usb_ep_in, data, size, MCEUSB_RX);
 }
 
+/* Send data out the IR blaster port(s) */
+static int mceusb_tx_ir(void *priv, int *txbuf, u32 n)
+{
+   struct mceusb_dev *ir = priv;
+   int i, ret = 0;
+   int count, cmdcount = 0;
+   unsigned char *cmdbuf; /* MCE command buffer */
+   long signal_duration = 0; /* Singnal length in us */
+   struct timeval start_time, end_time;
+
+   do_gettimeofday(start_time);
+
+   count = n / sizeof(int);
+
+   cmdbuf = kzalloc(sizeof(int) * MCE_CMDBUF_SIZE, GFP_KERNEL);
+   if (!cmdbuf)
+   return -ENOMEM;
+
+   /* MCE tx init header */
+   cmdbuf[cmdcount++] = MCE_CONTROL_HEADER;
+   cmdbuf[cmdcount++] = 0x08;
+   cmdbuf[cmdcount++] = ir-tx_mask;
+
+   /* Generate mce packet data */
+   for (i = 0; (i  count)  (cmdcount  MCE_CMDBUF_SIZE); i++) {
+   signal_duration += txbuf[i];
+   txbuf[i] = txbuf[i] / MCE_TIME_UNIT;
+
+   do { /* loop to support long pulses/spaces  127*50us=6.35ms */
+
+   /* Insert mce packet header every 4th entry */
+   if ((cmdcount  MCE_CMDBUF_SIZE) 
+   (cmdcount - MCE_TX_HEADER_LENGTH) %
+MCE_CODE_LENGTH == 0)
+   cmdbuf[cmdcount++] = MCE_PACKET_HEADER;
+
+   /* Insert mce packet data */
+   if (cmdcount  MCE_CMDBUF_SIZE)
+   cmdbuf[cmdcount++] =
+   (txbuf[i]  MCE_PULSE_BIT ?
+txbuf[i] : MCE_MAX_PULSE_LENGTH) |
+(i  1 ? 0x00 : MCE_PULSE_BIT);
+   else {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   } while ((txbuf[i]  MCE_MAX_PULSE_LENGTH) 
+(txbuf[i] -= MCE_MAX_PULSE_LENGTH));
+   }
+
+   /* Fix packet length in last header */
+   cmdbuf[cmdcount - (cmdcount - MCE_TX_HEADER_LENGTH) % MCE_CODE_LENGTH] =
+   0x80 + (cmdcount - MCE_TX_HEADER_LENGTH) % MCE_CODE_LENGTH - 1;
+
+   /* Check if we have room for the empty packet at the end */
+   if (cmdcount = MCE_CMDBUF_SIZE) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   /* All mce commands end with an empty packet (0x80) */
+   cmdbuf[cmdcount++] = 0x80;
+
+   /* Transmit the command to the mce device */
+   mce_async_out(ir, cmdbuf, cmdcount);
+
+   /*
+* The lircd gap calculation expects the write function to
+* wait the time it takes for the ircommand to be sent before
+* it returns.
+*/
+   do_gettimeofday(end_time);
+   signal_duration -= (end_time.tv_usec - start_time.tv_usec) +
+  (end_time.tv_sec - start_time.tv_sec) * 100;
+
+   /* delay with the closest number of ticks */
+   set_current_state(TASK_INTERRUPTIBLE);
+   schedule_timeout(usecs_to_jiffies(signal_duration));
+
+out:
+   kfree(cmdbuf);
+   return ret ? ret : n;
+}
+
 /* Sets active IR outputs -- mce devices typically (all?) have two */
 static int mceusb_set_tx_mask(void *priv, u32 mask)
 {
@@ -533,6 

Re: laggy remote on x64

2010-07-01 Thread Timothy D. Lenz
I have now noticed that IR drivers are being loaded when I modprobe 
cx23885 to load the drivers for the HVR-1800 which doesn't even have a 
remote. The 32bit computer doesn't have this card, it has a Nexus and a 
FusionHDTV7 express. The drivers that are being loaded seem to be enough 
to get a responce from the nexus remote, but it's doing exactly the same 
thing as when I also modprobe ir_kbd_i2c which was always used in the 
past to load remote drivers for the nexus and is what I have been using 
to load drivers for the Fusion card. Is there some kind of conflict now? 
I've had the 1800 in the x64 system with the nexus for a long time but 
stopped using/updating it to get the 32bit system running. There seems 
to be a problem with the new IR drivers.


On 6/29/2010 4:54 PM, Timothy D. Lenz wrote:

I have 2 systems nearly identical except one runs 64bit and the other
runs 32bit. I'm now trying to use the remote port on the nexus-s card.
The 32 bit seems to be working ok, but the 64bit acts like it's bussy
doing somthing else. It randomly won't respond to the remote. It doesn't
buffer the keys or anything. Wait a moment and maybe it works fine for a
few presses. When it doesn't respond is highly random. Kernel-2.6.34,
debian squeeze updated a few days ago, v4l is hg from 06/25/2010
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html