date:20120105

Hello Everyone,

A very happy new year 2012! :)

This patchset is an RFC for the way videobuf2 can be adapted to add support for
DMA buffer sharing framework[1].

The original patch-set for the idea, and PoC of buffer sharing was by 
Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing
between two v4l2 devices[2]. This RFC is needed to adapt these patches to the
changes that have happened in the DMA buffer sharing framework over past few
months.

To begin with, I have tried to adapt only the dma-contig allocator, and only as
a user of dma-buf buffer. I am currently working on the v4l2-as-an-exporter
changes, and will share as soon as I get it in some shape.

As with the PoC [2], the handle for sharing buffers is a file-descriptor (fd).
The usage documentation is also a part of [1].

So, the current RFC has the following limitations:
- Only buffer sharing as a buffer user,
- doesn't handle cases where even for a contiguous buffer, the sg_table can have
   more than one scatterlist entry.


Thanks and best regards,
~Sumit.

[1]: dma-buf patchset at: https://lkml.org/lkml/2011/12/26/29
[2]: http://lwn.net/Articles/454389

Sumit Semwal (4):
  v4l: Add DMABUF as a memory type
  v4l:vb2: add support for shared buffer (dma_buf)
  v4l:vb: remove warnings about MEMORY_DMABUF
  v4l:vb2: Add dma-contig allocator as dma_buf user

 drivers/media/video/videobuf-core.c|4 +
 drivers/media/video/videobuf2-core.c   |  186 +++-
 drivers/media/video/videobuf2-dma-contig.c |  125 +++
 include/linux/videodev2.h  |8 ++
 include/media/videobuf2-core.h |   30 +
 5 files changed, 352 insertions(+), 1 deletions(-)

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

[RFCv1 1/4] v4l: Add DMABUF as a memory type

Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 include/linux/videodev2.h |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..3c0ade1 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -185,6 +185,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR  = 2,
V4L2_MEMORY_OVERLAY  = 3,
+   V4L2_MEMORY_DMABUF   = 4,
 };
 
 /* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -574,6 +575,8 @@ struct v4l2_requestbuffers {
  * should be passed to mmap() called on the video node)
  * @userptr:   when memory is V4L2_MEMORY_USERPTR, a userspace pointer
  * pointing to this plane
+ * @fd:when memory is V4L2_MEMORY_DMABUF, a userspace 
file
+ * descriptor associated with this plane
  * @data_offset:   offset in the plane to the start of data; usually 0,
  * unless there is a header in front of the data
  *
@@ -588,6 +591,7 @@ struct v4l2_plane {
union {
__u32   mem_offset;
unsigned long   userptr;
+   int fd;
} m;
__u32   data_offset;
__u32   reserved[11];
@@ -610,6 +614,9 @@ struct v4l2_plane {
  * (or a cookie that should be passed to mmap() as offset)
  * @userptr:   for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR;
  * a userspace pointer pointing to this buffer
+ * @fd:for non-multiplanar buffers with
+ * memory == V4L2_MEMORY_DMABUF; a userspace file descriptor
+ * associated with this buffer
  * @planes:for multiplanar buffers; userspace pointer to the array of plane
  * info structs for this buffer
  * @length:size in bytes of the buffer (NOT its payload) for single-plane
@@ -636,6 +643,7 @@ struct v4l2_buffer {
__u32   offset;
unsigned long   userptr;
struct v4l2_plane *planes;
+   int fd;
} m;
__u32   length;
__u32   input;
-- 
1.7.5.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

[RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)

This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.

For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A sample allocator of
dma-buf shared buffer is given at [1]]

[1]: Rob Clark's DRM:
   https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 drivers/media/video/videobuf2-core.c |  186 +-
 include/media/videobuf2-core.h   |   30 ++
 2 files changed, 215 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index 95a3f5e..6cd2f97 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -107,6 +107,27 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
 }
 
 /**
+ * __vb2_buf_dmabuf_put() - release memory associated with
+ * a DMABUF shared buffer
+ */
+static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
+{
+   struct vb2_queue *q = vb-vb2_queue;
+   unsigned int plane;
+
+   for (plane = 0; plane  vb-num_planes; ++plane) {
+   void *mem_priv = vb-planes[plane].mem_priv;
+
+   if (mem_priv) {
+   call_memop(q, plane, detach_dmabuf, mem_priv);
+   dma_buf_put(vb-planes[plane].dbuf);
+   vb-planes[plane].dbuf = NULL;
+   vb-planes[plane].mem_priv = NULL;
+   }
+   }
+}
+
+/**
  * __setup_offsets() - setup unique offsets (cookies) for every plane in
  * every buffer on the queue
  */
@@ -228,6 +249,8 @@ static void __vb2_free_mem(struct vb2_queue *q, unsigned 
int buffers)
/* Free MMAP buffers or release USERPTR buffers */
if (q-memory == V4L2_MEMORY_MMAP)
__vb2_buf_mem_free(vb);
+   if (q-memory == V4L2_MEMORY_DMABUF)
+   __vb2_buf_dmabuf_put(vb);
else
__vb2_buf_userptr_put(vb);
}
@@ -350,6 +373,13 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, 
struct v4l2_buffer *b)
 */
memcpy(b-m.planes, vb-v4l2_planes,
b-length * sizeof(struct v4l2_plane));
+
+   if (q-memory == V4L2_MEMORY_DMABUF) {
+   unsigned int plane;
+   for (plane = 0; plane  vb-num_planes; ++plane) {
+   b-m.planes[plane].m.fd = 0;
+   }
+   }
} else {
/*
 * We use length and offset in v4l2_planes array even for
@@ -361,6 +391,8 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct 
v4l2_buffer *b)
b-m.offset = vb-v4l2_planes[0].m.mem_offset;
else if (q-memory == V4L2_MEMORY_USERPTR)
b-m.userptr = vb-v4l2_planes[0].m.userptr;
+   else if (q-memory == V4L2_MEMORY_DMABUF)
+   b-m.fd = 0;
}
 
/*
@@ -452,6 +484,21 @@ static int __verify_mmap_ops(struct vb2_queue *q)
 }
 
 /**
+ * __verify_dmabuf_ops() - verify that all memory operations required for
+ * DMABUF queue type have been provided
+ */
+static int __verify_dmabuf_ops(struct vb2_queue *q)
+{
+   if (!(q-io_modes  VB2_DMABUF) || !q-mem_ops-attach_dmabuf
+   || !q-mem_ops-detach_dmabuf
+   || !q-mem_ops-map_dmabuf
+   || !q-mem_ops-unmap_dmabuf)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
  * vb2_reqbufs() - Initiate streaming
  * @q: videobuf2 queue
  * @req:   struct passed from userspace to vidioc_reqbufs handler in driver
@@ -485,6 +532,7 @@ int vb2_reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req)
}
 
if (req-memory != V4L2_MEMORY_MMAP
+req-memory != V4L2_MEMORY_DMABUF
 req-memory != V4L2_MEMORY_USERPTR) {
dprintk(1, reqbufs: unsupported memory type\n);
return -EINVAL;
@@ -514,6 +562,11 @@ int vb2_reqbufs(struct vb2_queue *q, struct 
v4l2_requestbuffers *req)
return -EINVAL;
}
 
+   if (req-memory == V4L2_MEMORY_DMABUF  __verify_dmabuf_ops(q)) {
+   dprintk(1, reqbufs: DMABUF for current setup unsupported\n);
+   return -EINVAL;
+   }
+
if (req-count == 0 || q-num_buffers != 0 || q-memory != req-memory) 
{
/*
 * We already have buffers allocated, so first check if they
@@ -621,7 +674,8 @@ int vb2_create_bufs(struct vb2_queue *q, struct 
v4l2_create_buffers

[RFCv1 4/4] v4l:vb2: Add dma-contig allocator as dma_buf user

This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.

Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
---
 drivers/media/video/videobuf2-dma-contig.c |  125 
 1 files changed, 125 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index f17ad98..e671371 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -13,6 +13,8 @@
 #include linux/module.h
 #include linux/slab.h
 #include linux/dma-mapping.h
+#include linux/scatterlist.h
+#include linux/dma-buf.h
 
 #include media/videobuf2-core.h
 #include media/videobuf2-memops.h
@@ -27,6 +29,7 @@ struct vb2_dc_buf {
dma_addr_t  dma_addr;
unsigned long   size;
struct vm_area_struct   *vma;
+   struct dma_buf_attachment   *db_attach;
atomic_trefcount;
struct vb2_vmarea_handler   handler;
 };
@@ -37,6 +40,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned 
long size)
 {
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
+   /* TODO: add db_attach processing while adding DMABUF as exporter */
 
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
@@ -106,6 +110,8 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
+   WARN_ON(buf-db_attach);
+
return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
  vb2_common_vm_ops, buf-handler);
 }
@@ -148,6 +154,121 @@ static void vb2_dma_contig_put_userptr(void *mem_priv)
kfree(buf);
 }
 
+static int vb2_dma_contig_map_dmabuf(void *mem_priv,
+   enum dma_data_direction direction)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct dma_buf *dmabuf;
+   struct sg_table *sg;
+
+   if (!buf || !buf-db_attach) {
+   printk(KERN_ERR No dma buffer to pin\n);
+   return -EINVAL;
+   }
+
+   WARN_ON(buf-dma_addr);
+
+   if (direction == DMA_NONE) {
+   printk(KERN_ERR Incorrect DMA direction\n);
+   return -EINVAL;
+   }
+
+   dmabuf = buf-db_attach-dmabuf;
+
+   /* get the associated scatterlist for this buffer */
+   sg = dma_buf_map_attachment(buf-db_attach, direction);
+
+   if (!sg) {
+   printk(KERN_ERR Error getting dmabuf scatterlist\n);
+   return -EINVAL;
+   }
+
+   /*
+*  convert sglist to paddr:
+*  Assumption: for dma-contig, dmabuf would map to single entry
+*  Will return an error if it has more than one.
+*/
+   if (sg-nents  1) {
+   printk(KERN_ERR
+   dmabuf scatterlist has more than 1 entry\n);
+   return -EINVAL;
+   }
+
+   buf-dma_addr = sg_dma_address(sg-sgl);
+   /* TODO: check the buffer size as per S_FMT */
+   buf-size = sg_dma_len(sg-sgl);
+
+   /* save this scatterlist in dmabuf for put_scatterlist */
+   dmabuf-priv = sg;
+
+   return 0;
+}
+
+static void vb2_dma_contig_unmap_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct dma_buf *dmabuf;
+   struct sg_table *sg;
+
+   if (!buf || !buf-db_attach)
+   return;
+
+   WARN_ON(!buf-dma_addr);
+
+   dmabuf = buf-db_attach-dmabuf;
+   sg = dmabuf-priv;
+
+   /* Put the sg for this buffer */
+   dma_buf_unmap_attachment(buf-db_attach, sg);
+
+   buf-dma_addr = 0;
+   buf-size = 0;
+}
+
+static void *vb2_dma_contig_attach_dmabuf(void *alloc_ctx, struct dma_buf 
*dbuf)
+{
+   struct vb2_dc_conf *conf = alloc_ctx;
+   struct vb2_dc_buf *buf;
+   struct dma_buf_attachment *dba;
+
+   buf = kzalloc(sizeof *buf, GFP_KERNEL);
+   if (!buf)
+   return ERR_PTR(-ENOMEM);
+
+   /* create attachment for the dmabuf with the user device */
+   dba = dma_buf_attach(dbuf, conf-dev);
+   if (IS_ERR(dba)) {
+   printk(KERN_ERR failed to attach dmabuf\n);
+   kfree(buf);
+   return dba;
+   }
+
+   buf-conf = conf;
+   buf-size = dba-dmabuf-size;
+   buf-db_attach = dba;
+   buf-dma_addr = 0; /* dma_addr is available only after map */
+
+   return buf;
+}
+
+static void vb2_dma_contig_detach_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+
+   if (!buf)
+   return;
+
+   if (buf-dma_addr) {
+   vb2_dma_contig_unmap_dmabuf(buf);
+   }
+
+   /* detach this attachment */
+   dma_buf_detach(buf-db_attach-dmabuf, buf-db_attach);
+

