RE: [PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface

2010-07-26 Thread Kukjin Kim
Sylwester Nawrocki wrote:
 
 Add register definitions for the camera interface/video postprocessor
 contained in Samsung's S5P SoC series.
 
 Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Reviewed-by: Pawel Osciak p.osc...@samsung.com
 Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com
 ---
  arch/arm/plat-samsung/include/plat/regs-fimc.h |  294
 
  1 files changed, 294 insertions(+), 0 deletions(-)
  create mode 100644 arch/arm/plat-samsung/include/plat/regs-fimc.h
 
 diff --git a/arch/arm/plat-samsung/include/plat/regs-fimc.h
b/arch/arm/plat-
 samsung/include/plat/regs-fimc.h
 new file mode 100644
 index 000..7f3141c
 --- /dev/null
 +++ b/arch/arm/plat-samsung/include/plat/regs-fimc.h
 @@ -0,0 +1,294 @@
 +/* arch/arm/plat-s5p/include/plat/regs-fimc.h
 + *
 + * Register definition file for Samsung Camera Interface (FIMC) driver
 + *
 + * Copyright (c) 2010 Samsung Electronics
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#ifndef REGS_FIMC_H_
 +#define REGS_FIMC_H_
 +
 +#define S5P_CIOYSA(__x)  (0x18 + (__x) * 4)
 +#define S5P_CIOCBSA(__x) (0x28 + (__x) * 4)
 +#define S5P_CIOCRSA(__x) (0x38 + (__x) * 4)
 +
 +/* Input source format */
 +#define S5P_CISRCFMT 0x00
 +#define S5P_CISRCFMT_ITU601_8BIT (1  31)
 +#define S5P_CISRCFMT_ITU601_16BIT(1  29)
 +#define S5P_CISRCFMT_ORDER422_YCBYCR (0  14)
 +#define S5P_CISRCFMT_ORDER422_YCRYCB (1  14)
 +#define S5P_CISRCFMT_ORDER422_CBYCRY (2  14)
 +#define S5P_CISRCFMT_ORDER422_CRYCBY (3  14)
 +#define S5P_CISRCFMT_HSIZE(x)((x)  16)
 +#define S5P_CISRCFMT_VSIZE(x)((x)  0)
 +
 +/* Window offset */
 +#define S5P_CIWDOFST 0x04
 +#define S5P_CIWDOFST_WINOFSEN(1  31)
 +#define S5P_CIWDOFST_CLROVFIY(1  30)
 +#define S5P_CIWDOFST_CLROVRLB(1  29)
 +#define S5P_CIWDOFST_WINHOROFST_MASK (0x7ff  16)
 +#define S5P_CIWDOFST_CLROVFICB   (1  15)
 +#define S5P_CIWDOFST_CLROVFICR   (1  14)
 +#define S5P_CIWDOFST_WINHOROFST(x)   ((x)  16)
 +#define S5P_CIWDOFST_WINVEROFST(x)   ((x)  0)
 +#define S5P_CIWDOFST_WINVEROFST_MASK (0xfff  0)
 +
 +/* Global control */
 +#define S5P_CIGCTRL  0x08
 +#define S5P_CIGCTRL_SWRST(1  31)
 +#define S5P_CIGCTRL_CAMRST_A (1  30)
 +#define S5P_CIGCTRL_SELCAM_ITU_A (1  29)
 +#define S5P_CIGCTRL_SELCAM_ITU_MASK  (1  29)
 +#define S5P_CIGCTRL_TESTPAT_NORMAL   (0  27)
 +#define S5P_CIGCTRL_TESTPAT_COLOR_BAR(1  27)
 +#define S5P_CIGCTRL_TESTPAT_HOR_INC  (2  27)
 +#define S5P_CIGCTRL_TESTPAT_VER_INC  (3  27)
 +#define S5P_CIGCTRL_TESTPAT_MASK (3  27)
 +#define S5P_CIGCTRL_TESTPAT_SHIFT(27)
 +#define S5P_CIGCTRL_INVPOLPCLK   (1  26)
 +#define S5P_CIGCTRL_INVPOLVSYNC  (1  25)
 +#define S5P_CIGCTRL_INVPOLHREF   (1  24)
 +#define S5P_CIGCTRL_IRQ_OVFEN(1  22)
 +#define S5P_CIGCTRL_HREF_MASK(1  21)
 +#define S5P_CIGCTRL_IRQ_LEVEL(1  20)
 +#define S5P_CIGCTRL_IRQ_CLR  (1  19)
 +#define S5P_CIGCTRL_IRQ_ENABLE   (1  16)
 +#define S5P_CIGCTRL_SHDW_DISABLE (1  12)
 +#define S5P_CIGCTRL_SELCAM_MIPI_A(1  7)
 +#define S5P_CIGCTRL_CAMIF_SELWB  (1  6)
 +#define S5P_CIGCTRL_INVPOLHSYNC  (1  4)
 +#define S5P_CIGCTRL_SELCAM_MIPI  (1  3)
 +#define S5P_CIGCTRL_INTERLACE(1  0)
 +
 +/* Window offset 2 */
 +#define S5P_CIWDOFST20x14
 +#define S5P_CIWDOFST2_HOROFF_MASK(0xfff  16)
 +#define S5P_CIWDOFST2_VEROFF_MASK(0xfff  0)
 +#define S5P_CIWDOFST2_HOROFF(x)  ((x)  16)
 +#define S5P_CIWDOFST2_VEROFF(x)  ((x)  0)
 +
 +/* Output DMA Y plane start address */
 +#define S5P_CIOYSA1  0x18
 +#define S5P_CIOYSA2  0x1c
 +#define S5P_CIOYSA3  0x20
 +#define S5P_CIOYSA4  0x24
 +
 +/* Output DMA Cb plane start address */
 +#define S5P_CIOCBSA1 0x28
 +#define S5P_CIOCBSA2 0x2c
 +#define S5P_CIOCBSA3 0x30
 +#define S5P_CIOCBSA4 0x34
 +
 +/* Output DMA Cr plane start address */
 +#define S5P_CIOCRSA1 0x38
 +#define S5P_CIOCRSA2 0x3c
 +#define S5P_CIOCRSA3 0x40
 +#define S5P_CIOCRSA4 0x44
 +
 +/* Target image format */
 +#define S5P_CITRGFMT 0x48
 +#define S5P_CITRGFMT_INROT90 (1  31)
 +#define S5P_CITRGFMT_YCBCR420(0  29)
 +#define S5P_CITRGFMT_YCBCR422(1  29)
 +#define S5P_CITRGFMT_YCBCR422_1P (2  29)
 +#define S5P_CITRGFMT_RGB 

Re: Linux Plumber's Conference: Call for Working Session Submissions

2010-07-26 Thread Laurent Pinchart
Hi Mauro,

On Saturday 24 July 2010 22:43:35 Mauro Carvalho Chehab wrote:
 CFP dead line for submitting proposals to LPC/2010 is approaching.
 For those that intends to submit proposals for it, please do it quickly,
 as the official dead line is July, 26.

I'm submitted a media controller presentation proposal.

-- 
Regards,

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


Re: how to mmap in videobuf-dma-sg.c

2010-07-26 Thread Laurent Pinchart
Hi Mauro,

On Sunday 25 July 2010 19:46:49 Mauro Carvalho Chehab wrote:

[snip]

 The current videobuf implementation has some problems. Laurent and Pawel
 are working on a new implementation that will likely solve such issues.
 Not sure if they already submitted the patches, since I just return back
 from vacations, and I'm still trying to handle all the backlogs on my
 inboxes. I haven't look at LMML posts yet.

No patches submitted yet. It will probably still be weeks before we can submit 
something.

-- 
Regards,

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


Re: [RFC/PATCH v2 01/10] media: Media device node support

2010-07-26 Thread Laurent Pinchart
Hi Hans,

Thanks for the review.

On Saturday 24 July 2010 13:59:11 Hans Verkuil wrote:
 On Wednesday 21 July 2010 16:35:26 Laurent Pinchart wrote:
  The media_devnode structure provides support for registering and
  unregistering character devices using a dynamic major number. Reference
  counting is handled internally, making device drivers easier to write
  without having to solve the open/disconnect race condition issue over
  and over again.
  
  The code is based on video/v4l2-dev.c.

[snip]

  diff --git a/drivers/media/media-devnode.c
  b/drivers/media/media-devnode.c new file mode 100644
  index 000..fa300f8
  --- /dev/null
  +++ b/drivers/media/media-devnode.c
  @@ -0,0 +1,339 @@

[snip]

  +/*
  + * Active devices
  + */
  +static DEFINE_MUTEX(media_devnode_lock);
 
 I don't think this lock is actually needed. The bit operations are already
 atomic, so we can do without this lock.

The mutex is needed to avoid an open/unregister race. Without it the device 
could be unregistered during media_open, after the media_devnode_is_registered 
check but before the call to get_device.

  +static DECLARE_BITMAP(media_devnode_nums, MEDIA_NUM_DEVICES);
  +
  +static inline void media_get(struct media_devnode *mdev)
  +{
  +   get_device(mdev-dev);
  +}
  +
  +static inline void media_put(struct media_devnode *mdev)
  +{
  +   put_device(mdev-dev);
  +}
 
 These functions are used quite rarely. I'd remove these inlines and just
 call get/put_device directly.

Agreed. I was thinking of removing them and thought you would like it better 
if I kept them :-)

[snip]

  +static long media_ioctl(struct file *filp, unsigned int cmd, unsigned
  long arg) +{
  +   struct media_devnode *mdev = media_devnode_data(filp);
  +
  +   if (!media_devnode_is_registered(mdev))
  +   return -EIO;
  +
  +   if (!mdev-fops-unlocked_ioctl)
  +   return -ENOTTY;
 
 These two if's should be swapper (just like in media_read and write).

I'm not sure why, but OK.

  +
  +   return mdev-fops-unlocked_ioctl(filp, cmd, arg);
  +}
  +
  +/* Override for the open function */
  +static int media_open(struct inode *inode, struct file *filp)
  +{
  +   struct media_devnode *mdev;
  +   int ret;
  +
  +   /* Check if the media device is available */
  +   mutex_lock(media_devnode_lock);
  +   mdev = container_of(inode-i_cdev, struct media_devnode, cdev);
  +   /* return ENODEV if the media device has been removed
  +  already or if it is not registered anymore. */
  +   if (mdev == NULL || !media_devnode_is_registered(mdev)) {
 
 mdev can never be NULL.

Indeed, thanks.

  +   mutex_unlock(media_devnode_lock);
  +   return -ENODEV;
  +   }
  +   /* and increase the device refcount */
  +   media_get(mdev);
  +   mutex_unlock(media_devnode_lock);
  +   if (mdev-fops-open) {
  +   ret = mdev-fops-open(filp);
  +   if (ret) {
  +   media_put(mdev);
  +   return ret;
  +   }
  +   }
  +
  +   filp-private_data = mdev;
  +   return 0;
  +}

[snip]

  +/**
  + * media_devnode_register - register a media device node
  + * @mdev: media device node structure we want to register
  + *
  + * The registration code assigns minor numbers and registers the new 
  device node
  + * with the kernel. An error is returned if no free minor number can be
  found,
  + * or if the registration of the device node fails.
  + *
  + * Zero is returned on success.
  + *
  + * Note that if the media_devnode_register call fails, the release()
  callback of
  + * the media_devnode structure is *not* called, so the caller is
  responsible for
  + * freeing any data.
  + */
  +int __must_check media_devnode_register(struct media_devnode *mdev)
  +{
  +   void *priv;
  +   int minor;
  +   int ret;
  +
  +   /* Part 1: find a free minor number */
  +   mutex_lock(media_devnode_lock);
  +   minor = find_next_zero_bit(media_devnode_nums, 0, MEDIA_NUM_DEVICES);
 
 When media_devnode_lock is removed we can't use find_next_zero_bit anymore.
 Instead, we have to loop over all bits and call test_and_set_bit() to
 ensure atomicity.

I think the lock is still needed (see above), so find_next_zero_bit can be 
kept.

  +   if (minor == MEDIA_NUM_DEVICES) {
  +   printk(KERN_ERR could not get a free minor\n);
  +   mutex_unlock(media_devnode_lock);
  +   return -ENFILE;
  +   }
  +
  +   set_bit(mdev-minor, media_devnode_nums);
  +   mdev-minor = minor;
  +
  +   mutex_unlock(media_devnode_lock);
  +
  +   /* Part 2: Initialize and register the character device */
  +   cdev_init(mdev-cdev, media_devnode_fops);
  +   mdev-cdev.owner = mdev-fops-owner;
  +
  +   ret = cdev_add(mdev-cdev, MKDEV(MAJOR(media_dev_t), mdev-minor), 1);
  +   if (ret  0) {
  +   printk(KERN_ERR %s: cdev_add failed\n, __func__);
  +   goto error;
  +   }
  +
  +   /* Part 3: register the media device
  +*
  +* Zeroing struct device will clear the device's drvdata, so make 

Re: [RFC/PATCH v2 02/10] media: Media device

2010-07-26 Thread Laurent Pinchart
Hi Hans,

On Saturday 24 July 2010 14:02:50 Hans Verkuil wrote:
 On Wednesday 21 July 2010 16:35:27 Laurent Pinchart wrote:
  The media_device structure abstracts functions common to all kind of
  media devices (v4l2, dvb, alsa, ...). It manages media entities and
  offers a userspace API to discover and configure the media device
  internal topology.
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  ---
  
   Documentation/media-framework.txt |   68
    drivers/media/Makefile|   
   2 +-
   drivers/media/media-device.c  |   77
   + include/media/media-device.h 
   |   53 + 4 files changed, 199 insertions(+), 1
   deletions(-)
   create mode 100644 Documentation/media-framework.txt
   create mode 100644 drivers/media/media-device.c
   create mode 100644 include/media/media-device.h
 
 snip
 
 As discussed on IRC: I would merge media-device and media-devnode. I see no
 benefit in separating them at this time.

I'm not too sure about it. I still think the separation gives us cleaner, 
easier to understand code. My opinion on it isn't that strong, so I could be 
convinced to merge the two, but Sakari seemed to think they shouldn't be 
merged last time I talked to him about it. I'll let him answer.

-- 
Regards,

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


Re: Pull request mxc

2010-07-26 Thread Sascha Hauer
[Added Guennadi, Baruch and linux-media to cc]

On Mon, Jul 26, 2010 at 11:32:19AM +0100, Russell King - ARM Linux wrote:
 On Mon, Jul 26, 2010 at 10:28:55AM +0100, Russell King - ARM Linux wrote:
  On Mon, Jul 26, 2010 at 11:00:14AM +0200, Sascha Hauer wrote:
160 files changed, 6547 insertions(+), 3276 deletions(-)
  
  I get:
  
  160 files changed, 6530 insertions(+), 3265 deletions
  
  which seems to be down to this difference between your diffstat and mine:
  
   arch/arm/mach-mx3/mach-mx31lilly.c |   48 +-
  
   arch/arm/mach-mx3/mach-mx31lilly.c |   20 +-
  
  This seems to be down to 4d5d859 (ARM: mx3: mx31lilly: fix build error for
  !CONFIG_USB_ULPI).
 
 Err...
 
 commit 10ee61384e444133e4d2cf2a1f21fdd50c2be297
 Author: Baruch Siach bar...@tkos.co.il
 Date:   Sun Jul 4 07:55:10 2010 +0300
 
 mx2_camera: Add soc_camera support for i.MX25/i.MX27
 
 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
 Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
 
 Why has no one from the V4L community reviewed this patch?

It was posted to linux-media and reviewed there. I put it in my tree to
prevent problems due to missing platform_data declarations when board
support for the camera gets added.

 
 Why are you using void __iomem * with the virtual address returned from
 dma_alloc_coherent()?  It doesn't return IOMEM addresses!

Baruch, can you fix this?

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCHv2 0/4] The Contiguous Memory Allocator

2010-07-26 Thread Michal Nazarewicz
Hello everyone,

The following patchset implements a Contiguous Memory Allocator.  For
those who have not yet stumbled across CMA an excerpt from
documentation:

   The Contiguous Memory Allocator (CMA) is a framework, which allows
   setting up a machine-specific configuration for physically-contiguous
   memory management. Memory for devices is then allocated according
   to that configuration.

   The main role of the framework is not to allocate memory, but to
   parse and manage memory configurations, as well as to act as an
   in-between between device drivers and pluggable allocators. It is
   thus not tied to any memory allocation method or strategy.

For more information please refer to the second patch from the
patchset which contains the documentation.


This is the second version of the patchset.  All of the changes are
concentrated in the second patch -- the other patches are almost
identical.

Major observable changes are:

1. The cma_map command line have been removed.  In exchange, a SysFS
   entry has been created under kernel/mm/contiguous.
   
   The configuration strings passed to CMA are now called attributes
   in the documentation.

   The intended way of specifying the attributes is
   a cma_set_defaults() function called by platform initialisation
   code.  regions attribute (the string specified by cma command
   line parameter) can be overwritten with command line parameter; the
   other attributes can be changed during run-time using the SysFS
   entries.

   (I still believe that the other attributes should have their own
   command line arguments as well but since they posed a lot of
   controversy (and many stopped reading after encountering them)
   cma_map have been removed.)

2. The behaviour of the map attribute has been modified slightly.
   Currently, if no rule matches given device it is assigned regions
   specified by the asterisk attribute.  It is by default built from
   the region names given in regions attribute.

   This also means that if no map is specified all devices use all
   the regions specified in the regions attribute.  This should be
   a handy default.

3. Devices can register private regions as well as regions that can be
   shared but are not reserved using standard CMA mechanisms.
   A private region has no name and can be accessed only by devices
   that have the pointer to it.

   Moreover, if device manages to run its code early enough it can
   register an early region.  An early region is one memory has not
   been reserved for.  At one point, platform initialisation code
   reserves memory for all registered early regions and if this
   succeeds those regions are registered as normal regions that can be
   used with the standard API.  This may be handy for devices that
   need some private region but don't want to worry about reserving
   it.

4. The way allocators are registered has changed.  Currently,
   a cma_allocator_register() function is used for that purpose.
   Moreover, allocators are attached to regions the first time memory
   is registered from the region or when allocator is registered which
   means that allocators can be dynamic modules that are loaded after
   the kernel booted (of course, it won't be possible to allocate
   a chunk of memory from a region if allocator is not loaded).


Index of new functions:

+static inline dma_addr_t __must_check
+cma_alloc_from(const char *regions, size_t size, dma_addr_t alignment)

+static inline int
+cma_info_about(struct cma_info *info, const const char *regions)

+int __must_check cma_region_register(struct cma_region *reg);

+dma_addr_t __must_check
+cma_alloc_from_region(struct cma_region *reg,
+ size_t size, dma_addr_t alignment);

+static inline dma_addr_t __must_check
+cma_alloc_from(const char *regions,
+   size_t size, dma_addr_t alignment);

+int cma_allocator_register(struct cma_allocator *alloc);


The patches in the patchset include:

Michal Nazarewicz (4):
  lib: rbtree: rb_root_init() function added

The rb_root_init() function initialises an RB tree with a single
node placed in the root.  This is more convenient then
initialising an empty tree and then adding an element.

  mm: cma: Contiguous Memory Allocator added

This patch is the main patchset that implements the CMA framework
including the best-fit allocator.  It also adds a documentation.

  mm: cma: Test device and application added

This patch adds a misc device that works as a proxy to the CMA
framework and a simple testing application.  This lets one test
the whole framework from user space as well as reply an recorded
allocate/free sequence.

  arm: Added CMA to Aquila and Goni

This patch adds the CMA platform initialisation code to two ARM
platforms.  It serves as an example of how this is achieved.

 Documentation/00-INDEX |2 +
 .../ABI/testing/sysfs-kernel-mm-contiguous |9 +
 

[PATCHv2 1/4] lib: rbtree: rb_root_init() function added

2010-07-26 Thread Michal Nazarewicz
Added a rb_root_init() function which initialises a rb_root
structure as a red-black tree with at most one element.  The
rationale is that using rb_root_init(root, node) is more
straightforward and cleaner then first initialising and
empty tree followed by an insert operation.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 include/linux/rbtree.h |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 7066acb..5b6dc66 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -130,6 +130,17 @@ static inline void rb_set_color(struct rb_node *rb, int 
color)
 }
 
 #define RB_ROOT(struct rb_root) { NULL, }
+
+static inline void rb_root_init(struct rb_root *root, struct rb_node *node)
+{
+   root-rb_node = node;
+   if (node) {
+   node-rb_parent_color = RB_BLACK; /* black, no parent */
+   node-rb_left  = NULL;
+   node-rb_right = NULL;
+   }
+}
+
 #definerb_entry(ptr, type, member) container_of(ptr, type, member)
 
 #define RB_EMPTY_ROOT(root)((root)-rb_node == NULL)
-- 
1.7.1

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


[PATCHv2 3/4] mm: cma: Test device and application added

2010-07-26 Thread Michal Nazarewicz
This patch adds a cma misc device which lets user space use the
CMA API.  This device is meant for testing.  A testing application
is also provided.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/misc/Kconfig   |8 +
 drivers/misc/Makefile  |1 +
 drivers/misc/cma-dev.c |  184 
 include/linux/cma.h|   30 
 tools/cma/cma-test.c   |  373 
 5 files changed, 596 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/cma-dev.c
 create mode 100644 tools/cma/cma-test.c

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 9b089df..6ae3d9f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -368,4 +368,12 @@ source drivers/misc/eeprom/Kconfig
 source drivers/misc/cb710/Kconfig
 source drivers/misc/iwmc3200top/Kconfig
 
+config CMA_DEVICE
+   tristate CMA misc device (DEVELOPEMENT)
+   depends on CMA
+   help
+ The CMA misc device allows allocating contiguous memory areas
+ from user space.  This is mostly for testing of the CMA
+ framework.
+
 endif # MISC_DEVICES
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 67552d6..9921370 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -32,3 +32,4 @@ obj-y += eeprom/
 obj-y  += cb710/
 obj-$(CONFIG_VMWARE_BALLOON)   += vmware_balloon.o
 obj-$(CONFIG_ARM_CHARLCD)  += arm-charlcd.o
