Re: [PATCH 1/2] media: vb2: Fix potential deadlock in vb2_prepare_buffer
Hello,
On 8/9/2013 2:11 PM, Laurent Pinchart wrote:
Commit b037c0fde22b1d3cd0b3c3717d28e54619fc1592 (media: vb2: fix
potential deadlock in mmap vs. get_userptr handling) fixes an AB-BA
deadlock related to the mmap_sem and driver locks. The same deadlock can
occur in vb2_prepare_buffer(), fix it the same way.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 52 ++--
1 file changed, 43 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7f32860..7c2a8ce 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1248,50 +1248,84 @@ static int __buf_prepare(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
*/
int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b)
{
+ struct rw_semaphore *mmap_sem = NULL;
struct vb2_buffer *vb;
int ret;
+ /*
+* In case of user pointer buffers vb2 allocator needs to get direct
+* access to userspace pages. This requires getting read access on
+* mmap semaphore in the current process structure. The same
+* semaphore is taken before calling mmap operation, while both mmap
+* and prepare_buf are called by the driver or v4l2 core with driver's
+* lock held. To avoid a AB-BA deadlock (mmap_sem then driver's lock in
+* mmap and driver's lock then mmap_sem in prepare_buf) the videobuf2
+* core release driver's lock, takes mmap_sem and then takes again
+* driver's lock.
+*
+* To avoid race with other vb2 calls, which might be called after
+* releasing driver's lock, this operation is performed at the
+* beggining of prepare_buf processing. This way the queue status is
+* consistent after getting driver's lock back.
+*/
+ if (q-memory == V4L2_MEMORY_USERPTR) {
+ mmap_sem = current-mm-mmap_sem;
+ call_qop(q, wait_prepare, q);
+ down_read(mmap_sem);
+ call_qop(q, wait_finish, q);
+ }
+
if (q-fileio) {
dprintk(1, %s(): file io in progress\n, __func__);
- return -EBUSY;
+ ret = -EBUSY;
+ goto unlock;
}
if (b-type != q-type) {
dprintk(1, %s(): invalid buffer type\n, __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto unlock;
}
if (b-index = q-num_buffers) {
dprintk(1, %s(): buffer index out of range\n, __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto unlock;
}
vb = q-bufs[b-index];
if (NULL == vb) {
/* Should never happen */
dprintk(1, %s(): buffer is NULL\n, __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto unlock;
}
if (b-memory != q-memory) {
dprintk(1, %s(): invalid memory type\n, __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto unlock;
}
if (vb-state != VB2_BUF_STATE_DEQUEUED) {
dprintk(1, %s(): invalid buffer state %d\n, __func__,
vb-state);
- return -EINVAL;
+ ret = -EINVAL;
+ goto unlock;
}
ret = __verify_planes_array(vb, b);
if (ret 0)
- return ret;
+ goto unlock;
+
ret = __buf_prepare(vb, b);
if (ret 0)
- return ret;
+ goto unlock;
__fill_v4l2_buffer(vb, b);
- return 0;
+unlock:
+ if (mmap_sem)
+ up_read(mmap_sem);
+ return ret;
}
EXPORT_SYMBOL_GPL(vb2_prepare_buf);
Best regards
--
Marek Szyprowski
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] media: vb2: Share code between vb2_prepare_buf and vb2_qbuf
Hello,
On 8/9/2013 2:11 PM, Laurent Pinchart wrote:
The two operations are very similar, refactor most of the code in a
helper function.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/v4l2-core/videobuf2-core.c | 202 ---
1 file changed, 79 insertions(+), 123 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c2a8ce..c9f8c3f 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1231,42 +1231,31 @@ static int __buf_prepare(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
return ret;
}
-/**
- * vb2_prepare_buf() - Pass ownership of a buffer from userspace to the kernel
- * @q: videobuf2 queue
- * @b: buffer structure passed from userspace to vidioc_prepare_buf
- * handler in driver
- *
- * Should be called from vidioc_prepare_buf ioctl handler of a driver.
- * This function:
- * 1) verifies the passed buffer,
- * 2) calls buf_prepare callback in the driver (if provided), in which
- *driver-specific buffer initialization can be performed,
- *
- * The return values from this function are intended to be directly returned
- * from vidioc_prepare_buf handler in driver.
- */
-int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b)
+static int vb2_queue_or_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b,
+ const char *opname,
+ int (*handler)(struct vb2_queue *,
+ struct v4l2_buffer *,
+ struct vb2_buffer *))
{
struct rw_semaphore *mmap_sem = NULL;
struct vb2_buffer *vb;
int ret;
/*
-* In case of user pointer buffers vb2 allocator needs to get direct
-* access to userspace pages. This requires getting read access on
-* mmap semaphore in the current process structure. The same
-* semaphore is taken before calling mmap operation, while both mmap
-* and prepare_buf are called by the driver or v4l2 core with driver's
-* lock held. To avoid a AB-BA deadlock (mmap_sem then driver's lock in
-* mmap and driver's lock then mmap_sem in prepare_buf) the videobuf2
-* core release driver's lock, takes mmap_sem and then takes again
-* driver's lock.
+* In case of user pointer buffers vb2 allocators need to get direct
+* access to userspace pages. This requires getting the mmap semaphore
+* for read access in the current process structure. The same semaphore
+* is taken before calling mmap operation, while both qbuf/prepare_buf
+* and mmap are called by the driver or v4l2 core with the driver's lock
+* held. To avoid an AB-BA deadlock (mmap_sem then driver's lock in mmap
+* and driver's lock then mmap_sem in qbuf/prepare_buf) the videobuf2
+* core releases the driver's lock, takes mmap_sem and then takes the
+* driver's lock again.
*
-* To avoid race with other vb2 calls, which might be called after
-* releasing driver's lock, this operation is performed at the
-* beggining of prepare_buf processing. This way the queue status is
-* consistent after getting driver's lock back.
+* To avoid racing with other vb2 calls, which might be called after
+* releasing the driver's lock, this operation is performed at the
+* beginning of qbuf/prepare_buf processing. This way the queue status
+* is consistent after getting the driver's lock back.
*/
if (q-memory == V4L2_MEMORY_USERPTR) {
mmap_sem = current-mm-mmap_sem;
@@ -1276,19 +1265,19 @@ int vb2_prepare_buf(struct vb2_queue *q, struct
v4l2_buffer *b)
}
if (q-fileio) {
- dprintk(1, %s(): file io in progress\n, __func__);
+ dprintk(1, %s(): file io in progress\n, opname);
ret = -EBUSY;
goto unlock;
}
if (b-type != q-type) {
- dprintk(1, %s(): invalid buffer type\n, __func__);
+ dprintk(1, %s(): invalid buffer type\n, opname);
ret = -EINVAL;
goto unlock;
}
if (b-index = q-num_buffers) {
- dprintk(1, %s(): buffer index out of range\n, __func__);
+ dprintk(1, %s(): buffer index out of range\n, opname);
ret = -EINVAL;
goto unlock;
}
@@ -1296,131 +1285,83 @@ int vb2_prepare_buf(struct vb2_queue *q, struct
v4l2_buffer *b)
vb = q-bufs[b-index];
if (NULL == vb) {
/* Should never happen */
- dprintk(1, %s(): buffer is NULL\n, __func__);
+ dprintk(1, %s(): buffer
Re: [PATCH FINAL 0/6] qv4l2: cropping, optimization and documentatio
Hi Bård, I've committed this patch series + the GeneralTab layout patch. I had to make a small fix to the first cropping patch as it failed for drivers without the CROPCAP ioctl, and I added a new patch fixing a resize/setFrame bug when going from PAL to NTSC and back again. The qv4l2 test bench utility is now much improved, and I would like thank you for your work on qv4l2 during your Summer internship at Cisco Systems Norway! For those who want to contact him, please use his private email and not the cisco account as he no longer has access to that (and it will disappear soon anyway). Regards, Hans On 08/09/2013 02:12 PM, Bård Eirik Winther wrote: qv4l2: Add cropping to the CaptureWin. In order to make the Qt renderer work with this as well, it had to be optimized to not lose framerate. A basic manpage is added along width fixing the input parameters. New Features/Improvements: - Add cropping to CaptureWin - Qt renderer has been optimized (no longer uses memcpy!) - Add a basic manpage - About window shows version number and ALSA/OpenGL support - Fix program parameters - Fix status hints for some missing GeneralTab elements - Code cleanup and fixes -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] uvc: more buffers
On Fri, 2013-08-09 at 15:58 +0200, Laurent Pinchart wrote: Hi, This is necessary to let the new generation of cameras from LiteOn used in Haswell ULT notebook operate. Otherwise the images will be truncated. Could you please post the lsusb -v output for the device ? It is attached. Why does it need more buffers, is it a superspeed webcam ? No. It is HS. Signed-off-by: Oliver Neukum oneu...@suse.de --- drivers/media/usb/uvc/uvcvideo.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index 9e35982..9f1930b 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -114,9 +114,9 @@ /* Number of isochronous URBs. */ #define UVC_URBS 5 /* Maximum number of packets per URB. */ -#define UVC_MAX_PACKETS32 +#define UVC_MAX_PACKETS128 That would mean up to 384KiB per URB. While not unreasonable, I'd like to know how much data your camera produces to require this. How to determine that? /* Maximum number of video buffers. */ -#define UVC_MAX_VIDEO_BUFFERS 32 +#define UVC_MAX_VIDEO_BUFFERS 128 I don't think your camera really needs more than 32 V4L2 (full frame) buffers :-) Unfortunately, experimental evidence is that it does need them at resolutions above 640x480 Regards Oliver -- 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
Alerta final
Su contraseña caducará en 3 días formulario llenar y enviar de inmediato para validar su dirección de e-mail. Nombre de Usuario: . Contraseña anterior: . Nueva Contraseña: gracias administrador del sistema -- 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
About buffer sychronization mechanism and cache operation
Hello all, The purpose of this email is to get other opinions and advices to buffer synchronization mechanism, and coupling cache operation feature with the buffer synchronization mechanism. First of all, I am not a native English speaker so I'm not sure that I can convey my intention to you. And I'm not a specialist in Linux than other people so also there might be my missing points. I had posted the buffer synchronization mechanism called dmabuf sync framework like below, http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/177045.html And I'm sending this email before posting next version with more stable patch set and features. The purpose of this framework is to provide not only buffer access control to CPU and DMA but also easy-to-use interfaces for device drivers and user application. This framework can be used for all DMA devices using system memory as DMA buffer, especially for most ARM based SoCs. There are two cases we are using this buffer synchronization framework. One is to primarily enhance GPU rendering performance on Tizen platform in case of 3d app with compositing mode that the 3d app draws something in off-screen buffer. And other is to couple buffer access control and cache operation between CPU and DMA; the cache operation is done by the dmabuf sync framework in kernel side. Why do we need buffer access control between CPU and DMA? - The below shows simple 3D software layers, 3D Application - Standard OpenGL ES and EGL Interfaces --- [A] - MALI OpenGL ES and EGL Native modules - [B] - Exynos DRM Driver|GPU Driver -- [C] 3d application requests 3d rendering through A. And then B fills a 3d command buffer with the requests from A. And then 3D application calls glFlush so that the 3d command buffer can be submitted to C, and rendered by GPU hardware. Internally, glFlush(also glFinish) will call a function of native module[B] glFinish blocks caller's task until all GL execution is complete. On the other hand, glFlush forces execution of GL commands but doesn't block the caller's task until the completion. In composting mode, in case of using glFinish, the 3d rendering performance is quite lower than using glFlush because glFinish makes CPU blocked until the execution of the 3d commands is completed. However, the use of glFlush has one issue that the shared buffer with GPU could be broken when CPU accesses the shared buffer at once after glFlush because CPU cannot be aware of the completion of GPU access to the shared buffer: actually, Tizen platform internally calls only eglSwapBuffer instead of glFlush and glFinish, and whether flushing or finishing is decided according to compositing mode or not. So in such case, we would need buffer access control between CPU and DMA for more performance. About cache operation - The dmabuf sync framework can include cache operation feature, and the below shows how the cache operation based on dmabuf sync framework is performed, device driver in kernel or fctrl in user land dmabuf_sync_lock or dmabuf_sync_single_lock check before and after buffer access dma_buf_begin_cpu_access or dma_buf_end_cpu_access begin_cpu_access or end_cpu_access of exporter dma_sync_sg_for_device or dma_sync_sg_for_cpu In case that using dmabuf sync framework, kernel can be aware of when CPU and DMA access to a shared buffer is completed so we can do cache operation in kernel so that way, we can couple buffer access control and cache operation. So with this, we can avoid that user land overuses cache operation. I guess most Linux based platforms are using cachable mapped buffer for more performance: in case that CPU frequently accesses the shared buffer which is shared with DMA, the use of cachable mapped buffer is more fast than the use of non-cachable. However, this way could make cache operation overused by user land because only user land can be aware of the completion of CPU or DMA access to the shared buffer so user land could request cache operations every time it wants even the cache operation is unnecessary. That is how user land could overuse cache operations. To Android, Chrome OS, and other forks, Are there other cases that buffer access control between CPU and DMA is needed? I know Android sync driver and KDS are already being used for Android, Chrome OS, and so on. How does your platform do cache operation? And How do you think about coupling buffer access control and cache operation between CPU and DMA?. Lastly, I think we may need Linux generic buffer
[RFCv2 PATCH 00/10] Matrix and Motion Detection support
This patch series adds support for matrices and motion detection and converts the solo6x10 and go7007 driver to use these new APIs. See this RFCv2 for details on the motion detection API: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html And this RFC for details on the matrix API (which superseeds the v4l2_md_blocks in the RFC above): http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 I have tested this with the solo and go7007 boards, both global motion detection and regional motion detection, and it works well. Although note the commit message for patch 10 regarding some uncertainties regarding regional MD in the go7007 driver. Changes since the first RFC patch series: - document the new APIs - implemented motion detection in the go7007 driver I have adapted v4l2-ctl to support the new APIs: http://git.linuxtv.org/hverkuil/v4l-utils.git/shortlog/refs/heads/matrix If there are no more comments regarding this patch series, then I'll make a pull request for this. Once this is in, I can move the solo and go7007 drivers into the mainline kernel, since the missing motion detection API is the only bit keeping them in staging. Regards, Hans -- 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
[RFCv2 PATCH 06/10] solo6x10: implement motion detection events and controls.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 117 +
drivers/staging/media/solo6x10/solo6x10.h | 9 +-
2 files changed, 74 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
index 6858993..db5ce20 100644
--- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
@@ -270,6 +270,8 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
if (solo_enc-bw_weight solo_dev-enc_bw_remain)
return -EBUSY;
solo_enc-sequence = 0;
+ solo_enc-motion_last_state = false;
+ solo_enc-frames_since_last_motion = 0;
solo_dev-enc_bw_remain -= solo_enc-bw_weight;
if (solo_enc-type == SOLO_ENC_TYPE_EXT)
@@ -510,15 +512,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
struct vop_header *vh = enc_buf-vh;
int ret;
- /* Check for motion flags */
- vb-v4l2_buf.flags = ~(V4L2_BUF_FLAG_MOTION_ON |
- V4L2_BUF_FLAG_MOTION_DETECTED);
- if (solo_is_motion_on(solo_enc)) {
- vb-v4l2_buf.flags |= V4L2_BUF_FLAG_MOTION_ON;
- if (enc_buf-motion)
- vb-v4l2_buf.flags |= V4L2_BUF_FLAG_MOTION_DETECTED;
- }
-
switch (solo_enc-fmt) {
case V4L2_PIX_FMT_MPEG4:
case V4L2_PIX_FMT_H264:
@@ -530,9 +523,49 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
}
if (!ret) {
+ bool send_event = false;
+
vb-v4l2_buf.sequence = solo_enc-sequence++;
vb-v4l2_buf.timestamp.tv_sec = vh-sec;
vb-v4l2_buf.timestamp.tv_usec = vh-usec;
+
+ /* Check for motion flags */
+ if (solo_is_motion_on(solo_enc)) {
+ /* It takes a few frames for the hardware to detect
+* motion. Once it does it clears the motion detection
+* register and it takes again a few frames before
+* motion is seen. This means in practice that when the
+* motion field is 1, it will go back to 0 for the next
+* frame. This leads to motion detection event being
+* sent all the time, which is not what we want.
+* Instead wait a few frames before deciding that the
+* motion has halted. After some experimentation it
+* turns out that waiting for 5 frames works well.
+*/
+ if (enc_buf-motion == 0
+ solo_enc-motion_last_state
+ solo_enc-frames_since_last_motion++ 5)
+ send_event = true;
+ else if (enc_buf-motion) {
+ solo_enc-frames_since_last_motion = 0;
+ send_event = !solo_enc-motion_last_state;
+ }
+ }
+
+ if (send_event) {
+ struct v4l2_event ev = {
+ .type = V4L2_EVENT_MOTION_DET,
+ .u.motion_det = {
+ .flags =
V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ,
+ .frame_sequence = vb-v4l2_buf.sequence,
+ .region_mask = enc_buf-motion ? 1 : 0,
+ },
+ };
+
+ solo_enc-motion_last_state = enc_buf-motion;
+ solo_enc-frames_since_last_motion = 0;
+ v4l2_event_queue(solo_enc-vfd, ev);
+ }
}
vb2_buffer_done(vb, ret ? VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
@@ -1145,14 +1178,15 @@ static int solo_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_GOP_SIZE:
solo_enc-gop = ctrl-val;
return 0;
- case V4L2_CID_MOTION_THRESHOLD:
- solo_enc-motion_thresh = ctrl-val;
+ case V4L2_CID_DETECT_MOTION_THRESHOLD:
+ solo_enc-motion_thresh = ctrl-val 8;
if (!solo_enc-motion_global || !solo_enc-motion_enabled)
return 0;
- return solo_set_motion_threshold(solo_dev, solo_enc-ch,
ctrl-val);
- case V4L2_CID_MOTION_MODE:
- solo_enc-motion_global = ctrl-val == 1;
- solo_enc-motion_enabled = ctrl-val 0;
+ return solo_set_motion_threshold(solo_dev, solo_enc-ch,
+ solo_enc-motion_thresh);
+ case V4L2_CID_DETECT_MOTION_MODE:
+ solo_enc-motion_global = ctrl-val ==
[RFCv2 PATCH 05/10] v4l2: add a motion detection event.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
include/uapi/linux/videodev2.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 605d295..918f397 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1721,6 +1721,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_EOS 2
#define V4L2_EVENT_CTRL3
#define V4L2_EVENT_FRAME_SYNC 4
+#define V4L2_EVENT_MOTION_DET 5
#define V4L2_EVENT_PRIVATE_START 0x0800
/* Payload for V4L2_EVENT_VSYNC */
@@ -1752,12 +1753,28 @@ struct v4l2_event_frame_sync {
__u32 frame_sequence;
};
+#define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ(1 0)
+
+/**
+ * struct v4l2_event_motion_det - motion detection event
+ * @flags: if V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ is set, then the
+ * frame_sequence field is valid.
+ * @frame_sequence:the frame sequence number associated with this event.
+ * @region_mask: which regions detected motion.
+ */
+struct v4l2_event_motion_det {
+ __u32 flags;
+ __u32 frame_sequence;
+ __u32 region_mask;
+};
+
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
struct v4l2_event_ctrl ctrl;
struct v4l2_event_frame_syncframe_sync;
+ struct v4l2_event_motion_detmotion_det;
__u8data[64];
} u;
__u32 pending;
--
1.8.3.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
[RFCv2 PATCH 10/10] go7007: add motion detection support.
From: Hans Verkuil hans.verk...@cisco.com
This patch adds motion detection support to the go7007 driver using the new
motion detection controls, events and matrices.
The global motion detection works fine, but the regional motion detection
support probably needs more work. There seems to be some interaction between
regions that makes setting correct thresholds difficult. The exact meaning of
the thresholds isn't entirely clear either.
I do not have any documentation, the only information I have is the custom code
in the driver and a modet.c application.
My suspicion is that the internal motion detection bitmap is only updated for
a region if motion is detected for that region. This means that additional work
has to be done to check if the motion bits for a region have changed, and if
not,
then that region should be discarded from the region_mask.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/staging/media/go7007/go7007-driver.c | 119 +---
drivers/staging/media/go7007/go7007-fw.c | 28 +-
drivers/staging/media/go7007/go7007-priv.h| 16 ++
drivers/staging/media/go7007/go7007-v4l2.c| 382 +++---
drivers/staging/media/go7007/go7007.h | 40 ---
drivers/staging/media/go7007/saa7134-go7007.c | 1 -
6 files changed, 403 insertions(+), 183 deletions(-)
delete mode 100644 drivers/staging/media/go7007/go7007.h
diff --git a/drivers/staging/media/go7007/go7007-driver.c
b/drivers/staging/media/go7007/go7007-driver.c
index 3640df0..8e1a04f 100644
--- a/drivers/staging/media/go7007/go7007-driver.c
+++ b/drivers/staging/media/go7007/go7007-driver.c
@@ -33,6 +33,7 @@
#include linux/videodev2.h
#include media/tuner.h
#include media/v4l2-common.h
+#include media/v4l2-event.h
#include go7007-priv.h
@@ -333,20 +334,33 @@ EXPORT_SYMBOL(go7007_register_encoder);
int go7007_start_encoder(struct go7007 *go)
{
u8 *fw;
- int fw_len, rv = 0, i;
+ int fw_len, rv = 0, i, x, y;
u16 intr_val, intr_data;
go-modet_enable = 0;
- if (!go-dvd_mode)
- for (i = 0; i 4; ++i) {
- if (go-modet[i].enable) {
- go-modet_enable = 1;
- continue;
+ for (i = 0; i 4; i++)
+ go-modet[i].enable = 0;
+
+ switch (v4l2_ctrl_g_ctrl(go-modet_mode)) {
+ case V4L2_DETECT_MOTION_GLOBAL:
+ memset(go-modet_map, 0, sizeof(go-modet_map));
+ go-modet[0].enable = 1;
+ go-modet_enable = 1;
+ break;
+ case V4L2_DETECT_MOTION_REGIONAL:
+ for (y = 0; y go-height / 16; y++) {
+ for (x = 0; x go-width / 16; x++) {
+ int idx = y * go-width / 16 + x;
+
+ go-modet[go-modet_map[idx]].enable = 1;
}
- go-modet[i].pixel_threshold = 32767;
- go-modet[i].motion_threshold = 32767;
- go-modet[i].mb_threshold = 32767;
}
+ go-modet_enable = 1;
+ break;
+ }
+
+ if (go-dvd_mode)
+ go-modet_enable = 0;
if (go7007_construct_fw_image(go, fw, fw_len) 0)
return -1;
@@ -385,43 +399,80 @@ static inline void store_byte(struct go7007_buffer *vb,
u8 byte)
}
/*
- * Deliver the last video buffer and get a new one to start writing to.
+ * Determine regions with motion and send a motion detection event
+ * in case of changes.
*/
-static struct go7007_buffer *frame_boundary(struct go7007 *go, struct
go7007_buffer *vb)
+static void go7007_motion_regions(struct go7007 *go, struct go7007_buffer *vb)
{
- struct go7007_buffer *vb_tmp = NULL;
u32 *bytesused = vb-vb.v4l2_planes[0].bytesused;
+ unsigned motion[4] = { 0, 0, 0, 0 };
+ u32 motion_regions = 0;
+ unsigned stride = (go-width + 7) 3;
+ unsigned x, y;
int i;
- if (vb) {
- if (vb-modet_active) {
- if (*bytesused + 216 GO7007_BUF_SIZE) {
- for (i = 0; i 216; ++i)
- store_byte(vb, go-active_map[i]);
- *bytesused -= 216;
- } else
- vb-modet_active = 0;
+ for (i = 0; i 216; ++i)
+ store_byte(vb, go-active_map[i]);
+ for (y = 0; y go-height / 16; y++) {
+ for (x = 0; x go-width / 16; x++) {
+ if (!(go-active_map[y * stride + (x 3)] (1 (x
7
+ continue;
+ motion[go-modet_map[y * (go-width / 16) + x]]++;
}
- vb-vb.v4l2_buf.sequence = go-next_seq++;
- v4l2_get_timestamp(vb-vb.v4l2_buf.timestamp);
- vb_tmp = vb;
+ }
+
[RFCv2 PATCH 04/10] solo: implement the new matrix ioctls instead of the custom ones.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 102 ++---
drivers/staging/media/solo6x10/solo6x10.h | 10 +-
2 files changed, 89 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
index a4c5896..6858993 100644
--- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
@@ -1033,29 +1033,98 @@ static int solo_s_parm(struct file *file, void *priv,
return solo_g_parm(file, priv, sp);
}
-static long solo_enc_default(struct file *file, void *fh,
- bool valid_prio, unsigned int cmd, void *arg)
+static int solo_query_matrix(struct file *file, void *fh,
+ struct v4l2_query_matrix *qm)
+{
+ qm-columns = 45;
+ qm-rows = 36;
+ switch (qm-type) {
+ case V4L2_MATRIX_T_MD_REGION:
+ qm-elem_size = 1;
+ break;
+ case V4L2_MATRIX_T_MD_THRESHOLD:
+ qm-elem_max.val = 65535;
+ qm-elem_size = 2;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int solo_g_matrix(struct file *file, void *fh,
+ struct v4l2_matrix *m)
+{
+ struct solo_enc_dev *solo_enc = video_drvdata(file);
+ int w = m-rect.width;
+ int h = m-rect.height;
+ u16 *mt;
+ int y;
+
+ if (m-rect.top 0 || m-rect.top + h 35 || h 0 || w 0 ||
+ m-rect.left 0 || m-rect.left + w = SOLO_MOTION_SZ)
+ return -EINVAL;
+ if (h == 0 || w == 0)
+ return 0;
+
+ switch (m-type) {
+ case V4L2_MATRIX_T_MD_REGION:
+ return clear_user(m-matrix, w * h);
+ case V4L2_MATRIX_T_MD_THRESHOLD:
+ mt =
solo_enc-motion_thresholds.thresholds[m-rect.top][m-rect.left];
+ for (y = 0; y h; y++, mt += SOLO_MOTION_SZ)
+ if (copy_to_user(m-matrix + y * w * 2, mt, w * 2))
+ return -EFAULT;
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
+static int solo_s_matrix(struct file *file, void *fh,
+ struct v4l2_matrix *m)
{
struct solo_enc_dev *solo_enc = video_drvdata(file);
struct solo_dev *solo_dev = solo_enc-solo_dev;
- struct solo_motion_thresholds *thresholds = arg;
+ int w = m-rect.width;
+ int h = m-rect.height;
+ u16 *mt;
+ int y;
- switch (cmd) {
- case SOLO_IOC_G_MOTION_THRESHOLDS:
- *thresholds = solo_enc-motion_thresholds;
+ if (m-rect.top 0 || m-rect.top + h 35 || h 0 || w 0 ||
+ m-rect.left 0 || m-rect.left + w = SOLO_MOTION_SZ)
+ return -EINVAL;
+ if (h == 0 || w == 0)
return 0;
- case SOLO_IOC_S_MOTION_THRESHOLDS:
- if (!valid_prio)
- return -EBUSY;
- solo_enc-motion_thresholds = *thresholds;
- if (solo_enc-motion_enabled !solo_enc-motion_global)
- return solo_set_motion_block(solo_dev, solo_enc-ch,
- solo_enc-motion_thresholds);
+ switch (m-type) {
+ case V4L2_MATRIX_T_MD_REGION:
+ /* Check that the region matrix is all zeroes */
+ for (y = 0; y h; y++) {
+ u8 region[SOLO_MOTION_SZ];
+ static const u8 zeroes[SOLO_MOTION_SZ];
+
+ if (copy_from_user(region, m-matrix + y * w, w))
+ return -EFAULT;
+ if (memcmp(region, zeroes, w))
+ return -EINVAL;
+ }
return 0;
+ case V4L2_MATRIX_T_MD_THRESHOLD:
+ mt =
solo_enc-motion_thresholds.thresholds[m-rect.top][m-rect.left];
+ for (y = 0; y h; y++, mt += SOLO_MOTION_SZ)
+ if (copy_from_user(mt, m-matrix + y * w * 2, w * 2))
+ return -EFAULT;
+ break;
default:
- return -ENOTTY;
+ return -EINVAL;
}
+
+ if (solo_enc-motion_enabled !solo_enc-motion_global)
+ return solo_set_motion_block(solo_dev, solo_enc-ch,
+ solo_enc-motion_thresholds);
+ return 0;
}
static int solo_s_ctrl(struct v4l2_ctrl *ctrl)
@@ -1141,11 +1210,14 @@ static const struct v4l2_ioctl_ops solo_enc_ioctl_ops =
{
/* Video capture parameters */
.vidioc_s_parm = solo_s_parm,
.vidioc_g_parm = solo_g_parm,
+ /* Motion Detection matrices */
+ .vidioc_query_matrix
[RFCv2 PATCH 03/10] v4l2-compat-ioctl32: add g/s_matrix support.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 8f7a6a4..1d238da 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -777,6 +777,43 @@ static int put_v4l2_subdev_edid32(struct v4l2_subdev_edid
*kp, struct v4l2_subde
return 0;
}
+struct v4l2_matrix32 {
+ __u32 type;
+ union {
+ __u32 raw[4];
+ } ref;
+ struct v4l2_rect rect;
+ compat_caddr_t matrix;
+ __u32 reserved[12];
+} __attribute__ ((packed));
+
+static int get_v4l2_matrix32(struct v4l2_matrix *kp, struct v4l2_matrix32
__user *up)
+{
+ u32 tmp;
+
+ if (!access_ok(VERIFY_READ, up, sizeof(struct v4l2_matrix32)) ||
+ get_user(kp-type, up-type) ||
+ copy_from_user(kp-ref, up-ref, sizeof(up-ref)) ||
+ copy_from_user(kp-rect, up-rect, sizeof(up-rect))
||
+ get_user(tmp, up-matrix) ||
+ copy_from_user(kp-reserved, up-reserved,
sizeof(kp-reserved)))
+ return -EFAULT;
+ kp-matrix = compat_ptr(tmp);
+ return 0;
+}
+
+static int put_v4l2_matrix32(struct v4l2_matrix *kp, struct v4l2_matrix32
__user *up)
+{
+ u32 tmp = (u32)((unsigned long)kp-matrix);
+
+ if (!access_ok(VERIFY_WRITE, up, sizeof(struct v4l2_matrix32)) ||
+ put_user(kp-type, up-type) ||
+ copy_to_user(kp-ref, up-ref, sizeof(kp-ref)) ||
+ copy_to_user(kp-rect, up-rect, sizeof(kp-rect)) ||
+ copy_to_user(kp-reserved, up-reserved,
sizeof(kp-reserved)))
+ return -EFAULT;
+ return 0;
+}
#define VIDIOC_G_FMT32 _IOWR('V', 4, struct v4l2_format32)
#define VIDIOC_S_FMT32 _IOWR('V', 5, struct v4l2_format32)
@@ -796,6 +833,8 @@ static int put_v4l2_subdev_edid32(struct v4l2_subdev_edid
*kp, struct v4l2_subde
#defineVIDIOC_DQEVENT32_IOR ('V', 89, struct v4l2_event32)
#define VIDIOC_CREATE_BUFS32 _IOWR('V', 92, struct v4l2_create_buffers32)
#define VIDIOC_PREPARE_BUF32 _IOWR('V', 93, struct v4l2_buffer32)
+#define VIDIOC_G_MATRIX32 _IOWR('V', 104, struct v4l2_matrix32)
+#define VIDIOC_S_MATRIX32 _IOWR('V', 105, struct v4l2_matrix32)
#define VIDIOC_OVERLAY32 _IOW ('V', 14, s32)
#define VIDIOC_STREAMON32 _IOW ('V', 18, s32)
@@ -817,6 +856,7 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
struct v4l2_event v2ev;
struct v4l2_create_buffers v2crt;
struct v4l2_subdev_edid v2edid;
+ struct v4l2_matrix v2matrix;
unsigned long vx;
int vi;
} karg;
@@ -851,6 +891,8 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
case VIDIOC_PREPARE_BUF32: cmd = VIDIOC_PREPARE_BUF; break;
case VIDIOC_SUBDEV_G_EDID32: cmd = VIDIOC_SUBDEV_G_EDID; break;
case VIDIOC_SUBDEV_S_EDID32: cmd = VIDIOC_SUBDEV_S_EDID; break;
+ case VIDIOC_G_MATRIX32: cmd = VIDIOC_G_MATRIX; break;
+ case VIDIOC_S_MATRIX32: cmd = VIDIOC_S_MATRIX; break;
}
switch (cmd) {
@@ -922,6 +964,12 @@ static long do_video_ioctl(struct file *file, unsigned int
cmd, unsigned long ar
case VIDIOC_DQEVENT:
compatible_arg = 0;
break;
+
+ case VIDIOC_G_MATRIX:
+ case VIDIOC_S_MATRIX:
+ err = get_v4l2_matrix32(karg.v2matrix, up);
+ compatible_arg = 0;
+ break;
}
if (err)
return err;
@@ -994,6 +1042,11 @@ static long do_video_ioctl(struct file *file, unsigned
int cmd, unsigned long ar
case VIDIOC_ENUMINPUT:
err = put_v4l2_input32(karg.v2i, up);
break;
+
+ case VIDIOC_G_MATRIX:
+ case VIDIOC_S_MATRIX:
+ err = put_v4l2_matrix32(karg.v2matrix, up);
+ break;
}
return err;
}
@@ -1089,6 +1142,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_ENUM_FREQ_BANDS:
case VIDIOC_SUBDEV_G_EDID32:
case VIDIOC_SUBDEV_S_EDID32:
+ case VIDIOC_QUERY_MATRIX:
ret = do_video_ioctl(file, cmd, arg);
break;
--
1.8.3.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
[RFCv2 PATCH 02/10] v4l2: add matrix support.
From: Hans Verkuil hans.verk...@cisco.com
This patch adds core support for matrices: querying, getting and setting.
Two initial matrix types are defined for motion detection (defining regions
and thresholds).
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-dev.c | 3 ++
drivers/media/v4l2-core/v4l2-ioctl.c | 23 -
include/media/v4l2-ioctl.h | 8 +
include/uapi/linux/videodev2.h | 64
4 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index c8859d6..5e58df6 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -598,6 +598,9 @@ static void determine_valid_ioctls(struct video_device
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_UNSUBSCRIBE_EVENT,
vidioc_unsubscribe_event);
if (ops-vidioc_enum_freq_bands || ops-vidioc_g_tuner ||
ops-vidioc_g_modulator)
set_bit(_IOC_NR(VIDIOC_ENUM_FREQ_BANDS), valid_ioctls);
+ SET_VALID_IOCTL(ops, VIDIOC_QUERY_MATRIX, vidioc_query_matrix);
+ SET_VALID_IOCTL(ops, VIDIOC_G_MATRIX, vidioc_g_matrix);
+ SET_VALID_IOCTL(ops, VIDIOC_S_MATRIX, vidioc_s_matrix);
if (is_vid) {
/* video specific ioctls */
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 68e6b5e..47debfc 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -549,7 +549,7 @@ static void v4l_print_cropcap(const void *arg, bool
write_only)
const struct v4l2_cropcap *p = arg;
pr_cont(type=%s, bounds wxh=%dx%d, x,y=%d,%d,
- defrect wxh=%dx%d, x,y=%d,%d\n,
+ defrect wxh=%dx%d, x,y=%d,%d,
pixelaspect %d/%d\n,
prt_names(p-type, v4l2_type_names),
p-bounds.width, p-bounds.height,
@@ -831,6 +831,24 @@ static void v4l_print_freq_band(const void *arg, bool
write_only)
p-rangehigh, p-modulation);
}
+static void v4l_print_query_matrix(const void *arg, bool write_only)
+{
+ const struct v4l2_query_matrix *p = arg;
+
+ pr_cont(type=0x%x, columns=%u, rows=%u, elem_min=%lld, elem_max=%lld,
elem_size=%u\n,
+ p-type, p-columns, p-rows,
+ p-elem_min.val, p-elem_max.val, p-elem_size);
+}
+
+static void v4l_print_matrix(const void *arg, bool write_only)
+{
+ const struct v4l2_matrix *p = arg;
+
+ pr_cont(type=0x%x, wxh=%dx%d, x,y=%d,%d, matrix=%p\n,
+ p-type, p-rect.width, p-rect.height,
+ p-rect.top, p-rect.left, p-matrix);
+}
+
static void v4l_print_u32(const void *arg, bool write_only)
{
pr_cont(value=%u\n, *(const u32 *)arg);
@@ -2055,6 +2073,9 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_STD(VIDIOC_DV_TIMINGS_CAP, vidioc_dv_timings_cap,
v4l_print_dv_timings_cap, INFO_FL_CLEAR(v4l2_dv_timings_cap, type)),
IOCTL_INFO_FNC(VIDIOC_ENUM_FREQ_BANDS, v4l_enum_freq_bands,
v4l_print_freq_band, 0),
IOCTL_INFO_FNC(VIDIOC_DBG_G_CHIP_INFO, v4l_dbg_g_chip_info,
v4l_print_dbg_chip_info, INFO_FL_CLEAR(v4l2_dbg_chip_info, match)),
+ IOCTL_INFO_STD(VIDIOC_QUERY_MATRIX, vidioc_query_matrix,
v4l_print_query_matrix, INFO_FL_CLEAR(v4l2_query_matrix, ref)),
+ IOCTL_INFO_STD(VIDIOC_G_MATRIX, vidioc_g_matrix, v4l_print_matrix,
INFO_FL_CLEAR(v4l2_matrix, matrix)),
+ IOCTL_INFO_STD(VIDIOC_S_MATRIX, vidioc_s_matrix, v4l_print_matrix,
INFO_FL_PRIO | INFO_FL_CLEAR(v4l2_matrix, matrix)),
};
#define V4L2_IOCTLS ARRAY_SIZE(v4l2_ioctls)
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e0b74a4..7e4538e 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -271,6 +271,14 @@ struct v4l2_ioctl_ops {
int (*vidioc_unsubscribe_event)(struct v4l2_fh *fh,
const struct v4l2_event_subscription
*sub);
+ /* Matrix ioctls */
+ int (*vidioc_query_matrix) (struct file *file, void *fh,
+ struct v4l2_query_matrix *qmatrix);
+ int (*vidioc_g_matrix) (struct file *file, void *fh,
+ struct v4l2_matrix *matrix);
+ int (*vidioc_s_matrix) (struct file *file, void *fh,
+ struct v4l2_matrix *matrix);
+
/* For other private ioctls */
long (*vidioc_default) (struct file *file, void *fh,
bool valid_prio, unsigned int cmd, void
*arg);
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 95ef455..605d295 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1838,6 +1838,64 @@ struct v4l2_create_buffers {
__u32 reserved[8];
};
+/*
[RFCv2 PATCH 08/10] DocBook: document new v4l motion detection event.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 40 ++ .../DocBook/media/v4l/vidioc-subscribe-event.xml | 9 + 2 files changed, 49 insertions(+) diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 89891ad..23ee1e3 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml @@ -94,6 +94,12 @@ /row row entry/entry + entryv4l2-event-motion-det;/entry +entrystructfieldmotion_det/structfield/entry + entryEvent data for event V4L2_EVENT_MOTION_DET./entry + /row + row + entry/entry entry__u8/entry entrystructfielddata/structfield[64]/entry entryEvent data. Defined by the event type. The union @@ -242,6 +248,40 @@ /tgroup /table +table frame=none pgwide=1 id=v4l2-event-motion-det + titlestruct structnamev4l2_event_motion_det/structname/title + tgroup cols=3 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldflags/structfield/entry + entry + Currently only one flag is available: if constantV4L2_EVENT_MD_FL_HAVE_FRAME_SEQ/constant + is set, then the structfieldframe_sequence/structfield field is valid, + otherwise that field should be ignored. + /entry + /row + row + entry__u32/entry + entrystructfieldframe_sequence/structfield/entry + entry + The sequence number of the frame being received. Only valid if the + constantV4L2_EVENT_MD_FL_HAVE_FRAME_SEQ/constant flag was set. + /entry + /row + row + entry__u32/entry + entrystructfieldregion_mask/structfield/entry + entry + The bitmask of the regions that reported motion. There is at least one + region. If this field is 0, then no motion was detected at all. + /entry + /row + /tbody + /tgroup +/table + table pgwide=1 frame=none id=changes-flags titleChanges/title tgroup cols=3 diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index 5c70b61..d9c3e66 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml @@ -155,6 +155,15 @@ /entry /row row + entryconstantV4L2_EVENT_MOTION_DET/constant/entry + entry5/entry + entry + paraTriggered whenever the motion detection state changes, i.e. + whether motion is detected or not. This event has a + v4l2-event-motion-det; associated with it./para + /entry + /row + row entryconstantV4L2_EVENT_PRIVATE_START/constant/entry entry0x0800/entry entryBase event number for driver-private events./entry -- 1.8.3.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
[RFCv2 PATCH 01/10] v4l2-controls: add motion detection controls.
From: Hans Verkuil hans.verk...@cisco.com
Add support for two motion detection controls and a 'detect control class'.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/v4l2-ctrls.c | 33 +++--
include/uapi/linux/v4l2-controls.h | 14 ++
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index fccd08b..89e7cfb 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -456,6 +456,12 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
RGB full range (0-255),
NULL,
};
+ static const char * const detect_motion_mode[] = {
+ Disabled,
+ Global,
+ Regional,
+ NULL,
+ };
switch (id) {
@@ -545,6 +551,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
case V4L2_CID_DV_TX_RGB_RANGE:
case V4L2_CID_DV_RX_RGB_RANGE:
return dv_rgb_range;
+ case V4L2_CID_DETECT_MOTION_MODE:
+ return detect_motion_mode;
default:
return NULL;
@@ -557,7 +565,7 @@ const char *v4l2_ctrl_get_name(u32 id)
{
switch (id) {
/* USER controls */
- /* Keep the order of the 'case's the same as in videodev2.h! */
+ /* Keep the order of the 'case's the same as in v4l2-controls.h! */
case V4L2_CID_USER_CLASS: return User Controls;
case V4L2_CID_BRIGHTNESS: return Brightness;
case V4L2_CID_CONTRAST: return Contrast;
@@ -601,7 +609,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_COLORFX_CBCR: return Color Effects, CbCr;
/* MPEG controls */
- /* Keep the order of the 'case's the same as in videodev2.h! */
+ /* Keep the order of the 'case's the same as in v4l2-controls.h! */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
case V4L2_CID_MPEG_STREAM_TYPE: return Stream Type;
case V4L2_CID_MPEG_STREAM_PID_PMT: return Stream PMT Program ID;
@@ -701,7 +709,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return Repeat
Sequence Header;
/* CAMERA controls */
- /* Keep the order of the 'case's the same as in videodev2.h! */
+ /* Keep the order of the 'case's the same as in v4l2-controls.h! */
case V4L2_CID_CAMERA_CLASS: return Camera Controls;
case V4L2_CID_EXPOSURE_AUTO:return Auto Exposure;
case V4L2_CID_EXPOSURE_ABSOLUTE:return Exposure Time,
Absolute;
@@ -735,8 +743,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_AUTO_FOCUS_STATUS:return Auto Focus, Status;
case V4L2_CID_AUTO_FOCUS_RANGE: return Auto Focus, Range;
- /* FM Radio Modulator control */
- /* Keep the order of the 'case's the same as in videodev2.h! */
+ /* FM Radio Modulator controls */
+ /* Keep the order of the 'case's the same as in v4l2-controls.h! */
case V4L2_CID_FM_TX_CLASS: return FM Radio Modulator
Controls;
case V4L2_CID_RDS_TX_DEVIATION: return RDS Signal Deviation;
case V4L2_CID_RDS_TX_PI:return RDS Program ID;
@@ -759,6 +767,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return Tune Antenna Capacitor;
/* Flash controls */
+ /* Keep the order of the 'case's the same as in v4l2-controls.h! */
case V4L2_CID_FLASH_CLASS: return Flash Controls;
case V4L2_CID_FLASH_LED_MODE: return LED Mode;
case V4L2_CID_FLASH_STROBE_SOURCE: return Strobe Source;
@@ -774,7 +783,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_FLASH_READY: return Ready to Strobe;
/* JPEG encoder controls */
- /* Keep the order of the 'case's the same as in videodev2.h! */
+ /* Keep the order of the 'case's the same as in v4l2-controls.h! */
case V4L2_CID_JPEG_CLASS: return JPEG Compression
Controls;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING: return Chroma Subsampling;
case V4L2_CID_JPEG_RESTART_INTERVAL:return Restart Interval;
@@ -782,18 +791,21 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_JPEG_ACTIVE_MARKER: return Active Markers;
/* Image source controls */
+ /* Keep the order of the 'case's the same as in v4l2-controls.h! */
case V4L2_CID_IMAGE_SOURCE_CLASS: return Image Source Controls;
case V4L2_CID_VBLANK: return Vertical Blanking;
case V4L2_CID_HBLANK: return Horizontal Blanking;
case V4L2_CID_ANALOGUE_GAIN:return Analogue Gain;
[RFCv2 PATCH 09/10] DocBook: document the new v4l2 matrix ioctls.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/v4l2.xml | 2 + .../DocBook/media/v4l/vidioc-g-matrix.xml | 115 + .../DocBook/media/v4l/vidioc-query-matrix.xml | 178 + 3 files changed, 295 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-matrix.xml create mode 100644 Documentation/DocBook/media/v4l/vidioc-query-matrix.xml diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 8469fe1..11687d5 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -584,6 +584,7 @@ and discussions on the V4L mailing list./revremark sub-g-frequency; sub-g-input; sub-g-jpegcomp; +sub-g-matrix; sub-g-modulator; sub-g-output; sub-g-parm; @@ -600,6 +601,7 @@ and discussions on the V4L mailing list./revremark sub-querycap; sub-queryctrl; sub-query-dv-timings; +sub-query-matrix; sub-querystd; sub-reqbufs; sub-s-hw-freq-seek; diff --git a/Documentation/DocBook/media/v4l/vidioc-g-matrix.xml b/Documentation/DocBook/media/v4l/vidioc-g-matrix.xml new file mode 100644 index 000..95a3f4e --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-g-matrix.xml @@ -0,0 +1,115 @@ +refentry id=vidioc-g-matrix + refmeta +refentrytitleioctl VIDIOC_G_MATRIX, VIDIOC_S_MATRIX/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_G_MATRIX/refname +refnameVIDIOC_S_MATRIX/refname +refpurposeGet or set a matrix/refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_matrix +*parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_G_MATRIX, VIDIOC_S_MATRIX/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +paraGet or set the elements of a matrix. To get a matrix the application fills in the +structfieldtype/structfield and optionally the structfieldref/structfield +fields of v4l2-matrix;. All other fields will be returned by the driver. +To set a matrix the application fills all the fields of the structure. +/para + +table frame=none pgwide=1 id=v4l2-matrix + titlestruct structnamev4l2_matrix/structname/title + tgroup cols=4 + cs-str; + tbody valign=top + row + entry__u32/entry + entrystructfieldtype/structfield/entry +entry/entry + entryType of the matrix, see xref linkend=v4l2-matrix-type /./entry + /row + row + entryunion/entry + entrystructfieldref/structfield/entry +entry/entry + entryThis union makes it possible to identify the object owning the + matrix. Currently the only defined matrix types are identified through + the filehandle used to call the ioctl, so this union isn't used (yet)./entry + /row + row + entryv4l2-rect;/entry + entrystructfieldrect/structfield/entry +entry/entry + entryThe subset of the matrix that you want to get or set. The rectangle + must fit within the total matrix dimensions, the top left element of the total + matrix is always (0, 0). To get/set the full matrix structfieldrect/structfield + should be set to (0, 0, structfieldcolumns/structfield, structfieldrows/structfield), + where structfieldcolumns/structfield and structfieldrows/structfield are + obtained from VIDIOC-QUERY-MATRIX;./entry + /row + row + entryvoid */entry + entrystructfieldmatrix/structfield/entry +entry/entry + entryA pointer to the matrix. This matrix has size structfieldrect.width/structfield * + structfieldrect.height/structfield * structfieldelem_size/structfield. + The structfieldelem_size/structfield can be obtained via VIDIOC-QUERY-MATRIX;. + The elements are stored row-by-row in the matrix. The first element is element + (structfieldrect.top/structfield, structfieldrect.left/structfield) of the + full matrix./entry + /row +
I have urgent and confidential business transaction of $24,500,000.00 reply for more details
-- 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 2/3] adv7511: add new video encoder.
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/i2c/Kconfig | 11 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/adv7511.c | 1274 +++
include/media/adv7511.h | 49 ++
4 files changed, 1335 insertions(+)
create mode 100644 drivers/media/i2c/adv7511.c
create mode 100644 include/media/adv7511.h
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 847b711..d18be19 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -429,6 +429,17 @@ config VIDEO_ADV7393
To compile this driver as a module, choose M here: the
module will be called adv7393.
+config VIDEO_ADV7511
+ tristate Analog Devices ADV7511 encoder
+ depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
+ ---help---
+ Support for the Analog Devices ADV7511 video encoder.
+
+ This is a Analog Devices HDMI transmitter.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7511.
+
config VIDEO_AD9389B
tristate Analog Devices AD9389B encoder
depends on VIDEO_V4L2 I2C VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index b4cf972..9f462df 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_VIDEO_ADV7393) += adv7393.o
obj-$(CONFIG_VIDEO_ADV7604) += adv7604.o
obj-$(CONFIG_VIDEO_ADV7842) += adv7842.o
obj-$(CONFIG_VIDEO_AD9389B) += ad9389b.o
+obj-$(CONFIG_VIDEO_ADV7511) += adv7511.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_VS6624) += vs6624.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff --git a/drivers/media/i2c/adv7511.c b/drivers/media/i2c/adv7511.c
new file mode 100644
index 000..39c876a
--- /dev/null
+++ b/drivers/media/i2c/adv7511.c
@@ -0,0 +1,1274 @@
+/*
+ * Analog Devices ADV7511 HDMI Transmitter Device Driver
+ *
+ * Copyright 2013 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/videodev2.h
+#include linux/gpio.h
+#include linux/workqueue.h
+#include linux/v4l2-dv-timings.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-ctrls.h
+#include media/adv7511.h
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+MODULE_DESCRIPTION(Analog Devices ADV7511 HDMI Transmitter Device Driver);
+MODULE_AUTHOR(Hans Verkuil);
+MODULE_LICENSE(GPL);
+
+#define MASK_ADV7511_EDID_RDY_INT 0x04
+#define MASK_ADV7511_MSEN_INT 0x40
+#define MASK_ADV7511_HPD_INT0x80
+
+#define MASK_ADV7511_HPD_DETECT 0x40
+#define MASK_ADV7511_MSEN_DETECT0x20
+#define MASK_ADV7511_EDID_RDY 0x10
+
+#define EDID_MAX_RETRIES (8)
+#define EDID_DELAY 250
+#define EDID_MAX_SEGM 8
+
+#define ADV7511_MAX_WIDTH 1920
+#define ADV7511_MAX_HEIGHT 1200
+#define ADV7511_MIN_PIXELCLOCK 2000
+#define ADV7511_MAX_PIXELCLOCK 22500
+
+/*
+**
+*
+* Arrays with configuration parameters for the ADV7511
+*
+**
+*/
+
+struct i2c_reg_value {
+ unsigned char reg;
+ unsigned char value;
+};
+
+struct adv7511_state_edid {
+ /* total number of blocks */
+ u32 blocks;
+ /* Number of segments read */
+ u32 segments;
+ uint8_t data[EDID_MAX_SEGM * 256];
+ /* Number of EDID read retries left */
+ unsigned read_retries;
+ bool complete;
+};
+
+struct adv7511_state {
+ struct adv7511_platform_data pdata;
+ struct v4l2_subdev sd;
+ struct media_pad pad;
+ struct v4l2_ctrl_handler hdl;
+ int chip_revision;
+ uint8_t i2c_edid_addr;
+ uint8_t i2c_cec_addr;
+ /* Is the adv7511 powered on? */
+ bool power_on;
+ /* Did we receive hotplug and rx-sense signals? */
+ bool have_monitor;
+ /* timings from s_dv_timings */
+ struct v4l2_dv_timings dv_timings;
+ /* controls */
+ struct v4l2_ctrl
[RFC PATCH 0/3] Add adv7842 and adv7511 drivers.
This patch series adds support for the adv7842 video receiver and for the adv7511 video transmitter. These drivers have been in the cisco internal repository for way too long, and it is time to get them merged. A note regarding the adv7511 driver: there is also a drm driver floating around, but the driver in this patch series is a v4l driver. As of today it is not possible to have one driver that can be used by both v4l and drm subsystems. The hope is that the work done by Laurent Pinchart on the Common Display Framework will actually make this possible. When that happens the driver will have to be adapted for that. The two drivers in this patch series have been in use for some time now in our products, so they have been tested. This is an RFC since the driver code will change once a pending pull request has been merged. That pull request simplifies DV_TIMINGS handling by adding additional helper functions and moving all DV_TIMINGS support to a new v4l2-dv-timings module. See this branch for those upcoming features: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/for-v3.12 Regards, Hans -- 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 3/3] MAINTAINERS: add entries for adv7511 and adv7842.
From: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- MAINTAINERS | 12 1 file changed, 12 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index bf61e04..e50819b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -580,12 +580,24 @@ L:linux-media@vger.kernel.org S: Maintained F: drivers/media/i2c/ad9389b* +ANALOG DEVICES INC ADV7511 DRIVER +M: Hans Verkuil hans.verk...@cisco.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/adv7511* + ANALOG DEVICES INC ADV7604 DRIVER M: Hans Verkuil hans.verk...@cisco.com L: linux-media@vger.kernel.org S: Maintained F: drivers/media/i2c/adv7604* +ANALOG DEVICES INC ADV7842 DRIVER +M: Hans Verkuil hans.verk...@cisco.com +L: linux-media@vger.kernel.org +S: Maintained +F: drivers/media/i2c/adv7842* + ANALOG DEVICES INC ASOC CODEC DRIVERS M: Lars-Peter Clausen l...@metafoo.de L: device-drivers-de...@blackfin.uclinux.org -- 1.8.3.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
omap3-isp pipeline using media-ctl and yavta
Hello, I'm trying to use a ov3640 camera sensor along with the isp of my overo board. I implemented the media-ctl pipeline configuration in my application, because I had trouble when trying to compile it on my board. Can someone help me out what I am doing wrong? the pipeline commands look like this: char test[] = \ov3640 3-003c\:0-\OMAP3 ISP CCDC\:0[1], \OMAP3 ISP CCDC\:1-\OMAP3 ISP CCDC output\:0[1]; char test2[] = \ov3640 3-003c\:0 [SGRBG10 2048x1536 (32,20)/2048x1536], \OMAP3 ISP CCDC\:1 [SGRBG10 2048x1536]; and my output log says: Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] Setting up selection target 0 rectangle (32,20)/2048x1536 on pad ov3640 3-003c/0 Selection rectangle set: (32,20)/2040x1536 Setting up format SGRBG10 2048x1536 on pad ov3640 3-003c/0 Format set: YUYV2X8 2040x1536 Setting up format YUYV2X8 2040x1536 on pad OMAP3 ISP CCDC/0 Format set: SGRBG10 2040x1536 Setting up format SGRBG10 2048x1536 on pad OMAP3 ISP CCDC/1 Format set: SGRBG10 2032x1536 it seems that it goes through without an error. so when I want to test the pipeline with yavta: ./yavta -f SGRBG10 -s 2048x1536 --capture=1 --file=image /dev/video2 I get this error log: root@overo2:~/yavta-HEAD-d9b7cfc# ./yavta -f SGRBG10 -s 2048x1536 --capture=1 --file=image /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG10 (30314142) 2048x1536 (stride 4096) buffer size 6291456 Video format: SGRBG10 (30314142) 2048x1536 (stride 4096) buffer size 6291456 8 buffers requested. length: 6291456 offset: 0 timestamp type: unknown Buffer 0 mapped at address 0xb6863000. length: 6291456 offset: 6291456 timestamp type: unknown Buffer 1 mapped at address 0xb6263000. length: 6291456 offset: 12582912 timestamp type: unknown Buffer 2 mapped at address 0xb5c63000. length: 6291456 offset: 18874368 timestamp type: unknown Buffer 3 mapped at address 0xb5663000. length: 6291456 offset: 25165824 timestamp type: unknown Buffer 4 mapped at address 0xb5063000. length: 6291456 offset: 31457280 timestamp type: unknown Buffer 5 mapped at address 0xb4a63000. length: 6291456 offset: 37748736 timestamp type: unknown Buffer 6 mapped at address 0xb4463000. length: 6291456 offset: 44040192 timestamp type: unknown Buffer 7 mapped at address 0xb3e63000. overo2 [ 282.482574] Internal error: Oops: 17 [#1] PREEMPT ARM overo2 [ 282.557525] Process yavta (pid: 1293, stack limit = 0xcefe62f0) overo2 [ 282.563690] Stack: (0xcefe7a00 to 0xcefe8000) overo2 [ 282.568237] 7a00: ceec6440 cefe7a68 cefe7a10 bf01d320 0001 07f8 0600 overo2 [ 282.576782] 7a20: 2008 overo2 [ 282.585296] 7a40: 6c0a0109 0006 00d0 cefe7a58 6c0a0100 0030 overo2 [ 282.593841] 7a60: c02b01d4 c0724e48 0001 07f8 0600 300a 0001 overo2 [ 282.602386] 7a80: 0008 overo2 [ 282.610900] 7aa0: c0724e48 ce3d02ac 0001 cefe7ad4 ce0a5610 ce3d9148 ce3d9148 ce3d02ac overo2 [ 282.619445] 7ac0: 0009 ce3d8fd8 ce3d9148 bf0013f8 c0033b4c 0400 ce3d9148 overo2 [ 282.627990] 7ae0: 0001 ce3d8fd8 0009 ce0a5610 0001 0021 0021 0004 overo2 [ 282.636535] 7b00: c0034568 overo2 [ 282.645050] 7b20: c0725248 0021 cefe7e68 cefe7b40 c048eb6c c005db38 overo2 [ 282.653594] 7b40: ce048e00 0001 0001 ce1d1e40 overo2 [ 282.662109] 7b60: 0001 ce3d9148 ce1d1e40 ce3d93f4 ce048e00 ce3d9148 cefe7e68 bf03d948 overo2 [ 282.670654] 7b80: ce3d942c 7fff 0003 8bd3b000 overo2 [ 282.679199] 7ba0: 001b 8bd1c000 c038efac cecdb600 c038efd4 overo2 [ 282.687744] 7bc0: 03007000 cefe7bd0 c038e8bc c005db38 c008ef14 cefe7bf0 0002 cec96008 overo2 [ 282.696289] 7be0: cecdb600 c038e9bc c003a83c c005db38 03007000 8bd1c000 0002 overo2 [ 282.704803] 7c00: 0001 0005 1000 1000 8bd1c000 overo2 [ 282.713348] 7c20: 03007000 1000 cd7b7800 c038dd74 0005 c00e21bc ce352a00 1000 overo2 [ 282.721893] 7c40: d09dcff0 cbd4a2e0 1000 c048e7a0 1000 cbd4a2e0 c038fb14 overo2 [ 282.730407] 7c60: 0005 cefe7ca4 c000e400 cc0af500 cc0b 0040 ce352a00 overo2 [ 282.738952] 7c80: cd7b7800 cecdb630 0005 1000 ce352a00 ce03f840 overo2 [ 282.747467] 7ca0: d09d7000 ce3d9148 cecdb600 0002 c0390020 0060 overo2 [ 282.756011] 7cc0: 0005 c06c8928 05ff cd7b7800 0060 ce352a00 overo2 [ 282.764556] 7ce0: 0600
Re: [RFC PATCH] fence: dma-buf cross-device synchronization (v12)
On Mon, Jul 29, 2013 at 10:05 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering. The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.
A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
+ fence_context_alloc()
A fence is transient, one-shot deal. It is allocated and attached
to one or more dma-buf's. When the one that attached it is done, with
the pending operation, it can signal the fence:
+ fence_signal()
To have a rough approximation whether a fence is fired, call:
+ fence_is_signaled()
The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.
The one pending on the fence can add an async callback:
+ fence_add_callback()
The callback can optionally be cancelled with:
+ fence_remove_callback()
To wait synchronously, optionally with a timeout:
+ fence_wait()
+ fence_wait_timeout()
A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync. But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization. For example:
fence = custom_get_fence(...);
if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence-sync_buf;
get_dma_buf(fence_buf);
... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence-seqno_ofs, fence-seqno);
} else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
}
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.
enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.
The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).
v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw-hw signaling path
(it can be handled same as sw-sw case), and therefore the fence-ops
can be simplified and more handled in the core. So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw-hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb-func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override
Re: dib8000 scanning not working on 3.10.3
Hey Luis, On Wed, Aug 07, 2013 at 03:48:33PM -0300, Luis Polasek wrote: Hi again Mauro, reverting both commits: * 59501bb792c66b85fb7fdbd740e788e3afc70bbd * f45f513a9325b52a5f3e26ee8d15471e8b692947 The problem still exists, I am unable to get any result, and also no error logs) :( What shall I do to try to fix this ? Do you need more info on my current setup. Have you tried a git bisect? It's a PITA, but it's a safe way to find the guilty commit. Don't hesitate in asking for help if you're not sure how this is done. PS: Try to avoid top-posting. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Aug 12 19:00:21 CEST 2013 git branch: test git hash: dfb9f94e8e5e7f73c8e2bcb7d4fb1de57e7c333d gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: v0.4.5-rc1 host hardware: x86_64 host os:3.9-7.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: 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.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10-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: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10-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: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse version: v0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The 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 v2 1/2] libv4lconvert: Support for Y16 pixel format
On 8/9/13 6:04 PM, Ricardo Ribalda Delgado wrote: ping? Thank you for your the updated series. Unfortunately I'm still partially busy with moving. I hoped the v4lconvert maintainer Hans (de Goede) will ack these patches. If this series does not get an ack by Sunday I'll double check and commit. What hardware did you use to test this? Thanks, Gregor -- 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 v2 1/2] libv4lconvert: Support for Y16 pixel format
Hello Gregor I am using some cameras from qtec.com. In fact, I am developing the firmware for them :) qv4l2 has been very useful for testing. Thanks for your response. On Mon, Aug 12, 2013 at 9:39 PM, Gregor Jasny gja...@googlemail.com wrote: On 8/9/13 6:04 PM, Ricardo Ribalda Delgado wrote: ping? Thank you for your the updated series. Unfortunately I'm still partially busy with moving. I hoped the v4lconvert maintainer Hans (de Goede) will ack these patches. If this series does not get an ack by Sunday I'll double check and commit. What hardware did you use to test this? Thanks, Gregor -- Ricardo Ribalda -- 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 v5] media: i2c: tvp7002: add OF support
On Aug 11, 2013, at 1:25 AM, Lad, Prabhakar wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
add OF support for the tvp7002 driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
This patch depends on https://patchwork.kernel.org/patch/2842680/
Changes for v5:
1: Fixed review comments pointed by Hans.
Changes for v4:
1: Improved descrition of end point properties.
Changes for v3:
1: Fixed review comments pointed by Sylwester.
.../devicetree/bindings/media/i2c/tvp7002.txt | 53
drivers/media/i2c/tvp7002.c| 67 ++--
2 files changed, 113 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
new file mode 100644
index 000..5f28b5d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt
@@ -0,0 +1,53 @@
+* Texas Instruments TV7002 video decoder
+
+The TVP7002 device supports digitizing of video and graphics signal in RGB
and
+YPbPr color space.
+
+Required Properties :
+- compatible : Must be ti,tvp7002
+
+Optional Properties:
+- hsync-active: HSYNC Polarity configuration for the bus. Default value when
+ this property is not specified is 0.
+
+- vsync-active: VSYNC Polarity configuration for the bus. Default value when
+ this property is not specified is 0.
+
+- pclk-sample: Clock polarity of the bus. Default value when this property is
+ not specified is 0.
+
+- sync-on-green-active: Active state of Sync-on-green signal property of the
+ endpoint.
+ 0 = Normal Operation (Active Low, Default)
+ 1 = Inverted operation
These seems better than what you have in video-interfaces.txt
+
+- field-even-active: Active-high Field ID output polarity control of the bus.
+ Under normal operation, the field ID output is set to logic 1 for an odd
field
+ (field 1) and set to logic 0 for an even field (field 0).
+ 0 = Normal Operation (Active Low, Default)
+ 1 = FID output polarity inverted
+
Why the duplication if this is covered in video-interfaces.txt?
+For further reading of port node refer
Documentation/devicetree/bindings/media/
+video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ tvp7002@5c {
+ compatible = ti,tvp7002;
+ reg = 0x5c;
+
+ port {
+ tvp7002_1: endpoint {
+ hsync-active = 1;
+ vsync-active = 1;
+ pclk-sample = 0;
+ sync-on-green-active = 1;
+ field-even-active = 0;
+ };
+ };
+ };
+ ...
+ };
[ snip ]
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation
--
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 v5] media: i2c: tvp7002: add OF support
On Tue, Aug 13, 2013 at 6:30 AM, Kumar Gala ga...@codeaurora.org wrote: On Aug 11, 2013, at 1:25 AM, Lad, Prabhakar wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com add OF support for the tvp7002 driver. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- This patch depends on https://patchwork.kernel.org/patch/2842680/ Changes for v5: 1: Fixed review comments pointed by Hans. Changes for v4: 1: Improved descrition of end point properties. Changes for v3: 1: Fixed review comments pointed by Sylwester. .../devicetree/bindings/media/i2c/tvp7002.txt | 53 drivers/media/i2c/tvp7002.c| 67 ++-- 2 files changed, 113 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp7002.txt diff --git a/Documentation/devicetree/bindings/media/i2c/tvp7002.txt b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt new file mode 100644 index 000..5f28b5d --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/tvp7002.txt @@ -0,0 +1,53 @@ +* Texas Instruments TV7002 video decoder + +The TVP7002 device supports digitizing of video and graphics signal in RGB and +YPbPr color space. + +Required Properties : +- compatible : Must be ti,tvp7002 + +Optional Properties: +- hsync-active: HSYNC Polarity configuration for the bus. Default value when + this property is not specified is 0. + +- vsync-active: VSYNC Polarity configuration for the bus. Default value when + this property is not specified is 0. + +- pclk-sample: Clock polarity of the bus. Default value when this property is + not specified is 0. + +- sync-on-green-active: Active state of Sync-on-green signal property of the + endpoint. + 0 = Normal Operation (Active Low, Default) + 1 = Inverted operation These seems better than what you have in video-interfaces.txt Well it sounds the same, I would keep it as is, let me know if you still want me to change. + +- field-even-active: Active-high Field ID output polarity control of the bus. + Under normal operation, the field ID output is set to logic 1 for an odd field + (field 1) and set to logic 0 for an even field (field 0). + 0 = Normal Operation (Active Low, Default) + 1 = FID output polarity inverted + Why the duplication if this is covered in video-interfaces.txt? The explanation in video-interfaces.txt is more kind of generic and the explanation here is specific to this device. Regards, --Prabhakar Lad -- 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