[RFCv1 3/4] v4l:vb: remove warnings about MEMORY_DMABUF

Adding DMABUF memory type causes videobuf to complain about not using it
in some switch cases. This patch removes these warnings.

Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
 drivers/media/video/videobuf-core.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index de4fa4e..b457c8b 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -335,6 +335,9 @@ static void videobuf_status(struct videobuf_queue *q, 
struct v4l2_buffer *b,
case V4L2_MEMORY_OVERLAY:
b-m.offset  = vb-boff;
break;
+   case V4L2_MEMORY_DMABUF:
+   /* DMABUF is not handled in videobuf framework */
+   break;
}
 
b-flags= 0;
@@ -411,6 +414,7 @@ int __videobuf_mmap_setup(struct videobuf_queue *q,
break;
case V4L2_MEMORY_USERPTR:
case V4L2_MEMORY_OVERLAY:
+   case V4L2_MEMORY_DMABUF:
/* nothing */
break;
}
-- 
1.7.5.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: [PATCH 1/1] omap3isp: Check media bus code on links

2012-01-05 Thread Sakari Ailus

Hi Laurent,

On Thu, Jan 05, 2012 at 11:12:14AM +0100, Laurent Pinchart wrote:
 Hi Sakari,
 
 On Thursday 05 January 2012 10:10:19 Sakari Ailus wrote:
  Check media bus code on links. The user could configure different formats
  at different ends of the link, say, 8 bits-per-pixel in the source and 10
  bits-per-pixel in the sink. This leads to interesting and typically
  undesired results image-wise.
  
  Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
  ---
   drivers/media/video/omap3isp/ispvideo.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/media/video/omap3isp/ispvideo.c
  b/drivers/media/video/omap3isp/ispvideo.c index 615dae5..dbdd5b4 100644
  --- a/drivers/media/video/omap3isp/ispvideo.c
  +++ b/drivers/media/video/omap3isp/ispvideo.c
  @@ -352,7 +352,8 @@ static int isp_video_validate_pipeline(struct
  isp_pipeline *pipe)
  
  /* Check if the two ends match */
  if (fmt_source.format.width != fmt_sink.format.width ||
  -   fmt_source.format.height != fmt_sink.format.height)
  +   fmt_source.format.height != fmt_sink.format.height ||
  +   fmt_source.format.code != fmt_sink.format.code)
 
 If you scroll down a bit, the check is already present in the second branch 
 of 
 the if statement. The reason why the driver doesn't enforce the same format 
 unconditionally is that the lane shifter on the CCDC sink link can shift 
 data, 
 so a special check is needed there.

Ooops. My mistake --- I had made an error in implementing
validate_pipeline() op. Somehow my assumption was the resulted issue would
be present in the original code.

You may thus ignore this patch completely.

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
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

[GIT PULL] davinci vpbe pull request

2012-01-05 Thread Hadli, Manjunath

Hi Mauro,
 Can you please pull these vpbe patches which add the support for
 DM365 and DM355 display?

 The 3 vpbe patches were sent to you as a pull request earlier. Please  see 
this mail:
 
http://linux.omap.com/pipermail/davinci-linux-open-source/2011-November/023496.html

 I have now rebased these to 3.2 since my earlier pull request was  not based 
on commits on Linus's tree.
 As a result they look like recent commits, but have actually been  around for 
a long time.

 Thx,
 -Manju

The following changes since commit 805a6af8dba5dfdd35ec35dc52ec0122400b2610:
  Linus Torvalds (1):
Linux 3.2

are available in the git repository at:

  git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git for-mauro-v3.3

Manjunath Hadli (3):
  davinci vpbe: add dm365 VPBE display driver changes
  davinci vpbe: add dm365 and dm355 specific OSD changes
  davinci vpbe: add VENC block changes to enable dm365 and dm355

 drivers/media/video/davinci/vpbe.c  |   48 +++-
 drivers/media/video/davinci/vpbe_osd.c  |  473 --- 
 drivers/media/video/davinci/vpbe_venc.c |  205 --
 include/media/davinci/vpbe.h|   16 +
 include/media/davinci/vpbe_venc.h   |4 +
 5 files changed, 678 insertions(+), 68 deletions(-)
--
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

Fix Leadtek DTV2000H radio tuner

2012-01-05 Thread Miroslav Slugeň

Resending signed-off version for kernel 3.2
Signed-off-by: Miroslav Slugen thunder@gmail.com
From dadfa45664f765297e03e73a907ac04bd55e9b25 Mon Sep 17 00:00:00 2001
From: Miroslav Slugen thunder@gmail.com
Date: Tue, 13 Dec 2011 19:36:15 +0100
Subject: [PATCH] Leadtek DTV2000H J has Philips FMD1216MEX tuner, this patch fixed not working
 radio part, but some stations are still not visible.

---
diff -Naurp a/drivers/media/video/cx88/cx88-cards.c b/drivers/media/video/cx88/cx88-cards.c
--- a/drivers/media/video/cx88/cx88-cards.c	2012-01-05 00:55:44.0 +0100
+++ b/drivers/media/video/cx88/cx88-cards.c	2012-01-05 12:38:27.177910802 +0100
@@ -1306,7 +1306,7 @@ static const struct cx88_board cx88_boar
 	},
 	[CX88_BOARD_WINFAST_DTV2000H_J] = {
 		.name   = WinFast DTV2000 H rev. J,
-		.tuner_type = TUNER_PHILIPS_FMD1216ME_MK3,
+		.tuner_type = TUNER_PHILIPS_FMD1216MEX_MK3,
 		.radio_type = UNSET,
 		.tuner_addr = ADDR_UNSET,
 		.radio_addr = ADDR_UNSET,
@@ -3232,6 +3232,7 @@ static void cx88_card_setup_pre_i2c(stru
 		cx_set(MO_GP0_IO, 0x1010);
 		break;
 
+	case CX88_BOARD_WINFAST_DTV2000H_J:
 	case CX88_BOARD_HAUPPAUGE_HVR3000:
 	case CX88_BOARD_HAUPPAUGE_HVR4000:
 		/* Init GPIO */
diff -Naurp a/drivers/media/video/cx88/cx88-dvb.c b/drivers/media/video/cx88/cx88-dvb.c
--- a/drivers/media/video/cx88/cx88-dvb.c	2012-01-05 00:55:44.0 +0100
+++ b/drivers/media/video/cx88/cx88-dvb.c	2012-01-05 12:38:27.177910802 +0100
@@ -999,7 +999,6 @@ static int dvb_register(struct cx8802_de
 		}
 		break;
 	case CX88_BOARD_WINFAST_DTV2000H:
-	case CX88_BOARD_WINFAST_DTV2000H_J:
 	case CX88_BOARD_HAUPPAUGE_HVR1100:
 	case CX88_BOARD_HAUPPAUGE_HVR1100LP:
 	case CX88_BOARD_HAUPPAUGE_HVR1300:
@@ -1013,6 +1012,17 @@ static int dvb_register(struct cx8802_de
 goto frontend_detach;
 		}
 		break;
+	case CX88_BOARD_WINFAST_DTV2000H_J:
+		fe0-dvb.frontend = dvb_attach(cx22702_attach,
+	   hauppauge_hvr_config,
+	   core-i2c_adap);
+		if (fe0-dvb.frontend != NULL) {
+			if (!dvb_attach(simple_tuner_attach, fe0-dvb.frontend,
+   core-i2c_adap, 0x61,
+   TUNER_PHILIPS_FMD1216MEX_MK3))
+goto frontend_detach;
+		}
+		break;
 	case CX88_BOARD_HAUPPAUGE_HVR3000:
 		/* MFE frontend 1 */
 		mfe_shared = 1;
diff -Naurp a/drivers/media/video/tuner-core.c b/drivers/media/video/tuner-core.c
--- a/drivers/media/video/tuner-core.c	2012-01-05 00:55:44.0 +0100
+++ b/drivers/media/video/tuner-core.c	2012-01-05 12:38:27.177910802 +0100
@@ -326,6 +326,7 @@ static void set_type(struct i2c_client *
 		t-mode_mask = T_RADIO;
 		break;
 	case TUNER_PHILIPS_FMD1216ME_MK3:
+	case TUNER_PHILIPS_FMD1216MEX_MK3:
 		buffer[0] = 0x0b;
 		buffer[1] = 0xdc;
 		buffer[2] = 0x9c;

Re: subdev support for querying struct v4l2_input *

2012-01-05 Thread Steven Toth

 In the cx23885 driver as part of vidioc_enum_input call, I have a need
 to return V4L2_IN_ST_NO_SIGNAL in the status
 field as part of struct v4l2_input. Thus, when no signal is detected
 by the video decoder it can be signalled to the calling application.

 v4l2_subdev_video_ops-g_input_status

I'm blind.

That will work, thanks Scott.

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

[PATCH v2] media: tvp5150: Add mbus_fmt callbacks.

2012-01-05 Thread Javier Martin

These callbacks allow a host video driver
to poll video formats supported by tvp5150.

---
Changes since v1:
 Fix standard handling in tvp5150_mbus_fmt()
---
 drivers/media/video/tvp5150.c |   67 +
 1 files changed, 67 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index 26cc75b..c58c8d5 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -778,6 +778,70 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
return -EINVAL;
 }
 
+static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
+{
+   int val = tvp5150_read(sd, TVP5150_STATUS_REG_5);
+
+   switch (val  0x0F) {
+   case 0x01:
+   return V4L2_STD_NTSC;
+   case 0x03:
+   return V4L2_STD_PAL;
+   case 0x05:
+   return V4L2_STD_PAL_M;
+   case 0x07:
+   return V4L2_STD_PAL_N | V4L2_STD_PAL_Nc;
+   case 0x09:
+   return V4L2_STD_NTSC_443;
+   case 0xb:
+   return V4L2_STD_SECAM;
+   default:
+   return V4L2_STD_UNKNOWN;
+   }
+}
+
+static int tvp5150_enum_mbus_fmt(struct v4l2_subdev *sd, unsigned index,
+   enum v4l2_mbus_pixelcode *code)
+{
+   if (index)
+   return -EINVAL;
+
+   *code = V4L2_MBUS_FMT_YUYV8_2X8;
+   return 0;
+}
+
+static int tvp5150_mbus_fmt(struct v4l2_subdev *sd,
+   struct v4l2_mbus_framefmt *f)
+{
+   struct tvp5150 *decoder = to_tvp5150(sd);
+   v4l2_std_id std;
+
+   if (f == NULL)
+   return -EINVAL;
+
+   tvp5150_reset(sd, 0);
+
+   /* Calculate height and width based on current standard */
+   if (decoder-norm == V4L2_STD_ALL)
+   std = tvp5150_read_std(sd);
+   else
+   std = decoder-norm;
+
+   f-width = 720;
+   if (std  V4L2_STD_525_60)
+   f-height = 480;
+   else
+   f-height = 576;
+
+   f-code = V4L2_MBUS_FMT_YUYV8_2X8;
+   f-field = V4L2_FIELD_SEQ_TB;
+   f-colorspace = V4L2_COLORSPACE_SMPTE170M;
+
+   v4l2_dbg(1, debug, sd, width = %d, height = %d\n, f-width,
+   f-height);
+   return 0;
+}
+
 /
I2C Command
  /
@@ -930,6 +994,9 @@ static const struct v4l2_subdev_tuner_ops tvp5150_tuner_ops 
= {
 
 static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_routing = tvp5150_s_routing,
+   .enum_mbus_fmt = tvp5150_enum_mbus_fmt,
+   .s_mbus_fmt = tvp5150_mbus_fmt,
+   .try_mbus_fmt = tvp5150_mbus_fmt,
 };
 
 static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
-- 
1.7.0.4

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

[PATCH 3/5] [media] drxk_hard: fix locking issues when changing the delsys

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/dvb/frontends/drxk_hard.c |   45 --
 drivers/media/dvb/frontends/drxk_hard.h |1 -
 2 files changed, 24 insertions(+), 22 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
b/drivers/media/dvb/frontends/drxk_hard.c
index a95fb44..97670db 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6188,7 +6188,6 @@ static int drxk_sleep(struct dvb_frontend *fe)
 
dprintk(1, \n);
ShutDown(state);
-   mutex_unlock(state-ctlock);
return 0;
 }
 
@@ -6203,7 +6202,7 @@ static int drxk_gate_ctrl(struct dvb_frontend *fe, int 
enable)
 static int drxk_set_parameters(struct dvb_frontend *fe)
 {
struct dtv_frontend_properties *p = fe-dtv_property_cache;
-   u32 delsys  = p-delivery_system;
+   u32 delsys  = p-delivery_system, old_delsys;
struct drxk_state *state = fe-demodulator_priv;
u32 IF;
 
@@ -6221,28 +6220,33 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
fe-ops.tuner_ops.set_params(fe);
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 0);
+
+   old_delsys = state-props.delivery_system;
state-props = *p;
 
-   switch (delsys) {
-   case SYS_DVBC_ANNEX_A:
-   case SYS_DVBC_ANNEX_C:
-   if (!state-m_hasDVBC)
-   return -EINVAL;
-   state-m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? true : 
false;
-   if (state-m_itut_annex_c)
-   SetOperationMode(state, OM_QAM_ITU_C);
-   else
-   SetOperationMode(state, OM_QAM_ITU_A);
+   if (old_delsys != delsys) {
+   ShutDown(state);
+   switch (delsys) {
+   case SYS_DVBC_ANNEX_A:
+   case SYS_DVBC_ANNEX_C:
+   if (!state-m_hasDVBC)
+   return -EINVAL;
+   state-m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? 
true : false;
+   if (state-m_itut_annex_c)
+   SetOperationMode(state, OM_QAM_ITU_C);
+   else
+   SetOperationMode(state, OM_QAM_ITU_A);
+   break;
+   state-m_itut_annex_c = true;
break;
-   state-m_itut_annex_c = true;
-   break;
-   case SYS_DVBT:
-   if (!state-m_hasDVBT)
+   case SYS_DVBT:
+   if (!state-m_hasDVBT)
+   return -EINVAL;
+   SetOperationMode(state, OM_DVBT);
+   break;
+   default:
return -EINVAL;
-   SetOperationMode(state, OM_DVBT);
-   break;
-   default:
-   return -EINVAL;
+   }
}
 
fe-ops.tuner_ops.get_if_frequency(fe, IF);
@@ -6405,7 +6409,6 @@ struct dvb_frontend *drxk_attach(const struct drxk_config 
*config,
state-m_GPIO = ~state-antenna_gpio;
 
mutex_init(state-mutex);
-   mutex_init(state-ctlock);
 
memcpy(state-frontend.ops, drxk_ops, sizeof(drxk_ops));
state-frontend.demodulator_priv = state;
diff --git a/drivers/media/dvb/frontends/drxk_hard.h 
b/drivers/media/dvb/frontends/drxk_hard.h
index 7e3e4cf..3a58b73 100644
--- a/drivers/media/dvb/frontends/drxk_hard.h
+++ b/drivers/media/dvb/frontends/drxk_hard.h
@@ -204,7 +204,6 @@ struct drxk_state {
void  *priv;
 
struct mutex mutex;
-   struct mutex ctlock;
 
u32m_Instance;   /** Channel 1,2,3 or 4 */
 
-- 
1.7.7.5

--
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] [media] drxk: remove ops.info.frequency_stepsize from DVB-C

ops.info.frequency_stepsize is used only for DVB-T  friends. For
DVB-C, the step size is calculated using the symbol rate.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/dvb/frontends/drxk_hard.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
b/drivers/media/dvb/frontends/drxk_hard.c
index c8213f6..77e78f4 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6356,7 +6356,6 @@ static struct dvb_frontend_ops drxk_c_ops = {
.delsys = { SYS_DVBC_ANNEX_A, SYS_DVBC_ANNEX_C },
.info = {
 .name = DRXK DVB-C,
-.frequency_stepsize = 62500,
 .frequency_min = 4700,
 .frequency_max = 86200,
 .symbol_rate_min = 87,
-- 
1.7.7.5

--
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] [media] dvb_frontend: regression fix: add a missing inc inside the loop

without it, the loop will run forever!

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 678e329..cd3c0f6 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1481,6 +1481,7 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
__func__, desired_system);
return 0;
}
+   ncaps++;
}
type = dvbv3_type(desired_system);
 
-- 
1.7.7.5

--
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] [media] drxk: create only one frontend for both DVB-C and DVB-T