+obj-$(CONFIG_CMA_DEVICE)   += cma-dev.o
diff --git a/drivers/misc/cma-dev.c b/drivers/misc/cma-dev.c
new file mode 100644
index 000..7d7bc05
--- /dev/null
+++ b/drivers/misc/cma-dev.c
@@ -0,0 +1,184 @@
+/*
+ * Contiguous Memory Allocator userspace driver
+ * Copyright (c) 2010 by Samsung Electronics.
+ * Written by Michal Nazarewicz (m.nazarew...@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 optional) any later version of the license.
+ */
+
+#define pr_fmt(fmt) cma:  fmt
+
+#ifdef CONFIG_CMA_DEBUG
+#  define DEBUG
+#endif
+
+#include linux/errno.h   /* Error numbers */
+#include linux/err.h /* IS_ERR_VALUE() */
+#include linux/fs.h  /* struct file */
+#include linux/mm.h  /* Memory stuff */
+#include linux/mman.h
+#include linux/slab.h
+#include linux/module.h  /* Standard module stuff */
+#include linux/device.h  /* struct device, dev_dbg() */
+#include linux/types.h   /* Just to be safe ;) */
+#include linux/uaccess.h /* __copy_{to,from}_user */
+#include linux/miscdevice.h  /* misc_register() and company */
+
+#include linux/cma.h
+
+static int  cma_file_open(struct inode *inode, struct file *file);
+static int  cma_file_release(struct inode *inode, struct file *file);
+static long cma_file_ioctl(struct file *file, unsigned cmd, unsigned long arg);
+static int  cma_file_mmap(struct file *file, struct vm_area_struct *vma);
+
+
+static struct miscdevice cma_miscdev = {
+   .minor = MISC_DYNAMIC_MINOR,
+   .name  = cma,
+   .fops  = (const struct file_operations) {
+   .owner  = THIS_MODULE,
+   .open   = cma_file_open,
+   .release= cma_file_release,
+   .unlocked_ioctl = cma_file_ioctl,
+   .mmap   = cma_file_mmap,
+   },
+};
+#define cma_dev (cma_miscdev.this_device)
+
+
+#define cma_file_start(file) (((dma_addr_t *)(file)-private_data)[0])
+#define cma_file_size(file)  (((dma_addr_t *)(file)-private_data)[1])
+
+
+static int  cma_file_open(struct inode *inode, struct file *file)
+{
+   dev_dbg(cma_dev, %s(%p)\n, __func__, (void *)file);
+
+   file-private_data = NULL;
+
+   return 0;
+}
+
+
+static int  cma_file_release(struct inode *inode, struct file *file)
+{
+   dev_dbg(cma_dev, %s(%p)\n, __func__, (void *)file);
+
+   if (file-private_data) {
+   cma_put(cma_file_start(file));
+   kfree(file-private_data);
+   }
+
+   return 0;
+}
+
+
+static long cma_file_ioctl(struct file *file, unsigned cmd, unsigned long arg)
+{
+   struct cma_alloc_request req;
+   struct device fake_device;
+   unsigned long addr;
+   long ret;
+
+   dev_dbg(cma_dev, %s(%p)\n, __func__, (void *)file);
+
+   if (cmd != IOCTL_CMA_ALLOC)
+   return -ENOTTY;
+
+   if (!arg)
+   return -EINVAL;
+
+   if (file-private_data) /* Already allocated */
+   return -EBADFD;
+
+   if (copy_from_user(req, (void *)arg, sizeof req))
+   return -EFAULT;
+
+   if (req.magic != CMA_MAGIC)
+   return -ENOTTY;
+
+   /* May happen on 32 bit system. */
+   if (req.size  ~(typeof(req.size))0 ||
+   

[PATCHv2 4/4] arm: Added CMA to Aquila and Goni

2010-07-26 Thread Michal Nazarewicz
Added the CMA initialisation code to two Samsung platforms.

Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 arch/arm/mach-s5pv210/mach-aquila.c |   13 +
 arch/arm/mach-s5pv210/mach-goni.c   |   13 +
 2 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-s5pv210/mach-aquila.c 
b/arch/arm/mach-s5pv210/mach-aquila.c
index 0992618..ab156f9 100644
--- a/arch/arm/mach-s5pv210/mach-aquila.c
+++ b/arch/arm/mach-s5pv210/mach-aquila.c
@@ -19,6 +19,7 @@
 #include linux/gpio_keys.h
 #include linux/input.h
 #include linux/gpio.h
+#include linux/cma.h
 
 #include asm/mach/arch.h
 #include asm/mach/map.h
@@ -454,6 +455,17 @@ static void __init aquila_map_io(void)
s3c24xx_init_uarts(aquila_uartcfgs, ARRAY_SIZE(aquila_uartcfgs));
 }
 
+static void __init aquila_reserve(void)
+{
+   static char regions[] __initdata =
+   -mfc_fw=1M/128K;mfc_b1=32M;mfc_b2=...@0x4000;
+   static char map[] __initdata =
+   s3c-mfc5/f=mfc_fw;s3c-mfc5/a=mfc_b1;s3c-mfc5/b=mfc_b2;
+
+   cma_set_defaults(regions, map, NULL);
+   cma_early_regions_reserve(NULL);
+}
+
 static void __init aquila_machine_init(void)
 {
/* PMIC */
@@ -478,4 +490,5 @@ MACHINE_START(AQUILA, Aquila)
.map_io = aquila_map_io,
.init_machine   = aquila_machine_init,
.timer  = s3c24xx_timer,
+   .reserve= aquila_reserve,
 MACHINE_END
diff --git a/arch/arm/mach-s5pv210/mach-goni.c 
b/arch/arm/mach-s5pv210/mach-goni.c
index 7b18505..2b0a349 100644
--- a/arch/arm/mach-s5pv210/mach-goni.c
+++ b/arch/arm/mach-s5pv210/mach-goni.c
@@ -19,6 +19,7 @@
 #include linux/gpio_keys.h
 #include linux/input.h
 #include linux/gpio.h
+#include linux/cma.h
 
 #include asm/mach/arch.h
 #include asm/mach/map.h
@@ -435,6 +436,17 @@ static void __init goni_map_io(void)
s3c24xx_init_uarts(goni_uartcfgs, ARRAY_SIZE(goni_uartcfgs));
 }
 
+static void __init goni_reserve(void)
+{
+   static char regions[] __initdata =
+   -mfc_fw=1M/128K;mfc_b1=32M;mfc_b2=...@0x4000;
+   static char map[] __initdata =
+   s3c-mfc5/f=mfc_fw;s3c-mfc5/a=mfc_b1;s3c-mfc5/b=mfc_b2;
+
+   cma_set_defaults(regions, map, NULL);
+   cma_early_regions_reserve(NULL);
+}
+
 static void __init goni_machine_init(void)
 {
/* PMIC */
@@ -456,4 +468,5 @@ MACHINE_START(GONI, GONI)
.map_io = goni_map_io,
.init_machine   = goni_machine_init,
.timer  = s3c24xx_timer,
+   .reserve= goni_reserve,
 MACHINE_END
-- 
1.7.1

--
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] IR/imon: remove incorrect calls to input_free_device

2010-07-26 Thread Jarod Wilson
Per Dmitry Torokhov (in a completely unrelated thread on linux-input),
following input_unregister_device with an input_free_device is
forbidden, the former is sufficient alone.

CC: Dmitry Torokhov dmitry.torok...@gmail.com
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/media/IR/imon.c |5 +
 1 files changed, 1 insertions(+), 4 deletions(-)

diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index 0195dd5..08dff8c 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -1944,7 +1944,6 @@ static struct imon_context *imon_init_intf0(struct 
usb_interface *intf)
 
 urb_submit_failed:
ir_input_unregister(ictx-idev);
-   input_free_device(ictx-idev);
 idev_setup_failed:
 find_endpoint_failed:
mutex_unlock(ictx-lock);
@@ -2014,10 +2013,8 @@ static struct imon_context *imon_init_intf1(struct 
usb_interface *intf,
return ictx;
 
 urb_submit_failed:
-   if (ictx-touch) {
+   if (ictx-touch)
input_unregister_device(ictx-touch);
-   input_free_device(ictx-touch);
-   }
 touch_setup_failed:
 find_endpoint_failed:
mutex_unlock(ictx-lock);
-- 
1.7.1.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


Re: [RFC/PATCH v2 02/10] media: Media device

2010-07-26 Thread Sakari Ailus
Hans Verkuil wrote:
 On Wednesday 21 July 2010 16:35:27 Laurent Pinchart wrote:
 The media_device structure abstracts functions common to all kind of
 media devices (v4l2, dvb, alsa, ...). It manages media entities and
 offers a userspace API to discover and configure the media device
 internal topology.

 Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  Documentation/media-framework.txt |   68 
  drivers/media/Makefile|2 +-
  drivers/media/media-device.c  |   77 
 +
  include/media/media-device.h  |   53 +
  4 files changed, 199 insertions(+), 1 deletions(-)
  create mode 100644 Documentation/media-framework.txt
  create mode 100644 drivers/media/media-device.c
  create mode 100644 include/media/media-device.h

 
 snip
 
 As discussed on IRC: I would merge media-device and media-devnode. I see no
 benefit in separating them at this time.

I have to say I like the current separation of registration / node
handling and the actual implementation, as in V4L2. There's more code to
both files in the following patches. It think the result is easier to
understand the way it is.

You do have a point there that there's no need to separate them since
media_devnode is only used in media_device, at the moment at least. Or
is there a chance we would get different kind of control devices that
would use media_devnode in the future? I don't see a clear need for
such, though.

Could media_devnode and media_device be combined without breaking this
nice separation in the code too much?

Regards,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.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: tm6000 bad marge staging/tm6000 into staging/all

2010-07-26 Thread Stefan Ringel

 Am 25.07.2010 19:58, schrieb Mauro Carvalho Chehab:

Em 25-07-2010 04:28, Stefan Ringel escreveu:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Mauro,

This marge are wrong! It's added double dvb led off, but my patch has
only ones.

raw | combined (merge: 011906d 6e5e76f)

Merge branch 'staging/tm6000' into staging/all
Mauro Carvalho Chehab [Sun, 4 Jul 2010 19:33:26 + (16:33 -0300)]

* staging/tm6000: (29 commits)
   tm6000: Partially revert some copybuf logic
   tm6000: Be sure that the new buffer is empty
   tm6000: Fix copybuf continue logic Signed-off-by: Mauro Carvalho
Chehabmche...@redhat.com
   tm6000: audio packet has always 180 bytes
   tm6000: Improve set bitrate routines used by alsa
   tm6000-alsa: Implement a routine to store data received from URB
   tm6000-alsa: Fix several bugs at the driver initialization code
   tm6000: avoid unknown symbol tm6000_debug
   tm6000: Add a callback code for buffer fill
   tm6000: Use an emum for extension type
   tm6000-alsa: rework audio buffer allocation/deallocation
   tm6000: Avoid OOPS when loading tm6000-alsa module
   tm6000: Fix compilation breakages
   V4L/DVB: Staging: tm6000: Fix coding style issues
   V4L/DVB: tm6000: move dvb into a separate kern module
   V4L/DVB: tm6000: rewrite init and fini
   V4L/DVB: tm6000: Fix Video decoder initialization
   V4L/DVB: tm6000: rewrite copy_streams
   V4L/DVB: tm6000: add DVB support for tuner xc5000
   V4L/DVB: tm6000: set variable dev_mode in function tm6000_start_stream
   ...

diff --cc drivers/staging/tm6000/tm6000-core.c

index 27f3f55,1fea5a0..9f60ad5
- --- 1/drivers/staging/tm6000/tm6000-core.c
- --- 2/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@@ -336,11 -332,11 +332,17 @@@ int tm6000_init_analog_mode(struct tm60
 mutex_unlock(dev-lock);

 msleep(100);
- -   tm6000_set_standard (dev,dev-norm);
- -   tm6000_set_audio_bitrate (dev,48000);
+   tm6000_set_standard(dev,dev-norm);
+   tm6000_set_audio_bitrate(dev, 48000);
+
+   /* switch dvb led off */
+   if (dev-gpio.dvb_led) {
++  tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
++  dev-gpio.dvb_led, 0x01);
++  }
  +
  +  /* switch dvb led off */
  +  if (dev-gpio.dvb_led) {
 tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
 dev-gpio.dvb_led, 0x01);
 }

I hate those merge conflicts ;)

could you please send me a patch fixing it at staging/all? I won't apply it
upstream, but we shouldn't simply revert a patch at staging, otherwise, we'll
break every clone of my tree.

cannot found staging/all.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMS+eJAAoJEAWtPFjxMvFGDw8IAJnmTxTehH4TeqwI3Gn+8gcn
Xp8VPH/F67npT3zHQMq4luBEWdnMKkI/y54en8czoqG+EHEnxZjFZUxJUkAKPbpd
pU9vVUrQGtUQOf7zY6qYSqaSPIJr+abTmE1k2Wnd47Zwlu35tfRhuVXqfrTu7JkT
/Jy4Xf/IOtJvCa62eDCnhB6+gAq+hj5peHiZb7KBxOQO1NH8DQ8DYQPT9xNn5SFs
mCmQv9BdNrLdXS4mCkufBWEinennolOIoaSIyj2GkvJm8aSvzIWGvm28zxjPLKPL
PLH7A+WPMHCdor7Psn7QJKCm3DPEKu3vcOTOmFYsBJfV/pUNMK+5y3qV1WP9Ayg=
=HCq5
-END PGP SIGNATURE-



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


V4L2: avoid name conflicts in macros

2010-07-26 Thread Guennadi Liakhovetski
sd and err are too common names to be used in macros for local variables.
Prefix them with an underscore to avoid name clashing.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 include/media/v4l2-device.h |   22 +++---
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index 5d5d550..aaa9f00 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -99,11 +99,11 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev *sd);
while walking the subdevs list. */
 #define __v4l2_device_call_subdevs(v4l2_dev, cond, o, f, args...)  \
