[RFC PATCH v9 3/6] media: videobuf2: Separate vb2_poll()

[Junghak Sung]

Separate vb2_poll() into core and v4l2 part.

Signed-off-by: Junghak Sung 
Signed-off-by: Geunyoung Kim 
Acked-by: Seung-Woo Kim 
Acked-by: Inki Dae 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c |   80 +++---
 1 file changed, 52 insertions(+), 28 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index d254452..0ca9f23 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -745,7 +745,7 @@ void vb2_queue_release(struct vb2_queue *q)
 EXPORT_SYMBOL_GPL(vb2_queue_release);
 
 /**
- * vb2_poll() - implements poll userspace operation
+ * vb2_core_poll() - implements poll userspace operation
  * @q: videobuf2 queue
  * @file:  file argument passed to the poll file operation handler
  * @wait:  wait argument passed to the poll file operation handler
@@ -757,33 +757,20 @@ EXPORT_SYMBOL_GPL(vb2_queue_release);
  * For OUTPUT queues, if a buffer is ready to be dequeued, the file descriptor
  * will be reported as available for writing.
  *
- * If the driver uses struct v4l2_fh, then vb2_poll() will also check for any
- * pending events.
- *
  * The return values from this function are intended to be directly returned
  * from poll handler in driver.
  */
-unsigned int vb2_poll(struct vb2_queue *q, struct file *file, poll_table *wait)
+unsigned int vb2_core_poll(struct vb2_queue *q, struct file *file,
+   poll_table *wait)
 {
-   struct video_device *vfd = video_devdata(file);
unsigned long req_events = poll_requested_events(wait);
struct vb2_buffer *vb = NULL;
-   unsigned int res = 0;
unsigned long flags;
 
-   if (test_bit(V4L2_FL_USES_V4L2_FH, >flags)) {
-   struct v4l2_fh *fh = file->private_data;
-
-   if (v4l2_event_pending(fh))
-   res = POLLPRI;
-   else if (req_events & POLLPRI)
-   poll_wait(file, >wait, wait);
-   }
-
if (!q->is_output && !(req_events & (POLLIN | POLLRDNORM)))
-   return res;
+   return 0;
if (q->is_output && !(req_events & (POLLOUT | POLLWRNORM)))
-   return res;
+   return 0;
 
/*
 * Start file I/O emulator only if streaming API has not been used yet.
@@ -792,16 +779,16 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
*file, poll_table *wait)
if (!q->is_output && (q->io_modes & VB2_READ) &&
(req_events & (POLLIN | POLLRDNORM))) {
if (__vb2_init_fileio(q, 1))
-   return res | POLLERR;
+   return POLLERR;
}
if (q->is_output && (q->io_modes & VB2_WRITE) &&
(req_events & (POLLOUT | POLLWRNORM))) {
if (__vb2_init_fileio(q, 0))
-   return res | POLLERR;
+   return POLLERR;
/*
 * Write to OUTPUT queue can be done immediately.
 */
-   return res | POLLOUT | POLLWRNORM;
+   return POLLOUT | POLLWRNORM;
}
}
 
@@ -810,21 +797,21 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
*file, poll_table *wait)
 * error flag is set.
 */
if (!vb2_is_streaming(q) || q->error)
-   return res | POLLERR;
+   return POLLERR;
/*
 * For compatibility with vb1: if QBUF hasn't been called yet, then
 * return POLLERR as well. This only affects capture queues, output
 * queues will always initialize waiting_for_buffers to false.
 */
if (q->waiting_for_buffers)
-   return res | POLLERR;
+   return POLLERR;
 
/*
 * For output streams you can write as long as there are fewer buffers
 * queued than there are buffers available.
 */
if (q->is_output && q->queued_count < q->num_buffers)
-   return res | POLLOUT | POLLWRNORM;
+   return POLLOUT | POLLWRNORM;
 