Instead of creating two DVB frontend entries for the same device,
create just one entry, and fill the delivery_system according with
the supported standards.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/dvb/ddbridge/ddbridge-core.c |2 +-
 drivers/media/dvb/frontends/drxk.h |6 +-
 drivers/media/dvb/frontends/drxk_hard.c|  192 
 drivers/media/dvb/frontends/drxk_hard.h|3 +-
 drivers/media/dvb/ngene/ngene-cards.c  |2 +-
 drivers/media/video/em28xx/em28xx-dvb.c|   28 +
 6 files changed, 88 insertions(+), 145 deletions(-)

diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c 
b/drivers/media/dvb/ddbridge/ddbridge-core.c
index ba9a643..2f31648 100644
--- a/drivers/media/dvb/ddbridge/ddbridge-core.c
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -580,7 +580,7 @@ static int demod_attach_drxk(struct ddb_input *input)
memset(config, 0, sizeof(config));
config.adr = 0x29 + (input-nr  1);
 
-   fe = input-fe = dvb_attach(drxk_attach, config, i2c, input-fe2);
+   fe = input-fe = dvb_attach(drxk_attach, config, i2c);
if (!input-fe) {
printk(KERN_ERR No DRXK found!\n);
return -ENODEV;
diff --git a/drivers/media/dvb/frontends/drxk.h 
b/drivers/media/dvb/frontends/drxk.h
index 870432f..0209818 100644
--- a/drivers/media/dvb/frontends/drxk.h
+++ b/drivers/media/dvb/frontends/drxk.h
@@ -37,12 +37,10 @@ struct drxk_config {
 #if defined(CONFIG_DVB_DRXK) || (defined(CONFIG_DVB_DRXK_MODULE) \
  defined(MODULE))
 extern struct dvb_frontend *drxk_attach(const struct drxk_config *config,
-   struct i2c_adapter *i2c,
-   struct dvb_frontend **fe_t);
+   struct i2c_adapter *i2c);
 #else
 static inline struct dvb_frontend *drxk_attach(const struct drxk_config 
*config,
-   struct i2c_adapter *i2c,
-   struct dvb_frontend **fe_t)
+   struct i2c_adapter *i2c)
 {
 printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
 return NULL;
diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
b/drivers/media/dvb/frontends/drxk_hard.c
index 77e78f4..a95fb44 100644
--- a/drivers/media/dvb/frontends/drxk_hard.c
+++ b/drivers/media/dvb/frontends/drxk_hard.c
@@ -6174,7 +6174,7 @@ error:
return status;
 }
 
-static void drxk_c_release(struct dvb_frontend *fe)
+static void drxk_release(struct dvb_frontend *fe)
 {
struct drxk_state *state = fe-demodulator_priv;
 
@@ -6182,21 +6182,7 @@ static void drxk_c_release(struct dvb_frontend *fe)
kfree(state);
 }
 
-static int drxk_c_init(struct dvb_frontend *fe)
-{
-   struct drxk_state *state = fe-demodulator_priv;
-
-   dprintk(1, \n);
-   if (mutex_trylock(state-ctlock) == 0)
-   return -EBUSY;
-   if (state-m_itut_annex_c)
-   SetOperationMode(state, OM_QAM_ITU_C);
-   else
-   SetOperationMode(state, OM_QAM_ITU_A);
-   return 0;
-}
-
-static int drxk_c_sleep(struct dvb_frontend *fe)
+static int drxk_sleep(struct dvb_frontend *fe)
 {
struct drxk_state *state = fe-demodulator_priv;
 
@@ -6229,24 +6215,36 @@ static int drxk_set_parameters(struct dvb_frontend *fe)
return -EINVAL;
}
 
+   if (fe-ops.i2c_gate_ctrl)
+   fe-ops.i2c_gate_ctrl(fe, 1);
+   if (fe-ops.tuner_ops.set_params)
+   fe-ops.tuner_ops.set_params(fe);
+   if (fe-ops.i2c_gate_ctrl)
+   fe-ops.i2c_gate_ctrl(fe, 0);
+   state-props = *p;
+
switch (delsys) {
case SYS_DVBC_ANNEX_A:
-   state-m_itut_annex_c = false;
-   break;
case SYS_DVBC_ANNEX_C:
+   if (!state-m_hasDVBC)
+   return -EINVAL;
+   state-m_itut_annex_c = (delsys == SYS_DVBC_ANNEX_C) ? true : 
false;
+   if (state-m_itut_annex_c)
+   SetOperationMode(state, OM_QAM_ITU_C);
+   else
+   SetOperationMode(state, OM_QAM_ITU_A);
+   break;
state-m_itut_annex_c = true;
break;
+   case SYS_DVBT:
+   if (!state-m_hasDVBT)
+   return -EINVAL;
+   SetOperationMode(state, OM_DVBT);
+   break;
default:
return -EINVAL;
}
 
-   if (fe-ops.i2c_gate_ctrl)
-   fe-ops.i2c_gate_ctrl(fe, 1);
-   if (fe-ops.tuner_ops.set_params)
-   fe-ops.tuner_ops.set_params(fe);
-   if (fe-ops.i2c_gate_ctrl)
-   fe-ops.i2c_gate_ctrl(fe, 0);
-   state-props = *p;
fe-ops.tuner_ops.get_if_frequency(fe, IF);
Start(state, 0, IF);
 
@@ -6314,91 +6312,54 @@ static int

[PATCH 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

This patch series contain one feature and two bug fixes:

1) it ports the DRX-K driver to use just one frontend for all three
   delivery systems (DVB-C Annex A, DVB-C Annex C and DVB-T).
   As not all DRX-K supports all three, it also adds a logic there to
   show and accept only the delivery systems that are valid to the
   detected DRX-K version;

2) fixes a bug at dvb_frontend that causes it to wait forever, while
   changing to the second or upper delivery system (a var were not
   incremented inside it);

3) fixes a bug that a delivery system change would appear only on the
   second call, for a DVBv3 application.

With all these series applied, it is now possible to use frontend 0
for all delivery systems. As the current tools don't support changing
the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
be used to change between them:

For example, to use DVB-T with the standard scan:

$ ./dvb-fe-tool -d DVBT  scan /usr/share/dvb/dvb-t/au-Adelaide

[1] 
http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils


Mauro Carvalho Chehab (5):
  [media] drxk: remove ops.info.frequency_stepsize from DVB-C
  [media] drxk: create only one frontend for both DVB-C and DVB-T
  [media] drxk_hard: fix locking issues when changing the delsys
  [media] dvb_frontend: regression fix: add a missing inc inside the