do {\
-   struct v4l2_subdev *sd; \
+   struct v4l2_subdev *__sd;   \
\
-   list_for_each_entry(sd, (v4l2_dev)-subdevs, list) \
-   if ((cond)  sd-ops-o  sd-ops-o-f)  \
-   sd-ops-o-f(sd , ##args); \
+   list_for_each_entry(__sd, (v4l2_dev)-subdevs, list)   \
+   if ((cond)  __sd-ops-o  __sd-ops-o-f)  \
+   __sd-ops-o-f(__sd , ##args); \
} while (0)
 
 /* Call the specified callback for all subdevs matching the condition.
@@ -112,16 +112,16 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev 
*sd);
subdev while walking the subdevs list. */
 #define __v4l2_device_call_subdevs_until_err(v4l2_dev, cond, o, f, args...) \
 ({ \
-   struct v4l2_subdev *sd; \
-   long err = 0;   \
+   struct v4l2_subdev *__sd;   \
+   long __err = 0; \
\
-   list_for_each_entry(sd, (v4l2_dev)-subdevs, list) {   \
-   if ((cond)  sd-ops-o  sd-ops-o-f)  \
-   err = sd-ops-o-f(sd , ##args);   \
-   if (err  err != -ENOIOCTLCMD) \
+   list_for_each_entry(__sd, (v4l2_dev)-subdevs, list) { \
+   if ((cond)  __sd-ops-o  __sd-ops-o-f)  \
+   __err = __sd-ops-o-f(__sd , ##args); \
+   if (__err  __err != -ENOIOCTLCMD) \
break;  \
}   \
-   (err == -ENOIOCTLCMD) ? 0 : err;\
+   (__err == -ENOIOCTLCMD) ? 0 : __err;\
 })
 
 /* Call the specified callback for all subdevs matching grp_id (if 0, then
-- 
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: V4L2: avoid name conflicts in macros

2010-07-26 Thread Hans Verkuil
On Monday 26 July 2010 17:39:15 Guennadi Liakhovetski wrote:
 sd and err are too common names to be used in macros for local variables.
 Prefix them with an underscore to avoid name clashing.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de

Good point.

Acked-by: Hans Verkuil hverk...@xs4all.nl

Regards,

Hans

 ---
  include/media/v4l2-device.h |   22 +++---
  1 files changed, 11 insertions(+), 11 deletions(-)
 
 diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
 index 5d5d550..aaa9f00 100644
 --- a/include/media/v4l2-device.h
 +++ b/include/media/v4l2-device.h
 @@ -99,11 +99,11 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev 
 *sd);
 while walking the subdevs list. */
  #define __v4l2_device_call_subdevs(v4l2_dev, cond, o, f, args...)\
   do {\
 - struct v4l2_subdev *sd; \
 + struct v4l2_subdev *__sd;   \
   \
 - list_for_each_entry(sd, (v4l2_dev)-subdevs, list) \
 - if ((cond)  sd-ops-o  sd-ops-o-f)  \
 - sd-ops-o-f(sd , ##args); \
 + list_for_each_entry(__sd, (v4l2_dev)-subdevs, list)   \
 + if ((cond)  __sd-ops-o  __sd-ops-o-f)  \
 + __sd-ops-o-f(__sd , ##args); \
   } while (0)
  
  /* Call the specified callback for all subdevs matching the condition.
 @@ -112,16 +112,16 @@ void v4l2_device_unregister_subdev(struct v4l2_subdev 
 *sd);
 subdev while walking the subdevs list. */
  #define __v4l2_device_call_subdevs_until_err(v4l2_dev, cond, o, f, args...) \
  ({   \
 - struct v4l2_subdev *sd; \
 - long err = 0;   \
 + struct v4l2_subdev *__sd;   \
 + long __err = 0; \
   \
 - list_for_each_entry(sd, (v4l2_dev)-subdevs, list) {   \
 - if ((cond)  sd-ops-o  sd-ops-o-f)  \
 - err = sd-ops-o-f(sd , ##args);   \
 - if (err  err != -ENOIOCTLCMD) \
 + list_for_each_entry(__sd, (v4l2_dev)-subdevs, list) { \
 + if ((cond)  __sd-ops-o  __sd-ops-o-f)  \
 + __err = __sd-ops-o-f(__sd , ##args); \
 + if (__err  __err != -ENOIOCTLCMD) \
   break;  \
   }   \
 - (err == -ENOIOCTLCMD) ? 0 : err;\
 + (__err == -ENOIOCTLCMD) ? 0 : __err;\
  })
  
  /* Call the specified callback for all subdevs matching grp_id (if 0, then
 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
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: [SAMPLE v2 04/12] v4l-subdev: Add pads operations

2010-07-26 Thread Laurent Pinchart
On Friday 23 July 2010 17:56:02 Karicheri, Muralidharan wrote:
 Laurent,
 
 Could you explain the probe and active usage using an example such as
 below?
 
 Link1Link2
 input sensor - ccdc - video node.
 
 Assume Link2 we can have either format 1 or format 2 for capture.

Sure.

The probe and active formats are used to probe supported formats and 
getting/setting active formats.

* Enumerating supported formats on the CCDC input and output would be done 
with the following calls

ENUM_FMT(CCDC input pad)

for the input, and

S_FMT(PROBE, CCDC input pad, format)
ENUM_FMT(CCDC output pad)

for the output.

Setting the probe format on the input pad is required, as the format on an 
output pad usually depends on the format on input pads.

* Trying a format on the CCDC input and output would be done with

S_FMT(PROBE, CCDC input pad, format)

for the input, and

S_FMT(PROBE, CCDC input pad, format)
S_FMT(PROBE, CCDC output pad, format)

on the output. The S_FMT call will mangle the format given format if it can't 
be supported exactly, so there's no need to call G_FMT after S_FMT (a G_FMT 
call following a S_FMT call will return the same format as the S_FMT call).

* Setting the active format is done with

S_FMT(ACTIVE, CCDC input pad, format)
S_FMT(ACTIVE, CCDC output pad, format)

The formats will be applied to the hardware (possibly with a delay, drivers 
can delay register writes until STREAMON for instance).

Probe formats are stored in the subdev file handles, so two applications 
trying formats at the same time will not interfere with each other. Active 
formats are stored in the device structure, so modifications done by an 
application are visible to other applications.

Hope this helps clarifying the API.

-- 
Regards,

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


RE: [SAMPLE v2 04/12] v4l-subdev: Add pads operations

2010-07-26 Thread Karicheri, Muralidharan
Laurent,

Thanks for clarifying this. I guess this will also get documented in the
v4l2 specs (if not already done) as part of this patch.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com

-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
Sent: Monday, July 26, 2010 12:13 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org; sakari.ai...@maxwell.research.nokia.com
Subject: Re: [SAMPLE v2 04/12] v4l-subdev: Add pads operations

On Friday 23 July 2010 17:56:02 Karicheri, Muralidharan wrote:
 Laurent,

 Could you explain the probe and active usage using an example such as
 below?

 Link1Link2
 input sensor - ccdc - video node.

 Assume Link2 we can have either format 1 or format 2 for capture.

Sure.

The probe and active formats are used to probe supported formats and
getting/setting active formats.

* Enumerating supported formats on the CCDC input and output would be done
with the following calls

ENUM_FMT(CCDC input pad)

for the input, and

S_FMT(PROBE, CCDC input pad, format)
ENUM_FMT(CCDC output pad)

for the output.

Setting the probe format on the input pad is required, as the format on an
output pad usually depends on the format on input pads.

* Trying a format on the CCDC input and output would be done with

S_FMT(PROBE, CCDC input pad, format)

for the input, and

S_FMT(PROBE, CCDC input pad, format)
S_FMT(PROBE, CCDC output pad, format)

on the output. The S_FMT call will mangle the format given format if it
can't
be supported exactly, so there's no need to call G_FMT after S_FMT (a G_FMT
call following a S_FMT call will return the same format as the S_FMT call).

* Setting the active format is done with

S_FMT(ACTIVE, CCDC input pad, format)
S_FMT(ACTIVE, CCDC output pad, format)

The formats will be applied to the hardware (possibly with a delay, drivers
can delay register writes until STREAMON for instance).

Probe formats are stored in the subdev file handles, so two applications
trying formats at the same time will not interfere with each other. Active
formats are stored in the device structure, so modifications done by an
application are visible to other applications.

Hope this helps clarifying the API.

--
Regards,

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


Re: [RFC/PATCH v2 01/10] media: Media device node support

2010-07-26 Thread Laurent Pinchart
Hi Hans,

On Monday 26 July 2010 11:07:14 Laurent Pinchart wrote:
 Hi Hans,
 On Saturday 24 July 2010 13:59:11 Hans Verkuil wrote:
  On Wednesday 21 July 2010 16:35:26 Laurent Pinchart wrote:
   The media_devnode structure provides support for registering and
   unregistering character devices using a dynamic major number. Reference
   counting is handled internally, making device drivers easier to write
   without having to solve the open/disconnect race condition issue over
   and over again.
   
   The code is based on video/v4l2-dev.c.

[snip]

   + mdev-dev.class = media_class;
   + mdev-dev.devt = MKDEV(MAJOR(media_dev_t), mdev-minor);
   + mdev-dev.release = media_devnode_release;
   + if (mdev-parent)
   + mdev-dev.parent = mdev-parent;
   + dev_set_name(mdev-dev, media%d, mdev-minor);
  
  Wouldn't mediactlX be a better name? Just plain 'media' is awfully
  general.
 
 Good question.

Oops, I forgot to elaborate on that :-)

Plain media is indeed very generic. mediactl would be more specific, but 
I've never really liked the term media controller. If you look at the media 
framework documentation, there's no reference to controller :-) I think it's 
just a media device.

-- 
Regards,

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


[PATCH 0/5] Support CSI2 on SH-Mobile SoCs

2010-07-26 Thread Guennadi Liakhovetski
This patch series adds support fot the CSI2 unit on some SH-Mobile SoCs, 
which implement the MIPI CSI-2 bus.

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


[PATCH 1/5] V4L2: mediabus: add 12-bit Bayer and YUV420 pixel formats

2010-07-26 Thread Guennadi Liakhovetski
These formats belong to the standard format set, defined by the MIPI CSI-2
specification.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 include/media/v4l2-mediabus.h |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 865cda7..584e1b1 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -41,6 +41,11 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
V4L2_MBUS_FMT_SGRBG8_1X8,
+   V4L2_MBUS_FMT_SBGGR12_1X12,
+   V4L2_MBUS_FMT_YUYV8_1_5X8,
+   V4L2_MBUS_FMT_YVYU8_1_5X8,
+   V4L2_MBUS_FMT_UYVY8_1_5X8,
+   V4L2_MBUS_FMT_VYUY8_1_5X8,
 };
 
 /**
-- 
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


[PATCH 2/5] ARM: mash-shmobile: add clock definitions for CEU and CSI2

2010-07-26 Thread Guennadi Liakhovetski
Two more clocks to be managed by the runtime PM.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 arch/arm/mach-shmobile/clock-sh7372.c |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-shmobile/clock-sh7372.c 
b/arch/arm/mach-shmobile/clock-sh7372.c
index b801efb..9b87985 100644
--- a/arch/arm/mach-shmobile/clock-sh7372.c
+++ b/arch/arm/mach-shmobile/clock-sh7372.c
@@ -395,7 +395,7 @@ static struct clk div6_reparent_clks[DIV6_REPARENT_NR] = {
 
 enum { MSTP001,
MSTP131, MSTP130,
-   MSTP129, MSTP128,
+   MSTP129, MSTP128, MSTP127, MSTP126,
MSTP118, MSTP117, MSTP116,
MSTP106, MSTP101, MSTP100,
MSTP223,
@@ -413,6 +413,8 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP130] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 30, 0), /* VEU2 */
[MSTP129] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 29, 0), /* VEU1 */
[MSTP128] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 28, 0), /* VEU0 */
+   [MSTP127] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 27, 0), /* CEU */
+   [MSTP126] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 26, 0), /* CSI2 */
[MSTP118] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 18, 0), /* DSITX */
[MSTP117] = MSTP(div4_clks[DIV4_B], SMSTPCR1, 17, 0), /* LCDC1 */
[MSTP116] = MSTP(div6_clks[DIV6_SUB], SMSTPCR1, 16, 0), /* IIC0 */
@@ -498,6 +500,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID(uio_pdrv_genirq.3, mstp_clks[MSTP130]), /* VEU2 */
CLKDEV_DEV_ID(uio_pdrv_genirq.2, mstp_clks[MSTP129]), /* VEU1 */
CLKDEV_DEV_ID(uio_pdrv_genirq.1, mstp_clks[MSTP128]), /* VEU0 */
+   CLKDEV_DEV_ID(sh_mobile_ceu.0, mstp_clks[MSTP127]), /* CEU */
+   CLKDEV_DEV_ID(sh-mobile-csi2.0, mstp_clks[MSTP126]), /* CSI2 */
CLKDEV_DEV_ID(sh-mipi-dsi.0, mstp_clks[MSTP118]), /* DSITX */
CLKDEV_DEV_ID(sh_mobile_lcdc_fb.1, mstp_clks[MSTP117]), /* LCDC1 */
CLKDEV_DEV_ID(i2c-sh_mobile.0, mstp_clks[MSTP116]), /* IIC0 */
-- 
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


[PATCH 3/5] V4L2: soc-camera: export soc-camera bus type for notifications

2010-07-26 Thread Guennadi Liakhovetski
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/video/soc_camera.c |3 ++-
 include/media/soc_camera.h   |3 +++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 475757b..f203293 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1107,13 +1107,14 @@ static int soc_camera_resume(struct device *dev)
return ret;
 }
 
-static struct bus_type soc_camera_bus_type = {
+struct bus_type soc_camera_bus_type = {
.name   = soc-camera,
.probe  = soc_camera_probe,
.remove = soc_camera_remove,
.suspend= soc_camera_suspend,
.resume = soc_camera_resume,
 };
+EXPORT_SYMBOL_GPL(soc_camera_bus_type);
 
 static struct device_driver ic_drv = {
.name   = camera,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index b8289c2..2ce9573 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -12,12 +12,15 @@
 #ifndef SOC_CAMERA_H
 #define SOC_CAMERA_H
 
+#include linux/device.h
 #include linux/mutex.h
 #include linux/pm.h
 #include linux/videodev2.h
 #include media/videobuf-core.h
 #include media/v4l2-device.h
 
+extern struct bus_type soc_camera_bus_type;
+
 struct soc_camera_device {
struct list_head list;
struct device dev;
-- 
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


[PATCH 4/5] V4L2: soc-camera: add a MIPI CSI-2 driver for SH-Mobile platforms

2010-07-26 Thread Guennadi Liakhovetski
Some SH-Mobile SoCs implement a MIPI CSI-2 controller, that can interface to
several video clients and send data to the CEU or to the Image Signal
Processor.  This patch implements a v4l2-subdevice driver for CSI-2 to be used
within the soc-camera framework, implementing the second subdevice in addition
to the actual video clients.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
 drivers/media/video/Kconfig  |6 +
 drivers/media/video/Makefile |1 +
 drivers/media/video/sh_mobile_csi2.c |  354 ++
 include/media/sh_mobile_csi2.h   |   46 +
 4 files changed, 407 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/sh_mobile_csi2.c
 create mode 100644 include/media/sh_mobile_csi2.h

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..4595eb9 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -955,6 +955,12 @@ config VIDEO_PXA27x
---help---
  This is a v4l2 driver for the PXA27x Quick Capture Interface
 
+config VIDEO_SH_MOBILE_CSI2
+   tristate SuperH Mobile MIPI CSI-2 Interface driver
+   depends on VIDEO_DEV  SOC_CAMERA  HAVE_CLK
+   ---help---
+ This is a v4l2 driver for the SuperH MIPI CSI-2 Interface
+
 config VIDEO_SH_MOBILE_CEU
tristate SuperH Mobile CEU Interface driver
depends on VIDEO_DEV  SOC_CAMERA  HAS_DMA  HAVE_CLK
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..79df307 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_SOC_CAMERA_PLATFORM)   += soc_camera_platform.o
 obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
 obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
 obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
+obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o
 obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)  += sh_mobile_ceu_camera.o
 
 obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/media/video/sh_mobile_csi2.c 
b/drivers/media/video/sh_mobile_csi2.c
new file mode 100644
index 000..c71adf6
--- /dev/null
+++ b/drivers/media/video/sh_mobile_csi2.c
@@ -0,0 +1,354 @@
+/*
+ * Driver for the SH-Mobile MIPI CSI-2 unit
+ *
+ * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/io.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/slab.h
+#include linux/videodev2.h
+
+#include media/sh_mobile_csi2.h
+#include media/soc_camera.h
+#include media/v4l2-common.h
+#include media/v4l2-dev.h
+#include media/v4l2-device.h
+#include media/v4l2-mediabus.h
+#include media/v4l2-subdev.h
+
+#define SH_CSI2_TREF   0x00
+#define SH_CSI2_SRST   0x04
+#define SH_CSI2_PHYCNT 0x08
+#define SH_CSI2_CHKSUM 0x0C
+#define SH_CSI2_VCDT   0x10
+
+struct sh_csi2 {
+   struct v4l2_subdev  subdev;
+   struct list_headlist;
+   struct notifier_block   notifier;
+   unsigned intirq;
+   void __iomem*base;
+   struct platform_device  *pdev;
+   struct sh_csi2_client_config*client;
+};
+
+static int sh_csi2_try_fmt(struct v4l2_subdev *sd,
+  struct v4l2_mbus_framefmt *mf)
+{
+   struct sh_csi2 *priv = container_of(sd, struct sh_csi2, subdev);
+   struct sh_csi2_pdata *pdata = priv-pdev-dev.platform_data;
+
+   if (mf-width  8188)
+   mf-width = 8188;
+   else if (mf-width  1)
+   mf-width = ~1;
+
+   switch (pdata-type) {
+   case SH_CSI2C:
+   switch (mf-code) {
+   case V4L2_MBUS_FMT_YUYV8_2X8_BE:/* YUV422 */
+   case V4L2_MBUS_FMT_YUYV8_1_5X8: /* YUV420 */
+   case V4L2_MBUS_FMT_GREY8_1X8:   /* RAW8 */
+   case V4L2_MBUS_FMT_SBGGR8_1X8:
+   case V4L2_MBUS_FMT_SGRBG8_1X8:
+   break;
+   default:
+   /* All MIPI CSI-2 devices must support one of primary 
formats */
+   mf-code = V4L2_MBUS_FMT_YUYV8_2X8_LE;
+   }
+   break;
+   case SH_CSI2I:
+   switch (mf-code) {
+   case V4L2_MBUS_FMT_GREY8_1X8:   /* RAW8 */
+   case V4L2_MBUS_FMT_SBGGR8_1X8:
+   case V4L2_MBUS_FMT_SGRBG8_1X8:
+   case V4L2_MBUS_FMT_SBGGR10_1X10:/* RAW10 */
+   case V4L2_MBUS_FMT_SBGGR12_1X12:/* RAW12 */
+   break;
+   default:
+   /* All MIPI CSI-2 devices must support one of 

Re: [RFC/PATCH v2 06/10] media: Entities, pads and links enumeration

2010-07-26 Thread Laurent Pinchart
Hi Pete,

On Thursday 22 July 2010 18:36:51 Pete Eberlein wrote:
 On Thu, 2010-07-22 at 17:20 +0200, Laurent Pinchart wrote:
   Laurent Pinchart wrote:
   
   ...
   
diff --git a/Documentation/media-framework.txt
b/Documentation/media-framework.txt index 3acc62b..16c0177 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -270,3 +270,137 @@ required, drivers don't need to provide a
set_power
  
  [snip]
  
+The media_user_pad, media_user_link and media_user_links structure
are defined
+as
   
   I have a comment on naming. These are user space structures, sure, but
   do we want that fact to be visible in the names of the structures? I
   would just drop the user_ out and make the naming as good as possible
   in user space. That is much harder to change later than naming inside
   the kernel.
  
  I agree.
  
   That change causes a lot of clashes in naming since the equivalent
   kernel structure is there as well. Those could have _k postfix, for
   example, to differentiate them from user space names. I don't really
   have a good suggestion how they should be called.
  
  Maybe media_k_* ? I'm not very happy with that name either though.
 
 What do you think about a single underscore prefix for the kernel
 structures, used commonly to indicate that a declaration is limited?

The underscore is usually used for internal functions/variables. I'd rather go 
for _k, I think it's more obvious.

-- 
Regards,

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


Re: [RFC/PATCH v2 06/10] media: Entities, pads and links enumeration

2010-07-26 Thread Laurent Pinchart
Hi Sakari,

On Thursday 22 July 2010 19:30:21 Sakari Ailus wrote:
 Laurent Pinchart wrote:
  +
  +struct media_user_pad {
  + __u32 entity;   /* entity ID */
  + __u8 index; /* pad index */
  + __u32 direction;/* pad direction */
  +};
  
  Another small comment, I think you mentioned it yourself some time back
  
  :-): how about some reserved fields to these structures?
  
  Very good point. Reserved fields are needed in media_user_entity and
  media_user_links at least. For media_user_pad and media_user_link, we
  could do without reserved fields if we add fields to media_user_links to
  store the size of those structures.
 
 The structure size is part of the ioctl number defined by the _IOC macro

Not in this case, the ioctl uses a structure that stores pointers to the links 
and pads arrays.

 so I'd go with reserved fields even for these structures. Otherwise
 special handling would be required for these ioctls in a few places.

A few reserved links would still be good, yes.

-- 
Regards,

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


Re: [RFC/PATCH v2 06/10] media: Entities, pads and links enumeration

2010-07-26 Thread Laurent Pinchart
Hi Hans,

On Saturday 24 July 2010 14:45:39 Hans Verkuil wrote:
 On Wednesday 21 July 2010 16:35:31 Laurent Pinchart wrote:
  Create the following two ioctls and implement them at the media device
  level to enumerate entities, pads and links.
  
  - MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties
  - MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity
  
  Entity IDs can be non-contiguous. Userspace applications should
  enumerate entities using the MEDIA_ENTITY_ID_FLAG_NEXT flag. When the
  flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return
  the next entity with an ID bigger than the requested one.
  
  Only forward links that originate at one of the entity's source pads are
  returned during the enumeration process.
  
  Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
  Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
  ---
  
   Documentation/media-framework.txt |  134
    drivers/media/media-device.c  | 
   153 + include/linux/media.h
   |   73 ++
   include/media/media-device.h  |3 +
   include/media/media-entity.h  |   19 +-
   5 files changed, 364 insertions(+), 18 deletions(-)
   create mode 100644 include/linux/media.h
 
 snip
 
  diff --git a/include/linux/media.h b/include/linux/media.h
  new file mode 100644
  index 000..746bdda
  --- /dev/null
  +++ b/include/linux/media.h
  @@ -0,0 +1,73 @@
  +#ifndef __LINUX_MEDIA_H
  +#define __LINUX_MEDIA_H
  +
  +#define MEDIA_ENTITY_TYPE_NODE 1
  +#define MEDIA_ENTITY_TYPE_SUBDEV   2
  +
  +#define MEDIA_ENTITY_SUBTYPE_NODE_V4L  1
  +#define MEDIA_ENTITY_SUBTYPE_NODE_FB   2
  +#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA 3
  +#define MEDIA_ENTITY_SUBTYPE_NODE_DVB  4
  +
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER1
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER2
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC   3
  +
  +#define MEDIA_PAD_DIR_INPUT1
  +#define MEDIA_PAD_DIR_OUTPUT   2
  +
  +#define MEDIA_LINK_FLAG_ACTIVE (1  0)
  +#define MEDIA_LINK_FLAG_IMMUTABLE  (1  1)
  +
  +#define MEDIA_ENTITY_ID_FLAG_NEXT  (1  31)
  +
  +struct media_user_pad {
  +   __u32 entity;   /* entity ID */
  +   __u8 index; /* pad index */
  +   __u32 direction;/* pad direction */
  +};
 
 How about:
 
 struct media_pad {
   __u32 entity;   /* entity ID */
   __u16 index;/* pad index */
   __u16 flags;/* pad flags (includes direction) */

Just to be sure, I suppose I should combine flags + direction in the 
media_k_pad structure as well, right ?

   u32 reserved;
 };

OK.

 I think u16 for the number of pads might be safer than a u8.

it should definitely be enough, otherwise we'll have a big issue anyway.

  +
  +struct media_user_entity {
  +   __u32 id;
  +   char name[32];
  +   __u32 type;
  +   __u32 subtype;
  +   __u8 pads;
  +   __u32 links;
 
 Need reserved fields.

OK.

  +
  +   union {
  +   /* Node specifications */
  +   struct {
  +   __u32 major;
  +   __u32 minor;
  +   } v4l;
  +   struct {
  +   __u32 major;
  +   __u32 minor;
  +   } fb;
  +   int alsa;
  +   int dvb;
  +
  +   /* Sub-device specifications */
  +   /* Nothing needed yet */
 
 Add something like:
 
   __u8 raw[64];

OK.

 
  +   };
  +};
  +
  +struct media_user_link {
  +   struct media_user_pad source;
  +   struct media_user_pad sink;
  +   __u32 flags;
 
 Add a single __u32 reserved.

OK.

  +};
  +
  +struct media_user_links {
  +   __u32 entity;
  +   /* Should have enough room for pads elements */
  +   struct media_user_pad __user *pads;
  +   /* Should have enough room for links elements */
  +   struct media_user_link __user *links;
 
 Add a  __u32 reserved[4].

OK.

  +};
  +
  +#define MEDIA_IOC_ENUM_ENTITIES_IOWR('M', 1, struct media_user_entity)
  +#define MEDIA_IOC_ENUM_LINKS   _IOWR('M', 2, struct 
  media_user_links)
 
 We also need a MEDIA_IOC_QUERYCAP or MEDIA_IOC_VERSION or something like
 that.



-- 
Regards,

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


Re: [RFC/PATCH v2 03/10] media: Entities, pads and links

2010-07-26 Thread Laurent Pinchart
Hi Hans,

On Saturday 24 July 2010 14:18:11 Hans Verkuil wrote:
 On Wednesday 21 July 2010 16:35:28 Laurent Pinchart wrote:
 
 snip
 
  diff --git a/include/media/media-entity.h b/include/media/media-entity.h
  new file mode 100644
  index 000..fd44647
  --- /dev/null
  +++ b/include/media/media-entity.h
  @@ -0,0 +1,79 @@
  +#ifndef _MEDIA_ENTITY_H
  +#define _MEDIA_ENTITY_H
  +
  +#include linux/list.h
  +
  +#define MEDIA_ENTITY_TYPE_NODE 1
  +#define MEDIA_ENTITY_TYPE_SUBDEV   2
  +
  +#define MEDIA_ENTITY_SUBTYPE_NODE_V4L  1
  +#define MEDIA_ENTITY_SUBTYPE_NODE_FB   2
  +#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA 3
  +#define MEDIA_ENTITY_SUBTYPE_NODE_DVB  4
  +
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER1
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER2
  +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC   3
 
 These names are too awkward.
 
 I see two options:
 
 1) Rename the type field to 'entity' and the macros to
 MEDIA_ENTITY_NODE/SUBDEV. Also rename subtype to type and the macros to
 MEDIA_ENTITY_TYPE_NODE_V4L and MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER. We
 might even get away with dropping _TYPE from the macro name.
 
 2) Merge type and subtype to a single entity field. The top 16 bits are the
 entity type, the bottom 16 bits are the subtype. That way you end up with:
 
 #define MEDIA_ENTITY_NODE (1  16)
 #define MEDIA_ENTITY_SUBDEV   (2  16)
 
 #define MEDIA_ENTITY_NODE_V4L (MEDIA_ENTITY_NODE + 1)
 
 #define MEDIA_ENTITY_SUBDEV_VID_DECODER   (MEDIA_ENTITY_SUBDEV + 
 1)
 
 I rather like this option myself.

I like option 2 better, but I would keep the field name type instead of 
entity. Constants could start with MEDIA_ENTITY_TYPE_, or just MEDIA_ENTITY_ 
(I think I would prefer MEDIA_ENTITY_TYPE_).

  +
  +#define MEDIA_LINK_FLAG_ACTIVE (1  0)
  +#define MEDIA_LINK_FLAG_IMMUTABLE  (1  1)
  +
  +#define MEDIA_PAD_DIR_INPUT1
  +#define MEDIA_PAD_DIR_OUTPUT   2
  +
  +struct media_entity_link {
  +   struct media_entity_pad *source;/* Source pad */
  +   struct media_entity_pad *sink;  /* Sink pad  */
  +   struct media_entity_link *other;/* Link in the reverse direction */
  +   u32 flags;  /* Link flags (MEDIA_LINK_FLAG_*) */
  +};
  +
  +struct media_entity_pad {
  +   struct media_entity *entity;/* Entity this pad belongs to */
  +   u32 direction;  /* Pad direction (MEDIA_PAD_DIR_*) */
  +   u8 index;   /* Pad index in the entity pads array */
 
 We can use bitfields for direction and index. That way we can also easily
 add other flags/attributes.

You proposed to merge the direction field into a new flags field, I suppose 
that should be done here too for consistency. Having 16 flags might be a bit 
low though, 32 would be better. If you want to keep 16 bits for now, maybe we 
should have 2 reserved __u32 instead of one.

  +};
  +

-- 
Regards,

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


Re: [PATCH] IR/imon: remove incorrect calls to input_free_device

2010-07-26 Thread Dmitry Torokhov
On Mon, Jul 26, 2010 at 10:13:52AM -0400, Jarod Wilson wrote:
 Per Dmitry Torokhov (in a completely unrelated thread on linux-input),
 following input_unregister_device with an input_free_device is
 forbidden, the former is sufficient alone.
 
 CC: Dmitry Torokhov dmitry.torok...@gmail.com
 Signed-off-by: Jarod Wilson ja...@redhat.com

Acked-by: Dmitry Torokhov d...@mail.ru

Random notes about irmon:

imon_init_idev():
memcpy(ir-dev, ictx-dev, sizeof(struct device));

This is... scary.  Devices are refcounted and if you copy them around
all hell may break loose. On an unrelated note you do not need memcpy to
copy a structire, *it-dev = *ictx-dev will do.

imon_init_idev(), imon_init_touch(): - consizer returning proper error
codes via ERR_PTR() and check wit IS_ERR().

 ---
  drivers/media/IR/imon.c |5 +
  1 files changed, 1 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
 index 0195dd5..08dff8c 100644
 --- a/drivers/media/IR/imon.c
 +++ b/drivers/media/IR/imon.c
 @@ -1944,7 +1944,6 @@ static struct imon_context *imon_init_intf0(struct 
 usb_interface *intf)
  
  urb_submit_failed:
   ir_input_unregister(ictx-idev);
 - input_free_device(ictx-idev);
  idev_setup_failed:
  find_endpoint_failed:
   mutex_unlock(ictx-lock);
 @@ -2014,10 +2013,8 @@ static struct imon_context *imon_init_intf1(struct 
 usb_interface *intf,
   return ictx;
  
  urb_submit_failed:
 - if (ictx-touch) {
 + if (ictx-touch)
   input_unregister_device(ictx-touch);
 - input_free_device(ictx-touch);
 - }
  touch_setup_failed:
  find_endpoint_failed:
   mutex_unlock(ictx-lock);

Thanks.

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


Re: tm6000 bad marge staging/tm6000 into staging/all

2010-07-26 Thread Mauro Carvalho Chehab
Em 26-07-2010 12:17, Stefan Ringel escreveu:
  Am 25.07.2010 19:58, schrieb Mauro Carvalho Chehab:
 Em 25-07-2010 04:28, Stefan Ringel escreveu:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Mauro,

 This marge are wrong! It's added double dvb led off, but my patch has
 only ones.

 raw | combined (merge: 011906d 6e5e76f)

 Merge branch 'staging/tm6000' into staging/all
 Mauro Carvalho Chehab [Sun, 4 Jul 2010 19:33:26 + (16:33 -0300)]

 break every clone of my tree.
 cannot found staging/all.

Sorry, I meant staging/other. staging/all is an internal temporary branch I used
locally.

Cheers,
Mauro

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


Re: [Q]: any DVB-S2 card which is 45MS/s capable?

2010-07-26 Thread Emmanuel

Goga777 a écrit :
If someone has tested a DVB-S2 card at 45MS/s (I am interested in QPSK 
moslty) please speak out ;-).

I dont need CI, dual tuner can be a bonus but definitely not mandatory.
I already asked the question, so sorry to come back again with it, but I 
did not get a clear answer: the only thing I know is that STV0900 is 
able to do it, but I guess that the board itself must be well thought 
out to achieve these high rates?