if (list_empty(>done_list)) {
/*
@@ -832,7 +819,7 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
*file, poll_table *wait)
 * return immediately. DQBUF will return -EPIPE.
 */
if (q->last_buffer_dequeued)
-   return res | POLLIN | POLLRDNORM;
+   return POLLIN | POLLRDNORM;
 
poll_wait(file, >done_wq, wait);
}
@@ -849,10 +836,47 @@ unsigned int vb2_poll(struct vb2_queue *q, struct file 
*file, poll_table *wait)
if (vb && (vb->state == VB2_BUF_STATE_DONE
  

[RFC PATCH v9 2/6] media: videobuf2: Add set_timestamp to struct vb2_queue

[Junghak Sung]

Add set_timestamp to struct vb2_queue as a flag set if vb2-core should
set timestamps.

Signed-off-by: Junghak Sung 
Signed-off-by: Geunyoung Kim 
Acked-by: Seung-Woo Kim 
Acked-by: Inki Dae 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c |   20 +++-
 include/media/videobuf2-core.h   |2 ++
 2 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 93e16375..d254452 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -118,10 +118,8 @@ static int __set_timestamp(struct vb2_buffer *vb, const 
void *pb)
 * For output buffers copy the timestamp if needed,
 * and the timecode field and flag if needed.
 */
-   if ((q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK) ==
-   V4L2_BUF_FLAG_TIMESTAMP_COPY) {
+   if (q->set_timestamp)
vb->timestamp = timeval_to_ns(>timestamp);
-   }
vbuf->flags |= b->flags & V4L2_BUF_FLAG_TIMECODE;
if (b->flags & V4L2_BUF_FLAG_TIMECODE)
vbuf->timecode = b->timecode;
@@ -239,8 +237,7 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
 */
b->flags &= ~V4L2_BUFFER_MASK_FLAGS;
b->flags |= q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK;
-   if ((q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK) !=
-   V4L2_BUF_FLAG_TIMESTAMP_COPY) {
+   if (!q->set_timestamp) {
/*
 * For non-COPY timestamps, drop timestamp source bits
 * and obtain the timestamp source from the queue.
@@ -404,8 +401,7 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb,
 
/* Zero flags that the vb2 core handles */
vbuf->flags = b->flags & ~V4L2_BUFFER_MASK_FLAGS;
-   if ((vb->vb2_queue->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK) !=
-   V4L2_BUF_FLAG_TIMESTAMP_COPY || !V4L2_TYPE_IS_OUTPUT(b->type)) {
+   if (!vb->vb2_queue->set_timestamp || !V4L2_TYPE_IS_OUTPUT(b->type)) {
/*
 * Non-COPY timestamps and non-OUTPUT queues will get
 * their timestamp and timestamp source flags from the
@@ -723,6 +719,8 @@ int vb2_queue_init(struct vb2_queue *q)
q->buf_ops = _buf_ops;
q->is_multiplanar = V4L2_TYPE_IS_MULTIPLANAR(q->type);
q->is_output = V4L2_TYPE_IS_OUTPUT(q->type);
+   q->set_timestamp = (q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK)
+   == V4L2_BUF_FLAG_TIMESTAMP_COPY;
 
return vb2_core_queue_init(q);
 }
@@ -1080,9 +1078,7 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, 
char __user *data, size_
 * should set timestamps if V4L2_BUF_FLAG_TIMESTAMP_COPY is set. Nobody
 * else is able to provide this information with the write() operation.
 */
-   bool set_timestamp = !read &&
-   (q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK) ==
-   V4L2_BUF_FLAG_TIMESTAMP_COPY;
+   bool set_timestamp = !read && q->set_timestamp;
int ret, index;
 
dprintk(3, "mode %s, offset %ld, count %zd, %sblocking\n",
@@ -1271,9 +1267,7 @@ static int vb2_thread(void *data)
 
if (q->is_output) {
prequeue = q->num_buffers;
-   set_timestamp =
-   (q->timestamp_flags & V4L2_BUF_FLAG_TIMESTAMP_MASK) ==
-   V4L2_BUF_FLAG_TIMESTAMP_COPY;
+   set_timestamp = q->set_timestamp;
}
 
set_freezable();
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 6404f81..b73a28a 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -431,6 +431,7 @@ struct vb2_buf_ops {
  * called since poll() needs to return POLLERR in that situation.
  * @is_multiplanar: set if buffer type is multiplanar
  * @is_output: set if buffer type is output
+ * @copy_timestamp: set if vb2-core should set timestamps
  * @last_buffer_dequeued: used in poll() and DQBUF to immediately return if the
  * last decoded buffer was already dequeued. Set for capture queues
  * when a buffer with the V4L2_BUF_FLAG_LAST is dequeued.
@@ -480,6 +481,7 @@ struct vb2_queue {
unsigned intwaiting_for_buffers:1;
unsigned intis_multiplanar:1;
unsigned intis_output:1;
+   unsigned intset_timestamp:1;
unsigned intlast_buffer_dequeued:1;
 
struct vb2_fileio_data  *fileio;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to 

[RFC PATCH v9 6/6] media: videobuf2: Move vb2_fileio_data and vb2_thread to core part

[Junghak Sung]

Move things related with vb2 file I/O and vb2_thread without doing any
functional changes. After that, videobuf2-internal.h is removed because
it is not necessary any more.

Signed-off-by: Junghak Sung 
Signed-off-by: Geunyoung Kim 
Acked-by: Seung-Woo Kim 
Acked-by: Inki Dae 
---
 drivers/media/v4l2-core/videobuf2-core.c |  777 +-
 drivers/media/v4l2-core/videobuf2-internal.h |  161 --
 drivers/media/v4l2-core/videobuf2-v4l2.c |  630 +
 include/media/videobuf2-core.h   |   43 ++
 include/media/videobuf2-v4l2.h   |   38 +-
 5 files changed, 824 insertions(+), 825 deletions(-)
 delete mode 100644 drivers/media/v4l2-core/videobuf2-internal.h

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 33bdd81..f62c548 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -28,11 +28,155 @@
 
 #include 
 
-#include "videobuf2-internal.h"
+static int debug;
+module_param(debug, int, 0644);
 
-int vb2_debug;
-EXPORT_SYMBOL_GPL(vb2_debug);
-module_param_named(debug, vb2_debug, int, 0644);
+#define dprintk(level, fmt, arg...)  \
+   do {  \
+   if (debug >= level)   \
+   pr_info("vb2-core: %s: " fmt, __func__, ## arg); \
+   } while (0)
+
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+
+/*
+ * If advanced debugging is on, then count how often each op is called
+ * successfully, which can either be per-buffer or per-queue.
+ *
+ * This makes it easy to check that the 'init' and 'cleanup'
+ * (and variations thereof) stay balanced.
+ */
+
+#define log_memop(vb, op)  \
+   dprintk(2, "call_memop(%p, %d, %s)%s\n",\
+   (vb)->vb2_queue, (vb)->index, #op,  \
+   (vb)->vb2_queue->mem_ops->op ? "" : " (nop)")
+
+#define call_memop(vb, op, args...)\
+({ \
+   struct vb2_queue *_q = (vb)->vb2_queue; \
+   int err;\
+   \
+   log_memop(vb, op);  \
+   err = _q->mem_ops->op ? _q->mem_ops->op(args) : 0;  \
+   if (!err)   \
+   (vb)->cnt_mem_ ## op++; \
+   err;\
+})
+
+#define call_ptr_memop(vb, op, args...)
\
+({ \
+   struct vb2_queue *_q = (vb)->vb2_queue; \
+   void *ptr;  \
+   \
+   log_memop(vb, op);  \
+   ptr = _q->mem_ops->op ? _q->mem_ops->op(args) : NULL;   \
+   if (!IS_ERR_OR_NULL(ptr))   \
+   (vb)->cnt_mem_ ## op++; \
+   ptr;\
+})
+
+#define call_void_memop(vb, op, args...)   \
+({ \
+   struct vb2_queue *_q = (vb)->vb2_queue; \
+   \
+   log_memop(vb, op);  \
+   if (_q->mem_ops->op)\
+   _q->mem_ops->op(args);  \
+   (vb)->cnt_mem_ ## op++; \
+})
+
+#define log_qop(q, op) \
+   dprintk(2, "call_qop(%p, %s)%s\n", q, #op,  \
+   (q)->ops->op ? "" : " (nop)")
+
+#define call_qop(q, op, args...)   \
+({ \
+   int err;\
+   \
+   log_qop(q, op); \
+   err = (q)->ops->op ? (q)->ops->op(args) : 0;\
+   if (!err)   \
+  

[RFC PATCH v9] Refactoring Videobuf2 for common use

[Junghak Sung]

Hello everybody,
This is the 9th round for refactoring Videobuf2(a.k.a VB2).

The purpose of this patch series is to separate existing VB2 framework
into core part and V4L2 specific part. So that not only V4L2 but also other
frameworks can use them to manage buffer and utilize queue.

Why do we try to make the VB2 framework to be common?

As you may know, current DVB framework uses ringbuffer mechanism to demux
MPEG-2 TS data and pass it to userspace. However, this mechanism requires
extra memory copy because DVB framework provides only read() system call for
application - read() system call copies the kernel data to user-space buffer.
So if we can use VB2 framework which supports streaming I/O and buffer
sharing mechanism, then we could enhance existing DVB framework by removing
the extra memory copy - with VB2 framework, application can access the kernel
data directly through mmap system call.

We have a plan for this work as follows:
1. Separate existing VB2 framework into three parts - VB2 core, VB2 v4l2.
   Of course, this change will not affect other v4l2-based
   device drivers. This patch series corresponds to this step.

2. Add and implement new APIs for DVB streaming I/O.
   We can remove unnecessary memory copy between kernel-space and user-space
   by using these new APIs. However, we leaves legacy interfaces as-is
   for backward compatibility.

This patch series is the first step for it.

Changes since v8
1. Use u64 for timestamp instead of struct timespec
struct timespec in vb2-core is replaced with u64 containing nanoseconds,
because struct timespec is still not safe from the y2038 problem.
Of course, ktime_get_ns() is also used instead of ktime_get_ts().

Changes since v7
1. Use struct timespec for timestamp
struct timespec is used for timestamp in videobuf2 core and vb2 drivers call
ktime_get_ns() directly instead of calling v4l2_set_timestamp() to handling
y2038 problem, which is pointed by Hans and Sakari.

Changes since v6
1. Based on v6
Patch series v6 was accepted (but, not merged yet). So, this series v7 is
based on v6.

2. Fix a warning on fimc-lite.c
In patch series v6, a warning is reported by kbuild robot. So, this warning
is fixed.

3. Move things related with vb2_thread to core part
In order to move vb2_thread to vb2-core, these changes below would precede it.
 - timestamp of vb2_v4l2_buffer is moved to vb2_buffer for common use.
 - A flag - which is for checking if vb2-core should set timestamps or not - is
  added as a member of vb2_queue.
 - Replace v4l2-stuffs with common things in vb2_fileio_data and vb2_thread.

Older versions than v6 have been merged to media_tree. So, I snip the change log
of those versions, but you can find them at below links.

[1] RFC PATCH v1 - http://www.spinics.net/lists/linux-media/msg90688.html
[2] RFC PATCH v2 - http://www.spinics.net/lists/linux-media/msg92130.html
[3] RFC PATCH v3 - http://www.spinics.net/lists/linux-media/msg92953.html
[4] RFC PATCH v4 - http://www.spinics.net/lists/linux-media/msg93421.html
[5] RFC PATCH v5 - http://www.spinics.net/lists/linux-media/msg93810.html
[6] RFC PATCH v6 - http://www.spinics.net/lists/linux-media/msg94112.html
[7] RFC PATCH v7 - http://www.spinics.net/lists/linux-media/msg94283.html


This patch series is based on top version of media_tree.git [8].
I have applied this patches to my own git [9] and tested this patch series
with v4l2-compliance util on ubuntu PC(Intel i7-3770) for x86 system
and odroid-xu3(exynos5422) for ARM.

[8] media_tree.git - http://git.linuxtv.org/cgit.cgi/media_tree.git master
[9] jsung/dvb-vb2.git - http://git.linuxtv.org/cgit.cgi/jsung/dvb-vb2.git 
vb2-refactoring

Any suggestions and comments are welcome.

Regards,
Junghak

Junghak Sung (6):
  media: videobuf2: Move timestamp to vb2_buffer
  media: videobuf2: Add set_timestamp to struct vb2_queue
  media: videobuf2: Separate vb2_poll()
  media: videobuf2: last_buffer_queued is set at fill_v4l2_buffer()
  media: videobuf2: Refactor vb2_fileio_data and vb2_thread
  media: videobuf2: Move vb2_fileio_data and vb2_thread to core part

 drivers/input/touchscreen/sur40.c  |2 +-
 drivers/media/dvb-frontends/rtl2832_sdr.c  |2 +-
 drivers/media/pci/cobalt/cobalt-irq.c  |2 +-
 drivers/media/pci/cx23885/cx23885-core.c   |2 +-
 drivers/media/pci/cx23885/cx23885-video.c  |2 +-
 drivers/media/pci/cx25821/cx25821-video.c  |2 +-
 drivers/media/pci/cx88/cx88-core.c |2 +-
 drivers/media/pci/dt3155/dt3155.c  |2 +-
 drivers/media/pci/netup_unidvb/netup_unidvb_core.c |2 +-
 drivers/media/pci/saa7134/saa7134-core.c   |2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c |4 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2.c |2 +-
 drivers/media/pci/sta2x11/sta2x11_vip.c|2 +-
 drivers/media/pci/tw68/tw68-video.c|2 +-
 

[RFC PATCH v9 1/6] media: videobuf2: Move timestamp to vb2_buffer

[Junghak Sung]

Move timestamp from struct vb2_v4l2_buffer to struct vb2_buffer
for common use, and change its type to u64 in order to handling
y2038 problem. This patch also includes all device drivers' changes related to
this restructuring.

Signed-off-by: Junghak Sung 
Signed-off-by: Geunyoung Kim 
Acked-by: Seung-Woo Kim 
Acked-by: Inki Dae 
---
 drivers/input/touchscreen/sur40.c  |2 +-
 drivers/media/dvb-frontends/rtl2832_sdr.c  |2 +-
 drivers/media/pci/cobalt/cobalt-irq.c  |2 +-
 drivers/media/pci/cx23885/cx23885-core.c   |2 +-
 drivers/media/pci/cx23885/cx23885-video.c  |2 +-
 drivers/media/pci/cx25821/cx25821-video.c  |2 +-
 drivers/media/pci/cx88/cx88-core.c |2 +-
 drivers/media/pci/dt3155/dt3155.c  |2 +-
 drivers/media/pci/netup_unidvb/netup_unidvb_core.c |2 +-
 drivers/media/pci/saa7134/saa7134-core.c   |2 +-
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c |4 ++--
 drivers/media/pci/solo6x10/solo6x10-v4l2.c |2 +-
 drivers/media/pci/sta2x11/sta2x11_vip.c|2 +-
 drivers/media/pci/tw68/tw68-video.c|2 +-
 drivers/media/platform/am437x/am437x-vpfe.c|2 +-
 drivers/media/platform/blackfin/bfin_capture.c |2 +-
 drivers/media/platform/coda/coda-bit.c |6 +++---
 drivers/media/platform/coda/coda.h |2 +-
 drivers/media/platform/davinci/vpbe_display.c  |2 +-
 drivers/media/platform/davinci/vpif_capture.c  |2 +-
 drivers/media/platform/davinci/vpif_display.c  |6 +++---
 drivers/media/platform/exynos-gsc/gsc-m2m.c|4 ++--
 drivers/media/platform/exynos4-is/fimc-capture.c   |2 +-
 drivers/media/platform/exynos4-is/fimc-isp-video.c |2 +-
 drivers/media/platform/exynos4-is/fimc-lite.c  |2 +-
 drivers/media/platform/exynos4-is/fimc-m2m.c   |2 +-
 drivers/media/platform/m2m-deinterlace.c   |2 +-
 drivers/media/platform/marvell-ccic/mcam-core.c|2 +-
 drivers/media/platform/mx2_emmaprp.c   |2 +-
 drivers/media/platform/omap3isp/ispvideo.c |2 +-
 drivers/media/platform/rcar_jpu.c  |2 +-
 drivers/media/platform/s3c-camif/camif-capture.c   |2 +-
 drivers/media/platform/s5p-g2d/g2d.c   |2 +-
 drivers/media/platform/s5p-jpeg/jpeg-core.c|4 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc.c   |4 ++--
 drivers/media/platform/sh_veu.c|2 +-
 drivers/media/platform/sh_vou.c|2 +-
 drivers/media/platform/soc_camera/atmel-isi.c  |2 +-
 drivers/media/platform/soc_camera/mx2_camera.c |2 +-
 drivers/media/platform/soc_camera/mx3_camera.c |2 +-
 drivers/media/platform/soc_camera/rcar_vin.c   |2 +-
 .../platform/soc_camera/sh_mobile_ceu_camera.c |2 +-
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c  |4 ++--
 drivers/media/platform/ti-vpe/vpe.c|2 +-
 drivers/media/platform/vim2m.c |2 +-
 drivers/media/platform/vivid/vivid-kthread-cap.c   |7 ---
 drivers/media/platform/vivid/vivid-kthread-out.c   |   10 ++
 drivers/media/platform/vivid/vivid-sdr-cap.c   |5 +++--
 drivers/media/platform/vivid/vivid-vbi-cap.c   |   10 ++
 drivers/media/platform/vsp1/vsp1_video.c   |2 +-
 drivers/media/platform/xilinx/xilinx-dma.c |2 +-
 drivers/media/usb/airspy/airspy.c  |2 +-
 drivers/media/usb/au0828/au0828-video.c|2 +-
 drivers/media/usb/em28xx/em28xx-video.c|2 +-
 drivers/media/usb/go7007/go7007-driver.c   |2 +-
 drivers/media/usb/hackrf/hackrf.c  |4 ++--
 drivers/media/usb/pwc/pwc-if.c |3 +--
 drivers/media/usb/s2255/s2255drv.c |2 +-
 drivers/media/usb/stk1160/stk1160-video.c  |2 +-
 drivers/media/usb/usbtv/usbtv-video.c  |2 +-
 drivers/media/usb/uvc/uvc_video.c  |   15 +--
 drivers/media/v4l2-core/videobuf2-v4l2.c   |   10 +-
 drivers/staging/media/davinci_vpfe/vpfe_video.c|2 +-
 drivers/staging/media/omap4iss/iss_video.c |2 +-
 drivers/usb/gadget/function/uvc_queue.c|2 +-
 include/media/videobuf2-core.h |2 ++
 include/media/videobuf2-v4l2.h |2 --
 include/trace/events/v4l2.h|4 ++--
 include/trace/events/vb2.h |7 +--
 69 files changed, 107 insertions(+), 104 deletions(-)

diff --git a/drivers/input/touchscreen/sur40.c 
b/drivers/input/touchscreen/sur40.c
index d214f22..1a2eeaf 100644
--- a/drivers/input/touchscreen/sur40.c
+++ 

[RFC PATCH v9 4/6] media: videobuf2: last_buffer_queued is set at fill_v4l2_buffer()

[Junghak Sung]

The location in which last_buffer_queued is set is moved to fill_v4l2_buffer().
So, __vb2_perform_fileio() can use vb2_core_dqbuf() instead of
vb2_internal_dqbuf().

Signed-off-by: Junghak Sung 
Signed-off-by: Geunyoung Kim 
Acked-by: Seung-Woo Kim 
Acked-by: Inki Dae 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index 0ca9f23..b0293df 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -270,6 +270,11 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, void 
*pb)
if (vb2_buffer_in_use(q, vb))
b->flags |= V4L2_BUF_FLAG_MAPPED;
 
+   if (!q->is_output &&
+   b->flags & V4L2_BUF_FLAG_DONE &&
+   b->flags & V4L2_BUF_FLAG_LAST)
+   q->last_buffer_dequeued = true;
+
return 0;
 }
 
@@ -579,10 +584,6 @@ static int vb2_internal_dqbuf(struct vb2_queue *q, struct 
v4l2_buffer *b,
 
ret = vb2_core_dqbuf(q, b, nonblocking);
 
-   if (!ret && !q->is_output &&
-   b->flags & V4L2_BUF_FLAG_LAST)
-   q->last_buffer_dequeued = true;
-
return ret;
 }
 
-- 
1.7.9.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

[RFC PATCH v9 5/6] media: videobuf2: Refactor vb2_fileio_data and vb2_thread

[Junghak Sung]

Replace v4l2-stuffs with common things in struct vb2_fileio_data and
vb2_thread().

Signed-off-by: Junghak Sung 
Signed-off-by: Geunyoung Kim 
Acked-by: Seung-Woo Kim 
Acked-by: Inki Dae 
---
 drivers/media/v4l2-core/videobuf2-v4l2.c |  104 ++
 1 file changed, 49 insertions(+), 55 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-v4l2.c 
b/drivers/media/v4l2-core/videobuf2-v4l2.c
index b0293df..f806ef4 100644
--- a/drivers/media/v4l2-core/videobuf2-v4l2.c
+++ b/drivers/media/v4l2-core/videobuf2-v4l2.c
@@ -920,9 +920,10 @@ struct vb2_fileio_buf {
  * or write function.
  */
 struct vb2_fileio_data {
-   struct v4l2_requestbuffers req;
-   struct v4l2_plane p;
-   struct v4l2_buffer b;
+   unsigned int count;
+   unsigned int type;
+   unsigned int memory;
+   struct vb2_buffer *b;
struct vb2_fileio_buf bufs[VB2_MAX_FRAME];
unsigned int cur_index;
unsigned int initial_index;
@@ -975,6 +976,10 @@ static int __vb2_init_fileio(struct vb2_queue *q, int read)
if (fileio == NULL)
return -ENOMEM;
 
+   fileio->b = kzalloc(q->buf_struct_size, GFP_KERNEL);
+   if (fileio->b == NULL)
+   return -ENOMEM;
+
fileio->read_once = q->fileio_read_once;
fileio->write_immediately = q->fileio_write_immediately;
 
@@ -982,11 +987,11 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read)
 * Request buffers and use MMAP type to force driver
 * to allocate buffers by itself.
 */
-   fileio->req.count = count;
-   fileio->req.memory = VB2_MEMORY_MMAP;
-   fileio->req.type = q->type;
+   fileio->count = count;
+   fileio->memory = VB2_MEMORY_MMAP;
+   fileio->type = q->type;
q->fileio = fileio;
-   ret = vb2_core_reqbufs(q, fileio->req.memory, >req.count);
+   ret = vb2_core_reqbufs(q, fileio->memory, >count);
if (ret)
goto err_kfree;
 
@@ -1015,24 +1020,17 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read)
 * Read mode requires pre queuing of all buffers.
 */
if (read) {
-   bool is_multiplanar = q->is_multiplanar;
-
/*
 * Queue all buffers.
 */
for (i = 0; i < q->num_buffers; i++) {
-   struct v4l2_buffer *b = >b;
+   struct vb2_buffer *b = fileio->b;
 
-   memset(b, 0, sizeof(*b));
+   memset(b, 0, q->buf_struct_size);
b->type = q->type;
-   if (is_multiplanar) {
-   memset(>p, 0, sizeof(fileio->p));
-   b->m.planes = >p;
-   b->length = 1;
-   }
b->memory = q->memory;
b->index = i;
-   ret = vb2_internal_qbuf(q, b);
+   ret = vb2_core_qbuf(q, i, b);
if (ret)
goto err_reqbufs;
fileio->bufs[i].queued = 1;
@@ -1055,8 +1053,8 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read)
return ret;
 
 err_reqbufs:
-   fileio->req.count = 0;
-   vb2_core_reqbufs(q, fileio->req.memory, >req.count);
+   fileio->count = 0;
+   vb2_core_reqbufs(q, fileio->memory, >count);
 
 err_kfree:
q->fileio = NULL;
@@ -1075,8 +1073,9 @@ static int __vb2_cleanup_fileio(struct vb2_queue *q)
if (fileio) {
vb2_core_streamoff(q, q->type);
q->fileio = NULL;
-   fileio->req.count = 0;
-   vb2_reqbufs(q, >req);
+   fileio->count = 0;
+   vb2_core_reqbufs(q, fileio->memory, >count);
+   kfree(fileio->b);
kfree(fileio);
dprintk(3, "file io emulator closed\n");
}
@@ -1129,24 +1128,21 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, 
char __user *data, size_
 */
index = fileio->cur_index;
if (index >= q->num_buffers) {
+   struct vb2_buffer *b = fileio->b;
+
/*
 * Call vb2_dqbuf to get buffer back.
 */
-   memset(>b, 0, sizeof(fileio->b));
-   fileio->b.type = q->type;
-   fileio->b.memory = q->memory;
-   if (is_multiplanar) {
-   memset(>p, 0, sizeof(fileio->p));
-   fileio->b.m.planes = >p;
-   fileio->b.length = 1;
-   }
-   ret = vb2_internal_dqbuf(q, >b, nonblock);
+   memset(b, 0, q->buf_struct_size);
+   b->type = q->type;
+   b->memory = q->memory;
+   ret = vb2_core_dqbuf(q, 

[GIT PULL for v4.4-rc1] media updates

[Mauro Carvalho Chehab]

Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.4-1

For the media updates, including:
- Lots of improvements at the kABI documentation;
- Split of Videobuf2 into a common part and a V4L2 specific one;
- Split of the VB2 tracing events into a separate header file;
- s5p-mfc got support for Exynos 5433;
- v4l2 fixes for 64-bits alignment when running 32 bits userspace on ARM;
- Added support for SDR radio transmitter at core, vivid and hackrf drivers;
- Some y2038 fixups;
- Some improvements at V4L2 colorspace support;
- saa7164 converted to use the V4L2 core control framework;
- several new boards additions, cleanups and fixups.

Thanks!
Mauro

PS.: There are two patches for scripts/kernel-doc that are needed by the
documentation patches on Media. Jon is OK on merging those via my tree.

---

The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:

  Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
tags/media/v4.4-1

for you to fetch changes up to 79f5b6ae960d380c829fb67d5dadcd1d025d2775:

  [media] c8sectpfe: Remove select on CONFIG_FW_LOADER_USER_HELPER_FALLBACK 
(2015-10-20 16:02:41 -0200)


media updates for v4.4-rc1


Alexander Kuleshov (1):
  [media] media/pci/cobalt: Use %*ph to print small buffers

Andrew Milkovich (1):
  [media] Staging: media: bcm2048: warnings for uninitialized variables 
fixed

Andrzej Hajda (6):
  [media] v4l2-compat-ioctl32: fix alignment for ARM64
  [media] cx231xx: fix handling cx231xx_read_i2c_data result
  [media] staging: media: omap4iss: fix handling platform_get_irq result
  [media] media: am437x-vpfe: fix handling platform_get_irq result
  [media] s5p-mfc: end-of-stream handling for newer encoders
  [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder 
capture queue

Andrzej Pietrasiewicz (2):
  [media] s5p-jpeg: add support for 5433
  [media] MAINTAINERS: add exynos jpeg codec maintainers

Antonio Ospite (1):
  [media] media/v4l2-ctrls: fix setting autocluster to manual with 
VIDIOC_S_CTRL

Antti Palosaari (15):
  [media] vivid: SDR cap: add control for FM deviation
  [media] vivid: sdr cap: few enhancements
  [media] v4l2: rename V4L2_TUNER_ADC to V4L2_TUNER_SDR
  [media] v4l2: add RF gain control
  [media] DocBook: document tuner RF gain control
  [media] v4l2: add support for SDR transmitter
  [media] DocBook: document SDR transmitter
  [media] v4l: add type field to v4l2_modulator struct
  [media] DocBook: add modulator type field
  [media] hackrf: add control for RF amplifier
  [media] hackrf: switch to single function which configures everything
  [media] hackrf: add support for transmitter
  [media] hackrf: do not set human readable name for formats
  [media] DocBook: add SDR specific info to G_TUNER / S_TUNER
  [media] DocBook: add SDR specific info to G_MODULATOR / S_MODULATOR

Arnd Bergmann (2):
  [media] exynos4-is: use monotonic timestamps as advertized
  [media] use v4l2_get_timestamp where possible

Benoit Parrot (1):
  [media] media: v4l2-ctrls: Fix 64bit support in get_ctrl()

Darek Zielski (1):
  [media] saa7134: add Leadtek Winfast TV2100 FM card support

Erik Andresen (1):
  [media] Add Terratec H7 Revision 4 to DVBSky driver

Ezequiel Garcia (2):
  [media] vivid: Fix iteration in driver removal path
  [media] vivid: Add an option to configure the maximum number of devices

Fengguang Wu (1):
  [media] i2c: fix platform_no_drv_owner.cocci warnings

Geert Uytterhoeven (3):
  [media] rcar_vin: Remove obsolete r8a779x-vin platform_device_id entries
  [media] atmel-isi: Protect PM-only functions to kill warning
  [media] VIDEO_RENESAS_JPU should depend on HAS_DMA

Geliang Tang (1):
  [media] media: fix kernel-doc warnings in v4l2-dv-timings.h

Graham Eccleston (1):
  [media] Compro U650F support

Hans Verkuil (26):
  [media] v4l2-compat-ioctl32: replace pr_warn by pr_debug
  [media] vivid: use ARRAY_SIZE to calculate max control value
  [media] vivid: use Bradford method when converting Rec. 709 to NTSC 1953
  [media] videodev2.h: add support for the DCI-P3 colorspace
  [media] DocBook media: document the new DCI-P3 colorspace
  [media] vivid-tpg: support the DCI-P3 colorspace
  [media] vivid: add support for the DCI-P3 colorspace
  [media] videodev2.h: add SMPTE 2084 transfer function define
  [media] vivid-tpg: add support for SMPTE 2084 transfer function
  [media] vivid: add support for SMPTE 2084 transfer function
  [media] DocBook media: Document the SMPTE 2084 transfer function
  [media] vim2m: small cleanup: use 

Re: [PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

[Robin Murphy]

Hi Tomasz,

On 02/11/15 13:43, Tomasz Figa wrote:

I'd like to know what is the boundary mask and what hardware imposes
requirements like this. The cost here is not only over-allocating a
little, but making many, many buffers contiguously mappable on the
CPU, unmappable contiguously in IOMMU, which just defeats the purpose
of having an IOMMU, which I believe should be there for simple IP
blocks taking one DMA address to be able to view the buffer the same
way as the CPU.


The expectation with dma_map_sg() is that you're either going to be 
iterating over the buffer segments, handing off each address to the 
device to process one by one; or you have a scatter-gather-capable 
device, in which case you hand off the whole list at once. It's in the 
latter case where you have to make sure the list doesn't exceed the 
hardware limitations of that device. I believe the original concern was 
disk controllers (the introduction of dma_parms seems to originate from 
the linux-scsi list), but most scatter-gather engines are going to have 
some limit on how much they can handle per entry (IMO the dmaengine 
drivers are the easiest example to look at).


Segment boundaries are a little more arcane, but my assumption is that 
they relate to the kind of devices whose addressing is not flat but 
relative to some separate segment register (The "64-bit" mode of USB 
EHCI is one concrete example I can think of) - since you cannot 
realistically change the segment register while the device is in the 
middle of accessing a single buffer entry, that entry must not fall 
across a segment boundary or at some point the device's accesses are 
going to overflow the offset address bits and wrap around to bogus 
addresses at the bottom of the segment.


Now yes, it will be possible under _most_ circumstances to use an IOMMU 
to lay out a list of segments with page-aligned lengths within a single 
IOVA allocation whilst still meeting all the necessary constraints. It 
just needs some unavoidably complicated calculations - quite likely 
significantly more complex than my v5 version of map_sg() that tried to 
do that and merge segments but failed to take the initial alignment into 
account properly - since there are much simpler ways to enforce just the 
_necessary_ behaviour for the DMA API, I put the complicated stuff to 
one side for now to prevent it holding up getting the basic functional 
support in place.



Hmm, I thought the DMA API maps a (possibly) non-contiguous set of
memory pages into a contiguous block in device memory address space.
This would allow passing a dma mapped buffer to device dma using just
a device address and length.



Not at all. The streaming DMA API (dma_map_* and friends) has two 
responsibilities: performing any necessary cache maintenance to ensure the 
device will correctly see data from the CPU, and the CPU will correctly see 
data from the device; and working out an address for that buffer from the 
device's point of view to actually hand off to the hardware (which is perfectly 
well allowed to fail).


Agreed. The dma_map_*() API is not guaranteed to return a single
contiguous part of virtual address space for any given SG list.
However it was understood to be able to map buffers contiguously
mappable by the CPU into a single segment and users,
videobuf2-dma-contig in particular, relied on this.


I don't follow that - _any_ buffer made of page-sized chunks is going to 
be mappable contiguously by the CPU; it's clearly impossible for the 
streaming DMA API itself to offer such a guarantee, because it's 
entirely orthogonal to the presence or otherwise of an IOMMU.


Furthermore, I can't see any existing dma_map_sg implementation (between 
arm/64 and x86, at least), that _won't_ break that expectation under 
certain conditions (ranging from "relatively pathological" to "always"), 
so it still seems questionable to have a dependency on it.



Consider SWIOTLB's implementation - segments which already lie at physical 
addresses within the device's DMA mask just get passed through, while those 
that lie outside it get mapped into the bounce buffer, but still as individual 
allocations (arch code just handles cache maintenance on the resulting physical 
addresses and can apply any hard-wired DMA offset for the device concerned).


And this is fine for vb2-dma-contig, which was made for devices that
require buffers contiguous in its address space. Without IOMMU it will
allow only physically contiguous buffers and fails otherwise, which is
fine, because it's a hardware requirement.


If it depends on having contiguous-from-the-device's-view DMA buffers 
either way, that's a sign it should perhaps be using the coherent DMA 
API instead, which _does_ give such a guarantee. I'm well aware of the 
"but the noncacheable mappings make userspace access unacceptably slow!" 
issue many folks have with that, though, and don't particularly fancy 
going off on that tangent here.



IIUC, the change above breaks 

dvb_usb_cxusb triggers "DMA-API: device driver maps memory from stack" error

[John Barberio]

Attaching an August DVB-T210 usb stick to the system causes a "DMA-API: device 
driver maps memory from stack" error, and while the device registers and 
appears functional, no data is produced from the tuner.

Bus 001 Device 007: ID 0572:c688 Conexant Systems (Rockwell), Inc. Geniatech 
T230 DVB-T2 TV Stick

[ 1582.310802] i2c i2c-11: cxd2820r: i2c rd failed=-5 reg=10 len=1
[ 2352.832621] perf interrupt took too long (5005 > 5000), lowering 
kernel.perf_event_max_sample_rate to 25000
[ 3954.856707] usb 1-3.2: new high-speed USB device number 7 using xhci_hcd
[ 3954.948021] usb 1-3.2: language id specifier not provided by device, 
defaulting to English
[ 3954.951324] usb 1-3.2: New USB device found, idVendor=0572, idProduct=c688
[ 3954.951332] usb 1-3.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 4062.922871] dvb-usb: found a 'Mygica T230 DVB-T/T2/C' in warm state.
[ 4062.923388] [ cut here ]
[ 4062.923405] WARNING: CPU: 1 PID: 19330 at lib/dma-debug.c:1169 
check_for_stack+0x90/0xd0()
[ 4062.923409] xhci_hcd :00:14.0: DMA-API: device driver maps memory from 
stack [addr=88004c68b998]
[ 4062.923412] Modules linked in: dvb_usb_cxusb(+) dib0070 dvb_usb 
rc_pinnacle_pctv_hd em28xx_rc tda18271 cxd2820r em28xx_dvb dvb_core em28xx 
tveeprom v4l2_common videodev media snd_hda_codec_hdmi arc4 iwlmvm 
snd_hda_codec_realtek intel_rapl coretemp iTCO_wdt iTCO_vendor_support 
kvm_intel btusb snd_hda_codec_generic kvm btrtl snd_hda_intel btbcm btintel 
mac80211 snd_hda_codec snd_intel_sst_acpi bluetooth snd_intel_sst_core 
crct10dif_pclmul snd_soc_rt5670 snd_soc_sst_mfld_platform snd_hda_core 
crc32_pclmul snd_soc_rl6231 crc32c_intel snd_soc_core snd_compress snd_hwdep 
snd_pcm_dmaengine ac97_bus iwlwifi cfg80211 joydev r8169 i915 mii tpm_tis 
snd_seq ir_lirc_codec i2c_algo_bit i2c_i801 tpm lpc_ich lirc_dev ir_rc5_decoder 
ir_sanyo_decoder ir_nec_decoder ir_rc6_decoder ir_sony_decoder ir_jvc_decoder 
ir_xmp_decoder
[ 4062.923516]  ir_sharp_decoder ir_mce_kbd_decoder drm_kms_helper 
snd_seq_device rc_rc6_mce snd_pcm ite_cir drm snd_timer rc_core dw_dmac video 
snd rfkill_gpio rfkill fjes mei_txe i2c_designware_platform i2c_designware_pci 
i2c_designware_core soundcore soc_button_array shpchp pinctrl_cherryview 
dw_dmac_pci dw_dmac_core mei iosf_mbi nfsd auth_rpcgss nfs_acl lockd grace 
sunrpc hid_logitech_hidpp uas usb_storage hid_logitech_dj serio_raw sdhci_pci 
sdhci_acpi sdhci i2c_hid mmc_core
[ 4062.923584] CPU: 1 PID: 19330 Comm: modprobe Not tainted 
4.3.0-0.rc6.git2.1.fc24.x86_64 #1
[ 4062.923587] Hardware name:  /NUC5CPYB, BIOS 
PYBSWCEL.86A.0044.2015.0925.1143 09/25/2015
[ 4062.923591]   e8e1feb9 88004c68b580 
81419a49
[ 4062.923599]  88004c68b5c8 88004c68b5b8 810a9c12 
88004c68b998
[ 4062.923606]  88017a7fb098 88017a792990 0002 
0001
[ 4062.923613] Call Trace:
[ 4062.923619]  [] dump_stack+0x4b/0x72
[ 4062.923625]  [] warn_slowpath_common+0x82/0xc0
[ 4062.923630]  [] warn_slowpath_fmt+0x5c/0x80
[ 4062.923635]  [] check_for_stack+0x90/0xd0
[ 4062.923639]  [] debug_dma_map_page+0xfa/0x150
[ 4062.923646]  [] usb_hcd_map_urb_for_dma+0x5f8/0x780
[ 4062.923652]  [] ? is_ftrace_trampoline+0x4b/0x70
[ 4062.923657]  [] usb_hcd_submit_urb+0x1cd/0xab0
[ 4062.923662]  [] ? __bfs+0x33/0x280
[ 4062.923667]  [] ? mark_held_locks+0x79/0xa0
[ 4062.923671]  [] ? __raw_spin_lock_init+0x21/0x60
[ 4062.923676]  [] ? lockdep_init_map+0x73/0x640
[ 4062.923680]  [] ? trace_hardirqs_on_caller+0x129/0x1b0
[ 4062.923684]  [] usb_submit_urb+0x3fc/0x5a0
[ 4062.923688]  [] usb_start_wait_urb+0x74/0x180
[ 4062.923693]  [] usb_bulk_msg+0xbd/0x160
[ 4062.923701]  [] dvb_usb_generic_rw+0xd8/0x1d0 [dvb_usb]
[ 4062.923707]  [] dvb_usb_generic_write+0x19/0x20 [dvb_usb]
[ 4062.923724]  [] cxusb_ctrl_msg+0xed/0x130 [dvb_usb_cxusb]
[ 4062.923730]  [] ? dvb_usb_set_active_fe+0x3e/0x70 [dvb_usb]
[ 4062.923737]  [] cxusb_power_ctrl+0x58/0x60 [dvb_usb_cxusb]
[ 4062.923817]  [] cxusb_d680_dmb_power_ctrl+0x2b/0x90 
[dvb_usb_cxusb]
[ 4062.923824]  [] ? __kmalloc+0x28e/0x360
[ 4062.923831]  [] dvb_usb_device_power_ctrl+0x33/0x50 
[dvb_usb]
[ 4062.923844]  [] dvb_usb_device_init+0x24a/0x6a0 [dvb_usb]
[ 4062.923852]  [] cxusb_probe+0x1f2/0x210 [dvb_usb_cxusb]
[ 4062.923857]  [] usb_probe_interface+0x1bb/0x2e0
[ 4062.923865]  [] driver_probe_device+0x224/0x480
[ 4062.923870]  [] __driver_attach+0x88/0x90
[ 4062.923875]  [] ? driver_probe_device+0x480/0x480
[ 4062.923879]  [] bus_for_each_dev+0x73/0xc0
[ 4062.923884]  [] driver_attach+0x1e/0x20
[ 4062.923888]  [] bus_add_driver+0x1ee/0x280
[ 4062.923894]  [] driver_register+0x60/0xe0
[ 4062.923898]  [] usb_register_driver+0xad/0x160
[ 4062.923903]  [] ? 0xa09c
[ 4062.923909]  [] cxusb_driver_init+0x1e/0x1000 
[dvb_usb_cxusb]
[ 4062.923914]  [] do_one_initcall+0xb3/0x200
[ 4062.923920]  [] ? rcu_read_lock_sched_held+0x6d/0x80
[ 4062.923924]  [] ? 

Re: [PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

[Russell King - ARM Linux]

On Tue, Nov 03, 2015 at 05:41:24PM +, Robin Murphy wrote:
> Hi Tomasz,
> 
> On 02/11/15 13:43, Tomasz Figa wrote:
> >Agreed. The dma_map_*() API is not guaranteed to return a single
> >contiguous part of virtual address space for any given SG list.
> >However it was understood to be able to map buffers contiguously
> >mappable by the CPU into a single segment and users,
> >videobuf2-dma-contig in particular, relied on this.
> 
> I don't follow that - _any_ buffer made of page-sized chunks is going to be
> mappable contiguously by the CPU; it's clearly impossible for the streaming
> DMA API itself to offer such a guarantee, because it's entirely orthogonal
> to the presence or otherwise of an IOMMU.

Tomasz's use of "virtual address space" above in combination with the
DMA API is really confusing.

dma_map_sg() does *not* construct a CPU view of the passed scatterlist.
The only thing dma_map_sg() might do with virtual addresses is to use
them as a way to achieve cache coherence for one particular view of
that memory, that being the kernel's own lowmem mapping and any kmaps.
It doesn't extend to vmalloc() or userspace mappings of the memory.

If the scatterlist is converted to an array of struct page pointers,
it's possible to map it with vmap(), but it's implementation defined
whether such a mapping will receive cache maintanence as part of the
DMA API or not.  (If you have PIPT caches, it will, if they're VIPT
caches, maybe not.)

There is a separate set of calls to deal with the flushing issues for
vmap()'d memory in this case - see flush_kernel_vmap_range() and
invalidate_kernel_vmap_range().

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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

Geniatech / Mygica T230

[Mike Parkins]

Hi,
I can't get this dvb-t2 USB device to work despite the linuxtv site
claiming it is working since 3.19 kernel. I tried talking to the driver
team on IRC a few months ago and they said they would look at it but I have
recently pulled the linuxtv git tree and compiled it on my Linux Mint 4.09
kernel system and it has not changed. Below is the output of a typical
tuning attempt:

mp@Aurorabox ~ $ dvbv5-scan uk-CrystalPalace -I CHANNEL
Scanning frequency #1 49000
Lock   (0x1f) C/N= 28.25dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x11c0
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1200
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1240
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1280
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1600
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1640
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1680
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x16c0
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1700
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1740
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1780
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1804
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1a40
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1a80
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1ac0
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1b00
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the PMT table for service 0x1c00
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the NIT table
ERRORdvb_read_sections: no data read on section filter
ERRORerror while reading the SDT table
WARNING: no SDT table - storing channel(s) without their names
Storing Service ID 4164: '490.00MHz#4164'
Storing Service ID 4287: '490.00MHz#4287'
Storing Service ID 4288: '490.00MHz#4288'
Storing Service ID 4352: '490.00MHz#4352'
Storing Service ID 4416: '490.00MHz#4416'
Scanning frequency #2 51400
Lock   (0x1f) Signal= -29.00dBm C/N= 21.50dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #3 545833000
Lock   (0x1f) Signal= -30.00dBm C/N= 31.00dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #4 50600
Lock   (0x1f) Signal= -30.00dBm C/N= 28.50dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #5 48200
Lock   (0x1f) Signal= -30.00dBm C/N= 21.75dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #6 529833000
Lock   (0x1f) Signal= -29.00dBm C/N= 21.75dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #7 53800
Lock   (0x1f) Signal= -29.00dBm C/N= 16.50dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #8 57000
Lock   (0x1f) Signal= -46.00dBm C/N= 26.50dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
Scanning frequency #9 58600
Lock   (0x1f) Signal= -39.00dBm C/N= 26.25dB
ERRORdvb_read_sections: no data read on section filter
ERRORerror while waiting for PAT table
mp@Aurorabox ~ $
--
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 05/19] media: Move media graph state for streamon/off to the pipeline

[Sakari Ailus]

Hi Mauro,

On Wed, Oct 28, 2015 at 09:38:47AM +0900, Mauro Carvalho Chehab wrote:
> Em Tue, 27 Oct 2015 01:01:36 +0200
> Sakari Ailus  escreveu:
> 
> > The struct media_entity_graph was allocated in the stack, limiting the
> > number of entities that could be reasonably allocated. Instead, move the
> > struct to struct media_pipeline which is typically allocated using
> > kmalloc() instead.
> > 
> > The intent is to keep the enumeration around for later use for the
> > duration of the streaming. As streaming is eventually stopped, an
> > unfortunate memory allocation failure would prevent stopping the
> > streaming. As no memory will need to be allocated, the problem is avoided
> > altogether.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/media-entity.c | 16 
> >  include/media/media-entity.h |  2 ++
> >  2 files changed, 10 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> > index fceaf44..667ab32 100644
> > --- a/drivers/media/media-entity.c
> > +++ b/drivers/media/media-entity.c
> > @@ -456,16 +456,16 @@ __must_check int media_entity_pipeline_start(struct 
> > media_entity *entity,
> >  struct media_pipeline *pipe)
> >  {
> > struct media_device *mdev = entity->graph_obj.mdev;
> > -   struct media_entity_graph graph;
> > +   struct media_entity_graph *graph = >graph;
> > struct media_entity *entity_err = entity;
> > struct media_link *link;
> > int ret;
> >  
> > mutex_lock(>graph_mutex);
> >  
> > -   media_entity_graph_walk_start(, entity);
> > +   media_entity_graph_walk_start(graph, entity);
> >  
> > -   while ((entity = media_entity_graph_walk_next())) {
> > +   while ((entity = media_entity_graph_walk_next(graph))) {
> > DECLARE_BITMAP(active, MEDIA_ENTITY_MAX_PADS);
> > DECLARE_BITMAP(has_no_links, MEDIA_ENTITY_MAX_PADS);
> >  
> > @@ -546,9 +546,9 @@ error:
> >  * Link validation on graph failed. We revert what we did and
> >  * return the error.
> >  */
> > -   media_entity_graph_walk_start(, entity_err);
> > +   media_entity_graph_walk_start(graph, entity_err);
> >  
> > -   while ((entity_err = media_entity_graph_walk_next())) {
> > +   while ((entity_err = media_entity_graph_walk_next(graph))) {
> > entity_err->stream_count--;
> > if (entity_err->stream_count == 0)
> > entity_err->pipe = NULL;
> > @@ -582,13 +582,13 @@ EXPORT_SYMBOL_GPL(media_entity_pipeline_start);
> >  void media_entity_pipeline_stop(struct media_entity *entity)
> >  {
> > struct media_device *mdev = entity->graph_obj.mdev;
> > -   struct media_entity_graph graph;
> > +   struct media_entity_graph *graph = >pipe->graph;
> >  
> > mutex_lock(>graph_mutex);
> >  
> > -   media_entity_graph_walk_start(, entity);
> > +   media_entity_graph_walk_start(graph, entity);
> >  
> > -   while ((entity = media_entity_graph_walk_next())) {
> > +   while ((entity = media_entity_graph_walk_next(graph))) {
> > entity->stream_count--;
> > if (entity->stream_count == 0)
> > entity->pipe = NULL;
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > index dde9a5f..b2864cb 100644
> > --- a/include/media/media-entity.h
> > +++ b/include/media/media-entity.h
> > @@ -98,6 +98,8 @@ struct media_entity_graph {
> >  };
> >  
> >  struct media_pipeline {
> > +   /* For walking the graph in pipeline start / stop */
> > +   struct media_entity_graph graph;
> >  };
> 
> Please use the kernel-doc format for documenting struct.

I'll do that.

> 
> After this change:
> 
> Reviewed-by: Mauro Carvalho Chehab 

Thanks!

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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

Re: [PATCH 14/19] v4l: omap3isp: Use media entity enumeration API

[Sakari Ailus]

Hi Mauro,

On Wed, Oct 28, 2015 at 10:30:30AM +0900, Mauro Carvalho Chehab wrote:
> Em Tue, 27 Oct 2015 01:01:45 +0200
> Sakari Ailus  escreveu:
> 
> > From: Sakari Ailus 
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/platform/omap3isp/isp.c  | 21 +
> >  drivers/media/platform/omap3isp/isp.h  |  5 +++--
> >  drivers/media/platform/omap3isp/ispccdc.c  |  2 +-
> >  drivers/media/platform/omap3isp/ispvideo.c | 20 ++--
> >  drivers/media/platform/omap3isp/ispvideo.h |  4 ++--
> >  5 files changed, 33 insertions(+), 19 deletions(-)
> > 
> > diff --git a/drivers/media/platform/omap3isp/isp.c 
> > b/drivers/media/platform/omap3isp/isp.c
> > index 4a01a36..61c128e 100644
> > --- a/drivers/media/platform/omap3isp/isp.c
> > +++ b/drivers/media/platform/omap3isp/isp.c
> > @@ -896,7 +896,7 @@ static int isp_pipeline_enable(struct isp_pipeline 
> > *pipe,
> >  * starting entities if the pipeline won't start anyway (those entities
> >  * would then likely fail to stop, making the problem worse).
> >  */
> > -   if (pipe->entities & isp->crashed)
> > +   if (media_entity_enum_intersects(>entities, >crashed))
> > return -EIO;
> 
> If the size of entities/crashed enums is different, it should be
> returning an error, I guess, as this would be a driver's problem, and the
> graph traversal on OMAP3 would likely be wrong.

They should always have the same size. The omap3isp does not support dynamic
entity (un)registration. Both enums are initialised once all the entities
have been registered.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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

Re: [PATCH 03/19] media: Add an API to manage entity enumerations

[Sakari Ailus]

Hi Mauro,

Many thanks for the thorough review of the set!

On Wed, Oct 28, 2015 at 11:09:31AM +0900, Mauro Carvalho Chehab wrote:
> Em Tue, 27 Oct 2015 01:01:34 +0200
> Sakari Ailus  escreveu:
> 
> > From: Sakari Ailus 
> > 
> > This is useful in e.g. knowing whether certain operations have already
> > been performed for an entity. The users include the framework itself (for
> > graph walking) and a number of drivers.
> > 
> > Signed-off-by: Sakari Ailus 
> > ---
> >  drivers/media/media-entity.c |  39 +
> >  include/media/media-device.h |  14 +
> >  include/media/media-entity.h | 128 
> > ---
> >  3 files changed, 173 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> > index d11f440..fceaf44 100644
> > --- a/drivers/media/media-entity.c
> > +++ b/drivers/media/media-entity.c
> > @@ -213,6 +213,45 @@ void media_gobj_remove(struct media_gobj *gobj)
> >  }
> >  
> >  /**
> > + * __media_entity_enum_init - Initialise an entity enumeration
> > + *
> > + * @e: Entity enumeration to be initialised
> > + * @idx_max: Maximum number of entities in the enumeration
> > + *
> > + * Returns zero on success or a negative error code.
> > + */
> > +int __media_entity_enum_init(struct media_entity_enum *e, int idx_max)
> > +{
> > +   if (idx_max > MEDIA_ENTITY_ENUM_MAX_ID) {
> > +   e->e = kcalloc(DIV_ROUND_UP(idx_max, BITS_PER_LONG),
> > +  sizeof(long), GFP_KERNEL);
> 
> That looks wrong to me when the graph size increases. 
> 
> If e->e is not null, you need first to free the previously allocated
> map before allocing a new one.

Indeed. You'll first have to call media_entity_enum_cleanup().

It's the responsibility of the user of this interface (i.e. driver and the
framework) to ensure that the enum is large enough to contain all the
entities. Allowing dynamic updates to the graph does indeed open a can of
worms and I'd prefer to keep that can sealed for a bit longer.

> 
> > +   if (!e->e)
> > +   return -ENOMEM;
> > +   } else {
> > +   e->e = e->__e;
> > +   }
> > +
> > +   bitmap_zero(e->e, idx_max);
> > +   e->idx_max = idx_max;
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(__media_entity_enum_init);
> > +
> > +/**
> > + * media_entity_enum_cleanup - Release resources of an entity enumeration
> > + *
> > + * @e: Entity enumeration to be released
> > + */
> > +void media_entity_enum_cleanup(struct media_entity_enum *e)
> > +{
> > +   if (e->e != e->__e)
> > +   kfree(e->e);
> > +   e->e = NULL;
> > +}
> > +EXPORT_SYMBOL_GPL(media_entity_enum_cleanup);
> > +
> > +/**
> >   * media_entity_init - Initialize a media entity
> >   *
> >   * @num_pads: Total number of sink and source pads.
> > diff --git a/include/media/media-device.h b/include/media/media-device.h
> > index c0e1764..2d46c66 100644
> > --- a/include/media/media-device.h
> > +++ b/include/media/media-device.h
> > @@ -110,6 +110,20 @@ struct media_device {
> >  /* media_devnode to media_device */
> >  #define to_media_device(node) container_of(node, struct media_device, 
> > devnode)
> >  
> > +/**
> > + * media_entity_enum_init - Initialise an entity enumeration
> > + *
> > + * @e: Entity enumeration to be initialised
> > + * @mdev: The related media device
> > + *
> > + * Returns zero on success or a negative error code.
> > + */
> > +static inline __must_check int media_entity_enum_init(
> > +   struct media_entity_enum *e, struct media_device *mdev)
> > +{
> > +   return __media_entity_enum_init(e, mdev->entity_internal_idx_max + 1);
> > +}
> > +
> >  void media_device_init(struct media_device *mdev);
> >  void media_device_cleanup(struct media_device *mdev);
> >  int __must_check __media_device_register(struct media_device *mdev,
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > index d3d3a39..fc54192 100644
> > --- a/include/media/media-entity.h
> > +++ b/include/media/media-entity.h
> > @@ -23,7 +23,7 @@
> >  #ifndef _MEDIA_ENTITY_H
> >  #define _MEDIA_ENTITY_H
> >  
> > -#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -71,6 +71,22 @@ struct media_gobj {
> > struct list_headlist;
> >  };
> >  
> > +#define MEDIA_ENTITY_ENUM_MAX_DEPTH16
> > +#define MEDIA_ENTITY_ENUM_MAX_ID   64
> > +
> > +/*
> > + * The number of pads can't be bigger than the number of entities,
> > + * as the worse-case scenario is to have one entity linked up to
> > + * MEDIA_ENTITY_ENUM_MAX_ID - 1 entities.
> > + */
> > +#define MEDIA_ENTITY_MAX_PADS  (MEDIA_ENTITY_ENUM_MAX_ID - 1)
> > +
> > +struct media_entity_enum {
> > +   DECLARE_BITMAP(__e, MEDIA_ENTITY_ENUM_MAX_ID);
> 
> I don't think it makes sense to keep MEDIA_ENTITY_ENUM_MAX_ID. 
> Instead, let's just dynamically allocate the bitmap.

I think it makes 

Re: [PATCH 04/19] media: Move struct media_entity_graph definition up

[Sakari Ailus]

Hi Mauro,

On Wed, Oct 28, 2015 at 09:36:50AM +0900, Mauro Carvalho Chehab wrote:
> Em Tue, 27 Oct 2015 01:01:35 +0200
> Sakari Ailus  escreveu:
> 
> > It will be needed in struct media_pipeline shortly.
> > 
> > Signed-off-by: Sakari Ailus 
> 
> Reviewed-by: Mauro Carvalho Chehab 
> (but see below)
> 
> > ---
> >  include/media/media-entity.h | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/include/media/media-entity.h b/include/media/media-entity.h
> > index fc54192..dde9a5f 100644
> > --- a/include/media/media-entity.h
> > +++ b/include/media/media-entity.h
> > @@ -87,6 +87,16 @@ struct media_entity_enum {
> > int idx_max;
> >  };
> >  
> > +struct media_entity_graph {
> 
> Not a problem on this patch itself, but since you're touching this
> struct, it would be nice to take the opportunity and document it ;)

I'll document it in a separate patch on top of the set. Would you be fine
with that?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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

Re: [PATCH 07/19] media: Use the new media_entity_graph_walk_start()

[Sakari Ailus]

Hi Mauro,

On Wed, Oct 28, 2015 at 09:43:43AM +0900, Mauro Carvalho Chehab wrote:
> Em Tue, 27 Oct 2015 01:01:38 +0200
> Sakari Ailus  escreveu:
> 
> > Signed-off-by: Sakari Ailus 
> 
> Please add some documentation at the body for all patches.
> 
> Btw, IMHO, it would be best to fold this patch and the following ones
> that are related to media_entity_graph_walk_init() altogether, as it
> makes easier to review if all places were covered.

I think patches such as the 8th are easier to review as they are.

For the coverage,

$ git grep -l -E '^ *media_entity_graph_walk_start' 
Documentation/media-framework.txt
drivers/media/media-entity.c
drivers/media/platform/exynos4-is/media-dev.c
drivers/media/platform/omap3isp/isp.c
drivers/media/platform/omap3isp/ispvideo.c
drivers/media/platform/vsp1/vsp1_video.c
drivers/media/platform/xilinx/xilinx-dma.c
drivers/staging/media/davinci_vpfe/vpfe_video.c
drivers/staging/media/omap4iss/iss.c
drivers/staging/media/omap4iss/iss_video.c

Which suggests that I'm probably missing a few patches, indeed. I'll take
that into account in the next submission.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: 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

[v4l-utils 0/5] Misc build fixes

[Thomas Petazzoni]

Hello,

Here is a small set of fixes against v4l-utils that we have
accumulated in the Buildroot project to fix a number of build
issues. Those build issues are related to linking with the musl C
library, or do linking with the libintl library when the gettext
functions are not provided by the C library (which is what happens the
uClibc C library is used).

Thanks,

Thomas

Peter Seiderer (1):
  dvb/keytable: fix missing libintl linking

Thomas Petazzoni (4):
  libv4lsyscall-priv.h: Use off_t instead of __off_t
  utils: Properly use ENABLE_NLS for locale related code
  utils/v4l2-compliance: Include  instead of 
  libv4lsyscall-priv.h: Only define SYS_mmap2 if needed

 lib/libv4l1/v4l1compat.c   |  3 +--
 lib/libv4l2/v4l2convert.c  |  5 ++---
 lib/libv4lconvert/libv4lsyscall-priv.h | 13 +
 utils/dvb/Makefile.am  |  8 
 utils/dvb/dvb-fe-tool.c|  2 ++
 utils/dvb/dvb-format-convert.c |  2 ++
 utils/dvb/dvbv5-scan.c |  2 ++
 utils/dvb/dvbv5-zap.c  |  2 ++
 utils/keytable/Makefile.am |  1 +
 utils/keytable/keytable.c  |  2 ++
 utils/v4l2-compliance/v4l-helpers.h|  2 +-
 11 files changed, 24 insertions(+), 18 deletions(-)

-- 
2.6.2

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

[v4l-utils 5/5] dvb/keytable: fix missing libintl linking

[Thomas Petazzoni]

From: Peter Seiderer 

Signed-off-by: Peter Seiderer 
---
 utils/dvb/Makefile.am  | 8 
 utils/keytable/Makefile.am | 1 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/utils/dvb/Makefile.am b/utils/dvb/Makefile.am
index 6aae408..a96a1a2 100644
--- a/utils/dvb/Makefile.am
+++ b/utils/dvb/Makefile.am
@@ -2,19 +2,19 @@ bin_PROGRAMS = dvb-fe-tool dvbv5-zap dvbv5-scan 
dvb-format-convert
 man_MANS = dvb-fe-tool.1 dvbv5-zap.1 dvbv5-scan.1 dvb-format-convert.1
 
 dvb_fe_tool_SOURCES = dvb-fe-tool.c
-dvb_fe_tool_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvb_fe_tool_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvb_fe_tool_LDFLAGS = $(ARGP_LIBS) -lm
 
 dvbv5_zap_SOURCES = dvbv5-zap.c
-dvbv5_zap_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvbv5_zap_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvbv5_zap_LDFLAGS = $(ARGP_LIBS) -lm
 
 dvbv5_scan_SOURCES = dvbv5-scan.c
-dvbv5_scan_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvbv5_scan_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvbv5_scan_LDFLAGS = $(ARGP_LIBS) -lm
 
 dvb_format_convert_SOURCES = dvb-format-convert.c
-dvb_format_convert_LDADD = ../../lib/libdvbv5/libdvbv5.la
+dvb_format_convert_LDADD = ../../lib/libdvbv5/libdvbv5.la @LIBINTL@
 dvb_format_convert_LDFLAGS = $(ARGP_LIBS) -lm
 
 EXTRA_DIST = README
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 925c8ea..8444ac2 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -5,6 +5,7 @@ keytablesystem_DATA = $(srcdir)/rc_keymaps/*
 udevrules_DATA = 70-infrared.rules
 
 ir_keytable_SOURCES = keytable.c parse.h
+ir_keytable_LDADD = @LIBINTL@
 ir_keytable_LDFLAGS = $(ARGP_LIBS)
 
 EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace 
gen_keytables.pl ir-keytable.1 rc_maps.cfg
-- 
2.6.2

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

[v4l-utils 3/5] utils/v4l2-compliance: Include instead of

[Thomas Petazzoni]

Code should not be including  header, but instead it
should include the public  header.

On glibc and uClibc,  simply includes , but with
the musl C library, it spits out a warning telling you that you're not
doing the right thing:

In file included from ./v4l-helpers.h:12:0,
 from ./cv4l-helpers.h:5,
 from v4l2-compliance.h:36,
 from v4l2-test-controls.cpp:33:
.../sysroot/usr/include/sys/fcntl.h:1:2: warning: #warning redirecting 
incorrect #include  to  [-Wcpp]
 #warning redirecting incorrect #include  to 

Signed-off-by: Thomas Petazzoni 
---
 utils/v4l2-compliance/v4l-helpers.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/utils/v4l2-compliance/v4l-helpers.h 
b/utils/v4l2-compliance/v4l-helpers.h
index d8a273d..9aafa34 100644
--- a/utils/v4l2-compliance/v4l-helpers.h
+++ b/utils/v4l2-compliance/v4l-helpers.h
@@ -9,7 +9,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.6.2

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

[v4l-utils 2/5] utils: Properly use ENABLE_NLS for locale related code

[Thomas Petazzoni]

Various tools in utils/ use ENABLE_NLS to decide whether locale
support is available or not, and only include  if ENABLE_NLS
is defined. However, they unconditionally use functions defined in
 such as setlocale(), bindtextdomain() or textdomain(),
which causes build failures when the prototypes of such functions are
not available due to  not being included.

In order to fix this, we add ENABLE_NLS conditionals around the calls
to these functions.

Signed-off-by: Thomas Petazzoni 
---
 utils/dvb/dvb-fe-tool.c| 2 ++
 utils/dvb/dvb-format-convert.c | 2 ++
 utils/dvb/dvbv5-scan.c | 2 ++
 utils/dvb/dvbv5-zap.c  | 2 ++
 utils/keytable/keytable.c  | 2 ++
 5 files changed, 10 insertions(+)

diff --git a/utils/dvb/dvb-fe-tool.c b/utils/dvb/dvb-fe-tool.c
index efc2ebf..ba01aa9 100644
--- a/utils/dvb/dvb-fe-tool.c
+++ b/utils/dvb/dvb-fe-tool.c
@@ -276,9 +276,11 @@ int main(int argc, char *argv[])
struct dvb_v5_fe_parms *parms;
int fe_flags = O_RDWR;
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
argp_parse(, argc, argv, ARGP_NO_HELP | ARGP_NO_EXIT, 0, 0);
 
diff --git a/utils/dvb/dvb-format-convert.c b/utils/dvb/dvb-format-convert.c
index e39df03..09451d4 100644
--- a/utils/dvb/dvb-format-convert.c
+++ b/utils/dvb/dvb-format-convert.c
@@ -132,9 +132,11 @@ int main(int argc, char **argv)
.args_doc = N_(" "),
};
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
memset(, 0, sizeof(args));
argp_parse(, argc, argv, ARGP_NO_HELP | ARGP_NO_EXIT, , );
diff --git a/utils/dvb/dvbv5-scan.c b/utils/dvb/dvbv5-scan.c
index be1586d..1bb0ced 100644
--- a/utils/dvb/dvbv5-scan.c
+++ b/utils/dvb/dvbv5-scan.c
@@ -461,9 +461,11 @@ int main(int argc, char **argv)
.args_doc = N_(""),
};
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
memset(, 0, sizeof(args));
args.sat_number = -1;
diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index 2812166..848259b 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -758,9 +758,11 @@ int main(int argc, char **argv)
.args_doc = N_(" [or  if in monitor 
mode]"),
};
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
memset(, 0, sizeof(args));
args.sat_number = -1;
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 63938b9..3922ad2 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -1467,9 +1467,11 @@ int main(int argc, char *argv[])
static struct sysfs_names *names;
struct rc_device  rc_dev;
 
+#ifdef ENABLE_NLS
setlocale (LC_ALL, "");
bindtextdomain (PACKAGE, LOCALEDIR);
textdomain (PACKAGE);
+#endif
 
argp_parse(, argc, argv, ARGP_NO_HELP | ARGP_NO_EXIT, 0, 0);
 
-- 
2.6.2

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

[v4l-utils 1/5] libv4lsyscall-priv.h: Use off_t instead of __off_t

[Thomas Petazzoni]

__off_t is a kernel internal symbol, which happens to be user-visible
with glibc, but not necessarily with other C libraries such as
musl. In v4l-utils code, it's mainly used for the mmap() prototype,
but the mmap() manpage really uses off_t, not __off_t.

Switching from __off_t to off_t allows the code to build properly with
musl.

Signed-off-by: Thomas Petazzoni 
---
 lib/libv4l1/v4l1compat.c   |  3 +--
 lib/libv4l2/v4l2convert.c  |  5 ++---
 lib/libv4lconvert/libv4lsyscall-priv.h | 11 +++
 3 files changed, 6 insertions(+), 13 deletions(-)

diff --git a/lib/libv4l1/v4l1compat.c b/lib/libv4l1/v4l1compat.c
index 393896c..cb79629 100644
--- a/lib/libv4l1/v4l1compat.c
+++ b/lib/libv4l1/v4l1compat.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include "../libv4lconvert/libv4lsyscall-priv.h" /* for __off_t */
 
 #include 
 #include 
@@ -116,7 +115,7 @@ LIBV4L_PUBLIC ssize_t read(int fd, void *buffer, size_t n)
 }
 
 LIBV4L_PUBLIC void *mmap(void *start, size_t length, int prot, int flags, int 
fd,
-   __off_t offset)
+   off_t offset)
 {
return v4l1_mmap(start, length, prot, flags, fd, offset);
 }
diff --git a/lib/libv4l2/v4l2convert.c b/lib/libv4l2/v4l2convert.c
index 0384c13..6abccbf 100644
--- a/lib/libv4l2/v4l2convert.c
+++ b/lib/libv4l2/v4l2convert.c
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include "../libv4lconvert/libv4lsyscall-priv.h"
 #include 
 #include 
 
@@ -148,14 +147,14 @@ LIBV4L_PUBLIC ssize_t read(int fd, void *buffer, size_t n)
 }
 
 LIBV4L_PUBLIC void *mmap(void *start, size_t length, int prot, int flags, int 
fd,
-   __off_t offset)
+   off_t offset)
 {
return v4l2_mmap(start, length, prot, flags, fd, offset);
 }
 
 #if defined(linux) && defined(__GLIBC__)
 LIBV4L_PUBLIC void *mmap64(void *start, size_t length, int prot, int flags, 
int fd,
-   __off64_t offset)
+   off64_t offset)
 {
return v4l2_mmap(start, length, prot, flags, fd, offset);
 }
diff --git a/lib/libv4lconvert/libv4lsyscall-priv.h 
b/lib/libv4lconvert/libv4lsyscall-priv.h
index f548fb2..f87eff4 100644
--- a/lib/libv4lconvert/libv4lsyscall-priv.h
+++ b/lib/libv4lconvert/libv4lsyscall-priv.h
@@ -59,11 +59,6 @@
 #define_IOC_SIZE(cmd) IOCPARM_LEN(cmd)
 #defineMAP_ANONYMOUS MAP_ANON
 #defineMMAP2_PAGE_SHIFT 0
-typedef off_t __off_t;
-#endif
-
-#if defined(ANDROID)
-typedef off_t __off_t;
 #endif
 
 #undef SYS_OPEN
@@ -95,15 +90,15 @@ typedef off_t __off_t;
 #if defined(__FreeBSD__)
 #define SYS_MMAP(addr, len, prot, flags, fd, off) \
__syscall(SYS_mmap, (void *)(addr), (size_t)(len), \
-   (int)(prot), (int)(flags), (int)(fd), (__off_t)(off))
+   (int)(prot), (int)(flags), (int)(fd), (off_t)(off))
 #elif defined(__FreeBSD_kernel__)
 #define SYS_MMAP(addr, len, prot, flags, fd, off) \
syscall(SYS_mmap, (void *)(addr), (size_t)(len), \
-   (int)(prot), (int)(flags), (int)(fd), (__off_t)(off))
+   (int)(prot), (int)(flags), (int)(fd), (off_t)(off))
 #else
 #define SYS_MMAP(addr, len, prot, flags, fd, off) \
syscall(SYS_mmap2, (void *)(addr), (size_t)(len), \
-   (int)(prot), (int)(flags), (int)(fd), (__off_t)((off) 
>> MMAP2_PAGE_SHIFT))
+   (int)(prot), (int)(flags), (int)(fd), (off_t)((off) >> 
MMAP2_PAGE_SHIFT))
 #endif
 
 #define SYS_MUNMAP(addr, len) \
-- 
2.6.2

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

[v4l-utils 4/5] libv4lsyscall-priv.h: Only define SYS_mmap2 if needed

[Thomas Petazzoni]

The logic in libv4lsyscall-priv.h unconditionally defines SYS_mmap2 on
Linux systems, but with current versions of C libraries, SYS_mmap2 is
already defined, and therefore this additional definition causes some
build warnings:

In file included from processing/libv4lprocessing.h:24:0,
 from libv4lconvert-priv.h:37,
 from tinyjpeg.c:42:
processing/../libv4lsyscall-priv.h:44:0: warning: "SYS_mmap2" redefined
 #define SYS_mmap2 __NR_mmap2
 ^
In file included from .../sysroot/usr/include/sys/syscall.h:4:0,
 from processing/../libv4lsyscall-priv.h:39,
 from processing/libv4lprocessing.h:24,
 from libv4lconvert-priv.h:37,
 from tinyjpeg.c:42:
.../sysroot/usr/include/bits/syscall.h:504:0: note: this is the location of the 
previous definition
 #define SYS_mmap2 192

This commit fixes that by only defining SYS_mmap2 if not already
defined.

Signed-off-by: Thomas Petazzoni 
---
 lib/libv4lconvert/libv4lsyscall-priv.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/libv4lconvert/libv4lsyscall-priv.h 
b/lib/libv4lconvert/libv4lsyscall-priv.h
index f87eff4..bc18b21 100644
--- a/lib/libv4lconvert/libv4lsyscall-priv.h
+++ b/lib/libv4lconvert/libv4lsyscall-priv.h
@@ -41,7 +41,9 @@
 #include 
 /* On 32 bits archs we always use mmap2, on 64 bits archs there is no mmap2 */
 #ifdef __NR_mmap2
+#if !defined(SYS_mmap2)
 #defineSYS_mmap2 __NR_mmap2
+#endif
 #defineMMAP2_PAGE_SHIFT 12
 #else
 #defineSYS_mmap2 SYS_mmap
-- 
2.6.2

--
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] v4l2-ctrls: remove unclaimed v4l2_ctrl_add_ctrl() interface

[Vladimir Zapolskiy]

v4l2_ctrl_add_ctrl() interface has no users since its introduction in
commit 0996517cf8ea ("V4L/DVB: v4l2: Add new control handling framework")
and its functionality is covered by v4l2_ctrl_new() and derivative
interfaces, so it is safe to remove the interface from the kernel.

Signed-off-by: Vladimir Zapolskiy 
---
 Documentation/video4linux/v4l2-controls.txt |  1 -
 drivers/media/v4l2-core/v4l2-ctrls.c| 16 
 include/media/v4l2-ctrls.h  | 12 
 3 files changed, 29 deletions(-)

diff --git a/Documentation/video4linux/v4l2-controls.txt 
b/Documentation/video4linux/v4l2-controls.txt
index 5517db6..5e759ca 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -647,7 +647,6 @@ Or you can add specific controls to a handler:
volume = v4l2_ctrl_new_std(_ctrl_handler, , 
V4L2_CID_AUDIO_VOLUME, ...);
v4l2_ctrl_new_std(_ctrl_handler, , V4L2_CID_BRIGHTNESS, ...);
v4l2_ctrl_new_std(_ctrl_handler, , V4L2_CID_CONTRAST, ...);
-   v4l2_ctrl_add_ctrl(_ctrl_handler, volume);
 
 What you should not do is make two identical controls for two handlers.
 For example:
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index b6b7dcc..3b14485 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2198,22 +2198,6 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct 
v4l2_ctrl_handler *hdl,
 }
 EXPORT_SYMBOL(v4l2_ctrl_new_int_menu);
 
-/* Add a control from another handler to this handler */
-struct v4l2_ctrl *v4l2_ctrl_add_ctrl(struct v4l2_ctrl_handler *hdl,
- struct v4l2_ctrl *ctrl)
-{
-   if (hdl == NULL || hdl->error)
-   return NULL;
-   if (ctrl == NULL) {
-   handler_set_err(hdl, -EINVAL);
-   return NULL;
-   }
-   if (ctrl->handler == hdl)
-   return ctrl;
-   return handler_new_ref(hdl, ctrl) ? NULL : ctrl;
-}
-EXPORT_SYMBOL(v4l2_ctrl_add_ctrl);
-
 /* Add the controls from another handler to our own. */
 int v4l2_ctrl_add_handler(struct v4l2_ctrl_handler *hdl,
  struct v4l2_ctrl_handler *add,
diff --git a/include/media/v4l2-ctrls.h b/include/media/v4l2-ctrls.h
index da6fe98..0bc9b35 100644
--- a/include/media/v4l2-ctrls.h
+++ b/include/media/v4l2-ctrls.h
@@ -535,18 +535,6 @@ struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct 
v4l2_ctrl_handler *hdl,
u32 id, u8 max, u8 def, const s64 *qmenu_int);
 
 /**
- * v4l2_ctrl_add_ctrl() - Add a control from another handler to this handler.
- * @hdl:   The control handler.
- * @ctrl:  The control to add.
- *
- * It will return NULL if it was unable to add the control reference.
- * If the control already belonged to the handler, then it will do
- * nothing and just return @ctrl.
- */
-struct v4l2_ctrl *v4l2_ctrl_add_ctrl(struct v4l2_ctrl_handler *hdl,
- struct v4l2_ctrl *ctrl);
-
-/**
  * v4l2_ctrl_add_handler() - Add all controls from handler @add to
  * handler @hdl.
  * @hdl:   The control handler.
-- 
2.1.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] libdvbv5: fix the count of partial receptions

[Felipe Eduardo Concha Avello]

Currently the number of elements are counted wrong, its divided by the size
of a pointer and not the size of the struct
isdb_desc_partial_reception (uint16_t).

I noticed this when using "dvbv5-scan -v" in order to debug an ISDB-T table.

Signed-off-by: Felipe Concha Avello 
---
diff --git a/lib/libdvbv5/descriptors/desc_partial_reception.c
b/lib/libdvbv5/descriptors/desc_partial_reception.c
index ce40882..63b8a07 100644
--- a/lib/libdvbv5/descriptors/desc_partial_reception.c
+++ b/lib/libdvbv5/descriptors/desc_partial_reception.c
@@ -38,7 +38,7 @@ int isdb_desc_partial_reception_init(struct
dvb_v5_fe_parms *parms,

memcpy(d->partial_reception, p, d->length);

-   len = d->length / sizeof(d->partial_reception);
+   len = d->length / sizeof(*d->partial_reception);

for (i = 0; i < len; i++)
bswap16(d->partial_reception[i].service_id);
@@ -58,7 +58,7 @@ void isdb_desc_partial_reception_print(struct
dvb_v5_fe_parms *parms, const stru
int i;
size_t len;

-   len = d->length / sizeof(d->partial_reception);
+   len = d->length / sizeof(*d->partial_reception);

for (i = 0; i < len; i++) {
dvb_loginfo("|   service ID[%d] %d", i,
d->partial_reception[i].service_id);
diff --git a/lib/libdvbv5/dvb-scan.c b/lib/libdvbv5/dvb-scan.c
index 1ffb98a..38f558b 100644
--- a/lib/libdvbv5/dvb-scan.c
+++ b/lib/libdvbv5/dvb-scan.c
@@ -905,7 +905,7 @@ static void add_update_nit_1seg(struct dvb_table_nit *nit,
if (!tr->update)
return;

-   len = d->length / sizeof(d->partial_reception);
+   len = d->length / sizeof(*d->partial_reception);

for (i = 0; i < len; i++) {
if (tr->entry->service_id ==
d->partial_reception[i].service_id) {
--
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 v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

[Tomasz Figa]

On Wed, Nov 4, 2015 at 2:41 AM, Robin Murphy  wrote:
> Hi Tomasz,
>
> On 02/11/15 13:43, Tomasz Figa wrote:
>>
>> I'd like to know what is the boundary mask and what hardware imposes
>> requirements like this. The cost here is not only over-allocating a
>> little, but making many, many buffers contiguously mappable on the
>> CPU, unmappable contiguously in IOMMU, which just defeats the purpose
>> of having an IOMMU, which I believe should be there for simple IP
>> blocks taking one DMA address to be able to view the buffer the same
>> way as the CPU.
>
>
> The expectation with dma_map_sg() is that you're either going to be
> iterating over the buffer segments, handing off each address to the device
> to process one by one;

My understanding of a scatterlist was that it represents a buffer as a
whole, by joining together its physically discontinuous segments.

I don't see how single segments (layout of which is completely up to
the allocator; often just single pages) would be usable for hardware
that needs to do some work more serious than just writing a byte
stream continuously to subsequent buffers. In case of such simple
devices you don't even need an IOMMU (for means other than protection
and/or getting over address space limitations).

However, IMHO the most important use case of an IOMMU is to make
buffers, which are contiguous in CPU virtual address space (VA),
contiguous in device's address space (IOVA). Your implementation of
dma_map_sg() effectively breaks this ability, so I'm not really
following why it's located under drivers/iommu and supposed to be used
with IOMMU-enabled platforms...

> or you have a scatter-gather-capable device, in which
> case you hand off the whole list at once.

No need for mapping ability of the IOMMU here as well (except for
working around address space issues, as I mentioned above).

> It's in the latter case where you
> have to make sure the list doesn't exceed the hardware limitations of that
> device. I believe the original concern was disk controllers (the
> introduction of dma_parms seems to originate from the linux-scsi list), but
> most scatter-gather engines are going to have some limit on how much they
> can handle per entry (IMO the dmaengine drivers are the easiest example to
> look at).
>
> Segment boundaries are a little more arcane, but my assumption is that they
> relate to the kind of devices whose addressing is not flat but relative to
> some separate segment register (The "64-bit" mode of USB EHCI is one
> concrete example I can think of) - since you cannot realistically change the
> segment register while the device is in the middle of accessing a single
> buffer entry, that entry must not fall across a segment boundary or at some
> point the device's accesses are going to overflow the offset address bits
> and wrap around to bogus addresses at the bottom of the segment.

The two requirements above sound like something really specific to
scatter-gather-capable hardware, which as I pointed above, barely need
an IOMMU (at least its mapping capabilities). We are talking here
about very IOMMU-specific code, though...

Now, while I see that on some systems there might be IOMMU used for
improving protection and working around addressing issues with
SG-capable hardware, the code shouldn't be breaking the majority of
systems with IOMMU used as the only possible way to make physically
discontinuous appear (IO-virtually) continuous to devices incapable of
scatter-gather.

>
> Now yes, it will be possible under _most_ circumstances to use an IOMMU to
> lay out a list of segments with page-aligned lengths within a single IOVA
> allocation whilst still meeting all the necessary constraints. It just needs
> some unavoidably complicated calculations - quite likely significantly more
> complex than my v5 version of map_sg() that tried to do that and merge
> segments but failed to take the initial alignment into account properly -
> since there are much simpler ways to enforce just the _necessary_ behaviour
> for the DMA API, I put the complicated stuff to one side for now to prevent
> it holding up getting the basic functional support in place.

Somehow just whatever currently done in arch/arm/mm/dma-mapping.c was
sufficient and not overly complicated.

See http://lxr.free-electrons.com/source/arch/arm/mm/dma-mapping.c#L1547 .

I can see that the code there at least tries to comply with maximum
segment size constraint. Segment boundary seems to be ignored, though.
However, I'm convinced that in most (if not all) cases where IOMMU
IOVA-contiguous mapping is needed, those two requirements don't exist.
Do we really have to break the good hardware only because the
bad^Wlimited one is broken?

Couldn't we preserve the ARM-like behavior whenever
dma_parms->segment_boundary_mask is set to all 1s and
dma_parms->max_segment_size to UINT_MAX (what currently drivers used
to set) or 0 (sounds more logical for the meaning of "no maximum
given")?

>
> 

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

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:   Wed Nov  4 04:00:20 CET 2015
git branch: test
git hash:   79f5b6ae960d380c829fb67d5dadcd1d025d2775
gcc version:i686-linux-gcc (GCC) 5.1.0
sparse version: v0.5.0-51-ga53cea2
smatch version: 0.4.1-3153-g7d56ab3
host hardware:  x86_64
host os:4.0.0-3.slh.1-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: OK
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.32.27-i686: OK
linux-2.6.33.7-i686: OK
linux-2.6.34.7-i686: OK
linux-2.6.35.9-i686: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12.23-i686: OK
linux-3.13.11-i686: OK
linux-3.14.9-i686: OK
linux-3.15.2-i686: OK
linux-3.16.7-i686: OK
linux-3.17.8-i686: OK
linux-3.18.7-i686: OK
linux-3.19-i686: OK
linux-4.0-i686: OK
linux-4.1.1-i686: OK
linux-4.2-i686: OK
linux-4.3-i686: OK
linux-2.6.32.27-x86_64: OK
linux-2.6.33.7-x86_64: OK
linux-2.6.34.7-x86_64: OK
linux-2.6.35.9-x86_64: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12.23-x86_64: OK
linux-3.13.11-x86_64: OK
linux-3.14.9-x86_64: OK
linux-3.15.2-x86_64: OK
linux-3.16.7-x86_64: OK
linux-3.17.8-x86_64: OK
linux-3.18.7-x86_64: OK
linux-3.19-x86_64: OK
linux-4.0-x86_64: OK
linux-4.1.1-x86_64: OK
linux-4.2-x86_64: OK
linux-4.3-x86_64: ERRORS
apps: OK
spec-git: OK
sparse: WARNINGS
smatch: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH v6 1/3] iommu: Implement common IOMMU ops for DMA mapping

[Tomasz Figa]

On Wed, Nov 4, 2015 at 3:40 AM, Russell King - ARM Linux
 wrote:
> On Tue, Nov 03, 2015 at 05:41:24PM +, Robin Murphy wrote:
>> Hi Tomasz,
>>
>> On 02/11/15 13:43, Tomasz Figa wrote:
>> >Agreed. The dma_map_*() API is not guaranteed to return a single
>> >contiguous part of virtual address space for any given SG list.
>> >However it was understood to be able to map buffers contiguously
>> >mappable by the CPU into a single segment and users,
>> >videobuf2-dma-contig in particular, relied on this.
>>
>> I don't follow that - _any_ buffer made of page-sized chunks is going to be
>> mappable contiguously by the CPU; it's clearly impossible for the streaming
>> DMA API itself to offer such a guarantee, because it's entirely orthogonal
>> to the presence or otherwise of an IOMMU.
>
> Tomasz's use of "virtual address space" above in combination with the
> DMA API is really confusing.

I suppose I must have mistakenly use "virtual address space" somewhere
instead of "IO virtual address space". I'm sorry for causing
confusion.

The thing being discussed here is mapping of buffers described by
scatterlists into IO virtual address space, i.e. the operation
happening when dma_map_sg() is called for an IOMMU-enabled device.

Best regards,
Tomasz
--
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 MC Next Gen v2 2/3] sound/usb: Create media mixer function and control interface entities

[Shuah Khan]

On 10/25/2015 03:37 PM, Shuah Khan wrote:
> On 10/22/2015 01:16 AM, Takashi Iwai wrote:
>> On Wed, 21 Oct 2015 01:25:15 +0200,
>> Shuah Khan wrote:
>>>
>>> Add support for creating MEDIA_ENT_F_AUDIO_MIXER entity for
>>> each mixer and a MEDIA_INTF_T_ALSA_CONTROL control interface
>>> entity that links to mixer entities. MEDIA_INTF_T_ALSA_CONTROL
>>> entity corresponds to the control device for the card.
>>>
>>> Signed-off-by: Shuah Khan 
>>> ---
>>>   sound/usb/card.c |  5 +++
>>>   sound/usb/media.c| 89
>>> 
>>>   sound/usb/media.h| 20 
>>>   sound/usb/mixer.h|  1 +
>>>   sound/usb/usbaudio.h |  1 +
>>>   5 files changed, 116 insertions(+)
>>>
>>> diff --git a/sound/usb/card.c b/sound/usb/card.c
>>> index 469d2bf..d004cb4 100644
>>> --- a/sound/usb/card.c
>>> +++ b/sound/usb/card.c
>>> @@ -560,6 +560,9 @@ static int usb_audio_probe(struct usb_interface
>>> *intf,
>>>   if (err < 0)
>>>   goto __error;
>>>
>>> +/* Create media entities for mixer and control dev */
>>> +media_mixer_init(chip);
>>> +
>>>   usb_chip[chip->index] = chip;
>>>   chip->num_interfaces++;
>>>   chip->probing = 0;
>>> @@ -616,6 +619,8 @@ static void usb_audio_disconnect(struct
>>> usb_interface *intf)
>>>   list_for_each(p, >midi_list) {
>>>   snd_usbmidi_disconnect(p);
>>>   }
>>> +/* delete mixer media resources */
>>> +media_mixer_delete(chip);
>>>   /* release mixer resources */
>>>   list_for_each_entry(mixer, >mixer_list, list) {
>>>   snd_usb_mixer_disconnect(mixer);
>>> diff --git a/sound/usb/media.c b/sound/usb/media.c
>>> index 0cbfee6..a26ea8b 100644
>>> --- a/sound/usb/media.c
>>> +++ b/sound/usb/media.c
>>> @@ -199,4 +199,93 @@ void media_stop_pipeline(struct
>>> snd_usb_substream *subs)
>>>   if (mctl)
>>>   media_disable_source(mctl);
>>>   }
>>> +
>>> +int media_mixer_init(struct snd_usb_audio *chip)
>>> +{
>>> +struct device *ctl_dev = >card->ctl_dev;
>>> +struct media_intf_devnode *ctl_intf;
>>> +struct usb_mixer_interface *mixer;
>>> +struct media_device *mdev;
>>> +struct media_mixer_ctl *mctl;
>>> +u32 intf_type = MEDIA_INTF_T_ALSA_CONTROL;
>>> +int ret;
>>> +
>>> +mdev = media_device_find_devres(>dev->dev);
>>> +if (!mdev)
>>> +return -ENODEV;
>>> +
>>> +ctl_intf = (struct media_intf_devnode *)
>>> chip->ctl_intf_media_devnode;
>>
>> Why do we need cast?  Can't chip->ctl_intf_media_devnode itself be
>> struct media_intf_devndoe pointer?
> 
> Yeah. There is no need to cast here. I will fix it.

Sorry I misspoke. The reason for this cast is ctl_intf_media_devnode
is void to avoid including media.h and other media files in usbaudio.h

The same approach I took for card.h when adding media_ctl to
struct snd_usb_substream

Does this sound reasonable or would you rather see these to be
their respective struct pointers which would require including
media.h in these headers?

thanks,
-- Shuah

-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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 MC Next Gen v2 2/3] sound/usb: Create media mixer function and control interface entities

[Takashi Iwai]

On Tue, 03 Nov 2015 17:06:45 +0100,
Shuah Khan wrote:
> 
> On 10/25/2015 03:37 PM, Shuah Khan wrote:
> > On 10/22/2015 01:16 AM, Takashi Iwai wrote:
> >> On Wed, 21 Oct 2015 01:25:15 +0200,
> >> Shuah Khan wrote:
> >>>
> >>> Add support for creating MEDIA_ENT_F_AUDIO_MIXER entity for
> >>> each mixer and a MEDIA_INTF_T_ALSA_CONTROL control interface
> >>> entity that links to mixer entities. MEDIA_INTF_T_ALSA_CONTROL
> >>> entity corresponds to the control device for the card.
> >>>
> >>> Signed-off-by: Shuah Khan 
> >>> ---
> >>>   sound/usb/card.c |  5 +++
> >>>   sound/usb/media.c| 89
> >>> 
> >>>   sound/usb/media.h| 20 
> >>>   sound/usb/mixer.h|  1 +
> >>>   sound/usb/usbaudio.h |  1 +
> >>>   5 files changed, 116 insertions(+)
> >>>
> >>> diff --git a/sound/usb/card.c b/sound/usb/card.c
> >>> index 469d2bf..d004cb4 100644
> >>> --- a/sound/usb/card.c
> >>> +++ b/sound/usb/card.c
> >>> @@ -560,6 +560,9 @@ static int usb_audio_probe(struct usb_interface
> >>> *intf,
> >>>   if (err < 0)
> >>>   goto __error;
> >>>
> >>> +/* Create media entities for mixer and control dev */
> >>> +media_mixer_init(chip);
> >>> +
> >>>   usb_chip[chip->index] = chip;
> >>>   chip->num_interfaces++;
> >>>   chip->probing = 0;
> >>> @@ -616,6 +619,8 @@ static void usb_audio_disconnect(struct
> >>> usb_interface *intf)
> >>>   list_for_each(p, >midi_list) {
> >>>   snd_usbmidi_disconnect(p);
> >>>   }
> >>> +/* delete mixer media resources */
> >>> +media_mixer_delete(chip);
> >>>   /* release mixer resources */
> >>>   list_for_each_entry(mixer, >mixer_list, list) {
> >>>   snd_usb_mixer_disconnect(mixer);
> >>> diff --git a/sound/usb/media.c b/sound/usb/media.c
> >>> index 0cbfee6..a26ea8b 100644
> >>> --- a/sound/usb/media.c
> >>> +++ b/sound/usb/media.c
> >>> @@ -199,4 +199,93 @@ void media_stop_pipeline(struct
> >>> snd_usb_substream *subs)
> >>>   if (mctl)
> >>>   media_disable_source(mctl);
> >>>   }
> >>> +
> >>> +int media_mixer_init(struct snd_usb_audio *chip)
> >>> +{
> >>> +struct device *ctl_dev = >card->ctl_dev;
> >>> +struct media_intf_devnode *ctl_intf;
> >>> +struct usb_mixer_interface *mixer;
> >>> +struct media_device *mdev;
> >>> +struct media_mixer_ctl *mctl;
> >>> +u32 intf_type = MEDIA_INTF_T_ALSA_CONTROL;
> >>> +int ret;
> >>> +
> >>> +mdev = media_device_find_devres(>dev->dev);
> >>> +if (!mdev)
> >>> +return -ENODEV;
> >>> +
> >>> +ctl_intf = (struct media_intf_devnode *)
> >>> chip->ctl_intf_media_devnode;
> >>
> >> Why do we need cast?  Can't chip->ctl_intf_media_devnode itself be
> >> struct media_intf_devndoe pointer?
> > 
> > Yeah. There is no need to cast here. I will fix it.
> 
> Sorry I misspoke. The reason for this cast is ctl_intf_media_devnode
> is void to avoid including media.h and other media files in usbaudio.h

You can declare the struct without definition in each header file.
So just declare it and use it in usbaudio.h like:

struct media_intf_devnode;

struct snd_usb_audio {

struct media_intf_devnode *ctl_intf_media_devnode;


And even if you're using a void pointer there instead of the explicit
struct pointer, the cast is superfluous.  The implicit cast between a
void pointer and any other pointer is valid in plain C.


Takashi
--
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 MC Next Gen v2 2/3] sound/usb: Create media mixer function and control interface entities

[Shuah Khan]

On 11/03/2015 09:23 AM, Takashi Iwai wrote:
> On Tue, 03 Nov 2015 17:06:45 +0100,
> Shuah Khan wrote:
>>
>> On 10/25/2015 03:37 PM, Shuah Khan wrote:
>>> On 10/22/2015 01:16 AM, Takashi Iwai wrote:
 On Wed, 21 Oct 2015 01:25:15 +0200,
 Shuah Khan wrote:
>
> Add support for creating MEDIA_ENT_F_AUDIO_MIXER entity for
> each mixer and a MEDIA_INTF_T_ALSA_CONTROL control interface
> entity that links to mixer entities. MEDIA_INTF_T_ALSA_CONTROL
> entity corresponds to the control device for the card.
>
> Signed-off-by: Shuah Khan 
> ---
>   sound/usb/card.c |  5 +++
>   sound/usb/media.c| 89
> 
>   sound/usb/media.h| 20 
>   sound/usb/mixer.h|  1 +
>   sound/usb/usbaudio.h |  1 +
>   5 files changed, 116 insertions(+)
>
> diff --git a/sound/usb/card.c b/sound/usb/card.c
> index 469d2bf..d004cb4 100644
> --- a/sound/usb/card.c
> +++ b/sound/usb/card.c
> @@ -560,6 +560,9 @@ static int usb_audio_probe(struct usb_interface
> *intf,
>   if (err < 0)
>   goto __error;
>
> +/* Create media entities for mixer and control dev */
> +media_mixer_init(chip);
> +
>   usb_chip[chip->index] = chip;
>   chip->num_interfaces++;
>   chip->probing = 0;
> @@ -616,6 +619,8 @@ static void usb_audio_disconnect(struct
> usb_interface *intf)
>   list_for_each(p, >midi_list) {
>   snd_usbmidi_disconnect(p);
>   }
> +/* delete mixer media resources */
> +media_mixer_delete(chip);
>   /* release mixer resources */
>   list_for_each_entry(mixer, >mixer_list, list) {
>   snd_usb_mixer_disconnect(mixer);
> diff --git a/sound/usb/media.c b/sound/usb/media.c
> index 0cbfee6..a26ea8b 100644
> --- a/sound/usb/media.c
> +++ b/sound/usb/media.c
> @@ -199,4 +199,93 @@ void media_stop_pipeline(struct
> snd_usb_substream *subs)
>   if (mctl)
>   media_disable_source(mctl);
>   }
> +
> +int media_mixer_init(struct snd_usb_audio *chip)
> +{
> +struct device *ctl_dev = >card->ctl_dev;
> +struct media_intf_devnode *ctl_intf;
> +struct usb_mixer_interface *mixer;
> +struct media_device *mdev;
> +struct media_mixer_ctl *mctl;
> +u32 intf_type = MEDIA_INTF_T_ALSA_CONTROL;
> +int ret;
> +
> +mdev = media_device_find_devres(>dev->dev);
> +if (!mdev)
> +return -ENODEV;
> +
> +ctl_intf = (struct media_intf_devnode *)
> chip->ctl_intf_media_devnode;

 Why do we need cast?  Can't chip->ctl_intf_media_devnode itself be
 struct media_intf_devndoe pointer?
>>>
>>> Yeah. There is no need to cast here. I will fix it.
>>
>> Sorry I misspoke. The reason for this cast is ctl_intf_media_devnode
>> is void to avoid including media.h and other media files in usbaudio.h
> 
> You can declare the struct without definition in each header file.
> So just declare it and use it in usbaudio.h like:
> 
> struct media_intf_devnode;
> 
> struct snd_usb_audio {
>   
>   struct media_intf_devnode *ctl_intf_media_devnode;
>   
> 
> And even if you're using a void pointer there instead of the explicit
> struct pointer, the cast is superfluous.  The implicit cast between a
> void pointer and any other pointer is valid in plain C.
> 

Yes. cast is definitely not necessary. I will drop the cast and leave
the rest alone.

thanks,
-- Shuah


-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shua...@osg.samsung.com | (970) 217-8978
--
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