loop
  [media] dvb_frontend: Update ops.info.type earlier

 drivers/media/dvb/ddbridge/ddbridge-core.c |2 +-
 drivers/media/dvb/dvb-core/dvb_frontend.c  |   11 +-
 drivers/media/dvb/frontends/drxk.h |6 +-
 drivers/media/dvb/frontends/drxk_hard.c|  206 
 drivers/media/dvb/frontends/drxk_hard.h|4 +-
 drivers/media/dvb/ngene/ngene-cards.c  |2 +-
 drivers/media/video/em28xx/em28xx-dvb.c|   28 +
 7 files changed, 104 insertions(+), 155 deletions(-)

-- 
1.7.7.5

--
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: Add support for two new types of Leadtek Winfast TV 2000XP tuner

2012-01-05 Thread Miroslav Slugeň

Resending signed-off version
Signed-off-by: Miroslav Slugen thunder@gmail.com
From: Miroslav Slugen thunder@gmail.com
Date: Mon, 12 Dec 2011 00:20:24 +0100
Subject: [PATCH] Add support for two new types of Leadtek Winfast TV 2000XP tuner, author of
 this patch is Istvan Varga. Only resending current reformated version against
 actual git.

---
 drivers/media/video/cx88/cx88-cards.c |   91 +
 drivers/media/video/cx88/cx88-input.c |4 ++
 drivers/media/video/cx88/cx88.h   |2 +
 3 files changed, 97 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/cx88/cx88-cards.c b/drivers/media/video/cx88/cx88-cards.c
index 3929d93..dca369d 100644
--- a/drivers/media/video/cx88/cx88-cards.c
+++ b/drivers/media/video/cx88/cx88-cards.c
@@ -1643,6 +1643,78 @@ static const struct cx88_board cx88_boards[] = {
 			.gpio3  = 0x,
 		},
 	},
+	[CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36] = {
+		.name   = Leadtek TV2000 XP Global (SC4100),
+		.tuner_type = TUNER_XC4000,
+		.tuner_addr = 0x61,
+		.radio_type = UNSET,
+		.radio_addr = ADDR_UNSET,
+		.input  = { {
+			.type   = CX88_VMUX_TELEVISION,
+			.vmux   = 0,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C04,   /* pin 18 = 1, pin 19 = 0 */
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_COMPOSITE1,
+			.vmux   = 1,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C0C,   /* pin 18 = 1, pin 19 = 1 */
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_SVIDEO,
+			.vmux   = 2,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C0C,   /* pin 18 = 1, pin 19 = 1 */
+			.gpio3  = 0x,
+		} },
+		.radio = {
+			.type   = CX88_RADIO,
+			.gpio0  = 0x0400,/* pin 2 = 0 */
+			.gpio1  = 0x,
+			.gpio2  = 0x0C00,   /* pin 18 = 0, pin 19 = 0 */
+			.gpio3  = 0x,
+		},
+	},
+	[CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43] = {
+		.name   = Leadtek TV2000 XP Global (XC4100),
+		.tuner_type = TUNER_XC4000,
+		.tuner_addr = 0x61,
+		.radio_type = UNSET,
+		.radio_addr = ADDR_UNSET,
+		.input  = { {
+			.type   = CX88_VMUX_TELEVISION,
+			.vmux   = 0,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x6040,   /* pin 14 = 1, pin 13 = 0 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_COMPOSITE1,
+			.vmux   = 1,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x6060,   /* pin 14 = 1, pin 13 = 1 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		}, {
+			.type   = CX88_VMUX_SVIDEO,
+			.vmux   = 2,
+			.gpio0  = 0x0400,   /* pin 2 = 0 */
+			.gpio1  = 0x6060,   /* pin 14 = 1, pin 13 = 1 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		} },
+		.radio = {
+			.type   = CX88_RADIO,
+			.gpio0  = 0x0400,/* pin 2 = 0 */
+			.gpio1  = 0x6000,/* pin 14 = 1, pin 13 = 0 */
+			.gpio2  = 0x,
+			.gpio3  = 0x,
+		},
+	},
 	[CX88_BOARD_POWERCOLOR_REAL_ANGEL] = {
 		.name   = PowerColor RA330,	/* Long names may confuse LIRC. */
 		.tuner_type = TUNER_XC2028,
@@ -2719,6 +2791,21 @@ static const struct cx88_subid cx88_subids[] = {
 		.subdevice = 0x6618,
 		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL,
 	}, {
+		/* TV2000 XP Global [107d:6618] */
+		.subvendor = 0x107d,
+		.subdevice = 0x6619,
+		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL,
+	}, {
+		/* WinFast TV2000 XP Global with XC4000 tuner */
+		.subvendor = 0x107d,
+		.subdevice = 0x6f36,
+		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36,
+	}, {
+		/* WinFast TV2000 XP Global with XC4000 tuner and different GPIOs */
+		.subvendor = 0x107d,
+		.subdevice = 0x6f43,
+		.card  = CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43,
+	}, {
 		.subvendor = 0xb034,
 		.subdevice = 0x3034,
 		.card  = CX88_BOARD_PROF_7301,
@@ -3075,6 +3162,8 @@ static int cx88_xc4000_tuner_callback(struct cx88_core *core,
 	switch (core-boardnr) {
 	case CX88_BOARD_WINFAST_DTV1800H_XC4000:
 	case CX88_BOARD_WINFAST_DTV2000H_PLUS:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43:
 		return cx88_xc4000_winfast2000h_plus_callback(core,
 			  command, arg);
 	}
@@ -3250,6 +3339,8 @@ static void cx88_card_setup_pre_i2c(struct cx88_core *core)
 
 	case CX88_BOARD_WINFAST_DTV1800H_XC4000:
 	case CX88_BOARD_WINFAST_DTV2000H_PLUS:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F36:
+	case CX88_BOARD_WINFAST_TV2000_XP_GLOBAL_6F43:
 		cx88_xc4000_winfast2000h_plus_callback(core,
 		   XC4000_TUNER_RESET, 0);
 		break;
diff --git a/drivers/media/video/cx88/cx88-input.c b/drivers/media/video/cx88/cx88-input.c
index e614201..ebf448c 100644
--- a/drivers/media/video/cx88/cx88-input.c
+++ b/drivers/media/video/cx88/cx88-input.c
@@ -103,6 +103,8 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
 	case CX88_BOARD_WINFAST_DTV1800H_XC4000:
 	case

Re: [RFC 01/17] v4l: Introduce integer menu controls

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:53 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi
 
 Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
 controls are just like menu controls but the menu items are 64-bit integers
 rather than strings.

[snip]

 diff --git a/drivers/media/video/v4l2-ctrls.c
 b/drivers/media/video/v4l2-ctrls.c index 0f415da..083bb79 100644
 --- a/drivers/media/video/v4l2-ctrls.c
 +++ b/drivers/media/video/v4l2-ctrls.c

 @@ -1775,16 +1797,22 @@ int v4l2_querymenu(struct v4l2_ctrl_handler *hdl,
 struct v4l2_querymenu *qm)
 
   qm-reserved = 0;
   /* Sanity checks */

You should return -EINVAL here if the control is not of a menu type. It was 
done implictly before by the ctrl-qmenu == NULL check, but that's now 
conditioned to the control type being V4L2_CTRL_TYPE_MENU.

 - if (ctrl-qmenu == NULL ||
 + if ((ctrl-type == V4L2_CTRL_TYPE_MENU  ctrl-qmenu == NULL) ||
 + (ctrl-type == V4L2_CTRL_TYPE_INTEGER_MENU
 +   ctrl-qmenu_int == NULL) ||
   i  ctrl-minimum || i  ctrl-maximum)
   return -EINVAL;
   /* Use mask to see if this menu item should be skipped */
   if (ctrl-menu_skip_mask  (1  i))
   return -EINVAL;
   /* Empty menu items should also be skipped */
 - if (ctrl-qmenu[i] == NULL || ctrl-qmenu[i][0] == '\0')
 - return -EINVAL;
 - strlcpy(qm-name, ctrl-qmenu[i], sizeof(qm-name));
 + if (ctrl-type == V4L2_CTRL_TYPE_MENU) {
 + if (ctrl-qmenu[i] == NULL || ctrl-qmenu[i][0] == '\0')
 + return -EINVAL;
 + strlcpy(qm-name, ctrl-qmenu[i], sizeof(qm-name));
 + } else if (ctrl-type == V4L2_CTRL_TYPE_INTEGER_MENU) {

And you can then replace the else if by an else.

 + qm-value = ctrl-qmenu_int[i];
 + }
   return 0;
  }
  EXPORT_SYMBOL(v4l2_querymenu);

-- 
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 02/17] v4l: Document integer menu controls

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:54 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi
 
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  Documentation/DocBook/media/v4l/compat.xml |   10 +
  Documentation/DocBook/media/v4l/v4l2.xml   |7 
  .../DocBook/media/v4l/vidioc-queryctrl.xml |   39
 +++- 3 files changed, 54 insertions(+), 2 deletions(-)
 
 diff --git a/Documentation/DocBook/media/v4l/compat.xml
 b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644
 --- a/Documentation/DocBook/media/v4l/compat.xml
 +++ b/Documentation/DocBook/media/v4l/compat.xml
 @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for
 removal in 2.6.35. /orderedlist
  /section
 
 +section
 +  titleV4L2 in Linux 3.3/title

Seems it will be for 3.4 :-) Same for Documentation/DocBook/media/v4l/v4l2.xml

 +  orderedlist
 +listitem
 +   paraAdded integer menus, the new type will be
 +   V4L2_CTRL_TYPE_INTEGER_MENU./para
 +/listitem
 +  /orderedlist
 +/section
 +
  section id=other
titleRelation of V4L2 to other Linux multimedia APIs/title
 

-- 
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 03/17] vivi: Add an integer menu test control

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:55 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi
 
 Add an integer menu test control for the vivi driver.
 
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/vivi.c |   21 +
  1 files changed, 21 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
 index 7d754fb..763ec23 100644
 --- a/drivers/media/video/vivi.c
 +++ b/drivers/media/video/vivi.c
 @@ -177,6 +177,7 @@ struct vivi_dev {
   struct v4l2_ctrl   *menu;
   struct v4l2_ctrl   *string;
   struct v4l2_ctrl   *bitmask;
 + struct v4l2_ctrl   *int_menu;
 
   spinlock_t slock;
   struct mutex   mutex;
 @@ -503,6 +504,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
 vivi_buffer *buf) dev-boolean-cur.val,
   dev-menu-qmenu[dev-menu-cur.val],
   dev-string-cur.string);
 + snprintf(str, sizeof(str),  integer_menu %s, value %lld ,
 + dev-int_menu-qmenu[dev-int_menu-cur.val],

Shouldn't you print the content of qmenu_int as a 64-bit integer instead ?

 + dev-int64-cur.val64);