my hvr4000 card works well with dvb-s transponder with so high SR - 44950
see tp 11044 on http://www.lyngsat.com/eam22.html

also, no any problems with dvb-s2 tp with SR 3
  
Yes that I know, dvb-s up to 45MS/s is OK though I cant test that here, 
but DVB-S2 is limited to 3 whereas I have one tp here which is 
DVB-S2, QPSK, FEC 5/6 at 45MS/s.
This is why I am looking for a dvb card which is able to tune to these 
(presumably) extreme rates.

Bye
Manu
--
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] IR/imon: remove incorrect calls to input_free_device

2010-07-26 Thread Jarod Wilson
On Mon, Jul 26, 2010 at 1:34 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Mon, Jul 26, 2010 at 10:13:52AM -0400, Jarod Wilson wrote:
 Per Dmitry Torokhov (in a completely unrelated thread on linux-input),
 following input_unregister_device with an input_free_device is
 forbidden, the former is sufficient alone.

 CC: Dmitry Torokhov dmitry.torok...@gmail.com
 Signed-off-by: Jarod Wilson ja...@redhat.com

 Acked-by: Dmitry Torokhov d...@mail.ru

 Random notes about irmon:

 imon_init_idev():
        memcpy(ir-dev, ictx-dev, sizeof(struct device));

 This is... scary.  Devices are refcounted and if you copy them around
 all hell may break loose. On an unrelated note you do not need memcpy to
 copy a structire, *it-dev = *ictx-dev will do.

 imon_init_idev(), imon_init_touch(): - consizer returning proper error
 codes via ERR_PTR() and check wit IS_ERR().

Hm, I'm overdue to give that driver another look (bz.k.o #16351), will
add looking at these to the TODO list... (have immortalized them in
the bz).


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


RE: [RFC 0/8] TI TILER-DMM driver

2010-07-26 Thread Sin, David
Thanks, Santosh, for your comments.  I will roll them into an RFC v2.

Also, adding the media list...

-David

-Original Message-
From: Shilimkar, Santosh 
Sent: Saturday, July 24, 2010 2:45 AM
To: Sin, David; linux-arm-ker...@lists.arm.linux.org.uk; 
linux-o...@vger.kernel.org; Tony Lindgren; Russell King
Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Cousson, Benoit
Subject: RE: [RFC 0/8] TI TILER-DMM driver

David, 
 -Original Message-
 From: Sin, David
 Sent: Saturday, July 24, 2010 4:52 AM
 To: linux-arm-ker...@lists.arm.linux.org.uk; linux-o...@vger.kernel.org;
 Tony Lindgren; Russell King
 Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh;
 Sin, David
 Subject: [RFC 0/8] TI TILER-DMM driver
 
 TILER is a hardware block made by Texas Instruments.  Its purpose is to
 organize video/image memory in a 2-dimensional fashion to limit memory
 bandwidth and facilitate 0 effort rotation and mirroring.  The TILER
 driver facilitates allocating, freeing, as well as mapping 2D blocks
 (areas)
 in the TILER container(s).  It also facilitates rotating and mirroring
 the allocated blocks or its rectangular subsections.
 
 List of pending items in proposed order:
 
 * Add area packing support (multiple blocks can reside in the same
 band/area)
   to optimize area use
 * Add group-ID support (to specify which blocks can reside together in the
   same area)
 * Add multiple search directions to TCM-SiTA
 * Add 1D block support (including adding 1D search algo to TCM-SiTA)
 * Optimize mutex handling (don.t hold mutex during memory
   allocation/mapping/cache flushing)
 * Add block reference counting, support for sharing blocks
 * Move all kernel-API-s to tiler-iface.c
 * Support orphaned block support (in preparation for process cleanup
 support)
 * Change block identification from physical address to key-ID pair
   (in preparation for user space support, and process security)
 * Add support for process security (blocks from separate processes never
   reside in the same band)
 * Support file interface (ioctl and mmap)
 * Support for buffers (ordered list of blocks that are mapped to userspace
   together, such as YUV420sp)
 * Support 1D user buffer mapping into TILER container
 * Support for block pre-reservation (to further optimize area use)
 
 David Sin (1):
   TILER-DMM: DMM-PAT driver for TI TILER
 
 Lajos Molnar (6):
   TILER-DMM: Container manager interface and utility definitons
   TILER-DMM: TILER Memory Manager interface and implementation
   TILER-DMM: TILER interface file and documentation
   TILER-DMM: Geometry and view manipulation functions.
   TILER-DMM: Main TILER driver implementation.
   TILER-DMM: Linking TILER driver into the Linux kernel build
 
 Ravi Ramachandra (1):
   TILER-DMM: Sample TCM implementation: Simple TILER Allocator
 
I am just summarizing some of my comments here

1. linux-arm-ker...@lists.arm.linux.org.uk is not operational anymore. The
current list is linux-arm-ker...@lists.infradead.org

2. Thanks for the Documentation patch. Just take care of correct directory for 
same

3. iormap on RAM will be prohibited. Russell has a patch in the queue so
we need to look at the alternative.
4. You haven't implemented probe fuction in both of your diver and doing
all work in init itself. You might want to revisit that

5. DMM register info is auto-generated thanks to Benoit. We can use that 
directly.

6. There are too many header files(8-9) and I think you can re-organise all of 
them to manage with 3-4

7. Commenting style is not consistent in all patches and does not follow
linux style in few places

8. The DMM driver registration can be done using omap_device framework as
is being done for most of the OMAP4 drivers.

9. Error handling can be improved

10. There is an excessive usage of barriers and may be we can keep 
only the necessary ones.

Thanks for the tiler port.

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


RE: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

2010-07-26 Thread Sin, David
Thanks, Russel, for your comments.  I will rework the RFC and send out a v2 
soon.  

-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] 
Sent: Saturday, July 24, 2010 3:09 AM
To: Sin, David
Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-o...@vger.kernel.org; Tony 
Lindgren; Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, 
Santosh; Molnar, Lajos
Subject: Re: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

On Fri, Jul 23, 2010 at 06:22:21PM -0500, David Sin wrote:
 +static struct platform_driver dmm_driver_ldm = {
 + .driver = {
 + .owner = THIS_MODULE,
 + .name = dmm,
 + },
 + .probe = NULL,
 + .shutdown = NULL,
 + .remove = NULL,
 +};

What's the point of this driver structure? [dhs] -- This is pretty much 
incomplete.  I will revist this based on the suggestions you and Santosh have 
given in the other e-mail replies. 

 +s32 dmm_pat_refill(struct dmm *dmm, struct pat *pd, enum pat_mode mode)
 +{
 + void __iomem *r;
 + u32 v;
 +
 + /* Only manual refill supported */
 + if (mode != MANUAL)
 + return -EFAULT;
 +
 + /* Check that the DMM_PAT_STATUS register has not reported an error */
 + r = dmm-base + DMM_PAT_STATUS__0;
 + v = __raw_readl(r);
 + if (WARN(v  0xFC00, KERN_ERR dmm_pat_refill() error.\n))
 + return -EIO;
 +
 + /* Set next register to NULL */
 + r = dmm-base + DMM_PAT_DESCR__0;
 + v = __raw_readl(r);
 + v = SET_FLD(v, 31, 4, (u32) NULL);
 + __raw_writel(v, r);
 +
 + /* Set area to be refilled */
 + r = dmm-base + DMM_PAT_AREA__0;
 + v = __raw_readl(r);
 + v = SET_FLD(v, 30, 24, pd-area.y1);
 + v = SET_FLD(v, 23, 16, pd-area.x1);
 + v = SET_FLD(v, 14, 8, pd-area.y0);
 + v = SET_FLD(v, 7, 0, pd-area.x0);
 + __raw_writel(v, r);
 + wmb();

Maybe use writel() (which will contain the barrier _before_ the write op.) 
[dhs] -- I didn't know this.  Thanks for this input.

 +
 + /* First, clear the DMM_PAT_IRQSTATUS register */
 + r = dmm-base + DMM_PAT_IRQSTATUS;
 + __raw_writel(0x, r);
 + wmb();

And consider using:
writel(0x, dmm-base + DMM_PAT_IRQSTATUS);

In any case, writes to devices are ordered, so there's no real need to
add barriers between each write - in which case writel_relaxed() or
__raw_writel() can be used (which'll be added soon.) [dhs] -- OK, will 
incorporate in RFC v2.

 +
 + r = dmm-base + DMM_PAT_IRQSTATUS_RAW;
 + while (__raw_readl(r) != 0)
 + ;

It's normal to use cpu_relax() in busy-wait loops.  What if the IRQ status
never becomes zero? [dhs] -- I will revist this as well.

 +MODULE_LICENSE(GPL v2);
 +MODULE_AUTHOR(david...@ti.com);
 +MODULE_AUTHOR(mol...@ti.com);

MODULE_AUTHOR(Name email); or just MODULE_AUTHOR(Name);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [RFC 3/8] TILER-DMM: Sample TCM implementation: Simple TILER Allocator

2010-07-26 Thread Sin, David
Comments acknowledged.  Adding in media lists also.

-David

-Original Message-
From: Shilimkar, Santosh
Sent: Saturday, July 24, 2010 2:13 AM
To: Sin, David; linux-arm-ker...@lists.arm.linux.org.uk; 
linux-o...@vger.kernel.org; Tony Lindgren; Russell King
Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Ramachandra, Ravikiran; 
Molnar, Lajos
Subject: RE: [RFC 3/8] TILER-DMM: Sample TCM implementation: Simple TILER 
Allocator

 -Original Message-
 From: Sin, David
 Sent: Saturday, July 24, 2010 4:52 AM
 To: linux-arm-ker...@lists.arm.linux.org.uk; linux-o...@vger.kernel.org;
 Tony Lindgren; Russell King
 Cc: Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, Santosh;
 Ramachandra, Ravikiran; Molnar, Lajos; Sin, David
 Subject: [RFC 3/8] TILER-DMM: Sample TCM implementation: Simple TILER
 Allocator

 From: Ravi Ramachandra r.ramachan...@ti.com

 This patch implements a simple TILER Container Manager.

 Signed-off-by: Ravi Ramachandra r.ramachan...@ti.com
 Signed-off-by: Lajos Molnar mol...@ti.com
 Signed-off-by: David Sin david...@ti.com
 ---
  drivers/media/video/tiler/tcm/Makefile|1 +
  drivers/media/video/tiler/tcm/_tcm-sita.h |   64 
Why is such a header file name. Can't you club
  drivers/media/video/tiler/tcm/tcm-sita.c  |  459
 +
  drivers/media/video/tiler/tcm/tcm-sita.h  |   37 +++
You should club _tcm-sita.h and tcm-sita.h together
  4 files changed, 561 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/tiler/tcm/Makefile
  create mode 100644 drivers/media/video/tiler/tcm/_tcm-sita.h
  create mode 100644 drivers/media/video/tiler/tcm/tcm-sita.c
  create mode 100644 drivers/media/video/tiler/tcm/tcm-sita.h

 diff --git a/drivers/media/video/tiler/tcm/Makefile
 b/drivers/media/video/tiler/tcm/Makefile
 new file mode 100644
 index 000..8434607
 --- /dev/null
 +++ b/drivers/media/video/tiler/tcm/Makefile
 @@ -0,0 +1 @@
 +obj-$(CONFIG_TI_TILER) += tcm-sita.o
 diff --git a/drivers/media/video/tiler/tcm/_tcm-sita.h
 b/drivers/media/video/tiler/tcm/_tcm-sita.h
 new file mode 100644
 index 000..4ede1ab
 --- /dev/null
 +++ b/drivers/media/video/tiler/tcm/_tcm-sita.h
 @@ -0,0 +1,64 @@
 +/*
 + * _tcm_sita.h
 + *
 + * SImple Tiler Allocator (SiTA) private structures.
 + *
 + * Author: Ravi Ramachandra r.ramachan...@ti.com
 + *
 + * Copyright (C) 2009-2010 Texas Instruments, Inc.
 + *
 + * This package is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 + */
 +
 +#ifndef _TCM_SITA_H
 +#define _TCM_SITA_H
 +
 +#include ../tcm.h
Header inclusion
 +
 +/* length between two coordinates */
 +#define LEN(a, b) ((a)  (b) ? (a) - (b) + 1 : (b) - (a) + 1)
 +
 +enum criteria {
 + CR_MAX_NEIGHS   = 0x01,
 + CR_FIRST_FOUND  = 0x10,
 + CR_BIAS_HORIZONTAL  = 0x20,
 + CR_BIAS_VERTICAL= 0x40,
 + CR_DIAGONAL_BALANCE = 0x80
 +};
 +
 +/* nearness to the beginning of the search field from 0 to 1000 */
 +struct nearness_factor {
 + s32 x;
 + s32 y;
 +};
 +
 +/*
 + * Statistics on immediately neighboring slots.  Edge is the number of
 + * border segments that are also border segments of the scan field.  Busy
 + * refers to the number of neighbors that are occupied.
 + */
 +struct neighbor_stats {
 + u16 edge;
 + u16 busy;
 +};
 +
 +/* structure to keep the score of a potential allocation */
 +struct score {
 + struct nearness_factor  f;
 + struct neighbor_stats   n;
 + struct tcm_area a;
 + u16neighs;  /* number of busy neighbors */
 +};
 +
 +struct sita_pvt {
 + struct mutex mtx;
 + struct tcm_area ***map; /* pointers to the parent area for each slot
 */
 +};
 +
 +#endif
 diff --git a/drivers/media/video/tiler/tcm/tcm-sita.c
 b/drivers/media/video/tiler/tcm/tcm-sita.c
 new file mode 100644
 index 000..93be3e6
 --- /dev/null
 +++ b/drivers/media/video/tiler/tcm/tcm-sita.c
 @@ -0,0 +1,459 @@
 +/*
 + * tcm-sita.c
 + *
 + * SImple Tiler Allocator (SiTA): 2D and 1D allocation(reservation)
 algorithm
 + *
 + * Authors: Ravi Ramachandra r.ramachan...@ti.com,
 + *  Lajos Molnar mol...@ti.com
 + *
 + * Copyright (C) 2009-2010 Texas Instruments, Inc.
 + *
 + * This package is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 + *
 + */
 +#include linux/slab.h
 

RE: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and implementation

2010-07-26 Thread Sin, David
OK -- I will revisit this.  Thanks for the explanation.

-David

-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] 
Sent: Saturday, July 24, 2010 3:01 AM
To: Sin, David
Cc: linux-arm-ker...@lists.arm.linux.org.uk; linux-o...@vger.kernel.org; Tony 
Lindgren; Kanigeri, Hari; Ohad Ben-Cohen; Hiremath, Vaibhav; Shilimkar, 
Santosh; Molnar, Lajos
Subject: Re: [RFC 4/8] TILER-DMM: TILER Memory Manager interface and 
implementation

On Fri, Jul 23, 2010 at 06:22:24PM -0500, David Sin wrote:
 +/* allocate and flush a page */
 +static struct mem *alloc_mem(void)
 +{
 + struct mem *m = kzalloc(sizeof(*m), GFP_KERNEL);
 + if (!m)
 + return NULL;
 +
 + m-pg = alloc_page(GFP_KERNEL | GFP_DMA);
 + if (!m-pg) {
 + kfree(m);
 + return NULL;
 + }
 +
 + m-pa = page_to_phys(m-pg);
 +
 + /* flush the cache entry for each page we allocate. */
 + dmac_flush_range(page_address(m-pg),
 + page_address(m-pg) + PAGE_SIZE);
 + outer_flush_range(m-pa, m-pa + PAGE_SIZE);

NAK.  This is an abuse of these interfaces, and is buggy in any case.

ARMv6 and ARMv7 CPUs speculatively prefetch memory, which means that
there's no guarantee that if you flush the caches for a particular
range of virtual space, that it will stay flushed until you decide
to read it.  So flushing the caches in some memory allocator can't
guarantee that when you eventually get around to using the page that
there won't be cache lines associated with it.
--
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-26 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:Mon Jul 26 19:05:02 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14993:9652f85e688a
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328
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/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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: [SAMPLE v2 04/12] v4l-subdev: Add pads operations

2010-07-26 Thread Hans Verkuil
On Monday 26 July 2010 18:12:55 Laurent Pinchart wrote:
 On Friday 23 July 2010 17:56:02 Karicheri, Muralidharan wrote:
  Laurent,
  
  Could you explain the probe and active usage using an example such as
  below?
  
  Link1Link2
  input sensor - ccdc - video node.
  
  Assume Link2 we can have either format 1 or format 2 for capture.
 
 Sure.
 
 The probe and active formats are used to probe supported formats and 
 getting/setting active formats.

Just to verify: we are dealing with mediabus formats here, right?

One thing that I don't like is the name 'probe'. I would prefer the name
'proposed'. You propose an input format and based on that you can enumerate
a list of proposed output format. I think that name fits better than 'probe'
which I find confusing in this context.

 
 * Enumerating supported formats on the CCDC input and output would be done 
 with the following calls
 
 ENUM_FMT(CCDC input pad)
 
 for the input, and
 
 S_FMT(PROBE, CCDC input pad, format)
 ENUM_FMT(CCDC output pad)
 
 for the output.

How does ENUM_FMT know if it has to use the proposed or actual input formats?
Or is it supposed to always act on proposed formats?

 
 Setting the probe format on the input pad is required, as the format on an 
 output pad usually depends on the format on input pads.
 
 * Trying a format on the CCDC input and output would be done with
 
 S_FMT(PROBE, CCDC input pad, format)
 
 for the input, and
 
 S_FMT(PROBE, CCDC input pad, format)
 S_FMT(PROBE, CCDC output pad, format)
 
 on the output. The S_FMT call will mangle the format given format if it can't 
 be supported exactly, so there's no need to call G_FMT after S_FMT (a G_FMT 
 call following a S_FMT call will return the same format as the S_FMT call).
 
 * Setting the active format is done with
 
 S_FMT(ACTIVE, CCDC input pad, format)
 S_FMT(ACTIVE, CCDC output pad, format)
 
 The formats will be applied to the hardware (possibly with a delay, drivers 
 can delay register writes until STREAMON for instance).
 
 Probe formats are stored in the subdev file handles, so two applications 
 trying formats at the same time will not interfere with each other. Active 
 formats are stored in the device structure, so modifications done by an 
 application are visible to other applications.
 
 Hope this helps clarifying the API.

You know that I have never been happy with this approach, but I also have to
admit that I haven't found a better way of doing it.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [RFC 0/8] TI TILER-DMM driver

2010-07-26 Thread Sin, David
Thanks for your feedback, Linus.  I will incorporate an acronym list in the 
documentation.  TCM stands for TILER container manager, which pretty much 
represents the interface to the logic which determines the location for a given 
2-D area request.  SiTA (Simple TILER algorithm) is the implementation behind 
that interface.  I will work on revising the acronym to avoid any conflicts.

-David 

-Original Message-
From: Linus Walleij [mailto:linus.ml.wall...@gmail.com] 
Sent: Saturday, July 24, 2010 6:48 PM
To: Sin, David
Cc: linux-arm-ker...@lists.infradead.org
Subject: Re: [RFC 0/8] TI TILER-DMM driver

2010/7/24 David Sin david...@ti.com:

 TILER is a hardware block made by Texas Instruments.  Its purpose is to
 organize video/image memory in a 2-dimensional fashion to limit memory
 bandwidth and facilitate 0 effort rotation and mirroring.  The TILER
 driver facilitates allocating, freeing, as well as mapping 2D blocks (areas)
 in the TILER container(s).  It also facilitates rotating and mirroring
 the allocated blocks or its rectangular subsections.

Pretty cool hardware!

(...)
 * Add multiple search directions to TCM-SiTA
 * Add 1D block support (including adding 1D search algo to TCM-SiTA)

Spell out these acronyms. I've been writing some code for the ARM
TCM (Tightly Coupled Memory) and often vendors pick up this terminology
and call all on-chip memory TCM, though it has a specific technical
meaning in ARM context.

What does TCM mean in your case?
And what is SiTA?

Yours,
Linus Walleij
--
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: [SAMPLE v2 04/12] v4l-subdev: Add pads operations

2010-07-26 Thread Laurent Pinchart
Hi Hans,

On Monday 26 July 2010 21:42:49 Hans Verkuil wrote:
 On Monday 26 July 2010 18:12:55 Laurent Pinchart wrote:
  On Friday 23 July 2010 17:56:02 Karicheri, Muralidharan wrote:
   Laurent,
   
   Could you explain the probe and active usage using an example such as
   below?
   
   Link1Link2
   
   input sensor - ccdc - video node.
   
   Assume Link2 we can have either format 1 or format 2 for capture.
  
  Sure.
  
  The probe and active formats are used to probe supported formats and
  getting/setting active formats.
 
 Just to verify: we are dealing with mediabus formats here, right?

That's correct.

 One thing that I don't like is the name 'probe'. I would prefer the name
 'proposed'. You propose an input format and based on that you can enumerate
 a list of proposed output format. I think that name fits better than
 'probe' which I find confusing in this context.

I'm open to all kind of suggestions. Those patches were not posted for review, 
they're not final yet. They're just sample code.

  * Enumerating supported formats on the CCDC input and output would be
  done with the following calls
  
  ENUM_FMT(CCDC input pad)
  
  for the input, and
  
  S_FMT(PROBE, CCDC input pad, format)
  ENUM_FMT(CCDC output pad)
  
  for the output.
 
 How does ENUM_FMT know if it has to use the proposed or actual input
 formats? Or is it supposed to always act on proposed formats?

Enumeration always uses the probe/proposed formats.

  Setting the probe format on the input pad is required, as the format on
  an output pad usually depends on the format on input pads.
  
  * Trying a format on the CCDC input and output would be done with
  
  S_FMT(PROBE, CCDC input pad, format)
  
  for the input, and
  
  S_FMT(PROBE, CCDC input pad, format)
  S_FMT(PROBE, CCDC output pad, format)
  
  on the output. The S_FMT call will mangle the format given format if it
  can't be supported exactly, so there's no need to call G_FMT after S_FMT
  (a G_FMT call following a S_FMT call will return the same format as the
  S_FMT call).
  
  * Setting the active format is done with
  
  S_FMT(ACTIVE, CCDC input pad, format)
  S_FMT(ACTIVE, CCDC output pad, format)
  
  The formats will be applied to the hardware (possibly with a delay,
  drivers can delay register writes until STREAMON for instance).
  
  Probe formats are stored in the subdev file handles, so two applications
  trying formats at the same time will not interfere with each other.
  Active formats are stored in the device structure, so modifications done
  by an application are visible to other applications.
  
  Hope this helps clarifying the API.
 
 You know that I have never been happy with this approach, but I also have
 to admit that I haven't found a better way of doing it.

Once again I'm open to proposals/discussions/whatever (well, mostly whatever 
:-)). Let's concentrate on the media controller patches first, I'll then 
submit the next set and we'll discuss it.

