[PATCH] dma-buf: Expose buffer size to userspace
Each dma-buf has an associated size and it's reasonable for userspace
to want to know what it is.
Since userspace already has an fd, expose the size using the
size = lseek(fd, SEEK_END, 0); lseek(fd, SEEK_CUR, 0);
idiom.
Signed-off-by: Christopher James Halse Rogers
christopher.halse.rog...@canonical.com
---
I've run into a point in the radeon DRM userspace where I need the
size of a dma-buf. I could add a radeon-specific mechanism to get that,
but this seems like something that would be more generally useful.
I'm not entirely sure about supporting both SEEK_END and SEEK_CUR; this
is somewhat of an abuse of lseek, as seeking obviously doesn't make sense.
It's the obivous idiom for getting the size of what's on the other end of a
file descriptor, though.
I didn't notice anywhere to document this; Documentation/dma-buf-api didn't
seem like the right place. Is there somewhere I've overlooked?
drivers/base/dma-buf.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 6687ba7..c33a857 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -77,9 +77,36 @@ static int dma_buf_mmap_internal(struct file *file, struct
vm_area_struct *vma)
return dmabuf-ops-mmap(dmabuf, vma);
}
+static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
+{
+ struct dma_buf *dmabuf;
+ loff_t base;
+
+ if (!is_dma_buf_file(file))
+ return -EBADF;
+
+ dmabuf = file-private_data;
+
+ /* only support discovering the end of the buffer,
+ but also allow SEEK_SET to maintain the idiomatic
+ SEEK_END(0), SEEK_CUR(0) pattern */
+ if (whence == SEEK_END)
+ base = dmabuf-size;
+ else if (whence == SEEK_SET)
+ base = 0;
+ else
+ return -EINVAL;
+
+ if (offset != 0)
+ return -EINVAL;
+
+ return base + offset;
+}
+
static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap = dma_buf_mmap_internal,
+ .llseek = dma_buf_llseek,
};
/*
@@ -133,6 +160,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
dmabuf-exp_name = exp_name;
file = anon_inode_getfile(dmabuf, dma_buf_fops, dmabuf, flags);
+ file-f_mode |= FMODE_LSEEK;
dmabuf-file = file;
--
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
Re: [RFC PATCH 2/8] v4l2-dv-timings: add new helper module.
Hi Hans, Thanks for the patch, this will still simplify driver writing :-) On Mon, Jul 29, 2013 at 6:10 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com This module makes it easy to filter valid timings from the full list of CEA and DMT timings based on the timings capabilities. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com 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
Re: [RFC PATCH 3/8] v4l2: move dv-timings related code to v4l2-dv-timings.c
Hi Hans, Thanks for the patch. On Mon, Jul 29, 2013 at 6:10 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com v4l2-common.c contained a bunch of dv-timings related functions. Move that to the new v4l2-dv-timings.c which is a more appropriate place for them. There aren't many drivers that do HDTV, so it is a good idea to separate common code related to that into a module of its own. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com 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
Re: [RFC PATCH 5/8] videodev2.h: defines to calculate blanking and frame sizes
Hi Hans, Thanks for the patch. On Mon, Jul 29, 2013 at 6:10 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com It is very common to have to calculate the total width and height of the blanking and the full frame, so add a few defines that deal with that. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com 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
Re: [RFC PATCH 6/8] v4l2: use new V4L2_DV_BT_BLANKING/FRAME defines
Hi Hans, Thanks for the patch. On Mon, Jul 29, 2013 at 6:10 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com Use the new defines to calculate the full blanking and frame sizes. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Cc: Lad, Prabhakar prabhakar.cse...@gmail.com Cc: Scott Jiang scott.jiang.li...@gmail.com --- [Snip] drivers/media/i2c/ths7303.c| 6 ++ drivers/media/i2c/ths8200.c| 8 For the above two, Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com May be you can split this patch into two ? one with i2c changes and other with driver. 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
Re: [PATCH] drm/exynos: Add check for IOMMU while passing physically continous memory flag
Hi Sylwester, On 2 August 2013 16:28, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Vikas, On 08/02/2013 12:10 PM, Vikas Sajjan wrote: yeah, we could not allocate CMA region for FIMD, because the function dma_declare_contiguous() needs dev as the first argument and we have access to dev node only if it is NON-DT way of probing like the way it is done in arch/arm/mach-davinci/devices-da8xx.c But now, since the probing is through DT way, there is NO way ( Let me know if something is newly added ) to call dma_declare_contiguous() and reserve CMA region . See this patch series [1]. We have have been using this kind of bindings for assigning physically contiguous memory regions to the Exynos multimedia devices, instead of what's currently in mainline where same physical addresses are repeated in dts for various boards without much thought. And where custom device specific parsing code is required at arch side. $ git grep mfc\-[lr] arch/arm/boot/dts arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-r = 0x4300 0x80; arch/arm/boot/dts/exynos4210-origen.dts: samsung,mfc-l = 0x5100 0x80; arch/arm/boot/dts/exynos4210-smdkv310.dts: samsung,mfc-r = 0x4300 0x80; arch/arm/boot/dts/exynos4210-smdkv310.dts: samsung,mfc-l = 0x5100 0x80; arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-r = 0x4300 0x80; arch/arm/boot/dts/exynos4412-origen.dts: samsung,mfc-l = 0x5100 0x80; arch/arm/boot/dts/exynos4412-smdk4412.dts: samsung,mfc-r = 0x4300 0x80; arch/arm/boot/dts/exynos4412-smdk4412.dts: samsung,mfc-l = 0x5100 0x80; arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-r = 0x4300 0x80; arch/arm/boot/dts/exynos5250-arndale.dts:samsung,mfc-l = 0x5100 0x80; arch/arm/boot/dts/exynos5250-smdk5250.dts: samsung,mfc-r = 0x4300 0x80; arch/arm/boot/dts/exynos5250-smdk5250.dts: samsung,mfc-l = 0x5100 0x80; [1] http://www.spinics.net/lists/arm-kernel/msg263130.html Thanks, its good that now we have a new way to reserve CMA region. Regards, Sylwester -- Thanks and Regards Vikas Sajjan -- 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 3/5] qv4l2: add ALSA stream to qv4l2
On Saturday, August 03, 2013 12:19:54 AM you wrote: Hello, diff --git a/utils/qv4l2/Makefile.am b/utils/qv4l2/Makefile.am index 22d4c17..eed25b0 100644 --- a/utils/qv4l2/Makefile.am +++ b/utils/qv4l2/Makefile.am @@ -4,7 +4,8 @@ qv4l2_SOURCES = qv4l2.cpp general-tab.cpp ctrl-tab.cpp vbi-tab.cpp v4l2-api.cpp capture-win-qt.cpp capture-win-qt.h capture-win-gl.cpp capture-win-gl.h \ raw2sliced.cpp qv4l2.h capture-win.h general-tab.h vbi-tab.h v4l2-api.h raw2sliced.h nodist_qv4l2_SOURCES = moc_qv4l2.cpp moc_general-tab.cpp moc_capture-win.cpp moc_vbi-tab.cpp qrc_qv4l2.cpp -qv4l2_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4lconvert/libv4lconvert.la ../libv4l2util/libv4l2util.la +qv4l2_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4lconvert/libv4lconvert.la ../libv4l2util/libv4l2util.la \ + ../libmedia_dev/libmedia_dev.la if WITH_QV4L2_GL qv4l2_CPPFLAGS = $(QTGL_CFLAGS) -DENABLE_GL @@ -14,6 +15,12 @@ qv4l2_CPPFLAGS = $(QT_CFLAGS) qv4l2_LDFLAGS = $(QT_LIBS) endif +if WITH_QV4L2_ALSA +qv4l2_CPPFLAGS += $(ALSA_CFLAGS) -DENABLE_ALSA I would prefer if you don't add another define to the command line. To check for ALSA support please include config.h and use the flag provided there. That is fine for me. However, this design was to make the alsa code not compile in when not required. While I am at it, should I do the same for OpenGL, that is, remove WITH_QV4L2_GL with a config.h define)? The patch series has already been patched in, but I do have another series that adds features and fixes to the first OpenGL patches. It should not be a problem to change OpenGL accordingly as well. B. 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 -- 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/6] v4l: ti-vpe: Create a vpdma helper library
Hi,
On 02/08/13 17:03, Archit Taneja wrote:
+struct vpdma_data_format vpdma_yuv_fmts[] = {
+ [VPDMA_DATA_FMT_Y444] = {
+ .data_type = DATA_TYPE_Y444,
+ .depth = 8,
+ },
This, and all the other tables, should probably be consts?
+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+ u32 val = *valp;
+
+ val = ~(mask shift);
+ val |= (field mask) shift;
+ *valp = val;
+}
I think insert normally means, well, inserting a thing in between
something. What you do here is overwriting.
Why not just call it write_field?
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+ buf-size = size;
+ buf-mapped = 0;
Maybe true/false is clearer here that 0/1.
+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for
completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list
*list)
+{
+ /* we always use the first list */
+ int list_num = 0;
+ int list_size;
+
+ if (vpdma_list_busy(vpdma, list_num))
+ return -EBUSY;
+
+ /* 16-byte granularity */
+ list_size = (list-next - list-buf.addr) 4;
+
+ write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list-buf.dma_addr);
+ wmb();
What is the wmb() for?
+ write_reg(vpdma, VPDMA_LIST_ATTR,
+ (list_num VPDMA_LIST_NUM_SHFT) |
+ (list-type VPDMA_LIST_TYPE_SHFT) |
+ list_size);
+
+ return 0;
+}
+static void vpdma_firmware_cb(const struct firmware *f, void *context)
+{
+ struct vpdma_data *vpdma = context;
+ struct vpdma_buf fw_dma_buf;
+ int i, r;
+
+ dev_dbg(vpdma-pdev-dev, firmware callback\n);
+
+ if (!f || !f-data) {
+ dev_err(vpdma-pdev-dev, couldn't get firmware\n);
+ return;
+ }
+
+ /* already initialized */
+ if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+ VPDMA_LIST_RDY_SHFT)) {
+ vpdma-ready = true;
+ return;
+ }
+
+ r = vpdma_buf_alloc(fw_dma_buf, f-size);
+ if (r) {
+ dev_err(vpdma-pdev-dev,
+ failed to allocate dma buffer for firmware\n);
+ goto rel_fw;
+ }
+
+ memcpy(fw_dma_buf.addr, f-data, f-size);
+
+ vpdma_buf_map(vpdma, fw_dma_buf);
+
+ write_reg(vpdma, VPDMA_LIST_ADDR, (u32) fw_dma_buf.dma_addr);
+
+ for (i = 0; i 100; i++) { /* max 1 second */
+ msleep_interruptible(10);
You call interruptible version here, but you don't handle the
interrupted case. I believe the loop will just continue looping, even if
the user interrupted.
+ if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+ VPDMA_LIST_RDY_SHFT))
+ break;
+ }
+
+ if (i == 100) {
+ dev_err(vpdma-pdev-dev, firmware upload failed\n);
+ goto free_buf;
+ }
+
+ vpdma-ready = true;
+
+free_buf:
+ vpdma_buf_unmap(vpdma, fw_dma_buf);
+
+ vpdma_buf_free(fw_dma_buf);
+rel_fw:
+ release_firmware(f);
+}
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC PATCH 7/8] v4l2: use new V4L2_DV_BT_BLANKING/FRAME defines
Hi Hans, Thanks for the patch. On Mon, Jul 29, 2013 at 6:11 PM, Hans Verkuil hverk...@xs4all.nl wrote: From: Hans Verkuil hans.verk...@cisco.com Use the new blanking and frame size defines. This also fixed a bug in these drivers: they assumed that the height for interlaced formats was the field height, however height is the frame height. So the height for a field is actually bt-height / 2. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Cc: Lad, Prabhakar prabhakar.cse...@gmail.com Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com 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
[RFC PATCH 1/7] qv4l2: fix YUY2 shader
Fixed the YUY2 shaders to support scaling.
The new solution has cleaner shader code and texture upload
uses a better format for OpenGL.
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
utils/qv4l2/capture-win-gl.cpp | 68 ++
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index 52412c7..bae6569 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -1,5 +1,5 @@
/*
- * The YUY2 shader code was copied and simplified from face-responder. The
code is under public domain:
+ * The YUY2 shader code is based on face-responder. The code is under public
domain:
*
https://bitbucket.org/nateharward/face-responder/src/0c3b4b957039d9f4bf1da09b9471371942de2601/yuv42201_laplace.frag?at=master
*
* All other OpenGL code:
@@ -446,47 +446,51 @@ QString CaptureWinGLEngine::shader_YUY2_invariant(__u32
format)
{
switch (format) {
case V4L2_PIX_FMT_YUYV:
- return QString(y = (luma_chroma.r - 0.0625) * 1.1643;
- if (mod(xcoord, 2.0) == 0.0) {
- u = luma_chroma.a;
- v = texture2D(tex, vec2(pixelx + texl_w,
pixely)).a;
+ return QString(if (mod(xcoord, 2.0) == 0.0) {
+ luma_chroma = texture2D(tex, vec2(pixelx,
pixely));
+ y = (luma_chroma.r - 0.0625) * 1.1643;
} else {
- v = luma_chroma.a;
- u = texture2D(tex, vec2(pixelx - texl_w,
pixely)).a;
+ luma_chroma = texture2D(tex, vec2(pixelx -
texl_w, pixely));
+ y = (luma_chroma.b - 0.0625) * 1.1643;
}
+ u = luma_chroma.g - 0.5;
+ v = luma_chroma.a - 0.5;
);
case V4L2_PIX_FMT_YVYU:
- return QString(y = (luma_chroma.r - 0.0625) * 1.1643;
- if (mod(xcoord, 2.0) == 0.0) {
- v = luma_chroma.a;
- u = texture2D(tex, vec2(pixelx + texl_w,
pixely)).a;
+ return QString(if (mod(xcoord, 2.0) == 0.0) {
+ luma_chroma = texture2D(tex, vec2(pixelx,
pixely));
+ y = (luma_chroma.r - 0.0625) * 1.1643;
} else {
- u = luma_chroma.a;
- v = texture2D(tex, vec2(pixelx - texl_w,
pixely)).a;
+ luma_chroma = texture2D(tex, vec2(pixelx -
texl_w, pixely));
+ y = (luma_chroma.b - 0.0625) * 1.1643;
}
+ u = luma_chroma.a - 0.5;
+ v = luma_chroma.g - 0.5;
);
case V4L2_PIX_FMT_UYVY:
- return QString(y = (luma_chroma.a - 0.0625) * 1.1643;
- if (mod(xcoord, 2.0) == 0.0) {
- u = luma_chroma.r;
- v = texture2D(tex, vec2(pixelx + texl_w,
pixely)).r;
+ return QString(if (mod(xcoord, 2.0) == 0.0) {
+ luma_chroma = texture2D(tex, vec2(pixelx,
pixely));
+ y = (luma_chroma.g - 0.0625) * 1.1643;
} else {
- v = luma_chroma.r;
- u = texture2D(tex, vec2(pixelx - texl_w,
pixely)).r;
+ luma_chroma = texture2D(tex, vec2(pixelx -
texl_w, pixely));
+ y = (luma_chroma.a - 0.0625) * 1.1643;
}
+ u = luma_chroma.r - 0.5;
+ v = luma_chroma.b - 0.5;
);
case V4L2_PIX_FMT_VYUY:
- return QString(y = (luma_chroma.a - 0.0625) * 1.1643;
- if (mod(xcoord, 2.0) == 0.0) {
- v = luma_chroma.r;
- u = texture2D(tex, vec2(pixelx + texl_w,
pixely)).r;
+ return QString(if (mod(xcoord, 2.0) == 0.0) {
+ luma_chroma = texture2D(tex, vec2(pixelx,
pixely));
+ y = (luma_chroma.g - 0.0625) * 1.1643;
} else {
- u = luma_chroma.r;
- v = texture2D(tex, vec2(pixelx - texl_w,
pixely)).r;
+ luma_chroma = texture2D(tex, vec2(pixelx -
texl_w, pixely));
+
[RFC PATCH 4/7] qv4l2: add function getMargins
Created a function to get the total margins (window frame) in pixels
outside the actual video frame beeing displayed.
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
utils/qv4l2/capture-win.cpp | 14 ++
utils/qv4l2/capture-win.h | 2 ++
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp
index 2d57909..e583900 100644
--- a/utils/qv4l2/capture-win.cpp
+++ b/utils/qv4l2/capture-win.cpp
@@ -54,16 +54,22 @@ void CaptureWin::buildWindow(QWidget *videoSurface)
vbox-setSpacing(b);
}
+QSize CaptureWin::getMargins()
+{
+ int l, t, r, b;
+ layout()-getContentsMargins(l, t, r, b);
+ return QSize(l + r, t + b + m_information.minimumSizeHint().height() +
layout()-spacing());
+}
+
void CaptureWin::setMinimumSize(int minw, int minh)
{
QDesktopWidget *screen = QApplication::desktop();
QRect resolution = screen-screenGeometry();
QSize maxSize = maximumSize();
- int l, t, r, b;
- layout()-getContentsMargins(l, t, r, b);
- minw += l + r;
- minh += t + b + m_information.minimumSizeHint().height() +
layout()-spacing();
+ QSize margins = getMargins();
+ minw += margins.width();
+ minh += margins.height();
if (minw resolution.width())
minw = resolution.width();
diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h
index ca60244..6b72e00 100644
--- a/utils/qv4l2/capture-win.h
+++ b/utils/qv4l2/capture-win.h
@@ -78,6 +78,8 @@ public:
protected:
void closeEvent(QCloseEvent *event);
void buildWindow(QWidget *videoSurface);
+ QSize getMargins();
+
/**
* @brief A label that can is used to display capture information.
--
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
[RFC PATCH 2/7] qv4l2: fix black screen with opengl after capture
Fixes the issue when the window was beeing resized/moved
and the frame image would become black.
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
utils/qv4l2/capture-win-gl.cpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index bae6569..edae60f 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -253,6 +253,12 @@ void CaptureWinGLEngine::paintGL()
changeShader();
if (m_frameData == NULL) {
+ glBegin(GL_QUADS);
+ glTexCoord2f(0.0f, 0.0f); glVertex2f(0.0, 0);
+ glTexCoord2f(1.0f, 0.0f); glVertex2f(m_frameWidth, 0);
+ glTexCoord2f(1.0f, 1.0f); glVertex2f(m_frameWidth,
m_frameHeight);
+ glTexCoord2f(0.0f, 1.0f); glVertex2f(0, m_frameHeight);
+ glEnd();
return;
}
--
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
[RFC PATCH 7/7] qv4l2: add aspect ratio support
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
utils/qv4l2/capture-win.cpp | 24 ++--
utils/qv4l2/capture-win.h | 8 +++-
utils/qv4l2/general-tab.cpp | 36
utils/qv4l2/general-tab.h | 3 +++
utils/qv4l2/qv4l2.cpp | 22 +++---
utils/qv4l2/qv4l2.h | 2 +-
6 files changed, 84 insertions(+), 11 deletions(-)
diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp
index 435c19b..415829a 100644
--- a/utils/qv4l2/capture-win.cpp
+++ b/utils/qv4l2/capture-win.cpp
@@ -30,6 +30,7 @@
#define MIN_WIN_SIZE_HEIGHT 120
bool CaptureWin::m_enableScaling = true;
+double CaptureWin::m_pixelAspectRatio = 1.0;
CaptureWin::CaptureWin() :
m_curWidth(-1),
@@ -73,6 +74,14 @@ void CaptureWin::resetSize()
resize(w, h);
}
+int CaptureWin::actualFrameWidth(int width)
+{
+ if (m_enableScaling)
+ return (int)((double)width * m_pixelAspectRatio);
+ else
+ return width;
+}
+
QSize CaptureWin::getMargins()
{
int l, t, r, b;
@@ -94,6 +103,14 @@ void CaptureWin::enableScaling(bool enable)
delete event;
}
+void CaptureWin::setPixelAspectRatio(double ratio)
+{
+ m_pixelAspectRatio = ratio;
+ QResizeEvent *event = new QResizeEvent(QSize(width(), height()),
QSize(width(), height()));
+ QCoreApplication::sendEvent(this, event);
+ delete event;
+}
+
void CaptureWin::resize(int width, int height)
{
// Dont resize window if the frame size is the same in
@@ -105,7 +122,7 @@ void CaptureWin::resize(int width, int height)
m_curHeight = height;
QSize margins = getMargins();
- width += margins.width();
+ width = actualFrameWidth(width) + margins.width();
height += margins.height();
QDesktopWidget *screen = QApplication::desktop();
@@ -127,12 +144,15 @@ void CaptureWin::resize(int width, int height)
QSize CaptureWin::scaleFrameSize(QSize window, QSize frame)
{
- int actualFrameWidth = frame.width();;
+ int actualFrameWidth;
int actualFrameHeight = frame.height();
if (!m_enableScaling) {
window.setWidth(frame.width());
window.setHeight(frame.height());
+ actualFrameWidth = frame.width();
+ } else {
+ actualFrameWidth = CaptureWin::actualFrameWidth(frame.width());
}
double newW, newH;
diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h
index 1bfb1e1..eded9e0 100644
--- a/utils/qv4l2/capture-win.h
+++ b/utils/qv4l2/capture-win.h
@@ -76,9 +76,10 @@ public:
static bool isSupported() { return false; }
void enableScaling(bool enable);
+ void setPixelAspectRatio(double ratio);
static QSize scaleFrameSize(QSize window, QSize frame);
-public slots:
+ public slots:
void resetSize();
protected:
@@ -99,6 +100,11 @@ protected:
*/
static bool m_enableScaling;
+ /**
+* @note Aspect ratio it taken care of by scaling, frame size is for
square pixels only!
+*/
+ static double m_pixelAspectRatio;
+
signals:
void close();
diff --git a/utils/qv4l2/general-tab.cpp b/utils/qv4l2/general-tab.cpp
index 5996c03..53b7e36 100644
--- a/utils/qv4l2/general-tab.cpp
+++ b/utils/qv4l2/general-tab.cpp
@@ -53,6 +53,7 @@ GeneralTab::GeneralTab(const QString device, v4l2 fd, int
n, QWidget *parent)
m_tvStandard(NULL),
m_qryStandard(NULL),
m_videoTimings(NULL),
+ m_pixelAspectRatio(NULL),
m_qryTimings(NULL),
m_freq(NULL),
m_vidCapFormats(NULL),
@@ -210,6 +211,20 @@ GeneralTab::GeneralTab(const QString device, v4l2 fd,
int n, QWidget *parent)
connect(m_qryTimings, SIGNAL(clicked()),
SLOT(qryTimingsClicked()));
}
+ if (!isRadio() !isVbi()) {
+ m_pixelAspectRatio = new QComboBox(parent);
+ m_pixelAspectRatio-addItem(Autodetect);
+ m_pixelAspectRatio-addItem(Square);
+ m_pixelAspectRatio-addItem(NTSC/PAL-M/PAL-60);
+ m_pixelAspectRatio-addItem(NTSC/PAL-M/PAL-60, Anamorphic);
+ m_pixelAspectRatio-addItem(PAL/SECAM);
+ m_pixelAspectRatio-addItem(PAL/SECAM, Anamorphic);
+
+ addLabel(Pixel Aspect Ratio);
+ addWidget(m_pixelAspectRatio);
+ connect(m_pixelAspectRatio, SIGNAL(activated(int)),
SIGNAL(pixelAspectRatioChanged()));
+ }
+
if (m_tuner.capability) {
QDoubleValidator *val;
double factor = (m_tuner.capability V4L2_TUNER_CAP_LOW) ? 16
: 16000;
@@ -1105,6 +1120,27 @@ void GeneralTab::updateFrameSize()
updateFrameInterval();
}
+double GeneralTab::getPixelAspectRatio()
+{
+ if (m_pixelAspectRatio-currentText().compare(Autodetect) == 0) {
+ v4l2_cropcap ratio;
+
[RFC PATCH 3/7] qv4l2: show frames option can be toggled during capture
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
utils/qv4l2/qv4l2.cpp | 77 ++-
utils/qv4l2/qv4l2.h | 2 +-
2 files changed, 41 insertions(+), 38 deletions(-)
diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp
index e078e91..fa1425d 100644
--- a/utils/qv4l2/qv4l2.cpp
+++ b/utils/qv4l2/qv4l2.cpp
@@ -404,7 +404,7 @@ void ApplicationWindow::capVbiFrame()
m_capStartAct-setChecked(false);
return;
}
- if (m_showFrames) {
+ if (showFrames()) {
for (unsigned y = 0; y m_vbiHeight; y++) {
__u8 *p = data + y * m_vbiWidth;
__u8 *q = m_capImage-bits() + y *
m_capImage-bytesPerLine();
@@ -448,7 +448,7 @@ void ApplicationWindow::capVbiFrame()
m_tv = tv;
}
status = QString(Frame: %1 Fps: %2).arg(++m_frame).arg(m_fps);
- if (m_showFrames)
+ if (showFrames())
m_capture-setFrame(m_capImage-width(), m_capImage-height(),
m_capDestFormat.fmt.pix.pixelformat,
m_capImage-bits(), status);
@@ -490,7 +490,7 @@ void ApplicationWindow::capFrame()
if (m_saveRaw.openMode())
m_saveRaw.write((const char *)m_frameData, s);
- if (!m_showFrames)
+ if (!showFrames())
break;
if (m_mustConvert)
err = v4lconvert_convert(m_convertData,
m_capSrcFormat, m_capDestFormat,
@@ -514,7 +514,7 @@ void ApplicationWindow::capFrame()
if (again)
return;
- if (m_showFrames) {
+ if (showFrames()) {
if (m_mustConvert)
err = v4lconvert_convert(m_convertData,
m_capSrcFormat, m_capDestFormat,
(unsigned char
*)m_buffers[buf.index].start, buf.bytesused,
@@ -544,7 +544,7 @@ void ApplicationWindow::capFrame()
if (again)
return;
- if (m_showFrames) {
+ if (showFrames()) {
if (m_mustConvert)
err = v4lconvert_convert(m_convertData,
m_capSrcFormat, m_capDestFormat,
(unsigned char
*)buf.m.userptr, buf.bytesused,
@@ -592,10 +592,10 @@ void ApplicationWindow::capFrame()
.arg((m_totalAudioLatency.tv_sec * 1000 +
m_totalAudioLatency.tv_usec / 1000) / m_frame));
}
#endif
- if (displaybuf == NULL m_showFrames)
+ if (displaybuf == NULL showFrames())
status.append( Error: Unsupported format.);
- if (m_showFrames)
+ if (showFrames())
m_capture-setFrame(m_capImage-width(), m_capImage-height(),
m_capDestFormat.fmt.pix.pixelformat,
displaybuf, status);
@@ -778,6 +778,13 @@ void ApplicationWindow::stopCapture()
refresh();
}
+bool ApplicationWindow::showFrames()
+{
+ if (m_showFramesAct-isChecked() !m_capture-isVisible())
+ m_capture-show();
+ return m_showFramesAct-isChecked();
+}
+
void ApplicationWindow::startOutput(unsigned)
{
}
@@ -851,7 +858,6 @@ void ApplicationWindow::capStart(bool start)
m_capImage = NULL;
return;
}
- m_showFrames = m_showFramesAct-isChecked();
m_frame = m_lastFrame = m_fps = 0;
m_capMethod = m_genTab-capMethod();
@@ -859,7 +865,6 @@ void ApplicationWindow::capStart(bool start)
v4l2_format fmt;
v4l2_std_id std;
- m_showFrames = false;
g_fmt_sliced_vbi(fmt);
g_std(std);
fmt.fmt.sliced.service_set = (std V4L2_STD_625_50) ?
@@ -898,14 +903,14 @@ void ApplicationWindow::capStart(bool start)
m_vbiHeight = fmt.fmt.vbi.count[0] +
fmt.fmt.vbi.count[1];
m_vbiSize = m_vbiWidth * m_vbiHeight;
m_frameData = new unsigned char[m_vbiSize];
- if (m_showFrames) {
- m_capture-setMinimumSize(m_vbiWidth, m_vbiHeight);
- m_capImage = new QImage(m_vbiWidth, m_vbiHeight,
dstFmt);
- m_capImage-fill(0);
- m_capture-setFrame(m_capImage-width(),
m_capImage-height(),
-
m_capDestFormat.fmt.pix.pixelformat, m_capImage-bits(), No frame);
+ m_capture-setMinimumSize(m_vbiWidth, m_vbiHeight);
+ m_capImage = new QImage(m_vbiWidth, m_vbiHeight, dstFmt);
+ m_capImage-fill(0);
+ m_capture-setFrame(m_capImage-width(), m_capImage-height(),
+ m_capDestFormat.fmt.pix.pixelformat,
m_capImage-bits(), No
[RFC PATCH 6/7] qv4l2: add hotkey for reset scaling to frame size
Adds hotkey CTRL + F for both CaptureWin and main Capture menu. Resets the scaling of CaptureWin to fit frame size. Signed-off-by: Bård Eirik Winther bwint...@cisco.com --- utils/qv4l2/capture-win.cpp | 3 +++ utils/qv4l2/capture-win.h | 1 + utils/qv4l2/qv4l2.cpp | 1 + 3 files changed, 5 insertions(+) diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp index 4c5dd57..435c19b 100644 --- a/utils/qv4l2/capture-win.cpp +++ b/utils/qv4l2/capture-win.cpp @@ -38,6 +38,8 @@ CaptureWin::CaptureWin() : setWindowTitle(V4L2 Capture); m_hotkeyClose = new QShortcut(Qt::CTRL+Qt::Key_W, this); connect(m_hotkeyClose, SIGNAL(activated()), this, SLOT(close())); + m_hotkeyScaleReset = new QShortcut(Qt::CTRL+Qt::Key_F, this); + connect(m_hotkeyScaleReset, SIGNAL(activated()), this, SLOT(resetSize())); } CaptureWin::~CaptureWin() @@ -48,6 +50,7 @@ CaptureWin::~CaptureWin() layout()-removeWidget(this); delete layout(); delete m_hotkeyClose; + delete m_hotkeyScaleReset; } void CaptureWin::buildWindow(QWidget *videoSurface) diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h index eea0335..1bfb1e1 100644 --- a/utils/qv4l2/capture-win.h +++ b/utils/qv4l2/capture-win.h @@ -104,6 +104,7 @@ signals: private: QShortcut *m_hotkeyClose; + QShortcut *m_hotkeyScaleReset; int m_curWidth; int m_curHeight; }; diff --git a/utils/qv4l2/qv4l2.cpp b/utils/qv4l2/qv4l2.cpp index 6b64892..92a415f 100644 --- a/utils/qv4l2/qv4l2.cpp +++ b/utils/qv4l2/qv4l2.cpp @@ -144,6 +144,7 @@ ApplicationWindow::ApplicationWindow() : connect(m_scalingAct, SIGNAL(toggled(bool)), this, SLOT(enableScaling(bool))); m_resetScalingAct = new QAction(Resize to Frame Size, this); m_resetScalingAct-setStatusTip(Resizes the capture window to match frame size); + m_resetScalingAct-setShortcut(Qt::CTRL+Qt::Key_F); QMenu *captureMenu = menuBar()-addMenu(Capture); captureMenu-addAction(m_capStartAct); -- 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
[RFC PATCH 5/7] qv4l2: add video scaling for CaptureWin
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
utils/qv4l2/capture-win-gl.cpp | 26 --
utils/qv4l2/capture-win-gl.h | 8
utils/qv4l2/capture-win-qt.cpp | 24 +-
utils/qv4l2/capture-win-qt.h | 5 ++
utils/qv4l2/capture-win.cpp| 106 +++--
utils/qv4l2/capture-win.h | 18 +--
utils/qv4l2/qv4l2.cpp | 27 +--
utils/qv4l2/qv4l2.h| 4 ++
8 files changed, 181 insertions(+), 37 deletions(-)
diff --git a/utils/qv4l2/capture-win-gl.cpp b/utils/qv4l2/capture-win-gl.cpp
index edae60f..628aaec 100644
--- a/utils/qv4l2/capture-win-gl.cpp
+++ b/utils/qv4l2/capture-win-gl.cpp
@@ -43,6 +43,15 @@ void CaptureWinGL::stop()
#endif
}
+void CaptureWinGL::resizeEvent(QResizeEvent *event)
+{
+ QSize margins = getMargins();
+#ifdef ENABLE_GL
+ m_videoSurface.setSize(width() - margins.width(), height() -
margins.height());
+#endif
+ event-accept();
+}
+
void CaptureWinGL::setFrame(int width, int height, __u32 format, unsigned char
*data, const QString info)
{
#ifdef ENABLE_GL
@@ -109,11 +118,22 @@ void CaptureWinGLEngine::initializeGL()
checkError(InitializeGL);
}
+void CaptureWinGLEngine::setSize(int width, int height)
+{
+ QSize sizedFrame = CaptureWin::scaleFrameSize(QSize(width, height),
QSize(m_frameWidth, m_frameHeight));
+
+ width = sizedFrame.width();
+ height = sizedFrame.height();
+
+ if (width 0 height 0) {
+ setMaximumSize(width, height);
+ resizeGL(width, height);
+ }
+}
void CaptureWinGLEngine::resizeGL(int width, int height)
{
- // Resizing is disabled by setting viewport equal to frame size
- glViewport(0, 0, m_frameWidth, m_frameHeight);
+ glViewport(0, 0, width, height);
}
void CaptureWinGLEngine::setFrame(int width, int height, __u32 format,
unsigned char *data)
@@ -123,8 +143,6 @@ void CaptureWinGLEngine::setFrame(int width, int height,
__u32 format, unsigned
m_frameWidth = width;
m_frameHeight = height;
m_frameFormat = format;
-
- QGLWidget::setMaximumSize(m_frameWidth, m_frameHeight);
}
m_frameData = data;
diff --git a/utils/qv4l2/capture-win-gl.h b/utils/qv4l2/capture-win-gl.h
index 08e72b2..ef06d0b 100644
--- a/utils/qv4l2/capture-win-gl.h
+++ b/utils/qv4l2/capture-win-gl.h
@@ -21,6 +21,9 @@
#include qv4l2.h
#include capture-win.h
+#include QBoxLayout
+#include QResizeEvent
+
#ifdef ENABLE_GL
#define GL_GLEXT_PROTOTYPES
#include QGLWidget
@@ -40,6 +43,7 @@ public:
void stop();
void setFrame(int width, int height, __u32 format, unsigned char *data);
bool hasNativeFormat(__u32 format);
+ void setSize(int width, int height);
protected:
void paintGL();
@@ -88,6 +92,10 @@ public:
bool hasNativeFormat(__u32 format);
static bool isSupported();
+ protected:
+ void resizeEvent(QResizeEvent *event);
+
+private:
#ifdef ENABLE_GL
CaptureWinGLEngine m_videoSurface;
#endif
diff --git a/utils/qv4l2/capture-win-qt.cpp b/utils/qv4l2/capture-win-qt.cpp
index 63c77d5..0f6964b 100644
--- a/utils/qv4l2/capture-win-qt.cpp
+++ b/utils/qv4l2/capture-win-qt.cpp
@@ -22,8 +22,9 @@
CaptureWinQt::CaptureWinQt() :
m_frame(new QImage(0, 0, QImage::Format_Invalid))
{
-
CaptureWin::buildWindow(m_videoSurface);
+ m_scaledFrame.setWidth(0);
+ m_scaledFrame.setHeight(0);
}
CaptureWinQt::~CaptureWinQt()
@@ -31,6 +32,19 @@ CaptureWinQt::~CaptureWinQt()
delete m_frame;
}
+void CaptureWinQt::resizeEvent(QResizeEvent *event)
+{
+ if (m_frame-bits() == NULL)
+ return;
+
+ QPixmap img = QPixmap::fromImage(*m_frame);
+ m_scaledFrame = scaleFrameSize(QSize(m_videoSurface.width(),
m_videoSurface.height()),
+ QSize(m_frame-width(),
m_frame-height()));
+ img = img.scaled(m_scaledFrame.width(), m_scaledFrame.height(),
Qt::IgnoreAspectRatio);
+ m_videoSurface.setPixmap(img);
+ QWidget::resizeEvent(event);
+}
+
void CaptureWinQt::setFrame(int width, int height, __u32 format, unsigned char
*data, const QString info)
{
QImage::Format dstFmt;
@@ -41,6 +55,8 @@ void CaptureWinQt::setFrame(int width, int height, __u32
format, unsigned char *
if (m_frame-width() != width || m_frame-height() != height ||
m_frame-format() != dstFmt) {
delete m_frame;
m_frame = new QImage(width, height, dstFmt);
+ m_scaledFrame = scaleFrameSize(QSize(m_videoSurface.width(),
m_videoSurface.height()),
+ QSize(m_frame-width(),
m_frame-height()));
}
if (data == NULL || !supported)
@@ -49,7 +65,11 @@ void CaptureWinQt::setFrame(int width, int height, __u32
format, unsigned char *
memcpy(m_frame-bits(),
[RFC PATCH 0/7] qv4l2: scaling and pixel aspect ratio
The patch series depends on the qv4l2 ALSA and OpenGL patch series. This adds scaling and aspect ratio support to the qv4l2 CaptureWin. It also fixes some issues with the original OpenGL patch series, as well as adding tweaks and improvements left out in the original patches. Some of the changes/improvements: - CaptureWin have scaling support for video frames for all renderers - CaptureWin support pixel aspect ratio scaling - Aspect ratio and scaling can be changed during capture - CaptureWin's setMinimumSize is now resize, which resizes the window to the frame size given and minimum size is set automatically - The YUY2 shader programs are rewritten and has the resizing issue fixed - The Show Frames option in Capture menu can be toggled during capture - Reset and disable scaling options - Added a hotkey: CTRL + F : (size to video 'F'rame) When either the main window or capture window is selected this will reset the scaling to fit the frame size. This option is also available in the Capture menu. Pixel Aspect Ratio Modes: - Autodetect (if not supported this assumes square pixels) - Square - NTSC/PAL-M/PAL-60 - NTSC/PAL-M/PAL-60, Anamorphic - PAL/SECAM - PAL/SECAM, Anamorphic -- 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/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors
On 02/08/13 17:03, Archit Taneja wrote:
Create functions which the VPE driver can use to create a VPDMA descriptor and
add it to a VPDMA descriptor list. These functions take a pointer to an
existing
list, and append the configuration/data/control descriptor header to the list.
In the case of configuration descriptors, the creation of a payload block may
be
required(the payloads can hold VPE MMR values, or scaler coefficients). The
allocation of the payload buffer and it's content is left to the VPE driver.
However, the VPDMA library provides helper macros to create payload in the
correct format.
Add debug functions to dump the descriptors in a way such that it's easy to
see
the values of different fields in the descriptors.
There are lots of defines and inline functions in this patch. But at
least the ones I looked at were only used once.
For example, dtd_set_xfer_length_height() is called only in one place.
Then dtd_set_xfer_length_height() uses DTD_W1(), and again it's the only
place where DTD_W1() is used.
So instead of:
dtd_set_xfer_length_height(dtd, c_rect-width, height);
You could as well do:
dtd-xfer_length_height = (c_rect-width DTD_LINE_LENGTH_SHFT) | height;
Now, presuming the compiler optimizes correctly, there should be no
difference between the two options above. My only point is that I wonder
if having multiple layers there improves readability at all. Some
helper funcs are rather trivial, like:
+static inline void dtd_set_w1(struct vpdma_dtd *dtd, u32 value)
+{
+ dtd-w1 = value;
+}
Then there are some, like dtd_set_type_ctl_stride(), that contains lots
of parameters. Hmm, okay, dtd_set_type_ctl_stride() is called in two
places, so at least in that case it makes sense to have that helper
func. But dtd_set_type_ctl_stride() uses DTD_W0(), and that's again the
only place where it's used.
So, I don't know. I'm not suggesting to change anything, I just started
wondering if all those macros and helpers actually help or not.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 269 +++
drivers/media/platform/ti-vpe/vpdma.h | 48 ++
drivers/media/platform/ti-vpe/vpdma_priv.h | 695
+
3 files changed, 1012 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index b15b3dd..b957381 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/sched.h
#include linux/slab.h
+#include linux/videodev2.h
#include vpdma.h
#include vpdma_priv.h
@@ -425,6 +426,274 @@ int vpdma_submit_descs(struct vpdma_data *vpdma, struct
vpdma_desc_list *list)
return 0;
}
+static void dump_cfd(struct vpdma_cfd *cfd)
+{
+ int class;
+
+ class = cfd_get_class(cfd);
+
+ pr_debug(config descriptor of payload class: %s\n,
+ class == CFD_CLS_BLOCK ? simple block :
+ address data block);
+
+ if (class == CFD_CLS_BLOCK)
+ pr_debug(word0: dst_addr_offset = 0x%08x\n,
+ cfd_get_dest_addr_offset(cfd));
+
+ if (class == CFD_CLS_BLOCK)
+ pr_debug(word1: num_data_wrds = %d\n, cfd_get_block_len(cfd));
+
+ pr_debug(word2: payload_addr = 0x%08x\n, cfd_get_payload_addr(cfd));
+
+ pr_debug(word3: pkt_type = %d, direct = %d, class = %d, dest = %d,
+ payload_len = %d\n, cfd_get_pkt_type(cfd),
+ cfd_get_direct(cfd), class, cfd_get_dest(cfd),
+ cfd_get_payload_len(cfd));
+}
There's quite a bit of code in these dump functions, and they are always
called. I'm sure getting that data is good for debugging, but I presume
they are quite useless for normal use. So I think they should be
compiled in only if some Kconfig option is selected.
+/*
+ * data transfer descriptor
+ *
+ * All fields are 32 bits to make them endian neutral
What does that mean? Why would 32bit fields make it endian neutral?
+ */
+struct vpdma_dtd {
+ u32 type_ctl_stride;
+ union {
+ u32 xfer_length_height;
+ u32 w1;
+ };
+ dma_addr_t start_addr;
+ u32 pkt_ctl;
+ union {
+ u32 frame_width_height; /* inbound */
+ dma_addr_t desc_write_addr;/* outbound */
Are you sure dma_addr_t is always 32 bit?
+ };
+ union {
+ u32 start_h_v; /* inbound */
+ u32 max_width_height; /* outbound */
+ };
+ u32 client_attr0;
+ u32 client_attr1;
+};
I'm not sure if I understand the struct right, but presuming this one
struct is used for both writing and reading, and certain set of fields
is used for writes and
Re: [PATCH 3/6] v4l: ti-vpe: Add VPE mem to mem driver
On 02/08/13 17:03, Archit Taneja wrote: VPE is a block which consists of a single memory to memory path which can perform chrominance up/down sampling, de-interlacing, scaling, and color space conversion of raster or tiled YUV420 coplanar, YUV422 coplanar or YUV422 interleaved video formats. We create a mem2mem driver based primarily on the mem2mem-testdev example. The de-interlacer, scaler and color space converter are all bypassed for now to keep the driver simple. Chroma up/down sampler blocks are implemented, so conversion beteen different YUV formats is possible. Each mem2mem context allocates a buffer for VPE MMR values which it will use when it gets access to the VPE HW via the mem2mem queue, it also allocates a VPDMA descriptor list to which configuration and data descriptors are added. Based on the information received via v4l2 ioctls for the source and destination queues, the driver configures the values for the MMRs, and stores them in the buffer. There are also some VPDMA parameters like frame start and line mode which needs to be configured, these are configured by direct register writes via the VPDMA helper functions. The driver's device_run() mem2mem op will add each descriptor based on how the source and destination queues are set up for the given ctx, once the list is prepared, it's submitted to VPDMA, these descriptors when parsed by VPDMA will upload MMR registers, start DMA of video buffers on the various input and output clients/ports. When the list is parsed completely(and the DMAs on all the output ports done), an interrupt is generated which we use to notify that the source and destination buffers are done. The rest of the driver is quite similar to other mem2mem drivers, we use the multiplane v4l2 ioctls as the HW support coplanar formats. Signed-off-by: Archit Taneja arc...@ti.com --- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile |2 + drivers/media/platform/ti-vpe/vpe.c | 1763 ++ drivers/media/platform/ti-vpe/vpe_regs.h | 496 + 4 files changed, 2271 insertions(+) create mode 100644 drivers/media/platform/ti-vpe/vpe.c create mode 100644 drivers/media/platform/ti-vpe/vpe_regs.h Just two quick comments, the same as to an earlier patch: consts for tables, and write instead of insert. Tomi signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 7/7] qv4l2: add aspect ratio support
Hi Bård,
Some comments below...
On 08/05/2013 10:56 AM, Bård Eirik Winther wrote:
Signed-off-by: Bård Eirik Winther bwint...@cisco.com
---
utils/qv4l2/capture-win.cpp | 24 ++--
utils/qv4l2/capture-win.h | 8 +++-
utils/qv4l2/general-tab.cpp | 36
utils/qv4l2/general-tab.h | 3 +++
utils/qv4l2/qv4l2.cpp | 22 +++---
utils/qv4l2/qv4l2.h | 2 +-
6 files changed, 84 insertions(+), 11 deletions(-)
diff --git a/utils/qv4l2/capture-win.cpp b/utils/qv4l2/capture-win.cpp
index 435c19b..415829a 100644
--- a/utils/qv4l2/capture-win.cpp
+++ b/utils/qv4l2/capture-win.cpp
@@ -30,6 +30,7 @@
#define MIN_WIN_SIZE_HEIGHT 120
bool CaptureWin::m_enableScaling = true;
+double CaptureWin::m_pixelAspectRatio = 1.0;
CaptureWin::CaptureWin() :
m_curWidth(-1),
@@ -73,6 +74,14 @@ void CaptureWin::resetSize()
resize(w, h);
}
+int CaptureWin::actualFrameWidth(int width)
+{
+ if (m_enableScaling)
+ return (int)((double)width * m_pixelAspectRatio);
+ else
No need for the 'else' statement.
+ return width;
+}
+
QSize CaptureWin::getMargins()
{
int l, t, r, b;
@@ -94,6 +103,14 @@ void CaptureWin::enableScaling(bool enable)
delete event;
}
+void CaptureWin::setPixelAspectRatio(double ratio)
+{
+ m_pixelAspectRatio = ratio;
+ QResizeEvent *event = new QResizeEvent(QSize(width(), height()),
QSize(width(), height()));
+ QCoreApplication::sendEvent(this, event);
+ delete event;
+}
+
void CaptureWin::resize(int width, int height)
{
// Dont resize window if the frame size is the same in
@@ -105,7 +122,7 @@ void CaptureWin::resize(int width, int height)
m_curHeight = height;
QSize margins = getMargins();
- width += margins.width();
+ width = actualFrameWidth(width) + margins.width();
height += margins.height();
QDesktopWidget *screen = QApplication::desktop();
@@ -127,12 +144,15 @@ void CaptureWin::resize(int width, int height)
QSize CaptureWin::scaleFrameSize(QSize window, QSize frame)
{
- int actualFrameWidth = frame.width();;
+ int actualFrameWidth;
int actualFrameHeight = frame.height();
if (!m_enableScaling) {
window.setWidth(frame.width());
window.setHeight(frame.height());
+ actualFrameWidth = frame.width();
+ } else {
+ actualFrameWidth = CaptureWin::actualFrameWidth(frame.width());
}
double newW, newH;
diff --git a/utils/qv4l2/capture-win.h b/utils/qv4l2/capture-win.h
index 1bfb1e1..eded9e0 100644
--- a/utils/qv4l2/capture-win.h
+++ b/utils/qv4l2/capture-win.h
@@ -76,9 +76,10 @@ public:
static bool isSupported() { return false; }
void enableScaling(bool enable);
+ void setPixelAspectRatio(double ratio);
static QSize scaleFrameSize(QSize window, QSize frame);
-public slots:
+ public slots:
void resetSize();
protected:
@@ -99,6 +100,11 @@ protected:
*/
static bool m_enableScaling;
+ /**
+ * @note Aspect ratio it taken care of by scaling, frame size is for
square pixels only!
+ */
+ static double m_pixelAspectRatio;
+
signals:
void close();
diff --git a/utils/qv4l2/general-tab.cpp b/utils/qv4l2/general-tab.cpp
index 5996c03..53b7e36 100644
--- a/utils/qv4l2/general-tab.cpp
+++ b/utils/qv4l2/general-tab.cpp
@@ -53,6 +53,7 @@ GeneralTab::GeneralTab(const QString device, v4l2 fd, int
n, QWidget *parent)
m_tvStandard(NULL),
m_qryStandard(NULL),
m_videoTimings(NULL),
+ m_pixelAspectRatio(NULL),
m_qryTimings(NULL),
m_freq(NULL),
m_vidCapFormats(NULL),
@@ -210,6 +211,20 @@ GeneralTab::GeneralTab(const QString device, v4l2 fd,
int n, QWidget *parent)
connect(m_qryTimings, SIGNAL(clicked()),
SLOT(qryTimingsClicked()));
}
+ if (!isRadio() !isVbi()) {
+ m_pixelAspectRatio = new QComboBox(parent);
+ m_pixelAspectRatio-addItem(Autodetect);
+ m_pixelAspectRatio-addItem(Square);
+ m_pixelAspectRatio-addItem(NTSC/PAL-M/PAL-60);
+ m_pixelAspectRatio-addItem(NTSC/PAL-M/PAL-60, Anamorphic);
+ m_pixelAspectRatio-addItem(PAL/SECAM);
+ m_pixelAspectRatio-addItem(PAL/SECAM, Anamorphic);
+
+ addLabel(Pixel Aspect Ratio);
+ addWidget(m_pixelAspectRatio);
+ connect(m_pixelAspectRatio, SIGNAL(activated(int)),
SIGNAL(pixelAspectRatioChanged()));
+ }
+
if (m_tuner.capability) {
QDoubleValidator *val;
double factor = (m_tuner.capability V4L2_TUNER_CAP_LOW) ? 16
: 16000;
@@ -1105,6 +1120,27 @@ void GeneralTab::updateFrameSize()
updateFrameInterval();
}
+double
[PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
To address the case where physically continous memory MAY NOT be a
mandatory requirement for fb, the patch adds a feature to get non physically
continous memory for fb if IOMMU is supported and if CONTIG memory allocation
fails.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Signed-off-by: Arun Kumar arun...@samsung.com
---
changes since v1:
- Modified to add the fallback patch if CONTIG alloc fails as suggested
by Rob Clark robdcl...@gmail.com and Tomasz Figa
tomasz.f...@gmail.com.
- changed the commit message.
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..9a4b886 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
#include drm/drm_crtc.h
#include drm/drm_fb_helper.h
#include drm/drm_crtc_helper.h
+#include drm/exynos_drm.h
#include exynos_drm_drv.h
#include exynos_drm_fb.h
@@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
- /* 0 means to allocate physically continuous memory */
- exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+ exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
if (IS_ERR(exynos_gem_obj)) {
- ret = PTR_ERR(exynos_gem_obj);
- goto err_release_framebuffer;
+ /*
+* If IOMMU is supported then try to get buffer from
+* non-continous memory area
+*/
+ if (is_drm_iommu_supported(dev))
+ exynos_gem_obj = exynos_drm_gem_create(dev,
+ EXYNOS_BO_NONCONTIG, size);
+ if (IS_ERR(exynos_gem_obj)) {
+ ret = PTR_ERR(exynos_gem_obj);
+ goto err_release_framebuffer;
+ }
+ dev_warn(pdev-dev, exynos_gem_obj for FB is allocated with\n
+ non physically continuous memory\n);
}
exynos_fbdev-exynos_gem_obj = exynos_gem_obj;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 01/13] [media] exynos5-is: Adding media device driver for exynos5
Hi Sylwester,
Thank you for the review.
Will address all your review comments.
Some responses below:
[snip]
+
+static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
+{
+ struct device_node *of_node = fmd-pdev-dev.of_node;
+ int ret;
+
+ /*
+* Runtime resume one of the FIMC entities to make sure
+* the sclk_cam clocks are not globally disabled.
It's a bit mysterious to me, is this requirement still valid on Exynos5 ?
I glanced over the Exynos5250 datasheet and there seem to be no sclk_cam?
clocks dependency on any of GScaler clocks. Maybe you don't need a clock
provider in this driver, perhaps sensor drivers could use sclk_cam clocks
directly, assigned through dts ?
Yes these clocks can be directly exposed via dt.
I will drop clock provider from this driver.
[snip]
+/*
+ * The peripheral sensor clock management.
+ */
+static void fimc_md_put_clocks(struct fimc_md *fmd)
+{
+ int i = FIMC_MAX_CAMCLKS;
+
+ while (--i= 0) {
+ if (IS_ERR(fmd-camclk[i].clock))
+ continue;
+ clk_put(fmd-camclk[i].clock);
+ fmd-camclk[i].clock = ERR_PTR(-EINVAL);
+ }
Please double check if you need this sclk_cam clocks handling. We could
simply add a requirement that this driver supports only sensor subdevs
through the v4l2-async API and which controls their clock themselves.
sclk_cam* handling can be removed and be done from respective
sensors. But I think the sclk_bayer handling needs to be retained in the
media driver.
+}
+
+static int fimc_md_get_clocks(struct fimc_md *fmd)
+{
+ struct device *dev = NULL;
+ char clk_name[32];
+ struct clk *clock;
+ int i, ret = 0;
+
+ for (i = 0; i FIMC_MAX_CAMCLKS; i++)
+ fmd-camclk[i].clock = ERR_PTR(-EINVAL);
+
+ if (fmd-pdev-dev.of_node)
+ dev =fmd-pdev-dev;
+
+ for (i = 0; i SCLK_BAYER; i++) {
+ snprintf(clk_name, sizeof(clk_name), sclk_cam%u, i);
+ clock = clk_get(dev, clk_name);
+
+ if (IS_ERR(clock)) {
+ dev_err(fmd-pdev-dev, Failed to get clock:
%s\n,
+ clk_name);
+ ret = PTR_ERR(clock);
+ break;
+ }
+ fmd-camclk[i].clock = clock;
+ }
+ if (ret)
+ fimc_md_put_clocks(fmd);
+
+ /* Prepare bayer clk */
+ clock = clk_get(dev, sclk_bayer);
+
+ if (IS_ERR(clock)) {
+ dev_err(fmd-pdev-dev, Failed to get clock: %s\n,
+ clk_name);
Wrong error message.
+ ret = PTR_ERR(clock);
+ goto err_exit;
+ }
+ ret = clk_prepare(clock);
+ if (ret 0) {
+ clk_put(clock);
+ fmd-camclk[SCLK_BAYER].clock = ERR_PTR(-EINVAL);
+ goto err_exit;
+ }
+ fmd-camclk[SCLK_BAYER].clock = clock;
Could you explain a bit how is this SCLK_BAYER clock used ? Is it routed
to external image sensor, or is it used only inside an SoC ?
It is not defined properly in the manual, but I suppose its the bus clock
for the bayer rgb data bus. So for proper sensor functionality, we need this
sclk_bayer in addition to the external sensor clks (sclk_cam*). Isn't
exynos5 media driver is the best place to handle such clocks?
+ return 0;
+err_exit:
+ fimc_md_put_clocks(fmd);
+ return ret;
+}
+
Regards
Arun
--
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 v3 01/13] [media] exynos5-is: Adding media device driver for exynos5
Hi Sachin,
Thank you for the review.
On Mon, Aug 5, 2013 at 10:51 AM, Sachin Kamat sachin.ka...@linaro.org wrote:
On 2 August 2013 20:32, Arun Kumar K arun...@samsung.com wrote:
From: Shaik Ameer Basha shaik.am...@samsung.com
This patch adds support for media device for EXYNOS5 SoCs.
The current media device supports the following ips to connect
through the media controller framework.
* MIPI-CSIS
Support interconnection(subdev interface) between devices
* FIMC-LITE
Support capture interface from device(Sensor, MIPI-CSIS) to memory
Support interconnection(subdev interface) between devices
* FIMC-IS
Camera post-processing IP having multiple sub-nodes.
G-Scaler will be added later to the current media device.
The media device creates two kinds of pipelines for connecting
the above mentioned IPs.
The pipeline0 is uses Sensor, MIPI-CSIS and FIMC-LITE which captures
image data and dumps to memory.
Pipeline1 uses FIMC-IS components for doing post-processing
operations on the captured image and give scaled YUV output.
Pipeline0
++ +---+ +---+ ++
| Sensor | -- | MIPI-CSIS | -- | FIMC-LITE | -- | Memory |
++ +---+ +---+ ++
Pipeline1
++ ++ +---+ +---+
| Memory | -- | ISP | -- |SCC| -- |SCP|
++ ++ +---+ +---+
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Signed-off-by: Arun Kumar K arun...@samsung.com
[snip]
+
+Common 'camera' node
+
+
+Required properties:
+
+- compatible : must be samsung,exynos5-fimc, simple-bus
I am not sure if this point was discusssed during the previous
versions. samsung,exynos5-fimc seems a bit generic.
The compatible string should generally point to a specific SoC (the
first one to have this IP), something like samsung,exynos5250-fimc.
Yes will make it samsung,exynos5250-fimc
+- clocks : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names : must contain sclk_cam0, sclk_cam1 entries,
+ matching entries in the clocks property.
+
[snip]
+Example:
+
+ aliases {
+ fimc-lite0 = fimc_lite_0
+ };
+
+ /* Parallel bus IF sensor */
+ i2c_0: i2c@1386 {
+ s5k6aa: sensor@3c {
+ compatible = samsung,s5k6aafx;
+ reg = 0x3c;
+ vddio-supply = ...;
+
+ clock-frequency = 2400;
+ clocks = ...;
+ clock-names = mclk;
+
+ port {
+ s5k6aa_ep: endpoint {
+ remote-endpoint = fimc0_ep;
+ bus-width = 8;
+ hsync-active = 0;
+ vsync-active = 1;
+ pclk-sample = 1;
+ };
+ };
+ };
+ };
+
+ /* MIPI CSI-2 bus IF sensor */
+ s5c73m3: sensor@0x1a {
0x not needed.
Ok.
Regards
Arun
--
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 v3 01/13] [media] exynos5-is: Adding media device driver for exynos5
Hi Arun,
On 08/05/2013 12:06 PM, Arun Kumar K wrote:
Hi Sylwester,
Thank you for the review.
Will address all your review comments.
Some responses below:
Thanks, it took me a while to review this nearly 10k of code.
But fortunately I could spent some more time at the computer
this weekend ;)
[snip]
+
+static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
+{
+ struct device_node *of_node = fmd-pdev-dev.of_node;
+ int ret;
+
+ /*
+* Runtime resume one of the FIMC entities to make sure
+* the sclk_cam clocks are not globally disabled.
It's a bit mysterious to me, is this requirement still valid on Exynos5 ?
I glanced over the Exynos5250 datasheet and there seem to be no sclk_cam?
clocks dependency on any of GScaler clocks. Maybe you don't need a clock
provider in this driver, perhaps sensor drivers could use sclk_cam clocks
directly, assigned through dts ?
Yes these clocks can be directly exposed via dt.
I will drop clock provider from this driver.
That's great, this patch set won't depend then on the proper clock
deregistration support in the common clock framework.
+/*
+ * The peripheral sensor clock management.
+ */
+static void fimc_md_put_clocks(struct fimc_md *fmd)
+{
+ int i = FIMC_MAX_CAMCLKS;
+
+ while (--i= 0) {
+ if (IS_ERR(fmd-camclk[i].clock))
+ continue;
+ clk_put(fmd-camclk[i].clock);
+ fmd-camclk[i].clock = ERR_PTR(-EINVAL);
+ }
Please double check if you need this sclk_cam clocks handling. We could
simply add a requirement that this driver supports only sensor subdevs
through the v4l2-async API and which controls their clock themselves.
sclk_cam* handling can be removed and be done from respective
sensors. But I think the sclk_bayer handling needs to be retained in the
media driver.
Yes, that was my understanding as well.
+}
+
+static int fimc_md_get_clocks(struct fimc_md *fmd)
+{
+ struct device *dev = NULL;
+ char clk_name[32];
+ struct clk *clock;
+ int i, ret = 0;
+
+ for (i = 0; i FIMC_MAX_CAMCLKS; i++)
+ fmd-camclk[i].clock = ERR_PTR(-EINVAL);
+
+ if (fmd-pdev-dev.of_node)
+ dev =fmd-pdev-dev;
+
+ for (i = 0; i SCLK_BAYER; i++) {
+ snprintf(clk_name, sizeof(clk_name), sclk_cam%u, i);
+ clock = clk_get(dev, clk_name);
+
+ if (IS_ERR(clock)) {
+ dev_err(fmd-pdev-dev, Failed to get clock:
%s\n,
+ clk_name);
+ ret = PTR_ERR(clock);
+ break;
+ }
+ fmd-camclk[i].clock = clock;
+ }
+ if (ret)
+ fimc_md_put_clocks(fmd);
+
+ /* Prepare bayer clk */
+ clock = clk_get(dev, sclk_bayer);
+
+ if (IS_ERR(clock)) {
+ dev_err(fmd-pdev-dev, Failed to get clock: %s\n,
+ clk_name);
Wrong error message.
+ ret = PTR_ERR(clock);
+ goto err_exit;
+ }
+ ret = clk_prepare(clock);
+ if (ret 0) {
+ clk_put(clock);
+ fmd-camclk[SCLK_BAYER].clock = ERR_PTR(-EINVAL);
+ goto err_exit;
+ }
+ fmd-camclk[SCLK_BAYER].clock = clock;
Could you explain a bit how is this SCLK_BAYER clock used ? Is it routed
to external image sensor, or is it used only inside an SoC ?
It is not defined properly in the manual, but I suppose its the bus clock
for the bayer rgb data bus. So for proper sensor functionality, we need this
sclk_bayer in addition to the external sensor clks (sclk_cam*). Isn't
exynos5 media driver is the best place to handle such clocks?
I see, I think it's the right place. I was just curious what this clock
was exactly. It an SoC requires it internally then it is correct to handle
it as you do now. And if it happens that it controls the CAM_BAY_MCLK
output clock of the camera bay, then it could be exposed as the master
clock for the device attached to that physical camera port. In that case
the SCLK_CAM bayer clock could be gated conditionally in the media device
driver, depending on the data bus interface used by a remote image data
source device. But that's mostly speculations. I'm fine with associating
this clock with the media device, especially as far as the DT binding is
concerned.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] exynos4-is: Annotate unused functions
Hi Sachin, On 08/05/2013 07:12 AM, Sachin Kamat wrote: On 2 August 2013 12:02, Sachin Kamat sachin.ka...@linaro.org wrote: __is_set_init_isp_aa and fimc_is_hw_set_tune currently do not have any callers. However these functions may be used in the future. Hence instead of deleting them, staticize and annotate them with __maybe_unused flag to avoid compiler warnings. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Thanks for applying the other 2 patches in this series. What is your opinion about this one? Does this look good or do you prefer to delete the code altogether? Thanks for your work on this. I think it would be better to call those functions somewhere instead, e.g. in the fimc-is initialization routine, until there is a user interface available for this 3A control. fimc_is_hw_set_tune() just needs a private control a think. Let me see if I can come up with at least some intermediate patch to achieve this, so the warnings can be eliminated. I wouldn't like to take such steps backwards, marking those functions static an unused. Regards, Sylwester -- 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/6] v4l: ti-vpe: Create a vpdma helper library
On Monday 05 August 2013 01:43 PM, Tomi Valkeinen wrote:
Hi,
On 02/08/13 17:03, Archit Taneja wrote:
+struct vpdma_data_format vpdma_yuv_fmts[] = {
+ [VPDMA_DATA_FMT_Y444] = {
+ .data_type = DATA_TYPE_Y444,
+ .depth = 8,
+ },
This, and all the other tables, should probably be consts?
That's true, I'll fix those.
+static void insert_field(u32 *valp, u32 field, u32 mask, int shift)
+{
+ u32 val = *valp;
+
+ val = ~(mask shift);
+ val |= (field mask) shift;
+ *valp = val;
+}
I think insert normally means, well, inserting a thing in between
something. What you do here is overwriting.
Why not just call it write_field?
sure, will change it.
+ * Allocate a DMA buffer
+ */
+int vpdma_buf_alloc(struct vpdma_buf *buf, size_t size)
+{
+ buf-size = size;
+ buf-mapped = 0;
Maybe true/false is clearer here that 0/1.
okay.
+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait for
completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct vpdma_desc_list *list)
+{
+ /* we always use the first list */
+ int list_num = 0;
+ int list_size;
+
+ if (vpdma_list_busy(vpdma, list_num))
+ return -EBUSY;
+
+ /* 16-byte granularity */
+ list_size = (list-next - list-buf.addr) 4;
+
+ write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list-buf.dma_addr);
+ wmb();
What is the wmb() for?
VPDMA_LIST_ADDR needs to be written before VPDMA_LIST_ATTR, otherwise
VPDMA doesn't work. wmb() ensures the ordering.
+ write_reg(vpdma, VPDMA_LIST_ATTR,
+ (list_num VPDMA_LIST_NUM_SHFT) |
+ (list-type VPDMA_LIST_TYPE_SHFT) |
+ list_size);
+
+ return 0;
+}
+static void vpdma_firmware_cb(const struct firmware *f, void *context)
+{
+ struct vpdma_data *vpdma = context;
+ struct vpdma_buf fw_dma_buf;
+ int i, r;
+
+ dev_dbg(vpdma-pdev-dev, firmware callback\n);
+
+ if (!f || !f-data) {
+ dev_err(vpdma-pdev-dev, couldn't get firmware\n);
+ return;
+ }
+
+ /* already initialized */
+ if (get_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
+ VPDMA_LIST_RDY_SHFT)) {
+ vpdma-ready = true;
+ return;
+ }
+
+ r = vpdma_buf_alloc(fw_dma_buf, f-size);
+ if (r) {
+ dev_err(vpdma-pdev-dev,
+ failed to allocate dma buffer for firmware\n);
+ goto rel_fw;
+ }
+
+ memcpy(fw_dma_buf.addr, f-data, f-size);
+
+ vpdma_buf_map(vpdma, fw_dma_buf);
+
+ write_reg(vpdma, VPDMA_LIST_ADDR, (u32) fw_dma_buf.dma_addr);
+
+ for (i = 0; i 100; i++) { /* max 1 second */
+ msleep_interruptible(10);
You call interruptible version here, but you don't handle the
interrupted case. I believe the loop will just continue looping, even if
the user interrupted.
Okay. I think I don't understand the interruptible version correctly. We
don't need to msleep_interruptible here, we aren't waiting on any wake
up event, we just want to wait till a bit gets set.
I am thinking of implementing something similar to wait_for_bit_change()
in 'drivers/video/omap2/dss/dsi.c'
Archit
--
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: mceusb Fintek ir transmitter only works when X is not running
On Sun, Aug 04, 2013 at 01:56:49PM +0100, Rajil Saraswat wrote: Hi, I have a HP MCE ir transreceiver which is recognised as Fintek device. The receiver works fine, however the transmitter only works when there is no X session running. When X is stopped and the following command is issued from the virtual console (tty1), then the transmitter works: irsend SEND_ONCE mceusb KEY_1 However, as soon as X is started even though irsend goes through, the transmitter led's dont go through. Any idea why this may be happening? These are the system details: #uname -a Linux localhost 3.10.4-gentoo #7 SMP Sun Aug 4 12:07:08 BST 2013 x86_64 Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux # lsusb Bus 002 Device 008: ID 1934:5168 Feature Integration Technology Inc. (Fintek) F71610A or F71612A Consumer Infrared Receiver/Transceiver I have the exact same device and it works fine with 3.10.4 vanilla, whether X is running out or not. Please can you send the output of usbmon while issuing irsend (just the interface with the mce device). Thanks Sean -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [media] exynos4-is: Annotate unused functions
Hi Sylwester, On 5 August 2013 16:35, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Sachin, On 08/05/2013 07:12 AM, Sachin Kamat wrote: On 2 August 2013 12:02, Sachin Kamat sachin.ka...@linaro.org wrote: __is_set_init_isp_aa and fimc_is_hw_set_tune currently do not have any callers. However these functions may be used in the future. Hence instead of deleting them, staticize and annotate them with __maybe_unused flag to avoid compiler warnings. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Thanks for applying the other 2 patches in this series. What is your opinion about this one? Does this look good or do you prefer to delete the code altogether? Thanks for your work on this. I think it would be better to call those functions somewhere instead, e.g. in the fimc-is initialization routine, until there is a user interface available for this 3A control. fimc_is_hw_set_tune() just needs a private control a think. Let me see if I can come up with at least some intermediate patch to achieve this, so the warnings can be eliminated. I wouldn't like to take such steps backwards, marking those functions static an unused. Marking it unused is just a stop gap solution to silence unnecessary warnings. However if you can come up with some users for these functions, then that would be great and right thing to do. -- With warm regards, Sachin -- 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/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors
On Monday 05 August 2013 02:41 PM, Tomi Valkeinen wrote:
On 02/08/13 17:03, Archit Taneja wrote:
Create functions which the VPE driver can use to create a VPDMA descriptor and
add it to a VPDMA descriptor list. These functions take a pointer to an existing
list, and append the configuration/data/control descriptor header to the list.
In the case of configuration descriptors, the creation of a payload block may be
required(the payloads can hold VPE MMR values, or scaler coefficients). The
allocation of the payload buffer and it's content is left to the VPE driver.
However, the VPDMA library provides helper macros to create payload in the
correct format.
Add debug functions to dump the descriptors in a way such that it's easy to see
the values of different fields in the descriptors.
There are lots of defines and inline functions in this patch. But at
least the ones I looked at were only used once.
For example, dtd_set_xfer_length_height() is called only in one place.
Then dtd_set_xfer_length_height() uses DTD_W1(), and again it's the only
place where DTD_W1() is used.
So instead of:
dtd_set_xfer_length_height(dtd, c_rect-width, height);
You could as well do:
dtd-xfer_length_height = (c_rect-width DTD_LINE_LENGTH_SHFT) | height;
Now, presuming the compiler optimizes correctly, there should be no
difference between the two options above. My only point is that I wonder
if having multiple layers there improves readability at all. Some
helper funcs are rather trivial, like:
+static inline void dtd_set_w1(struct vpdma_dtd *dtd, u32 value)
+{
+ dtd-w1 = value;
+}
Then there are some, like dtd_set_type_ctl_stride(), that contains lots
of parameters. Hmm, okay, dtd_set_type_ctl_stride() is called in two
places, so at least in that case it makes sense to have that helper
func. But dtd_set_type_ctl_stride() uses DTD_W0(), and that's again the
only place where it's used.
So, I don't know. I'm not suggesting to change anything, I just started
wondering if all those macros and helpers actually help or not.
There are some more descriptors to add later on, but you are right about
many of them being used at only one place, I'll have a look at the
macros again.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/platform/ti-vpe/vpdma.c | 269 +++
drivers/media/platform/ti-vpe/vpdma.h | 48 ++
drivers/media/platform/ti-vpe/vpdma_priv.h | 695 +
3 files changed, 1012 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index b15b3dd..b957381 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/sched.h
#include linux/slab.h
+#include linux/videodev2.h
#include vpdma.h
#include vpdma_priv.h
@@ -425,6 +426,274 @@ int vpdma_submit_descs(struct vpdma_data *vpdma, struct
vpdma_desc_list *list)
return 0;
}
+static void dump_cfd(struct vpdma_cfd *cfd)
+{
+ int class;
+
+ class = cfd_get_class(cfd);
+
+ pr_debug(config descriptor of payload class: %s\n,
+ class == CFD_CLS_BLOCK ? simple block :
+ address data block);
+
+ if (class == CFD_CLS_BLOCK)
+ pr_debug(word0: dst_addr_offset = 0x%08x\n,
+ cfd_get_dest_addr_offset(cfd));
+
+ if (class == CFD_CLS_BLOCK)
+ pr_debug(word1: num_data_wrds = %d\n, cfd_get_block_len(cfd));
+
+ pr_debug(word2: payload_addr = 0x%08x\n, cfd_get_payload_addr(cfd));
+
+ pr_debug(word3: pkt_type = %d, direct = %d, class = %d, dest = %d,
+ payload_len = %d\n, cfd_get_pkt_type(cfd),
+ cfd_get_direct(cfd), class, cfd_get_dest(cfd),
+ cfd_get_payload_len(cfd));
+}
There's quite a bit of code in these dump functions, and they are always
called. I'm sure getting that data is good for debugging, but I presume
they are quite useless for normal use. So I think they should be
compiled in only if some Kconfig option is selected.
Won't pr_debug() functions actually print something only when
CONFIG_DYNAMIC_DEBUG is selected or if the DEBUG is defined? They will
still consume a lot of code, but it would just end up in dummy printk
calls, right?
+/*
+ * data transfer descriptor
+ *
+ * All fields are 32 bits to make them endian neutral
What does that mean? Why would 32bit fields make it endian neutral?
Each 32 bit field describes one word of the data descriptor. Each
descriptor has a number of parameters.
If we look at the word 'xfer_length_height'. It's composed of height
(from bits 15:0) and width(from bits 31:16). If the word was expressed
using bit fields, we can describe the word(in big endian) as:
struct vpdma_dtd {
...
unsigned intxfer_width:16;
unsigned intxfer_height:16;
...
...
};
and in little endian as:
Re: [PATCH 1/6] v4l: ti-vpe: Create a vpdma helper library
On 05/08/13 14:26, Archit Taneja wrote:
On Monday 05 August 2013 01:43 PM, Tomi Valkeinen wrote:
+/*
+ * submit a list of DMA descriptors to the VPE VPDMA, do not wait
for completion
+ */
+int vpdma_submit_descs(struct vpdma_data *vpdma, struct
vpdma_desc_list *list)
+{
+/* we always use the first list */
+int list_num = 0;
+int list_size;
+
+if (vpdma_list_busy(vpdma, list_num))
+return -EBUSY;
+
+/* 16-byte granularity */
+list_size = (list-next - list-buf.addr) 4;
+
+write_reg(vpdma, VPDMA_LIST_ADDR, (u32) list-buf.dma_addr);
+wmb();
What is the wmb() for?
VPDMA_LIST_ADDR needs to be written before VPDMA_LIST_ATTR, otherwise
VPDMA doesn't work. wmb() ensures the ordering.
Are you sure it's needed? Here's an interesting thread about writing and
reading to registers: http://marc.info/?t=13058859492r=1w=2
+
+for (i = 0; i 100; i++) {/* max 1 second */
+msleep_interruptible(10);
You call interruptible version here, but you don't handle the
interrupted case. I believe the loop will just continue looping, even if
the user interrupted.
Okay. I think I don't understand the interruptible version correctly. We
don't need to msleep_interruptible here, we aren't waiting on any wake
up event, we just want to wait till a bit gets set.
Well, I think the interruptible versions should be used when the user
(wel, userspace program) initiates the action. The user should have the
option to interrupt a possibly long running operation, which is what
msleep_interruptible() makes possible.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH 1/2] ARM: Exynos: replace custom MFC reserved memory handling with generic code
MFC driver use custom bindings for managing reserved memory. Those bindings
are not really specific to MFC device and no even well discussed. They can
be easily replaced with generic, platform independent code for handling
reserved and contiguous memory.
Two additional child devices for each memory port (AXI master) are
introduced to let one assign some properties to each of them. Later one
can also use them to assign properties related to SYSMMU controllers,
which can be used to manage the limited dma window provided by those
memory ports.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
.../devicetree/bindings/media/s5p-mfc.txt | 63 +---
arch/arm/boot/dts/exynos4.dtsi | 10 +++-
arch/arm/boot/dts/exynos4210-origen.dts| 25 +++-
arch/arm/boot/dts/exynos4210-smdkv310.dts | 25 +++-
arch/arm/boot/dts/exynos4412-origen.dts| 25 +++-
arch/arm/boot/dts/exynos4412-smdk4412.dts | 25 +++-
arch/arm/boot/dts/exynos5250-arndale.dts | 26 +++-
arch/arm/boot/dts/exynos5250-smdk5250.dts | 26 +++-
arch/arm/boot/dts/exynos5250.dtsi | 10 +++-
arch/arm/mach-exynos/mach-exynos4-dt.c | 16 -
arch/arm/mach-exynos/mach-exynos5-dt.c | 17 --
arch/arm/plat-samsung/include/plat/mfc.h | 11
arch/arm/plat-samsung/s5p-dev-mfc.c| 32 --
13 files changed, 212 insertions(+), 99 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index df37b02..d9528d4 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -6,10 +6,17 @@ The MFC device driver is a v4l2 driver which can encode/decode
video raw/elementary streams and has support for all popular
video codecs.
+The MFC device is connected to system bus with two memory ports (AXI
+masters) for better performance. Those memory ports are modelled as
+separate child devices, so one can assign some properties to them (like
+memory region for dma buffer allocation or sysmmu controller).
+
Required properties:
- compatible : value should be either one among the following
(a) samsung,mfc-v5 for MFC v5 present in Exynos4 SoCs
(b) samsung,mfc-v6 for MFC v6 present in Exynos5 SoCs
+ and additionally simple-bus to correctly initialize child
+ devices for memory ports (AXI masters)
- reg : Physical base address of the IP registers and length of memory
mapped region.
@@ -19,31 +26,69 @@ Required properties:
- clock-names : from common clock binding: must contain sclk_mfc and mfc,
corresponding to entries in the clocks property.
- - samsung,mfc-r : Base address of the first memory bank used by MFC
- for DMA contiguous memory allocation and its size.
-
- - samsung,mfc-l : Base address of the second memory bank used by MFC
- for DMA contiguous memory allocation and its size.
-
Optional properties:
- samsung,power-domain : power-domain property defined with a phandle
to respective power domain.
+Two child nodes must be defined for MFC device. Their names must be
+following: memport-r and memport-l (right and left). Required
+properties:
+ - compatible : value should be samsung,memport
+ - dma-memory-region : optional property with a phandle to respective memory
+ region (see devicetree/bindings/memory.txt), if no
region
+ is defined, sysmmu controller must be used for managing
+ limited dma window of each memory port.
+
+
Example:
SoC specific DT entry:
mfc: codec@1340 {
- compatible = samsung,mfc-v5;
+ compatible = samsung,mfc-v5, simple-bus;
reg = 0x1340 0x1;
interrupts = 0 94 0;
samsung,power-domain = pd_mfc;
clocks = clock 170, clock 273;
clock-names = sclk_mfc, mfc;
+ status = disabled;
+
+ mfc_r: memport-r {
+ compatible = samsung,memport;
+ };
+
+ mfc_l: memport-l {
+ compatible = samsung,memport;
+ };
};
Board specific DT entry:
+memory {
+ /* ... */
+ reserved-memory {
+ #address-cells = 1;
+ #size-cells = 1;
+
+ mfc_l_mem: mfc_l_region@4300 {
+ compatible = contiguous-memory-region,
reserved-memory-region;
+ reg = 0x4300 0x100;
+ };
+
+ mfc_r_mem: mfc_r_region@5200 {
+ compatible = contiguous-memory-region,
reserved-memory-region;
+ reg = 0x5200 0x100;
+ };
+ };
+};
+
codec@1340 {
- samsung,mfc-r = 0x4300 0x80;
-
[PATCH 2/2] media: s5p-mfc: remove DT hacks and simplify initialization code
This patch removes custom initialization of reserved memory regions from
s5p-mfc driver. Memory initialization can be now handled by generic
code.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 75 ++
1 file changed, 15 insertions(+), 60 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index a130dcd..696e0e0 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1011,51 +1011,11 @@ static int match_child(struct device *dev, void *data)
{
if (!dev_name(dev))
return 0;
- return !strcmp(dev_name(dev), (char *)data);
+ return !!strstr(dev_name(dev), (char *)data);
}
static void *mfc_get_drv_data(struct platform_device *pdev);
-static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
-{
- unsigned int mem_info[2] = { };
-
- dev-mem_dev_l = devm_kzalloc(dev-plat_dev-dev,
- sizeof(struct device), GFP_KERNEL);
- if (!dev-mem_dev_l) {
- mfc_err(Not enough memory\n);
- return -ENOMEM;
- }
- device_initialize(dev-mem_dev_l);
- of_property_read_u32_array(dev-plat_dev-dev.of_node,
- samsung,mfc-l, mem_info, 2);
- if (dma_declare_coherent_memory(dev-mem_dev_l, mem_info[0],
- mem_info[0], mem_info[1],
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
- mfc_err(Failed to declare coherent memory for\n
- MFC device\n);
- return -ENOMEM;
- }
-
- dev-mem_dev_r = devm_kzalloc(dev-plat_dev-dev,
- sizeof(struct device), GFP_KERNEL);
- if (!dev-mem_dev_r) {
- mfc_err(Not enough memory\n);
- return -ENOMEM;
- }
- device_initialize(dev-mem_dev_r);
- of_property_read_u32_array(dev-plat_dev-dev.of_node,
- samsung,mfc-r, mem_info, 2);
- if (dma_declare_coherent_memory(dev-mem_dev_r, mem_info[0],
- mem_info[0], mem_info[1],
- DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE) == 0) {
- pr_err(Failed to declare coherent memory for\n
- MFC device\n);
- return -ENOMEM;
- }
- return 0;
-}
-
/* MFC probe function */
static int s5p_mfc_probe(struct platform_device *pdev)
{
@@ -1107,25 +1067,20 @@ static int s5p_mfc_probe(struct platform_device *pdev)
goto err_res;
}
- if (pdev-dev.of_node) {
- ret = s5p_mfc_alloc_memdevs(dev);
- if (ret 0)
- goto err_res;
- } else {
- dev-mem_dev_l = device_find_child(dev-plat_dev-dev,
- s5p-mfc-l, match_child);
- if (!dev-mem_dev_l) {
- mfc_err(Mem child (L) device get failed\n);
- ret = -ENODEV;
- goto err_res;
- }
- dev-mem_dev_r = device_find_child(dev-plat_dev-dev,
- s5p-mfc-r, match_child);
- if (!dev-mem_dev_r) {
- mfc_err(Mem child (R) device get failed\n);
- ret = -ENODEV;
- goto err_res;
- }
+ dev-mem_dev_l = device_find_child(dev-plat_dev-dev, -l,
+ match_child);
+ if (!dev-mem_dev_l) {
+ mfc_err(Mem child (L) device get failed\n);
+ ret = -ENODEV;
+ goto err_res;
+ }
+
+ dev-mem_dev_r = device_find_child(dev-plat_dev-dev, -r,
+ match_child);
+ if (!dev-mem_dev_r) {
+ mfc_err(Mem child (R) device get failed\n);
+ ret = -ENODEV;
+ goto err_res;
}
dev-alloc_ctx[0] = vb2_dma_contig_init_ctx(dev-mem_dev_l);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Exynos: MFC: clean up device tree bindings
Hello, This patch series are an attempt to cleanup the reserved memory device tree bindings for MFC device. MFC device has two memory ports (AXI masters), which are used to do DMA. Usually separate memory regions are being defined for each of those memory ports to improve performance. Some versions of MFC block have also significant limitation on the possible address range available for each of those memory ports/banks. In the board file era, there have been two additional platform devices defined for each of memory ports (named s5p-mfc-l and s5p-mfc-r) to let the driver distinguish memory allocations done for each of them. Each of those platform devices might have special DMA ops assigned to fulfil specific memory requirements for a given memory port. Later, when device tree binding was added for MFC device, those memory ports were designed as two additional properties: samsung,mfc-l and samsung,mfc-r for codec node. This approach however has some significant limitation, so I propose to redesign it before the binding become considered as stable. The first problem with the proposed bindings is the fact that samsung,mfc-r/samsung,mfc-l properties are tied only to base address + size attributes of reserved memory and do not allow to assign any other attributes to those memory ports. This limits using those memory ports only to simple reserved memory. The second issue with those attributes is the fact that they are very specific to the MFC device, while reserved memory region is something more generic, which can be used for other devices as well. For example even on Exynos4 platform, similar reserved memory handling will be needed for the FIMC ISP device. For handling reserved memory regions and having a method to assign them to particular device I have posted the patches [1], which add device tree support to Contiguous Memory Allocator and simple reserved memory allocator based on dma_declare_coherent() function. This patch series is my proposal for replacing those custom bindings with generic approach, proposed in [1]. To get it working we need separate device node for each memory port, what has been achieved by adding simple-bus compatibility entry to the main MFC device node and adding two child nodes, which represent each memory port. Those child nodes have compatible property set to samsung,memport. With such a structure dma-memory-region property with a phandle to respective reserved region can be easily added to the child nodes of MFC device. The advantage of such approach is the fact that those child nodes can be also used for adding properties for IOMMU (SYSMMU) controllers. This way also bindings for SYSMMU and the code, which handles it can be simplified, because respective device tree part better matches physical hardware design. Best regards Marek Szyprowski Samsung RD Institute Poland [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/257615/ Patch summary: Marek Szyprowski (2): ARM: Exynos: replace custom MFC reserved memory handling with generic code media: s5p-mfc: remove DT hacks and simplify initialization code .../devicetree/bindings/media/s5p-mfc.txt | 63 +--- arch/arm/boot/dts/exynos4.dtsi | 10 ++- arch/arm/boot/dts/exynos4210-origen.dts| 25 ++- arch/arm/boot/dts/exynos4210-smdkv310.dts | 25 ++- arch/arm/boot/dts/exynos4412-origen.dts| 25 ++- arch/arm/boot/dts/exynos4412-smdk4412.dts | 25 ++- arch/arm/boot/dts/exynos5250-arndale.dts | 26 ++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 26 ++- arch/arm/boot/dts/exynos5250.dtsi | 10 ++- arch/arm/mach-exynos/mach-exynos4-dt.c | 16 - arch/arm/mach-exynos/mach-exynos5-dt.c | 17 - arch/arm/plat-samsung/include/plat/mfc.h | 11 --- arch/arm/plat-samsung/s5p-dev-mfc.c| 32 - drivers/media/platform/s5p-mfc/s5p_mfc.c | 75 14 files changed, 227 insertions(+), 159 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] v4l: ti-vpe: Add helpers for creating VPDMA descriptors
On 05/08/13 15:05, Archit Taneja wrote:
On Monday 05 August 2013 02:41 PM, Tomi Valkeinen wrote:
There's quite a bit of code in these dump functions, and they are always
called. I'm sure getting that data is good for debugging, but I presume
they are quite useless for normal use. So I think they should be
compiled in only if some Kconfig option is selected.
Won't pr_debug() functions actually print something only when
CONFIG_DYNAMIC_DEBUG is selected or if the DEBUG is defined? They will
If DEBUG is defined, they are always printed. If dynamic debug is in
use, the user has to enable debug prints for VPE for the dumps to be
printed.
still consume a lot of code, but it would just end up in dummy printk
calls, right?
Yes.
Well, I don't know VPE, so I can't really say how much those prints are
needed or not. They just looked very verbose to me.
I think we should have normal level debugging messages compiled in by
default, and for verbose there should be a separate compile options.
With verbose I mean something that may be useful if you are changing the
code and want to verify it or debugging some very odd bug. I.e. for the
developer of the driver.
And with normal something that would be used when, say, somebody uses
VPE for in his app, but things don't seem to be quite right, and there's
need to get some info on what is going on. I.e. for normal user.
But that's just my opinion, and it's obviously difficult to define those
clearly =). To be honest, I don't know how much overhead very verbose
kernel debug prints even cause. Maybe it's negligible.
+/*
+ * data transfer descriptor
+ *
+ * All fields are 32 bits to make them endian neutral
What does that mean? Why would 32bit fields make it endian neutral?
Each 32 bit field describes one word of the data descriptor. Each
descriptor has a number of parameters.
If we look at the word 'xfer_length_height'. It's composed of height
(from bits 15:0) and width(from bits 31:16). If the word was expressed
using bit fields, we can describe the word(in big endian) as:
struct vpdma_dtd {
...
unsigned intxfer_width:16;
unsigned intxfer_height:16;
...
...
};
and in little endian as:
struct vpdma_dtd {
...
unsigned intxfer_height:16;
unsigned intxfer_width:16;
...
...
};
So this representation makes it endian dependent. Maybe the comment
should be improved saying that usage of u32 words instead of bit fields
prevents endian issues.
No, I don't think that's correct. Endianness is about bytes, not 16 bit
words. The above text doesn't make much sense to me.
I haven't really worked with endiannes issues, but maybe __le32 and
others should be used in the struct, if that struct is read by the HW.
And use cpu_to_le32() others to write those. But googling will
probably give more info (I should read also =).
+ */
+struct vpdma_dtd {
+u32type_ctl_stride;
+union {
+u32xfer_length_height;
+u32w1;
+};
+dma_addr_tstart_addr;
+u32pkt_ctl;
+union {
+u32frame_width_height;/* inbound */
+dma_addr_tdesc_write_addr;/* outbound */
Are you sure dma_addr_t is always 32 bit?
I am not sure about this.
Is this struct directly read by the HW, or written to HW? If so, I
believe using dma_addr_t is very wrong here. Having a typedef like
dma_addr_t hides the actual type used for it. So even if it currently
would always be 32bit, there's no guarantee.
+};
+union {
+u32start_h_v;/* inbound */
+u32max_width_height;/* outbound */
+};
+u32client_attr0;
+u32client_attr1;
+};
I'm not sure if I understand the struct right, but presuming this one
struct is used for both writing and reading, and certain set of fields
is used for writes and other set for reads, would it make sense to have
two different structs, instead of using unions? Although they do have
many common fields, and the unions are a bit scattered there, so I don't
know if that would be cleaner...
It helps in a having a common debug function, I don't see much benefit
apart from that. I'll see if it's better to have them as separate structs.
Ok. Does the struct have any bit or such that tells us if the current
data is inbound or outbound?
Tomi
signature.asc
Description: OpenPGP digital signature
Proposal
I seek your consent to present you as the next of kin to the account of a deceased client for claims valued at Fourteen million, three hundred thousand Pounds. Contact me through my private email for details: halawani@ovi.com Mr. Halawani, Azhar Abdulrahim. Solicitors Legal Services Barristers United Kingdom -- 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] drm/exynos: Add fallback option to get non physically continous memory for fb
On Mon, Aug 5, 2013 at 5:44 AM, Vikas Sajjan vikas.saj...@linaro.org wrote:
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
To address the case where physically continous memory MAY NOT be a
mandatory requirement for fb, the patch adds a feature to get non physically
continous memory for fb if IOMMU is supported and if CONTIG memory allocation
fails.
Reviewed-by: Rob Clark robdcl...@gmail.com
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Signed-off-by: Arun Kumar arun...@samsung.com
---
changes since v1:
- Modified to add the fallback patch if CONTIG alloc fails as
suggested
by Rob Clark robdcl...@gmail.com and Tomasz Figa
tomasz.f...@gmail.com.
- changed the commit message.
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..9a4b886 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
#include drm/drm_crtc.h
#include drm/drm_fb_helper.h
#include drm/drm_crtc_helper.h
+#include drm/exynos_drm.h
#include exynos_drm_drv.h
#include exynos_drm_fb.h
@@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
- /* 0 means to allocate physically continuous memory */
- exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+ exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
if (IS_ERR(exynos_gem_obj)) {
- ret = PTR_ERR(exynos_gem_obj);
- goto err_release_framebuffer;
+ /*
+* If IOMMU is supported then try to get buffer from
+* non-continous memory area
+*/
+ if (is_drm_iommu_supported(dev))
+ exynos_gem_obj = exynos_drm_gem_create(dev,
+ EXYNOS_BO_NONCONTIG, size);
+ if (IS_ERR(exynos_gem_obj)) {
+ ret = PTR_ERR(exynos_gem_obj);
+ goto err_release_framebuffer;
+ }
+ dev_warn(pdev-dev, exynos_gem_obj for FB is allocated
with\n
+ non physically continuous memory\n);
}
exynos_fbdev-exynos_gem_obj = exynos_gem_obj;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2] drm/exynos: Add fallback option to get non physically continous memory for fb
On Monday 05 of August 2013 15:14:42 Vikas Sajjan wrote:
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate
buffer. [0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
To address the case where physically continous memory MAY NOT be a
mandatory requirement for fb, the patch adds a feature to get non
physically continous memory for fb if IOMMU is supported and if CONTIG
memory allocation fails.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Signed-off-by: Arun Kumar arun...@samsung.com
---
changes since v1:
- Modified to add the fallback patch if CONTIG alloc fails as suggested
by Rob Clark robdcl...@gmail.com and Tomasz Figa
tomasz.f...@gmail.com.
- changed the commit message.
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..9a4b886
100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
#include drm/drm_crtc.h
#include drm/drm_fb_helper.h
#include drm/drm_crtc_helper.h
+#include drm/exynos_drm.h
#include exynos_drm_drv.h
#include exynos_drm_fb.h
@@ -165,11 +166,21 @@ static int exynos_drm_fbdev_create(struct
drm_fb_helper *helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
- /* 0 means to allocate physically continuous memory */
- exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+ exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
You can put the fallback here like this:
if (IS_ERR(exynos_gem_obj) is_drm_iommu_supported(dev)) {
/*
* If IOMMU is supported then try to get buffer from
* non-continous memory area
*/
dev_warn(pdev-dev, contiguous FB allocation failed, falling
back to non-contiguous\n);
exynos_gem_obj = exynos_drm_gem_create(dev,
EXYNOS_BO_NONCONTIG, size);
}
if (IS_ERR(exynos_gem_obj)) {
- ret = PTR_ERR(exynos_gem_obj);
- goto err_release_framebuffer;
And then you can leave this original check untouched, reducing the
diffstat and unnecessary code indentation.
+ /*
+ * If IOMMU is supported then try to get buffer from
+ * non-continous memory area
+ */
+ if (is_drm_iommu_supported(dev))
+ exynos_gem_obj = exynos_drm_gem_create(dev,
+ EXYNOS_BO_NONCONTIG, size);
+ if (IS_ERR(exynos_gem_obj)) {
+ ret = PTR_ERR(exynos_gem_obj);
+ goto err_release_framebuffer;
+ }
+ dev_warn(pdev-dev, exynos_gem_obj for FB is allocated with\n
+ non physically continuous memory\n);
Please don't split messages into multiple lines, because this makes
grepping for them harder (and checkpatch complains).
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 03/13] [media] exynos5-fimc-is: Add driver core files
Hi Sylwester,
On Sun, Aug 4, 2013 at 3:12 AM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
On 08/02/2013 05:02 PM, Arun Kumar K wrote:
This driver is for the FIMC-IS IP available in Samsung Exynos5
SoC onwards. This patch adds the core files for the new driver.
Signed-off-by: Arun Kumar Karun...@samsung.com
Signed-off-by: Kilyeon Imkilyeon...@samsung.com
---
drivers/media/platform/exynos5-is/fimc-is-core.c | 394
++
drivers/media/platform/exynos5-is/fimc-is-core.h | 122 +++
2 files changed, 516 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-core.c
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-core.h
diff --git a/drivers/media/platform/exynos5-is/fimc-is-core.c
b/drivers/media/platform/exynos5-is/fimc-is-core.c
new file mode 100644
index 000..7b7762b
--- /dev/null
+++ b/drivers/media/platform/exynos5-is/fimc-is-core.c
@@ -0,0 +1,394 @@
+/*
+ * Samsung EXYNOS5 FIMC-IS (Imaging Subsystem) driver
+*
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Arun Kumar Karun...@samsung.com
+ *
+ * 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.
+ */
+
+#includelinux/bug.h
+#includelinux/ctype.h
+#includelinux/device.h
+#includelinux/debugfs.h
+#includelinux/delay.h
+#includelinux/errno.h
+#includelinux/err.h
+#includelinux/firmware.h
+#includelinux/fs.h
+#includelinux/gpio.h
+#includelinux/interrupt.h
+#includelinux/kernel.h
+#includelinux/list.h
+#includelinux/module.h
+#includelinux/types.h
+#includelinux/platform_device.h
+#includelinux/pm_runtime.h
+#includelinux/slab.h
+#includelinux/videodev2.h
+#includelinux/of.h
+#includelinux/of_gpio.h
+#includelinux/of_address.h
+#includelinux/of_platform.h
+#includelinux/of_irq.h
+#includelinux/pinctrl/consumer.h
+
+#includemedia/v4l2-device.h
+#includemedia/v4l2-ioctl.h
+#includemedia/v4l2-mem2mem.h
+#includemedia/v4l2-of.h
+#includemedia/videobuf2-core.h
+#includemedia/videobuf2-dma-contig.h
+
+#include fimc-is.h
+#include fimc-is-i2c.h
+
+#define CLK_MCU_ISP_DIV0_FREQ (200 * 100)
+#define CLK_MCU_ISP_DIV1_FREQ (100 * 100)
+#define CLK_ISP_DIV0_FREQ (134 * 100)
+#define CLK_ISP_DIV1_FREQ (68 * 100)
+#define CLK_ISP_DIVMPWM_FREQ (34 * 100)
+
+static char *fimc_is_clock_name[] = {
+ [IS_CLK_ISP]= isp,
+ [IS_CLK_MCU_ISP]= mcu_isp,
+ [IS_CLK_ISP_DIV0] = isp_div0,
+ [IS_CLK_ISP_DIV1] = isp_div1,
+ [IS_CLK_ISP_DIVMPWM]= isp_divmpwm,
+ [IS_CLK_MCU_ISP_DIV0] = mcu_isp_div0,
+ [IS_CLK_MCU_ISP_DIV1] = mcu_isp_div1,
+};
+
+static void fimc_is_put_clocks(struct fimc_is *is)
+{
+ int i;
+
+ for (i = 0; i IS_CLK_MAX_NUM; i++) {
+ if (IS_ERR(is-clock[i]))
+ continue;
+ clk_unprepare(is-clock[i]);
+ clk_put(is-clock[i]);
+ is-clock[i] = NULL;
+ }
+}
+
+static int fimc_is_get_clocks(struct fimc_is *is)
+{
+ struct device *dev =is-pdev-dev;
+ int i, ret;
+
+ for (i = 0; i IS_CLK_MAX_NUM; i++) {
+ is-clock[i] = clk_get(dev, fimc_is_clock_name[i]);
+ if (IS_ERR(is-clock[i]))
+ goto err;
+ ret = clk_prepare(is-clock[i]);
+ if (ret 0) {
+ clk_put(is-clock[i]);
+ is-clock[i] = ERR_PTR(-EINVAL);
+ goto err;
+ }
+ }
+ return 0;
+err:
+ fimc_is_put_clocks(is);
+ pr_err(Failed to get clock: %s\n, fimc_is_clock_name[i]);
+ return -ENXIO;
+}
+
+static int fimc_is_configure_clocks(struct fimc_is *is)
+{
+ int i, ret;
+
+ for (i = 0; i IS_CLK_MAX_NUM; i++)
+ is-clock[i] = ERR_PTR(-EINVAL);
+
+ ret = fimc_is_get_clocks(is);
+ if (ret)
+ return ret;
+
+ /* Set rates */
+ ret = clk_set_rate(is-clock[IS_CLK_MCU_ISP_DIV0],
+ CLK_MCU_ISP_DIV0_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_MCU_ISP_DIV1],
+ CLK_MCU_ISP_DIV1_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_ISP_DIV0], CLK_ISP_DIV0_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_ISP_DIV1], CLK_ISP_DIV1_FREQ);
+ if (ret)
+ return ret;
+ ret = clk_set_rate(is-clock[IS_CLK_ISP_DIVMPWM],
+ CLK_ISP_DIVMPWM_FREQ);
+ return ret;
+}
+
+static void fimc_is_pipelines_destroy(struct fimc_is *is)
+{
+ int i;
+
+ for (i = 0; i is-num_instance; i++)
Re: [PATCH] trivial: adjust code alignment
Hello Julia, IMHO keep the patch as it is. It does not change any code that is good. Suspicious code that comes up here can be addressed in a separate patch. just my 2 cents, re, wh Am 05.08.2013 18:19, schrieb Julia Lawall: On Mon, 5 Aug 2013, Dan Carpenter wrote: On Mon, Aug 05, 2013 at 04:47:39PM +0200, Julia Lawall wrote: diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c index e8a1ce2..4a5a5dc 100644 --- a/drivers/media/i2c/ov7670.c +++ b/drivers/media/i2c/ov7670.c @@ -1369,8 +1369,8 @@ static int ov7670_s_exp(struct v4l2_subdev *sd, int value) unsigned char com1, com8, aech, aechh; ret = ov7670_read(sd, REG_COM1, com1) + -ov7670_read(sd, REG_COM8, com8); -ov7670_read(sd, REG_AECHH, aechh); +ov7670_read(sd, REG_COM8, com8); +ov7670_read(sd, REG_AECHH, aechh); if (ret) return ret; The new indenting isn't correct here and anyway the intent was to combine all the error codes together and return them as an error code jumble. I'm not a fan of error code jumbles, probably the right thing is to check each function call or, barring that, to return -EIO. Oops, thanks for spotting that. I'm not sure whether it is safe to abort these calls as soon as the first one fails, but perhaps I could introduce some more variables, and test them all afterwards. What should I do with the big patch? Resend it with this cut out? Or, considering that I might have overlooked something else, send 90 some little ones? thanks, julia -- To unsubscribe from this list: send the line unsubscribe kernel-janitors 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] trivial: adjust code alignment
On Mon, 5 Aug 2013, walter harms wrote: Hello Julia, IMHO keep the patch as it is. It does not change any code that is good. Suspicious code that comes up here can be addressed in a separate patch. OK, thanks! julia -- 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] trivial: adjust code alignment
On Mon, 5 Aug 2013, Dan Carpenter wrote: On Mon, Aug 05, 2013 at 04:47:39PM +0200, Julia Lawall wrote: diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c index e8a1ce2..4a5a5dc 100644 --- a/drivers/media/i2c/ov7670.c +++ b/drivers/media/i2c/ov7670.c @@ -1369,8 +1369,8 @@ static int ov7670_s_exp(struct v4l2_subdev *sd, int value) unsigned char com1, com8, aech, aechh; ret = ov7670_read(sd, REG_COM1, com1) + - ov7670_read(sd, REG_COM8, com8); - ov7670_read(sd, REG_AECHH, aechh); + ov7670_read(sd, REG_COM8, com8); + ov7670_read(sd, REG_AECHH, aechh); if (ret) return ret; The new indenting isn't correct here and anyway the intent was to combine all the error codes together and return them as an error code jumble. I'm not a fan of error code jumbles, probably the right thing is to check each function call or, barring that, to return -EIO. Oops, thanks for spotting that. I'm not sure whether it is safe to abort these calls as soon as the first one fails, but perhaps I could introduce some more variables, and test them all afterwards. What should I do with the big patch? Resend it with this cut out? Or, considering that I might have overlooked something else, send 90 some little ones? thanks, julia -- 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] trivial: adjust code alignment
On Mon, 5 Aug 2013 18:19:18 +0200 (CEST) Julia Lawall julia.law...@lip6.fr wrote: Oops, thanks for spotting that. I'm not sure whether it is safe to abort these calls as soon as the first one fails, but perhaps I could introduce some more variables, and test them all afterwards. Yes, it would be safe. But it's hard to imagine a scenario where any of those particular calls would fail that doesn't involve smoke. The code is evidence of ancient laziness on my part. I'll add fixing it up to my list of things to do. Thanks, jon -- 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 v3 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation
On 08/03/2013 03:41 PM, Sylwester Nawrocki wrote: On 08/02/2013 05:02 PM, Arun Kumar K wrote: The patch adds the DT binding documentation for Samsung Exynos5 SoC series imaging subsystem (FIMC-IS). diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt new file mode 100644 index 000..49a373a --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt @@ -0,0 +1,52 @@ +Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS) +-- + +The camera subsystem on Samsung Exynos5 SoC has some changes relative +to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and +FIMC-LITE IPs but has a much improved version of FIMC-IS which can +handle sensor controls and camera post-processing operations. The +Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many +post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two +dedicated scalers (SCC and SCP). So there are a lot of blocks mentioned there, yet the binding doesn't seem to describe most of it. Is the binding complete? +pmu subnode +--- + +Required properties: + - reg : should contain PMU physical base address and size of the memory + mapped registers. I think you need a compatible value for this. How else is the node identified? The node name probably should not be used for identification. + +i2c-isp (ISP I2C bus controller) nodes +-- + +Required properties: + +- compatible: should be samsung,exynos4212-i2c-isp for Exynos4212, + Exynos4412 and Exynos5250 SoCs; +- reg: physical base address and length of the registers set; +- clocks: must contain gate clock specifier for this controller; +- clock-names: must contain i2c_isp entry. + +For the above nodes it is required to specify a pinctrl state named default, Is above nodes both pmu, i2c-isp? It might make sense to be more explicit re: which nodes this comment applies to. +according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt. + +Device tree nodes of the image sensors' controlled directly by the FIMC-IS s/'// ? +firmware must be child nodes of their corresponding ISP I2C bus controller node. +The data link of these image sensors must be specified using the common video +interfaces bindings, defined in video-interfaces.txt. -- 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] trivial: adjust code alignment
On Mon, Aug 05, 2013 at 06:24:43PM +0200, walter harms wrote: Hello Julia, IMHO keep the patch as it is. It does not change any code that is good. Suspicious code that comes up here can be addressed in a separate patch. Gar... No, if we silence static checker warnings without fixing the bug then we are hiding real problems and making them more difficult to find. Just drop this chunk. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Exynos: MFC: clean up device tree bindings
On 08/05/13 21:26, Marek Szyprowski wrote: Hello, Hi, This patch series are an attempt to cleanup the reserved memory device tree bindings for MFC device. MFC device has two memory ports (AXI masters), which are used to do DMA. Usually separate memory regions are being defined for each of those memory ports to improve performance. Some versions of MFC block have also significant limitation on the possible address range available for each of those memory ports/banks. In the board file era, there have been two additional platform devices defined for each of memory ports (named s5p-mfc-l and s5p-mfc-r) to let the driver distinguish memory allocations done for each of them. Each of those platform devices might have special DMA ops assigned to fulfil specific memory requirements for a given memory port. Later, when device tree binding was added for MFC device, those memory ports were designed as two additional properties: samsung,mfc-l and samsung,mfc-r for codec node. This approach however has some significant limitation, so I propose to redesign it before the binding become considered as stable. The first problem with the proposed bindings is the fact that samsung,mfc-r/samsung,mfc-l properties are tied only to base address + size attributes of reserved memory and do not allow to assign any other attributes to those memory ports. This limits using those memory ports only to simple reserved memory. The second issue with those attributes is the fact that they are very specific to the MFC device, while reserved memory region is something more generic, which can be used for other devices as well. For example even on Exynos4 platform, similar reserved memory handling will be needed for the FIMC ISP device. For handling reserved memory regions and having a method to assign them to particular device I have posted the patches [1], which add device tree support to Contiguous Memory Allocator and simple reserved memory allocator based on dma_declare_coherent() function. This patch series is my proposal for replacing those custom bindings with generic approach, proposed in [1]. To get it working we need separate device node for each memory port, what has been achieved by adding simple-bus compatibility entry to the main MFC device node and adding two child nodes, which represent each memory port. Those child nodes have compatible property set to samsung,memport. With such a structure dma-memory-region property with a phandle to respective reserved region can be easily added to the child nodes of MFC device. The advantage of such approach is the fact that those child nodes can be also used for adding properties for IOMMU (SYSMMU) controllers. This way also bindings for SYSMMU and the code, which handles it can be simplified, because respective device tree part better matches physical hardware design. Best regards Marek Szyprowski Samsung RD Institute Poland [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/257615/ Patch summary: Marek Szyprowski (2): ARM: Exynos: replace custom MFC reserved memory handling with generic code media: s5p-mfc: remove DT hacks and simplify initialization code .../devicetree/bindings/media/s5p-mfc.txt | 63 +--- arch/arm/boot/dts/exynos4.dtsi | 10 ++- arch/arm/boot/dts/exynos4210-origen.dts| 25 ++- arch/arm/boot/dts/exynos4210-smdkv310.dts | 25 ++- arch/arm/boot/dts/exynos4412-origen.dts| 25 ++- arch/arm/boot/dts/exynos4412-smdk4412.dts | 25 ++- arch/arm/boot/dts/exynos5250-arndale.dts | 26 ++- arch/arm/boot/dts/exynos5250-smdk5250.dts | 26 ++- arch/arm/boot/dts/exynos5250.dtsi | 10 ++- arch/arm/mach-exynos/mach-exynos4-dt.c | 16 - arch/arm/mach-exynos/mach-exynos5-dt.c | 17 - arch/arm/plat-samsung/include/plat/mfc.h | 11 --- arch/arm/plat-samsung/s5p-dev-mfc.c| 32 - drivers/media/platform/s5p-mfc/s5p_mfc.c | 75 14 files changed, 227 insertions(+), 159 deletions(-) Nice cleanup MFC dt bindings, BTW, IMHO, how about keeping the reserved memory in exynos4.dtsi instead of adding them in each board dts files, it depends on board though... Kamil, if you're OK on the 2nd patch, please let me know so that this could be merged into samsung tree for v3.12.. Thanks, Kukjin -- 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 v6 00/10] Renesas VSP1 driver
Hello, Here's the sixth version of the VSP1 engine (a Video Signal Processor found in several Renesas R-Car SoCs) driver. This version adds a videobuf2 mmap locking fix and improves the documentation patch (thanks to Hans for the discussion we had on IRC, hopefully we won't need another round now). The VSP1 is a video processing engine that includes a blender, scalers, filters and statistics computation. Configurable data path routing logic allows ordering the internal blocks in a flexible way, making this driver a prime candidate for the media controller API. Due to the configurable nature of the pipeline the driver doesn't use the V4L2 mem-to-mem framework, even though the device usually operates in memory to memory mode. Only the read pixel formatters, up/down scalers, write pixel formatters and LCDC interface are supported at this stage. The patch series starts with a fix for the media controller graph traversal code, three documentation fixes, a videobuf2 mmap locking fix and new pixel format and media bus code definitions. The last three patches finally add the VSP1 driver and fix two issues (I haven't squashed the patches together to keep proper attribution). Changes since v1: - Updated to the v3.11 media controller API changes - Only add the LIF entity to the entities list when the LIF is present - Added a MODULE_ALIAS() - Fixed file descriptions in comment blocks - Removed function prototypes for the unimplemented destroy functions - Fixed a typo in the HST register name - Fixed format propagation for the UDS entities - Added v4l2_capability::device_caps support - Prefix the device name with platform: in bus_info - Zero the v4l2_pix_format priv field in the internal try format handler - Use vb2_is_busy() instead of vb2_is_streaming() when setting the format - Use the vb2_ioctl_* handlers where possible Changes since v2: - Use a bitmap to track visited entities during graph traversal - Fixed a typo in the V4L2_MBUS_FMT_ARGB888_1X32 documentation - Fix register macros that were missing a n argument - Mask unused bits when clearing the interrupt status register - Explain why stride alignment to 128 bytes is needed - Use the aligned stride value when computing the image size - Assorted cosmetic changes Changes since v3: - Handle timeout errors when resetting WPFs - Use DECLARE_BITMAP - Update the NV16M/NV61M documentation to mention the multi-planar API for NV61M Changes since v4: - Clarify the VIDIOC_CREATE_BUFS format requirements in the V4L2 documentation - Clarify vb2 queue_setup() and buf_prepare() usage documentation - Remove duplicate printk's in devm_* error paths - Implement VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF support - Reject invalid buffers in the .buffer_queue() handler Changes since v5: - Use the vb2 fop helpers - Reword the VIDIOC_CREATE_BUFS clarification - Take the queue or device lock in vb2_fop_mmap() - Accept custom sizeimage values in .queue_setup() Katsuya Matsubara (2): vsp1: Fix lack of the sink entity registration for enabled links vsp1: Use the maximum number of entities defined in platform data Laurent Pinchart (8): media: Add support for circular graph traversal Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements media: vb2: Clarify queue_setup() and buf_prepare() usage documentation media: vb2: Take queue or device lock in vb2_fop_mmap() v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value v4l: Add media format codes for ARGB and AYUV on 32-bit busses v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats v4l: Renesas R-Car VSP1 driver Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 171 Documentation/DocBook/media/v4l/pixfmt.xml |1 + Documentation/DocBook/media/v4l/subdev-formats.xml | 611 +-- .../DocBook/media/v4l/vidioc-create-bufs.xml | 41 +- Documentation/DocBook/media_api.tmpl |6 + drivers/media/media-entity.c | 14 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile|2 + drivers/media/platform/vsp1/Makefile |5 + drivers/media/platform/vsp1/vsp1.h | 73 ++ drivers/media/platform/vsp1/vsp1_drv.c | 495 + drivers/media/platform/vsp1/vsp1_entity.c | 181 drivers/media/platform/vsp1/vsp1_entity.h | 68 ++ drivers/media/platform/vsp1/vsp1_lif.c | 238 + drivers/media/platform/vsp1/vsp1_lif.h | 37 + drivers/media/platform/vsp1/vsp1_regs.h| 581 +++ drivers/media/platform/vsp1/vsp1_rpf.c | 209 drivers/media/platform/vsp1/vsp1_rwpf.c| 124 +++ drivers/media/platform/vsp1/vsp1_rwpf.h| 53 + drivers/media/platform/vsp1/vsp1_uds.c | 346 +++ drivers/media/platform/vsp1/vsp1_uds.h | 40 +
[PATCH v6 09/10] vsp1: Fix lack of the sink entity registration for enabled links
From: Katsuya Matsubara ma...@igel.co.jp Each source entity maintains a pointer to the counterpart sink entity while an enabled link connects them. It should be managed by the setup_link callback in the media controller framework at runtime. However, enabled links which connect RPFs and WPFs that have an equivalent index number are created during initialization. This registers the pointer to a sink entity from the source entity when an enabled link is created. Signed-off-by: Katsuya Matsubara ma...@igel.co.jp Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/platform/vsp1/vsp1_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/vsp1/vsp1_drv.c b/drivers/media/platform/vsp1/vsp1_drv.c index e58e49c..41dd891 100644 --- a/drivers/media/platform/vsp1/vsp1_drv.c +++ b/drivers/media/platform/vsp1/vsp1_drv.c @@ -101,6 +101,9 @@ static int vsp1_create_links(struct vsp1_device *vsp1, struct vsp1_entity *sink) entity, pad, flags); if (ret 0) return ret; + + if (flags MEDIA_LNK_FL_ENABLED) + source-sink = entity; } } -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 10/10] vsp1: Use the maximum number of entities defined in platform data
From: Katsuya Matsubara ma...@igel.co.jp
The VSP1 driver allows to define the maximum number of each module
such as RPF, WPF, and UDS in a platform data definition.
This suppresses operations for nonexistent or unused modules.
Signed-off-by: Katsuya Matsubara ma...@igel.co.jp
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vsp1/vsp1_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 41dd891..8700842 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -35,7 +35,7 @@ static irqreturn_t vsp1_irq_handler(int irq, void *data)
irqreturn_t ret = IRQ_NONE;
unsigned int i;
- for (i = 0; i VPS1_MAX_WPF; ++i) {
+ for (i = 0; i vsp1-pdata-wpf_count; ++i) {
struct vsp1_rwpf *wpf = vsp1-wpf[i];
struct vsp1_pipeline *pipe;
u32 status;
@@ -243,7 +243,7 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
/* Reset any channel that might be running. */
status = vsp1_read(vsp1, VI6_STATUS);
- for (i = 0; i VPS1_MAX_WPF; ++i) {
+ for (i = 0; i vsp1-pdata-wpf_count; ++i) {
unsigned int timeout;
if (!(status VI6_STATUS_SYS_ACT(i)))
@@ -267,10 +267,10 @@ static int vsp1_device_init(struct vsp1_device *vsp1)
vsp1_write(vsp1, VI6_CLK_DCSWT, (8 VI6_CLK_DCSWT_CSTPW_SHIFT) |
(8 VI6_CLK_DCSWT_CSTRW_SHIFT));
- for (i = 0; i VPS1_MAX_RPF; ++i)
+ for (i = 0; i vsp1-pdata-rpf_count; ++i)
vsp1_write(vsp1, VI6_DPR_RPF_ROUTE(i), VI6_DPR_NODE_UNUSED);
- for (i = 0; i VPS1_MAX_UDS; ++i)
+ for (i = 0; i vsp1-pdata-uds_count; ++i)
vsp1_write(vsp1, VI6_DPR_UDS_ROUTE(i), VI6_DPR_NODE_UNUSED);
vsp1_write(vsp1, VI6_DPR_SRU_ROUTE, VI6_DPR_NODE_UNUSED);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 01/10] media: Add support for circular graph traversal
The graph traversal API (media_entity_graph_walk_*) doesn't support
cyclic graphs and will fail to correctly walk a graph when circular
links exist. Support circular graph traversal by checking whether an
entity has already been visited before pushing it to the stack.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/media-entity.c | 14 +++---
include/media/media-entity.h | 4
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index cb30ffb..2c286c3 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -20,6 +20,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#include linux/bitmap.h
#include linux/module.h
#include linux/slab.h
#include media/media-entity.h
@@ -121,7 +122,6 @@ static struct media_entity *stack_pop(struct
media_entity_graph *graph)
return entity;
}
-#define stack_peek(en) ((en)-stack[(en)-top - 1].entity)
#define link_top(en) ((en)-stack[(en)-top].link)
#define stack_top(en) ((en)-stack[(en)-top].entity)
@@ -140,6 +140,12 @@ void media_entity_graph_walk_start(struct
media_entity_graph *graph,
{
graph-top = 0;
graph-stack[graph-top].entity = NULL;
+ bitmap_zero(graph-entities, MEDIA_ENTITY_ENUM_MAX_ID);
+
+ if (WARN_ON(entity-id = MEDIA_ENTITY_ENUM_MAX_ID))
+ return;
+
+ __set_bit(entity-id, graph-entities);
stack_push(graph, entity);
}
EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
@@ -180,9 +186,11 @@ media_entity_graph_walk_next(struct media_entity_graph
*graph)
/* Get the entity in the other end of the link . */
next = media_entity_other(entity, link);
+ if (WARN_ON(next-id = MEDIA_ENTITY_ENUM_MAX_ID))
+ return NULL;
- /* Was it the entity we came here from? */
- if (next == stack_peek(graph)) {
+ /* Has the entity already been visited? */
+ if (__test_and_set_bit(next-id, graph-entities)) {
link_top(graph)++;
continue;
}
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index 06bacf9..10df551 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -23,6 +23,7 @@
#ifndef _MEDIA_ENTITY_H
#define _MEDIA_ENTITY_H
+#include linux/bitops.h
#include linux/list.h
#include linux/media.h
@@ -113,12 +114,15 @@ static inline u32 media_entity_subtype(struct
media_entity *entity)
}
#define MEDIA_ENTITY_ENUM_MAX_DEPTH16
+#define MEDIA_ENTITY_ENUM_MAX_ID 64
struct media_entity_graph {
struct {
struct media_entity *entity;
int link;
} stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];
+
+ DECLARE_BITMAP(entities, MEDIA_ENTITY_ENUM_MAX_ID);
int top;
};
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 05/10] v4l: Fix V4L2_MBUS_FMT_YUV10_1X30 media bus pixel code value
The V4L2_MBUS_FMT_YUV10_1X30 code is documented as being equal to 0x2014, while the v4l2-mediabus.h header defines it as 0x2016. Fix the documentation. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index adc6198..0c2b1f2 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2574,7 +2574,7 @@ /row row id=V4L2-MBUS-FMT-YUV10-1X30 entryV4L2_MBUS_FMT_YUV10_1X30/entry - entry0x2014/entry + entry0x2016/entry entry/entry entryysubscript9/subscript/entry entryysubscript8/subscript/entry -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 03/10] media: vb2: Clarify queue_setup() and buf_prepare() usage documentation
Explain how the two operations must handle formats and validate buffer
sizes when used with VIDIOC_CREATE_BUFS.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
include/media/videobuf2-core.h | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index d88a098..6781258 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -219,8 +219,9 @@ struct vb2_buffer {
* configured format and *num_buffers is the total number
* of buffers, that are being allocated. When called from
* VIDIOC_CREATE_BUFS, fmt != NULL and it describes the
- * target frame format. In this case *num_buffers are being
- * allocated additionally to q-num_buffers.
+ * target frame format (if the format isn't valid the
+ * callback must return -EINVAL). In this case *num_buffers
+ * are being allocated additionally to q-num_buffers.
* @wait_prepare: release any locks taken while calling vb2 functions;
* it is called before an ioctl needs to wait for a new
* buffer to arrive; required to avoid a deadlock in
@@ -236,8 +237,10 @@ struct vb2_buffer {
* @buf_prepare: called every time the buffer is queued from userspace
* and from the VIDIOC_PREPARE_BUF ioctl; drivers may
* perform any initialization required before each hardware
- * operation in this callback; if an error is returned, the
- * buffer will not be queued in driver; optional
+ * operation in this callback; drivers that support
+ * VIDIOC_CREATE_BUFS must also validate the buffer size;
+ * if an error is returned, the buffer will not be queued
+ * in driver; optional
* @buf_finish:called before every dequeue of the buffer back
to
* userspace; drivers may perform any operations required
* before userspace accesses the buffer; optional
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 07/10] v4l: Add V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV61M formats
NV16M and NV61M are planar YCbCr 4:2:2 and YCrCb 4:2:2 formats with a
luma plane followed by an interleaved chroma plane. The planes are not
required to be contiguous in memory, and the formats can only be used
with the multi-planar formats API.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
Reviewed-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 171 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 1 +
include/uapi/linux/videodev2.h | 2 +
3 files changed, 174 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..c51d5a4
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,171 @@
+refentry
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16'), V4L2_PIX_FMT_NV61M
('NM61')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname
id=V4L2-PIX-FMT-NV16MconstantV4L2_PIX_FMT_NV16M/constant/refname
+ refname
id=V4L2-PIX-FMT-NV61MconstantV4L2_PIX_FMT_NV61M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant and
constantV4L2_PIX_FMT_NV61/constant with planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:0 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane does not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is chrominance data with alternating chroma samples.
+The CbCr plane is the same width and height, in bytes, as the Y plane.
+Each CbCr pair belongs to four pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Y'subscript00/subscript, Y'subscript01/subscript,
+Y'subscript10/subscript, Y'subscript11/subscript.
+constantV4L2_PIX_FMT_NV61M/constant is the same as
constantV4L2_PIX_FMT_NV16M/constant
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr
byte./para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant and
+constantV4L2_PIX_FMT_NV61M/constant are intended to be used only in drivers
+and applications that support the multi-planar API, described in
+xref linkend=planar-apis/. /para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript02/subscript/entry
+ entryCrsubscript02/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;4:/entry
+
[PATCH v6 06/10] v4l: Add media format codes for ARGB8888 and AYUV8888 on 32-bit busses
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/subdev-formats.xml | 609 + Documentation/DocBook/media_api.tmpl | 6 + include/uapi/linux/v4l2-mediabus.h | 6 +- 3 files changed, 254 insertions(+), 367 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 0c2b1f2..f72c1cc 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -97,31 +97,39 @@ colspec colname=id align=left / colspec colname=code align=center/ colspec colname=bit / - colspec colnum=4 colname=b23 align=center / - colspec colnum=5 colname=b22 align=center / - colspec colnum=6 colname=b21 align=center / - colspec colnum=7 colname=b20 align=center / - colspec colnum=8 colname=b19 align=center / - colspec colnum=9 colname=b18 align=center / - colspec colnum=10 colname=b17 align=center / - colspec colnum=11 colname=b16 align=center / - colspec colnum=12 colname=b15 align=center / - colspec colnum=13 colname=b14 align=center / - colspec colnum=14 colname=b13 align=center / - colspec colnum=15 colname=b12 align=center / - colspec colnum=16 colname=b11 align=center / - colspec colnum=17 colname=b10 align=center / - colspec colnum=18 colname=b09 align=center / - colspec colnum=19 colname=b08 align=center / - colspec colnum=20 colname=b07 align=center / - colspec colnum=21 colname=b06 align=center / - colspec colnum=22 colname=b05 align=center / - colspec colnum=23 colname=b04 align=center / - colspec colnum=24 colname=b03 align=center / - colspec colnum=25 colname=b02 align=center / - colspec colnum=26 colname=b01 align=center / - colspec colnum=27 colname=b00 align=center / - spanspec namest=b23 nameend=b00 spanname=b0 / + colspec colnum=4 colname=b31 align=center / + colspec colnum=5 colname=b20 align=center / + colspec colnum=6 colname=b29 align=center / + colspec colnum=7 colname=b28 align=center / + colspec colnum=8 colname=b27 align=center / + colspec colnum=9 colname=b26 align=center / + colspec colnum=10 colname=b25 align=center / + colspec colnum=11 colname=b24 align=center / + colspec colnum=12 colname=b23 align=center / + colspec colnum=13 colname=b22 align=center / + colspec colnum=14 colname=b21 align=center / + colspec colnum=15 colname=b20 align=center / + colspec colnum=16 colname=b19 align=center / + colspec colnum=17 colname=b18 align=center / + colspec colnum=18 colname=b17 align=center / + colspec colnum=19 colname=b16 align=center / + colspec colnum=20 colname=b15 align=center / + colspec colnum=21 colname=b14 align=center / + colspec colnum=22 colname=b13 align=center / + colspec colnum=23 colname=b12 align=center / + colspec colnum=24 colname=b11 align=center / + colspec colnum=25 colname=b10 align=center / + colspec colnum=26 colname=b09 align=center / + colspec colnum=27 colname=b08 align=center / + colspec colnum=28 colname=b07 align=center / + colspec colnum=29 colname=b06 align=center / + colspec colnum=30 colname=b05 align=center / + colspec colnum=31 colname=b04 align=center / + colspec colnum=32 colname=b03 align=center / + colspec colnum=33 colname=b02 align=center / + colspec colnum=34 colname=b01 align=center / + colspec colnum=35 colname=b00 align=center / + spanspec namest=b31 nameend=b00 spanname=b0 / thead row entryIdentifier/entry @@ -133,6 +141,14 @@ entry/entry entry/entry entryBit/entry + entry31/entry + entry30/entry + entry29/entry + entry28/entry + entry27/entry + entry26/entry + entry25/entry + entry24/entry entry23/entry entry22/entry entry21/entry @@ -164,7 +180,7 @@ entryV4L2_MBUS_FMT_RGB444_2X8_PADHI_BE/entry entry0x1001/entry entry/entry - dash-ent-16; + dash-ent-24; entry0/entry entry0/entry entry0/entry @@ -178,7 +194,7 @@ entry/entry entry/entry entry/entry - dash-ent-16; + dash-ent-24; entrygsubscript3/subscript/entry
[PATCH v6 04/10] media: vb2: Take queue or device lock in vb2_fop_mmap()
The vb2_fop_mmap() function is a plug-in implementation of the mmap()
file operation that calls vb2_mmap() on the queue associated with the
video device. Neither the vb2_fop_mmap() function nor the v4l2_mmap()
mmap handler in the V4L2 core take any lock, leading to race conditions
between mmap() and other buffer-related ioctls such as VIDIOC_REQBUFS.
Fix it by taking the queue or device lock around the vb2_mmap() call.
Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com
---
drivers/media/v4l2-core/videobuf2-core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 9fc4bab..bd4bade 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2578,8 +2578,15 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf);
int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma)
{
struct video_device *vdev = video_devdata(file);
+ struct mutex *lock = vdev-queue-lock ? vdev-queue-lock : vdev-lock;
+ int err;
- return vb2_mmap(vdev-queue, vma);
+ if (lock mutex_lock_interruptible(lock))
+ return -ERESTARTSYS;
+ err = vb2_mmap(vdev-queue, vma);
+ if (lock)
+ mutex_unlock(lock);
+ return err;
}
EXPORT_SYMBOL_GPL(vb2_fop_mmap);
--
1.8.1.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 02/10] Documentation: media: Clarify the VIDIOC_CREATE_BUFS format requirements
The VIDIOC_CREATE_BUFS ioctl takes a format argument that must contain a valid format supported by the driver. Clarify the documentation. Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- .../DocBook/media/v4l/vidioc-create-bufs.xml | 41 ++ 1 file changed, 26 insertions(+), 15 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml index cd99436..9b700a5 100644 --- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml @@ -62,18 +62,29 @@ addition to the constantVIDIOC_REQBUFS/constant ioctl, when a tighter control over buffers is required. This ioctl can be called multiple times to create buffers of different sizes./para -paraTo allocate device buffers applications initialize relevant fields of -the structnamev4l2_create_buffers/structname structure. They set the -structfieldtype/structfield field in the -v4l2-format; structure, embedded in this -structure, to the respective stream or buffer type. -structfieldcount/structfield must be set to the number of required buffers. -structfieldmemory/structfield specifies the required I/O method. The -structfieldformat/structfield field shall typically be filled in using -either the constantVIDIOC_TRY_FMT/constant or -constantVIDIOC_G_FMT/constant ioctl(). Additionally, applications can adjust -structfieldsizeimage/structfield fields to fit their specific needs. The -structfieldreserved/structfield array must be zeroed./para +paraTo allocate the device buffers applications must initialize the +relevant fields of the structnamev4l2_create_buffers/structname structure. +The structfieldcount/structfield field must be set to the number of +requested buffers, the structfieldmemory/structfield field specifies the +requested I/O method and the structfieldreserved/structfield array must be +zeroed./para + +paraThe structfieldformat/structfield field specifies the image format +that the buffers must be able to handle. The application has to fill in this +v4l2-format;. Usually this will be done using the +constantVIDIOC_TRY_FMT/constant or constantVIDIOC_G_FMT/constant ioctl() +to ensure that the requested format is supported by the driver. Unsupported +formats will result in an error./para + +paraThe buffers created by this ioctl will have as minimum size the size +defined by the structfieldformat.pix.sizeimage/structfield field. If the +structfieldformat.pix.sizeimage/structfield field is less than the minimum +required for the given format, then structfieldsizeimage/structfield will be +increased by the driver to that minimum to allocate the buffers. If it is +larger, then the value will be used as-is. The same applies to the +structfieldsizeimage/structfield field of the +structnamev4l2_plane_pix_format/structname structure in the case of +multiplanar formats./para paraWhen the ioctl is called with a pointer to this structure the driver will attempt to allocate up to the requested number of buffers and store the @@ -144,9 +155,9 @@ mapped/link I/O./para varlistentry termerrorcodeEINVAL/errorcode/term listitem - paraThe buffer type (structfieldtype/structfield field) or the -requested I/O method (structfieldmemory/structfield) is not -supported./para + paraThe buffer type (structfieldformat.type/structfield field), +requested I/O method (structfieldmemory/structfield) or format +(structfieldformat/structfield field) is not valid./para /listitem /varlistentry /variablelist -- 1.8.1.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mceusb Fintek ir transmitter only works when X is not running
I have the exact same device and it works fine with 3.10.4 vanilla,
whether X is running out or not. Please can you send the output of
usbmon while issuing irsend (just the interface with the mce device).
Thanks
Sean
Please find attached two traces.
- X.txt from inside an X session where irsend doesnt trigger ir led.
-noX.txt from virtual console with X stopped. irsend triggers the ir led.
Also, i have made sure input for this device is disabled in X.
-
#cat /etc/X11/xorg.conf.d/5-evdev.conf
Section InputClass
Identifier Media Center Ed. eHome Infrared Remote Transceiver
(1934:5168)
MatchProduct Media Center Ed. eHome Infrared Remote
Transceiver (1934:5168)
MatchDevicePath /dev/input/event*
#MatchIsKeyboard on
Option Ignore
#Driver null
EndSection
which leads to
[ 2845.548] (II) config/udev: Adding input device Media Center Ed.
eHome Infrared Remote Transceiver (1934:5168) (/dev/input/event11)
[ 2845.548] (**) Media Center Ed. eHome Infrared Remote Transceiver
(1934:5168): Ignoring device from InputClass Media Center Ed. eHome
Infrared Remote Transceiver (1934:5168)
-
Thanks
Rajil
88012216fb40 2649813401 C Bo:2:005:2 0 28672
880122380a80 2649813421 S Bi:2:005:1 -115 13
880122380a80 2649813474 C Bi:2:005:1 0 13 = 55534253 9077 00
880122380a80 2649813567 S Bo:2:005:2 -115 31 = 55534243 9177 0010
0a2a 93cc 4008 00
880122380a80 2649813597 C Bo:2:005:2 0 31
88012216b000 2649813613 S Bo:2:005:2 -115 4096 = c03b3998 0002 0001a2c2
88012216b000 2649813847 C Bo:2:005:2 0 4096
880122380a80 2649813865 S Bi:2:005:1 -115 13
880122380a80 2649813970 C Bi:2:005:1 0 13 = 55534253 9177 00
88012216b540 2651999787 S Io:2:008:1 -115:1 3 = 9f0802
88012216b540 2652000419 C Io:2:008:1 0:1 3
88012216b0c0 2652010210 S Io:2:008:1 -115:1 86 = 84ffb458 8b840a8b 0a8b8420
8b0a8b84 0a8b0a8b 840a8b0a 8b84208b 208b840a
88012216b0c0 2652034421 C Io:2:008:1 0:1 86
88012216b0c0 2655068437 S Io:2:008:1 -115:1 3 = 9f0802
880122380a80 2655068524 S Bo:2:005:2 -115 31 = 55534243 9277 0010
0a2a f44b 2008 00
880122380a80 2655068601 C Bo:2:005:2 0 31
88012216fcc0 2655068609 S Bo:2:005:2 -115 4096 = 38383031 32323136
66623430 20323634 39383133 34303120 4320426f
88012216fcc0 2655068851 C Bo:2:005:2 0 4096
880122380a80 2655068866 S Bi:2:005:1 -115 13
880122380a80 2655068978 C Bi:2:005:1 0 13 = 55534253 9277 00
880122380a80 2655069019 S Bo:2:005:2 -115 31 = 55534243 9377 0010
0a2a 6490 c008 00
880122380a80 2655069101 C Bo:2:005:2 0 31
88012216fb40 2655069115 S Bo:2:005:2 -115 4096 = 7375646f 3a617574 68293a20
61757468 20636f75 6c64206e 6f742069 64656e74
88012216fb40 2655069350 C Bo:2:005:2 0 4096
88012216b0c0 2655069354 C Io:2:008:1 0:1 3
880122380a80 2655069374 S Bi:2:005:1 -115 13
880122380a80 2655069476 C Bi:2:005:1 0 13 = 55534253 9377 00
880122380a80 2655069520 S Bo:2:005:2 -115 31 = 55534243 9477 0010
0a2a f44b 2008 00
880122380a80 2655069602 C Bo:2:005:2 0 31
880126bd03c0 2655069618 S Bo:2:005:2 -115 4096 = 38383031 32323136
66623430 20323634 39383133 34303120 4320426f
880126bd03c0 2655069851 C Bo:2:005:2 0 4096
880122380a80 2655069864 S Bi:2:005:1 -115 13
880122380a80 2655069975 C Bi:2:005:1 0 13 = 55534253 9477 00
880122380a80 2655077261 S Bo:2:005:2 -115 31 = 55534243 9577 0010
0a2a 6490 c008 00
880122380a80 2655077399 C Bo:2:005:2 0 31
880126bd0c00 2655077419 S Bo:2:005:2 -115 4096 = 7375646f 3a617574 68293a20
61757468 20636f75 6c64206e 6f742069 64656e74
88012216bcc0 2655079154 S Io:2:008:1 -115:1 86 = 84ffb458 8b840a8b 0a8b8420
8b0a8b84 0a8b0a8b 840a8b0a 8b84208b 208b840a
88012216bcc0 2655103412 C Io:2:008:1 0:1 86
880126bd0c00 2655132779 C Bo:2:005:2 0 4096
880122380a80 2655132797 S Bi:2:005:1 -115 13
880122380a80 2655132905 C Bi:2:005:1 0 13 = 55534253 9577 00
880122380a80 2655132930 S Bo:2:005:2 -115 31 = 55534243 9677 0050
0a2a 93cc 4828 00
880122380a80 2655132986 C Bo:2:005:2 0 31
880126bd0c00 2655132995 S Bo:2:005:2 -115 20480 = c03b3998 0001
0001a2c3 001e
880126bd0c00 2655133790 C Bo:2:005:2 0 20480
880122380a80 2655133813 S Bi:2:005:1 -115 13
880122380a80 2655133851 C Bi:2:005:1 0 13 = 55534253 9677 00
880122380a80 2655133925 S Bo:2:005:2 -115 31 = 55534243 9777 0010
0a2a 93cc 7008 00
880122380a80 2655133997 C Bo:2:005:2 0 31
88012216bd80
Re: [RFC 0/1] drm/pl111: Initial drm/kms driver for pl111
On Mon, Aug 5, 2013 at 1:10 PM, Tom Cooksey tom.cook...@arm.com wrote: Hi Rob, +linux-media, +linaro-mm-sig for discussion of video/camera buffer constraints... On Fri, Jul 26, 2013 at 11:58 AM, Tom Cooksey tom.cook...@arm.com wrote: * It abuses flags parameter of DRM_IOCTL_MODE_CREATE_DUMB to also allocate buffers for the GPU. Still not sure how to resolve this as we don't use DRM for our GPU driver. any thoughts/plans about a DRM GPU driver? Ideally long term (esp. once the dma-fence stuff is in place), we'd have gpu-specific drm (gpu-only, no kms) driver, and SoC/display specific drm/kms driver, using prime/dmabuf to share between the two. The extra buffers we were allocating from armsoc DDX were really being allocated through DRM/GEM so we could get an flink name for them and pass a reference to them back to our GPU driver on the client side. If it weren't for our need to access those extra off-screen buffers with the GPU we wouldn't need to allocate them with DRM at all. So, given they are really GPU buffers, it does absolutely make sense to allocate them in a different driver to the display driver. However, to avoid unnecessary memcpys related cache maintenance ops, we'd also like the GPU to render into buffers which are scanned out by the display controller. So let's say we continue using DRM_IOCTL_MODE_CREATE_DUMB to allocate scan out buffers with the display's DRM driver but a custom ioctl on the GPU's DRM driver to allocate non scanout, off-screen buffers. Sounds great, but I don't think that really works with DRI2. If we used two drivers to allocate buffers, which of those drivers do we return in DRI2ConnectReply? Even if we solve that somehow, GEM flink names are name-spaced to a single device node (AFAIK). So when we do a DRI2GetBuffers, how does the EGL in the client know which DRM device owns GEM flink name 1234? We'd need some pretty dirty hacks. You would return the name of the display driver allocating the buffers. On the client side you can use generic ioctls to go from flink - handle - dmabuf. So the client side would end up opening both the display drm device and the gpu, but without needing to know too much about the display. I think the bit I was missing was that a GEM bo for a buffer imported using dma_buf/PRIME can still be flink'd. So the display controller's DRM driver allocates scan-out buffers via the DUMB buffer allocate ioctl. Those scan-out buffers than then be exported from the dispaly's DRM driver and imported into the GPU's DRM driver using PRIME. Once imported into the GPU's driver, we can use flink to get a name for that buffer within the GPU DRM driver's name-space to return to the DRI2 client. That same namespace is also what DRI2 back-buffers are allocated from, so I think that could work... Except... (and.. the general direction is that things will move more to just use dmabuf directly, ie. wayland or dri3) Anyway, that latter case also gets quite difficult. The GPU DRM driver would need to know the constraints of the display controller when allocating buffers intended to be scanned out. For example, pl111 typically isn't behind an IOMMU and so requires physically contiguous memory. We'd have to teach the GPU's DRM driver about the constraints of the display HW. Not exactly a clean driver model. :-( I'm still a little stuck on how to proceed, so any ideas would greatly appreciated! My current train of thought is having a kind of SoC-specific DRM driver which allocates buffers for both display and GPU within a single GEM namespace. That SoC-specific DRM driver could then know the constraints of both the GPU and the display HW. We could then use PRIME to export buffers allocated with the SoC DRM driver and import them into the GPU and/or display DRM driver. Usually if the display drm driver is allocating the buffers that might be scanned out, it just needs to have minimal knowledge of the GPU (pitch alignment constraints). I don't think we need a 3rd device just to allocate buffers. While Mali can render to pretty much any buffer, there is a mild performance improvement to be had if the buffer stride is aligned to the AXI bus's max burst length when drawing to the buffer. I suspect the display controllers might frequently benefit if the pitch is aligned to AXI burst length too.. So in some respects, there is a constraint on how buffers which will be drawn to using the GPU are allocated. I don't really like the idea of teaching the display controller DRM driver about the GPU buffer constraints, even if they are fairly trivial like this. If the same display HW IP is being used on several SoCs, it seems wrong somehow to enforce those GPU constraints if some of those SoCs don't have a GPU. Well, I suppose you could get min_pitch_alignment from devicetree, or something like this.. In the end, the easy solution is just
Re: dib8000 scanning not working on 3.10.3
Hi Mauro, I have tested using dvb5-scan, and the results are the same (no results, and no error logs) :( Do you have any clue why it is not working with this kernel version ? Thanks and regards... On Thu, Aug 1, 2013 at 2:15 PM, Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Thu, 1 Aug 2013 13:36:25 -0300 Ezequiel Garcia ezequiel.gar...@free-electrons.com escreveu: Hi Luis, (I'm Ccing Mauro, who mantains this driver and might know what's going on). On Wed, Jul 31, 2013 at 03:47:10PM -0300, Luis Polasek wrote: Hi, I just upgraded my kernel to 3.10.3, and dib8000 scanning does not work anymore. I tested using dvbscan (from dvb-apps/util/) and w_scan on a Prolink Pixelview SBTVD (dib8000 module*).This tools worked very well on version 3.9.9 , but now it does not produces any result, and also there are no error messages in the logs (dmesg). Please run a git bisect and report your findings. Note that dibcom8000 shows just a handful of commit on 2013, so you could start reverting those and see what happens. Perhaps it is a failure at the DVBv3 emulation. Did it also break using dvbv5-scan (part of v4l-utils)? Regards, Mauro -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL for v3.11-rc5] media fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for some drivers fixes (em28xx, coda, usbtv, s5p, hdpvr and ml86v7667) and at a fix for media DocBook. Thanks! Mauro - The following changes since commit 1b2c14b44adcb7836528640bfdc40bf7499d987d: -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] gspca: fix dev_open() error path
If v4l2_fh_open() fails in dev_open(), gspca_dev-module left locked.
The patch adds module_put(gspca_dev-module) on this path.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/usb/gspca/gspca.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/gspca/gspca.c b/drivers/media/usb/gspca/gspca.c
index b7ae872..048507b 100644
--- a/drivers/media/usb/gspca/gspca.c
+++ b/drivers/media/usb/gspca/gspca.c
@@ -1266,6 +1266,7 @@ static void gspca_release(struct v4l2_device *v4l2_device)
static int dev_open(struct file *file)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
+ int ret;
PDEBUG(D_STREAM, [%s] open, current-comm);
@@ -1273,7 +1274,10 @@ static int dev_open(struct file *file)
if (!try_module_get(gspca_dev-module))
return -ENODEV;
- return v4l2_fh_open(file);
+ ret = v4l2_fh_open(file);
+ if (ret)
+ module_put(gspca_dev-module);
+ return ret;
}
static int dev_close(struct file *file)
--
1.8.1.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
Re: dib8000 scanning not working on 3.10.3
Em Mon, 05 Aug 2013 16:09:56 -0300 Luis Polasek lpola...@gmail.com escreveu: Hi Mauro, I have tested using dvb5-scan, and the results are the same (no results, and no error logs) :( Do you have any clue why it is not working with this kernel version ? c/c Oliver and Patrick, who maintains this driver There were a recent change on this driver, in order to support some newer versions of this chipset. Perhaps those changes broke it for you. commit 59501bb792c66b85fb7fdbd740e788e3afc70bbd Author: Olivier Grenie olivier.gre...@parrot.com Date: Mon Dec 31 09:51:17 2012 -0300 [media] dib7090p: improve the support of the dib7090 and dib7790 The intend of this patch is to improve the support of the dib7090 and dib7790. The AGC1 min value is set to 32768 by default. The actual AGC1 min and the external attenuation are controled depending on the received RF level. Signed-off-by: Olivier Grenie olivier.gre...@parrot.com Signed-off-by: Patrick Boettcher patrick.boettc...@parrot.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com commit f45f513a9325b52a5f3e26ee8d15471e8b692947 Author: Olivier Grenie olivier.gre...@parrot.com Date: Mon Dec 31 09:47:10 2012 -0300 [media] dib7090p: remove the support for the dib7090E The intend of this patch is to remove the support for the dib7090E. The DiB7090E-package has never left prototype state and never made it to mass-prod-state. Signed-off-by: Olivier Grenie olivier.gre...@parrot.com Signed-off-by: Patrick Boettcher patrick.boettc...@parrot.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Could you please revert those patches and see if they fix the issue? Please try to revert this one first: http://git.linuxtv.org/media_tree.git/commitdiff_plain/59501bb792c66b85fb7fdbd740e788e3afc70bbd If this doesn't solve, try to revert just this one: http://git.linuxtv.org/media_tree.git/commitdiff_plain/f45f513a9325b52a5f3e26ee8d15471e8b692947 then, try to revert both. AFAIKT, those are the only changes that may be affecting isdb-t on dib8000 driver. Thanks! Mauro Thanks and regards... On Thu, Aug 1, 2013 at 2:15 PM, Mauro Carvalho Chehab m.che...@samsung.comwrote: Em Thu, 1 Aug 2013 13:36:25 -0300 Ezequiel Garcia ezequiel.gar...@free-electrons.com escreveu: Hi Luis, (I'm Ccing Mauro, who mantains this driver and might know what's going on). On Wed, Jul 31, 2013 at 03:47:10PM -0300, Luis Polasek wrote: Hi, I just upgraded my kernel to 3.10.3, and dib8000 scanning does not work anymore. I tested using dvbscan (from dvb-apps/util/) and w_scan on a Prolink Pixelview SBTVD (dib8000 module*).This tools worked very well on version 3.9.9 , but now it does not produces any result, and also there are no error messages in the logs (dmesg). Please run a git bisect and report your findings. Note that dibcom8000 shows just a handful of commit on 2013, so you could start reverting those and see what happens. Perhaps it is a failure at the DVBv3 emulation. Did it also break using dvbv5-scan (part of v4l-utils)? Regards, Mauro -- Cheers, Mauro -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mceusb Fintek ir transmitter only works when X is not running
On Mon, Aug 05, 2013 at 07:17:10PM +0100, Rajil Saraswat wrote: Please find attached two traces. - X.txt from inside an X session where irsend doesnt trigger ir led. -noX.txt from virtual console with X stopped. irsend triggers the ir led. Also, i have made sure input for this device is disabled in X. - #cat /etc/X11/xorg.conf.d/5-evdev.conf Section InputClass Identifier Media Center Ed. eHome Infrared Remote Transceiver (1934:5168) MatchProduct Media Center Ed. eHome Infrared Remote Transceiver (1934:5168) MatchDevicePath /dev/input/event* #MatchIsKeyboard on Option Ignore #Driver null EndSection which leads to [ 2845.548] (II) config/udev: Adding input device Media Center Ed. eHome Infrared Remote Transceiver (1934:5168) (/dev/input/event11) [ 2845.548] (**) Media Center Ed. eHome Infrared Remote Transceiver (1934:5168): Ignoring device from InputClass Media Center Ed. eHome Infrared Remote Transceiver (1934:5168) - Why are you doing this? -snip- X case where it does not work: 880118d1f240 2548275209 S Io:2:008:1 -115:1 3 = 9f0802 880118d1f240 2548275281 E Io:2:008:1 -28 0 880118d1fb40 2548286204 S Io:2:008:1 -115:1 86 = 84ffb458 8b840a8b 0a8b8420 8b0a8b84 0a8b0a8b 840a8b0a 8b84208b 208b840a 880118d1fb40 2548286310 E Io:2:008:1 -28 0 All the urb submissions result in an error -28: ENOSPC. These errors aren't logged by default. I'm not sure about why this would happen. According to Documentation/usb/error-codes.txt: -ENOSPC This request would overcommit the usb bandwidth reserved for periodic transfers (interrupt, isochronous). Could you try putting the device on its own bus (i.e root hub which does not share bus with another device, see lsusb output). If that does not work, could you capture the usbmon output while starting X and then irsend, to see if your X config somehow affects it. Sean -- 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
Syntek webcams and out-of-tree driver
Hello,
the in-kernel stkwebcam driver (by Jaime Velasco Juan and Nicolas VIVIEN)
supports only two webcam types (USB IDs 0x174f:0xa311 and 0x05e1:0x0501).
There are many other Syntek webcam types that are not supported by this
driver (such as 0x174f:0x6a31 in Asus F5RL laptop).
There is an out-of-tree GPL driver called stk11xx (by Martin Roos and also
Nicolas VIVIEN) at http://sourceforge.net/projects/syntekdriver/ which
supports more webcams. It can be even compiled for the latest kernels using
the patch below and seems to work somehow (slow and buggy but better than
nothing) with the Asus F5RL.
Is there any possibility that this driver could be merged into the kernel?
The code could probably be simplified a lot and integrated into gspca.
diff -urp syntekdriver-code-107-trunk-orig/driver/stk11xx.h
syntekdriver-code-107-trunk//driver/stk11xx.h
--- syntekdriver-code-107-trunk-orig/driver/stk11xx.h 2012-03-10
10:03:12.0 +0100
+++ syntekdriver-code-107-trunk//driver/stk11xx.h 2013-08-05
22:50:00.0 +0200
@@ -33,6 +33,7 @@
#ifndef STK11XX_H
#define STK11XX_H
+#include media/v4l2-device.h
#define DRIVER_NAMEstk11xx
/** Name of this driver */
#define DRIVER_VERSION v3.0.0
/** Version of this driver */
@@ -316,6 +317,7 @@ struct stk11xx_video {
* @struct usb_stk11xx
*/
struct usb_stk11xx {
+ struct v4l2_device v4l2_dev;
struct video_device *vdev; /** Pointer on a V4L2
video device */
struct usb_device *udev;/** Pointer on a USB
device */
struct usb_interface *interface;/** Pointer on a USB interface
*/
diff -urp syntekdriver-code-107-trunk-orig/driver/stk11xx-v4l.c
syntekdriver-code-107-trunk//driver/stk11xx-v4l.c
--- syntekdriver-code-107-trunk-orig/driver/stk11xx-v4l.c 2012-03-10
09:54:57.0 +0100
+++ syntekdriver-code-107-trunk//driver/stk11xx-v4l.c 2013-08-05
22:51:12.0 +0200
@@ -1498,9 +1498,17 @@ int v4l_stk11xx_register_video_device(st
{
int err;
+ err = v4l2_device_register(dev-interface-dev, dev-v4l2_dev);
+ if (err 0) {
+ STK_ERROR(couldn't register v4l2_device\n);
+ kfree(dev);
+ return err;
+ }
+
strcpy(dev-vdev-name, DRIVER_DESC);
- dev-vdev-parent = dev-interface-dev;
+// dev-vdev-parent = dev-interface-dev;
+ dev-vdev-v4l2_dev = dev-v4l2_dev;
dev-vdev-fops = v4l_stk11xx_fops;
dev-vdev-release = video_device_release;
dev-vdev-minor = -1;
@@ -1533,6 +1541,7 @@ int v4l_stk11xx_unregister_video_device(
video_set_drvdata(dev-vdev, NULL);
video_unregister_device(dev-vdev);
+ v4l2_device_unregister(dev-v4l2_dev);
return 0;
}
--
Ondrej Zary
--
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
Vážení E-mail užívateľa;
Vážení E-mail užívateľa; Prekročili ste 23432 boxy nastaviť svoje Webová služba / Administrátor, a budete mať problémy pri odosielaní a prijímať e-maily, kým znova overiť. Musíte aktualizovať kliknutím na odkaz nižšie a vyplňte údaje pre overenie vášho účtu Prosím, kliknite na odkaz nižšie alebo skopírovať vložiť do e-prehliadač pre overenie Schránky. http://webmailupdate203242.jimdo.com/ Pozor! Ak tak neurobíte, budú mať obmedzený prístup k e-mailu schránky. Ak sa nepodarí aktualizovať svoj #8203;#8203;účet do troch dní od aktualizácie oznámenia, bude váš účet natrvalo uzavretá. S pozdravom, System Administrator #174; -- 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 v3 02/13] [media] exynos5-fimc-is: Add Exynos5 FIMC-IS device tree bindings documentation
On 08/05/2013 06:53 PM, Stephen Warren wrote: On 08/03/2013 03:41 PM, Sylwester Nawrocki wrote: On 08/02/2013 05:02 PM, Arun Kumar K wrote: The patch adds the DT binding documentation for Samsung Exynos5 SoC series imaging subsystem (FIMC-IS). diff --git a/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt new file mode 100644 index 000..49a373a --- /dev/null +++ b/Documentation/devicetree/bindings/media/exynos5-fimc-is.txt @@ -0,0 +1,52 @@ +Samsung EXYNOS5 SoC series Imaging Subsystem (FIMC-IS) +-- + +The camera subsystem on Samsung Exynos5 SoC has some changes relative +to previous SoC versions. Exynos5 has almost similar MIPI-CSIS and +FIMC-LITE IPs but has a much improved version of FIMC-IS which can +handle sensor controls and camera post-processing operations. The +Exynos5 FIMC-IS has a dedicated ARM Cortex A5 processor, many +post-processing blocks (ISP, DRC, FD, ODC, DIS, 3DNR) and two +dedicated scalers (SCC and SCP). So there are a lot of blocks mentioned there, yet the binding doesn't seem to describe most of it. Is the binding complete? Thanks for the review Stephen. No, the binding certainly isn't complete, it doesn't describe the all available IP blocks. There are separate MMIO address regions for each block for the main CPUs and for the Cortex-A5 which is supposed to run firmware that controls the whole subsystem. So in theory all those IP blocks should be listed as device tree nodes, with at least their compatible, reg and interrupts properties. However due to most of the sub-devices being controlled by the firmware the current Linux driver for this whole FIMC-IS subsystem doesn't need to now exact details of each internal data processing block. The is a mailbox interface used for communication between host CPU and the FIMC-IS CPU. So while we could list all the devices, we decided not to do so. Because it is not needed by the current software and we may miss some details for case where the whole subsystem is controlled by the host CPU (however such scenario is extremely unlikely AFAICT) which then would be impossible or hard to change. I guess we should list all available devices, similarly as it's done in Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt. And then should they just be disabled through the status property if they are not needed in the Linux driver ? I guess it is more sensible than marking them as optional and then not listing them in dts at all ? +pmu subnode +--- + +Required properties: + - reg : should contain PMU physical base address and size of the memory + mapped registers. I think you need a compatible value for this. How else is the node identified? The node name probably should not be used for identification. Of course the node name is currently used for identification. There is no compatible property because this pmu node is used to get hold of only part of the Power Management Unit registers, specific to the FIMC-IS. The PMU has more registers that also other drivers would be interested in, e.g. clocks or USB. I have been considering exposing the PMU registers through a syscon-like interface and having a phandle pointing to it in the relevant device nodes. Adding compatible property might not be a good approach. It would have been hard to map this to a separate device described in the SoC's datasheet. Registers specific to the FIMC-IS are not contiguous in the PMU MMIO region. + +i2c-isp (ISP I2C bus controller) nodes +-- + +Required properties: + +- compatible: should be samsung,exynos4212-i2c-isp for Exynos4212, + Exynos4412 and Exynos5250 SoCs; +- reg: physical base address and length of the registers set; +- clocks: must contain gate clock specifier for this controller; +- clock-names: must contain i2c_isp entry. + +For the above nodes it is required to specify a pinctrl state named default, Is above nodes both pmu, i2c-isp? It might make sense to be more explicit re: which nodes this comment applies to. Yeah, certainly there is room for improvement here. above nodes was supposed to refer to the i2c-isp nodes only, it should be said more precisely. +according to the pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt. -- 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 v3 04/13] [media] exynos5-fimc-is: Add common driver header files
Hi Sylwester,
On Sun, Aug 4, 2013 at 3:13 AM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
On 08/02/2013 05:02 PM, Arun Kumar K wrote:
This patch adds all the common header files used by the fimc-is
driver. It includes the commands for interfacing with the firmware
and error codes from IS firmware, metadata and command parameter
definitions.
Signed-off-by: Arun Kumar Karun...@samsung.com
Signed-off-by: Kilyeon Imkilyeon...@samsung.com
---
drivers/media/platform/exynos5-is/fimc-is-cmd.h| 187 +++
drivers/media/platform/exynos5-is/fimc-is-err.h| 257 +
.../media/platform/exynos5-is/fimc-is-metadata.h | 767 +
drivers/media/platform/exynos5-is/fimc-is-param.h | 1212
4 files changed, 2423 insertions(+)
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-cmd.h
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-err.h
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-metadata.h
create mode 100644 drivers/media/platform/exynos5-is/fimc-is-param.h
[snip]
+
+struct camera2_tonemap_dm {
+ enum tonemap_mode mode;
+ /* assuming maxCurvePoints = 64 */
+ float curve_red[64];
+ float curve_green[64];
+ float curve_blue[64];
So all those floating point numbers are now not really used in
the driver but we need them for proper data structures/offsets
declarations of the firmware interface ?
Yes. Same floats are used in firmware internal data structures
also and the driver should assign these values when these parameters
are to be changed.
+};
+
[snip]
+/* -- Effect
--- */
+enum isp_imageeffect_command {
+ ISP_IMAGE_EFFECT_DISABLE= 0,
+ ISP_IMAGE_EFFECT_MONOCHROME = 1,
+ ISP_IMAGE_EFFECT_NEGATIVE_MONO = 2,
+ ISP_IMAGE_EFFECT_NEGATIVE_COLOR = 3,
+ ISP_IMAGE_EFFECT_SEPIA = 4,
+ ISP_IMAGE_EFFECT_AQUA = 5,
+ ISP_IMAGE_EFFECT_EMBOSS = 6,
+ ISP_IMAGE_EFFECT_EMBOSS_MONO= 7,
+ ISP_IMAGE_EFFECT_SKETCH = 8,
+ ISP_IMAGE_EFFECT_RED_YELLOW_POINT = 9,
+ ISP_IMAGE_EFFECT_GREEN_POINT= 10,
+ ISP_IMAGE_EFFECT_BLUE_POINT = 11,
+ ISP_IMAGE_EFFECT_MAGENTA_POINT = 12,
+ ISP_IMAGE_EFFECT_WARM_VINTAGE = 13,
+ ISP_IMAGE_EFFECT_COLD_VINTAGE = 14,
+ ISP_IMAGE_EFFECT_POSTERIZE = 15,
+ ISP_IMAGE_EFFECT_SOLARIZE = 16,
+ ISP_IMAGE_EFFECT_WASHED = 17,
+ ISP_IMAGE_EFFECT_CCM= 18,
+};
Hmm, I guess we will need a private v4l2 control for those.
Yes. I am planning to add the controls after the basic support
gets merged.
Regards
Arun
--
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 v3] drm/exynos: Add fallback option to get non physically continous memory for fb
While trying to get boot-logo up on exynos5420 SMDK which has eDP panel
connected with resolution 2560x1600, following error occured even with
IOMMU enabled:
[0.88] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate buffer.
[0.89] [drm] Initialized exynos 1.0.0 20110530 on minor 0
To address the cases where physically continous memory MAY NOT be a
mandatory requirement for fb, the patch adds a feature to get non physically
continous memory for fb if IOMMU is supported and if CONTIG memory allocation
fails.
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
Signed-off-by: Arun Kumar arun...@samsung.com
Reviewed-by: Rob Clark robdcl...@gmail.com
---
changes since v2:
- addressed comments given by Tomasz Figa tomasz.f...@gmail.com.
changes since v1:
- Modified to add the fallback patch if CONTIG alloc fails as suggested
by Rob Clark robdcl...@gmail.com and Tomasz Figa
tomasz.f...@gmail.com.
- changed the commit message.
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 8e60bd6..faec77e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -16,6 +16,7 @@
#include drm/drm_crtc.h
#include drm/drm_fb_helper.h
#include drm/drm_crtc_helper.h
+#include drm/exynos_drm.h
#include exynos_drm_drv.h
#include exynos_drm_fb.h
@@ -165,8 +166,17 @@ static int exynos_drm_fbdev_create(struct drm_fb_helper
*helper,
size = mode_cmd.pitches[0] * mode_cmd.height;
- /* 0 means to allocate physically continuous memory */
- exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);
+ exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG, size);
+ /*
+* If IOMMU is supported then try to get buffer from non physically
+* continous memory area.
+*/
+ if (IS_ERR(exynos_gem_obj) is_drm_iommu_supported(dev)) {
+ dev_warn(pdev-dev, contiguous FB allocation failed, falling
back to non-contiguous\n);
+ exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_NONCONTIG,
+ size);
+ }
+
if (IS_ERR(exynos_gem_obj)) {
ret = PTR_ERR(exynos_gem_obj);
goto err_release_framebuffer;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