Shouldn't this be dev-int_menu-cur.val ?

 + gen_text(dev, vbuf, line++ * 16, 16, str);
   mutex_unlock(dev-ctrl_handler.lock);
   gen_text(dev, vbuf, line++ * 16, 16, str);
   if (dev-button_pressed) {
 @@ -1183,6 +1188,22 @@ static const struct v4l2_ctrl_config
 vivi_ctrl_bitmask = { .step = 0,
  };
 
 +static const s64 * const vivi_ctrl_int_menu_values[] = {
 + 1, 1, 2, 3, 5, 8, 13, 21, 42,
 +};
 +
 +static const struct v4l2_ctrl_config vivi_ctrl_string = {
 + .ops = vivi_ctrl_ops,
 + .id = VIDI_CID_CUSTOM_BASE + 7
 + .name = Integer menu,
 + .type = V4L2_CTRL_TYPE_INTEGER_MENU,
 + .min = 1,
 + .max = 8,

There are 9 values in your vivi_ctrl_int_menu_values array. Is 8 on purpose 
here ?

 + .def = 4,
 + .menu_skip_mask = 0x02,
 + .qmenu_int = vivi_ctrl_int_menu_values,
 +};
 +
  static const struct v4l2_file_operations vivi_fops = {
   .owner  = THIS_MODULE,
   .open   = v4l2_fh_open,

-- 
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: [yavta PATCH 1/1] Support integer menus.

Hi Sakari,

Thanks for the patch.

On Wednesday 28 December 2011 10:47:01 Sakari Ailus wrote:
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  yavta.c |   12 +---
  1 files changed, 9 insertions(+), 3 deletions(-)
 
 diff --git a/yavta.c b/yavta.c
 index c0e9acb..9b8a80e 100644
 --- a/yavta.c
 +++ b/yavta.c
 @@ -551,6 +551,7 @@ static int video_enable(struct device *dev, int enable)
  }
 
  static void video_query_menu(struct device *dev, unsigned int id,
 +  unsigned int type,
unsigned int min, unsigned int max)
  {
   struct v4l2_querymenu menu;
 @@ -562,7 +563,10 @@ static void video_query_menu(struct device *dev,
 unsigned int id, if (ret  0)
   continue;
 
 - printf(  %u: %.32s\n, menu.index, menu.name);
 + if (type == V4L2_CTRL_TYPE_MENU)
 + printf(  %u: %.32s\n, menu.index, menu.name);
 + else
 + printf(  %u: %lld\n, menu.index, menu.value);
   };
  }
 
 @@ -607,8 +611,10 @@ static void video_list_controls(struct device *dev)
   query.id, query.name, query.minimum, query.maximum,
   query.step, query.default_value, value);
 
 - if (query.type == V4L2_CTRL_TYPE_MENU)
 - video_query_menu(dev, query.id, query.minimum, 
 query.maximum);
 + if (query.type == V4L2_CTRL_TYPE_MENU ||
 + query.type == V4L2_CTRL_TYPE_INTEGER_MENU)
 + video_query_menu(dev, query.id, query.type,
 +  query.minimum, query.maximum);

What about passing query to the function instead ?

 
   nctrls++;
   }

-- 
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 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:56 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi
 
 Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
 IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
 VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
 
 VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.

As those ioctls are experimental, should we deprecate them ?

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/v4l2-subdev.c |   26 -
  include/linux/v4l2-subdev.h   |   45 ++
  include/media/v4l2-subdev.h   |5 
  3 files changed, 75 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/media/video/v4l2-subdev.c
 b/drivers/media/video/v4l2-subdev.c index 65ade5f..e8ae098 100644
 --- a/drivers/media/video/v4l2-subdev.c
 +++ b/drivers/media/video/v4l2-subdev.c
 @@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh,
 struct v4l2_subdev *sd) {
  #if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
   /* Allocate try format and crop in the same memory block */
 - fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop))
 + fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop)
 ++ sizeof(*fh-try_compose))
 * sd-entity.num_pads, GFP_KERNEL);

Could you check how the 3 structures are aligned on 64-bit platforms ? I'm a 
bit worried about the compiler expecting a 64-bit alignment for one of them, 
and getting only a 32-bit alignment in the end.

What about using kcalloc ?

   if (fh-try_fmt == NULL)
   return -ENOMEM;
 
   fh-try_crop = (struct v4l2_rect *)
   (fh-try_fmt + sd-entity.num_pads);
 +
 + fh-try_compose = (struct v4l2_rect *)
 + (fh-try_crop + sd-entity.num_pads);
  #endif
   return 0;
  }
 @@ -281,6 +285,26 @@ static long subdev_do_ioctl(struct file *file,
 unsigned int cmd, void *arg) return v4l2_subdev_call(sd, pad,
 enum_frame_interval, subdev_fh, fie);
   }
 +
 + case VIDIOC_SUBDEV_G_SELECTION: {
 + struct v4l2_subdev_selection *sel = arg;

Shouldn't you check sel-which ?

 + if (sel-pad = sd-entity.num_pads)
 + return -EINVAL;
 +
 + return v4l2_subdev_call(
 + sd, pad, get_selection, subdev_fh, sel);
 + }
 +
 + case VIDIOC_SUBDEV_S_SELECTION: {
 + struct v4l2_subdev_selection *sel = arg;

And here too ?

 + if (sel-pad = sd-entity.num_pads)
 + return -EINVAL;
 +
 + return v4l2_subdev_call(
 + sd, pad, set_selection, subdev_fh, sel);
 + }
  #endif
   default:
   return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
 diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
 index ed29cbb..d53d775 100644
 --- a/include/linux/v4l2-subdev.h
 +++ b/include/linux/v4l2-subdev.h
 @@ -123,6 +123,47 @@ struct v4l2_subdev_frame_interval_enum {
   __u32 reserved[9];
  };
 
 +#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE (1  0)
 +#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE (1  1)
 +#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG (1  2)
 +
 +/* active cropping area */
 +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE  0
 +/* default cropping area */
 +#define V4L2_SUBDEV_SEL_TGT_CROP_DEFAULT 1
 +/* cropping bounds */
 +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS  2
 +/* current composing area */
 +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE   256
 +/* default composing area */
 +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_DEFAULT  257
 +/* composing bounds */
 +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS   258
 +
 +
 +/**
 + * struct v4l2_subdev_selection - selection info
 + *
 + * @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
 + * @pad: pad number, as reported by the media API
 + * @target: selection target, used to choose one of possible rectangles
 + * @flags: constraints flags
 + * @r: coordinates of selection window
 + * @reserved: for future use, rounds structure size to 64 bytes, set to
 zero + *
 + * Hardware may use multiple helper window to process a video stream.
 + * The structure is used to exchange this selection areas between
 + * an application and a driver.
 + */
 +struct v4l2_subdev_selection {
 + __u32 which;
 + __u32 pad;
 + __u32 target;
 + __u32 flags;
 + struct v4l2_rect r;
 + __u32 reserved[8];
 +};
 +
  #define VIDIOC_SUBDEV_G_FMT  _IOWR('V',  4, struct v4l2_subdev_format)
  #define VIDIOC_SUBDEV_S_FMT  _IOWR('V',  5, struct v4l2_subdev_format)
  #define VIDIOC_SUBDEV_G_FRAME_INTERVAL \
 @@ -137,5 +178,9 @@ struct v4l2_subdev_frame_interval_enum {
   _IOWR('V', 75, struct

Re: [RFC 05/17] v4l: Support s_crop and g_crop through s/g_selection

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:27:57 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi
 
 Revert to s_selection if s_crop isn't implemented by a driver. Same for
 g_selection / g_crop.

Shouldn't this say Fall back instead of Revert ?

 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  drivers/media/video/v4l2-subdev.c |   37
 +++-- 1 files changed, 35 insertions(+), 2
 deletions(-)
 
 diff --git a/drivers/media/video/v4l2-subdev.c
 b/drivers/media/video/v4l2-subdev.c index e8ae098..f8de551 100644
 --- a/drivers/media/video/v4l2-subdev.c
 +++ b/drivers/media/video/v4l2-subdev.c
 @@ -226,6 +226,8 @@ static long subdev_do_ioctl(struct file *file, unsigned
 int cmd, void *arg)
 
   case VIDIOC_SUBDEV_G_CROP: {
   struct v4l2_subdev_crop *crop = arg;
 + struct v4l2_subdev_selection sel;
 + int rval;
 
   if (crop-which != V4L2_SUBDEV_FORMAT_TRY 
   crop-which != V4L2_SUBDEV_FORMAT_ACTIVE)
 @@ -234,11 +236,27 @@ static long subdev_do_ioctl(struct file *file,
 unsigned int cmd, void *arg) if (crop-pad = sd-entity.num_pads)
   return -EINVAL;
 
 - return v4l2_subdev_call(sd, pad, get_crop, subdev_fh, crop);
 + rval = v4l2_subdev_call(sd, pad, get_crop, subdev_fh, crop);
 + if (rval != -ENOIOCTLCMD)
 + return rval;
 +
 + memset(sel, 0, sizeof(sel));
 + sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;

Shouldn't sel.which be set to crop-which ?

 + sel.pad = crop-pad;
 + sel.target = V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE;
 +
 + rval = v4l2_subdev_call(
 + sd, pad, get_selection, subdev_fh, sel);
 +
 + crop-rect = sel.r;
 +
 + return rval;
   }
 
   case VIDIOC_SUBDEV_S_CROP: {
   struct v4l2_subdev_crop *crop = arg;
 + struct v4l2_subdev_selection sel;
 + int rval;
 
   if (crop-which != V4L2_SUBDEV_FORMAT_TRY 
   crop-which != V4L2_SUBDEV_FORMAT_ACTIVE)
 @@ -247,7 +265,22 @@ static long subdev_do_ioctl(struct file *file,
 unsigned int cmd, void *arg) if (crop-pad = sd-entity.num_pads)
   return -EINVAL;
 
 - return v4l2_subdev_call(sd, pad, set_crop, subdev_fh, crop);
 + rval = v4l2_subdev_call(sd, pad, set_crop, subdev_fh, crop);
 + if (rval != -ENOIOCTLCMD)
 + return rval;
 +
 + memset(sel, 0, sizeof(sel));
 + sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;

Same here.

 + sel.pad = crop-pad;
 + sel.target = V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE;
 + sel.r = crop-rect;
 +
 + rval = v4l2_subdev_call(
 + sd, pad, set_selection, subdev_fh, sel);
 +
 + crop-rect = sel.r;
 +
 + return rval;
   }
 
   case VIDIOC_SUBDEV_ENUM_MBUS_CODE: {

-- 
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 4/9] [media] dvb_frontend: Don't use ops-info.type anymore

2012-01-05 Thread e9hack

Am 01.01.2012 21:11, schrieb Mauro Carvalho Chehab:
 Get rid of using ops-info.type defined on DVB drivers,
 as it doesn't apply anymore.

 
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
 ++---
  1 files changed, 266 insertions(+), 275 deletions(-)

 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index eefcb7f..7f6ce06 100644
 @@ -1902,6 +1850,37 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
   memcpy(info, fe-ops.info, sizeof(struct dvb_frontend_info));
   dvb_frontend_get_frequency_limits(fe, info-frequency_min, 
 info-frequency_max);
  
 + /*
 +  * Associate the 4 delivery systems supported by DVBv3
 +  * API with their DVBv5 counterpart. For the other standards,
 +  * use the closest type, assuming that it would hopefully
 +  * work with a DVBv3 application.
 +  * It should be noticed that, on multi-frontend devices with
 +  * different types (terrestrial and cable, for example),
 +  * a pure DVBv3 application won't be able to use all delivery
 +  * systems. Yet, changing the DVBv5 cache to the other delivery
 +  * system should be enough for making it work.
 +  */
 + switch (dvbv3_type(c-delivery_system)) {
 + case DVBV3_QPSK:
 + fe-ops.info.type = FE_QPSK;
 + break;
 + case DVBV3_ATSC:
 + fe-ops.info.type = FE_ATSC;
 + break;
 + case DVBV3_QAM:
 + fe-ops.info.type = FE_QAM;
 + break;
 + case DVBV3_OFDM:
 + fe-ops.info.type = FE_OFDM;
 + break;
 + default:
 + printk(KERN_ERR
 +%s: doesn't know how to handle a DVBv3 call to 
 delivery system %i\n,
 +__func__, c-delivery_system);
 + fe-ops.info.type = FE_OFDM;
 + }
 +

Hi,

I think this is partly wrong. The old delivery system values must be set in the 
given data
structure from caller:

fe-ops.info.type = FE_QAM;

must be replace by

info-type = FE_QAM;

Regards,
Hartmut
--
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 08/17] v4l: Image source control class

Hi Sakari,

Thanks for the patch.

On Tuesday 20 December 2011 21:28:00 Sakari Ailus wrote:
 From: Sakari Ailus sakari.ai...@iki.fi
 
 Add image source control class. This control class is intended to contain
 low level controls which deal with control of the image capture process ---
 the A/D converter in image sensors, for example.
 
 Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
 ---
  Documentation/DocBook/media/v4l/controls.xml   |  101 +
  .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml   |6 +
  drivers/media/video/v4l2-ctrls.c   |   10 ++
  include/linux/videodev2.h  |   10 ++
  4 files changed, 127 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/DocBook/media/v4l/controls.xml
 b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..69ede83
 100644
 --- a/Documentation/DocBook/media/v4l/controls.xml
 +++ b/Documentation/DocBook/media/v4l/controls.xml
 @@ -3356,6 +3356,107 @@ interface and may change in the future./para
/table
 
  /section
 +
 +section id=image-source-controls
 +  titleImage Source Control Reference/title
 +
 +  note
 + titleExperimental/title
 +
 + paraThis is an link
 + linkend=experimentalexperimental/link interface and may
 + change in the future./para
 +  /note
 +
 +  para
 + The Image Source control class is intended for low-level
 + control of image source devices such as image sensors. The
 + devices feature an analogue to digital converter and a bus

Is the V4L2 documentation written in US or UK English ? US uses analog, UK 
uses analogue. Analog would be shorter in control names.

 + transmitter to transmit the image data out of the device.
 +  /para
 +
 +  table pgwide=1 frame=none id=image-source-control-id
 +  titleImage Source Control IDs/title
 +
 +  tgroup cols=4
 + colspec colname=c1 colwidth=1* /
 + colspec colname=c2 colwidth=6* /
 + colspec colname=c3 colwidth=2* /
 + colspec colname=c4 colwidth=6* /
 + spanspec namest=c1 nameend=c2 spanname=id /
 + spanspec namest=c2 nameend=c4 spanname=descr /
 + thead
 +   row
 + entry spanname=id align=leftID/entry
 + entry align=leftType/entry
 +   /rowrow rowsep=1entry spanname=descr
 align=leftDescription/entry +  /row
 + /thead
 + tbody valign=top
 +   rowentry/entry/row
 +   row
 + entry
 spanname=idconstantV4L2_CID_IMAGE_SOURCE_CLASS/constant/entry +  
  
   entryclass/entry
 +   /row
 +   row
 + entry spanname=descrThe IMAGE_SOURCE class descriptor./entry
 +   /row
 +   row
 + entry
 spanname=idconstantV4L2_CID_IMAGE_SOURCE_VBLANK/constant/entry + 
entryinteger/entry
 +   /row
 +   row
 + entry spanname=descrVertical blanking. The idle
 + preriod after every frame during which no image data is

s/preriod/period/

 + produced. The unit of vertical blanking is a line. Every
 + line has length of the image width plus horizontal
 + blanking at the pixel clock specified by struct
 + v4l2_mbus_framefmt xref linkend=v4l2-mbus-framefmt
 + /./entry
 +   /row
 +   row
 + entry
 spanname=idconstantV4L2_CID_IMAGE_SOURCE_HBLANK/constant/entry + 
entryinteger/entry
 +   /row
 +   row
 + entry spanname=descrHorizontal blanking. The idle
 + preriod after every line of image data during which no

s/preriod/period/

 + image data is produced. The unit of horizontal blanking is
 + pixels./entry
 +   /row
 +   row
 + entry
 spanname=idconstantV4L2_CID_IMAGE_SOURCE_LINK_FREQ/constant/entry
 + entryinteger menu/entry
 +   /row
 +   row
 + entry spanname=descrImage source's data bus frequency.

What's the frequency unit ? Sample/second ?

 + Together with the media bus pixel code, bus type (clock
 + cycles per sample), the data bus frequency defines the
 + pixel clock. xref linkend=v4l2-mbus-framefmt / The
 + frame rate can be calculated from the pixel clock, image
 + width and height and horizontal and vertical blanking. The
 + frame rate control is performed by selecting the desired
 + horizontal and vertical blanking.
 + /entry
 +   /row
 +   row
 + entry
 spanname=idconstantV4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN/constant/en
 try +entryinteger/entry
 +   /row
 +   row
 + entry spanname=descrAnalogue gain is gain affecting
 + all colour components in the pixel matrix. The gain
 + operation is performed in the analogue domain before A/D
 + conversion.

Should we define one gain per color component ?

 + /entry
 +   /row
 +   rowentry/entry/row
 + /tbody
 +  /tgroup
 +  /table
 +
 +/section
 +
  /section
 
!--
 diff --git

DVB: Question on TS_DECODER

2012-01-05 Thread Hamad Kadmany

Hi,

dvb_dmxdev_start_feed sets TS_DECODER to ts_type regardless of whether
pes-output was set to DMX_OUT_DECODER or not, but depending on the pes-type
only. 

This might cause confusion, there's a hidden assumption that if user is not
interested to send data to decoder, the pes type must always be
DMX_PES_OTHER, which makes the API a bit un-clear to user-space.

If user-space is only interested in recording video packets for example, and
by mistake sets DMX_PES_VIDEO (because it just says the pes type which is
independent from the pes output type) then packets will make their way to
the decoder eventhough this was not the intention.

Is there any special reason to have this? 

Thanks,
Hamad

--
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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 With all these series applied, it is now possible to use frontend 0
 for all delivery systems. As the current tools don't support changing
 the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
 be used to change between them:

Hi Mauro,

While from a functional standpoint I think this is a good change (and
we probably should have done it this way all along), is there not
concern that this could be interpreted by regular users as a
regression?  Right now they get two frontends, and they can use all
their existing tools.  We're moving to a model where if users upgraded
their kernel they would now require some new userland tool to do
something that the kernel was allowing them to do previously.

Sure, it's not ABI breakage in the classic sense but the net effect
is the same - stuff that used to work stops working and now they need
new tools or to recompile their existing tools to include new
functionality (which as you mentioned, none of those tools have
today).

Perhaps you would consider some sort of module option that would let
users fall back to the old behavior?

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch -longterm v2] V4L/DVB: v4l2-ioctl: integer overflow in video_usercopy()