-- 
Regards,

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


Re: [RFC/PATCH v2 06/10] media: Entities, pads and links enumeration

2010-07-26 Thread Hans Verkuil
On Monday 26 July 2010 18:34:42 Laurent Pinchart wrote:
 Hi Hans,
 
 On Saturday 24 July 2010 14:45:39 Hans Verkuil wrote:
  On Wednesday 21 July 2010 16:35:31 Laurent Pinchart wrote:
   Create the following two ioctls and implement them at the media device
   level to enumerate entities, pads and links.
   
   - MEDIA_IOC_ENUM_ENTITIES: Enumerate entities and their properties
   - MEDIA_IOC_ENUM_LINKS: Enumerate all pads and links for a given entity
   
   Entity IDs can be non-contiguous. Userspace applications should
   enumerate entities using the MEDIA_ENTITY_ID_FLAG_NEXT flag. When the
   flag is set in the entity ID, the MEDIA_IOC_ENUM_ENTITIES will return
   the next entity with an ID bigger than the requested one.
   
   Only forward links that originate at one of the entity's source pads are
   returned during the enumeration process.
   
   Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
   Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
   ---
   
Documentation/media-framework.txt |  134
 drivers/media/media-device.c  | 
153 + include/linux/media.h
|   73 ++
include/media/media-device.h  |3 +
include/media/media-entity.h  |   19 +-
5 files changed, 364 insertions(+), 18 deletions(-)
create mode 100644 include/linux/media.h
  
  snip
  
   diff --git a/include/linux/media.h b/include/linux/media.h
   new file mode 100644
   index 000..746bdda
   --- /dev/null
   +++ b/include/linux/media.h
   @@ -0,0 +1,73 @@
   +#ifndef __LINUX_MEDIA_H
   +#define __LINUX_MEDIA_H
   +
   +#define MEDIA_ENTITY_TYPE_NODE   1
   +#define MEDIA_ENTITY_TYPE_SUBDEV 2
   +
   +#define MEDIA_ENTITY_SUBTYPE_NODE_V4L1
   +#define MEDIA_ENTITY_SUBTYPE_NODE_FB 2
   +#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA   3
   +#define MEDIA_ENTITY_SUBTYPE_NODE_DVB4
   +
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER  1
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER  2
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC 3
   +
   +#define MEDIA_PAD_DIR_INPUT  1
   +#define MEDIA_PAD_DIR_OUTPUT 2
   +
   +#define MEDIA_LINK_FLAG_ACTIVE   (1  0)
   +#define MEDIA_LINK_FLAG_IMMUTABLE(1  1)
   +
   +#define MEDIA_ENTITY_ID_FLAG_NEXT(1  31)
   +
   +struct media_user_pad {
   + __u32 entity;   /* entity ID */
   + __u8 index; /* pad index */
   + __u32 direction;/* pad direction */
   +};
  
  How about:
  
  struct media_pad {
  __u32 entity;   /* entity ID */
  __u16 index;/* pad index */
  __u16 flags;/* pad flags (includes direction) */
 
 Just to be sure, I suppose I should combine flags + direction in the 
 media_k_pad structure as well, right ?

Yes. I think we should just make a u32 flags, use bits 0 and 1 for the direction
and add a simple inline like this:

static inline u8 media_dir(struct media_pad *pad)
{
return pad-flags  MEDIA_PAD_MASK_DIR);
}

And we should use the same for media_k_pad (and make a media_k_dir inline).

 
  u32 reserved;
  };
 
 OK.
 
  I think u16 for the number of pads might be safer than a u8.
 
 it should definitely be enough, otherwise we'll have a big issue anyway.

Is u8 definitely enough or u16? I assume u16.

snip

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RFC/PATCH v2 03/10] media: Entities, pads and links

2010-07-26 Thread Hans Verkuil
On Monday 26 July 2010 18:38:28 Laurent Pinchart wrote:
 Hi Hans,
 
 On Saturday 24 July 2010 14:18:11 Hans Verkuil wrote:
  On Wednesday 21 July 2010 16:35:28 Laurent Pinchart wrote:
  
  snip
  
   diff --git a/include/media/media-entity.h b/include/media/media-entity.h
   new file mode 100644
   index 000..fd44647
   --- /dev/null
   +++ b/include/media/media-entity.h
   @@ -0,0 +1,79 @@
   +#ifndef _MEDIA_ENTITY_H
   +#define _MEDIA_ENTITY_H
   +
   +#include linux/list.h
   +
   +#define MEDIA_ENTITY_TYPE_NODE   1
   +#define MEDIA_ENTITY_TYPE_SUBDEV 2
   +
   +#define MEDIA_ENTITY_SUBTYPE_NODE_V4L1
   +#define MEDIA_ENTITY_SUBTYPE_NODE_FB 2
   +#define MEDIA_ENTITY_SUBTYPE_NODE_ALSA   3
   +#define MEDIA_ENTITY_SUBTYPE_NODE_DVB4
   +
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_DECODER  1
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_VID_ENCODER  2
   +#define MEDIA_ENTITY_SUBTYPE_SUBDEV_MISC 3
  
  These names are too awkward.
  
  I see two options:
  
  1) Rename the type field to 'entity' and the macros to
  MEDIA_ENTITY_NODE/SUBDEV. Also rename subtype to type and the macros to
  MEDIA_ENTITY_TYPE_NODE_V4L and MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER. We
  might even get away with dropping _TYPE from the macro name.
  
  2) Merge type and subtype to a single entity field. The top 16 bits are the
  entity type, the bottom 16 bits are the subtype. That way you end up with:
  
  #define MEDIA_ENTITY_NODE   (1  16)
  #define MEDIA_ENTITY_SUBDEV (2  16)
  
  #define MEDIA_ENTITY_NODE_V4L   (MEDIA_ENTITY_NODE + 1)
  
  #define MEDIA_ENTITY_SUBDEV_VID_DECODER (MEDIA_ENTITY_SUBDEV + 
  1)
  
  I rather like this option myself.
 
 I like option 2 better, but I would keep the field name type instead of 
 entity. Constants could start with MEDIA_ENTITY_TYPE_, or just 
 MEDIA_ENTITY_ 
 (I think I would prefer MEDIA_ENTITY_TYPE_).

Yes, I realized that later as well. Keep the 'type' field name.
I'm not sure about the macro name. I still think 
MEDIA_ENTITY_TYPE_SUBDEV_VID_DECODER
is too much of a mouthful.

 
   +
   +#define MEDIA_LINK_FLAG_ACTIVE   (1  0)
   +#define MEDIA_LINK_FLAG_IMMUTABLE(1  1)
   +
   +#define MEDIA_PAD_DIR_INPUT  1
   +#define MEDIA_PAD_DIR_OUTPUT 2
   +
   +struct media_entity_link {
   + struct media_entity_pad *source;/* Source pad */
   + struct media_entity_pad *sink;  /* Sink pad  */
   + struct media_entity_link *other;/* Link in the reverse direction */
   + u32 flags;  /* Link flags (MEDIA_LINK_FLAG_*) */
   +};
   +
   +struct media_entity_pad {
   + struct media_entity *entity;/* Entity this pad belongs to */
   + u32 direction;  /* Pad direction (MEDIA_PAD_DIR_*) */
   + u8 index;   /* Pad index in the entity pads array */
  
  We can use bitfields for direction and index. That way we can also easily
  add other flags/attributes.
 
 You proposed to merge the direction field into a new flags field, I suppose 
 that should be done here too for consistency. Having 16 flags might be a bit 
 low though, 32 would be better. If you want to keep 16 bits for now, maybe we 
 should have 2 reserved __u32 instead of one.

Yes, let's use a u32 flags field for this.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

2010-07-26 Thread Sin, David
Hi Laurent, 
Thanks for taking the time to review.  These are all very good comments and I 
will work on incorporating them into the next RFC version.
 
-David

-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] 
Sent: Monday, July 26, 2010 3:13 AM
To: linux-arm-ker...@lists.infradead.org
Cc: Sin, David; Molnar, Lajos
Subject: Re: [RFC 1/8] TILER-DMM: DMM-PAT driver for TI TILER

Hi David,

On Saturday 24 July 2010 01:28:07 David Sin wrote:
 This patch adds support for DMM-PAT initialization and programming.
 
 Signed-off-by: David Sin david...@ti.com
 Signed-off-by: Lajos Molnar mol...@ti.com
 ---
  arch/arm/mach-omap2/include/mach/dmm.h |  128 
  drivers/media/video/tiler/dmm.c|  200
  2 files changed, 328 insertions(+), 0
 deletions(-)
  create mode 100644 arch/arm/mach-omap2/include/mach/dmm.h
  create mode 100644 drivers/media/video/tiler/dmm.c
 
 diff --git a/arch/arm/mach-omap2/include/mach/dmm.h
 b/arch/arm/mach-omap2/include/mach/dmm.h new file mode 100644
 index 000..68b798a
 --- /dev/null
 +++ b/arch/arm/mach-omap2/include/mach/dmm.h
 @@ -0,0 +1,128 @@
 +/*
 + * dmm.h
 + *
 + * DMM driver support functions for TI DMM-TILER hardware block.
 + *
 + * Author: David Sin david...@ti.com
 + *
 + * Copyright (C) 2009-2010 Texas Instruments, Inc.
 + *
 + * This package is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + *
 + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 + */
 +
 +#ifndef DMM_H
 +#define DMM_H
 +
 +#define DMM_BASE 0x4E00
 +#define DMM_SIZE 0x800
 +
 +#define DMM_REVISION  0x000
 +#define DMM_HWINFO0x004
 +#define DMM_LISA_HWINFO   0x008
 +#define DMM_DMM_SYSCONFIG 0x010
 +#define DMM_LISA_LOCK 0x01C
 +#define DMM_LISA_MAP__0   0x040
 +#define DMM_LISA_MAP__1   0x044

Why the double _ ?

 +#define DMM_TILER_HWINFO  0x208
 +#define DMM_TILER_OR__0   0x220
 +#define DMM_TILER_OR__1   0x224
 +#define DMM_PAT_HWINFO0x408
 +#define DMM_PAT_GEOMETRY  0x40C
 +#define DMM_PAT_CONFIG0x410
 +#define DMM_PAT_VIEW__0   0x420
 +#define DMM_PAT_VIEW__1   0x424
 +#define DMM_PAT_VIEW_MAP__0   0x440
 +#define DMM_PAT_VIEW_MAP_BASE 0x460
 +#define DMM_PAT_IRQ_EOI   0x478
 +#define DMM_PAT_IRQSTATUS_RAW 0x480
 +#define DMM_PAT_IRQSTATUS 0x490
 +#define DMM_PAT_IRQENABLE_SET 0x4A0
 +#define DMM_PAT_IRQENABLE_CLR 0x4B0
 +#define DMM_PAT_STATUS__0 0x4C0
 +#define DMM_PAT_STATUS__1 0x4C4
 +#define DMM_PAT_STATUS__2 0x4C8
 +#define DMM_PAT_STATUS__3 0x4CC
 +#define DMM_PAT_DESCR__0  0x500
 +#define DMM_PAT_AREA__0   0x504
 +#define DMM_PAT_CTRL__0   0x508
 +#define DMM_PAT_DATA__0   0x50C
 +#define DMM_PEG_HWINFO0x608
 +#define DMM_PEG_PRIO  0x620
 +#define DMM_PEG_PRIO_PAT  0x640
 +
 +/**
 + * PAT refill programming mode.
 + */
 +enum pat_mode {
 + MANUAL,
 + AUTO
 +};

MANUAL and AUTO are pretty generic names to have in the top-level scope. 
Please at least rename them to PAT_MANUAL and PAT_AUTO.

Even better, the pat_ prefix might be better called dmm_pat_, as PAT is 
already used for Physical Address Extension on x86 (granted, the DMM-PAT is 
not likely to be used on x86 platforms).

An explanation of the DMM and PAT acronyms would be nice as well.

 +
 +/**
 + * Area definition for DMM physical address translator.
 + */
 +struct pat_area {
 + s32 x0:8;
 + s32 y0:8;
 + s32 x1:8;
 + s32 y1:8;

What's wrong with four u8 fields ?

 +};
 +
 +/**
 + * DMM physical address translator control.
 + */
 +struct pat_ctrl {
 + s32 start:4;
 + s32 dir:4;
 + s32 lut_id:8;
 + s32 sync:12;
 + s32 ini:4;
 +};
 +
 +/**
 + * PAT descriptor.
 + */
 +struct pat {
 + struct pat *next;
 + struct pat_area area;
 + struct pat_ctrl ctrl;
 + u32 data;
 +};
 +
 +/**
 + * DMM device data
 + */
 +struct dmm {
 + void __iomem *base;
 +};
 +
 +/**
 + * Create and initialize the physical address translator.
 + * @param idPAT id
 + * @return pointer to device data
 + */
 +struct dmm *dmm_pat_init(u32 id);
 +
 +/**
 + * Program the physical address translator.
 + * @param dmm   Device data
 + * @param desc  PAT descriptor
 + * @param mode  programming mode
 + * @return an error status.
 + */
 +s32 dmm_pat_refill(struct dmm *dmm, struct pat *desc, enum pat_mode mode);
 +
 +/**
 + * Clean up the physical address translator.
 + * @param dmmDevice data
 + * @return an error status.
 + */
 +void dmm_pat_release(struct dmm *dmm);
 +
 +#endif
 diff --git a/drivers/media/video/tiler/dmm.c
 b/drivers/media/video/tiler/dmm.c new file mode 100644
 

Re: [PATCHv2 2/4] mm: cma: Contiguous Memory Allocator added

2010-07-26 Thread Hans Verkuil
Hi Michal,

Thanks for working on this, we definitely need something along these lines.

On Monday 26 July 2010 16:40:30 Michal Nazarewicz wrote:
 The Contiguous Memory Allocator framework is a set of APIs for
 allocating physically contiguous chunks of memory.
 
 Various chips require contiguous blocks of memory to operate.  Those
 chips include devices such as cameras, hardware video decoders and
 encoders, etc.
 
 The code is highly modular and customisable to suit the needs of
 various users.  Set of regions reserved for CMA can be configured on
 run-time and it is easy to add custom allocator algorithms if one
 has such need.
 
 For more details see Documentation/contiguous-memory.txt.
 
 Signed-off-by: Michal Nazarewicz m.nazarew...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Reviewed-by: Pawel Osciak p.osc...@samsung.com
 ---
  Documentation/00-INDEX |2 +
  .../ABI/testing/sysfs-kernel-mm-contiguous |9 +
  Documentation/contiguous-memory.txt|  646 +++
  Documentation/kernel-parameters.txt|4 +
  include/linux/cma.h|  445 
  mm/Kconfig |   34 +
  mm/Makefile|3 +
  mm/cma-best-fit.c  |  407 +++
  mm/cma.c   | 1170 
 
  9 files changed, 2720 insertions(+), 0 deletions(-)
  create mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-contiguous
  create mode 100644 Documentation/contiguous-memory.txt
  create mode 100644 include/linux/cma.h
  create mode 100644 mm/cma-best-fit.c
  create mode 100644 mm/cma.c
 
 diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
 index 5405f7a..bb50209 100644
 --- a/Documentation/00-INDEX
 +++ b/Documentation/00-INDEX
 @@ -94,6 +94,8 @@ connector/
   - docs on the netlink based userspace-kernel space communication mod.
  console/
   - documentation on Linux console drivers.
 +contiguous-memory.txt
 + - documentation on physically-contiguous memory allocation framework.
  cpu-freq/
   - info on CPU frequency and voltage scaling.
  cpu-hotplug.txt
 diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-contiguous 
 b/Documentation/ABI/testing/sysfs-kernel-mm-contiguous
 new file mode 100644
 index 000..05e2f6a
 --- /dev/null
 +++ b/Documentation/ABI/testing/sysfs-kernel-mm-contiguous
 @@ -0,0 +1,9 @@
 +What:/sys/kernel/mm/contiguous/
 +Date:July 2008
 +Contact: Michal Nazarewicz m.nazarew...@samsung.com
 +Description:
 + /sys/kernel/mm/contiguous/ contains two files: asterisk and
 + map.  They are used to configure the Contiguous Memory
 + Allocator framework.
 +
 + For details see Documentation/contiguous-memory.txt.
 diff --git a/Documentation/contiguous-memory.txt 
 b/Documentation/contiguous-memory.txt
 new file mode 100644
 index 000..6eb1295
 --- /dev/null
 +++ b/Documentation/contiguous-memory.txt
 @@ -0,0 +1,646 @@
 + -*- org -*-
 +
 +* Contiguous Memory Allocator
 +
 +   The Contiguous Memory Allocator (CMA) is a framework, which allows
 +   setting up a machine-specific configuration for physically-contiguous
 +   memory management. Memory for devices is then allocated according
 +   to that configuration.
 +
 +   The main role of the framework is not to allocate memory, but to
 +   parse and manage memory configurations, as well as to act as an
 +   in-between between device drivers and pluggable allocators. It is
 +   thus not tied to any memory allocation method or strategy.
 +
 +** Why is it needed?
 +
 +Various devices on embedded systems have no scatter-getter and/or
 +IO map support and as such require contiguous blocks of memory to
 +operate.  They include devices such as cameras, hardware video
 +decoders and encoders, etc.
 +
 +Such devices often require big memory buffers (a full HD frame is,
 +for instance, more then 2 mega pixels large, i.e. more than 6 MB
 +of memory), which makes mechanisms such as kmalloc() ineffective.
 +
 +Some embedded devices impose additional requirements on the
 +buffers, e.g. they can operate only on buffers allocated in
 +particular location/memory bank (if system has more than one
 +memory bank) or buffers aligned to a particular memory boundary.
 +
 +Development of embedded devices have seen a big rise recently
 +(especially in the V4L area) and many such drivers include their
 +own memory allocation code. Most of them use bootmem-based methods.
 +CMA framework is an attempt to unify contiguous memory allocation
 +mechanisms and provide a simple API for device drivers, while
 +staying as customisable and modular as possible.
 +
 +** Design
 +
 +The 

Re: [Q]: any DVB-S2 card which is 45MS/s capable?

2010-07-26 Thread VDR User
Look at the vp-1041 I think.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH 0/15] STAGING: add lirc device drivers

2010-07-26 Thread Jarod Wilson
This patch series adds the remaining lirc_foo device drivers to the staging
tree. The core lirc_dev driver and lirc headers are currently merged in a
v4l/dvb staging tree (which is pulled into linux-next), and are utilized by
way of an IR decoder/encoder bridge plugin to ir-core.

I've started porting lirc_foo drivers over to ir-core, first tackling the
lirc_mceusb and lirc_imon drivers. lirc_mceusb is no more, replaced by a
pure ir-core mceusb driver, and lirc_imon only supports the old first-gen
imon devices now, which are quite different from the current-gen ones, now
supported by a pure ir-core imon driver.

The long-term goal here is that all of these drivers should either be ported
to ir-core, or dropped entirely. Some of them (*cough* lirc_parallel *cough*)
should likely just be put out to pasture, but others are definitely still in
use by quite a few people out there. I've got hardware for another four or
five of the drivers, but not the rest, so I'm hoping that maybe people who
have the hardware will pitch in and help with the porting if the bits are
more readily available by way of the staging tree.

Drivers I have hardware for, and am thus most likely to work on porting to
ir-core before any others (and probably in this order):
- lirc_zilog
- lirc_streamzap
- lirc_i2c
- lirc_serial
- lirc_sir

Additionally, Maxim Levitsky, the author of lirc_ene0100, has already started
work on porting lirc_ene0100 to ir-core. Everything else, definitely
looking for help.

Patches:
staging/lirc: add lirc_bt829 driver
staging/lirc: add lirc_ene0100 driver
staging/lirc: add lirc_i2c driver
staging/lirc: add lirc_igorplugusb driver
staging/lirc: add lirc_imon driver
staging/lirc: add lirc_it87 driver
staging/lirc: add lirc_ite8709 driver
staging/lirc: add lirc_parallel driver
staging/lirc: add lirc_sasem driver
staging/lirc: add lirc_serial driver
staging/lirc: add lirc_sir driver
staging/lirc: add lirc_streamzap driver
staging/lirc: add lirc_ttusbir driver
staging/lirc: add lirc_zilog driver
staging/lirc: wire up Kconfig and Makefile bits

Diffstat:
 drivers/staging/Kconfig |2 +
 drivers/staging/Makefile|1 +
 drivers/staging/lirc/Kconfig|  110 +++
 drivers/staging/lirc/Makefile   |   19 +
 drivers/staging/lirc/TODO   |8 +
 drivers/staging/lirc/lirc_bt829.c   |  383 +
 drivers/staging/lirc/lirc_ene0100.c |  646 ++
 drivers/staging/lirc/lirc_ene0100.h |  169 
 drivers/staging/lirc/lirc_i2c.c |  536 
 drivers/staging/lirc/lirc_igorplugusb.c |  555 
 drivers/staging/lirc/lirc_imon.c| 1058 +++
 drivers/staging/lirc/lirc_it87.c| 1019 +++
 drivers/staging/lirc/lirc_it87.h|  116 +++
 drivers/staging/lirc/lirc_ite8709.c |  542 
 drivers/staging/lirc/lirc_parallel.c|  705 
 drivers/staging/lirc/lirc_parallel.h|   26 +
 drivers/staging/lirc/lirc_sasem.c   |  933 +
 drivers/staging/lirc/lirc_serial.c  | 1313 +
 drivers/staging/lirc/lirc_sir.c | 1282 
 drivers/staging/lirc/lirc_streamzap.c   |  821 ++
 drivers/staging/lirc/lirc_ttusbir.c |  397 +
 drivers/staging/lirc/lirc_zilog.c   | 1387
+++
 22 files changed, 12028 insertions(+), 0 deletions(-)

-- 
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 01/15] staging/lirc: add lirc_bt829 driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_bt829.c |  383 +
 1 files changed, 383 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_bt829.c

