Re: Siano DVB USB device called Smart Plus
Em 20-01-2012 02:34, Denilson Figueiredo de Sá escreveu:
On Thu, Jan 19, 2012 at 12:42, Mauro Carvalho Chehab mche...@redhat.com
wrote:
From the product page, it is a 1-seg device. So, it likely uses a sms1xxx
chip.
Correct, Siano SMS1140.
You'll likely need to add a new board entry there for it, and discover
the GPIO pins linked to the leds and infrared (the numbers for .board_cfg
and .led* on the above data structure). You can do it by either sniffing
the USB board traffic or by opening the device and carefully examining the
board tracks.
I've added two photos of the circuit here:
http://linuxtv.org/wiki/index.php/Smart_Plus
Considering there are these lines at sms-usb.c:
{ USB_DEVICE(0x187f, 0x0202),
.driver_info = SMS1XXX_BOARD_SIANO_NICE },
I thought I didn't need to add a new board entry, just update the
current one.
You may need to add it anyway, as the device may not be equal to
Siano Nice reference board.
Then I added a few lines, as shown below, but it seems
the driver still tries to load dvb_nova_12mhz_b0.inp instead of
isdbt_nova_12mhz_b0.inp.
No. there's a parameter for the smsmdtv module to select the right
standard:
drivers/media/dvb/siano/smscoreapi.c:module_param(default_mode, int, 0644);
You need to pass default_mode=6 for ISDB-T to work. Just renaming
the firmware won't work. Of course, the firmware name entry needs to be
filled.
Btw, adding both firmwares work, as the same device can likely be used
in Europe with DVB-T. So, maybe we can add some parameter there to specify
the default mode. Not sure if such change would be easy though.
If I rename (or symlink) the firmware file, the driver loads the
firmware. After smsdvb module gets loaded, then there is a /dev/dvb/
entry for my device, but still the programs I tried (w_scan and vlc)
don't find any channels.
About the GPIO pins: even on Windows, the only LED from this device
does not blink. So I don't care about LED feedback. Also, right now
I'm not worried about IR remote, so I'm leaving that out.
Anyway, I can supply some usb logs if they would help debugging this.
--- sms-cards.c.orig2012-01-20 00:42:47.0 -0200
+++ sms-cards.c 2012-01-20 01:05:11.0 -0200
@@ -92,6 +92,8 @@
/* 11 */
.name = Siano Nice Digital Receiver,
.type = SMS_NOVA_B0,
+ .fw[DEVICE_MODE_ISDBT_BDA] = isdbt_nova_12mhz_b0.inp,
+ .rc_codes = RC_MAP_HAUPPAUGE,
},
[SMS1XXX_BOARD_SIANO_VENICE] = {
/* 12 */
@@ -299,6 +301,7 @@
case SMS1XXX_BOARD_HAUPPAUGE_WINDHAM:
case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD:
case SMS1XXX_BOARD_HAUPPAUGE_TIGER_MINICARD_R2:
+ case SMS1XXX_BOARD_SIANO_NICE:
request_module(smsdvb);
break;
default:
--
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: Build change in media_build to support Debian
Em 19-01-2012 21:04, Benjamin Limmer escreveu:
commit 2949a7393f3e2598d4de49b408587462b11f819f
Author: Ben Limmer benjamin.lim...@readytalk.com
Date: Thu Jan 19 16:01:15 2012 -0700
Update to build script to give Debian users the Ubunutu package hints.
The aptitude package names are the same.
diff --git a/build b/build
index c3947b3..6843033 100755
--- a/build
+++ b/build
@@ -134,6 +134,10 @@ sub give_hints()
give_arch_linux_hints;
return;
}
+ if ($system_release =~ /Debian/) {
+ give_ubuntu_hints;
+ return;
+ }
# Fall-back to generic hint code
foreach my $prog (@missing) {
Please see the above commit message. This is an easy change to support hints
for debian users. I've confirmed these changes work on Debian Squeeze.
-Ben Limmer--
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
Applied, thanks!
--
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: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On 20 January 2012 00:37, Pawel Osciak pa...@osciak.com wrote:
Hi Sumit,
Thank you for your work. Please find my comments below.
Hi Pawel,
Thank you for finding time for this review, and your comments :) - my
comments inline.
[Also, as an aside, Tomasz has also been working on the vb2 adaptation
to dma-buf, and his patches should be more comprehensive, in that he
is also planning to include 'vb2 as exporter' of dma-buf. He might
take and improve on this RFC, so it might be worthwhile to wait for
it?]
snip
* __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);
This looks like a bug. If memory is MMAP, you'd __vb2_buf_mem_free(vb)
AND __vb2_buf_userptr_put(vb), which is wrong. Have you tested MMAP
and USERPTR with those patches applied?
I agree - fairly stupid mistake on my end. will correct in the next version.
}
@@ -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;
I'm confused here. Isn't this the way to return fd for userspace to
pass to other drivers? I was imagining that the userspace would be
getting an fd back in plane structure to pass to other drivers, i.e.
userspace dequeuing a DMABUF v4l2_buffer should be able to pass it
forward to another driver using fd found in dequeued buffer.
Shouldn't this also fill in length?
Well, as a 'dma-buf' 'user', V4L2 will only get an FD from userspace
to map it to a dma-buf. The 'give-an-fd-to-pass-to-other-drivers' is
part of the exporter's functionality.
That's why I guess we did it like this - the __fill_vb2_buffer() does
copy data from userspace to vb2.
But perhaps you're right; it might be needed if the userspace refers
back to the fd from a dequeued buffer. Let me think through, and I
will reply again.
+ }
snip
@@ -840,6 +899,11 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b,
b-m.planes[plane].length;
}
}
+ if (b-memory == V4L2_MEMORY_DMABUF) {
+ for (plane = 0; plane vb-num_planes; ++plane) {
+ v4l2_planes[plane].m.fd =
b-m.planes[plane].m.fd;
Shouldn't this fill length too?
The reason this doesn't fill length is because length gets updated
based on the actual size of the buffer from the dma-buf gotten from
dma_buf_get() called in __qbuf_dmabuf().
+ }
+ }
} else {
/*
* Single-planar buffers do not use planes array,
@@ -854,6 +918,10 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
const struct v4l2_buffer *b,
v4l2_planes[0].m.userptr = b-m.userptr;
v4l2_planes[0].length = b-length;
}
+ if (b-memory == V4L2_MEMORY_DMABUF) {
+ v4l2_planes[0].m.fd = b-m.fd;
Ditto.
see above.
+ }
+
}
vb-v4l2_buf.field = b-field;
@@ -962,6 +1030,109 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
}
/**
+ * __qbuf_dmabuf() - handle qbuf of a DMABUF buffer
+ */
+static int __qbuf_dmabuf(struct vb2_buffer *vb, const struct v4l2_buffer *b)
+{
+ struct v4l2_plane planes[VIDEO_MAX_PLANES];
+ struct vb2_queue *q = vb-vb2_queue;
+ void *mem_priv;
+ unsigned int plane;
+ int ret;
+ int write = !V4L2_TYPE_IS_OUTPUT(q-type);
+
+ /* Verify and copy relevant information provided by the userspace */
+ ret = __fill_vb2_buffer(vb, b, planes);
+ if (ret)
+ return ret;
+
+ for (plane = 0; plane vb-num_planes; ++plane) {
+ struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
+
+ if (IS_ERR_OR_NULL(dbuf)) {
+ dprintk(1, qbuf: invalid dmabuf fd for
+ plane %d\n, plane);
+ ret = PTR_ERR(dbuf);
+ goto err;
+ }
+
+ /* this doesn't get filled in until
Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Sumit and Pawel,
Please find comments below.
On 01/20/2012 11:41 AM, Sumit Semwal wrote:
On 20 January 2012 00:37, Pawel Osciakpa...@osciak.com wrote:
Hi Sumit,
Thank you for your work. Please find my comments below.
Hi Pawel,
Thank you for finding time for this review, and your comments :) - my
comments inline.
[Also, as an aside, Tomasz has also been working on the vb2 adaptation
to dma-buf, and his patches should be more comprehensive, in that he
is also planning to include 'vb2 as exporter' of dma-buf. He might
take and improve on this RFC, so it might be worthwhile to wait for
it?]
snip
struct vb2_mem_ops {
void*(*alloc)(void *alloc_ctx, unsigned long size);
@@ -65,6 +82,16 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
+ /* Comment from Rob Clark: XXX: I think the attach / detach could be
handled
+* in the vb2 core, and vb2_mem_ops really just need to get/put the
+* sglist (and make sure that the sglist fits it's needs..)
+*/
I *strongly* agree with Rob here. Could you explain the reason behind
not doing this?
Allocator should ideally not have to be aware of attaching/detaching,
this is not specific to an allocator.
Ok, I thought we'll start with this version first, and then refine.
But you guys are right.
I think that it is not possible to move attach/detach to vb2-core. The
problem is that dma_buf_attach needs 'struct device' argument. This
pointer is not available in vb2-core. This pointer is delivered by
device's driver in void *alloc_context.
Moving information about device would introduce new problems like:
- breaking layering in vb2
- some allocators like vb2-vmalloc do not posses any device related
attributes
Best regards,
Tomasz Stanislawski
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] media i.MX27 camera: fix buffer handling and videobuf2 support.
The way video buffer handling is programmed for i.MX27 leads to buffers being written when they are not ready. It can be easily checked enabling DEBUG features of the driver. This series migrate the driver to videobuf2 and provide an additional discard queue to make sure all the events are handled in the right order. I've only tested the series with an i.MX27 device and so I've tried not to touch code scpecific for mx25. However, any mx25 tester would be more than welcome. [PATCH 1/4] media i.MX27 camera: migrate driver to videobuf2 [PATCH 2/4] media i.MX27 camera: add start_stream and stop_stream callbacks. [PATCH 3/4] media i.MX27 camera: improve discard buffer handling. [PATCH 4/4] media i.MX27 camera: handle overflows properly. -- 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/4] media i.MX27 camera: migrate driver to videobuf2
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 277 ++
1 files changed, 128 insertions(+), 149 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 68038e7..290ac9d 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -3,6 +3,7 @@
*
* Copyright (C) 2008, Sascha Hauer, Pengutronix
* Copyright (C) 2010, Baruch Siach, Orex Computed Radiography
+ * Copyright (C) 2012, Javier Martin, Vista Silicon S.L.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -30,8 +31,8 @@
#include media/v4l2-common.h
#include media/v4l2-dev.h
-#include media/videobuf-core.h
-#include media/videobuf-dma-contig.h
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-contig.h
#include media/soc_camera.h
#include media/soc_mediabus.h
@@ -256,13 +257,25 @@ struct mx2_camera_dev {
size_t discard_size;
struct mx2_fmt_cfg *emma_prp;
u32 frame_count;
+ struct vb2_alloc_ctx*alloc_ctx;
+};
+
+enum mx2_buffer_state {
+ MX2_STATE_NEEDS_INIT = 0,
+ MX2_STATE_PREPARED = 1,
+ MX2_STATE_QUEUED = 2,
+ MX2_STATE_ACTIVE = 3,
+ MX2_STATE_DONE = 4,
+ MX2_STATE_ERROR = 5,
+ MX2_STATE_IDLE = 6,
};
/* buffer for one video frame */
struct mx2_buffer {
/* common v4l buffer stuff -- must be first */
- struct videobuf_buffer vb;
-
+ struct vb2_buffer vb;
+ struct list_headqueue;
+ enum mx2_buffer_state state;
enum v4l2_mbus_pixelcodecode;
int bufnum;
@@ -407,7 +420,7 @@ static irqreturn_t mx27_camera_irq(int irq_csi, void *data)
static void mx25_camera_frame_done(struct mx2_camera_dev *pcdev, int fb,
int state)
{
- struct videobuf_buffer *vb;
+ struct vb2_buffer *vb;
struct mx2_buffer *buf;
struct mx2_buffer **fb_active = fb == 1 ? pcdev-fb1_active :
pcdev-fb2_active;
@@ -420,25 +433,24 @@ static void mx25_camera_frame_done(struct mx2_camera_dev
*pcdev, int fb,
goto out;
vb = (*fb_active)-vb;
- dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%08lx %d\n, __func__,
- vb, vb-baddr, vb-bsize);
+ dev_dbg(pcdev-dev, %s (vb=0x%p) 0x%p %lu\n, __func__,
+ vb, vb2_plane_vaddr(vb, 0), vb2_get_plane_payload(vb, 0));
- vb-state = state;
- do_gettimeofday(vb-ts);
- vb-field_count++;
-
- wake_up(vb-done);
+ do_gettimeofday(vb-v4l2_buf.timestamp);
+ vb-v4l2_buf.sequence++;
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
if (list_empty(pcdev-capture)) {
buf = NULL;
writel(0, pcdev-base_csi + fb_reg);
} else {
buf = list_entry(pcdev-capture.next, struct mx2_buffer,
- vb.queue);
+ queue);
vb = buf-vb;
- list_del(vb-queue);
- vb-state = VIDEOBUF_ACTIVE;
- writel(videobuf_to_dma_contig(vb), pcdev-base_csi + fb_reg);
+ list_del(buf-queue);
+ buf-state = MX2_STATE_ACTIVE;
+ writel(vb2_dma_contig_plane_dma_addr(vb, 0),
+ pcdev-base_csi + fb_reg);
}
*fb_active = buf;
@@ -453,9 +465,9 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void *data)
u32 status = readl(pcdev-base_csi + CSISR);
if (status CSISR_DMA_TSF_FB1_INT)
- mx25_camera_frame_done(pcdev, 1, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 1, MX2_STATE_DONE);
else if (status CSISR_DMA_TSF_FB2_INT)
- mx25_camera_frame_done(pcdev, 2, VIDEOBUF_DONE);
+ mx25_camera_frame_done(pcdev, 2, MX2_STATE_DONE);
/* FIXME: handle CSISR_RFF_OR_INT */
@@ -467,59 +479,47 @@ static irqreturn_t mx25_camera_irq(int irq_csi, void
*data)
/*
* Videobuf operations
*/
-static int mx2_videobuf_setup(struct videobuf_queue *vq, unsigned int *count,
- unsigned int *size)
+static int mx2_videobuf_setup(struct vb2_queue *vq,
+ const struct v4l2_format *fmt,
+ unsigned int *count, unsigned int *num_planes,
+ unsigned int sizes[], void *alloc_ctxs[])
{
- struct soc_camera_device *icd = vq-priv_data;
+ struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
+ struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
int bytes_per_line = soc_mbus_bytes_per_line(icd-user_width,
[PATCH 2/4] media i.MX27 camera: add start_stream and stop_stream callbacks.
Add start_stream and stop_stream callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 107 +++---
1 files changed, 77 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 290ac9d..4816da6 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -560,7 +560,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
struct soc_camera_host *ici =
to_soc_camera_host(icd-parent);
struct mx2_camera_dev *pcdev = ici-priv;
- struct mx2_fmt_cfg *prp = pcdev-emma_prp;
struct mx2_buffer *buf = container_of(vb, struct mx2_buffer, vb);
unsigned long flags;
@@ -572,29 +571,7 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
buf-state = MX2_STATE_QUEUED;
list_add_tail(buf-queue, pcdev-capture);
- if (mx27_camera_emma(pcdev)) {
- if (prp-cfg.channel == 1) {
- writel(PRP_CNTL_CH1EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH1_LEN |
- PRP_CNTL_CH1BYP |
- PRP_CNTL_CH1_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
- } else {
- writel(PRP_CNTL_CH2EN |
- PRP_CNTL_CSIEN |
- prp-cfg.in_fmt |
- prp-cfg.out_fmt |
- PRP_CNTL_CH2_LEN |
- PRP_CNTL_CH2_TSKIP(0) |
- PRP_CNTL_IN_TSKIP(0),
- pcdev-base_emma + PRP_CNTL);
- }
- goto out;
- } else { /* cpu_is_mx25() */
+ if (!mx27_camera_emma(pcdev)) { /* cpu_is_mx25() */
u32 csicr3, dma_inten = 0;
if (pcdev-fb1_active == NULL) {
@@ -629,8 +606,6 @@ static void mx2_videobuf_queue(struct vb2_buffer *vb)
writel(csicr3, pcdev-base_csi + CSICR3);
}
}
-
-out:
spin_unlock_irqrestore(pcdev-lock, flags);
}
@@ -692,11 +667,83 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
spin_unlock_irqrestore(pcdev-lock, flags);
}
+static int mx2_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ if (count 2) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (prp-cfg.channel == 1) {
+ writel(PRP_CNTL_CH1EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH1_LEN |
+ PRP_CNTL_CH1BYP |
+ PRP_CNTL_CH1_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ } else {
+ writel(PRP_CNTL_CH2EN |
+ PRP_CNTL_CSIEN |
+ prp-cfg.in_fmt |
+ prp-cfg.out_fmt |
+ PRP_CNTL_CH2_LEN |
+ PRP_CNTL_CH2_TSKIP(0) |
+ PRP_CNTL_IN_TSKIP(0),
+ pcdev-base_emma + PRP_CNTL);
+ }
+ }
+err:
+ spin_unlock_irqrestore(pcdev-lock, flags);
+
+ return ret;
+}
+
+static int mx2_stop_streaming(struct vb2_queue *q)
+{
+ struct soc_camera_device *icd = soc_camera_from_vb2q(q);
+ struct soc_camera_host *ici =
+ to_soc_camera_host(icd-parent);
+ struct mx2_camera_dev *pcdev = ici-priv;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+ unsigned long flags;
+ u32 cntl;
+
+ spin_lock_irqsave(pcdev-lock, flags);
+ if (mx27_camera_emma(pcdev)) {
+ cntl = readl(pcdev-base_emma + PRP_CNTL);
+ if (prp-cfg.channel == 1) {
+ writel(cntl ~PRP_CNTL_CH1EN,
+ pcdev-base_emma + PRP_CNTL);
+ }
[PATCH 3/4] media i.MX27 camera: improve discard buffer handling.
The way discard buffer was previously handled lead
to possible races that made a buffer that was not
yet ready to be overwritten by new video data. This
is easily detected at 25fps just adding #define DEBUG
to enable the memset check and seeing how the image
is corrupted.
A new discard queue and two discard buffers have
been added to make them flow trough the pipeline
of queues and thus provide suitable event ordering.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 215 +-
1 files changed, 117 insertions(+), 98 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 4816da6..e0c5dd4 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -224,6 +224,28 @@ struct mx2_fmt_cfg {
struct mx2_prp_cfg cfg;
};
+enum mx2_buffer_state {
+ MX2_STATE_NEEDS_INIT = 0,
+ MX2_STATE_PREPARED = 1,
+ MX2_STATE_QUEUED = 2,
+ MX2_STATE_ACTIVE = 3,
+ MX2_STATE_DONE = 4,
+ MX2_STATE_ERROR = 5,
+ MX2_STATE_IDLE = 6,
+};
+
+/* buffer for one video frame */
+struct mx2_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct vb2_buffer vb;
+ struct list_headqueue;
+ enum mx2_buffer_state state;
+ enum v4l2_mbus_pixelcodecode;
+
+ int bufnum;
+ booldiscard;
+};
+
struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
@@ -240,6 +262,7 @@ struct mx2_camera_dev {
struct list_headcapture;
struct list_headactive_bufs;
+ struct list_headdiscard;
spinlock_t lock;
@@ -252,6 +275,7 @@ struct mx2_camera_dev {
u32 csicr1;
+ struct mx2_buffer buf_discard[2];
void*discard_buffer;
dma_addr_t discard_buffer_dma;
size_t discard_size;
@@ -260,27 +284,6 @@ struct mx2_camera_dev {
struct vb2_alloc_ctx*alloc_ctx;
};
-enum mx2_buffer_state {
- MX2_STATE_NEEDS_INIT = 0,
- MX2_STATE_PREPARED = 1,
- MX2_STATE_QUEUED = 2,
- MX2_STATE_ACTIVE = 3,
- MX2_STATE_DONE = 4,
- MX2_STATE_ERROR = 5,
- MX2_STATE_IDLE = 6,
-};
-
-/* buffer for one video frame */
-struct mx2_buffer {
- /* common v4l buffer stuff -- must be first */
- struct vb2_buffer vb;
- struct list_headqueue;
- enum mx2_buffer_state state;
- enum v4l2_mbus_pixelcodecode;
-
- int bufnum;
-};
-
static struct mx2_fmt_cfg mx27_emma_prp_table[] = {
/*
* This is a generic configuration which is valid for most
@@ -334,6 +337,29 @@ static struct mx2_fmt_cfg *mx27_emma_prp_get_format(
return mx27_emma_prp_table[0];
};
+static void mx27_update_emma_buf(struct mx2_camera_dev *pcdev,
+unsigned long phys, int bufnum)
+{
+ u32 imgsize = pcdev-icd-user_height * pcdev-icd-user_width;
+ struct mx2_fmt_cfg *prp = pcdev-emma_prp;
+
+ if (prp-cfg.channel == 1) {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_RGB1_PTR + 4 * bufnum);
+ } else {
+ writel(phys, pcdev-base_emma +
+ PRP_DEST_Y_PTR -
+ 0x14 * bufnum);
+ if (prp-out_fmt == V4L2_PIX_FMT_YUV420) {
+ writel(phys + imgsize,
+ pcdev-base_emma + PRP_DEST_CB_PTR -
+ 0x14 * bufnum);
+ writel(phys + ((5 * imgsize) / 4), pcdev-base_emma +
+ PRP_DEST_CR_PTR - 0x14 * bufnum);
+ }
+ }
+}
+
static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
{
unsigned long flags;
@@ -382,7 +408,7 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
pcdev-icd = icd;
- pcdev-frame_count = -1;
+ pcdev-frame_count = 0;
dev_info(icd-parent, Camera driver attached to camera %d\n,
icd-devnum);
@@ -648,10 +674,9 @@ static void mx2_videobuf_release(struct vb2_buffer *vb)
* types.
*/
spin_lock_irqsave(pcdev-lock, flags);
- if (buf-state == MX2_STATE_QUEUED || buf-state == MX2_STATE_ACTIVE) {
- list_del_init(buf-queue);
- buf-state = MX2_STATE_NEEDS_INIT;
- } else if (cpu_is_mx25() buf-state == MX2_STATE_ACTIVE) {
+ INIT_LIST_HEAD(buf-queue);
+ buf-state = MX2_STATE_NEEDS_INIT;
+ if (cpu_is_mx25() buf-state ==
[PATCH 4/4] media i.MX27 camera: handle overflows properly.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index e0c5dd4..cdc614f 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -1274,7 +1274,10 @@ static void mx27_camera_frame_done_emma(struct
mx2_camera_dev *pcdev,
buf-state = state;
do_gettimeofday(vb-v4l2_buf.timestamp);
vb-v4l2_buf.sequence = pcdev-frame_count;
- vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
+ if (state == MX2_STATE_ERROR)
+ vb2_buffer_done(vb, VB2_BUF_STATE_ERROR);
+ else
+ vb2_buffer_done(vb, VB2_BUF_STATE_DONE);
}
pcdev-frame_count++;
@@ -1309,19 +1312,11 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
struct mx2_buffer *buf;
if (status (1 7)) { /* overflow */
- u32 cntl;
- /*
-* We only disable channel 1 here since this is the only
-* enabled channel
-*
-* FIXME: the correct DMA overflow handling should be resetting
-* the buffer, returning an error frame, and continuing with
-* the next one.
-*/
- cntl = readl(pcdev-base_emma + PRP_CNTL);
- writel(cntl ~(PRP_CNTL_CH1EN | PRP_CNTL_CH2EN),
- pcdev-base_emma + PRP_CNTL);
- writel(cntl, pcdev-base_emma + PRP_CNTL);
+ buf = list_entry(pcdev-active_bufs.next,
+ struct mx2_buffer, queue);
+ mx27_camera_frame_done_emma(pcdev,
+ buf-bufnum, MX2_STATE_ERROR);
+ status = ~(1 7);
}
if status (3 5)) == (3 5)) ||
((status (3 3)) == (3 3)))
--
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
Re: [PATCH] Adding YUV input support for OMAP3ISP driver
Hi Enrico, On Thursday 19 January 2012 15:17:57 Enrico wrote: On Thu, Jan 19, 2012 at 2:52 PM, Gary Thomas g...@mlbassoc.com wrote: On 2012-01-19 06:35, Gary Thomas wrote: My camera init code is attached. In the previous kernel, the I2C bus was probed implicitly when I initialized the OMAP3ISP. I thought I remembered some discussion about how that worked (maybe changing), so this is probably where the problem starts. If you have an example, I can check my setup against it. Note: I reworked how the sensor+I2C was initialized to be omap3_init_camera(cobra3530p73_isp_platform_data); omap_register_i2c_bus(cobra3530p73_isp_platform_data.subdevs-subdevs[0] .i2c_adapter_id, 400, cobra3530p73_isp_platform_data.subdevs-subdevs[0].board_info, 1); The TVP5150 is now found, but 'media-ctl -p' still dies :-( Have a look at [1] (the linux_3.2.bb file to see the list of patches,inside linux-3.2 directory for the actual patches), it's based on mainline kernel 3.2 and the bt656 patches i submitted months ago, it should be easy to adapt it for you board. rant Really, there are patches for all these problems since months (from me, Javier, TI), but because no maintainer cared (apart from Laurent) they were never reviewed/applied and there is always someone who comes back with all the usual problems (additional yuv format, bt656 mode, tvp5150 that doesn't work...). /rant I totally understand your feeling. I'd like to get YUV support integrated in the OMAP3 ISP driver. However, I have no YUV image source hardware, so I can only review the patches but not test them. If someone can rebase the existing patches on top of http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp- omap3isp-yuv and test them, then I'll review the result. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [RFC] dvb: Add DVBv5 properties for quality parameters
The DVBv3 quality parameters are limited on several ways:
- Doesn't provide any way to indicate the used measure;
- Userspace need to guess how to calculate the measure;
- Only a limited set of stats are supported;
- Doesn't provide QoS measure for the OFDM TPS/TMCC
carriers, used to detect the network parameters for
DVB-T/ISDB-T;
- Can't be called in a way to require them to be filled
all at once (atomic reads from the hardware), with may
cause troubles on interpreting them on userspace;
- On some OFDM delivery systems, the carriers can be
independently modulated, having different properties.
Currently, there's no way to report per-layer stats;
This RFC adds the header definitions meant to solve that issues.
After discussed, I'll write a patch for the DocBook and add support
for it on some demods. Support for dvbv5-zap and dvbv5-scan tools
will also have support for those features.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
include/linux/dvb/frontend.h | 78 +-
1 files changed, 77 insertions(+), 1 deletions(-)
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index cb4428a..f9cdb7d 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -320,7 +320,21 @@ struct dvb_frontend_event {
#define DTV_ENUM_DELSYS44
-#define DTV_MAX_COMMANDDTV_ENUM_DELSYS
+/* Quality parameters */
+#define DTV_ENUM_QUALITY 45 /* Enumerates supported QoS parameters
*/
+#define DTV_QUALITY_SNR46
+#define DTV_QUALITY_CNR47
+#define DTV_QUALITY_EsNo 48
+#define DTV_QUALITY_EbNo 49
+#define DTV_QUALITY_RELATIVE 50
+#define DTV_ERROR_BER 51
+#define DTV_ERROR_PER 52
+#define DTV_ERROR_PARAMS 53 /* Error count at TMCC or TPS carrier */
+#define DTV_FE_STRENGTH54
+#define DTV_FE_SIGNAL 55
+#define DTV_FE_UNC 56
+
+#define DTV_MAX_COMMANDDTV_FE_UNC
typedef enum fe_pilot {
PILOT_ON,
@@ -372,12 +386,74 @@ struct dtv_cmds_h {
__u32 reserved:30;/* Align */
};
+/**
+ * Scale types for the quality parameters.
+ * @FE_SCALE_DECIBEL: The scale is measured in dB, typically
+ * used on signal measures.
+ * @FE_SCALE_LINEAR: The scale is linear.
+ * typically used on error QoS parameters.
+ * @FE_SCALE_RELATIVE: The scale is relative.
+ */
+enum fecap_scale_params {
+ FE_SCALE_DECIBEL,
+ FE_SCALE_LINEAR,
+ FE_SCALE_RELATIVE
+};
+
+/**
+ * struct dtv_status - Used for reading a DTV status property
+ *
+ * @value: value of the measure. Should range from 0 to 0x;
+ * @scale: Filled with enum fecap_scale_params - the scale
+ * in usage for that parameter
+ * @min: minimum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0.
+ * @max: maximum value. Not used if the scale is relative.
+ * For non-relative measures, define the measure
+ * associated with dtv_status.value == 0x.
+ *
+ * At userspace, min/max values should be used to calculate the
+ * absolute value of that measure, if fecap_scale_params is not
+ * FE_SCALE_RELATIVE, using the following formula:
+ * measure = min + (value * (max - min) / 0x)
+ *
+ * For error count measures, typically, min = 0, and max = 0x,
+ * and the measure represent the number of errors detected.
+ *
+ * Up to 4 status groups can be provided. This is for the
+ * OFDM standards where the carriers can be grouped into
+ * independent layers, each with its own modulation. When
+ * such layers are used (for example, on ISDB-T), the status
+ * should be filled with:
+ * stat.status[0] = global statistics;
+ * stat.status[1] = layer A statistics;
+ * stat.status[2] = layer B statistics;
+ * stat.status[3] = layer C statistics.
+ * and stat.len should be filled with the latest filled status + 1.
+ * If the frontend doesn't provide a global statistics,
+ * stat.has_global should be 0.
+ * Delivery systems that don't use it, should just set stat.len and
+ * stat.has_global with 1, and fill just stat.status[0].
+ */
+struct dtv_status {
+ __u16 value;
+ __u16 scale;
+ __s16 min;
+ __s16 max;
+} __attribute__ ((packed));
+
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
+ __u8 len;
+ __u8 has_global;
+ struct dtv_status status[4];
+ } stat;
+ struct {
__u8 data[32];
__u32 len;
__u32
[PATCH v2 0/2] add dm365 specific media formats
add mediabus formats and pixel formats supported as part of dm365 vpfe device. The device supports media formats(transfer and storage) which include- 1: ALAW compressed bayer. 2: UV interleaved without Y (for resizer). 3: YDYC. Changes from previous version: 1: Added entries in subdev-formats.xml for V4L2_MBUS_FMT_YDYC8_1X16, V4L2_MBUS_FMT_UV8_1X8, V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8, V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8, V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8, V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8. 2: Added documentation of ALAW and UV8 pix format. Manjunath Hadli (2): media: add new mediabus format enums for dm365 v4l2: add new pixel formats supported on dm365 .../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62 +++ Documentation/DocBook/media/v4l/pixfmt.xml |2 + Documentation/DocBook/media/v4l/subdev-formats.xml | 171 include/linux/v4l2-mediabus.h | 10 +- include/linux/videodev2.h |9 + 6 files changed, 286 insertions(+), 2 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] media: add new mediabus format enums for dm365
add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYC8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 171 include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..48d92bb 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -356,6 +356,9 @@ listitemparaIf the pixel components are DPCM-compressed, a mention of the DPCM compression and the number of bits per compressed pixel component./para /listitem + listitemparaIf the pixel components are ALAW-compressed, a mention of the + ALAW compression and the number of bits per compressed pixel component./para + /listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -572,6 +575,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row row id=V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-BE entryV4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE/entry entry0x3003/entry @@ -965,6 +1036,56 @@ entryysubscript1/subscript/entry entryysubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-UV8-1X8 + entryV4L2_MBUS_FMT_UV8_1X8/entry + entry0x2015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry +
[PATCH v2 2/2] v4l2: add new pixel formats supported on dm365
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 and associated formats
to represent Bayer format frames compressed by A-LAW alogorithm,
add V4L2_PIX_FMT_UV8 to represent storage of C data (UV interleved)
only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
.../DocBook/media/v4l/pixfmt-srggb10alaw8.xml | 34 +++
Documentation/DocBook/media/v4l/pixfmt-uv8.xml | 62
Documentation/DocBook/media/v4l/pixfmt.xml |2 +
include/linux/videodev2.h |9 +++
4 files changed, 107 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-uv8.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
new file mode 100644
index 000..8c1765c
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml
@@ -0,0 +1,34 @@
+ refentry
+ refmeta
+ refentrytitle
+ V4L2_PIX_FMT_SRGGB10ALAW8 ('bBL8'),
+ V4L2_PIX_FMT_SGBRG10ALAW8 ('bgL8'),
+ V4L2_PIX_FMT_SGRBG10ALAW8 ('BGL8'),
+ V4L2_PIX_FMT_SBGGR10ALAW8 ('bRL8'),
+ /refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname id=V4L2-PIX-FMT-SRGGB10ALAW8
+ constantV4L2_PIX_FMT_SRGGB10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGRBG10ALAW8
+ constantV4L2_PIX_FMT_SGRBG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SGBRG10ALAW8
+ constantV4L2_PIX_FMT_SGBRG10ALAW8/constant
+ /refname
+ refname id=V4L2-PIX-FMT-SBGGR10ALAW8
+ constantV4L2_PIX_FMT_SBGGR10ALAW8/constant
+ /refname
+ refpurpose10-bit Bayer formats compressed to 8 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraThe following four pixel formats are raw sRGB / Bayer
+ formats with 10 bits per colour compressed to 8 bits each,
+ using the A-LAW algorithm. Each colour component consumes 8
+ bits of memory. In other respects this format is similar to
+ xref linkend=V4L2-PIX-FMT-SRGGB8./xref/para
+ /refsect1
+ /refentry
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
new file mode 100644
index 000..e3e6b11
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml
@@ -0,0 +1,62 @@
+ refentry id=V4L2-PIX-FMT-UV8
+ refmeta
+ refentrytitleV4L2_PIX_FMT_UV8 ('UV8')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_UV8/constant/refname
+ refpurposeUV plane interleaved/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+ paraIn this format there is no Y plane, Only C plane. ie
+ (UV interleaved)/para
+ example
+ title
+ constantV4L2_PIX_FMT_UV8/constant
+ pixel image
+ /title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript20/subscript/entry
+ entryCrsubscript20/subscript/entry
+ entryCbsubscript21/subscript/entry
+ entryCrsubscript21/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;12:/entry
+ entryCbsubscript30/subscript/entry
+ entryCrsubscript30/subscript/entry
+ entryCbsubscript31/subscript/entry
+ entryCrsubscript31/subscript/entry
+ /row
+ /tbody
+ /tgroup
+ /informaltable
+ /para
+ /formalpara
Re: [Linaro-mm-sig] [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism
Hi Summit,
Sorry for the late review. I know that this code is now in mainline, but I
still have a couple of comments. I'll send patches if you agree with them.
On Monday 26 December 2011 10:23:15 Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- creation of a buffer object, its association with a file pointer, and
associated allocator-defined operations on that buffer. This operation
is called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object,
to facilitate backing storage negotiation, using dma_buf_attach() API. -
the exported buffer object to be shared with the other entity by asking
for its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed
using the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this
buffer object using map_dma_buf and unmap_dma_buf operations.
Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.
Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.
For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
allowed.
More details are there in the documentation patch.
This is based on design suggestions from many people at the
mini-summits[1], most notably from Arnd Bergmann a...@arndb.de, Rob
Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch.
The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer
sharing between two v4l2 devices. [2]
[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Dave Airlie airl...@redhat.com
Reviewed-and-Tested-by: Rob Clark rob.cl...@linaro.org
---
drivers/base/Kconfig| 10 ++
drivers/base/Makefile |1 +
drivers/base/dma-buf.c | 291
+++ include/linux/dma-buf.h |
176
4 files changed, 478 insertions(+), 0 deletions(-)
create mode 100644 drivers/base/dma-buf.c
create mode 100644 include/linux/dma-buf.h
[snip]
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
new file mode 100644
index 000..e38ad24
--- /dev/null
+++ b/drivers/base/dma-buf.c
@@ -0,0 +1,291 @@
[snip]
+/**
+ * dma_buf_export - Creates a new dma_buf, and associates an anon file
+ * with this buffer, so it can be exported.
+ * Also connect the allocator specific data and ops to the buffer.
+ *
+ * @priv:[in]Attach private data of allocator to this buffer
+ * @ops: [in]Attach allocator-defined dma buf ops to the new buffer.
+ * @size:[in]Size of the buffer
+ * @flags: [in]mode flags for the file.
+ *
+ * Returns, on success, a newly created dma_buf object, which wraps the
+ * supplied private data and operations for dma_buf_ops. On either missing
+ * ops, or error in allocating struct dma_buf, will return negative error.
+ *
+ */
+struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
+ size_t size, int flags)
+{
+ struct dma_buf *dmabuf;
+ struct file *file;
+
+ if (WARN_ON(!priv || !ops
+ || !ops-map_dma_buf
+ || !ops-unmap_dma_buf
+ || !ops-release)) {
+ return ERR_PTR(-EINVAL);
+ }
+
+ dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
+ if (dmabuf == NULL)
+ return ERR_PTR(-ENOMEM);
+
+ dmabuf-priv = priv;
+ dmabuf-ops = ops;
dmabuf-ops will never but NULL, but (see below)
+ dmabuf-size = size;
+
+ file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
+
+ dmabuf-file = file;
+
+ mutex_init(dmabuf-lock);
+ INIT_LIST_HEAD(dmabuf-attachments);
+
+ return dmabuf;
+}
+EXPORT_SYMBOL_GPL(dma_buf_export);
[snip]
+/**
+ * dma_buf_attach - Add the device to dma_buf's attachments list;
optionally, + * calls attach() of dma_buf_ops to allow device-specific
attach functionality + * @dmabuf: [in]buffer to attach device to.
+ * @dev: [in]device to be attached.
+ *
+ * Returns struct dma_buf_attachment * for this attachment; may return
Re: Build change in media_build to support Debian
Il 20/01/2012 11:20, Mauro Carvalho Chehab ha scritto:
Em 19-01-2012 21:04, Benjamin Limmer escreveu:
commit 2949a7393f3e2598d4de49b408587462b11f819f
Author: Ben Limmer benjamin.lim...@readytalk.com
Date: Thu Jan 19 16:01:15 2012 -0700
Update to build script to give Debian users the Ubunutu package hints.
The aptitude package names are the same.
diff --git a/build b/build
index c3947b3..6843033 100755
--- a/build
+++ b/build
@@ -134,6 +134,10 @@ sub give_hints()
give_arch_linux_hints;
return;
}
+ if ($system_release =~ /Debian/) {
+ give_ubuntu_hints;
+ return;
+ }
# Fall-back to generic hint code
foreach my $prog (@missing) {
Please see the above commit message. This is an easy change to support hints
for debian users. I've confirmed these changes work on Debian Squeeze.
-Ben Limmer--
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
Applied, thanks!
--
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
Hi Mauro,
after this patch, the build script on media_build has lost the
execute permissions.
Can you chmod +x it again?
Best regards,
Gianluca
--
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: Build change in media_build to support Debian
Em 20-01-2012 11:34, Gianluca Gennari escreveu:
Il 20/01/2012 11:20, Mauro Carvalho Chehab ha scritto:
Em 19-01-2012 21:04, Benjamin Limmer escreveu:
commit 2949a7393f3e2598d4de49b408587462b11f819f
Author: Ben Limmer benjamin.lim...@readytalk.com
Date: Thu Jan 19 16:01:15 2012 -0700
Update to build script to give Debian users the Ubunutu package hints.
The aptitude package names are the same.
diff --git a/build b/build
index c3947b3..6843033 100755
--- a/build
+++ b/build
@@ -134,6 +134,10 @@ sub give_hints()
give_arch_linux_hints;
return;
}
+ if ($system_release =~ /Debian/) {
+ give_ubuntu_hints;
+ return;
+ }
# Fall-back to generic hint code
foreach my $prog (@missing) {
Please see the above commit message. This is an easy change to support
hints for debian users. I've confirmed these changes work on Debian Squeeze.
-Ben Limmer--
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
Applied, thanks!
--
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
Hi Mauro,
after this patch, the build script on media_build has lost the
execute permissions.
Can you chmod +x it again?
Thanks for pointing it!
Fixed.
Best regards,
Gianluca
--
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: [Linaro-mm-sig] [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Sumit,
On Thursday 05 January 2012 11:41:56 Sumit Semwal wrote:
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
Re: [Linaro-mm-sig] [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Sumit,
On Monday 16 January 2012 06:33:31 Semwal, Sumit wrote:
On Sun, Jan 15, 2012 at 2:08 AM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sumit,
Thanks for the patch!
Hi Sakari,
Thanks for reviewing this :)
snip
Shouldn't the buffer mapping only be done at the first call to
__qbuf_dmabuf()? On latter calls, the cache would need to be handled
according to presence of V4L2_BUF_FLAG_NO_CACHE_CLEAN /
V4L2_BUF_FLAG_NO_CACHE_INVALIDATE in v4l2_buffer.
Well, the 'map / unmap' implementation is by design exporter-specific; so
the exporter of the buffer may choose to, depending on the use case,
'map-and-keep' on first call to map_dmabuf, and do actual unmap only at
'release' time. This will mean that the {map,unmap}_dmabuf calls will be
used mostly for 'access-bracketing' between multiple users, and not for
actual map/unmap each time.
Again, the framework is flexible enough to allow exporters to actually
map/unmap as required (think cases where backing-storage migration might be
needed while buffers are in use - in that case, when all current users have
called unmap_XXX() on a buffer, it can be migrated, and the next map_XXX()
calls could give different mappings back to the users).
The kernel 'users' of dma-buf [in case of this RFC, v4l2] should not
ideally need to worry about the actual mapping/unmapping that is done; the
buffer exporter in a particular use-case should be able to handle it.
I'm afraid it's more complex than that. Your patch calls q-mem_ops-
map_dmabuf() at every VIDIOC_QBUF call. The function will call
dma_buf_map_attachment(), which could cache the mapping somehow (even though
that triggers an alarm somewhere in my brain, deciding in the exporter how to
do so will likely cause issues - I'll try to sort my thoughts out on this),
but it will also be responsible for mapping the sg list to the V4L2 device
IOMMU (not for dma-contig obviously, but this code is in videobuf2-core.c).
This is an expensive operation that we don't want to perform at every
QBUF/DQBUF.
V4L2 uses streaming DMA mappings, partly for performance reasons. That's
something dma-buf will likely need to support. Or you could argue that
streaming DMA mappings are broken by design on some platform anyway, but then
I'll expect a proposal for an efficient replacement :-)
snip
Same here, except reverse: this only should be done when the buffer is
destroyed --- either when the user explicitly calls reqbufs(0) or when
the file handle owning this buffer is being closed.
Mapping buffers at every prepare_buf and unmapping them in dqbuf is
prohibitively expensive. Same goes for many other APIs than V4L2, I
think.
I wonder if the means to do this exists already.
I have to admit I haven't followed the dma_buf discussion closely so I
might be missing something relevant here.
Hope the above explanation helps. Please do not hesitate to contact if you
need more details.
--
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: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Tomasz,
On Friday 20 January 2012 11:58:39 Tomasz Stanislawski wrote:
On 01/20/2012 11:41 AM, Sumit Semwal wrote:
On 20 January 2012 00:37, Pawel Osciakpa...@osciak.com wrote:
Hi Sumit,
Thank you for your work. Please find my comments below.
Hi Pawel,
Thank you for finding time for this review, and your comments :) - my
comments inline.
[Also, as an aside, Tomasz has also been working on the vb2 adaptation
to dma-buf, and his patches should be more comprehensive, in that he
is also planning to include 'vb2 as exporter' of dma-buf. He might
take and improve on this RFC, so it might be worthwhile to wait for
it?]
snip
struct vb2_mem_ops {
void*(*alloc)(void *alloc_ctx, unsigned long size);
@@ -65,6 +82,16 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
+ /* Comment from Rob Clark: XXX: I think the attach / detach
could be handled +* in the vb2 core, and vb2_mem_ops really
just need to get/put the +* sglist (and make sure that the
sglist fits it's needs..) +*/
I *strongly* agree with Rob here. Could you explain the reason behind
not doing this?
Allocator should ideally not have to be aware of attaching/detaching,
this is not specific to an allocator.
Ok, I thought we'll start with this version first, and then refine.
But you guys are right.
I think that it is not possible to move attach/detach to vb2-core. The
problem is that dma_buf_attach needs 'struct device' argument. This
pointer is not available in vb2-core. This pointer is delivered by
device's driver in void *alloc_context.
Moving information about device would introduce new problems like:
- breaking layering in vb2
- some allocators like vb2-vmalloc do not posses any device related
attributes
What about passing the device to vb2-core then ?
--
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: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Laurent,
On 01/20/2012 04:12 PM, Laurent Pinchart wrote:
Hi Tomasz,
On Friday 20 January 2012 11:58:39 Tomasz Stanislawski wrote:
On 01/20/2012 11:41 AM, Sumit Semwal wrote:
On 20 January 2012 00:37, Pawel Osciakpa...@osciak.com wrote:
Hi Sumit,
Thank you for your work. Please find my comments below.
Hi Pawel,
snip
struct vb2_mem_ops {
void*(*alloc)(void *alloc_ctx, unsigned long size);
@@ -65,6 +82,16 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
+ /* Comment from Rob Clark: XXX: I think the attach / detach
could be handled +* in the vb2 core, and vb2_mem_ops really
just need to get/put the +* sglist (and make sure that the
sglist fits it's needs..) +*/
I *strongly* agree with Rob here. Could you explain the reason behind
not doing this?
Allocator should ideally not have to be aware of attaching/detaching,
this is not specific to an allocator.
Ok, I thought we'll start with this version first, and then refine.
But you guys are right.
I think that it is not possible to move attach/detach to vb2-core. The
problem is that dma_buf_attach needs 'struct device' argument. This
pointer is not available in vb2-core. This pointer is delivered by
device's driver in void *alloc_context.
Moving information about device would introduce new problems like:
- breaking layering in vb2
- some allocators like vb2-vmalloc do not posses any device related
attributes
What about passing the device to vb2-core then ?
IMO, One way to do this is adding field 'struct device *dev' to struct
vb2_queue. This field should be filled by a driver prior to calling
vb2_queue_init.
Regards,
Tomasz Stanislawski
--
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: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
Hi Tomasz,
On Friday 20 January 2012 16:53:20 Tomasz Stanislawski wrote:
On 01/20/2012 04:12 PM, Laurent Pinchart wrote:
On Friday 20 January 2012 11:58:39 Tomasz Stanislawski wrote:
On 01/20/2012 11:41 AM, Sumit Semwal wrote:
On 20 January 2012 00:37, Pawel Osciakpa...@osciak.com wrote:
Hi Sumit,
Thank you for your work. Please find my comments below.
Hi Pawel,
snip
struct vb2_mem_ops {
void*(*alloc)(void *alloc_ctx, unsigned long
size);
@@ -65,6 +82,16 @@ struct vb2_mem_ops {
unsigned long size, int
write);
void(*put_userptr)(void *buf_priv);
+ /* Comment from Rob Clark: XXX: I think the attach / detach
could be handled +* in the vb2 core, and vb2_mem_ops really
just need to get/put the +* sglist (and make sure that the
sglist fits it's needs..) +*/
I *strongly* agree with Rob here. Could you explain the reason behind
not doing this?
Allocator should ideally not have to be aware of attaching/detaching,
this is not specific to an allocator.
Ok, I thought we'll start with this version first, and then refine.
But you guys are right.
I think that it is not possible to move attach/detach to vb2-core. The
problem is that dma_buf_attach needs 'struct device' argument. This
pointer is not available in vb2-core. This pointer is delivered by
device's driver in void *alloc_context.
Moving information about device would introduce new problems like:
- breaking layering in vb2
- some allocators like vb2-vmalloc do not posses any device related
attributes
What about passing the device to vb2-core then ?
IMO, One way to do this is adding field 'struct device *dev' to struct
vb2_queue. This field should be filled by a driver prior to calling
vb2_queue_init.
I haven't looked into the details, but that sounds good to me. Do we have use
cases where a queue is allocated before knowing which physical device it will
be used for ?
--
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
Remote control driver issue
Hello folks, i am a linux-TV newby; dreaming to get my vdr up and runing for up to 4month i am a blind user and have a limited access to the linux machine due to my blindness, i access windows normaly, then ssh to linux (*SORY FOR THAT*) so, i set up my debian machine correctly, runing, dbvb card detected, scaned, working through multicast using mumuDVB thank a lot to the #linuxtv people on freenode they helped me a lot so i should return something:) i installed v4l into my debian machine if i do make load my remote control get detected but if i reboot; Couldn't find any node at /sys/class/rc/rc*. so please how to make it auto loadable? i should do that every time my pc reboot, make load thank you a lot BTW, can i help with mailing list moderation ? -- 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: Remote control driver issue
On Fri, Jan 20, 2012 at 11:14 AM, Tayeb Meftah tayeb.mef...@gmail.com wrote: Hello folks, i am a linux-TV newby; dreaming to get my vdr up and runing for up to 4month i am a blind user and have a limited access to the linux machine due to my blindness, i access windows normaly, then ssh to linux (*SORY FOR THAT*) so, i set up my debian machine correctly, runing, dbvb card detected, scaned, working through multicast using mumuDVB thank a lot to the #linuxtv people on freenode they helped me a lot so i should return something:) i installed v4l into my debian machine if i do make load my remote control get detected but if i reboot; Couldn't find any node at /sys/class/rc/rc*. so please how to make it auto loadable? i should do that every time my pc reboot, make load thank you a lot BTW, can i help with mailing list moderation ? What tuner are you using? That is a very important piece of information since it tells us what drivers are involved for the IR support. Regards, 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: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Regards, Tomasz Stanislawski -- 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: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)
On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote: IMO, One way to do this is adding field 'struct device *dev' to struct vb2_queue. This field should be filled by a driver prior to calling vb2_queue_init. I haven't looked into the details, but that sounds good to me. Do we have use cases where a queue is allocated before knowing which physical device it will be used for ? I don't think so. In case of S5P drivers, vb2_queue_init is called while opening /dev/videoX. BTW. This struct device may help vb2 to produce logs with more descriptive client annotation. What happens if such a device is NULL. It would happen for vmalloc allocator used by VIVI? Good question. Should dma-buf accept NULL devices ? Or should vivi pass its V4L2 device to vb2 ? -- 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
[GIT PULL]: dma-buf tree: maintainer update
Hi Linus, Post the merge of dma-buf tree that was (very kindly) sent by Dave Airlie, various people involved in this project feel it is natural and practical for me to be the maintainer of this code. This is my first pull request to you, which only changes the MAINTAINERS file - could you please pull from it? [If you'd just prefer the patch, I could post that out as well.] Thanks and best regards, ~Sumit. The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) are available in the git repository at: git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git for-linus-3.3 Sumit Semwal (1): MAINTAINERS: Add dma-buf sharing framework maintainer MAINTAINERS | 11 +++ 1 files changed, 11 insertions(+), 0 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Jan 20 19:00:17 CET 2012 git hash:36be126cb0ebe3000a65c1049f339a3e882a9a47 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] af9013: fix i2c failures for dual-tuner devices
This patch fixes the following error messages with a
Terratec Cinergy T Stick Dual RC DVB-T device.
af9013: i2c wr failed=-1 reg=d607 len=1
af9015: command failed:2
af9013: i2c rd failed=-1 reg=d607 len=1
af9015: command failed:1
It implements exclusive access to i2c for only one frontend at a time
through a use-counter that is increased for each af9013_i2c_gate_ctrl-enable
or i2c-read/write and decreased accordingly. The use-counter remains
incremented after af9013_i2c_gate_ctrl-enable until the corresponding
disable.
Debug output was added.
ToDo:
* Replace frontend by adapter (the dual-tuner devices do actually
provide two adapters with one frontend each)
* move af9013_i2c_gate_mutex, locked_fe, af9013_i2c_gate_ctrl_usecnt
to the usb device
---
drivers/media/dvb/frontends/af9013.c | 93 +-
1 files changed, 80 insertions(+), 13 deletions(-)
diff --git a/drivers/media/dvb/frontends/af9013.c
b/drivers/media/dvb/frontends/af9013.c
index 6bcbcf5..ab69585 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -28,6 +28,54 @@ int af9013_debug;
module_param_named(debug, af9013_debug, int, 0644);
MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).);
+static DEFINE_MUTEX(af9013_i2c_gate_mutex);
+static struct dvb_frontend *locked_fe = 0;
+static int af9013_i2c_gate_ctrl_usecnt = 0;
+
+#define GATE_NOOP0
+#define GATE_ENABLE 1
+#define GATE_DISABLE 2
+
+static int af9013_i2c_gate_inc_use_count(struct dvb_frontend *fe, int gate_op)
+{
+ int success = 0;
+ while (1) {
+ if (mutex_lock_interruptible(af9013_i2c_gate_mutex) != 0) {
+ return -EAGAIN;
+ }
+ if (af9013_i2c_gate_ctrl_usecnt == 0 || locked_fe == fe) {
+ success = 1;
+ locked_fe = fe;
+ if (gate_op != GATE_DISABLE) {
+ af9013_i2c_gate_ctrl_usecnt++;
+ }
+ }
+ mutex_unlock(af9013_i2c_gate_mutex);
+ if (success) {
+ break;
+ }
+ schedule();
+ }
+ dbg(%s: %d (%d), __func__, af9013_i2c_gate_ctrl_usecnt, fe-dvb-num);
+ return 0;
+}
+
+static int af9013_i2c_gate_dec_use_count(struct dvb_frontend *fe, int gate_op)
+{
+ if (mutex_lock_interruptible(af9013_i2c_gate_mutex) != 0) {
+ return -EAGAIN;
+ }
+ if (gate_op != GATE_ENABLE) {
+ af9013_i2c_gate_ctrl_usecnt--;
+ }
+ if (af9013_i2c_gate_ctrl_usecnt == 0) {
+ locked_fe = 0;
+ }
+ mutex_unlock(af9013_i2c_gate_mutex);
+ dbg(%s: %d (%d), __func__, af9013_i2c_gate_ctrl_usecnt, fe-dvb-num);
+ return 0;
+}
+
struct af9013_state {
struct i2c_adapter *i2c;
struct dvb_frontend fe;
@@ -44,7 +92,6 @@ struct af9013_state {
unsigned long set_frontend_jiffies;
unsigned long read_status_jiffies;
bool first_tune;
- bool i2c_gate_state;
unsigned int statistics_step:3;
struct delayed_work statistics_work;
};
@@ -54,6 +101,7 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
const u8 *val, int len)
{
int ret;
+ struct dvb_frontend *fe = (priv-fe);
u8 buf[3+len];
struct i2c_msg msg[1] = {
{
@@ -69,6 +117,10 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
buf[2] = mbox;
memcpy(buf[3], val, len);
+ if (af9013_i2c_gate_inc_use_count(fe, GATE_NOOP) != 0) {
+ return -EAGAIN;
+ }
+ dbg(%s: I2C write reg:%04x (%d), __func__, reg, fe-dvb-num);
ret = i2c_transfer(priv-i2c, msg, 1);
if (ret == 1) {
ret = 0;
@@ -76,6 +128,10 @@ static int af9013_wr_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
warn(i2c wr failed=%d reg=%04x len=%d, ret, reg, len);
ret = -EREMOTEIO;
}
+
+ if (af9013_i2c_gate_dec_use_count(fe, GATE_NOOP) != 0) {
+ return -EAGAIN;
+ }
return ret;
}
@@ -84,6 +140,7 @@ static int af9013_rd_regs_i2c(struct af9013_state *priv, u8
mbox, u16 reg,
u8 *val, int len)
{
int ret;
+ struct dvb_frontend *fe = (priv-fe);
u8 buf[3];
struct i2c_msg msg[2] = {
{
@@ -103,6 +160,10 @@ static int af9013_rd_regs_i2c(struct af9013_state *priv,
u8 mbox, u16 reg,
buf[1] = (reg 0) 0xff;
buf[2] = mbox;
+ if (af9013_i2c_gate_inc_use_count(fe, GATE_NOOP) != 0) {
+ return -EAGAIN;
+ }
+ dbg(%s: I2C read reg:%04x (%d), __func__, reg, priv-fe.dvb-num);
ret = i2c_transfer(priv-i2c, msg, 2);
if (ret == 2) {
ret = 0;
@@ -110,6 +171,9 @@ static int af9013_rd_regs_i2c(struct
[PATCH] anysee: fix CI init
No more error that error seen when device is plugged: dvb_ca adapter 0: Invalid PC card inserted :( Signed-off-by: Antti Palosaari cr...@iki.fi --- drivers/media/dvb/dvb-usb/anysee.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/anysee.c b/drivers/media/dvb/dvb-usb/anysee.c index 7b77c7b..fdee856 100644 --- a/drivers/media/dvb/dvb-usb/anysee.c +++ b/drivers/media/dvb/dvb-usb/anysee.c @@ -1188,6 +1188,14 @@ static int anysee_ci_init(struct dvb_usb_device *d) if (ret) return ret; + ret = anysee_wr_reg_mask(d, REG_IOD, (0 2)|(0 1)|(0 0), 0x07); + if (ret) + return ret; + + ret = anysee_wr_reg_mask(d, REG_IOD, (1 2)|(1 1)|(1 0), 0x07); + if (ret) + return ret; + ret = dvb_ca_en50221_init(d-adapter[0].dvb_adap, state-ci, 0, 1); if (ret) return ret; -- 1.7.4.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] af9013: fix i2c failures for dual-tuner devices
On 01/20/2012 11:18 PM, Gordon Hecker wrote: This patch fixes the following error messages with a Terratec Cinergy T Stick Dual RC DVB-T device. af9013: i2c wr failed=-1 reg=d607 len=1 af9015: command failed:2 af9013: i2c rd failed=-1 reg=d607 len=1 af9015: command failed:1 It implements exclusive access to i2c for only one frontend at a time through a use-counter that is increased for each af9013_i2c_gate_ctrl-enable or i2c-read/write and decreased accordingly. The use-counter remains incremented after af9013_i2c_gate_ctrl-enable until the corresponding disable. Debug output was added. ToDo: * Replace frontend by adapter (the dual-tuner devices do actually provide two adapters with one frontend each) * move af9013_i2c_gate_mutex, locked_fe, af9013_i2c_gate_ctrl_usecnt to the usb device Again that same issue. But after af9013 rewrote those should not be very significant problem... If you looked, as I can guess, AF9015 code you can see callbacks lock that are for resolving same issue. Almost all callbacks are locked, but I left few rarely called callbacks without lock due to performance point of view. You can guess it causes always latency to wait other thread finish callback... I think you may resolve that just adding one or two callback lock more, likely for tuner init() and sleep(). I don't like that you are adding such code for the demod driver - problem is USB-bridge, its I2C adapter and firmware. Due to that such code should be in AF9015 driver. There has been originally two I2C adapters in af9015 but I removed those. And there is actually only one I2C adapter in AF9015. See these for more info about I2C bus connections: http://palosaari.fi/linux/v4l-dvb/controlling_tuner_af9015_dual_demod.txt http://palosaari.fi/linux/v4l-dvb/controlling_tuner.txt I think that piece of code is not very important and I dont like to see it in current af9013 driver. Do needed changes for af9015 instead. regards Antti -- http://palosaari.fi/ -- 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] it913x v1.23 use it913x_config.chip_ver to select firmware.
As recommended by Jason at ITE, the chip version should select firmware.
However, to continue to support IT9137 firmware with different configuration
the driver will use udev-descriptor.idVendor to select the difference
between IT9135 and IT9137.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/it913x.c | 19 +++
1 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/it913x.c
b/drivers/media/dvb/dvb-usb/it913x.c
index 654aa7c..59eb23c 100644
--- a/drivers/media/dvb/dvb-usb/it913x.c
+++ b/drivers/media/dvb/dvb-usb/it913x.c
@@ -388,19 +388,12 @@ static int ite_firmware_select(struct usb_device *udev,
{
int sw;
/* auto switch */
- if (le16_to_cpu(udev-descriptor.idProduct) ==
- USB_PID_ITETECH_IT9135)
- sw = IT9135_V1_FW;
- else if (le16_to_cpu(udev-descriptor.idProduct) ==
- USB_PID_ITETECH_IT9135_9005)
+ if (le16_to_cpu(udev-descriptor.idVendor) == USB_VID_KWORLD_2)
+ sw = IT9137_FW;
+ else if (it913x_config.chip_ver == 1)
sw = IT9135_V1_FW;
- else if (le16_to_cpu(udev-descriptor.idProduct) ==
- USB_PID_ITETECH_IT9135_9006) {
+ else
sw = IT9135_V2_FW;
- if (it913x_config.tuner_id_0 == 0)
- it913x_config.tuner_id_0 = IT9135_60;
- } else
- sw = IT9137_FW;
/* force switch */
if (dvb_usb_it913x_firmware != IT9135_AUTO)
@@ -416,6 +409,8 @@ static int ite_firmware_select(struct usb_device *udev,
it913x_config.firmware_ver = 1;
it913x_config.adc_x2 = 1;
props-firmware = fw_it9135_v2;
+ if (it913x_config.tuner_id_0 == 0)
+ it913x_config.tuner_id_0 = IT9135_60;
break;
case IT9137_FW:
default:
@@ -842,5 +837,5 @@ module_exit(it913x_module_exit);
MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com);
MODULE_DESCRIPTION(it913x USB 2 Driver);
-MODULE_VERSION(1.22);
+MODULE_VERSION(1.23);
MODULE_LICENSE(GPL);
--
1.7.8.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Import PCTV-80e Drivers from Devin Heitmueller's Repository
From: Patrick Dickey pdickeyb...@gmail.com This series of patches will import the drx39xxj(drx39xyj) drivers from Devin Heitmueller's HG Repository for the Pinnacle PCTV-80e USB Tuner. Patrick Dickey (2): import-pctv-80e-from-devin-heitmueller-hg-repository Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Patrick Dickey pdickeyb...@gmail.com import-pctv-80e-from-devin-heitmueller-hg-repository Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Patrick Dickey pdickeyb...@gmail.com Documentation/video4linux/CARDLIST.em28xx |1 + .../staging/media/dvb/frontends/drx39xyj/Kconfig |7 + .../staging/media/dvb/frontends/drx39xyj/Makefile |3 + .../media/dvb/frontends/drx39xyj/bsp_host.h| 80 + .../staging/media/dvb/frontends/drx39xyj/bsp_i2c.h | 217 + .../media/dvb/frontends/drx39xyj/bsp_tuner.h | 215 + .../media/dvb/frontends/drx39xyj/bsp_types.h | 229 + .../media/dvb/frontends/drx39xyj/drx39xxj.c| 457 + .../media/dvb/frontends/drx39xyj/drx39xxj.h| 40 + .../media/dvb/frontends/drx39xyj/drx39xxj_dummy.c | 134 + .../media/dvb/frontends/drx39xyj/drx_dap_fasi.c| 675 + .../media/dvb/frontends/drx39xyj/drx_dap_fasi.h| 268 + .../media/dvb/frontends/drx39xyj/drx_driver.c | 1600 ++ .../media/dvb/frontends/drx39xyj/drx_driver.h | 2588 +++ .../dvb/frontends/drx39xyj/drx_driver_version.h| 82 + .../staging/media/dvb/frontends/drx39xyj/drxj.c|16758 .../staging/media/dvb/frontends/drx39xyj/drxj.h| 730 + .../media/dvb/frontends/drx39xyj/drxj_map.h|15359 ++ .../staging/media/dvb/frontends/drx39xyj/drxj_mc.h | 3939 + .../media/dvb/frontends/drx39xyj/drxj_mc_vsb.h | 744 + .../media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h | 1437 ++ .../media/dvb/frontends/drx39xyj/drxj_options.h| 65 + 22 files changed, 45628 insertions(+), 0 deletions(-) create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Kconfig create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/Makefile create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_host.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_i2c.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_tuner.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/bsp_types.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx39xxj_dummy.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_dap_fasi.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drx_driver_version.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.c create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_map.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsb.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_mc_vsbqam.h create mode 100644 drivers/staging/media/dvb/frontends/drx39xyj/drxj_options.h -- 1.7.7.6 -- 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