2012-01-05 Thread Greg KH

On Thu, Jan 05, 2012 at 09:28:22AM +0300, Dan Carpenter wrote:
 If p-count is too high the multiplication could overflow and
 array_size would be lower than expected.  Mauro and Hans Verkuil
 suggested that we cap it at 1024.  That comes from the maximum
 number of controls with lots of room for expantion.
 
 $ grep V4L2_CID include/linux/videodev2.h | wc -l
 211
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

So this patch is only for 2.6.32?  But the original needs to get into
Linus's tree first (which is what I'm guessing the other patch you sent
is, right?)

thanks,

greg k-h
--
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

Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

2012-01-05 Thread Linus Torvalds

On Thu, Jan 5, 2012 at 8:16 AM, Linus Torvalds
torva...@linux-foundation.org wrote:

 Just fix the *obvious* breakage in BLKROSET. It's clearly what the
 code *intends* to do, it just didn't check for ENOIOCTLCMD.

So it seems from quick grepping that the block layer isn't actually
all that confused apart from that one BLK[SG]ETRO issue, although I'm
sure there are crazy drivers that think that EINVAL is the right error
return.

The *really* confused layer seems to be the damn media drivers. The
confusion there seems to go very deep indeed, where for some crazy
reason the media people seem to have made it part of the semantics
that if a driver doesn't support a particular ioctl, it returns
EINVAL.

Added, linux-media and Mauro to the Cc, because I'm about to commit
something like the attached patch to see if anything breaks. We may
have to revert it if things get too nasty, but we should have done
this years and years ago, so let's hope not.

Basic rules: ENOTTY means I don't recognize this ioctl. Yes, the
name is odd, and yes, it's for historical Unix reasons. ioctl's were
originally a way to control mainly terminal settings - think termios -
so when you did an ioctl on a file, you'd get I'm not a tty, dummy.
File flags were controlled with fcntl().

In contrast, EINVAL means there is something wrong with the
arguments, which very much implies I do recognize the ioctl.

And finally, ENOIOCTLCMD is a way to say ENOTTY in a sane manner, and
will now be turned into ENOTTY for the user space return (not EINVAL -
I have no idea where that idiocy came from, but it's clearly confused,
although it's also clearly very old).

This fixes the core files I noticed. It removes the *insane*
complaints from the compat_ioctl() (which would complain if you
returned ENOIOCTLCMD after an ioctl translation - the reason that is
totally insane is that somebody might use an ioctl on the wrong kind
of file descriptor, so even if it was translated perfectly fine,
ENOIOCTLCMD is a perfectly fine error return and shouldn't cause
warnings - and that allows us to remove stupid crap from the socket
ioctl code).

Does this break things and need to be reverted? Maybe. There could be
user code that tests *explicitly* for EINVAL and considers that the
wrong ioctl number, even though it's the wrong error return.

And we may have those kinds of mistakes inside the kernel too. We did
in the block layer BLKSETRO code, for example, as pointed out by
Paulo. That one is fixed here, but there may be others.

I didn't change any media layers, since there it's clearly an endemic
problem, and there it seems to be used as a we pass media ioctls down
and drivers should by definition recognize them, so if they don't, we
assume the driver is limited and doesn't support those particular
settings and return EINVAL.

But in general, any code like this is WRONG:

   switch (cmd) {
   case MYIOCTL:
  .. do something ..
   default:
  return -EINVAL;
   }

while something like this is CORRECT:

   switch (cmd) {
   case MYIOCT:
  if (arg)
 return -EINVAL;
  ...

   case OTHERIOCT:
  /* I recognize this one, but I don't support it */
  return -EINVAL;

   default:
  return -ENOIOCTLCMD; // Or -ENOTTY - see below about the difference
   }

where right now we do have some magic differences between ENOIOCTLCMD
and ENOTTY (the compat layer will try to do a translated ioctl *only*
if it gets ENOIOCTLCMD, iirc, so ENOTTY basically means this is my
final answer).

I'll try it out on my own setup here to see what problems I can
trigger, but I thought I'd send it out first just as (a) a heads-up
and (b) to let others try it out and see.. See the block/ioctl.c code
for an example of the kinds of things we may need even just inside the
kernel (and the kinds of things that could cause problems for
user-space that makes a difference between EINVAL and ENOTTY).

 Linus
 block/ioctl.c |   26 ++
 fs/compat_ioctl.c |9 ++---
 fs/ioctl.c|2 +-
 net/socket.c  |   16 +---
 4 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/block/ioctl.c b/block/ioctl.c
index ca939fc1030f..af8363e775a8 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -180,6 +180,26 @@ int __blkdev_driver_ioctl(struct block_device *bdev, fmode_t mode,
 EXPORT_SYMBOL_GPL(__blkdev_driver_ioctl);
 
 /*
+ * Is it an unrecognized ioctl? The correct returns are either
+ * ENOTTY (final) or ENOIOCTLCMD (I don't know this one, try a
+ * fallback). ENOIOCTLCMD gets turned into ENOTTY by the ioctl
+ * code before returning.
+ *
+ * Confused drivers sometimes return EINVAL, which is wrong. It
+ * means I understood the ioctl command, but the parameters to
+ * it were wrong.
+ *
+ * We should aim to just fix the broken drivers, the EINVAL case
+ * should go away.
+ */
+static inline int is_unrecognized_ioctl(int ret)
+{
+	return	ret == -EINVAL ||
+		ret == -ENOTTY ||
+		ret == ENOIOCTLCMD;

Re: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

2012-01-05 Thread Paolo Bonzini


On 01/05/2012 06:02 PM, Linus Torvalds wrote:

+   return  ret == -EINVAL ||
+   ret == -ENOTTY ||
+   ret == ENOIOCTLCMD;


Missing minus before ENOIOCTLCMD.

Paolo
--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

2012-01-05 Thread Linus Torvalds

On Thu, Jan 5, 2012 at 9:02 AM, Linus Torvalds
torva...@linux-foundation.org wrote:

 Added, linux-media and Mauro to the Cc, because I'm about to commit
 something like the attached patch to see if anything breaks. We may
 have to revert it if things get too nasty, but we should have done
 this years and years ago, so let's hope not.

Ok, so It works for me. I'll delay committing it in case somebody
has some quick obvious fixes or comments (like noticing other cases
like the blk_ioctl.c one), but on the whole I think I'll commit it
later today, just so that it will be as early as possible in the merge
window in case there is ENOTTY/EINVAL confusion.

The good news is that no user space can *ever* care about
ENOTTY/EINVAL in the generic case, since different drivers have
returned different error returns for years. So user space that doesn't
know exactly what it is dealing with will pretty much by definition
not be affected. Except perhaps in a good way - if it uses perror()
or strerror() or similar, it will now give a much better error
string of Inappropriate ioctl for device.

However, some applications don't work with generic devices, but
instead work with a very specific device or perhaps a very specific
subset.

So the exception would be user space apps that know exactly which
driver they are talking about, and that particular driver used to
always return EINVAL before, and now the ENOIOCTLCMD - ENOTTY fix
means that it returns the proper ENOTTY - and the application has
never seen it, and never tested against it, and breaks.

I don't *think* this happens outside of the media drivers, but we'll
see. It may be that we will have to make certain drivers return EINVAL
explicitly rather than ENOIOCTLCMD and add a comment about why. Sad,
if so, so we'll have little choice. Let's see what the breakage (if
any - cross your fingers) looks like.

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

[PATCH v2] [media] dvb_frontend: Update the dynamic info-type

Instead of changing the ops.info.type struct, updates only
the data that will be returned to userspace.

Also add some debug messages to help tracking such issues.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |   13 +
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index cd3c0f6..128f677 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1551,6 +1551,8 @@ static int set_delivery_system(struct dvb_frontend *fe, 
u32 desired_system)
}
}
}
+   dprintk(change delivery system on cache to %d\n, c-delivery_system);
+
return 0;
 }
 