diff --git a/drivers/staging/lirc/lirc_bt829.c 
b/drivers/staging/lirc/lirc_bt829.c
new file mode 100644
index 000..d0f34b5
--- /dev/null
+++ b/drivers/staging/lirc/lirc_bt829.c
@@ -0,0 +1,383 @@
+/*
+ * Remote control driver for the TV-card based on bt829
+ *
+ *  by Leonid Froenchenko lfr...@galileo.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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/threads.h
+#include linux/sched.h
+#include linux/ioport.h
+#include linux/pci.h
+#include linux/delay.h
+
+#include media/lirc_dev.h
+
+static int poll_main(void);
+static int atir_init_start(void);
+
+static void write_index(unsigned char index, unsigned int value);
+static unsigned int read_index(unsigned char index);
+
+static void do_i2c_start(void);
+static void do_i2c_stop(void);
+
+static void seems_wr_byte(unsigned char al);
+static unsigned char seems_rd_byte(void);
+
+static unsigned int read_index(unsigned char al);
+static void write_index(unsigned char ah, unsigned int edx);
+
+static void cycle_delay(int cycle);
+
+static void do_set_bits(unsigned char bl);
+static unsigned char do_get_bits(void);
+
+#define DATA_PCI_OFF 0x7FFC00
+#define WAIT_CYCLE   20
+
+#define DRIVER_NAME lirc_bt829
+
+static int debug;
+#define dprintk(fmt, args...)   \
+   do { \
+   if (debug)   \
+   printk(KERN_DEBUG DRIVER_NAME : fmt, ## args); \
+   } while (0)
+
+static int atir_minor;
+static unsigned long pci_addr_phys;
+static unsigned char *pci_addr_lin;
+
+static struct lirc_driver atir_driver;
+
+static struct pci_dev *do_pci_probe(void)
+{
+   struct pci_dev *my_dev;
+   my_dev = pci_get_device(PCI_VENDOR_ID_ATI,
+   PCI_DEVICE_ID_ATI_264VT, NULL);
+   if (my_dev) {
+   printk(KERN_ERR DRIVER_NAME : Using device: %s\n,
+  pci_name(my_dev));
+   pci_addr_phys = 0;
+   if (my_dev-resource[0].flags  IORESOURCE_MEM) {
+   pci_addr_phys = my_dev-resource[0].start;
+   printk(KERN_INFO DRIVER_NAME : memory at 0x%08X \n,
+  (unsigned int)pci_addr_phys);
+   }
+   if (pci_addr_phys == 0) {
+   printk(KERN_ERR DRIVER_NAME : no memory resource ?\n);
+   return NULL;
+   }
+   } else {
+   printk(KERN_ERR DRIVER_NAME : pci_probe failed\n);
+   return NULL;
+   }
+   return my_dev;
+}
+
+static int atir_add_to_buf(void *data, struct lirc_buffer *buf)
+{
+   unsigned char key;
+   int status;
+   status = poll_main();
+   key = (status  8)  0xFF;
+   if (status  0xFF) {
+   dprintk(reading key %02X\n, key);
+   lirc_buffer_write(buf, key);
+   return 0;
+   }
+   return -ENODATA;
+}
+
+static int atir_set_use_inc(void *data)
+{
+   dprintk(driver is opened\n);
+   return 0;
+}
+
+static void atir_set_use_dec(void *data)
+{
+   dprintk(driver is closed\n);
+}
+
+int init_module(void)
+{
+   struct pci_dev *pdev;
+
+   pdev = do_pci_probe();
+   if (pdev == NULL)
+   return 1;
+
+   if (!atir_init_start())
+   return 1;
+
+   strcpy(atir_driver.name, ATIR);
+   atir_driver.minor   = -1;
+   atir_driver.code_length = 8;
+   atir_driver.sample_rate = 10;
+   atir_driver.data= 0;
+   atir_driver.add_to_buf  = atir_add_to_buf;
+   atir_driver.set_use_inc = atir_set_use_inc;
+   atir_driver.set_use_dec = atir_set_use_dec;
+   atir_driver.dev = pdev-dev;
+   atir_driver.owner   = THIS_MODULE;
+
+   atir_minor = lirc_register_driver(atir_driver);
+   if (atir_minor  0) {
+   printk(KERN_ERR DRIVER_NAME : failed to register driver!\n);
+

[PATCH 02/15] staging/lirc: add lirc_ene0100 driver

2010-07-26 Thread Jarod Wilson

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_ene0100.c |  646 +++
 drivers/staging/lirc/lirc_ene0100.h |  169 +
 2 files changed, 815 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_ene0100.c
 create mode 100644 drivers/staging/lirc/lirc_ene0100.h

diff --git a/drivers/staging/lirc/lirc_ene0100.c 
b/drivers/staging/lirc/lirc_ene0100.c
new file mode 100644
index 000..a152c52
--- /dev/null
+++ b/drivers/staging/lirc/lirc_ene0100.c
@@ -0,0 +1,646 @@
+/*
+ * driver for ENE KB3926 B/C/D CIR (also known as ENE0100)
+ *
+ * Copyright (C) 2009 Maxim Levitsky maximlevit...@gmail.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.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pnp.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include lirc_ene0100.h
+
+static int sample_period = 75;
+static int enable_idle = 1;
+static int enable_learning;
+
+static void ene_set_idle(struct ene_device *dev, int idle);
+static void ene_set_inputs(struct ene_device *dev, int enable);
+
+/* read a hardware register */
+static u8 ene_hw_read_reg(struct ene_device *dev, u16 reg)
+{
+   outb(reg  8, dev-hw_io + ENE_ADDR_HI);
+   outb(reg  0xFF, dev-hw_io + ENE_ADDR_LO);
+   return inb(dev-hw_io + ENE_IO);
+}
+
+/* write a hardware register */
+static void ene_hw_write_reg(struct ene_device *dev, u16 reg, u8 value)
+{
+   outb(reg  8, dev-hw_io + ENE_ADDR_HI);
+   outb(reg  0xFF, dev-hw_io + ENE_ADDR_LO);
+   outb(value, dev-hw_io + ENE_IO);
+}
+
+/* change specific bits in hardware register */
+static void ene_hw_write_reg_mask(struct ene_device *dev,
+ u16 reg, u8 value, u8 mask)
+{
+   u8 regvalue;
+
+   outb(reg  8, dev-hw_io + ENE_ADDR_HI);
+   outb(reg  0xFF, dev-hw_io + ENE_ADDR_LO);
+
+   regvalue = inb(dev-hw_io + ENE_IO)  ~mask;
+   regvalue |= (value  mask);
+   outb(regvalue, dev-hw_io + ENE_IO);
+}
+
+/* read irq status and ack it */
+static int ene_hw_irq_status(struct ene_device *dev, int *buffer_pointer)
+{
+   u8 irq_status;
+   u8 fw_flags1, fw_flags2;
+
+   fw_flags2 = ene_hw_read_reg(dev, ENE_FW2);
+
+   if (buffer_pointer)
+   *buffer_pointer = 4 * (fw_flags2  ENE_FW2_BUF_HIGH);
+
+   if (dev-hw_revision  ENE_HW_C) {
+   irq_status = ene_hw_read_reg(dev, ENEB_IRQ_STATUS);
+
+   if (!(irq_status  ENEB_IRQ_STATUS_IR))
+   return 0;
+   ene_hw_write_reg(dev, ENEB_IRQ_STATUS,
+irq_status  ~ENEB_IRQ_STATUS_IR);
+
+   /* rev B support only recieving */
+   return ENE_IRQ_RX;
+   }
+
+   irq_status = ene_hw_read_reg(dev, ENEC_IRQ);
+
+   if (!(irq_status  ENEC_IRQ_STATUS))
+   return 0;
+
+   /* original driver does that twice - a workaround ? */
+   ene_hw_write_reg(dev, ENEC_IRQ, irq_status  ~ENEC_IRQ_STATUS);
+   ene_hw_write_reg(dev, ENEC_IRQ, irq_status  ~ENEC_IRQ_STATUS);
+
+   /* clear unknown flag in F8F9 */
+   if (fw_flags2  ENE_FW2_IRQ_CLR)
+   ene_hw_write_reg(dev, ENE_FW2, fw_flags2  ~ENE_FW2_IRQ_CLR);
+
+   /* check if this is a TX interrupt */
+   fw_flags1 = ene_hw_read_reg(dev, ENE_FW1);
+
+   if (fw_flags1  ENE_FW1_TXIRQ) {
+   ene_hw_write_reg(dev, ENE_FW1, fw_flags1  ~ENE_FW1_TXIRQ);
+   return ENE_IRQ_TX;
+   } else
+   return ENE_IRQ_RX;
+}
+
+static int ene_hw_detect(struct ene_device *dev)
+{
+   u8 chip_major, chip_minor;
+   u8 hw_revision, old_ver;
+   u8 tmp;
+   u8 fw_capabilities;
+
+   tmp = ene_hw_read_reg(dev, ENE_HW_UNK);
+   ene_hw_write_reg(dev, ENE_HW_UNK, tmp  ~ENE_HW_UNK_CLR);
+
+   chip_major = ene_hw_read_reg(dev, ENE_HW_VER_MAJOR);
+   chip_minor = ene_hw_read_reg(dev, ENE_HW_VER_MINOR);
+
+   ene_hw_write_reg(dev, ENE_HW_UNK, tmp);
+   hw_revision = ene_hw_read_reg(dev, ENE_HW_VERSION);
+   old_ver = ene_hw_read_reg(dev, ENE_HW_VER_OLD);
+
+   if (hw_revision == 0xFF) {
+
+   ene_printk(KERN_WARNING, device seems to be disabled\n);
+   

[PATCH 03/15] staging/lirc: add lirc_i2c driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_i2c.c |  536 +++
 1 files changed, 536 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_i2c.c

diff --git a/drivers/staging/lirc/lirc_i2c.c b/drivers/staging/lirc/lirc_i2c.c
new file mode 100644
index 000..6df2c0e
--- /dev/null
+++ b/drivers/staging/lirc/lirc_i2c.c
@@ -0,0 +1,536 @@
+/*
+ * lirc_i2c.c
+ *
+ * i2c IR driver for the onboard IR port on many TV tuner cards, including:
+ *  -Flavors of the Hauppauge PVR-150/250/350
+ *  -Hauppauge HVR-1300
+ *  -PixelView (BT878P+W/FM)
+ *  -KNC ONE TV Station/Anubis Typhoon TView Tuner
+ *  -Asus TV-Box and Creative/VisionTek BreakOut-Box
+ *  -Leadtek Winfast PVR2000
+ *
+ * Copyright (c) 2000 Gerd Knorr kra...@goldbach.in-berlin.de
+ * modified for PixelView (BT878P+W/FM) by
+ *  Michal Kochanowicz mkoch...@pld.org.pl
+ *  Christoph Bartelmus l...@bartelmus.de
+ * modified for KNC ONE TV Station/Anubis Typhoon TView Tuner by
+ *  Ulrich Mueller ulrich.muelle...@web.de
+ * modified for Asus TV-Box and Creative/VisionTek BreakOut-Box by
+ *  Stefan Jahn ste...@lkcc.org
+ * modified for inclusion into kernel sources by
+ *  Jerome Brock jbr...@users.sourceforge.net
+ * modified for Leadtek Winfast PVR2000 by
+ *  Thomas Reitmayr (treitm...@yahoo.com)
+ * modified for Hauppauge HVR-1300 by
+ *  Jan Frey (jf...@gmx.de)
+ *
+ * parts are cutpasted from the old lirc_haup.c driver
+ *
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+
+#include linux/version.h
+#include linux/module.h
+#include linux/kmod.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/string.h
+#include linux/timer.h
+#include linux/delay.h
+#include linux/errno.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/i2c-algo-bit.h
+
+#include media/lirc_dev.h
+
+struct IR {
+   struct lirc_driver l;
+   struct i2c_client  c;
+   int nextkey;
+   unsigned char b[3];
+   unsigned char bits;
+   unsigned char flag;
+};
+
+#define DEVICE_NAME lirc_i2c
+
+/* module parameters */
+static int debug;  /* debug output */
+static int minor = -1; /* minor number */
+
+#define dprintk(fmt, args...)  \
+   do {\
+   if (debug)  \
+   printk(KERN_DEBUG DEVICE_NAME :  fmt, \
+  ## args);\
+   } while (0)
+
+static int reverse(int data, int bits)
+{
+   int i;
+   int c;
+
+   for (c = 0, i = 0; i  bits; i++)
+   c |= ((data  (1i)) ? 1 : 0)  (bits-1-i);
+
+   return c;
+}
+
+static int add_to_buf_adap(void *data, struct lirc_buffer *buf)
+{
+   struct IR *ir = data;
+   unsigned char keybuf[4];
+
+   keybuf[0] = 0x00;
+   i2c_master_send(ir-c, keybuf, 1);
+   /* poll IR chip */
+   if (i2c_master_recv(ir-c, keybuf, sizeof(keybuf)) != sizeof(keybuf)) {
+   dprintk(read error\n);
+   return -EIO;
+   }
+
+   dprintk(key (0x%02x%02x%02x%02x)\n,
+   keybuf[0], keybuf[1], keybuf[2], keybuf[3]);
+
+   /* key pressed ? */
+   if (keybuf[2] == 0xff)
+   return -ENODATA;
+
+   /* remove repeat bit */
+   keybuf[2] = 0x7f;
+   keybuf[3] |= 0x80;
+
+   lirc_buffer_write(buf, keybuf);
+   return 0;
+}
+
+static int add_to_buf_pcf8574(void *data, struct lirc_buffer *buf)
+{
+   struct IR *ir = data;
+   int rc;
+   unsigned char all, mask;
+   unsigned char key;
+
+   /* compute all valid bits (key code + pressed/release flag) */
+   all = ir-bits | ir-flag;
+
+   /* save IR writable mask bits */
+   mask = i2c_smbus_read_byte(ir-c)  ~all;
+
+   /* send bit mask */
+   rc = i2c_smbus_write_byte(ir-c, (0xff  all) | mask);
+
+   /* receive scan code */
+   rc = i2c_smbus_read_byte(ir-c);
+
+   if (rc == -1) {
+   dprintk(%s read error\n, ir-c.name);
+   return -EIO;
+   }
+
+   /* drop duplicate polls */
+   if (ir-b[0] == (rc  all))
+   return 

[PATCH 04/15] staging/lirc: add lirc_igorplugusb driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_igorplugusb.c |  555 +++
 1 files changed, 555 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_igorplugusb.c

diff --git a/drivers/staging/lirc/lirc_igorplugusb.c 
b/drivers/staging/lirc/lirc_igorplugusb.c
new file mode 100644
index 000..bce600e
--- /dev/null
+++ b/drivers/staging/lirc/lirc_igorplugusb.c
@@ -0,0 +1,555 @@
+/*
+ * lirc_igorplugusb - USB remote support for LIRC
+ *
+ * Supports the standard homebrew IgorPlugUSB receiver with Igor's firmware.
+ * See http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20(AVR)_eng.htm
+ *
+ * The device can only record bursts of up to 36 pulses/spaces.
+ * Works fine with RC5. Longer commands lead to device buffer overrun.
+ * (Maybe a better firmware or a microcontroller with more ram can help?)
+ *
+ * Version 0.1  [beta status]
+ *
+ * Copyright (C) 2004 Jan M. Hochstein
+ * hochst...@algo.informatik.tu-darmstadt.de
+ *
+ * This driver was derived from:
+ *   Paul Miller pmill...@users.sourceforge.net
+ *  lirc_atiusb module
+ *   Vladimir Dergachev volo...@minspring.com's 2002
+ *  USB ATI Remote support (input device)
+ *   Adrian Dewhurst sailor...@sailorfrag.net's 2002
+ *  USB StreamZap remote driver (LIRC)
+ *   Artur Lipowski alipow...@kki.net.pl's 2002
+ *  lirc_dev and lirc_gpio LIRC modules
+ */
+
+/*
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/kmod.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/usb.h
+#include linux/time.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+
+/* module identification */
+#define DRIVER_VERSION 0.1
+#define DRIVER_AUTHOR  \
+   Jan M. Hochstein hochst...@algo.informatik.tu-darmstadt.de
+#define DRIVER_DESCUSB remote driver for LIRC
+#define DRIVER_NAMElirc_igorplugusb
+
+/* debugging support */
+#ifdef CONFIG_USB_DEBUG
+static int debug = 1;
+#else
+static int debug;
+#endif
+
+#define dprintk(fmt, args...)  \
+   do {\
+   if (debug)  \
+   printk(KERN_DEBUG fmt, ## args);\
+   } while (0)
+
+/* One mode2 pulse/space has 4 bytes. */
+#define CODE_LENGTH sizeof(int)
+
+/* Igor's firmware cannot record bursts longer than 36. */
+#define DEVICE_BUFLEN 36
+
+/*
+ * Header at the beginning of the device's buffer:
+ * unsigned char data_length
+ * unsigned char data_start(!=0 means ring-buffer overrun)
+ * unsigned char counter   (incremented by each burst)
+ */
+#define DEVICE_HEADERLEN   3
+
+/* This is for the gap */
+#define ADDITIONAL_LIRC_BYTES   2
+
+/* times to poll per second */
+#define SAMPLE_RATE 100
+static int sample_rate = SAMPLE_RATE;
+
+
+/ Igor's USB Request Codes */
+
+#define SET_INFRABUFFER_EMPTY   1
+/**
+ * Params: none
+ * Answer: empty
+ */
+
+#define GET_INFRACODE 2
+/**
+ * Params:
+ *   wValue: offset to begin reading infra buffer
+ *
+ * Answer: infra data
+ */
+
+#define SET_DATAPORT_DIRECTION  3
+/**
+ * Params:
+ *   wValue: (byte) 1 bit for each data port pin (0=in, 1=out)
+ *
+ * Answer: empty
+ */
+
+#define GET_DATAPORT_DIRECTION  4
+/**
+ * Params: none
+ *
+ * Answer: (byte) 1 bit for each data port pin (0=in, 1=out)
+ */
+
+#define SET_OUT_DATAPORT   5
+/**
+ * Params:
+ *   wValue: byte to write to output data port
+ *
+ * Answer: empty
+ */
+
+#define GET_OUT_DATAPORT   6
+/**
+ * Params: none
+ *
+ * Answer: least significant 3 bits read from output data port
+ */
+
+#define GET_IN_DATAPORT 7
+/**
+ * Params: none
+ *
+ * Answer: least significant 3 bits read from input data port
+ */
+
+#define READ_EEPROM 8
+/**
+ * Params:
+ *   wValue: offset to begin reading EEPROM
+ *
+ * Answer: EEPROM bytes
+ */
+
+#define WRITE_EEPROM   9
+/**
+ * Params:
+ *   wValue: offset to EEPROM byte
+ *   wIndex: byte to write
+ *
+ * Answer: empty
+ */
+
+#define SEND_RS232   10
+/**
+ * Params:
+ *   wValue: byte to send
+ *
+ * Answer: empty
+ */
+
+#define 

[PATCH 05/15] staging/lirc: add lirc_imon driver

2010-07-26 Thread Jarod Wilson
Nb: this is a very trimmed-down lirc_imon, which only supports the
oldest generation of imon devices that don't do onboard signal decoding
like the most recent generation imon devices -- those are now supported
by the ir-core imon driver.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_imon.c | 1058 ++
 1 files changed, 1058 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_imon.c

diff --git a/drivers/staging/lirc/lirc_imon.c b/drivers/staging/lirc/lirc_imon.c
new file mode 100644
index 000..43856d6
--- /dev/null
+++ b/drivers/staging/lirc/lirc_imon.c
@@ -0,0 +1,1058 @@
+/*
+ *   lirc_imon.c:  LIRC/VFD/LCD driver for SoundGraph iMON IR/VFD/LCD
+ *including the iMON PAD model
+ *
+ *   Copyright(C) 2004  Venky Raju(d...@venky.ws)
+ *   Copyright(C) 2009  Jarod Wilson ja...@wilsonet.com
+ *
+ *   lirc_imon 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/errno.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/usb.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+
+#define MOD_AUTHOR Venky Raju d...@venky.ws
+#define MOD_DESC   Driver for SoundGraph iMON MultiMedia IR/Display
+#define MOD_NAME   lirc_imon
+#define MOD_VERSION0.8
+
+#define DISPLAY_MINOR_BASE 144
+#define DEVICE_NAMElcd%d
+
+#define BUF_CHUNK_SIZE 4
+#define BUF_SIZE   128
+
+#define BIT_DURATION   250 /* each bit received is 250us */
+
+/*** P R O T O T Y P E S ***/
+
+/* USB Callback prototypes */
+static int imon_probe(struct usb_interface *interface,
+ const struct usb_device_id *id);
+static void imon_disconnect(struct usb_interface *interface);
+static void usb_rx_callback(struct urb *urb);
+static void usb_tx_callback(struct urb *urb);
+
+/* suspend/resume support */
+static int imon_resume(struct usb_interface *intf);
+static int imon_suspend(struct usb_interface *intf, pm_message_t message);
+
+/* Display file_operations function prototypes */
+static int display_open(struct inode *inode, struct file *file);
+static int display_close(struct inode *inode, struct file *file);
+
+/* VFD write operation */
+static ssize_t vfd_write(struct file *file, const char *buf,
+size_t n_bytes, loff_t *pos);
+
+/* LIRC driver function prototypes */
+static int ir_open(void *data);
+static void ir_close(void *data);
+
+/* Driver init/exit prototypes */
+static int __init imon_init(void);
+static void __exit imon_exit(void);
+
+/*** G L O B A L S ***/
+#define IMON_DATA_BUF_SZ   35
+
+struct imon_context {
+   struct usb_device *usbdev;
+   /* Newer devices have two interfaces */
+   int display;/* not all controllers do */
+   int display_isopen; /* display port has been opened */
+   int ir_isopen;  /* IR port open */
+   int dev_present;/* USB device presence */
+   struct mutex ctx_lock;  /* to lock this object */
+   wait_queue_head_t remove_ok;/* For unexpected USB disconnects */
+
+   int vfd_proto_6p;   /* some VFD require a 6th packet */
+
+   struct lirc_driver *driver;
+   struct usb_endpoint_descriptor *rx_endpoint;
+   struct usb_endpoint_descriptor *tx_endpoint;
+   struct urb *rx_urb;
+   struct urb *tx_urb;
+   unsigned char usb_rx_buf[8];
+   unsigned char usb_tx_buf[8];
+
+   struct rx_data {
+   int count;  /* length of 0 or 1 sequence */
+   int prev_bit;   /* logic level of sequence */
+   int initial_space;  /* initial space flag */
+   } rx;
+
+   struct tx_t {
+   unsigned char data_buf[IMON_DATA_BUF_SZ]; /* user data buffer */
+   struct completion finished; /* wait for write to finish */
+   atomic_t busy;  /* write in progress */
+   int status; /* status of tx completion */
+   } tx;
+};
+
+static struct file_operations display_fops = {
+   .owner  = THIS_MODULE,
+   .open   = display_open,
+   .write  = vfd_write,
+ 

[PATCH 06/15] staging/lirc: add lirc_it87 driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_it87.c | 1019 ++
 drivers/staging/lirc/lirc_it87.h |  116 +
 2 files changed, 1135 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_it87.c
 create mode 100644 drivers/staging/lirc/lirc_it87.h

diff --git a/drivers/staging/lirc/lirc_it87.c b/drivers/staging/lirc/lirc_it87.c
new file mode 100644
index 000..781abc3
--- /dev/null
+++ b/drivers/staging/lirc/lirc_it87.c
@@ -0,0 +1,1019 @@
+/*
+ * LIRC driver for ITE IT8712/IT8705 CIR port
+ *
+ * Copyright (C) 2001 Hans-Gunter Lutke Uphues hg...@web.de
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ *
+ * ITE IT8705 and IT8712(not tested) and IT8720 CIR-port support for lirc based
+ * via cut and paste from lirc_sir.c (C) 2000 Milan Pikula
+ *
+ * Attention: Sendmode only tested with debugging logs
+ *
+ * 2001/02/27 Christoph Bartelmus l...@bartelmus.de :
+ *   reimplemented read function
+ * 2005/06/05 Andrew Calkin implemented support for Asus Digimatrix,
+ *   based on work of the following member of the Outertrack Digimatrix
+ *   Forum: Art103 r_...@hotmail.com
+ * 2009/12/24 James Edwards jimbo-l...@edwardsclan.net implemeted support
+ *   for ITE8704/ITE8718, on my machine, the DSDT reports 8704, but the
+ *   chip identifies as 18.
+ */
+
+#include linux/module.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/signal.h
+#include linux/fs.h
+#include linux/interrupt.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/time.h
+#include linux/string.h
+#include linux/types.h
+#include linux/wait.h
+#include linux/mm.h
+#include linux/delay.h
+#include linux/poll.h
+#include asm/system.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/fcntl.h
+
+#include linux/timer.h
+#include linux/pnp.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+#include lirc_it87.h
+
+#ifdef LIRC_IT87_DIGIMATRIX
+static int digimatrix = 1;
+static int it87_freq = 36; /* kHz */
+static int irq = 9;
+#else
+static int digimatrix;
+static int it87_freq = 38; /* kHz */
+static int irq = IT87_CIR_DEFAULT_IRQ;
+#endif
+
+static unsigned long it87_bits_in_byte_out;
+static unsigned long it87_send_counter;
+static unsigned char it87_RXEN_mask = IT87_CIR_RCR_RXEN;
+
+#define RBUF_LEN 1024
+
+#define LIRC_DRIVER_NAME lirc_it87
+
+/* timeout for sequences in jiffies (=5/100s) */
+/* must be longer than TIME_CONST */
+#define IT87_TIMEOUT   (HZ*5/100)
+
+/* module parameters */
+static int debug;
+#define dprintk(fmt, args...)  \
+   do {\
+   if (debug)  \
+   printk(KERN_DEBUG LIRC_DRIVER_NAME :  \
+  fmt, ## args);   \
+   } while (0)
+
+static int io = IT87_CIR_DEFAULT_IOBASE;
+/* receiver demodulator default: off */
+static int it87_enable_demodulator;
+
+static int timer_enabled;
+static DEFINE_SPINLOCK(timer_lock);
+static struct timer_list timerlist;
+/* time of last signal change detected */
+static struct timeval last_tv = {0, 0};
+/* time of last UART data ready interrupt */
+static struct timeval last_intr_tv = {0, 0};
+static int last_value;
+
+static DECLARE_WAIT_QUEUE_HEAD(lirc_read_queue);
+
+static DEFINE_SPINLOCK(hardware_lock);
+static DEFINE_SPINLOCK(dev_lock);
+
+static int rx_buf[RBUF_LEN];
+unsigned int rx_tail, rx_head;
+
+static struct pnp_driver it87_pnp_driver;
+
+/* SECTION: Prototypes */
+
+/* Communication with user-space */
+static int lirc_open(struct inode *inode, struct file *file);
+static int lirc_close(struct inode *inode, struct file *file);
+static unsigned int lirc_poll(struct file *file, poll_table *wait);
+static ssize_t lirc_read(struct file *file, char *buf,
+size_t count, loff_t *ppos);
+static ssize_t lirc_write(struct file *file, const char *buf,
+ size_t n, loff_t *pos);
+static long lirc_ioctl(struct file *filep, unsigned int cmd, unsigned long 
arg);
+static void add_read_queue(int flag, unsigned long val);
+static int init_chrdev(void);
+static void drop_chrdev(void);
+/* Hardware */
+static irqreturn_t it87_interrupt(int irq, void 

[PATCH 07/15] staging/lirc: add lirc_ite8709 driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_ite8709.c |  542 +++
 1 files changed, 542 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_ite8709.c

diff --git a/drivers/staging/lirc/lirc_ite8709.c 
b/drivers/staging/lirc/lirc_ite8709.c
new file mode 100644
index 000..9352f45
--- /dev/null
+++ b/drivers/staging/lirc/lirc_ite8709.c
@@ -0,0 +1,542 @@
+/*
+ * LIRC driver for ITE8709 CIR port
+ *
+ * Copyright (C) 2008 Grégory Lardière spmf2004-l...@yahoo.fr
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+ * USA
+ */
+
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/sched.h
+#include linux/delay.h
+#include linux/pnp.h
+#include linux/io.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+#define LIRC_DRIVER_NAME lirc_ite8709
+
+#define BUF_CHUNK_SIZE sizeof(int)
+#define BUF_SIZE   (128*BUF_CHUNK_SIZE)
+
+/*
+ * The ITE8709 device seems to be the combination of IT8512 superIO chip and
+ * a specific firmware running on the IT8512's embedded micro-controller.
+ * In addition of the embedded micro-controller, the IT8512 chip contains a
+ * CIR module and several other modules. A few modules are directly accessible
+ * by the host CPU, but most of them are only accessible by the
+ * micro-controller. The CIR module is only accessible by the micro-controller.
+ * The battery-backed SRAM module is accessible by the host CPU and the
+ * micro-controller. So one of the MC's firmware role is to act as a bridge
+ * between the host CPU and the CIR module. The firmware implements a kind of
+ * communication protocol using the SRAM module as a shared memory. The IT8512
+ * specification is publicly available on ITE's web site, but the communication
+ * protocol is not, so it was reverse-engineered.
+ */
+
+/* ITE8709 Registers addresses and values (reverse-engineered) */
+#define ITE8709_MODE   0x1a
+#define ITE8709_REG_ADR0x1b
+#define ITE8709_REG_VAL0x1c
+#define ITE8709_IIR0x1e  /* Interrupt identification register */
+#define ITE8709_RFSR   0x1f  /* Receiver FIFO status register */
+#define ITE8709_FIFO_START 0x20
+
+#define ITE8709_MODE_READY 0X00
+#define ITE8709_MODE_WRITE 0X01
+#define ITE8709_MODE_READ  0X02
+#define ITE8709_IIR_RDAI   0x02  /* Receiver data available interrupt */
+#define ITE8709_IIR_RFOI   0x04  /* Receiver FIFO overrun interrupt */
+#define ITE8709_RFSR_MASK  0x3f  /* FIFO byte count mask */
+
+/*
+ * IT8512 CIR-module registers addresses and values
+ * (from IT8512 E/F specification v0.4.1)
+ */
+#define IT8512_REG_MSTCR   0x01  /* Master control register */
+#define IT8512_REG_IER 0x02  /* Interrupt enable register */
+#define IT8512_REG_CFR 0x04  /* Carrier frequency register */
+#define IT8512_REG_RCR 0x05  /* Receive control register */
+#define IT8512_REG_BDLR0x08  /* Baud rate divisor low byte 
register */
+#define IT8512_REG_BDHR0x09  /* Baud rate divisor high byte 
register */
+
+#define IT8512_MSTCR_RESET 0x01  /* Reset registers to default value */
+#define IT8512_MSTCR_FIFOCLR   0x02  /* Clear FIFO */
+#define IT8512_MSTCR_FIFOTL_7  0x04  /* FIFO threshold level : 7 */
+#define IT8512_MSTCR_FIFOTL_25 0x0c  /* FIFO threshold level : 25 */
+#define IT8512_IER_RDAIE   0x02  /* Enable data interrupt request */
+#define IT8512_IER_RFOIE   0x04  /* Enable FIFO overrun interrupt req */
+#define IT8512_IER_IEC 0x80  /* Enable interrupt request */
+#define IT8512_CFR_CF_36KHZ0x09  /* Carrier freq : low speed, 36kHz */
+#define IT8512_RCR_RXDCR_1 0x01  /* Demodulation carrier range : 1 */
+#define IT8512_RCR_RXACT   0x08  /* Receiver active */
+#define IT8512_RCR_RXEN0x80  /* Receiver enable */
+#define IT8512_BDR_6   6 /* Baud rate divisor : 6 */
+
+/* Actual values used by this driver */
+#define CFG_FIFOTL IT8512_MSTCR_FIFOTL_25
+#define CFG_CR_FREQIT8512_CFR_CF_36KHZ
+#define CFG_DCRIT8512_RCR_RXDCR_1
+#define CFG_BDRIT8512_BDR_6
+#define CFG_TIMEOUT10 /* Rearm interrupt when a space is  100 ms */
+
+static int debug;
+
+struct ite8709_device {
+

[PATCH 08/15] staging/lirc: add lirc_parallel driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_parallel.c |  705 ++
 drivers/staging/lirc/lirc_parallel.h |   26 ++
 2 files changed, 731 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_parallel.c
 create mode 100644 drivers/staging/lirc/lirc_parallel.h

diff --git a/drivers/staging/lirc/lirc_parallel.c 
b/drivers/staging/lirc/lirc_parallel.c
new file mode 100644
index 000..df12e7b
--- /dev/null
+++ b/drivers/staging/lirc/lirc_parallel.c
@@ -0,0 +1,705 @@
+/*
+ * lirc_parallel.c
+ *
+ * lirc_parallel - device driver for infra-red signal receiving and
+ * transmitting unit built by the author
+ *
+ * Copyright (C) 1998 Christoph Bartelmus l...@bartelmus.de
+ *
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+/*** Includes ***/
+
+#ifdef CONFIG_SMP
+#error --- Sorry, this driver is not SMP safe. ---
+#endif
+
+#include linux/module.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/signal.h
+#include linux/fs.h
+#include linux/kernel.h
+#include linux/ioport.h
+#include linux/time.h
+#include linux/mm.h
+#include linux/delay.h
+
+#include linux/io.h
+#include linux/signal.h
+#include linux/irq.h
+#include linux/uaccess.h
+#include asm/div64.h
+
+#include linux/poll.h
+#include linux/parport.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+#include lirc_parallel.h
+
+#define LIRC_DRIVER_NAME lirc_parallel
+
+#ifndef LIRC_IRQ
+#define LIRC_IRQ 7
+#endif
+#ifndef LIRC_PORT
+#define LIRC_PORT 0x378
+#endif
+#ifndef LIRC_TIMER
+#define LIRC_TIMER 65536
+#endif
+
+/*** Global Variables ***/
+
+static int debug;
+static int check_pselecd;
+
+unsigned int irq = LIRC_IRQ;
+unsigned int io = LIRC_PORT;
+#ifdef LIRC_TIMER
+unsigned int timer;
+unsigned int default_timer = LIRC_TIMER;
+#endif
+
+#define RBUF_SIZE (256) /* this must be a power of 2 larger than 1 */
+
+static int rbuf[RBUF_SIZE];
+
+DECLARE_WAIT_QUEUE_HEAD(lirc_wait);
+
+unsigned int rptr;
+unsigned int wptr;
+unsigned int lost_irqs;
+int is_open;
+
+struct parport *pport;
+struct pardevice *ppdevice;
+int is_claimed;
+
+unsigned int tx_mask = 1;
+
+/*** Internal Functions ***/
+
+static unsigned int in(int offset)
+{
+   switch (offset) {
+   case LIRC_LP_BASE:
+   return parport_read_data(pport);
+   case LIRC_LP_STATUS:
+   return parport_read_status(pport);
+   case LIRC_LP_CONTROL:
+   return parport_read_control(pport);
+   }
+   return 0; /* make compiler happy */
+}
+
+static void out(int offset, int value)
+{
+   switch (offset) {
+   case LIRC_LP_BASE:
+   parport_write_data(pport, value);
+   break;
+   case LIRC_LP_CONTROL:
+   parport_write_control(pport, value);
+   break;
+   case LIRC_LP_STATUS:
+   printk(KERN_INFO %s: attempt to write to status register\n,
+  LIRC_DRIVER_NAME);
+   break;
+   }
+}
+
+static unsigned int lirc_get_timer(void)
+{
+   return in(LIRC_PORT_TIMER)  LIRC_PORT_TIMER_BIT;
+}
+
+static unsigned int lirc_get_signal(void)
+{
+   return in(LIRC_PORT_SIGNAL)  LIRC_PORT_SIGNAL_BIT;
+}
+
+static void lirc_on(void)
+{
+   out(LIRC_PORT_DATA, tx_mask);
+}
+
+static void lirc_off(void)
+{
+   out(LIRC_PORT_DATA, 0);
+}
+
+static unsigned int init_lirc_timer(void)
+{
+   struct timeval tv, now;
+   unsigned int level, newlevel, timeelapsed, newtimer;
+   int count = 0;
+
+   do_gettimeofday(tv);
+   tv.tv_sec++; /* wait max. 1 sec. */
+   level = lirc_get_timer();
+   do {
+   newlevel = lirc_get_timer();
+   if (level == 0  newlevel != 0)
+   count++;
+   level = newlevel;
+   do_gettimeofday(now);
+   } while (count  1000  (now.tv_sec  tv.tv_sec
+|| (now.tv_sec == tv.tv_sec
+ now.tv_usec  tv.tv_usec)));
+
+   timeelapsed = ((now.tv_sec + 1 - tv.tv_sec)*100
++ (now.tv_usec - tv.tv_usec));
+   if (count = 1000  timeelapsed  0) {
+   if (default_timer == 0) {
+   /* autodetect timer */

[PATCH 09/15] staging/lirc: add lirc_sasem driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_sasem.c |  933 +
 1 files changed, 933 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_sasem.c

diff --git a/drivers/staging/lirc/lirc_sasem.c 
b/drivers/staging/lirc/lirc_sasem.c
new file mode 100644
index 000..9e516a1
--- /dev/null
+++ b/drivers/staging/lirc/lirc_sasem.c
@@ -0,0 +1,933 @@
+/*
+ * lirc_sasem.c - USB remote support for LIRC
+ * Version 0.5
+ *
+ * Copyright (C) 2004-2005 Oliver Stabel oliver.sta...@gmx.de
+ *  Tim Davies t...@opensystems.net.au
+ *
+ * This driver was derived from:
+ *   Venky Raju d...@venky.ws
+ *  lirc_imon - LIRC/VFD driver for Ahanix/Soundgraph IMON IR/VFD
+ *   Paul Miller pmill...@users.sourceforge.net's 2003-2004
+ *  lirc_atiusb - USB remote support for LIRC
+ *   Culver Consulting Services he...@culcon.com's 2003
+ *  Sasem OnAir VFD/IR USB driver
+ *
+ *
+ * NOTE - The LCDproc iMon driver should work with this module.  More info at
+ * http://www.frogstorm.info/sasem
+ */
+
+/*
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include linux/errno.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/uaccess.h
+#include linux/usb.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+
+#define MOD_AUTHOR Oliver Stabel oliver.sta...@gmx.de,  \
+   Tim Davies t...@opensystems.net.au
+#define MOD_DESC   USB Driver for Sasem Remote Controller V1.1
+#define MOD_NAME   lirc_sasem
+#define MOD_VERSION0.5
+
+#define VFD_MINOR_BASE 144 /* Same as LCD */
+#define DEVICE_NAMElcd%d
+
+#define BUF_CHUNK_SIZE 8
+#define BUF_SIZE   128
+
+#define IOCTL_LCD_CONTRAST 1
+
+/*** P R O T O T Y P E S ***/
+
+/* USB Callback prototypes */
+static int sasem_probe(struct usb_interface *interface,
+   const struct usb_device_id *id);
+static void sasem_disconnect(struct usb_interface *interface);
+static void usb_rx_callback(struct urb *urb);
+static void usb_tx_callback(struct urb *urb);
+
+/* VFD file_operations function prototypes */
+static int vfd_open(struct inode *inode, struct file *file);
+static long vfd_ioctl(struct file *file, unsigned cmd, unsigned long arg);
+static int vfd_close(struct inode *inode, struct file *file);
+static ssize_t vfd_write(struct file *file, const char *buf,
+   size_t n_bytes, loff_t *pos);
+
+/* LIRC driver function prototypes */
+static int ir_open(void *data);
+static void ir_close(void *data);
+
+/* Driver init/exit prototypes */
+static int __init sasem_init(void);
+static void __exit sasem_exit(void);
+
+/*** G L O B A L S ***/
+#define SASEM_DATA_BUF_SZ  32
+
+struct sasem_context {
+
+   struct usb_device *dev;
+   int vfd_isopen; /* VFD port has been opened   */
+   unsigned int vfd_contrast;  /* VFD contrast*/
+   int ir_isopen;  /* IR port has been opened  */
+   int dev_present;/* USB device presence  */
+   struct mutex ctx_lock;  /* to lock this object  */
+   wait_queue_head_t remove_ok;/* For unexpected USB disconnects */
+
+   struct lirc_driver *driver;
+   struct usb_endpoint_descriptor *rx_endpoint;
+   struct usb_endpoint_descriptor *tx_endpoint;
+   struct urb *rx_urb;
+   struct urb *tx_urb;
+   unsigned char usb_rx_buf[8];
+   unsigned char usb_tx_buf[8];
+
+   struct tx_t {
+   unsigned char data_buf[SASEM_DATA_BUF_SZ]; /* user data buffer 
*/
+   struct completion finished;  /* wait for write to finish  */
+   atomic_t busy;   /* write in progress*/
+   int status;  /* status of tx completion   */
+   } tx;
+
+   /* for dealing with repeat codes (wish there was a toggle bit!) */
+   struct timeval presstime;
+   char lastcode[8];
+   int codesaved;
+};
+
+/* VFD file operations */
+static struct file_operations vfd_fops = {
+   .owner  = THIS_MODULE,
+   .open   = vfd_open,
+   .write  = vfd_write,
+   

[PATCH 10/15] staging/lirc: add lirc_serial driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_serial.c | 1313 
 1 files changed, 1313 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_serial.c

diff --git a/drivers/staging/lirc/lirc_serial.c 
b/drivers/staging/lirc/lirc_serial.c
new file mode 100644
index 000..d2ea3f0
--- /dev/null
+++ b/drivers/staging/lirc/lirc_serial.c
@@ -0,0 +1,1313 @@
+/*
+ * lirc_serial.c
+ *
+ * lirc_serial - Device driver that records pulse- and pause-lengths
+ *(space-lengths) between DDCD event on a serial port.
+ *
+ * Copyright (C) 1996,97 Ralph Metzler r...@thp.uni-koeln.de
+ * Copyright (C) 1998 Trent Piepho xy...@u.washington.edu
+ * Copyright (C) 1998 Ben Pfaff b...@gnu.org
+ * Copyright (C) 1999 Christoph Bartelmus l...@bartelmus.de
+ * Copyright (C) 2007 Andrei Tanas and...@tanas.ca (suspend/resume support)
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+/*
+ * Steve's changes to improve transmission fidelity:
+ *   - for systems with the rdtsc instruction and the clock counter, a
+ * send_pule that times the pulses directly using the counter.
+ * This means that the LIRC_SERIAL_TRANSMITTER_LATENCY fudge is
+ * not needed. Measurement shows very stable waveform, even where
+ * PCI activity slows the access to the UART, which trips up other
+ * versions.
+ *   - For other system, non-integer-microsecond pulse/space lengths,
+ * done using fixed point binary. So, much more accurate carrier
+ * frequency.
+ *   - fine tuned transmitter latency, taking advantage of fractional
+ * microseconds in previous change
+ *   - Fixed bug in the way transmitter latency was accounted for by
+ * tuning the pulse lengths down - the send_pulse routine ignored
+ * this overhead as it timed the overall pulse length - so the
+ * pulse frequency was right but overall pulse length was too
+ * long. Fixed by accounting for latency on each pulse/space
+ * iteration.
+ *
+ * Steve Davies st...@daviesfam.org  July 2001
+ */
+
+#include linux/module.h
+#include linux/errno.h
+#include linux/signal.h
+#include linux/sched.h
+#include linux/fs.h
+#include linux/interrupt.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/serial_reg.h
+#include linux/time.h
+#include linux/string.h
+#include linux/types.h
+#include linux/wait.h
+#include linux/mm.h
+#include linux/delay.h
+#include linux/poll.h
+#include linux/platform_device.h
+
+#include asm/system.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/fcntl.h
+#include linux/spinlock.h
+
+#ifdef CONFIG_LIRC_SERIAL_NSLU2
+#include asm/hardware.h
+#endif
+/* From Intel IXP42X Developer's Manual (#252480-005): */
+/* ftp://download.intel.com/design/network/manuals/25248005.pdf */
+#define UART_IE_IXP42X_UUE   0x40 /* IXP42X UART Unit enable */
+#define UART_IE_IXP42X_RTOIE 0x10 /* IXP42X Receiver Data Timeout int.enable */
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+#define LIRC_DRIVER_NAME lirc_serial
+
+struct lirc_serial {
+   int signal_pin;
+   int signal_pin_change;
+   u8 on;
+   u8 off;
+   long (*send_pulse)(unsigned long length);
+   void (*send_space)(long length);
+   int features;
+   spinlock_t lock;
+};
+
+#define LIRC_HOMEBREW  0
+#define LIRC_IRDEO 1
+#define LIRC_IRDEO_REMOTE  2
+#define LIRC_ANIMAX3
+#define LIRC_IGOR  4
+#define LIRC_NSLU2 5
+
+/*** module parameters ***/
+static int type;
+static int io;
+static int irq;
+static int iommap;
+static int ioshift;
+static int softcarrier = 1;
+static int share_irq;
+static int debug;
+static int sense = -1; /* -1 = auto, 0 = active high, 1 = active low */
+static int txsense;/* 0 = active high, 1 = active low */
+
+#define dprintk(fmt, args...)  \
+   do {\
+   if (debug)  \
+   printk(KERN_DEBUG LIRC_DRIVER_NAME :  \
+  fmt, ## args);   \
+   } while (0)
+
+/* forward declarations */
+static long send_pulse_irdeo(unsigned long length);
+static long 

[PATCH 11/15] staging/lirc: add lirc_sir driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_sir.c | 1282 +++
 1 files changed, 1282 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_sir.c

diff --git a/drivers/staging/lirc/lirc_sir.c b/drivers/staging/lirc/lirc_sir.c
new file mode 100644
index 000..97146d1
--- /dev/null
+++ b/drivers/staging/lirc/lirc_sir.c
@@ -0,0 +1,1282 @@
+/*
+ * LIRC SIR driver, (C) 2000 Milan Pikula w...@fornax.sk
+ *
+ * lirc_sir - Device driver for use with SIR (serial infra red)
+ * mode of IrDA on many notebooks.
+ *
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ *
+ * 2000/09/16 Frank Przybylski m...@frankprzybylski.de :
+ *  added timeout and relaxed pulse detection, removed gap bug
+ *
+ * 2000/12/15 Christoph Bartelmus l...@bartelmus.de :
+ *   added support for Tekram Irmate 210 (sending does not work yet,
+ *   kind of disappointing that nobody was able to implement that
+ *   before),
+ *   major clean-up
+ *
+ * 2001/02/27 Christoph Bartelmus l...@bartelmus.de :
+ *   added support for StrongARM SA1100 embedded microprocessor
+ *   parts cut'n'pasted from sa1100_ir.c (C) 2000 Russell King
+ */
+
+#include linux/module.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/signal.h
+#include linux/fs.h
+#include linux/interrupt.h
+#include linux/ioport.h
+#include linux/kernel.h
+#include linux/serial_reg.h
+#include linux/time.h
+#include linux/string.h
+#include linux/types.h
+#include linux/wait.h
+#include linux/mm.h
+#include linux/delay.h
+#include linux/poll.h
+#include asm/system.h
+#include linux/io.h
+#include asm/irq.h
+#include linux/fcntl.h
+#ifdef LIRC_ON_SA1100
+#include asm/hardware.h
+#ifdef CONFIG_SA1100_COLLIE
+#include asm/arch/tc35143.h
+#include asm/ucb1200.h
+#endif
+#endif
+
+#include linux/timer.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+/* SECTION: Definitions */
+
+/*** Tekram dongle ***/
+#ifdef LIRC_SIR_TEKRAM
+/* stolen from kernel source */
+/* definitions for Tekram dongle */
+#define TEKRAM_115200 0x00
+#define TEKRAM_57600  0x01
+#define TEKRAM_38400  0x02
+#define TEKRAM_19200  0x03
+#define TEKRAM_9600   0x04
+#define TEKRAM_2400   0x08
+
+#define TEKRAM_PW 0x10 /* Pulse select bit */
+
+/* 10bit * 1s/115200bit in milliseconds = 87ms*/
+#define TIME_CONST (1000ul/115200ul)
+
+#endif
+
+#ifdef LIRC_SIR_ACTISYS_ACT200L
+static void init_act200(void);
+#elif defined(LIRC_SIR_ACTISYS_ACT220L)
+static void init_act220(void);
+#endif
+
+/*** SA1100 ***/
+#ifdef LIRC_ON_SA1100
+struct sa1100_ser2_registers {
+   /* HSSP control register */
+   unsigned char hscr0;
+   /* UART registers */
+   unsigned char utcr0;
+   unsigned char utcr1;
+   unsigned char utcr2;
+   unsigned char utcr3;
+   unsigned char utcr4;
+   unsigned char utdr;
+   unsigned char utsr0;
+   unsigned char utsr1;
+} sr;
+
+static int irq = IRQ_Ser2ICP;
+
+#define LIRC_ON_SA1100_TRANSMITTER_LATENCY 0
+
+/* pulse/space ratio of 50/50 */
+static unsigned long pulse_width = (13-LIRC_ON_SA1100_TRANSMITTER_LATENCY);
+/* 100/freq-pulse_width */
+static unsigned long space_width = (13-LIRC_ON_SA1100_TRANSMITTER_LATENCY);
+static unsigned int freq = 38000;  /* modulation frequency */
+static unsigned int duty_cycle = 50;   /* duty cycle of 50% */
+
+#endif
+
+#define RBUF_LEN 1024
+#define WBUF_LEN 1024
+
+#define LIRC_DRIVER_NAME lirc_sir
+
+#define PULSE '['
+
+#ifndef LIRC_SIR_TEKRAM
+/* 9bit * 1s/115200bit in milli seconds = 78.125ms*/
+#define TIME_CONST (900ul/115200ul)
+#endif
+
+
+/* timeout for sequences in jiffies (=5/100s), must be longer than TIME_CONST 
*/
+#define SIR_TIMEOUT(HZ*5/100)
+
+#ifndef LIRC_ON_SA1100
+#ifndef LIRC_IRQ
+#define LIRC_IRQ 4
+#endif
+#ifndef LIRC_PORT
+/* for external dongles, default to com1 */
+#if defined(LIRC_SIR_ACTISYS_ACT200L) || \
+defined(LIRC_SIR_ACTISYS_ACT220L) || \
+defined(LIRC_SIR_TEKRAM)
+#define LIRC_PORT 0x3f8
+#else
+/* onboard sir ports are typically com3 */
+#define LIRC_PORT 0x3e8
+#endif
+#endif
+
+static int io = LIRC_PORT;
+static int irq = LIRC_IRQ;
+static int threshold = 3;
+#endif
+
+static DEFINE_SPINLOCK(timer_lock);
+static struct timer_list timerlist;
+/* time of last signal change 

[PATCH 12/15] staging/lirc: add lirc_streamzap driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_streamzap.c |  821 +
 1 files changed, 821 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_streamzap.c

diff --git a/drivers/staging/lirc/lirc_streamzap.c 
b/drivers/staging/lirc/lirc_streamzap.c
new file mode 100644
index 000..5b46ac4
--- /dev/null
+++ b/drivers/staging/lirc/lirc_streamzap.c
@@ -0,0 +1,821 @@
+/*
+ * Streamzap Remote Control driver
+ *
+ * Copyright (c) 2005 Christoph Bartelmus l...@bartelmus.de
+ *
+ * This driver was based on the work of Greg Wickham and Adrian
+ * Dewhurst. It was substantially rewritten to support correct signal
+ * gaps and now maintains a delay buffer, which is used to present
+ * consistent timing behaviour to user space applications. Without the
+ * delay buffer an ugly hack would be required in lircd, which can
+ * cause sluggish signal decoding in certain situations.
+ *
+ * This driver is based on the USB skeleton driver packaged with the
+ * kernel; copyright (C) 2001-2003 Greg Kroah-Hartman (g...@kroah.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.
+ *
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include linux/kernel.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/module.h
+#include linux/smp_lock.h
+#include linux/completion.h
+#include linux/uaccess.h
+#include linux/usb.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+#define DRIVER_VERSION 1.28
+#define DRIVER_NAMElirc_streamzap
+#define DRIVER_DESCStreamzap Remote Control driver
+
+static int debug;
+
+#define USB_STREAMZAP_VENDOR_ID0x0e9c
+#define USB_STREAMZAP_PRODUCT_ID   0x
+
+/* Use our own dbg macro */
+#define dprintk(fmt, args...)  \
+   do {\
+   if (debug)  \
+   printk(KERN_DEBUG DRIVER_NAME [%d]:   \
+  fmt \n, ## args);  \
+   } while (0)
+
+/* table of devices that work with this driver */
+static struct usb_device_id streamzap_table[] = {
+   /* Streamzap Remote Control */
+   { USB_DEVICE(USB_STREAMZAP_VENDOR_ID, USB_STREAMZAP_PRODUCT_ID) },
+   /* Terminating entry */
+   { }
+};
+
+MODULE_DEVICE_TABLE(usb, streamzap_table);
+
+#define STREAMZAP_PULSE_MASK 0xf0
+#define STREAMZAP_SPACE_MASK 0x0f
+#define STREAMZAP_TIMEOUT0xff
+#define STREAMZAP_RESOLUTION 256
+
+/* number of samples buffered */
+#define STREAMZAP_BUF_LEN 128
+
+enum StreamzapDecoderState {
+   PulseSpace,
+   FullPulse,
+   FullSpace,
+   IgnorePulse
+};
+
+/* Structure to hold all of our device specific stuff
+ *
+ * some remarks regarding locking:
+ * theoretically this struct can be accessed from three threads:
+ *
+ * - from lirc_dev through set_use_inc/set_use_dec
+ *
+ * - from the USB layer throuh probe/disconnect/irq
+ *
+ *   Careful placement of lirc_register_driver/lirc_unregister_driver
+ *   calls will prevent conflicts. lirc_dev makes sure that
+ *   set_use_inc/set_use_dec are not being executed and will not be
+ *   called after lirc_unregister_driver returns.
+ *
+ * - by the timer callback
+ *
+ *   The timer is only running when the device is connected and the
+ *   LIRC device is open. Making sure the timer is deleted by
+ *   set_use_dec will make conflicts impossible.
+ */
+struct usb_streamzap {
+
+   /* usb */
+   /* save off the usb device pointer */
+   struct usb_device   *udev;
+   /* the interface for this device */
+   struct usb_interface*interface;
+
+   /* buffer  dma */
+   unsigned char   *buf_in;
+   dma_addr_t  dma_in;
+   unsigned intbuf_in_len;
+
+   struct usb_endpoint_descriptor *endpoint;
+
+   /* IRQ */
+   struct urb  *urb_in;
+
+   /* lirc */
+   struct lirc_driver  *driver;
+   struct lirc_buffer  *delay_buf;
+
+   /* timer used to support delay buffering */
+   struct timer_list   delay_timer;
+   int timer_running;
+   spinlock_t  timer_lock;
+
+   /* tracks whether we are currently receiving some signal */

[PATCH 13/15] staging/lirc: add lirc_ttusbir driver

2010-07-26 Thread Jarod Wilson
Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_ttusbir.c |  397 +++
 1 files changed, 397 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_ttusbir.c

diff --git a/drivers/staging/lirc/lirc_ttusbir.c 
b/drivers/staging/lirc/lirc_ttusbir.c
new file mode 100644
index 000..1f1da47
--- /dev/null
+++ b/drivers/staging/lirc/lirc_ttusbir.c
@@ -0,0 +1,397 @@
+/*
+ * lirc_ttusbir.c
+ *
+ * lirc_ttusbir - LIRC device driver for the TechnoTrend USB IR Receiver
+ *
+ * Copyright (C) 2007 Stefan Macher st_maker-l...@yahoo.de
+ *
+ * This LIRC driver provides access to the TechnoTrend USB IR Receiver.
+ * The receiver delivers the IR signal as raw sampled true/false data in
+ * isochronous USB packets each of size 128 byte.
+ * Currently the driver reduces the sampling rate by factor of 8 as this
+ * is still more than enough to decode RC-5 - others should be analyzed.
+ * But the driver does not rely on RC-5 it should be able to decode every
+ * IR signal that is not too fast.
+ */
+
+/*
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+#include linux/version.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/slab.h
+#include linux/usb.h
+
+#include media/lirc.h
+#include media/lirc_dev.h
+
+MODULE_DESCRIPTION(TechnoTrend USB IR device driver for LIRC);
+MODULE_AUTHOR(Stefan Macher (st_maker-l...@yahoo.de));
+MODULE_LICENSE(GPL);
+
+/* #define DEBUG */
+#ifdef DEBUG
+#define DPRINTK printk
+#else
+#define DPRINTK(_x_, a...)
+#endif
+
+/* function declarations */
+static int probe(struct usb_interface *intf, const struct usb_device_id *id);
+static void disconnect(struct usb_interface *intf);
+static void urb_complete(struct urb *urb);
+static int set_use_inc(void *data);
+static void set_use_dec(void *data);
+
+static int num_urbs = 2;
+module_param(num_urbs, int, S_IRUGO);
+MODULE_PARM_DESC(num_urbs,
+Number of URBs in queue. Try to increase to 4 in case 
+of problems (default: 2; minimum: 2));
+
+/* table of devices that work with this driver */
+static struct usb_device_id device_id_table[] = {
+   /* TechnoTrend USB IR Receiver */
+   { USB_DEVICE(0x0B48, 0x2003) },
+   /* Terminating entry */
+   { }
+};
+MODULE_DEVICE_TABLE(usb, device_id_table);
+
+/* USB driver definition */
+static struct usb_driver usb_driver = {
+   .name = TTUSBIR,
+   .id_table = (device_id_table[0]),
+   .probe = probe,
+   .disconnect = disconnect,
+};
+
+/* USB device definition */
+struct ttusbir_device {
+   struct usb_driver *usb_driver;
+   struct usb_device *udev;
+   struct usb_interface *interf;
+   struct usb_class_driver class_driver;
+   unsigned int ifnum; /* Interface number to use */
+   unsigned int alt_setting; /* alternate setting to use */
+   unsigned int endpoint; /* Endpoint to use */
+   struct urb **urb; /* num_urb URB pointers*/
+   char **buffer; /* 128 byte buffer for each URB */
+   struct lirc_buffer rbuf; /* Buffer towards LIRC */
+   struct lirc_driver driver;
+   int minor;
+   int last_pulse; /* remembers if last received byte was pulse or space */
+   int last_num; /* remembers how many last bytes appeared */
+   int opened;
+};
+
+/*** LIRC specific functions ***/
+static int set_use_inc(void *data)
+{
+   int i, retval;
+   struct ttusbir_device *ttusbir = data;
+
+   DPRINTK(Sending first URBs\n);
+   /* @TODO Do I need to check if I am already opened */
+   ttusbir-opened = 1;
+
+   for (i = 0; i  num_urbs; i++) {
+   retval = usb_submit_urb(ttusbir-urb[i], GFP_KERNEL);
+   if (retval) {
+   err(%s: usb_submit_urb failed on urb %d,
+   __func__, i);
+   return retval;
+   }
+   }
+   return 0;
+}
+
+static void set_use_dec(void *data)
+{
+   struct ttusbir_device *ttusbir = data;
+
+   DPRINTK(Device closed\n);
+
+   ttusbir-opened = 0;
+}
+
+/*** USB specific functions ***/
+
+/*
+ * This mapping table is used to do a very simple filtering of the
+ * input signal.
+ * For a value with at least 4 bits 

[PATCH 14/15] staging/lirc: add lirc_zilog driver

2010-07-26 Thread Jarod Wilson
Commonly found on several Hauppauge video capture devices.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/lirc/lirc_zilog.c | 1387 +
 1 files changed, 1387 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/lirc_zilog.c

diff --git a/drivers/staging/lirc/lirc_zilog.c 
b/drivers/staging/lirc/lirc_zilog.c
new file mode 100644
index 000..1b013bf
--- /dev/null
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -0,0 +1,1387 @@
+/*
+ * i2c IR lirc driver for devices with zilog IR processors
+ *
+ * Copyright (c) 2000 Gerd Knorr kra...@goldbach.in-berlin.de
+ * modified for PixelView (BT878P+W/FM) by
+ *  Michal Kochanowicz mkoch...@pld.org.pl
+ *  Christoph Bartelmus l...@bartelmus.de
+ * modified for KNC ONE TV Station/Anubis Typhoon TView Tuner by
+ *  Ulrich Mueller ulrich.muelle...@web.de
+ * modified for Asus TV-Box and Creative/VisionTek BreakOut-Box by
+ *  Stefan Jahn ste...@lkcc.org
+ * modified for inclusion into kernel sources by
+ *  Jerome Brock jbr...@users.sourceforge.net
+ * modified for Leadtek Winfast PVR2000 by
+ *  Thomas Reitmayr (treitm...@yahoo.com)
+ * modified for Hauppauge PVR-150 IR TX device by
+ *  Mark Weaver m...@npsl.co.uk
+ * changed name from lirc_pvr150 to lirc_zilog, works on more than pvr-150
+ * Jarod Wilson ja...@redhat.com
+ *
+ * parts are cutpasted from the lirc_i2c.c driver
+ *
+ *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *
+ */
+
+
+#include linux/version.h
+#include linux/module.h
+#include linux/kmod.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/fs.h
+#include linux/poll.h
+#include linux/string.h
+#include linux/timer.h
+#include linux/delay.h
+#include linux/completion.h
+#include linux/errno.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/firmware.h
+#include linux/vmalloc.h
+
+#include linux/mutex.h
+#include linux/kthread.h
+
+#include media/lirc_dev.h
+#include media/lirc.h
+
+struct IR {
+   struct lirc_driver l;
+
+   /* Device info */
+   struct mutex ir_lock;
+   int open;
+
+   /* RX device */
+   struct i2c_client c_rx;
+   int have_rx;
+
+   /* RX device buffer  lock */
+   struct lirc_buffer buf;
+   struct mutex buf_lock;
+
+   /* RX polling thread data */
+   struct completion *t_notify;
+   struct completion *t_notify2;
+   int shutdown;
+   struct task_struct *task;
+
+   /* RX read data */
+   unsigned char b[3];
+
+   /* TX device */
+   struct i2c_client c_tx;
+   int need_boot;
+   int have_tx;
+};
+
+/* Minor - data mapping */
+static struct IR *ir_devices[MAX_IRCTL_DEVICES];
+
+/* Block size for IR transmitter */
+#define TX_BLOCK_SIZE  99
+
+/* Hauppauge IR transmitter data */
+struct tx_data_struct {
+   /* Boot block */
+   unsigned char *boot_data;
+
+   /* Start of binary data block */
+   unsigned char *datap;
+
+   /* End of binary data block */
+   unsigned char *endp;
+
+   /* Number of installed codesets */
+   unsigned int num_code_sets;
+
+   /* Pointers to codesets */
+   unsigned char **code_sets;
+
+   /* Global fixed data template */
+   int fixed[TX_BLOCK_SIZE];
+};
+
+static struct tx_data_struct *tx_data;
+static struct mutex tx_data_lock;
+
+#define zilog_notify(s, args...) printk(KERN_NOTICE KBUILD_MODNAME :  s, \
+   ## args)
+#define zilog_error(s, args...) printk(KERN_ERR KBUILD_MODNAME :  s, ## args)
+
+#define ZILOG_HAUPPAUGE_IR_RX_NAME Zilog/Hauppauge IR RX
+#define ZILOG_HAUPPAUGE_IR_TX_NAME Zilog/Hauppauge IR TX
+
+/* module parameters */
+static int debug;  /* debug output */
+static int disable_rx; /* disable RX device */
+static int disable_tx; /* disable TX device */
+static int minor = -1; /* minor number */
+
+#define dprintk(fmt, args...)  \
+   do {\
+   if (debug)  \
+   printk(KERN_DEBUG KBUILD_MODNAME :  fmt,  \
+## args);  \
+   } while (0)
+
+static int add_to_buf(struct 

[PATCH 15/15] staging/lirc: wire up Kconfig and Makefile bits

2010-07-26 Thread Jarod Wilson
Make the bits under staging/lirc/ buildable, and add a TODO note.

Signed-off-by: Jarod Wilson ja...@redhat.com
---
 drivers/staging/Kconfig   |2 +
 drivers/staging/Makefile  |1 +
 drivers/staging/lirc/Kconfig  |  110 +
 drivers/staging/lirc/Makefile |   19 +++
 drivers/staging/lirc/TODO |8 +++
 5 files changed, 140 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/lirc/Kconfig
 create mode 100644 drivers/staging/lirc/Makefile
 create mode 100644 drivers/staging/lirc/TODO

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 9fc196d..fad88fb 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -155,5 +155,7 @@ source drivers/staging/tidspbridge/Kconfig
 
 source drivers/staging/quickstart/Kconfig
 
+source drivers/staging/lirc/Kconfig
+
 endif # !STAGING_EXCLUDE_BUILD
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 26942aa..27bb127 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_EASYCAP) += easycap/
 obj-$(CONFIG_SOLO6X10) += solo6x10/
 obj-$(CONFIG_TIDSPBRIDGE)  += tidspbridge/
 obj-$(CONFIG_ACPI_QUICKSTART)  += quickstart/
+obj-$(CONFIG_LIRC_STAGING) += lirc/
diff --git a/drivers/staging/lirc/Kconfig b/drivers/staging/lirc/Kconfig
new file mode 100644
index 000..968c2ad
--- /dev/null
+++ b/drivers/staging/lirc/Kconfig
@@ -0,0 +1,110 @@
+#
+# LIRC driver(s) configuration
+#
+menuconfig LIRC_STAGING
+   bool Linux Infrared Remote Control IR receiver/transmitter drivers
+   help
+ Say Y here, and all supported Linux Infrared Remote Control IR and
+ RF receiver and transmitter drivers will be displayed. When paired
+ with a remote control and the lirc daemon, the receiver drivers
+ allow control of your Linux system via remote control.
+
+if LIRC_STAGING
+
+config LIRC_BT829
+tristate BT829 based hardware
+   depends on LIRC_STAGING
+   help
+ Driver for the IR interface on BT829-based hardware
+
+config LIRC_ENE0100
+   tristate ENE KB3924/ENE0100 CIR Port Reciever
+   depends on LIRC_STAGING
+   help
+ This is a driver for CIR port handled by ENE KB3924 embedded
+ controller found on some notebooks.
+ It appears on PNP list as ENE0100.
+
+config LIRC_I2C
+   tristate I2C Based IR Receivers
+   depends on LIRC_STAGING
+   help
+ Driver for I2C-based IR receivers, such as those commonly
+ found onboard Hauppauge PVR-150/250/350 video capture cards
+
+config LIRC_IGORPLUGUSB
+   tristate Igor Cesko's USB IR Receiver
+   depends on LIRC_STAGING  USB
+   help
+ Driver for Igor Cesko's USB IR Receiver
+
+config LIRC_IMON
+   tristate Legacy SoundGraph iMON Receiver and Display
+   depends on LIRC_STAGING
+   help
+ Driver for the original SoundGraph iMON IR Receiver and Display
+
+ Current generation iMON devices use the input layer imon driver.
+
+config LIRC_IT87
+   tristate ITE IT87XX CIR Port Receiver
+   depends on LIRC_STAGING
+   help
+ Driver for the ITE IT87xx IR Receiver
+
+config LIRC_ITE8709
+   tristate ITE8709 CIR Port Receiver
+   depends on LIRC_STAGING  PNP
+   help
+ Driver for the ITE8709 IR Receiver
+
+config LIRC_PARALLEL
+   tristate Homebrew Parallel Port Receiver
+   depends on LIRC_STAGING  !SMP
+   help
+ Driver for Homebrew Parallel Port Receivers
+
+config LIRC_SASEM
+   tristate Sasem USB IR Remote
+   depends on LIRC_STAGING
+   help
+ Driver for the Sasem OnAir Remocon-V or Dign HV5 HTPC IR/VFD Module
+
+config LIRC_SERIAL
+   tristate Homebrew Serial Port Receiver
+   depends on LIRC_STAGING
+   help
+ Driver for Homebrew Serial Port Receivers
+
+config LIRC_SERIAL_TRANSMITTER
+   bool Serial Port Transmitter
+   default y
+   depends on LIRC_SERIAL
+   help
+ Serial Port Transmitter support
+
+config LIRC_SIR
+   tristate Built-in SIR IrDA port
+   depends on LIRC_STAGING
+   help
+ Driver for the SIR IrDA port
+
+config LIRC_STREAMZAP
+   tristate Streamzap PC Receiver
+   depends on LIRC_STAGING
+   help
+ Driver for the Streamzap PC Receiver
+
+config LIRC_TTUSBIR
+   tristate Technotrend USB IR Receiver
+   depends on LIRC_STAGING  USB
+   help
+ Driver for the Technotrend USB IR Receiver
+
+config LIRC_ZILOG
+   tristate Zilog/Hauppauge IR Transmitter
+   depends on LIRC_STAGING
+   help
+ Driver for the Zilog/Hauppauge IR Transmitter, found on
+ PVR-150/500, HVR-1200/1250/1700/1800, HD-PVR and other cards
+endif
diff --git a/drivers/staging/lirc/Makefile b/drivers/staging/lirc/Makefile
new file mode 100644
index 000..a019182
--- /dev/null
+++