Query the meaning of variable in v4l2_pix_format and v4l2_plane
Hi, I'm not sure the meaning of variables in v4l2_pix_format and v4l2_plane. Especially bytesperline, sizeimage, length and bytesused. v4l2_pix_format.width = width v4l2_pix_format.height = height v4l2_pix_format.bytesperline= bytesperline [in bytes] v4l2_pix_format.sizeimage = bytesperline * buf height - Is this right ? v4l2_plane.length = bytesperline * buf height - Is this right ? I don't which is right. v4l2_plane.bytesused= bytesperline * (top + height) v4l2_plane.bytesused= bytesperline * height v4l2_plane.bytesused= width * height * bytesperpixel v4l2_plane.bytesused= bytesperline * (top + height) - (pixelperline - (left + width)) * bytesperpixel I assumed the following buffer. | | |- bytesperline -| | | +--+- | ^ | ^ | | | | | | | | t | | | o | | | p | | | | | | | | | | V |- width --|| | |-- left --++ - | | ||| ^ | ||| | | b ||| | | u |||| f ||| h | ||| e | h ||| i | e ||| g | i ||| h | g ||| t | h |||| t ||| | | ||| | | | ||| v | | |++ - | | | | | | | | | | v +--+- Best regards, -- 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] media: DocBook: Fix trivial typo in Sub-device Interface
From: Jonghun Han jonghun@samsung.com When satisfied with the try results, applications can set the active formats by setting the which argument to V4L2_SUBDEV_FORMAT_ACTIVE not V4L2_SUBDEV_FORMAT_TRY. Signed-off-by: Jonghun Han jonghun@samsung.com --- Documentation/DocBook/v4l/dev-subdev.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml index 05c8fef..0916a73 100644 --- a/Documentation/DocBook/v4l/dev-subdev.xml +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -266,7 +266,7 @@ paraWhen satisfied with the try results, applications can set the active formats by setting the structfieldwhich/structfield argument to - constantV4L2_SUBDEV_FORMAT_TRY/constant. Active formats are changed + constantV4L2_SUBDEV_FORMAT_ACTIVE/constant. Active formats are changed exactly as try formats by drivers. To avoid modifying the hardware state during format negotiation, applications should negotiate try formats first and then modify the active settings using the try formats returned during -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: DocBook: Fix trivial typo in Sub-device Interface
From: Jonghun Han jonghun@samsung.com When satisfied with the try results, applications can set the active formats by setting the which argument to V4L2_SUBDEV_FORMAT_ACTIVE not V4L2_SUBDEV_FORMAT_TRY. Signed-off-by: Jonghun Han jonghun@samsung.com --- Documentation/DocBook/v4l/dev-subdev.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml index 05c8fef..0916a73 100644 --- a/Documentation/DocBook/v4l/dev-subdev.xml +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -266,7 +266,7 @@ paraWhen satisfied with the try results, applications can set the active formats by setting the structfieldwhich/structfield argument to - constantV4L2_SUBDEV_FORMAT_TRY/constant. Active formats are changed + constantV4L2_SUBDEV_FORMAT_ACTIVE/constant. Active formats are changed exactly as try formats by drivers. To avoid modifying the hardware state during format negotiation, applications should negotiate try formats first and then modify the active settings using the try formats returned during -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: DocBook: Fix trivial typo in Sub-device Interface
When satisfied with the try results, applications can set the active formats by setting the which argument to V4L2_SUBDEV_FORMAT_ACTIVE not V4L2_SUBDEV_FORMAT_TRY. Signed-off-by: Jonghun Han jonghun@samsung.com --- Documentation/DocBook/v4l/dev-subdev.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml index 05c8fef..0916a73 100644 --- a/Documentation/DocBook/v4l/dev-subdev.xml +++ b/Documentation/DocBook/v4l/dev-subdev.xml @@ -266,7 +266,7 @@ paraWhen satisfied with the try results, applications can set the active formats by setting the structfieldwhich/structfield argument to - constantV4L2_SUBDEV_FORMAT_TRY/constant. Active formats are changed + constantV4L2_SUBDEV_FORMAT_ACTIVE/constant. Active formats are changed exactly as try formats by drivers. To avoid modifying the hardware state during format negotiation, applications should negotiate try formats first and then modify the active settings using the try formats returned during -- 1.7.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] v4l: simulate old crop API using extended crop/compose API
Hi Tomasz Stanislawski,
On Thursday, May 05, 2011 6:40 PM Tomasz Stanislawski wrote:
This patch allows new drivers to work correctly with applications that use
old-style crop API.
The old crop ioctl is simulated by using selection ioctls.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/media/video/v4l2-ioctl.c | 85
+
1 files changed, 75 insertions(+), 10 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-
ioctl.c
index aeef966..d0a4073 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1723,11 +1723,31 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_crop *p = arg;
- if (!ops-vidioc_g_crop)
+ dbgarg(cmd, type=%s\n, prt_names(p-type,
v4l2_type_names));
+
+ if (ops-vidioc_g_crop) {
+ ret = ops-vidioc_g_crop(file, fh, p);
+ } else
+ if (ops-vidioc_g_selection) {
+ /* simulate capture crop using selection api */
+ struct v4l2_selection s = {
+ .type = p-type,
+ .target = V4L2_SEL_CROP_ACTIVE,
+ };
+
+ /* crop means compose for output devices */
+ if (p-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ s.target = V4L2_SEL_COMPOSE_ACTIVE;
+
If it also supports V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,
how about using Macro like V4L2_TYPE_IS_OUTPUT(type) ?
[snip]
Best regards,
Jonghun Han
--
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 5/7] v4l: s5p-fimc: add pm_runtime support
AALQBmAGkAbQBjADoAIA
BhAGQAZAAgAHAAbQBfAHIAdQBuAHQAaQBtAGUAIABzAHUAcABwAG8AcgB0AA==
x-cr-puzzleid: {0DF5696E-C27B-4620-A41E-B97F4C401FEA}
Hi Marek,
runtime_pm is used to minimize current.
In my opinion, the followings will be better.
1. Adds pm_runtime_get_sync before running of the first job.
IMO, dma_run callback function is the best place for calling in case of
M2M.
2. And then in the ISR, call pm_runtime_put_sync in the ISR bottom-half if
there is no remained job.
I had already implemented and tested.
But it remained code cleanup. I hope I can post it on the next week.
Best regards,
Jonghun Han
On Tuesday, April 05, 2011 11:07 PM Marek Szyprowski wrote:
This patch adds basic support for pm_runtime to s5p-fimc driver. PM
runtime
support is required to enable the driver on S5PV310 series with power
domain
driver enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |5 +
drivers/media/video/s5p-fimc/fimc-core.c| 14 ++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 95f8b4e1..f697ed1 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include linux/list.h
#include linux/slab.h
#include linux/clk.h
@@ -398,6 +399,8 @@ static int fimc_capture_open(struct file *file)
if (fimc_m2m_active(fimc))
return -EBUSY;
+ pm_runtime_get_sync(fimc-pdev-dev);
+
if (++fimc-vid_cap.refcnt == 1) {
ret = fimc_isp_subdev_init(fimc, 0);
if (ret) {
@@ -428,6 +431,8 @@ static int fimc_capture_close(struct file *file)
fimc_subdev_unregister(fimc);
}
+ pm_runtime_put_sync(fimc-pdev-dev);
+
return 0;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 6c919b3..ead5c0a 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -20,6 +20,7 @@
#include linux/interrupt.h
#include linux/device.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include linux/list.h
#include linux/io.h
#include linux/slab.h
@@ -1410,6 +1411,8 @@ static int fimc_m2m_open(struct file *file)
if (fimc-vid_cap.refcnt 0)
return -EBUSY;
+ pm_runtime_get_sync(fimc-pdev-dev);
+
fimc-m2m.refcnt++;
set_bit(ST_OUTDMA_RUN, fimc-state);
@@ -1452,6 +1455,8 @@ static int fimc_m2m_release(struct file *file)
if (--fimc-m2m.refcnt = 0)
clear_bit(ST_OUTDMA_RUN, fimc-state);
+ pm_runtime_put_sync(fimc-pdev-dev);
+
return 0;
}
@@ -1649,6 +1654,11 @@ static int fimc_probe(struct platform_device *pdev)
goto err_req_region;
}
+ pm_runtime_set_active(pdev-dev);
+ pm_runtime_enable(pdev-dev);
+
+ pm_runtime_get_sync(pdev-dev);
+
fimc-num_clocks = MAX_FIMC_CLOCKS - 1;
/* Check if a video capture node needs to be registered. */ @@ -
1706,6
+1716,8 @@ static int fimc_probe(struct platform_device *pdev)
dev_dbg(pdev-dev, %s(): fimc-%d registered successfully\n,
__func__, fimc-id);
+ pm_runtime_put_sync(pdev-dev);
+
return 0;
err_m2m:
@@ -1740,6 +1752,8 @@ static int __devexit fimc_remove(struct
platform_device
*pdev)
vb2_dma_contig_cleanup_ctx(fimc-alloc_ctx);
+ pm_runtime_disable(pdev-dev);
+
iounmap(fimc-regs);
release_resource(fimc-regs_res);
kfree(fimc-regs_res);
--
1.7.1.569.g6f426
--
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 1/2] media: vb2: add frame buffer emulator for video output devices
Hi Marek,
Here is my comments.
On Wednesday, March 30, 2011 4:01 PM Marek Szyprowski wrote:
This patch adds generic frame buffer emulator for any video output device
that uses videobuf2 framework. This emulator assumes that the driver is
capable of working in single-buffering mode and use memory allocator that
allows coherent memory mapping.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/Kconfig|7 +
drivers/media/video/Makefile |1 +
drivers/media/video/videobuf2-fb.c | 565
include/media/videobuf2-fb.h | 22 ++
4 files changed, 595 insertions(+), 0 deletions(-) create mode 100644
snip
+static struct fmt_desc fmt_conv_table[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_RGB565,
+ .bits_per_pixel = 16,
+ .red = {.offset = 11, .length = 5,},
+ .green = { .offset = 5,.length = 6,},
+ .blue = { .offset = 0,.length = 5,},
+ }, {
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .bits_per_pixel = 16,
+ .red = {.offset = 11, .length = 5,},
+ .green = { .offset = 5,.length = 5,},
+ .blue = { .offset = 0,.length = 5,},
+ }, {
+ .fourcc = V4L2_PIX_FMT_RGB444,
+ .bits_per_pixel = 16,
+ .red = {.offset = 8,.length = 4,},
+ .green = { .offset = 4,.length = 4,},
+ .blue = { .offset = 0,.length = 4,},
+ .transp = { .offset = 12, .length = 4,},
+ }, {
+ .fourcc = V4L2_PIX_FMT_BGR32,
+ .bits_per_pixel = 32,
+ .red = {.offset = 16, .length = 4,},
red.length should be 8 in case of BGR32.
+ .green = { .offset = 8,.length = 8,},
+ .blue = { .offset = 0,.length = 8,},
+ .transp = { .offset = 24, .length = 8,},
+ },
+ /* TODO: add more format descriptors */ };
+
+/**
+ * vb2_drv_lock() - a shortcut to call driver specific lock()
+ * @q: videobuf2 queue
+ */
+static inline void vb2_drv_lock(struct vb2_queue *q) {
+ q-ops-wait_finish(q);
+}
+
+/**
+ * vb2_drv_unlock() - a shortcut to call driver specific unlock()
+ * @q: videobuf2 queue
+ */
+static inline void vb2_drv_unlock(struct vb2_queue *q) {
+ q-ops-wait_prepare(q);
+}
+
+/**
+ * vb2_fb_activate() - activate framebuffer emulator
+ * @info:framebuffer vb2 emulator data
+ * This function activates framebuffer emulator. The pixel format
+ * is acquired from video node, memory is allocated and framebuffer
+ * structures are filled with valid data.
+ */
+static int vb2_fb_activate(struct fb_info *info) {
+ struct vb2_fb_data *data = info-par;
+ struct vb2_queue *q = data-q;
+ struct fb_var_screeninfo *var;
+ struct v4l2_format fmt;
+ struct fmt_desc *conv = NULL;
+ int width, height, fourcc, bpl, size;
+ int i, ret = 0;
+ int (*g_fmt)(struct file *file, void *fh, struct v4l2_format *f);
+
+ /*
+ * Check if streaming api has not been already activated.
+ */
+ if (q-streaming || q-num_buffers 0)
+ return -EBUSY;
+
+ dprintk(3, setting up framebuffer\n);
+
+ /*
+ * Open video node.
+ */
+ ret = data-vfd-fops-open(data-fake_file);
+ if (ret)
+ return ret;
+
+ /*
+ * Get format from the video node.
+ */
+ memset(fmt, 0, sizeof(fmt));
+ fmt.type = q-type;
+ if (data-vfd-ioctl_ops-vidioc_g_fmt_vid_out) {
+ g_fmt = data-vfd-ioctl_ops-vidioc_g_fmt_vid_out;
+ ret = g_fmt(data-fake_file, data-fake_file.private_data,
fmt);
+ if (ret)
+ goto err;
+ width = fmt.fmt.pix.width;
+ height = fmt.fmt.pix.height;
+ fourcc = fmt.fmt.pix.pixelformat;
+ bpl = fmt.fmt.pix.bytesperline;
+ size = fmt.fmt.pix.sizeimage;
+ } else if (data-vfd-ioctl_ops-vidioc_g_fmt_vid_out_mplane) {
+ g_fmt = data-vfd-ioctl_ops-vidioc_g_fmt_vid_out_mplane;
+ ret = g_fmt(data-fake_file, data-fake_file.private_data,
fmt);
+ if (ret)
+ goto err;
+ width = fmt.fmt.pix_mp.width;
+ height = fmt.fmt.pix_mp.height;
+ fourcc = fmt.fmt.pix_mp.pixelformat;
+ bpl = fmt.fmt.pix_mp.plane_fmt[0].bytesperline;
+ size = fmt.fmt.pix_mp.plane_fmt[0].sizeimage;
+ } else {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ dprintk(3, fb emu: width %d height %d fourcc %08x size %d bpl
%d\n,
+
RE: [RFC/PATCH 0/2] FrameBuffer emulator for V4L2/VideoBuf2
Hi Marek, On Wednesday, March 30, 2011 4:01 PM Marek Szyprowski wrote: Hello, On V4L2 brainstorming meeting in Warsaw we discussed the need of a framebuffer userspace interface for video output devices. Such framebuffer interface is aimed mainly for legacy applications and/or interoperatibility with Xfbdev. I proposed to give the idea of generic fb-on-top-of-video-node a second try, now using the power of videobuf2. This short patch series demonstrates that this approach is possible. We succesfully implemented a framebuffer emulator and tested it with s5p-hdmi driver on Samsung Exynos4 platform. This initial version provides a basic non-accelerated framebuffer device. The emulation is started on the first open of the framebuffer device and stopped on last close. The framebuffer boots in 'blanked' mode, so one also needs to make a call to blank ioctl (with FB_BLANK_UNBLANK argument) to enable video output. We successfully managed to get vanilla Xfbdev server working on top of it without ANY changes in X server sources. The framebuffer resolution and pixel format is autoconfigured from the parameters of the corresponding video output node. One can use v4l2-ctrl (or similar) tool to select pixel format, resolution, output, etc (and in the near future also the composition on the target video device). There a few requirements for the video output driver: 1. support for single-buffering mode 2. support for videoc_ioctl interface (this might change in the future) 3. use memory allocator that allows coherent mappings (mmaped framebuffer will be accessed by application while it is displayed by dma engine). The changes that are needed in the video output driver are really simple. Mainly one need to add just a call to vb2_fb_register(q, vfd) and vb2_fb_register(fb) functions. The future versions might aslo include the following features: - vsync event translation into WAIT_VSYNC framebuffer ioctl - support for frame buffer panning with upcoming S_COMPOSE ioctl As I know, the panning is different from upcoming S_COMPOSE. The panning selects the frame buffer area which will be read by display controller to support virtual screen feature. But as I remember, the S_COMPOSE is related in positioning on the display device like HDMI. IMO, VIDIOC_S_EXTCROP makes sense for panning. The patch series is based on the V2 of the s5p-hdmi driver. The complete kernel tree will be available on: git://git.infradead.org/users/kmpark/linux-2.6-samsung vb2-fb-tv branch. An updated s5p-hdmi/tv driver will be posted soon. Best regards -- Marek Szyprowski Samsung Poland RD Center Complete patch summary: Marek Szyprowski (2): media: vb2: add frame buffer emulator for video output devices media: s5p-hdmi: add support for frame buffer emulator drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/s5p-tv/Kconfig |1 + drivers/media/video/s5p-tv/mixer.h |2 + drivers/media/video/s5p-tv/mixer_video.c | 10 + drivers/media/video/videobuf2-fb.c | 565 ++ include/media/videobuf2-fb.h | 22 ++ 7 files changed, 608 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/videobuf2-fb.c create mode 100644 include/media/videobuf2-fb.h -- 1.7.1.569.g6f426 -- 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: v4l: Buffer pools
Hi all, The followings are Samsung S.LSI requirement for memory provider. 1. User space API 1.1. New memory management(MM) features should includes followings to the user space.: UMP A. user space API for memory allocation from system memory: UMP Any user process can allocate memory from kernel space by new MM model. B. user space API for cache operations: flush, clean, invalidate Any user process can do cache operation on the allocated memory. C. user space API for mapping memory attribute as cacheable When the system memory mapped into the user space, user process can set its property as cacheable. D. user space API for mapping memory attribute as non-cacheable When the system memory mapped into the user space, user process can set its property as non-cacheable. 1.2. Inter-process memory sharing: UMP New MM features should provide memory sharing between user process. A. Memory allocated by user space can be shared between user processes. B. Memory allocated by kernel space can be shared between user processes. 2. Kernel space API New MM features should includes followings to the kernel space.: CMA, VCMM 2-1. Physically memory allocator A. kernel space API for contiguous memory allocation: CMA(*) B. kernel space API for non-contiguous memory allocation: VCMM (*) C. start address alignment: CMA, VCMM D. selectable allocating region: CMA *refer to the bottom's extension. 2-2. Device virtual address management: VCMM New MM features should provide the way of managing device virtual memory address as like followings: A. IOMMU(System MMU) support IOMMU is a kind of memory MMU, but IOMMU is dedicated for each device. B. device virtual address mapping for each device C. virtual memory allocation D. mapping / remapping between phys and device virtual address E. dedicated device virtual address space for each device F. address translation between address space U.V / \ K.V - P.A \/ D.V U.V: User space address K.A: Kernel space address P.A: Physical address D.V: Device virtual address 3. Extensions A. extension for custom physical memory allocator B. extension for custom MMU controller - You can find the implementation in the following git repository. http://git.kernel.org/?p=linux/kernel/git/kki_ap/linux-2.6- samsung.git;a=tree;hb=refs/heads/2.6.36-samsung 1. UMP (Unified Memory Provider) - The UMP is an auxiliary component which enables memory to be shared across different applications, drivers and hardware components. - http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver- open-source/page__cid__133__show__newcomment/ - Suggested by ARM, Not submitted yet. - implementation drivers/media/video/samsung/ump/* 2. VCMM (Virtual Contiguous Memory Manager) - The VCMM is a framework to deal with multiple IOMMUs in a system with intuitive and abstract objects - Submitted by Michal Nazarewicz @Samsung-SPRC - Also submitted by KyongHo Cho @Samsung-SYS.LSI - http://article.gmane.org/gmane.linux.kernel.mm/56912/match=vcm - implementation include/linux/vcm.h include/linux/vcm-drv.h mm/vcm.c arch/arm/plat-s5p/s5p-vcm.c arch/amr/plat-s5p/include/plat/s5p-vcm.h 3. CMA (Contiguous Memory Allocator) - The Contiguous Memory Allocator (CMA) is a framework, which allows setting up a machine-specific configuration for physically-contiguous memory management. Memory for devices is then allocated according to that configuration. - http://lwn.net/Articles/396702/ - http://www.spinics.net/lists/linux-media/msg26486.html - Submitted by Michal Nazarewicz @Samsung-SPRC - implementation mm/cma.c include/linux/cma.h 4. SYS.MMU - System MMU supports address transition from VA to PA. - http://thread.gmane.org/gmane.linux.kernel.samsung-soc/3909 - Submitted by Sangbeom Kim - Merged by Kukjin Kim, ARM/S5P ARM ARCHITECTURES maintainer - implementation arch/arm/plat-s5p/sysmmu.c arch/arm/plat-s5p/include/plat/sysmmu.h Best regards, Jonghun Han -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Willy POISSON Sent: Tuesday, March 29, 2011 11:02 PM To: linux-media@vger.kernel.org Subject: v4l: Buffer pools Hi all, Following to the Warsaw mini-summit action point, I would like to open the thread to gather buffer pool memory manager requirements. The list of requirement for buffer pool may contain: - Support physically contiguous and virtual memory - Support IPC, import/export handles (between processes/drivers/userland/etc) - Security(access rights in order to secure no one unauthorized is allowed to access buffers) - Cache flush management (by using setdomain and optimize when flushing is needed) - Pin/unpin in order to get the actual address to be able to do defragmentation
RE: [Query] VIDIOC_QBUF and VIDIOC_STREAMON order
Hi all, On Tuesday, March 22, 2011 7:54 PM Laurent Pinchart wrote: On Tuesday 15 March 2011 08:50:45 Hans Verkuil wrote: On Tuesday, March 15, 2011 04:21:05 Pawel Osciak wrote: On Mon, Mar 14, 2011 at 03:49, Subash Patel subas...@gmail.com wrote: VIDIOC_STREAMON expects buffers to be queued before hardware part of image/video pipe is enabled. From my experience of V4L2 user space, I have always QBUFfed before invoking the STREAMON. Below is the API specification which also speaks something same: Not exactly. It says that the API requires buffers to be queued for output devices. It does not require any buffers to be queued for input devices. Sylwester is right here. This feature of not having to queue input buffers before STREAMON introduces problems to driver implementations and I am personally not a big fan of it either. But I'm seeing some additional problems here. Suppose we forced QBUF to be done before STREAMON. This would work, but what happens next? What should happen when we want to DQBUF the last buffer? If the device couldn't start without any buffers queued, can it continue streaming with all of them dequeued? I would guess not. So we'd either have to deny DQBUF of the last buffer (which for me personally is almost unacceptable) or have the last DQBUF automatically cause a STREAMOFF. So, for the latter, should applications, after they get all the data they wanted, be made to always have one more buffer queued as a throwaway buffer? This is probably the only reasonable solution here, but the applications would have to keep count of their queued buffers and be aware of this. Also, there might still be situations where being able to STREAMON without buffers queued would be beneficial. For example, enabling the device might be a slow/expensive operation and we might prefer to keep it running even if we don't want any data at the moment. Even for faster devices, being able to keep them on and periodically take a snapshot would be faster without having to call STREAMON anyway... The problem is that what is possible is highly hardware dependent. All video capture device I know of (composite in, HDMI in, etc) require that buffers are queued and they won't release that buffer to userspace until a new free buffer is available. That's funny, all video capture devices I know of behave the opposite way :-) They either pause the stream when they run out of buffers and resume it when a new buffer gets queued, or they throw away the data when intermediate buffers are used (such as with USB devices). Laurent, Exynos capture device is the same with your example. It should pause the stream not to overwrite when they run out of buffers and resume it when a new buffer gets queued. Hans, Do you mean that the buffer is overwritten without pause and resume until a new free buffer is coming ? They DMA continuously and stopping the DMA at the last buffer and restarting it when a new one appears tends to be too expensive and leads to additional loss of frames. In part how this should act depends on the use-case: if you are streaming video, then requiring buffers to be present before STREAMON and holding on to a buffer if userspace can't keep up seems quite reasonable to me. But for snapshot and codec type streams this behavior doesn't make sense. The main difference is that in this case the DMA is not driven by an external input, but by internal (userspace) demand. Something for our meeting to discuss. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Best regards, Jonghun Han -- 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 1/1] v4l: videobuf2: Add Exynos devices based allocator, named SDVMM
SDVMM: Shared Device Virtual Memory Management
This patch adds new videobuf2 memory allocator dedicated to Exynos.
This allocator gets memory using VCM which can get memory its own allocator
and also get memory via CMA optionally.
It requires the following 4 modules.
UMP (Unified Memory Provider), suggested by ARM.
VCM (Virtual Contiguous Memory framework), submitted by Samsung
CMA (Contiguous Memory Allocator), submitted by Samsung
SYS.MMU (System MMU), submitted by Samsung.
Signed-off-by: Jonghun Han jonghun@samsung.com
---
drivers/media/video/videobuf2-sdvmm.c | 659 +
include/media/videobuf2-sdvmm.h | 58 +++
2 files changed, 717 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-sdvmm.c
create mode 100644 include/media/videobuf2-sdvmm.h
diff --git a/drivers/media/video/videobuf2-sdvmm.c
b/drivers/media/video/videobuf2-sdvmm.c
new file mode 100644
index 000..06e12aa
--- /dev/null
+++ b/drivers/media/video/videobuf2-sdvmm.c
@@ -0,0 +1,659 @@
+/* linux/drivers/media/video/videobuf2-sdvmm.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Implementation of SDVMM memory allocator for videobuf2
+ * SDVMM : Shared Device Virtual Memory Management
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/err.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mm.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/vmalloc.h
+#include linux/cma.h
+#include linux/vcm-drv.h
+
+#include plat/s5p-vcm.h
+#include media/videobuf2-sdvmm.h
+
+#include ump_kernel_interface.h
+#include ump_kernel_interface_ref_drv.h
+#include ump_kernel_interface_vcm.h
+
+static int sdvmm_debug;
+module_param(sdvmm_debug, int, 0644);
+#define dbg(level, fmt, arg...)
\
+ do {\
+ if (sdvmm_debug = level) \
+ printk(KERN_DEBUG vb2_sdvmm: fmt, ## arg); \
+ } while (0)
+
+struct vb2_sdvmm_conf {
+ spinlock_t slock;
+
+ /* For CMA */
+ struct device *dev;
+ const char *type;
+ unsigned long alignment;
+ booluse_cma;
+
+ /* For VCMM */
+ struct vcm *vcm_ctx;
+ enum vcm_dev_id vcm_id;
+
+ /* SYS.MMU */
+ boolmmu_clk;
+ bool(*get_power)(void *);
+
+ void*priv;
+};
+
+struct vb2_sdvmm_buf {
+ struct vm_area_struct *vma;
+ struct vb2_sdvmm_conf *conf;
+ struct vb2_vmarea_handler handler;
+
+ atomic_tref;
+ unsigned long size;
+
+ struct vcm_res *vcm_res;
+ struct vcm_res *vcm_res_kern;
+ ump_dd_handle ump_dd_handle;
+ unsigned long dva_offset;
+};
+
+static void vb2_sdvmm_put(void *buf_priv);
+static int _vb2_sdvmm_mmap_pfn_range(struct vm_area_struct *vma,
+struct vcm_phys *vcm_phys,
+unsigned long size,
+const struct vm_operations_struct *vm_ops,
+void *priv);
+
+static void *_vb2_sdvmm_ump_register(struct vb2_sdvmm_buf *buf)
+{
+ struct vcm_phys_part*part = buf-vcm_res-phys-parts;
+ ump_dd_physical_block *blocks;
+ ump_dd_handle *handle;
+ struct ump_vcm ump_vcm;
+ int num_blocks = buf-vcm_res-phys-count;
+ int block_size, i;
+
+ block_size = sizeof(ump_dd_physical_block) * num_blocks;
+ blocks = (ump_dd_physical_block *)vmalloc(block_size);
+ for (i = 0; i num_blocks; i++) {
+ blocks[i].addr = part-start;
+ blocks[i].size = part-size;
+ ++part;
+
+ dbg(6, block addr(0x%08x), size(0x%08x)\n,
+ (u32)blocks[i].addr, (u32)blocks[i].size);
+ }
+
+ handle = ump_dd_handle_create_from_phys_blocks(blocks, num_blocks);
+ vfree(blocks);
+ if (handle == UMP_DD_HANDLE_INVALID) {
+ pr_err(ump_dd_handle_create_from_phys_blocks failed\n);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ ump_vcm.vcm = buf-conf-vcm_ctx;
+ ump_vcm.vcm_res = buf-vcm_res;
+ ump_vcm.dev_id = buf-conf-vcm_id;
+
+ if (ump_dd_meminfo_set(handle, (void *)ump_vcm)) {
+ ump_dd_reference_release(handle);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return (void *)handle
[RFC 0/1] v4l: videobuf2: Add Exynos devices based allocator, named SDVMM
== Introduction == The purpose of this RFC is to discuss the vb2-allocator for multimedia devices available in upcoming Samsung SoC Exynos. Not all of them are merged or submitted by now, but I decided to post this for starting discussion about buffer management. vb2-sdvmm is an allocator using SDVMM. The SDVMM is not a implementation itself. It is the name of solution which integrates UMP, VCM, CMA and SYS.MMU. The main purposes of Shared Device Virtual Memory Management(aka SDVMM) are: 1. Inter-process buffer sharing using UMP 2. Device virtual memory management using VCM and SYS.MMU(aka IOMMU) 3. Contiguous memory allocation support using CMA == Related patchset == 1. UMP (Unified Memory Provider) - The UMP is an auxiliary component which enables memory to be shared across different applications, drivers and hardware components. - http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/ - Suggested by ARM, Not submitted yet. 2. VCM (Virtual Contiguous Memory framework) - The VCM is a framework to deal with multiple IOMMUs in a system with intuitive and abstract objects - Submitted by Michal Nazarewicz @Samsung-SPRC - Also submitted by KyongHo Cho @Samsung-SYS.LSI - http://article.gmane.org/gmane.linux.kernel.mm/56912/match=vcm 3. CMA (Contiguous Memory Allocator) - The Contiguous Memory Allocator (CMA) is a framework, which allows setting up a machine-specific configuration for physically-contiguous memory management. Memory for devices is then allocated according to that configuration. - http://lwn.net/Articles/396702/ - http://www.spinics.net/lists/linux-media/msg26486.html - Submitted by Michal Nazarewicz @Samsung-SPRC 4. SYS.MMU - System mmu supports address transition from virtual address to physical address. - http://thread.gmane.org/gmane.linux.kernel.samsung-soc/3909 - Submitted by Sangbeom Kim - Merged by Kukjin Kim, ARM/S5P ARM ARCHITECTURES maintainer. == How to use == +---+ SecureId +---+ | Converter | -- | Renderer | +---+ +---+ ^| |^ ^ ^ || UVA || | | UVA | | UVA SecureId | || || | | +-+ | | +-+ +-+UVA by mmap | UMP | | | | UMP | | UMP | | | Lib | | | | Lib | | Lib | | +-+ | | +-+ +-+ | || || | | user space - || || | |kernel space |v v| | | | +---+ | |+--+ | | s5p-fimc | | || s3c-fb | | +---+ | |+--+ || || | ^ | +-+ +---+ +-+ +-+ | | | Ump |-|vb2|-| Ump | | Ump |--+ | | Drv | | sdvmm | | Drv | | Drv | | +-+ +---+ +-+ +-+ | | | | +---+ +---+ | VCM | |VCM| +---+ +---+ | | | | | +---+ | | |CMA| | | +---+ | DVA | | | | | +---+ | |SYS.MMU| | +---+ PA | | | v v v +---+ +---+ | FIMC| | FIMD| +---+ +---+ Basic flow - Output interface for source 1. Allocate discontiguous memory using UMP 2. Get User Virtual Address(aka UVA) 3. Send the UVA to the src(Output
RE: Memory allocation in Video4Linux
Hi,
Maybe VCM is helpful for you. Please refer to the following URL.
http://marc.info/?l=linux-mmm=129255940319217w=2
Best regards,
Jonghun Han
Wednesday, February 09, 2011 4:52 PM Hans Verkuil wrote:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Wednesday, February 09, 2011 4:52 PM
To: Wang, Wen W; Jozef Kruger
Cc: Kanigeri, Hari K; Iyer, Sundar; Yang, Jianwei; linux-media@vger.kernel.org
Subject: Re: Memory allocation in Video4Linux
On Wednesday, February 09, 2011 08:27:27 Wang, Wen W wrote:
Hi Hari,
You are right. What we need is virtual address.
Currently we alloc pages (alloc_pages()) for any request. Store those pages
for
an image buffer into a list. We also manage the virtual address for ISP by
ourself
(the range from 0 to 4GB) and the page table for our MMU which is independent
to
system MMU page table.
Assuming you are using video4linux for this driver, then you should take a
look at
the new videobuf2 framework that will appear in 2.6.39. It is already in the
media
tree (http://git.linuxtv.org/media_tree.git, see
include/media/videobuf2-core.h).
It is much better than the old videobuf framework, and in particular gives
the driver
much more control on how memory is allocated and used.
Regards,
Hans
Thanks
Wen
-Original Message-
From: Kanigeri, Hari K
Sent: 2011年2月9日 15:22
To: Iyer, Sundar; Wang, Wen W; Yang, Jianwei;
linux-media@vger.kernel.org;
umg-meego-handset-ker...@umglistsvr.jf.intel.com
Cc: Jozef Kruger
Subject: RE: Memory allocation in Video4Linux
-Original Message-
From: umg-meego-handset-kernel-boun...@umglistsvr.jf.intel.com
[mailto:umg-meego-handset-kernel-boun...@umglistsvr.jf.intel.com]
On Behalf Of Iyer, Sundar
Sent: Wednesday, February 09, 2011 12:20 PM
To: Wang, Wen W; Yang, Jianwei; linux-media@vger.kernel.org;
umg-meego- handset-ker...@umglistsvr.jf.intel.com
Cc: Jozef Kruger
Subject: Re: [Umg-meego-handset-kernel] Memory allocation in
Video4Linux
I remember some Continous Memory Allocator (CMA) being iterated
down a few versions on some mailing lists? IIRC, it is also for
large buffers and management for video IPs.
I believe CMA is for allocating physically contiguous memory and from
what Wen mentioned he also needs virtual memory management, which the
IOMMU will provide. Please check the open source discussion on CMA,
the last I heard CMA proposal was shot down.
Reference: http://www.spinics.net/lists/linux-media/msg26875.html
Wen, how are you currently allocating physical memory ?
Thank you,
Best regards,
Hari
翳 .n +% 遍荻 w .n 伐 {炳g n r■ ㄨ｛ 夸z罐zf＂
赙z_璁 :+v )撸
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in the
body
of a message to majord...@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
--
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
How to re-start m2m device after suspend ?
Hello, I don't know whether the way to restart m2m device after suspend is right or not. To go to suspend state, I think m2m device should stop the job even if there are remained jobs in ready queue. After suspend, driver should restart remained jobs in resume function without ioctl command like: VIDIOC_QBUF. According the m2m framework, device_run should be called to restart. And the device_run is called by v4l2_m2m_try_run called by v4l2_m2m_try_schedule and v4l2_m2m_job_finish. And v4l2_m2m_try_schedule is only for m2m framework. So in my opinion, if driver didn't call the v4l2_m2m_job_finish in suspend function, the resume function can start from v4l2_m2m_job_finish to restart the remained jobs. Is it right the way or is there anything recommended way ? Best regards, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: How to set global alpha to V4L2_BUF_TYPE_CAPTURE ?
Thanks for interesting. Ok, I will submit it using VIDIOC_S_CTRL. Best regards, -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, January 17, 2011 3:52 PM To: Jonghun Han Cc: linux-media@vger.kernel.org; pa...@osciak.com; 'Marek Szyprowski' Subject: Re: How to set global alpha to V4L2_BUF_TYPE_CAPTURE ? On Monday, January 17, 2011 04:44:54 Jonghun Han wrote: Hello, How to set global alpha to V4L2_BUF_TYPE_CAPTURE ? Samsung SoC S5PC210 has Camera interface and Video post processor named FIMC which can set the alpha value to V4L2_BUF_TYPE_CAPTURE. For example during color space conversion from YUV422 to ARGB, FIMC can set the alpha value to V4L2_BUF_TYPE_CAPTURE. I tried to find an available command to set it but I couldn't found it. That's right, there isn't. But there is fmt.win.global_alpha for Video Overlay Interface. So in my opinion VIDIOC_S_FMT is also suitable for V4L2_BUF_TYPE_CAPTURE*. How about using fmt.pix.priv in struct v4l2_format and fmt.pix_mp.reserved[0] in struct v4l2_format ? Not a good idea. This is really ideal for a control. We already have a somewhat similar control in the form of V4L2_CID_BG_COLOR. It's perfectly reasonable to add a V4L2_CID_ALPHA_COLOR (or something similar) where you set this up. The little available space in the format structs is too precious to use for something trivial like this :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
How to set global alpha to V4L2_BUF_TYPE_CAPTURE ?
Hello, How to set global alpha to V4L2_BUF_TYPE_CAPTURE ? Samsung SoC S5PC210 has Camera interface and Video post processor named FIMC which can set the alpha value to V4L2_BUF_TYPE_CAPTURE. For example during color space conversion from YUV422 to ARGB, FIMC can set the alpha value to V4L2_BUF_TYPE_CAPTURE. I tried to find an available command to set it but I couldn't found it. But there is fmt.win.global_alpha for Video Overlay Interface. So in my opinion VIDIOC_S_FMT is also suitable for V4L2_BUF_TYPE_CAPTURE*. How about using fmt.pix.priv in struct v4l2_format and fmt.pix_mp.reserved[0] in struct v4l2_format ? I welcome your opinion. Best regards, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
I was confused the source and destination.
I agree with you mostly.
In my opinion, the way how to notify the resolution change is return value
of the DQBUF.
But if we use DQBUF, there are some problem as below.
DQBUF means that the buffer has been operated already and application will
have the buffer's right.
Although application new QBUF destination buffers after changing
destination(CAPTURE),
driver cannot re-decode the I-frame which has the resolution change
information
because the I-frame has been dequeued already.
If application re-QBUF the buffer, the buffer sequence will be out of order
as below.
Original: I - B - B .
Out of order: missed - B - B - I .
How do you think about the following sequence.
1. getting the resolution change from the MFC H/W
2. copy the buffer to driver's internal memory.
3. send the result with DQBUF
4. changing destination buffers by application
5. QBUF for new destination buffers
6. in the first vb2_try_schedule
re-decode the driver's internal buffer instead of the B frame.
7. in the next vb2_try_schedule
decode the B frame in order.
I also welcome your comments.
Best regards,
-Original Message-
From: Kamil Debski [mailto:k.deb...@samsung.com]
Sent: Friday, January 14, 2011 4:24 PM
To: 'Jonghun Han'; linux-media@vger.kernel.org; linux-samsung-
s...@vger.kernel.org
Cc: Marek Szyprowski; pa...@osciak.com; kyungmin.p...@samsung.com;
jaeryul...@samsung.com; kgene@samsung.com
Subject: RE: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
-Original Message-
From: Jonghun Han [mailto:jonghun@samsung.com]
Hi,
Kamil Debski wrote:
snip
+/* Reqeust buffers */
+static int vidioc_reqbufs(struct file *file, void *priv,
+ struct v4l2_requestbuffers
*reqbufs)
+{
+ struct s5p_mfc_dev *dev = video_drvdata(file);
+ struct s5p_mfc_ctx *ctx = priv;
+ int ret = 0;
+ unsigned long flags;
+
+ mfc_debug_enter();
+ mfc_debug(Memory type: %d\n, reqbufs-memory);
+ if (reqbufs-memory != V4L2_MEMORY_MMAP) {
+ mfc_err(Only V4L2_MEMORY_MAP is supported.\n);
+ return -EINVAL;
+ }
+ if (reqbufs-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ /* Can only request buffers after an instance has been
opened.*/
+ if (ctx-state == MFCINST_DEC_GOT_INST) {
+ /* Decoding */
+ if (ctx-output_state != QUEUE_FREE) {
+ mfc_err(Bufs have already been
requested.\n);
+ return -EINVAL;
+ }
+ ret = vb2_reqbufs(ctx-vq_src, reqbufs);
+ if (ret) {
+ mfc_err(vb2_reqbufs on output failed.\n);
+ return ret;
+ }
+ mfc_debug(vb2_reqbufs: %d\n, ret);
+ ctx-output_state = QUEUE_BUFS_REQUESTED;
+ }
+ } else if (reqbufs-type ==
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ if (ctx-capture_state != QUEUE_FREE) {
+ mfc_err(Bufs have already been requested.\n);
+ return -EINVAL;
+ }
+ ctx-capture_state = QUEUE_BUFS_REQUESTED;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ if (ret) {
+ mfc_err(vb2_reqbufs on capture failed.\n);
+ return ret;
+ }
+ if (reqbufs-count ctx-dpb_count) {
+ mfc_err(Not enough buffers allocated.\n);
+ reqbufs-count = 0;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ return -ENOMEM;
+ }
+ ctx-total_dpb_count = reqbufs-count;
+ ret = s5p_mfc_alloc_dec_buffers(ctx);
+ if (ret) {
+ mfc_err(Failed to allocate decoding buffers.\n);
+ reqbufs-count = 0;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ return -ENOMEM;
+ }
+ if (ctx-dst_bufs_cnt == ctx-total_dpb_count) {
+ ctx-capture_state = QUEUE_BUFS_MMAPED;
+ } else {
+ mfc_err(Not all buffers passed to buf_init.\n);
+ reqbufs-count = 0;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ s5p_mfc_release_dec_buffers(ctx);
+ return -ENOMEM;
+ }
+ if (s5p_mfc_ctx_ready(ctx)) {
+ spin_lock_irqsave(dev-condlock, flags);
+ set_bit(ctx-num, dev-ctx_work_bits);
+ spin_unlock_irqrestore(dev-condlock, flags);
+ }
+ s5p_mfc_try_run(dev);
+ s5p_mfc_wait_for_done_ctx(ctx,
+
S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET, 1);
+ }
+ mfc_debug_leave();
+ return ret;
+}
I don't know how to handle the followings.
So I
RE: Memory sharing issue by application on V4L2 based device driver with system mmu.
Sorry for late reply. Samsung SoC C210 has many multimedia IPs. Each IP has its own MMU named SYSTEM MMU like CPU's MMU. So it can handle discontiguous memory using device own virtual address. What Inki Dae wants to discuss is how to allocate the memory and how to share it with other multimedia IPs. Thank you for interesting. Best regards, -Original Message- From: linux-fbdev-ow...@vger.kernel.org [mailto:linux-fbdev- ow...@vger.kernel.org] On Behalf Of Konrad Rzeszutek Wilk Sent: Wednesday, January 12, 2011 2:35 AM To: Jonghun Han Cc: 'InKi Dae'; linux-media@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 'linux-fbdev'; kyungmin.p...@samsung.com Subject: Re: Memory sharing issue by application on V4L2 based device driver with system mmu. .. snip.. But 64KB or 1MB physically contiguous memory is better than 4KB page in the point of performance. Could you explain that in more details please? I presume you are talking about a CPU that has a MMU unit, right? -- To unsubscribe from this list: send the line unsubscribe linux-fbdev 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: [RFC/PATCH v6 3/4] MFC: Add MFC 5.1 V4L2 driver
Hi,
Kamil Debski wrote:
snip
+/* Reqeust buffers */
+static int vidioc_reqbufs(struct file *file, void *priv,
+ struct v4l2_requestbuffers
*reqbufs)
+{
+ struct s5p_mfc_dev *dev = video_drvdata(file);
+ struct s5p_mfc_ctx *ctx = priv;
+ int ret = 0;
+ unsigned long flags;
+
+ mfc_debug_enter();
+ mfc_debug(Memory type: %d\n, reqbufs-memory);
+ if (reqbufs-memory != V4L2_MEMORY_MMAP) {
+ mfc_err(Only V4L2_MEMORY_MAP is supported.\n);
+ return -EINVAL;
+ }
+ if (reqbufs-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ /* Can only request buffers after an instance has been
opened.*/
+ if (ctx-state == MFCINST_DEC_GOT_INST) {
+ /* Decoding */
+ if (ctx-output_state != QUEUE_FREE) {
+ mfc_err(Bufs have already been
requested.\n);
+ return -EINVAL;
+ }
+ ret = vb2_reqbufs(ctx-vq_src, reqbufs);
+ if (ret) {
+ mfc_err(vb2_reqbufs on output failed.\n);
+ return ret;
+ }
+ mfc_debug(vb2_reqbufs: %d\n, ret);
+ ctx-output_state = QUEUE_BUFS_REQUESTED;
+ }
+ } else if (reqbufs-type ==
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ if (ctx-capture_state != QUEUE_FREE) {
+ mfc_err(Bufs have already been requested.\n);
+ return -EINVAL;
+ }
+ ctx-capture_state = QUEUE_BUFS_REQUESTED;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ if (ret) {
+ mfc_err(vb2_reqbufs on capture failed.\n);
+ return ret;
+ }
+ if (reqbufs-count ctx-dpb_count) {
+ mfc_err(Not enough buffers allocated.\n);
+ reqbufs-count = 0;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ return -ENOMEM;
+ }
+ ctx-total_dpb_count = reqbufs-count;
+ ret = s5p_mfc_alloc_dec_buffers(ctx);
+ if (ret) {
+ mfc_err(Failed to allocate decoding buffers.\n);
+ reqbufs-count = 0;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ return -ENOMEM;
+ }
+ if (ctx-dst_bufs_cnt == ctx-total_dpb_count) {
+ ctx-capture_state = QUEUE_BUFS_MMAPED;
+ } else {
+ mfc_err(Not all buffers passed to buf_init.\n);
+ reqbufs-count = 0;
+ ret = vb2_reqbufs(ctx-vq_dst, reqbufs);
+ s5p_mfc_release_dec_buffers(ctx);
+ return -ENOMEM;
+ }
+ if (s5p_mfc_ctx_ready(ctx)) {
+ spin_lock_irqsave(dev-condlock, flags);
+ set_bit(ctx-num, dev-ctx_work_bits);
+ spin_unlock_irqrestore(dev-condlock, flags);
+ }
+ s5p_mfc_try_run(dev);
+ s5p_mfc_wait_for_done_ctx(ctx,
+
S5P_FIMV_R2H_CMD_INIT_BUFFERS_RET, 1);
+ }
+ mfc_debug_leave();
+ return ret;
+}
I don't know how to handle the followings.
So I suggest that in reqbufs-type == V4L2_BUF_TYPE_VIDEO_OUTPUT case,
how about return -EINVAL if reqbufs-count is bigger than 1.
Because if reqbufs-count is bigger than 1, it is hard to handle the encoded
input stream.
For example: Dynamic resolution change
Dynamic resolution change means that resolution can be changed at any
I-frame with header on the fly during streaming.
MFC H/W can detect it after getting decoding command from the driver.
If the dynamic resolution change is detected by MFC H/W,
driver should let application know the fact to do the following Sequence 1
by application.
Sequence 1:
streamoff - munmap - reqbufs(0) - S_FMT(changed resolution) - querybuf
- mmap - re-QBUF with the I-frame - STREAMON - ...
Why it is hard to handle the encoded input stream in multiple input stream
case is the following Sequence 2.
Sequence 2:
QBUF(0) - QBUF(1: resolution changed I-frame) - QBUF(2: already changed)
- QBUF(3: already changed) - DQBUF(0) - DQBUF(1): return fail - ...
Application cannot know the resolution change in the QBUF ioctl.
Driver will return 0 at the QBUF because all parameters are fine.
But after sending the decode command to MFC H/W, driver can know that the
I-frame needs to change resolution.
In that case driver can return error at the DQBUF of the buffer.
In the sequence 2, application can know the resolution change in the
DQBUF(1).
So the application should re-QBUF the buffer 2, 3 after Sequence 1.
It is hard to re-control the buffers which are already queued in the point
of
Query for inter-process buffer sharing
Hello, How do you think about adding a new callback function which makes allocator for vb2 fill the reserved field in v4l2_buffer as below. As-Is: VIDIOC_QUERYBUF - v4l2_m2m_querybuf - vb2_querybuf - __fill_v4l2_buffer To-Be: VIDIOC_QUERYBUF - v4l2_m2m_querybuf - vb2_querybuf - __fill_v4l2_buffer + vb2_mem_ops.fill_v4l2_buffer I want to use the reserved field as for process unique key to share the buffer between inter-process. When I want to send a buffer which is allocated by A device to other process, I want to get the process unique key from VIDIOC_QUERYBUF. The process which gets the process unique key from other process will make user virtual address from the key in any other way. And then send it to B device using QBUF with USERPTR buffer type. How do you think about this concept ? Process A Process B 1. VIDIOC_QUERYBUF to get the process unique key 2. VIDIOC_DQBUF 3. Send the process unique key to Process B ---Process unique key 4. Make a user virtual address from the process unique key 5. VIDIOC_QBUF with user virtual address 6. find the paddr or device address from the user virtual addr. in videobuf2 7. H/W operation. SCM_RIGHTS can be the solution for inter-process buffer sharing. http://blog.toidinamai.de/en/programming/SCM_RIGHTS But it has risk that other process can also control the device using the shared file descriptor. So I'm trying to make another solution. Best regards, -- 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: Memory sharing issue by application on V4L2 based device driver with system mmu.
Hello, There are two reasons why malloc isn't suitable for it. The first is that malloc doesn't allocate memory when malloc is called. So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF. The second is that malloc uses 4KB page allocation. SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when TLB miss is occurred. So as possible as physically contiguous pages are needed for performance enhancement. So new allocator which can clear two main issues is needed. Best regards, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of InKi Dae Sent: Thursday, January 06, 2011 10:25 PM To: linux-media@vger.kernel.org Subject: Memory sharing issue by application on V4L2 based device driver with system mmu. Hello, all. I'd like to discuss memory sharing issue by application on v4l2 based device driver with system mmu and get some advices about that. Now I am working on Samsung SoC C210 platform and this platform has some multimedia devices with system mmu such as fimc, and mfc also we have implemented device drivers for them. those drivers are based on V4L2 framework with videobuf2. for system mmu of each device, we used VCM(Virtual Contiguous Memory) framework. Simply, VCM framework provides physical memory, device virtual memory allocation and memory mapping between them. when device driver is initialized or operated by user application, each driver allocates physical memory and device virtual memory and then mapping using VCM interface. refer to below link for more detail. http://www.spinics.net/lists/linux-media/msg26548.html Physical memory access process is as the following. DVA PA device -- system mmu -- physical memory DVA : device virtual address. PA : physical address. like this, device virtual address should be set to buffer(source or destination) register of multimedia device. the problem is that application want to share own memory with any device driver to avoid memory copy. in other words, user-allocated memory could be source or destination memory of multimedia device driver. let's see the diagram below. user application | | | | | 1. UVA(allocated by malloc) | | ＼|/ 2. UVA(in page unit) - multimedia device driver --- videobuf2 | || ^ | || | | || --- ||3. PA(in page unit) || || 4. PA(in page unit) 6. DVA || || || | ＼|/ | | Virtual Contiguous Memory - | | | | ^ | | | | | 5. map PA to DVA | | | | | | | | - - PA : physical address. UVA : user virtual address. DVA : device virtual address. 1. user application allocates user space memory through malloc function and sending it to multimedia device driver based on v4l2 framework through userptr feature. 2, 3. multimedia device driver gets translated physical address from videobuf2 framework in page unit. 4, 5. multimedia device driver gets allocated device virtual address and mapping it to physical address and then mapping them through VCM interface. 6. multimedia device driver sets device virtual address from VCM to buffer register. the diagram above is fully theoretical so I wonder that this way is reasonable and has some problems also what should be considered. thank you for your interesting. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 7/9] media: MFC: Add MFC v5.1 V4L2 driver
Hi Kamil, Kamil Debski wrote: Hi, Thanks for the comment. Some of them include my code, which will I comment below. My review also imply Kamil's original patch. snip +#define MFC_NUM_CONTEXTS 4 How about use MFC_NUM_INSTANT instead MFC_NUM_CONTEXTS ? Because too many terms can make confusion. An instance means an MFC HW instance. Context is used for each open file handle. I know that. But as I know each handle can have only single MFC H/W instance. So I wish to reduce the terms. Is there anything I missed ? snip What's the difference btw num and inst_no ? It looks very similar. The inst_no is the number of hardware instance in MFC. Num on the other hand is the number of context used by an open file handle. The inst_no made by MFC H/W has the same rule with num made by your code. So in my opinion it is always the same. How do you think about that ? snip Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland RD Center -- 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: Memory sharing issue by application on V4L2 based device driver with system mmu.
Hello, That's not a translation issue. What I mention is the size of allocation. The malloc uses 4KB page allocation and SYS.MMU can handle it. But 64KB or 1MB physically contiguous memory is better than 4KB page in the point of performance. Best regards, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of InKi Dae Sent: Friday, January 07, 2011 11:17 AM To: Jonghun Han Cc: linux-media@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-fbdev; kyungmin.p...@samsung.com Subject: Re: Memory sharing issue by application on V4L2 based device driver with system mmu. thank you for your comments. your second comment has no any problem as I said before, user virtual addess could be translated in page unit. but the problem, as you said, is that when cpu access to the memory in user mode, the memory allocated by malloc, page fault occurs so we can't find pfn to user virtual address. I missed that. but I think we could resolve this one. as before, user application allocates memory through malloc function and then send it to device driver(using userptr feature). if the pfn is null when device driver translated user virtual address in page unit then it allocates phsical memory in page unit using some interface such as alloc_page() and then mapping them. when pfn is null, to check it and allocate physical memory in page unit could be processed by videobuf2. of course, videobuf2 has no any duty considered for system mmu. so videobuf2 just provides callback for 3rd party and any platform with system mmu such as Samsung SoC C210 implements the function(allocating physical memory and mapping it) and registers it to callback of videobuf2. by doing so, I think your first comment could be cleared. please, feel free to give me your opinion and pointing out. thank you. 2011년 1월 7일 오전 8:57, Jonghun Han jonghun@samsung.com님의 말: Hello, There are two reasons why malloc isn't suitable for it. The first is that malloc doesn't allocate memory when malloc is called. So driver or vb2 cannot find PFN for it in the VIDIOC_QBUF. The second is that malloc uses 4KB page allocation. SYS.MMU(IO-MMU) can handle scattered memory. But it has a penalty when TLB miss is occurred. So as possible as physically contiguous pages are needed for performance enhancement. So new allocator which can clear two main issues is needed. Best regards, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of InKi Dae Sent: Thursday, January 06, 2011 10:25 PM To: linux-media@vger.kernel.org Subject: Memory sharing issue by application on V4L2 based device driver with system mmu. Hello, all. I'd like to discuss memory sharing issue by application on v4l2 based device driver with system mmu and get some advices about that. Now I am working on Samsung SoC C210 platform and this platform has some multimedia devices with system mmu such as fimc, and mfc also we have implemented device drivers for them. those drivers are based on V4L2 framework with videobuf2. for system mmu of each device, we used VCM(Virtual Contiguous Memory) framework. Simply, VCM framework provides physical memory, device virtual memory allocation and memory mapping between them. when device driver is initialized or operated by user application, each driver allocates physical memory and device virtual memory and then mapping using VCM interface. refer to below link for more detail. http://www.spinics.net/lists/linux-media/msg26548.html Physical memory access process is as the following. DVA PA device -- system mmu -- physical memory DVA : device virtual address. PA : physical address. like this, device virtual address should be set to buffer(source or destination) register of multimedia device. the problem is that application want to share own memory with any device driver to avoid memory copy. in other words, user-allocated memory could be source or destination memory of multimedia device driver. let's see the diagram below. user application | | | | | 1. UVA(allocated by malloc) | | ＼|/ 2. UVA(in page unit) - multimedia device driver --- videobuf2 | || ^ | || | | || --- ||3. PA(in page unit
RE: [PATCH 7/9] media: MFC: Add MFC v5.1 V4L2 driver
My review also imply Kamil's original patch.
Jeongtae Park wrote:
Multi Format Codec v5.1 is a module available on S5PC110 and S5PC210
Samsung SoCs. Hardware is capable of handling a range of video codecs
and this driver provides V4L2 interface for video decoding encoding.
Reviewed-by: Peter Oh jaeryul...@samsung.com
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
---
snip
+
+/* Display status */
+#define S5P_FIMV_DEC_STATUS_DECODING_ONLY0
+#define S5P_FIMV_DEC_STATUS_DECODING_DISPLAY 1
+#define S5P_FIMV_DEC_STATUS_DISPLAY_ONLY 2
+#define S5P_FIMV_DEC_STATUS_DECODING_EMPTY 3
+#define S5P_FIMV_DEC_STATUS_DECODING_STATUS_MASK 7
+#define S5P_FIMV_DEC_STATUS_PROGRESSIVE (03)
+#define S5P_FIMV_DEC_STATUS_INTERLACE(13)
+#define S5P_FIMV_DEC_STATUS_INTERLACE_MASK (13)
+#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_TWO (04)
+#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_FOUR (14)
+#define S5P_FIMV_DEC_STATUS_CRC_NUMBER_MASK (14)
+#define S5P_FIMV_DEC_STATUS_CRC_GENERATED(15)
+#define S5P_FIMV_DEC_STATUS_CRC_NOT_GENERATED(05)
+#define S5P_FIMV_DEC_STATUS_CRC_MASK (15)
Use like (0 3), (1 3) ...
snip
+/* Enumerate format */
+static int vidioc_enum_fmt(struct v4l2_fmtdesc *f, bool mplane, bool out,
+ enum s5p_mfc_node_type
node)
+{
+ struct s5p_mfc_fmt *fmt;
+ int i, j = 0;
+
+ if (node == MFCNODE_INVALID)
+ return 0;
+
+ for (i = 0; i ARRAY_SIZE(formats); ++i) {
+ if (mplane formats[i].num_planes == 1)
+ continue;
+ else if (!mplane formats[i].num_planes 1)
+ continue;
+ if (node == MFCNODE_DECODER) {
+ if (out formats[i].type != MFC_FMT_DEC)
+ continue;
+ else if (!out formats[i].type != MFC_FMT_RAW)
+ continue;
+ } else if (node == MFCNODE_ENCODER) {
+ if (out formats[i].type != MFC_FMT_RAW)
+ continue;
+ else if (!out formats[i].type != MFC_FMT_ENC)
+ continue;
+ }
+
+ if (j == f-index) {
+ fmt = formats[i];
+ strlcpy(f-description, fmt-name,
+ sizeof(f-description));
+ f-pixelformat = fmt-fourcc;
+
+ return 0;
+ }
+
+ ++j;
+ }
+
+ return -EINVAL;
+}
+
At a glance, no needed to use j variable.
if (i == f-index) instead of if (j == f-index)
snip
+/* Get format */
+static int vidioc_g_fmt(struct file *file, void *priv, struct v4l2_format
*f)
+{
+ struct s5p_mfc_ctx *ctx = priv;
+
+ mfc_debug_enter();
+ mfc_debug(f-type = %d ctx-state = %d\n, f-type, ctx-state);
+ if (f-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
+ ctx-state == MFCINST_GOT_INST) {
+ /* If the MFC is parsing the header,
+ * so wait until it is finished */
+ s5p_mfc_clean_ctx_int_flags(ctx);
+ s5p_mfc_wait_for_done_ctx(ctx,
S5P_FIMV_R2H_CMD_SEQ_DONE_RET,
+ 1);
+ }
+ if (f-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
+ ctx-state = MFCINST_HEAD_PARSED
+ ctx-state = MFCINST_ABORT) {
+ /* This is run on CAPTURE (deocde output) */
+ /* Width and height are set to the dimensions
+of the movie, the buffer is bigger and
+further processing stages should crop to this
+rectangle. */
+ f-fmt.pix_mp.width = ctx-buf_width;
+ f-fmt.pix_mp.height = ctx-buf_height;
+ f-fmt.pix_mp.field = V4L2_FIELD_NONE;
+ f-fmt.pix_mp.num_planes = 2;
+ /* Set pixelformat to the format in which MFC
+outputs the decoded frame */
+ f-fmt.pix_mp.pixelformat = V4L2_PIX_FMT_NV12MT;
+ f-fmt.pix_mp.plane_fmt[0].bytesperline = ctx-buf_width;
+ f-fmt.pix_mp.plane_fmt[0].sizeimage = ctx-luma_size;
+ f-fmt.pix_mp.plane_fmt[1].bytesperline = ctx-buf_width;
+ f-fmt.pix_mp.plane_fmt[1].sizeimage = ctx-chroma_size;
+ } else if (f-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+ /* This is run on OUTPUT
+The buffer contains compressed image
+so width and height have no meaning */
+ f-fmt.pix_mp.width = 1;
+ f-fmt.pix_mp.height = 1;
+ f-fmt.pix_mp.field = V4L2_FIELD_NONE;
+ f-fmt.pix_mp.plane_fmt[0].bytesperline = ctx-
dec_src_buf_size;
+
RE: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ?
Hi, Any comment for this ? In my opinion v4l2 spec is not accurate in this topic. Because VIDIOC_REQBUFS describes count is only used in V4L2_MEMORY_MMAP as below. __u32 count The number of buffers requested or granted. This field is only used when memory is set to V4L2_MEMORY_MMAP. But there is no comment in QBUF and DQBUF part about index. So I am confused. If an index isn't needed, how to driver handle it ? Best regards, Jonghun Han, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Jonghun Han Sent: Saturday, December 11, 2010 2:10 PM To: linux-media@vger.kernel.org Subject: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ? Hi, I wonder that a index should be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case. If it isn't needed, should driver return virtual address gotten from application on the fly with the VIDIOC_DQBUF ioctl ? Best regards, Jonghun Han, -- 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: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ?
Hi Laurent Pinchart, Thanks you for reply. It makes sense. Best regards, Jonghun Han -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Tuesday, December 14, 2010 8:00 PM To: Jonghun Han Cc: linux-media@vger.kernel.org; 'Hans Verkuil'; mche...@redhat.com Subject: Re: Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ? Hi Jonghun, On Tuesday 14 December 2010 11:51:17 Jonghun Han wrote: Hi, Any comment for this ? In my opinion v4l2 spec is not accurate in this topic. Because VIDIOC_REQBUFS describes count is only used in V4L2_MEMORY_MMAP as below. __u32 count The number of buffers requested or granted. This field is only used when memory is set to V4L2_MEMORY_MMAP. But there is no comment in QBUF and DQBUF part about index. So I am confused. If an index isn't needed, how to driver handle it ? The spec should be fixed. VIDIOC_REQBUFS needs to be called for USERPTR as well, and the buffer count is definitely used. On Saturday, December 11, 2010 2:10 PM Jonghun Han wrote: I wonder that a index should be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case. If it isn't needed, should driver return virtual address gotten from application on the fly with the VIDIOC_DQBUF ioctl ? VIDIOC_DQBUF is supposed to fill the v4l2_buffer structure with the index and the userspace virtual address (among other information). If it doesn't, it's a driver bug. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
Should a index be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case ?
Hi, I wonder that a index should be passed on the fly with the VIDIOC_QBUF ioctl in V4L2_MEMORY_USERPTR case. If it isn't needed, should driver return virtual address gotten from application on the fly with the VIDIOC_DQBUF ioctl ? Best regards, Jonghun Han, -- 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
How to control streaming in non-periodic system ?
Hi,
I'm looking for a general solution in camera preview application.
When I use the following sequence, there is no problem in normal case.
Normally application sleeps in poll and then will be waked up by Camera VSYNC.
while (1) {
poll
DQBUF
memcpy to FB
QBUF
}
But sometimes there is non-periodic long delay more than 1sec in application.
So before calling poll some buffers has been already passed to outgoing queue.
So in a single time quantum(schedule) many memcpy operations are done
on FB like:
poll - DQBUF - memcpy - QBUF - poll(no sleep) - DQBUF - memcpy...
So preview isn't unnatural owing to memcpy without delay.
In that case what is a general solution ?
In my opinion frame drop can be a solution.
So now I changed the sequence as below.
open device with non-block flag.
while (1) {
while (ret != -EAGAIN) {
idx = dp_idx;
ret = DQBUF(dq_idx);
}
if (idx -1) {
poll
DQBUF(idx)
}
memcpy to FB
QBUF
}
Best regards,
Jonghun Han,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC/PATCH 2/4] [media] s5p-fimc: Porting to videobuf 2
Sylwester Nawrocki wrote:
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Sylwester Nawrocki
Sent: Wednesday, December 01, 2010 11:36 PM
To: linux-media@vger.kernel.org; linux-samsung-...@vger.kernel.org
Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com;
s.nawro...@samsung.com
Subject: [RFC/PATCH 2/4] [media] s5p-fimc: Porting to videobuf 2
Porting to videobuf 2 and minor cleanup.
Separate videobuf_queue_ops are are created for m2m
and capture video nodes.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
snip
Hi,
@@ -968,6 +934,11 @@ static int fimc_m2m_streamon(struct file *file, void
*priv,
enum v4l2_buf_type type)
{
struct fimc_ctx *ctx = priv;
+
+ /* The source and target color format need to be set */
+ if (~ctx-state (FIMC_DST_FMT | FIMC_SRC_FMT))
+ return -EINVAL;
+
return v4l2_m2m_streamon(file, ctx-m2m_ctx, type);
}
You had better divide a state checking according to v4l2_buf_type to make
easier
for application to use it. For example application can have two threads
for handling m2m device. The one is for source control(OUTPUT) and
the other is for destination control(CAPTURE). If state checking is not
divided,
application should consider other thread's state whether VIDIOC_S_FMT was
called or not
before VIDIOC_STREAMON.
BRs,
--
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 7/7] v4l: videobuf2: add CMA allocator
Pawel Osciak wrote:
-Original Message-
From: Pawel Osciak [mailto:pa...@osciak.com]
Sent: Sunday, December 05, 2010 7:47 AM
To: Marek Szyprowski; Jonghun Han
Cc: linux-media@vger.kernel.org; kyungmin.p...@samsung.com
Subject: Re: [PATCH 7/7] v4l: videobuf2: add CMA allocator
Hi,
please see my comments below.
Also, if I could suggest something, please cut the code between
functions, not inside them, it'll make it easier for others to find
that location in the original code.
On Wed, Dec 1, 2010 at 00:56, Marek Szyprowski m.szyprow...@samsung.com
wrote:
Hello,
On Wednesday, December 01, 2010 9:36 AM Jonghun Han wrote:
Marek Szyprowski wrote:
2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
From: Pawel Osciak p.osc...@samsung.com
Add support for the CMA contiguous memory allocator to videobuf2.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
Hi Marek,
snip
+static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long
size)
static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long
size,
const struct
vb2_alloc_ctx
*alloc_ctx)
alloc_ctx can be useful for many cases.
Yes, right, I will add it in the next version.
Actually, I don't think so. Can you give an example of one of those
many cases? There is no need to add unused arguments that can be
useful in future just for the sake of future extensions, especially
not in the kernel in such sensitive code. This function can
potentially be called on each frame. And even more importantly, the
whole allocator interface has been designed so that functions will not
have to be vb2- or media-specific. Ideally, we should be able to hook
up functions from mm and other modules. And such functions either use
only vaddr and size, or have means of finding their contexts
otherwise.
If I remember correctly, this approach was actually suggested by
Laurent and it makes a lot of sense. We want to be able to use third
party kernel functions in allocators as much as possbile.
Hi,
What I mentioned many cases is related in VCMM(Virtual Contiguous Memory
Manager).
http://www.linuxsymposium.org/2010/view_abstract.php?content_key=64
When IOMMU(SYS.MMU) is used for device, each device uses its own device
virtual address
not a physical address or virtual address. VCMM device id is needed to get
the device virtual address.
But in vb2_cma_get_userptr we cannot find the VCMM device id.
If vb2_alloc_ctx is added as argument in vb2_cma_get_userptr and VCMM device
id is set
in vb2_cma_conf on vb2_cma_init, we can find VCMM device id in
vb2_cma_get_userptr.
+{
+ struct vb2_cma_buf *buf;
+ unsigned long paddr = 0;
+ int ret;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+
+ buf-vma = vb2_get_userptr(vaddr);
vb2_get_vma looks good instead of vb2_get_userptr.
How do you think about this ?
Right, this will make the code easier to understand. Thanks for the
hint!
Actually, I don't think it's a good idea. I think you have the whole
concept backwards.
vb2 doesn't care what is returned from this function. All it wants is
a cookie from this allocator. From the point of view where this
function is used, it is get_userptr not get_vma, vb2 wants to get
something describing a user pointer, but that does not have to mean a
vma. Moreover, in any case, the core does not care at all what it is
it is getting, since it *never uses it*. Changing the name of this
function would actually make it confusing.
In other words: this function is an implementation of
get_userptr_private_allocator_cookie allocator interface function
and *not* a get_vma function implementation. It does not have to be
a vma and the core does not care what it is anyway.
What I mentioned is vb2_get_userptr not
vb2_cma_get_userptr(vb2_mem_ops-get_userptr).
vb2_get_userptr is used in vb2_cma_get_userptr to find struct vm_area in
videobuf2-memops.c
Cookie concept is very nice. I absolutely agree with you.
+ if (!buf-vma) {
+ printk(KERN_ERR Failed acquiring VMA for vaddr
0x%08lx\n,
+ vaddr);
+ ret = -EINVAL;
+ goto done;
+ }
+
+ ret = vb2_contig_verify_userptr(buf-vma, vaddr, size,
paddr);
+ if (ret) {
+ vb2_put_userptr(buf-vma);
+ goto done;
+ }
+
In vb2_contig_verify_userptr, vma is re-found via find_vma although it
has
been checked after vb2_get_userptr.
Why double checking is needed ?
I'm not sure. I must check this core again, maybe it can be simplified a
bit.
I agree, it seems
RE: RFC: Problem of using v4l2 spec with codec function
Hi, If MFC(encoder/decoder) has a single node, how to know application's object before VIDIOC_S_FMT calling ? VIDIOC_S_CTRL can be called before VIDIOC_S_FMT. For example user wants to use MFC as an *encoder*, but user calls VIDIOC_S_CTRL with *decoder* command by mistake. In that case driver cannot return fail because it cannot know the purpose before VIDIOC_S_FMT calling. When VIDIOC_S_FMT is called to use MFC as an *encoder* after VIDIOC_S_CTRL, driver will be confused how to handle it. But in two nodes solution decoder command via VIDIOC_S_CTRL will be failed on encoder device node. -- Best regards, Jonghun Han -- -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Sunday, December 05, 2010 7:55 AM To: Kamil Debski Cc: Hans Verkuil; Jonghun Han; Laurent Pinchart; jaeryul...@samsung.com; linux- me...@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi all, I would side with Laurent on this. Judging by formats seems to be enough for this driver and it has great, in my opinion, advantages of a) not overcomplicating things for applications b) not adding new pieces to the API... -- Best regards, Pawel Osciak -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 7/7] v4l: videobuf2: add CMA allocator
Marek Szyprowski wrote:
2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
From: Pawel Osciak p.osc...@samsung.com
Add support for the CMA contiguous memory allocator to videobuf2.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
Hi Marek,
snip
+static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size)
static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long size,
const struct vb2_alloc_ctx
*alloc_ctx)
alloc_ctx can be useful for many cases.
+{
+ struct vb2_cma_buf *buf;
+ unsigned long paddr = 0;
+ int ret;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+
+ buf-vma = vb2_get_userptr(vaddr);
vb2_get_vma looks good instead of vb2_get_userptr.
How do you think about this ?
+ if (!buf-vma) {
+ printk(KERN_ERR Failed acquiring VMA for vaddr
0x%08lx\n,
+ vaddr);
+ ret = -EINVAL;
+ goto done;
+ }
+
+ ret = vb2_contig_verify_userptr(buf-vma, vaddr, size, paddr);
+ if (ret) {
+ vb2_put_userptr(buf-vma);
+ goto done;
+ }
+
In vb2_contig_verify_userptr, vma is re-found via find_vma although it has
been checked after vb2_get_userptr.
Why double checking is needed ?
+ buf-size = size;
+ buf-paddr = paddr;
+
+ return buf;
+
+done:
+ kfree(buf);
+ return ERR_PTR(ret);
+}
+
snip
BRs,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Laurent Pinchart wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, November 29, 2010 6:20 PM To: Hans Verkuil Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi, snip If so, then I think creating a so-called 'private' control for your hardware would be the best way to go. As an example of private controls search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. I would rely on formats. If the input format is YUV and the output format is MPEG, it's pretty obvious that the hardware should be encoding. If the formats are the other way around, then the hardware should be decoding. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC: Problem of using v4l2 spec with codec function
Hi, In two nodes case, application cannot know the feature via VIDIOC_QUERYCAP. Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE So application should call VIDIOC_G_FMT to recognize the feature. BRs, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Jonghun Han Sent: Monday, November 29, 2010 8:49 PM To: 'Laurent Pinchart'; 'Hans Verkuil' Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: RE: RFC: Problem of using v4l2 spec with codec function Laurent Pinchart wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, November 29, 2010 6:20 PM To: Hans Verkuil Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi, snip If so, then I think creating a so-called 'private' control for your hardware would be the best way to go. As an example of private controls search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. I would rely on formats. If the input format is YUV and the output format is MPEG, it's pretty obvious that the hardware should be encoding. If the formats are the other way around, then the hardware should be decoding. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: RFC: Problem of using v4l2 spec with codec function
Hi, Thanks for comment. I hope we would submit two nodes driver for encoder, decoder within 2010. BRs, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Hans Verkuil Sent: Monday, November 29, 2010 9:17 PM To: Jonghun Han Cc: 'Laurent Pinchart'; jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: RE: RFC: Problem of using v4l2 spec with codec function Hi, In two nodes case, application cannot know the feature via VIDIOC_QUERYCAP. Because decoder and encoder return the same CAPABILITY. OUTPUT and CAPTURE So application should call VIDIOC_G_FMT to recognize the feature. The current V4L API is not good enough to determine what each video node can do. The upcoming media controller API should help in that. For the time being you should just assume that applications know what they are doing. Anyway, I think having two device nodes is a perfectly valid solution. Particularly for more complex scenarios. Regards, Hans BRs, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Jonghun Han Sent: Monday, November 29, 2010 8:49 PM To: 'Laurent Pinchart'; 'Hans Verkuil' Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: RE: RFC: Problem of using v4l2 spec with codec function Laurent Pinchart wrote: -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Monday, November 29, 2010 6:20 PM To: Hans Verkuil Cc: jaeryul...@samsung.com; linux-media@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi, snip If so, then I think creating a so-called 'private' control for your hardware would be the best way to go. As an example of private controls search for the V4L2_CID_MPEG_CX2341X_BASE define in videodev2.h. I would rely on formats. If the input format is YUV and the output format is MPEG, it's pretty obvious that the hardware should be encoding. If the formats are the other way around, then the hardware should be decoding. Right. But.. If VIDIOC_S_CTRL is called before VIDIOC_S_FMT, how to distinguish them ? In my opinion decoder and encoder can have own control Ids. For example, After VIDIOC_S_CTRL related in decoder, if VIDIOC_S_FMT for encoder is called how to return it ? VIDIOC_S_CTRL has been succeeded because driver cannot know whether decoder or encoder. And then is it right that VIDIOC_S_FMT for encoder is failed due to VIDIOC_S_CTRL for decoder ? Can two nodes(encoder, decoder) be the solution ? BRs, -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