@@ -1965,6 +1967,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
switch (cmd) {
case FE_GET_INFO: {
struct dvb_frontend_info* info = parg;
+
memcpy(info, fe-ops.info, sizeof(struct dvb_frontend_info));
dvb_frontend_get_frequency_limits(fe, info-frequency_min, 
info-frequency_max);
 
@@ -1981,16 +1984,16 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
 */
switch (dvbv3_type(c-delivery_system)) {
case DVBV3_QPSK:
-   fe-ops.info.type = FE_QPSK;
+   info-type = FE_QPSK;
break;
case DVBV3_ATSC:
-   fe-ops.info.type = FE_ATSC;
+   info-type = FE_ATSC;
break;
case DVBV3_QAM:
-   fe-ops.info.type = FE_QAM;
+   info-type = FE_QAM;
break;
case DVBV3_OFDM:
-   fe-ops.info.type = FE_OFDM;
+   info-type = FE_OFDM;
break;
default:
printk(KERN_ERR
@@ -1998,6 +2001,8 @@ static int dvb_frontend_ioctl_legacy(struct file *file,
   __func__, c-delivery_system);
fe-ops.info.type = FE_OFDM;
}
+   dprintk(current delivery system on cache: %d, V3 type: %d\n,
+   c-delivery_system, fe-ops.info.type);
 
/* Force the CAN_INVERSION_AUTO bit on. If the frontend doesn't
 * do it, it is done for it. */
-- 
1.7.7.5

--
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: Broken ioctl error returns (was Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices)

On 05-01-2012 15:47, Linus Torvalds wrote:
 On Thu, Jan 5, 2012 at 9:37 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:

 For the media drivers, we've already fixed it, at the V4L side:
 -EINVAL doesn't mean that an ioctl is not supported anymore.
 I think that such fix went into Kernel 3.1.
 
 Ok, I'm happy to hear that the thing should be fixed. My grepping
 still found a fair amount of EINVAL returns both in code and in the
 Documentation subdirectory for media ioctls, but it really was just
 grepping with a few lines of context, so I didn't look closer at the
 semantics. I was just looking for certain patterns (ie grepping for
 EINVAL near ioctl or ENOIOCTLCMD etc) that I thought might indicate
 problem spots, and the media subdirectory had a lot of them.

Yeah, there are lots of EINVAL there, as the API is fairly complex
(about 80 ioctl's for V4L, plus a similar set for DVB),  but there's
an ioctl dispatcher inside the V4L core that handles the ENOTTY case,
at drivers/media/video/v4l2-ioctl.c.

You'll see some -EINVAL things there, but they're due to errors
on parameters (the semantics there is somewhat complex, to avoid
returning -ENOTTY where a -EINVAL should be returned, instead).

In summary, the code there is:

static long __video_do_ioctl(struct file *file,
unsigned int cmd, void *arg)
{
...
long ret = -ENOTTY;
...
switch (cmd) {
/*
 * several ioctl callbacks here. if they're not
 * implemented, break (e. g. -ENOTTY will be returned).
 */
...
}
...
return ret;

The context there is too big for noticing it with a few lines of
context, and too complex as well, as some ioctl's may be implemented 
by more than one callback, depending on what's needed, and some 
others have a default implementation there. This is somewhat similar 
to file ops callbacks.

 Can you test the patch with some media capture apps (preferably with
 the obvious fix for the problem that Paulo already pointed out -
 although that won't actually matter until some block driver starts
 using ENOIOCTLCMD there, so even the unfixed patch should mostly work
 for testing)?

Sure. I'm currently traveling, so I have just my first aids kit of devices
but they should be enough for testing it. I'll return you as soon as I finish
compiling the kernel on this slow 4 years-old notebook and run some
tests with the usual applications.

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

Re: [PATCH 4/9] [media] dvb_frontend: Don't use ops-info.type anymore

On 05-01-2012 14:19, e9hack wrote:
 Am 01.01.2012 21:11, schrieb Mauro Carvalho Chehab:
 Get rid of using ops-info.type defined on DVB drivers,
 as it doesn't apply anymore.
 

 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/dvb/dvb-core/dvb_frontend.c |  541 
 ++---
  1 files changed, 266 insertions(+), 275 deletions(-)
 
 diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
 b/drivers/media/dvb/dvb-core/dvb_frontend.c
 index eefcb7f..7f6ce06 100644
 @@ -1902,6 +1850,37 @@ static int dvb_frontend_ioctl_legacy(struct file 
 *file,
  memcpy(info, fe-ops.info, sizeof(struct dvb_frontend_info));
  dvb_frontend_get_frequency_limits(fe, info-frequency_min, 
 info-frequency_max);
  
 +/*
 + * Associate the 4 delivery systems supported by DVBv3
 + * API with their DVBv5 counterpart. For the other standards,
 + * use the closest type, assuming that it would hopefully
 + * work with a DVBv3 application.
 + * It should be noticed that, on multi-frontend devices with
 + * different types (terrestrial and cable, for example),
 + * a pure DVBv3 application won't be able to use all delivery
 + * systems. Yet, changing the DVBv5 cache to the other delivery
 + * system should be enough for making it work.
 + */
 +switch (dvbv3_type(c-delivery_system)) {
 +case DVBV3_QPSK:
 +fe-ops.info.type = FE_QPSK;
 +break;
 +case DVBV3_ATSC:
 +fe-ops.info.type = FE_ATSC;
 +break;
 +case DVBV3_QAM:
 +fe-ops.info.type = FE_QAM;
 +break;
 +case DVBV3_OFDM:
 +fe-ops.info.type = FE_OFDM;
 +break;
 +default:
 +printk(KERN_ERR
 +   %s: doesn't know how to handle a DVBv3 call to 
 delivery system %i\n,
 +   __func__, c-delivery_system);
 +fe-ops.info.type = FE_OFDM;
 +}
 +
 
 Hi,
 
 I think this is partly wrong. The old delivery system values must be set in 
 the given data
 structure from caller:
 
 fe-ops.info.type = FE_QAM;
 
 must be replace by
 
 info-type = FE_QAM;

Yeah, I noticed it today, when testing it with DRX-K. Patches fixing it
were sent to the ML earlier, but it ends that your solution is better
than mine ;) I've re-sent the patch to the ML, and added it upstream.

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

Re: [PATCH 2/3] drxk: correction frontend attatching

On 18-12-2011 04:05, Stefan Ringel wrote:
 Am 18.12.2011 00:47, schrieb Oliver Endriss:
 On Sunday 18 December 2011 00:39:49 Oliver Endriss wrote:
 On Saturday 17 December 2011 21:57:16 linu...@stefanringel.de wrote:
 From: Stefan Ringellinu...@stefanringel.de

 all drxk have dvb-t, but not dvb-c.

 Signed-off-by: Stefan Ringellinu...@stefanringel.de
 ---
   drivers/media/dvb/frontends/drxk_hard.c |6 --
   1 files changed, 4 insertions(+), 2 deletions(-)

 diff --git a/drivers/media/dvb/frontends/drxk_hard.c 
 b/drivers/media/dvb/frontends/drxk_hard.c
 index 038e470..8a59801 100644
 --- a/drivers/media/dvb/frontends/drxk_hard.c
 +++ b/drivers/media/dvb/frontends/drxk_hard.c
 @@ -6460,9 +6460,11 @@ struct dvb_frontend *drxk_attach(const struct 
 drxk_config *config,
   init_state(state);
   if (init_drxk(state)  0)
   goto error;
 -*fe_t =state-t_frontend;
  ^^^

 -returnstate-c_frontend;
  ^^
 +if (state-m_hasDVBC)
 +*fe_t =state-c_frontend;
  ^^^
 +
 +returnstate-t_frontend;
 ^^^

   error:
   printk(KERN_ERR drxk: not found\n);
 NAK, this changes the behaviour for existing drivers.

 What is the point to swap DVB-T and DVB-C frontends?
 If you really need this, please add an option to the config struct
 with default that does not change anything for existing drivers.
 Correction:
 Better do something like this (untested):

 if (state-m_hasDVBC) {
 *fe_t =state-t_frontend;
 return state-c_frontend;
 } else
 returnstate-t_frontend;

 CU
 Oliver

 What shall be that, explain? For me not practicable.

The right thing to do here is to create just one frontend per DRX-K.
This were already discussed in the past. Now that we have enough
dvb-core infrastructure to support it, I've made the patches for it:

http://news.gmane.org/gmane.linux.drivers.video-input-infrastructure

I took the m_hasDVBC and m_hasDVBT states into account, so DRX-K
drivers that implement just one of the types should now be properly
reported.

It also made the attachment logic simpler.

Regards,
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: Support for RC-6 in em28xx driver?

2012-01-05 Thread Simon Søndergaard

2012/1/5 Devin Heitmueller dheitmuel...@kernellabs.com:
2012/1/5 Simon Søndergaard john7...@gmail.com:
Hi,

I recently purchased a PCTV 290e USB Stick (em28174) it comes with a
remote almost as small as the stick itself... I've been able to get
both stick and remote to work. I also own an MCE media center remote
from HP (this make
http://www.ebay.com/itm/Original-Win7-PC-MCE-Media-Center-HP-Remote-Controller-/170594956920)
that sends RC-6 codes. While it do have a windows logo I still think
it is vastly superior to the one that shipped with the stick :-)

If I understand it correctly em28174 is a derivative of em2874?

In em28xx-input.c it is stated that: em2874 supports more protocols.
For now, let's just announce the two protocols that were already
tested

I've been searching high and low for a datasheet for em28(1)74, but
have been unable to find it online. Do anyone know if one of the
protocols supported is RC-6? and if so how do I get a copy of the
datasheet?

The 2874 supports NEC, RC-5, and RC-6/6A. I did the original support
(based on the docs provided under NDA) but ironically enough I didn't
have an RC6 remote kicking around so I didn't do the support for it.

IR receivers for MCE devices are dirt cheap ( $20), and if you're
doing a media center then it's likely the PCTV 290e probably isn't in
line-of-site for a remote anyway.

The 290e will be in line of sight.

Perhaps the info is already there, not sure why I overlooked it in the
first place:

EM2874_IR_RC6_MODE_00x08
EM2874_IR_RC6_MODE_6A 0x0b

RC5 and RC6 use same carrier frequency? so do I need another value for
EM28XX_R0F_XCLK?

Br,
/Simon

That said, if you still really want
to see it supported I can probably find a couple of hours to do it (or
walk Mauro through the register differences if he cares to).

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Support for RC-6 in em28xx driver?

2012/1/5 Simon Søndergaard john7...@gmail.com:
2012/1/5 Devin Heitmueller dheitmuel...@kernellabs.com:
2012/1/5 Simon Søndergaard john7...@gmail.com:
Hi,

If I understand it correctly em28174 is a derivative of em2874?

In em28xx-input.c it is stated that: em2874 supports more protocols.
For now, let's just announce the two protocols that were already
tested

IR receivers for MCE devices are dirt cheap ( $20), and if you're
doing a media center then it's likely the PCTV 290e probably isn't in
line-of-site for a remote anyway.

The 290e will be in line of sight.

Perhaps the info is already there, not sure why I overlooked it in the
first place:

EM2874_IR_RC6_MODE_0 0x08
EM2874_IR_RC6_MODE_6A 0x0b

Ah, so I guess I did put at least some of the info into the driver.
Also, for RC6 make sure bits 0-1 are 00 and for RC6A they need to be
set based on the number of bytes expected to be received (2 bytes=00,
3bytes=01, 4bytes=10). The received data gets stored in 0x52-0x55 (I
don't remember if the driver actually looks are 0x54/55 currently
since they aren't used for NEC or RC5)..

RC5 and RC6 use same carrier frequency? so do I need another value for
EM28XX_R0F_XCLK?

You shouldn't need to touch the XCLK register.

Good luck!

Devin

Re: Support for RC-6 in em28xx driver?

On Thu, Jan 5, 2012 at 5:48 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 Yes, it can.  Like almost every IR receiver provided by the linux
 media subsystem, the 290e is configured with the keymap of the
 pinnacle remote *by default*.  There are userland tools (e.g.
 ir-keytable) which allow you to load keymaps in for other remotes.

I should clarify my previous statement by saying that the support for
other remotes is constrained by what the hardware supports.  If the IR
receiver hardware only supports RC5 and NEC, then you can't use an RC6
remote with it.

But to your point, I actually used my Hauppauge remote when I
originally wrote the em2874 IR support (and only at the end
reconfigured it to use the PCTV remote).

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Support for RC-6 in em28xx driver?

2012-01-05 Thread Chris Rankin


Hi,

As someone who also owns a PCTV 290e device, I must agree that the remote 
control that it ships with is useless for VDR. Its biggest flaw is a lack of 
red, green, yellow and blue buttons, unlike the very nice remote control that 
ships with the Hauppauge NOVA-T2.


Are you suggesting that the 290e could (potentially) use *any* NEC, RC-5 or 
RC-6/6A remote control, please? Because I would find that useful... ;-).


Cheers,
Chris
--
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: Support for RC-6 in em28xx driver?

2012-01-05 Thread Simon Søndergaard

2012/1/5 Devin Heitmueller dheitmuel...@kernellabs.com:
2012/1/5 Simon Søndergaard john7...@gmail.com:
2012/1/5 Devin Heitmueller dheitmuel...@kernellabs.com:
2012/1/5 Simon Søndergaard john7...@gmail.com:
Hi,

If I understand it correctly em28174 is a derivative of em2874?

In em28xx-input.c it is stated that: em2874 supports more protocols.
For now, let's just announce the two protocols that were already
tested

IR receivers for MCE devices are dirt cheap ( $20), and if you're
doing a media center then it's likely the PCTV 290e probably isn't in
line-of-site for a remote anyway.

The 290e will be in line of sight.

Perhaps the info is already there, not sure why I overlooked it in the
first place:

EM2874_IR_RC6_MODE_0 0x08
EM2874_IR_RC6_MODE_6A 0x0b

The driver already reads up to 0x55.

Do you mean bits 0-1 of EM2874_R50_IR_CONFIG? The Driver code and the
defines above is in LSB 0 syntax, so bit 0-1 would overlap with the
0x0b value... Regardless I tried using 0x8b, 0x4b, 0x0b, 0x0a and 0x09
as the value for EM2874_R50_IR_CONFIG, but I never observed any
changes to EM2874_R51_IR :-(

I'm assuming that read count should still be read from EM2874_R51_IR
regardless of the mode

Br,
/Simon
--
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: Support for RC-6 in em28xx driver?

2012-01-05 Thread Simon Søndergaard

On Thu, Jan 5, 2012 at 11:51 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Thu, Jan 5, 2012 at 5:48 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
 Yes, it can.  Like almost every IR receiver provided by the linux
 media subsystem, the 290e is configured with the keymap of the
 pinnacle remote *by default*.  There are userland tools (e.g.
 ir-keytable) which allow you to load keymaps in for other remotes.

 I should clarify my previous statement by saying that the support for
 other remotes is constrained by what the hardware supports.  If the IR
 receiver hardware only supports RC5 and NEC, then you can't use an RC6
 remote with it.

 But to your point, I actually used my Hauppauge remote when I
 originally wrote the em2874 IR support (and only at the end
 reconfigured it to use the PCTV remote).

 Devin


Chris,

If the driver supported RC6 out of the box, the I should be able to
use the hp remote on my mythbuntu machine:

sudo ir-keytable -p rc-6 -c -w /lib/udev/rc_keymaps/rc6_mce

/etc/rc_maps.cfg could be updated to make the choice permanent

Br,
/Simon
--
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

em2874 bulk endpoint support

2012-01-05 Thread Dmitriy Fitisov

Hello everyone,
I know, Devin Heitmueller was about to add support  for em2874 bulk endpoint.

Is that still in plans?

Thank you.
Dmitriy 

Copying old thread:
 On Oct 29, 2010, at 2:37 PM, Devin Heitmueller wrote:

  On Fri, Oct 29, 2010 at 2:04 PM, Jarod Wilson jarod at wilsonet.com
 wrote:
  On Oct 15, 2010, at 6:07 PM, Jarod Wilson wrote:...
  So a spot of bad news here... I've been poking at one of Gavin's sticks 
  inside a VM he set up for me, simultaneous with talking to one of the 
  upstream em28xx driver authors. We now have a very good understanding of 
  why the stick isn't working.
  
  All known prior em28xx-based tuner sticks have had at least one 
  isochronous usb endpoint, with a max packet size of 940 bytes, typically. 
  This stick only has bulk usb endpoints and a max packet size of 512. 
  Supporting this stick is actually going to require a fair bit of work in 
  the em28xx driver core to support using bulk transfer instead of 
  isochronous transfer.
  
  Short version: don't buy this stick right now, its going to be a little 
  while before its actually supported.
  
  Jarod,
  
  Just an FYI:  bulk support for em2874/em2884 is on my todo list for
  the near future.


 Ah, very cool. I'm inclined to wait and let you do that part, since you know 
em28xx much better than I do, and I'll just focus on the device-specific 
implementation details (gpio settings, wiring up tuner and demod, etc). I'm 
assuming you have some other manufacturer's em2874/em2884 based devices to work 
on this for... :)


--
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 0/5] Fix dvb-core set_delivery_system and port drxk to one frontend

On 05-01-2012 16:38, Lars Hanisch wrote:
 Hi,
 
  First: I'm no driver but an application developer.
 
 Am 05.01.2012 17:40, schrieb Devin Heitmueller:
 On Thu, Jan 5, 2012 at 10:37 AM, Mauro Carvalho Chehab
 mche...@redhat.com  wrote:
 With all these series applied, it is now possible to use frontend 0
 for all delivery systems. As the current tools don't support changing
 the delivery system, the dvb-fe-tool (on my experimental tree[1]) can now
 be used to change between them:

 Hi Mauro,

 While from a functional standpoint I think this is a good change (and
 we probably should have done it this way all along), is there not
 concern that this could be interpreted by regular users as a
 regression?  Right now they get two frontends, and they can use all
 their existing tools.  We're moving to a model where if users upgraded
 their kernel they would now require some new userland tool to do
 something that the kernel was allowing them to do previously.

 Sure, it's not ABI breakage in the classic sense but the net effect
 is the same - stuff that used to work stops working and now they need
 new tools or to recompile their existing tools to include new
 functionality (which as you mentioned, none of those tools have
 today).
 
 Since now there isn't any consistent behaviour of hybrid multifrontend 
 devices.
 Some create multiple frontends but only one demux/dvr (like drx-k), others 
 create 
 all devices for every delivery system (HVR 4000). But they all could only be 
 opened 
 mutually exclusive. In case of vdr (my favourite app) you have to trick with 
 udev,
 symlinks, remove unwanted frontends etc. to get the devices in a shape so 
 the 
 application can use it. I don't know how mythtv is handling such devices, but 
 I 
 think there will be something like driver-dependend code in the one or other 
 way.
 
 The spec isn't really meaningful for hybrid devices. Maybe we should start 
 there and claim something the driver developer can follow.

We had some discussions about that at the KS workshop. All people there
agreed that the better is to use one frontend by physical device.

So, in the end of the day, all drivers should behave like what those DRX-K
patches are doing.

 Perhaps you would consider some sort of module option that would let
 users fall back to the old behavior?
 
  That would be fine but better would be a module option that will 
  initialize frontend0 to the connected delivery system. In case of DVB-C/-T
  you don't switch frequently from one to the other. You would need extra 
 hardware 
  like a splitter which switches inputs if there are e.g. 5V for an active 
 antenna
  (which means: switch to the dvb-t-input). Is there any DVB-T card which can 
 supply
  such voltage? And is it controllable via an ioctl (like LNB power supply in 
 DVB-S)?

This is called LNA. A proper LNA support is missing. I think we should 
add a DVBv5 property to control it, on the devices that supports this feature.

The DRX-K chips described at the drxk_hard.c don't support such feature, but
there are other devices that supports it.

Btw, there are some DRX-K devices with two separate demods and two separate
frontends. A driver option won't work on such devices, as one frontend may
be connected to DVB-C, and the other one to DVB-T.

Also, the user may have more than one device of the same type (I have 3 sticks 
here
with em28xx/drx-k) that could be used simultaneously. Again, a modprobe
parameter won't fit, if the user wants to use some devices for one type, and
the other ones for the second type.

 
  Anyway, I think, if there's finally a solution so all drivers behave the 
 same,
  the tools and applications will handle this new model in the near future.

Yes, that's what we expect ;)

The DTV_ENUM_DELSYS and DTV_DELIVERY_SYSTEM properties are enough to
properly support such devices.
 
  Please do something... :-)
 
 Regards,
 Lars.
 

 Devin

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

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

Re: em2874 bulk endpoint support