[no subject]
tomi.valkei...@ti.com, pza Bcc: Subject: Re: [PATCH 1/2 v6] of: add helper to parse display timings Reply-To: In-Reply-To: Pine.LNX.4.64.1210042307300.3744@axis700.grange X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-IRC: #ptxdist @freenode X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-Uptime: 09:13:09 up 103 days, 22:24, 36 users, load average: 0,57, 0,60, 0,61 On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote: +optional properties: + - hsync-active-high (bool): Hsync pulse is active high + - vsync-active-high (bool): Vsync pulse is active high For the above two we also considered using bool properties but eventually settled down with integer ones: - hsync-active = 1 for active-high and 0 for active low. This has the added advantage of being able to omit this property in the .dts, which then doesn't mean, that the polarity is active low, but rather, that the hsync line is not used on this hardware. So, maybe it would be good to use the same binding here too? Philipp, this is the same argumentation as we discussed yesterday for the dual-link LVDS option, so that one could be modelled in a similar way. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote: +optional properties: + - hsync-active-high (bool): Hsync pulse is active high + - vsync-active-high (bool): Vsync pulse is active high For the above two we also considered using bool properties but eventually settled down with integer ones: - hsync-active = 1 for active-high and 0 for active low. This has the added advantage of being able to omit this property in the .dts, which then doesn't mean, that the polarity is active low, but rather, that the hsync line is not used on this hardware. So, maybe it would be good to use the same binding here too? Philipp, this is the same argumentation as we discussed yesterday for the dual-link LVDS option, so that one could be modelled in a similar way. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data
Hi Mauro,
If you don't mind can we merge this patch at drm tree? the remainig
patches will be merged by Tomasz S.
To Marek Tomasz,
Can you give your acks?
Thank you,
Kyungmin Park
On 10/4/12, Inki Dae inki@samsung.com wrote:
Hello Media guys,
This is dependent of exynos drm patch set to be merged to mainline so if
there is no problem then please, give me ack so that I can merge this patch
with exynos drm patch set.
Thanks,
Inki Dae
-Original Message-
From: RAHUL SHARMA [mailto:rahul.sha...@samsung.com]
Sent: Thursday, October 04, 2012 4:40 PM
To: Tomasz Stanislawski; Kyungmin Park; linux-arm-
ker...@lists.infradead.org; linux-media@vger.kernel.org
Cc: In-Ki Dae; SUNIL JOSHI; r.sh.o...@gmail.com
Subject: Re: [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform
data
Hi Mr. Tomasz, Mr. Park, list,
First patch in the following set belongs to s5p-media, rest to
exynos-drm.
Please review the media patch so that It can be merged for mainline.
regards,
Rahul Sharma
On Thu, Oct 4, 2012 at 9:12 PM, Rahul Sharma rahul.sha...@samsung.com
wrote:
From: Tomasz Stanislawski t.stanisl...@samsung.com
This patch extends s5p-hdmi platform data by a GPIO identifier for
Hot-Plug-Detection pin.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/media/s5p_hdmi.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 361a751..181642b 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -20,6 +20,7 @@ struct i2c_board_info;
* @hdmiphy_info: template for HDMIPHY I2C device
* @mhl_bus: controller id for MHL control bus
* @mhl_info: template for MHL I2C device
+ * @hpd_gpio: GPIO for Hot-Plug-Detect pin
*
* NULL pointer for *_info fields indicates that
* the corresponding chip is not present
@@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
struct i2c_board_info *hdmiphy_info;
int mhl_bus;
struct i2c_board_info *mhl_info;
+ int hpd_gpio;
};
#endif /* S5P_HDMI_H */
--
1.7.0.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv9 02/25] Documentation: media: description of DMABUF importing in V4L2
Hi Tomasz,
Just a few more stylistic issues...
On Tue October 2 2012 16:27:13 Tomasz Stanislawski wrote:
This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: linux-...@vger.kernel.org
---
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 180
+++-
.../DocBook/media/v4l/vidioc-create-bufs.xml | 16 +-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 17 ++
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 ++---
5 files changed, 234 insertions(+), 30 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/compat.xml
b/Documentation/DocBook/media/v4l/compat.xml
index faa0fd1..a46f95b 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2621,6 +2621,10 @@ ioctls./para
listitem
paraSupport for frequency band enumeration:
VIDIOC-ENUM-FREQ-BANDS; ioctl./para
/listitem
+listitem
+ paraImporting DMABUF file descriptors as a new IO method described
+ in xref linkend=dmabuf /./para
+/listitem
/itemizedlist
/section
diff --git a/Documentation/DocBook/media/v4l/io.xml
b/Documentation/DocBook/media/v4l/io.xml
index 1885cc0..5b58657 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By
default
outgoing queue. When the constantO_NONBLOCK/constant flag was
given to the func-open; function, constantVIDIOC_DQBUF/constant
returns immediately with an EAGAIN; when no buffer is available. The
-func-select; or func-poll; function are always available./para
+func-select; or func-poll; functions are always available./para
paraTo start and stop capturing or output applications call the
VIDIOC-STREAMON; and VIDIOC-STREAMOFF; ioctl. Note
@@ -472,6 +472,161 @@ rest should be evident./para
/footnote/para
/section
+ section id=dmabuf
+titleStreaming I/O (DMA buffer importing)/title
+
+note
+ titleExperimental/title
+ paraThis is an link linkend=experimental experimental /link
+ interface and may change in the future./para
+/note
+
+paraThe DMABUF framework provides a generic method for sharing buffers
+between multiple devices. Device drivers that support DMABUF can export a DMA
+buffer to userspace as a file descriptor (known as the exporter role),
import a
+DMA buffer from userspace using a file descriptor previously exported for a
+different or the same device (known as the importer role), or both. This
+section describes the DMABUF importer role API in V4L2./para
+
+paraInput and output devices support the streaming I/O method when the
+constantV4L2_CAP_STREAMING/constant flag in the
+structfieldcapabilities/structfield field of v4l2-capability; returned
by
+the VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
+DMABUF file descriptors is supported is determined by calling the
+VIDIOC-REQBUFS; ioctl with the memory type set to
+constantV4L2_MEMORY_DMABUF/constant./para
+
+paraThis I/O method is dedicated for sharing DMA buffers between V4L
and
+other APIs.
It's more accurate to say something along the lines of: ...is dedicated to
sharing
DMA buffers between different devices, which may be V4L devices or other
video-related devices (e.g. DRM).
One of the uses of this API is to share buffers between different V4L devices,
so
that's a bit more generic than the original sentence suggests.
Buffers (planes) are allocated by a driver on behalf of an
+application. Next, these buffers are exported to the application as file
+descriptors using an API which is specific for an allocator driver. Only
such
+file descriptor are exchanged. The descriptors and meta-information are
passed
+in v4l2-buffer; (or in v4l2-plane; in the multi-planar API case). The
driver
+must be switched into DMABUF I/O mode by calling the VIDIOC-REQBUFS; with
the
+desired buffer type./para
+
+example
+ titleInitiating streaming I/O with DMABUF file descriptors/title
+
+ programlisting
+v4l2-requestbuffers; reqbuf;
+
+memset (amp;reqbuf, 0, sizeof (reqbuf));
no space after memset
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+reqbuf.memory = V4L2_MEMORY_DMABUF;
+reqbuf.count = 1;
+
+if (ioctl (fd, VIDIOC-REQBUFS;, amp;reqbuf) == -1) {
no space after ioctl
+ if (errno == EINVAL)
+ printf(Video capturing or DMABUF streaming is not
supported\n);
+ else
+ perror(VIDIOC_REQBUFS);
+
+ exit(EXIT_FAILURE);
+}
+ /programlisting
+/example
+
+paraThe buffer (plane) file descriptor is passed on the fly with
Re: [PATCHv9 03/25] v4l: vb2: add support for shared buffer (dma_buf)
Just a small heads-up for an upcoming change...
On Tue October 2 2012 16:27:14 Tomasz Stanislawski wrote:
From: Sumit Semwal sumit.sem...@ti.com
This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.
For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A sample allocator
of
dma-buf shared buffer is given at [1]]
[1]: Rob Clark's DRM:
https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/Kconfig |1 +
drivers/media/video/videobuf2-core.c | 207
+-
include/media/videobuf2-core.h | 27 +
3 files changed, 232 insertions(+), 3 deletions(-)
snip
@@ -970,6 +1040,109 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
}
/**
+ * __qbuf_dmabuf() - handle qbuf of a DMABUF buffer
+ */
+static int __qbuf_dmabuf(struct vb2_buffer *vb, const struct v4l2_buffer *b)
+{
+ struct v4l2_plane planes[VIDEO_MAX_PLANES];
+ struct vb2_queue *q = vb-vb2_queue;
+ void *mem_priv;
+ unsigned int plane;
+ int ret;
+ int write = !V4L2_TYPE_IS_OUTPUT(q-type);
+
+ /* Verify and copy relevant information provided by the userspace */
+ ret = __fill_vb2_buffer(vb, b, planes);
Note that this code will have to change a bit when my multiplanar fixes go in:
http://www.spinics.net/lists/linux-media/msg54601.html
__fill_vb2_buffer is now a void function, so there won't be any need to check
the error.
+ if (ret)
+ return ret;
+
+ for (plane = 0; plane vb-num_planes; ++plane) {
+ struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
+
+ if (IS_ERR_OR_NULL(dbuf)) {
+ dprintk(1, qbuf: invalid dmabuf fd for plane %d\n,
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ /* use DMABUF size if length is not provided */
+ if (planes[plane].length == 0)
+ planes[plane].length = dbuf-size;
+
+ if (planes[plane].length planes[plane].data_offset +
+ q-plane_sizes[plane]) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ /* Skip the plane if already verified */
+ if (dbuf == vb-planes[plane].dbuf
+ vb-v4l2_planes[plane].length == planes[plane].length) {
+ dma_buf_put(dbuf);
+ continue;
+ }
+
+ dprintk(1, qbuf: buffer for plane %d changed\n, plane);
+
+ /* Release previously acquired memory if present */
+ __vb2_plane_dmabuf_put(q, vb-planes[plane]);
+ memset(vb-v4l2_planes[plane], 0, sizeof(struct v4l2_plane));
+
+ /* Acquire each plane's memory */
+ mem_priv = call_memop(q, attach_dmabuf, q-alloc_ctx[plane],
+ dbuf, planes[plane].length, write);
+ if (IS_ERR(mem_priv)) {
+ dprintk(1, qbuf: failed to attach dmabuf\n);
+ ret = PTR_ERR(mem_priv);
+ dma_buf_put(dbuf);
+ goto err;
+ }
+
+ vb-planes[plane].dbuf = dbuf;
+ vb-planes[plane].mem_priv = mem_priv;
+ }
+
+ /* TODO: This pins the buffer(s) with dma_buf_map_attachment()).. but
+ * really we want to do this just before the DMA, not while queueing
+ * the buffer(s)..
+ */
+ for (plane = 0; plane vb-num_planes; ++plane) {
+ ret = call_memop(q, map_dmabuf, vb-planes[plane].mem_priv);
+ if (ret) {
+ dprintk(1, qbuf: failed to map dmabuf for plane %d\n,
+ plane);
+ goto err;
+ }
+ vb-planes[plane].dbuf_mapped = 1;
+ }
+
+ /*
+ * Call driver-specific initialization on the newly acquired buffer,
+ * if provided.
+ */
+ ret = call_qop(q, buf_init, vb);
+ if (ret) {
+ dprintk(1, qbuf: buffer initialization failed\n);
+ goto err;
+ }
+
+ /*
+ * Now that everything is in order, copy relevant information
+ * provided by userspace.
+ */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ vb-v4l2_planes[plane] = planes[plane];
+
+ return 0;
+err:
+ /* In case of errors, release planes that were
Re: [PATCHv9 09/25] v4l: vb2: add prepare/finish callbacks to allocators
Some small typos...
On Tue October 2 2012 16:27:20 Tomasz Stanislawski wrote:
From: Marek Szyprowski m.szyprow...@samsung.com
This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/videobuf2-core.c | 11 +++
include/media/videobuf2-core.h |7 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 901bc56..05da3b4 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -844,6 +844,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
{
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+ unsigned int plane;
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -854,6 +855,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
dprintk(4, Done processing on buffer %d, state: %d\n,
vb-v4l2_buf.index, vb-state);
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, finish, vb-planes[plane].mem_priv);
+
/* Add the buffer to the done buffers list */
spin_lock_irqsave(q-done_lock, flags);
vb-state = state;
@@ -1148,9 +1153,15 @@ err:
static void __enqueue_in_driver(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb-vb2_queue;
+ unsigned int plane;
vb-state = VB2_BUF_STATE_ACTIVE;
atomic_inc(q-queued_count);
+
+ /* sync buffers */
+ for (plane = 0; plane vb-num_planes; ++plane)
+ call_memop(q, prepare, vb-planes[plane].mem_priv);
+
q-ops-buf_queue(vb);
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 84f11f2..c306fec 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -56,6 +56,10 @@ struct vb2_fileio_data;
* dmabuf
* @unmap_dmabuf: releases access control to the dmabuf - allocator is
notified
* that this driver is done using the dmabuf for now
+ * @prepare: called everytime the buffer is passed from userspace to the
+ * driver, usefull for cache synchronisation, optional
everytime - every time
usefull - useful
+ * @finish: called everytime the buffer is passed back from the driver
everytime - every time
+ * to the userspace, also optional
* @vaddr: return a kernel virtual address to a given memory buffer
* associated with the passed private structure or NULL if no
* such mapping exists
@@ -82,6 +86,9 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
+ void(*prepare)(void *buf_priv);
+ void(*finish)(void *buf_priv);
+
void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
unsigned long size, int write);
void(*detach_dmabuf)(void *buf_priv);
--
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: [PATCHv9 17/25] Documentation: media: description of DMABUF exporting in V4L2
More stylistic comments and a suggestion for re-ordering the fields in the expbuf struct. On Tue October 2 2012 16:27:28 Tomasz Stanislawski wrote: This patch adds description and usage examples for exporting DMABUF file descriptor in V4L2. Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: linux-...@vger.kernel.org --- Documentation/DocBook/media/v4l/compat.xml|3 + Documentation/DocBook/media/v4l/io.xml|3 + Documentation/DocBook/media/v4l/v4l2.xml |1 + Documentation/DocBook/media/v4l/vidioc-expbuf.xml | 212 + 4 files changed, 219 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index a46f95b..f0512aa 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2625,6 +2625,9 @@ ioctls./para paraImporting DMABUF file descriptors as a new IO method described in xref linkend=dmabuf /./para /listitem +listitem + paraExporting DMABUF files using VIDIOC-EXPBUF; ioctl./para +/listitem /itemizedlist /section diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 5b58657..476f448 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -488,6 +488,9 @@ DMA buffer from userspace using a file descriptor previously exported for a different or the same device (known as the importer role), or both. This section describes the DMABUF importer role API in V4L2./para +paraRefer to link linked=vidioc-expbuf DMABUF exporting /link for +details about exporting a V4L2 buffers as DMABUF file descriptors./para exporting a - exporting + paraInput and output devices support the streaming I/O method when the constantV4L2_CAP_STREAMING/constant flag in the structfieldcapabilities/structfield field of v4l2-capability; returned by diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index eee6908..d8c2597 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -543,6 +543,7 @@ and discussions on the V4L mailing list./revremark sub-enuminput; sub-enumoutput; sub-enumstd; +sub-expbuf; sub-g-audio; sub-g-audioout; sub-g-crop; diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml new file mode 100644 index 000..bf28e7d --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml @@ -0,0 +1,212 @@ +refentry id=vidioc-expbuf + + refmeta +refentrytitleioctl VIDIOC_EXPBUF/refentrytitle +manvol; + /refmeta + + refnamediv +refnameVIDIOC_EXPBUF/refname +refpurposeExport a buffer as a DMABUF file descriptor./refpurpose + /refnamediv + + refsynopsisdiv +funcsynopsis + funcprototype + funcdefint functionioctl/function/funcdef + paramdefint parameterfd/parameter/paramdef + paramdefint parameterrequest/parameter/paramdef + paramdefstruct v4l2_exportbuffer *parameterargp/parameter/paramdef + /funcprototype +/funcsynopsis + /refsynopsisdiv + + refsect1 +titleArguments/title + +variablelist + varlistentry + termparameterfd/parameter/term + listitem + parafd;/para + /listitem + /varlistentry + varlistentry + termparameterrequest/parameter/term + listitem + paraVIDIOC_EXPBUF/para + /listitem + /varlistentry + varlistentry + termparameterargp/parameter/term + listitem + para/para + /listitem + /varlistentry +/variablelist + /refsect1 + + refsect1 +titleDescription/title + +note + titleExperimental/title + paraThis is an link linkend=experimental experimental /link + interface and may change in the future./para +/note + +paraThis ioctl is an extension to the link linkend=mmapmemory +mapping/link I/O method therefore it is available only for method therefore - method, therefore +constantV4L2_MEMORY_MMAP/constant buffers. It can be used to export a +buffer as a DMABUF file at any time after buffers have been allocated with the +VIDIOC-REQBUFS; ioctl./para + +para To export a buffer, applicationis fill v4l2-exportbuffer;. The applicationis - applications +structfield type /structfield field is set to the same buffer type as was +previously used with v4l2-requestbuffers;structfield type /structfield. +Applications must also set the structfield index /structfield field. Valid +index numbers range from zero to the number of buffers allocated with
Re: [PATCHv9 18/25] v4l: add buffer exporting via dmabuf
On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
This patch adds extension to V4L2 api. It allow to export a mmap buffer as
file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
mmap and return a file descriptor on success.
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/v4l2-compat-ioctl32.c |1 +
drivers/media/video/v4l2-dev.c|1 +
drivers/media/video/v4l2-ioctl.c | 10 ++
include/linux/videodev2.h | 28
include/media/v4l2-ioctl.h|2 ++
5 files changed, 42 insertions(+)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index f0b5aba..8788000 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -971,6 +971,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+ case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c
index 07aeafc..c43127c 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -638,6 +638,7 @@ static void determine_valid_ioctls(struct video_device
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
+ SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
SET_VALID_IOCTL(ops, VIDIOC_OVERLAY, vidioc_overlay);
SET_VALID_IOCTL(ops, VIDIOC_G_FBUF, vidioc_g_fbuf);
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index dffd3c9..f3ec8c0 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -458,6 +458,15 @@ static void v4l_print_buffer(const void *arg, bool
write_only)
tc-type, tc-flags, tc-frames, *(__u32
*)tc-userbits);
}
+static void v4l_print_exportbuffer(const void *arg, bool write_only)
+{
+ const struct v4l2_exportbuffer *p = arg;
+
+ pr_cont(fd=%d, type=%s, index=%u, plane=%u, flags=0x%08x\n,
+ p-fd, prt_names(p-type, v4l2_type_names),
+ p-index, p-plane, p-flags);
+}
+
static void v4l_print_create_buffers(const void *arg, bool write_only)
{
const struct v4l2_create_buffers *p = arg;
@@ -1947,6 +1956,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_STD(VIDIOC_S_FBUF, vidioc_s_fbuf, v4l_print_framebuffer,
INFO_FL_PRIO),
IOCTL_INFO_STD(VIDIOC_OVERLAY, vidioc_overlay, v4l_print_u32,
INFO_FL_PRIO),
IOCTL_INFO_FNC(VIDIOC_QBUF, v4l_qbuf, v4l_print_buffer, INFO_FL_QUEUE),
+ IOCTL_INFO_STD(VIDIOC_EXPBUF, vidioc_expbuf, v4l_print_exportbuffer, 0),
This needs the INFO_FL_QUEUE flag, that way this call is serialized
with the other queuing ioctls.
You can also add INFO_FL_CLEAR(v4l2_expbuf, flags). This assumes a field order
in the struct as given in my comment below. The FL_CLEAR flag will zero all
fields after 'flags'.
IOCTL_INFO_FNC(VIDIOC_DQBUF, v4l_dqbuf, v4l_print_buffer,
INFO_FL_QUEUE),
IOCTL_INFO_FNC(VIDIOC_STREAMON, v4l_streamon, v4l_print_buftype,
INFO_FL_PRIO | INFO_FL_QUEUE),
IOCTL_INFO_FNC(VIDIOC_STREAMOFF, v4l_streamoff, v4l_print_buftype,
INFO_FL_PRIO | INFO_FL_QUEUE),
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index e04a73e..f429b6a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -688,6 +688,33 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE0x0800
#define V4L2_BUF_FLAG_NO_CACHE_CLEAN 0x1000
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor
+ *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @flags: flags for newly created file, currently only O_CLOEXEC is
+ * supported, refer to manual of open syscall for more details
+ * @index: id number of the buffer
+ * @type:enum v4l2_buf_type; buffer type (type == *_MPLANE for
+ * multiplanar buffers);
+ * @plane: index of the plane to be exported, 0 for single plane queues
+ *
+ * Contains data used for exporting a video buffer as DMABUF file descriptor.
+ * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
+ * (identical to the cookie used to mmap() the buffer to userspace). All
+ * reserved fields must be set to zero. The field reserved0 is expected to
+ * become a structure 'type' allowing an alternative layout of the structure
+ * content.
[PATCH v3] media: add a VEU MEM2MEM format conversion and scaling driver
Video Engine Unit (VEU) is an IP block, found in multiple SuperH and ARM- based sh-mobile and r-mobile SoCs, capable of processing video data. It can perform colour-space conversion, scaling and several filtering transformations. This patch adds an initial implementation of a mem2mem V4L2 driver for VEU. So far only conversion from NV12 to RGB565 is supported. Further functionality shall be added in the future. This driver is based on a VEU vidix driver by Magnus Damm. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v3: - compliance test is now happy apart from 2 warnings - CREATE_BUFS not implemented - replaced EPERM with EBUSY - use the device instance object as queue private data instead of a random first opening file private data - S_FMT doesn't promote the caller to a stream owner drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile |2 + drivers/media/platform/sh_veu.c | 1306 +++ 3 files changed, 1317 insertions(+), 0 deletions(-) create mode 100644 drivers/media/platform/sh_veu.c diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index f588d62..6f08746 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -190,6 +190,15 @@ config VIDEO_SAMSUNG_EXYNOS_GSC help This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler. +config VIDEO_SH_VEU + tristate SuperH VEU mem2mem video processing driver + depends on VIDEO_DEV VIDEO_V4L2 + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + help + Support for the Video Engine Unit (VEU) on SuperH and + SH-Mobile SoCs. + endif # V4L_MEM2MEM_DRIVERS menuconfig V4L_TEST_DRIVERS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index baaa550..46669f6 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA) += coda.o obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o +obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o + obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/ diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c new file mode 100644 index 000..dbb773b --- /dev/null +++ b/drivers/media/platform/sh_veu.c @@ -0,0 +1,1306 @@ +/* + * sh-mobile VEU mem2mem driver + * + * Copyright (C) 2012 Renesas Electronics Corporation + * Author: Guennadi Liakhovetski, g.liakhovet...@gmx.de + * Copyright (C) 2008 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the version 2 of the GNU General Public License as + * published by the Free Software Foundation + */ + +#include linux/fs.h +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/io.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/slab.h +#include linux/types.h +#include linux/videodev2.h + +#include media/v4l2-dev.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/v4l2-mem2mem.h +#include media/videobuf2-dma-contig.h + +#define VEU_STR 0x00 /* start register */ +#define VEU_SWR 0x10 /* src: line length */ +#define VEU_SSR 0x14 /* src: image size */ +#define VEU_SAYR 0x18 /* src: y/rgb plane address */ +#define VEU_SACR 0x1c /* src: c plane address */ +#define VEU_BSSR 0x20 /* bundle mode register */ +#define VEU_EDWR 0x30 /* dst: line length */ +#define VEU_DAYR 0x34 /* dst: y/rgb plane address */ +#define VEU_DACR 0x38 /* dst: c plane address */ +#define VEU_TRCR 0x50 /* transform control */ +#define VEU_RFCR 0x54 /* resize scale */ +#define VEU_RFSR 0x58 /* resize clip */ +#define VEU_ENHR 0x5c /* enhance */ +#define VEU_FMCR 0x70 /* filter mode */ +#define VEU_VTCR 0x74 /* lowpass vertical */ +#define VEU_HTCR 0x78 /* lowpass horizontal */ +#define VEU_APCR 0x80 /* color match */ +#define VEU_ECCR 0x84 /* color replace */ +#define VEU_AFXR 0x90 /* fixed mode */ +#define VEU_SWPR 0x94 /* swap */ +#define VEU_EIER 0xa0 /* interrupt mask */ +#define VEU_EVTR 0xa4 /* interrupt event */ +#define VEU_STAR 0xb0 /* status */ +#define VEU_BSRR 0xb4 /* reset */ + +#define VEU_MCR00 0x200 /* color conversion matrix coefficient 00 */ +#define VEU_MCR01 0x204 /* color conversion matrix coefficient 01 */ +#define VEU_MCR02 0x208 /* color conversion matrix coefficient 02 */ +#define VEU_MCR10 0x20c /* color conversion matrix coefficient 10 */ +#define VEU_MCR11 0x210 /* color conversion matrix coefficient 11 */ +#define VEU_MCR12 0x214 /* color conversion matrix coefficient 12 */ +#define VEU_MCR20 0x218 /* color conversion matrix coefficient 20 */ +#define VEU_MCR21 0x21c /* color conversion matrix coefficient 21 */ +#define VEU_MCR22 0x220 /* color conversion matrix coefficient 22 */
Re: [PATCHv9 00/25] Integration of videobuf2 with DMABUF
On Tue October 2 2012 16:27:11 Tomasz Stanislawski wrote:
Hello everyone,
This patchset adds support for DMABUF [2] importing and exporting to V4L2
stack.
Hi Tomasz,
Thanks for this patch series! I've finished reviewing it, and only found minor
things. The only (minor) API issue I found is in patch 18 where I would suggest
that reordering the fields will make things a bit more natural.
For patches 1, 3, 4, 5, 6, 7, 8, 10, 11, 12, 13, 14, 15, 16, 19, 20, 21, 22,
23, 24, 25:
Acked-by: Hans Verkuil hans.verk...@cisco.com
After fixing the typos you can also add my Acked-by for patch 9.
Regards,
Hans
v9:
- rebase on 3.6
- change type for fs to __s32
- add support for vb2_ioctl_expbuf
- remove patch 'v4l: vb2: add support for DMA_ATTR_NO_KERNEL_MAPPING',
it will be posted as a separate patch
- fix typos and style in Documentation (from Hans Verkuil)
- only vb2-core and vb2-dma-contig selects DMA_SHARED_BUFFER in Kconfig
- use data_offset and length while queueing DMABUF
- return the most recently used fd at VIDIOC_DQBUF
- use (buffer-type, index, plane) tuple instead of mem_offset
to identify a for exporting (from Hans Verkuil)
- support for DMABUF mmap in vb2-dma-contig (from Laurent Pinchart)
- add testing alignment of vaddr and size while verifying userptr
against DMA capabilities (from Laurent Pinchart)
- substitute VM_DONTDUMP with VM_RESERVED
- simplify error handling in vb2_dc_get_dmabuf (from Laurent Pinchart)
v8:
- rebased on 3.6-rc1
- merged importer and exporter patchsets
- fixed missing fields in v4l2_plane32 and v4l2_buffer32 structs
- fixed typos/style in documentation
- significant reduction of warnings from checkpatch.pl
- fixed STREAMOFF issues reported by Dima Zavin [4] by adding
__vb2_dqbuf helper to vb2-core
- DC fails if userptr is not correctly aligned
- add support for DMA attributes in DC
- add support for buffers with no kernel mapping
- add reference counting on device from allocator context
- dummy support for mmap
- use dma_get_sgtable, drop vb2_dc_kaddr_to_pages hack and
vb2_dc_get_base_sgt helper
v7:
- support for V4L2_MEMORY_DMABUF in v4l2-compact-ioctl32.c
- cosmetic fixes to the documentation
- added importing for vmalloc because vmap support in dmabuf for 3.5
was pull-requested
- support for dmabuf importing for VIVI
- resurrect allocation of dma-contig context
- remove reference of alloc_ctx in dma-contig buffer
- use sg_alloc_table_from_pages
- fix DMA scatterlist calls to use orig_nents instead of nents
- fix memleak in vb2_dc_sgt_foreach_page (use orig_nents instead of nents)
v6:
- fixed missing entry in v4l2_memory_names
- fixed a bug occuring after get_user_pages failure
- fixed a bug caused by using invalid vma for get_user_pages
- prepare/finish no longer call dma_sync for dmabuf buffers
v5:
- removed change of importer/exporter behaviour
- fixes vb2_dc_pages_to_sgt basing on Laurent's hints
- changed pin/unpin words to lock/unlock in Doc
v4:
- rebased on mainline 3.4-rc2
- included missing importing support for s5p-fimc and s5p-tv
- added patch for changing map/unmap for importers
- fixes to Documentation part
- coding style fixes
- pairing {map/unmap}_dmabuf in vb2-core
- fixing variable types and semantic of arguments in videobufb2-dma-contig.c
v3:
- rebased on mainline 3.4-rc1
- split 'code refactor' patch to multiple smaller patches
- squashed fixes to Sumit's patches
- patchset is no longer dependant on 'DMA mapping redesign'
- separated path for handling IO and non-IO mappings
- add documentation for DMABUF importing to V4L
- removed all DMABUF exporter related code
- removed usage of dma_get_pages extension
v2:
- extended VIDIOC_EXPBUF argument from integer memoffset to struct
v4l2_exportbuffer
- added patch that breaks DMABUF spec on (un)map_atachment callcacks but
allows
to work with existing implementation of DMABUF prime in DRM
- all dma-contig code refactoring patches were squashed
- bugfixes
v1: List of changes since [1].
- support for DMA api extension dma_get_pages, the function is used to
retrieve
pages used to create DMA mapping.
- small fixes/code cleanup to videobuf2
- added prepare and finish callbacks to vb2 allocators, it is used keep
consistency between dma-cpu acess to the memory (by Marek Szyprowski)
- support for exporting of DMABUF buffer in V4L2 and Videobuf2, originated
from
[3].
- support for dma-buf exporting in vb2-dma-contig allocator
- support for DMABUF for s5p-tv and s5p-fimc (capture interface) drivers,
originated from [3]
- changed handling for userptr buffers (by Marek Szyprowski, Andrzej
Pietrasiewicz)
- let mmap method to use dma_mmap_writecombine call (by Marek Szyprowski)
[1]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/42966/focus=42968
[2] https://lkml.org/lkml/2011/12/26/29
[3] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
Re: [PATCH 04/14] media: add V4L2 DT binding documentation
On Wed, 3 Oct 2012, Rob Herring wrote:
On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
Hi Rob
On Tue, 2 Oct 2012, Rob Herring wrote:
On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Documentation/devicetree/bindings/media/v4l2.txt | 162
++
1 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
diff --git a/Documentation/devicetree/bindings/media/v4l2.txt
b/Documentation/devicetree/bindings/media/v4l2.txt
new file mode 100644
index 000..b8b3f41
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/v4l2.txt
@@ -0,0 +1,162 @@
+Video4Linux Version 2 (V4L2)
DT describes the h/w, but V4L2 is Linux specific. I think the binding
looks pretty good in terms of it is describing the h/w and not V4L2
components or settings. So in this case it's really just the name of the
file and title I have issue with.
Hm, I see your point, then, I guess, you'd also like the file name
changed. What should we use then? Just video? But there's already a
whole directory Documentation/devicetree/bindings/video dedicated to
graphics output (drm, fbdev). video-camera or video-capture? But this
file shall also be describing video output. Use video.txt and describe
inside what exactly this file is for?
Video output will probably have a lot of overlap with the graphics side.
How about video-interfaces.txt?
Hm, that's a bit too vague for me. Somewhere on the outskirts of my mind
I'm still considering making just one standard for both V4L2 and fbdev /
DRM? Just yesterday we were discussing some common properties with what is
being proposed in
http://www.mail-archive.com/linux-media@vger.kernel.org/index.html#53322
Still, I think, these two subsystems deserve two separate standards and
should just try to re-use properties wherever that makes sense.
video-stream seems a bit better, but this too is just a convention -
talking about video cameras and TV output as video streaming devices and
considering displays more static devices. In principle displays can be
considered taking streaming data just as well as TV encoders. What if we
just call this camera-tv.txt?
One other comment below:
+
+General concept
+---
+
+Video pipelines consist of external devices, e.g. camera sensors,
controlled
+over an I2C, SPI or UART bus, and SoC internal IP blocks, including
video DMA
+engines and video data processors.
+
+SoC internal blocks are described by DT nodes, placed similarly to other
SoC
+blocks. External devices are represented as child nodes of their
respective bus
+controller nodes, e.g. I2C.
+
+Data interfaces on all video devices are described by port child DT
nodes.
+Configuration of a port depends on other devices participating in the
data
+transfer and is described by link DT nodes, specified as children of
the
+port nodes:
+
+/foo {
+ port@0 {
+ link@0 { ... };
+ link@1 { ... };
+ };
+ port@1 { ... };
+};
+
+If a port can be configured to work with more than one other device on
the same
+bus, a link child DT node must be provided for each of them. If more
than one
+port is present on a device or more than one link is connected to a
port, a
+common scheme, using #address-cells, #size-cells and reg
properties is
+used.
+
+Optional link properties:
+- remote: phandle to the other endpoint link DT node.
This name is a little vague. Perhaps endpoint would be better.
endpoint can also refer to something local like in USB case. Maybe
rather the description of the remote property should be improved?
remote-endpoint?
Sorry, I really don't want to pull in yet another term here. We've got
ports and links already, now you're proposing to also use endpoind.
Until now everyone was happy with remote, any more opinions on this?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 v3] media: add a VEU MEM2MEM format conversion and scaling driver
Hi Guennadi, A few more small comments... On Fri October 5 2012 11:16:06 Guennadi Liakhovetski wrote: Video Engine Unit (VEU) is an IP block, found in multiple SuperH and ARM- based sh-mobile and r-mobile SoCs, capable of processing video data. It can perform colour-space conversion, scaling and several filtering transformations. This patch adds an initial implementation of a mem2mem V4L2 driver for VEU. So far only conversion from NV12 to RGB565 is supported. Further functionality shall be added in the future. This driver is based on a VEU vidix driver by Magnus Damm. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v3: - compliance test is now happy apart from 2 warnings - CREATE_BUFS not implemented - replaced EPERM with EBUSY - use the device instance object as queue private data instead of a random first opening file private data - S_FMT doesn't promote the caller to a stream owner drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile |2 + drivers/media/platform/sh_veu.c | 1306 +++ 3 files changed, 1317 insertions(+), 0 deletions(-) create mode 100644 drivers/media/platform/sh_veu.c diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index f588d62..6f08746 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -190,6 +190,15 @@ config VIDEO_SAMSUNG_EXYNOS_GSC help This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler. +config VIDEO_SH_VEU + tristate SuperH VEU mem2mem video processing driver + depends on VIDEO_DEV VIDEO_V4L2 + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + help + Support for the Video Engine Unit (VEU) on SuperH and + SH-Mobile SoCs. + endif # V4L_MEM2MEM_DRIVERS menuconfig V4L_TEST_DRIVERS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index baaa550..46669f6 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA)+= coda.o obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE) += m2m-deinterlace.o +obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o + obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) += s5p-mfc/ diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c new file mode 100644 index 000..dbb773b --- /dev/null +++ b/drivers/media/platform/sh_veu.c @@ -0,0 +1,1306 @@ +/* + * sh-mobile VEU mem2mem driver + * + * Copyright (C) 2012 Renesas Electronics Corporation + * Author: Guennadi Liakhovetski, g.liakhovet...@gmx.de + * Copyright (C) 2008 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the version 2 of the GNU General Public License as + * published by the Free Software Foundation + */ + +#include linux/fs.h +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/io.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/slab.h +#include linux/types.h +#include linux/videodev2.h + +#include media/v4l2-dev.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/v4l2-mem2mem.h +#include media/videobuf2-dma-contig.h + +#define VEU_STR 0x00 /* start register */ +#define VEU_SWR 0x10 /* src: line length */ +#define VEU_SSR 0x14 /* src: image size */ +#define VEU_SAYR 0x18 /* src: y/rgb plane address */ +#define VEU_SACR 0x1c /* src: c plane address */ +#define VEU_BSSR 0x20 /* bundle mode register */ +#define VEU_EDWR 0x30 /* dst: line length */ +#define VEU_DAYR 0x34 /* dst: y/rgb plane address */ +#define VEU_DACR 0x38 /* dst: c plane address */ +#define VEU_TRCR 0x50 /* transform control */ +#define VEU_RFCR 0x54 /* resize scale */ +#define VEU_RFSR 0x58 /* resize clip */ +#define VEU_ENHR 0x5c /* enhance */ +#define VEU_FMCR 0x70 /* filter mode */ +#define VEU_VTCR 0x74 /* lowpass vertical */ +#define VEU_HTCR 0x78 /* lowpass horizontal */ +#define VEU_APCR 0x80 /* color match */ +#define VEU_ECCR 0x84 /* color replace */ +#define VEU_AFXR 0x90 /* fixed mode */ +#define VEU_SWPR 0x94 /* swap */ +#define VEU_EIER 0xa0 /* interrupt mask */ +#define VEU_EVTR 0xa4 /* interrupt event */ +#define VEU_STAR 0xb0 /* status */ +#define VEU_BSRR 0xb4 /* reset */ + +#define VEU_MCR00 0x200 /* color conversion matrix coefficient 00 */ +#define VEU_MCR01 0x204 /* color conversion matrix coefficient 01 */ +#define VEU_MCR02 0x208 /* color conversion matrix coefficient 02 */ +#define VEU_MCR10 0x20c /* color conversion matrix coefficient 10 */ +#define VEU_MCR11 0x210 /* color conversion matrix coefficient 11 */ +#define VEU_MCR12 0x214 /* color conversion matrix coefficient 12 */
[PATCH] [media] v4l: Add mt9v034 sensor driver
From: Enric Balletbo i Serra eballe...@iseebcn.com The MT9V034 is a parallel wide VGA sensor from Aptina (formerly Micron) controlled through I2C. The driver creates a V4L2 subdevice. It currently supports binning and cropping, and the gain, auto gain, exposure, auto exposure and test pattern controls. The following patch is based on the MT9V032 driver from Laurent Pinchart and was tested on IGEP tech based boards with custom expansion board with MT9V034 sensor. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com --- drivers/media/i2c/Kconfig | 10 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/mt9v034.c | 834 +++ include/media/mt9v034.h | 15 + 4 files changed, 860 insertions(+), 0 deletions(-) create mode 100644 drivers/media/i2c/mt9v034.c create mode 100644 include/media/mt9v034.h diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig index 0e0793a..c35efda 100644 --- a/drivers/media/i2c/Kconfig +++ b/drivers/media/i2c/Kconfig @@ -475,6 +475,16 @@ config VIDEO_MT9V032 This is a Video4Linux2 sensor-level driver for the Micron MT9V032 752x480 CMOS sensor. +config VIDEO_MT9V034 + tristate Micron MT9V034 sensor support + depends on I2C VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API + depends on MEDIA_CAMERA_SUPPORT + ---help--- + This is a Video4Linux2 sensor-level driver for the Micron + MT9V034 752x480 CMOS sensor. The MT9V034 is a 1/3-inch + wide-VGA format CMOS active-pixel digital image sensor with + TrueSNAP gobal shutter and high dynamic range (HDR) operation. + config VIDEO_TCM825X tristate TCM825x camera sensor support depends on I2C VIDEO_V4L2 diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile index 4a270f7..9d4c417 100644 --- a/drivers/media/i2c/Makefile +++ b/drivers/media/i2c/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_VIDEO_MT9P031) += mt9p031.o obj-$(CONFIG_VIDEO_MT9T001) += mt9t001.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o obj-$(CONFIG_VIDEO_MT9V032) += mt9v032.o +obj-$(CONFIG_VIDEO_MT9V034) += mt9v034.o obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_VIDEO_NOON010PC30)+= noon010pc30.o obj-$(CONFIG_VIDEO_S5K6AA) += s5k6aa.o diff --git a/drivers/media/i2c/mt9v034.c b/drivers/media/i2c/mt9v034.c new file mode 100644 index 000..7bbfeb6 --- /dev/null +++ b/drivers/media/i2c/mt9v034.c @@ -0,0 +1,834 @@ +/* + * Driver for MT9V034 CMOS Image Sensor from Micron + * + * Copyright (C) 2012, Enric Balletbo eballe...@iseebcn.com + * + * Based on the MT9V032 driver, + * + * Copyright (C) 2010, Laurent Pinchart laurent.pinch...@ideasonboard.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. + */ + +#include linux/delay.h +#include linux/i2c.h +#include linux/log2.h +#include linux/mutex.h +#include linux/slab.h +#include linux/videodev2.h +#include linux/v4l2-mediabus.h +#include linux/module.h + +#include media/mt9v034.h +#include media/v4l2-ctrls.h +#include media/v4l2-device.h +#include media/v4l2-subdev.h + +#define MT9V034_PIXEL_ARRAY_HEIGHT 499 +#define MT9V034_PIXEL_ARRAY_WIDTH 809 + +#define MT9V034_SYSCLK_FREQ_DEF2660 + +#define MT9V034_CHIP_VERSION 0x00 +#defineMT9V034_CHIP_ID_REV10x1324 +#define MT9V034_COLUMN_START 0x01 +#defineMT9V034_COLUMN_START_MIN1 +#defineMT9V034_COLUMN_START_DEF1 +#defineMT9V034_COLUMN_START_MAX752 +#define MT9V034_ROW_START 0x02 +#defineMT9V034_ROW_START_MIN 4 +#defineMT9V034_ROW_START_DEF 4 +#defineMT9V034_ROW_START_MAX 482 +#define MT9V034_WINDOW_HEIGHT 0x03 +#defineMT9V034_WINDOW_HEIGHT_MIN 1 +#defineMT9V034_WINDOW_HEIGHT_DEF 480 +#defineMT9V034_WINDOW_HEIGHT_MAX 480 +#define MT9V034_WINDOW_WIDTH 0x04 +#defineMT9V034_WINDOW_WIDTH_MIN1 +#defineMT9V034_WINDOW_WIDTH_DEF752 +#defineMT9V034_WINDOW_WIDTH_MAX752 +#define MT9V034_HORIZONTAL_BLANKING0x05 +#defineMT9V034_HORIZONTAL_BLANKING_MIN 61 +#defineMT9V034_HORIZONTAL_BLANKING_DEF 94 +#defineMT9V034_HORIZONTAL_BLANKING_MAX 1023 +#define MT9V034_VERTICAL_BLANKING 0x06 +#defineMT9V034_VERTICAL_BLANKING_MIN
[PATCH v4] media: add a VEU MEM2MEM format conversion and scaling driver
Video Engine Unit (VEU) is an IP block, found in multiple SuperH and ARM- based sh-mobile and r-mobile SoCs, capable of processing video data. It can perform colour-space conversion, scaling and several filtering transformations. This patch adds an initial implementation of a mem2mem V4L2 driver for VEU. So far only conversion from NV12 to RGB565 is supported. Further functionality shall be added in the future. This driver is based on a VEU vidix driver by Magnus Damm. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- v4: - remove redundant checks - embed struct video_device - move video_register_device() to the end of probe() - switch to managed allocations drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile |2 + drivers/media/platform/sh_veu.c | 1264 +++ 3 files changed, 1275 insertions(+), 0 deletions(-) create mode 100644 drivers/media/platform/sh_veu.c diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index f588d62..6f08746 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -190,6 +190,15 @@ config VIDEO_SAMSUNG_EXYNOS_GSC help This is a v4l2 driver for Samsung EXYNOS5 SoC G-Scaler. +config VIDEO_SH_VEU + tristate SuperH VEU mem2mem video processing driver + depends on VIDEO_DEV VIDEO_V4L2 + select VIDEOBUF2_DMA_CONTIG + select V4L2_MEM2MEM_DEV + help + Support for the Video Engine Unit (VEU) on SuperH and + SH-Mobile SoCs. + endif # V4L_MEM2MEM_DRIVERS menuconfig V4L_TEST_DRIVERS diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index baaa550..46669f6 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -27,6 +27,8 @@ obj-$(CONFIG_VIDEO_CODA) += coda.o obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o +obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o + obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/ diff --git a/drivers/media/platform/sh_veu.c b/drivers/media/platform/sh_veu.c new file mode 100644 index 000..7365fb5 --- /dev/null +++ b/drivers/media/platform/sh_veu.c @@ -0,0 +1,1264 @@ +/* + * sh-mobile VEU mem2mem driver + * + * Copyright (C) 2012 Renesas Electronics Corporation + * Author: Guennadi Liakhovetski, g.liakhovet...@gmx.de + * Copyright (C) 2008 Magnus Damm + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the version 2 of the GNU General Public License as + * published by the Free Software Foundation + */ + +#include linux/fs.h +#include linux/kernel.h +#include linux/module.h +#include linux/interrupt.h +#include linux/io.h +#include linux/platform_device.h +#include linux/pm_runtime.h +#include linux/slab.h +#include linux/types.h +#include linux/videodev2.h + +#include media/v4l2-dev.h +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/v4l2-mem2mem.h +#include media/videobuf2-dma-contig.h + +#define VEU_STR 0x00 /* start register */ +#define VEU_SWR 0x10 /* src: line length */ +#define VEU_SSR 0x14 /* src: image size */ +#define VEU_SAYR 0x18 /* src: y/rgb plane address */ +#define VEU_SACR 0x1c /* src: c plane address */ +#define VEU_BSSR 0x20 /* bundle mode register */ +#define VEU_EDWR 0x30 /* dst: line length */ +#define VEU_DAYR 0x34 /* dst: y/rgb plane address */ +#define VEU_DACR 0x38 /* dst: c plane address */ +#define VEU_TRCR 0x50 /* transform control */ +#define VEU_RFCR 0x54 /* resize scale */ +#define VEU_RFSR 0x58 /* resize clip */ +#define VEU_ENHR 0x5c /* enhance */ +#define VEU_FMCR 0x70 /* filter mode */ +#define VEU_VTCR 0x74 /* lowpass vertical */ +#define VEU_HTCR 0x78 /* lowpass horizontal */ +#define VEU_APCR 0x80 /* color match */ +#define VEU_ECCR 0x84 /* color replace */ +#define VEU_AFXR 0x90 /* fixed mode */ +#define VEU_SWPR 0x94 /* swap */ +#define VEU_EIER 0xa0 /* interrupt mask */ +#define VEU_EVTR 0xa4 /* interrupt event */ +#define VEU_STAR 0xb0 /* status */ +#define VEU_BSRR 0xb4 /* reset */ + +#define VEU_MCR00 0x200 /* color conversion matrix coefficient 00 */ +#define VEU_MCR01 0x204 /* color conversion matrix coefficient 01 */ +#define VEU_MCR02 0x208 /* color conversion matrix coefficient 02 */ +#define VEU_MCR10 0x20c /* color conversion matrix coefficient 10 */ +#define VEU_MCR11 0x210 /* color conversion matrix coefficient 11 */ +#define VEU_MCR12 0x214 /* color conversion matrix coefficient 12 */ +#define VEU_MCR20 0x218 /* color conversion matrix coefficient 20 */ +#define VEU_MCR21 0x21c /* color conversion matrix coefficient 21 */ +#define VEU_MCR22 0x220 /* color conversion matrix coefficient 22 */ +#define VEU_COFFR 0x224 /* color conversion offset */ +#define VEU_CBR 0x228 /* color conversion clip */ + +/* + * 4092x4092 max size is
Re: [PATCH 05/14] media: add a V4L2 OF parser
On Tue October 2 2012 12:13:20 Sylwester Nawrocki wrote:
Hi Guennadi,
On 10/02/2012 11:49 AM, Guennadi Liakhovetski wrote:
+ if (!of_property_read_u32_array(node, data-lanes, data_lanes,
+ ARRAY_SIZE(data_lanes))) {
+ int i;
+ for (i = 0; i ARRAY_SIZE(data_lanes); i++)
+ link-mipi_csi_2.data_lanes[i] = data_lanes[i];
It doesn't look like what we aimed for. The data-lanes array is supposed
to be of variable length, thus I don't think it can be parsed like that.
Or am I missing something ? I think we need more something like below
(based on of_property_read_u32_array(), not tested):
Ok, you're right, that my version only was suitable for fixed-size arrays,
which wasn't our goal. But I don't think we should go down to manually
parsing property data. How about (tested;-))
data = of_find_property(node, data-lanes, NULL);
if (data) {
int i = 0;
const __be32 *lane = NULL;
do {
lane = of_prop_next_u32(data, lane, data_lanes[i]);
} while (lane i++ ARRAY_SIZE(data_lanes));
link-mipi_csi_2.num_data_lanes = i;
while (i--)
link-mipi_csi_2.data_lanes[i] = data_lanes[i];
}
Yes, that looks neat and does what it is supposed to do. :) Thanks!
For now, I'll trust you it works ;)
With regards to the remaining patches, it looks a bit scary to me how
complicated it got, perhaps mostly because of requirement to reference
host devices from subdevs. And it seems to rely on the existing SoC
camera infrastructure, which might imply lot's of work need to be done
for non soc-camera drivers. But I'm going to take a closer look and
comment more on the details at the corresponding patches.
I have to say that I agree with Sylwester here. It seems awfully complicated,
but I can't really put my finger on the actual cause. It would be really
interesting to see this implemented for a non-SoC device and to compare the
two.
One area that I do not yet completely understand is the i2c bus notifications
(or asynchronous loading or i2c modules).
I would have expected that using OF the i2c devices are still initialized
before the host/bridge driver is initialized. But I gather that's not the
case?
If this deferred probing is a general problem, then I think we need a general
solution as well that's part of the v4l2 core.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: add a VEU MEM2MEM format conversion and scaling driver
On Fri October 5 2012 12:43:41 Guennadi Liakhovetski wrote: Video Engine Unit (VEU) is an IP block, found in multiple SuperH and ARM- based sh-mobile and r-mobile SoCs, capable of processing video data. It can perform colour-space conversion, scaling and several filtering transformations. This patch adds an initial implementation of a mem2mem V4L2 driver for VEU. So far only conversion from NV12 to RGB565 is supported. Further functionality shall be added in the future. This driver is based on a VEU vidix driver by Magnus Damm. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Acked-by: Hans Verkuil hans.verk...@cisco.com Thanks! Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] media: add a V4L2 OF parser
On Fri, 5 Oct 2012, Hans Verkuil wrote:
On Tue October 2 2012 12:13:20 Sylwester Nawrocki wrote:
Hi Guennadi,
On 10/02/2012 11:49 AM, Guennadi Liakhovetski wrote:
+ if (!of_property_read_u32_array(node, data-lanes, data_lanes,
+ ARRAY_SIZE(data_lanes))) {
+ int i;
+ for (i = 0; i ARRAY_SIZE(data_lanes); i++)
+ link-mipi_csi_2.data_lanes[i] = data_lanes[i];
It doesn't look like what we aimed for. The data-lanes array is supposed
to be of variable length, thus I don't think it can be parsed like that.
Or am I missing something ? I think we need more something like below
(based on of_property_read_u32_array(), not tested):
Ok, you're right, that my version only was suitable for fixed-size
arrays,
which wasn't our goal. But I don't think we should go down to manually
parsing property data. How about (tested;-))
data = of_find_property(node, data-lanes, NULL);
if (data) {
int i = 0;
const __be32 *lane = NULL;
do {
lane = of_prop_next_u32(data, lane, data_lanes[i]);
} while (lane i++ ARRAY_SIZE(data_lanes));
link-mipi_csi_2.num_data_lanes = i;
while (i--)
link-mipi_csi_2.data_lanes[i] = data_lanes[i];
}
Yes, that looks neat and does what it is supposed to do. :) Thanks!
For now, I'll trust you it works ;)
With regards to the remaining patches, it looks a bit scary to me how
complicated it got, perhaps mostly because of requirement to reference
host devices from subdevs. And it seems to rely on the existing SoC
camera infrastructure, which might imply lot's of work need to be done
for non soc-camera drivers. But I'm going to take a closer look and
comment more on the details at the corresponding patches.
I have to say that I agree with Sylwester here. It seems awfully complicated,
but I can't really put my finger on the actual cause.
Well, which exactly part? The V4L2 OF part is quite simple.
It would be really
interesting to see this implemented for a non-SoC device and to compare the
two.
Sure, volunteers? ;-) In principle, if I find time, I could try to convert
sh_vou, which is also interesting, because it's an output driver.
One area that I do not yet completely understand is the i2c bus notifications
(or asynchronous loading or i2c modules).
I would have expected that using OF the i2c devices are still initialized
before the host/bridge driver is initialized. But I gather that's not the
case?
No, it's not. I'm not sure, whether it depends on the order of devices in
the .dts, but, I think, it's better to not have to mandate a certain order
and I also seem to have seen devices being registered in different order
with the same DT, but I'm not 100% sure about that.
If this deferred probing is a general problem, then I think we need a general
solution as well that's part of the v4l2 core.
That can be done, perhaps. But we can do it as a next step. As soon as
we're happy with the OF implementation as such, we can commit that,
possibly leaving soc-camera patches out for now, then we can think where
to put async I2C handling.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] media: add a V4L2 OF parser
On Fri October 5 2012 12:58:21 Guennadi Liakhovetski wrote:
On Fri, 5 Oct 2012, Hans Verkuil wrote:
On Tue October 2 2012 12:13:20 Sylwester Nawrocki wrote:
Hi Guennadi,
On 10/02/2012 11:49 AM, Guennadi Liakhovetski wrote:
+ if (!of_property_read_u32_array(node, data-lanes, data_lanes,
+ ARRAY_SIZE(data_lanes))) {
+ int i;
+ for (i = 0; i ARRAY_SIZE(data_lanes); i++)
+ link-mipi_csi_2.data_lanes[i] = data_lanes[i];
It doesn't look like what we aimed for. The data-lanes array is
supposed
to be of variable length, thus I don't think it can be parsed like
that.
Or am I missing something ? I think we need more something like below
(based on of_property_read_u32_array(), not tested):
Ok, you're right, that my version only was suitable for fixed-size
arrays,
which wasn't our goal. But I don't think we should go down to manually
parsing property data. How about (tested;-))
data = of_find_property(node, data-lanes, NULL);
if (data) {
int i = 0;
const __be32 *lane = NULL;
do {
lane = of_prop_next_u32(data, lane,
data_lanes[i]);
} while (lane i++ ARRAY_SIZE(data_lanes));
link-mipi_csi_2.num_data_lanes = i;
while (i--)
link-mipi_csi_2.data_lanes[i] = data_lanes[i];
}
Yes, that looks neat and does what it is supposed to do. :) Thanks!
For now, I'll trust you it works ;)
With regards to the remaining patches, it looks a bit scary to me how
complicated it got, perhaps mostly because of requirement to reference
host devices from subdevs. And it seems to rely on the existing SoC
camera infrastructure, which might imply lot's of work need to be done
for non soc-camera drivers. But I'm going to take a closer look and
comment more on the details at the corresponding patches.
I have to say that I agree with Sylwester here. It seems awfully
complicated,
but I can't really put my finger on the actual cause.
Well, which exactly part? The V4L2 OF part is quite simple.
No, the soc_camera part. The V4L2 OF part looks OK. Sorry, I should have
mentioned that!
It would be really
interesting to see this implemented for a non-SoC device and to compare the
two.
Sure, volunteers? ;-) In principle, if I find time, I could try to convert
sh_vou, which is also interesting, because it's an output driver.
One area that I do not yet completely understand is the i2c bus
notifications
(or asynchronous loading or i2c modules).
I would have expected that using OF the i2c devices are still initialized
before the host/bridge driver is initialized. But I gather that's not the
case?
No, it's not. I'm not sure, whether it depends on the order of devices in
the .dts, but, I think, it's better to not have to mandate a certain order
and I also seem to have seen devices being registered in different order
with the same DT, but I'm not 100% sure about that.
If this deferred probing is a general problem, then I think we need a
general
solution as well that's part of the v4l2 core.
That can be done, perhaps. But we can do it as a next step. As soon as
we're happy with the OF implementation as such, we can commit that,
possibly leaving soc-camera patches out for now, then we can think where
to put async I2C handling.
It would be good to have a number of 'Reviewed-by's or 'Acked-by's for the
DT binding documentation at least before it is merged.
I think the soc_camera patches should be left out for now. I suspect that
by adding core support for async i2c handling first, the soc_camera patches
will become a lot easier to understand.
Regards,
Hans
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 04/14] media: add V4L2 DT binding documentation
On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote:
On Wed, 3 Oct 2012, Rob Herring wrote:
On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote:
Hi Rob
On Tue, 2 Oct 2012, Rob Herring wrote:
On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote:
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Documentation/devicetree/bindings/media/v4l2.txt | 162
++
1 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
diff --git a/Documentation/devicetree/bindings/media/v4l2.txt
b/Documentation/devicetree/bindings/media/v4l2.txt
new file mode 100644
index 000..b8b3f41
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/v4l2.txt
@@ -0,0 +1,162 @@
+Video4Linux Version 2 (V4L2)
DT describes the h/w, but V4L2 is Linux specific. I think the binding
looks pretty good in terms of it is describing the h/w and not V4L2
components or settings. So in this case it's really just the name of the
file and title I have issue with.
Hm, I see your point, then, I guess, you'd also like the file name
changed. What should we use then? Just video? But there's already a
whole directory Documentation/devicetree/bindings/video dedicated to
graphics output (drm, fbdev). video-camera or video-capture? But this
file shall also be describing video output. Use video.txt and describe
inside what exactly this file is for?
Video output will probably have a lot of overlap with the graphics side.
How about video-interfaces.txt?
Hm, that's a bit too vague for me. Somewhere on the outskirts of my mind
I'm still considering making just one standard for both V4L2 and fbdev /
DRM? Just yesterday we were discussing some common properties with what is
being proposed in
http://www.mail-archive.com/linux-media@vger.kernel.org/index.html#53322
Still, I think, these two subsystems deserve two separate standards and
should just try to re-use properties wherever that makes sense.
video-stream seems a bit better, but this too is just a convention -
talking about video cameras and TV output as video streaming devices and
considering displays more static devices. In principle displays can be
considered taking streaming data just as well as TV encoders. What if we
just call this camera-tv.txt?
One other comment below:
+
+General concept
+---
+
+Video pipelines consist of external devices, e.g. camera sensors,
controlled
+over an I2C, SPI or UART bus, and SoC internal IP blocks, including
video DMA
+engines and video data processors.
+
+SoC internal blocks are described by DT nodes, placed similarly to
other SoC
+blocks. External devices are represented as child nodes of their
respective bus
+controller nodes, e.g. I2C.
+
+Data interfaces on all video devices are described by port child DT
nodes.
+Configuration of a port depends on other devices participating in the
data
+transfer and is described by link DT nodes, specified as children of
the
+port nodes:
+
+/foo {
+ port@0 {
+ link@0 { ... };
+ link@1 { ... };
+ };
+ port@1 { ... };
+};
+
+If a port can be configured to work with more than one other device on
the same
+bus, a link child DT node must be provided for each of them. If more
than one
+port is present on a device or more than one link is connected to a
port, a
+common scheme, using #address-cells, #size-cells and reg
properties is
+used.
+
+Optional link properties:
+- remote: phandle to the other endpoint link DT node.
This name is a little vague. Perhaps endpoint would be better.
endpoint can also refer to something local like in USB case. Maybe
rather the description of the remote property should be improved?
remote-endpoint?
Sorry, I really don't want to pull in yet another term here. We've got
ports and links already, now you're proposing to also use endpoind.
Until now everyone was happy with remote, any more opinions on this?
Actually, when I was reviewing the patch series today I got confused as
well by 'remote'. What about 'remote-link'?
And v4l2_of_get_remote() can be renamed to v4l2_of_get_remote_link() which
I think is a lot clearer.
The text can be improved as well since this:
- remote: phandle to the other endpoint link DT node.
is a bit vague. How about:
- remote-link: phandle to the remote end of this link.
Regards,
Hans
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH 05/14] media: add a V4L2 OF parser
On Fri, 5 Oct 2012, Hans Verkuil wrote: On Fri October 5 2012 12:58:21 Guennadi Liakhovetski wrote: On Fri, 5 Oct 2012, Hans Verkuil wrote: [snip] One area that I do not yet completely understand is the i2c bus notifications (or asynchronous loading or i2c modules). I would have expected that using OF the i2c devices are still initialized before the host/bridge driver is initialized. But I gather that's not the case? No, it's not. I'm not sure, whether it depends on the order of devices in the .dts, but, I think, it's better to not have to mandate a certain order and I also seem to have seen devices being registered in different order with the same DT, but I'm not 100% sure about that. If this deferred probing is a general problem, then I think we need a general solution as well that's part of the v4l2 core. That can be done, perhaps. But we can do it as a next step. As soon as we're happy with the OF implementation as such, we can commit that, possibly leaving soc-camera patches out for now, then we can think where to put async I2C handling. It would be good to have a number of 'Reviewed-by's or 'Acked-by's for the DT binding documentation at least before it is merged. Definitely, I'm sure you'll be honoured to be the first one in the list;-) I think the soc_camera patches should be left out for now. I suspect that by adding core support for async i2c handling first, the soc_camera patches will become a lot easier to understand. Ok, we can do this. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 04/14] media: add V4L2 DT binding documentation
On Fri, 5 Oct 2012, Hans Verkuil wrote: On Fri October 5 2012 11:43:27 Guennadi Liakhovetski wrote: On Wed, 3 Oct 2012, Rob Herring wrote: On 10/02/2012 09:33 AM, Guennadi Liakhovetski wrote: Hi Rob On Tue, 2 Oct 2012, Rob Herring wrote: On 09/27/2012 09:07 AM, Guennadi Liakhovetski wrote: [snip] +Optional link properties: +- remote: phandle to the other endpoint link DT node. This name is a little vague. Perhaps endpoint would be better. endpoint can also refer to something local like in USB case. Maybe rather the description of the remote property should be improved? remote-endpoint? Sorry, I really don't want to pull in yet another term here. We've got ports and links already, now you're proposing to also use endpoind. Until now everyone was happy with remote, any more opinions on this? Actually, when I was reviewing the patch series today I got confused as well by 'remote'. What about 'remote-link'? Yes, I was thinking about this one too, it looks a bit clumsy, but it does make it clearer, what is meant. And v4l2_of_get_remote() can be renamed to v4l2_of_get_remote_link() which I think is a lot clearer. The text can be improved as well since this: - remote: phandle to the other endpoint link DT node. is a bit vague. How about: - remote-link: phandle to the remote end of this link. Looks good to me. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 00/14] V4L2 DT support
Hi Guennadi, Any chance for a GIT tree including this patch series ? I'd like to see all these pieces put together and I don't seem to find any base tree that this series would have applied cleanly to. ...(20121005_media_for_v3.7-dt)$ git am -3 \[PATCH\ * Applying: i2c: add dummy inline functions for when CONFIG_OF_I2C(_MODULE) isn't defined Applying: of: add a dummy inline function for when CONFIG_OF is not defined Applying: OF: make a function pointer argument const Applying: media: add V4L2 DT binding documentation Applying: media: add a V4L2 OF parser Applying: media: soc-camera: prepare for asynchronous client probing Applying: media: soc-camera: support deferred probing of clients fatal: sha1 information is lacking or useless (drivers/media/platform/soc_camera/soc_camera.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0007 media: soc-camera: support deferred probing of clients When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. -- 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/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
Hi Guennadi, On Wed, 3 Oct 2012 00:09:29 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij +#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \ +!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE) No, we're not adding any preprocessor or run-time hardware dependencies to soc-camera or to any other generic code. I have no idea what those IFM O2D cameras are. If it's their common feature, that they cannot take any further I2C commands, while streaming, their drivers have to do that themselves. I'm not sure I understand you. To do what themselves? They - subdevice drivers of such IFM O2D cameras - should take care to avoid any I2C commands during a running read-out. Neither the bridge driver nor the framework core can or should know these details. This is just a generic call to a subdevice's .s_stream() method. What the driver does in it is totally its own business. Nobody says, that you have to issue I2C commands in it. The fact that many I2C commands are permitted during streaming doesn't necessary mean that an application must use them during streaming. Our camera application is aware of I2C bus access limitations during steaming and after streamon it doesn't use configurations resulting in I2C accesses to the sensor. But I'm not arguing for the ifdef here. We are using mt9v022 subdevice driver and I'd really avoid creating new custom subdevice driver, duplicating the mt9v022 driver functionality. This custom duplicated driver also won't be accepted in mainline, I think. I was thinking about a proposal for adding I2C bus access limitation awareness to the mt9v022 subdev driver. In our case we enable the snapshot mode by calling subdevice's .s_stream() in the .start_streaming() of the capture driver (that means as part of vb2_streamon() in soc_camera_streamon()) and then configure the logic for read-out there. Here is the relevant part from soc_camera_streamon(): if (ici-ops-init_videobuf) ret = videobuf_streamon(icd-vb_vidq); else ret = vb2_streamon(icd-vb2_vidq, i); After that I2C access is not possible until .stop_streaming() in the capture driver. After enabling streaming in .s_stream() the subdevice driver will have to filter (optionaly) further I2C accesses and return success code for them so that soc_camera_streamon() finaly succeeds. Currently the return code of s_stream v4l2_subdev_call() is not checked: if (!ret) v4l2_subdev_call(sd, video, s_stream, 1); But for the case it will be fixed, we have to return success code in s_stream, at least. Otherwise VIDIOC_STREAMON will fail. Will you accept adding optional I2C access filtering to the mt9v022 subdev driver? Thanks, Anatolij -- 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.7] media: s5p-hdmi: add HPD GPIO to platform data
Hi Mauro, This patch is a part of [PATCH v1 00/14] drm: exynos: hdmi: add dt based support for exynos5 hdmi patchset. The patchset refers to DRM tree (exynos-drm-next to be more exact). However the patch 'media: s5p-hdmi: add HPD GPIO to platform data' belong to the media tree. Regards, Tomasz Stanislawski The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4: em28xx: regression fix: use DRX-K sync firmware requests on em28xx (2012-10-02 17:15:22 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l-s5p-tv-for3.7 for you to fetch changes up to b26bab928dd6f6e1d5613b68fa6fea1d29c9005e: media: s5p-hdmi: add HPD GPIO to platform data (2012-10-05 14:53:05 +0200) Tomasz Stanislawski (1): media: s5p-hdmi: add HPD GPIO to platform data include/media/s5p_hdmi.h |2 ++ 1 file changed, 2 insertions(+) -- 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/4] [media] mmp: add register definition for marvell ccic
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Sunday, 30 September, 2012 01:26 To: Albert Wang Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH 1/4] [media] mmp: add register definition for marvell ccic On Fri, 28 Sep 2012, Albert Wang wrote: From: Libin Yang lby...@marvell.com This patch adds the definition of CCIC1/2 Clock Reset register address Signed-off-by: Albert Wang twan...@marvell.com Signed-off-by: Libin Yang lby...@marvell.com --- arch/arm/mach-mmp/include/mach/regs-apmu.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-mmp/include/mach/regs-apmu.h b/arch/arm/mach-mmp/include/mach/regs-apmu.h index 7af8deb..f2cf231 100755 --- a/arch/arm/mach-mmp/include/mach/regs-apmu.h +++ b/arch/arm/mach-mmp/include/mach/regs-apmu.h @@ -16,7 +16,8 @@ /* Clock Reset Control */ #define APMU_IREAPMU_REG(0x048) #define APMU_LCDAPMU_REG(0x04c) -#define APMU_CCIC APMU_REG(0x050) +#define APMU_CCIC_RST APMU_REG(0x050) +#define APMU_CCIC2_RST APMU_REG(0x0f4) Assuming APMU_CCIC hasn't been used until now, changing its name is ok, but I think, registers in this list are ordered by their addresses, so, your addition should go between #define APMU_SDH3 APMU_REG(0x0ec) #define APMU_ETH APMU_REG(0x0fc) Sorry for late response. Sure, you are right, we will change it in Version 2 Thanks Guennadi #define APMU_SDH0 APMU_REG(0x054) #define APMU_SDH1 APMU_REG(0x058) #define APMU_USBAPMU_REG(0x05c) -- 1.7.0.4 --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Thanks Albert Wang 86-21-61092656 -- 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 4/4] [media] marvell-ccic: core: add 3 frame buffers support in DMA_CONTIG mode
From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Sunday, 30 September, 2012 03:51 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org Subject: Re: [PATCH 4/4] [media] marvell-ccic: core: add 3 frame buffers support in DMA_CONTIG mode On Fri, 28 Sep 2012 21:47:39 +0800 Albert Wang twan...@marvell.com wrote: This patch adds support of 3 frame buffers in DMA-contiguous mode. In current DMA_CONTIG mode, only 2 frame buffers can be supported. Actually, Marvell CCIC can support at most 3 frame buffers. Currently 2 frame buffers mode will be used by default. To use 3 frame buffers mode, can do: define MAX_FRAME_BUFS 3 in mcam-core.h I have no problem with the concept. I honestly don't remember why I only used the two- buffer mode for dma-contig; perhaps it's because getting even two buffers can be a bit of a challenge on a lot of systems, maybe. The application really needs to be able to get at least four buffers for the three-buffer mode to be worthwhile (otherwise you're always in a situation where the driver owns less than three and has to juggle things). But we can certainly add it. Thank you for your review! Sorry for late response. I wish this were two patches, though: 1) Change lots of int variables to unsigned int (with reasoning as to why we want to do that). 2) Add three-buffer mode. OK. Your suggestion is reasonable. We can do that in Version 2 of patches. The mode should be runtime-selectable, as it is with the vmalloc mode. Otherwise seems OK. Thanks, jon Thanks Albert Wang 86-21-61092656 -- 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/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core
Hi, Jonathan We really appreciate you can review these patches! Sorry for late response. -Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Sunday, 30 September, 2012 03:41 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core On Fri, 28 Sep 2012 21:47:20 +0800 Albert Wang twan...@marvell.com wrote: This patch adds the support of Soc Camera on marvell-ccic mcam-core. The Soc Camera mode does not compatible with current mode. Only one mode can be used at one time. To use Soc Camera, CONFIG_VIDEO_MMP_SOC_CAMERA should be defined. What's more, the platform driver should support Soc camera at the same time. Also add MIPI interface and dual CCICs support in Soc Camera mode. I'm glad this work is being done, but I have some high-level grumbles to start with. This patch is too big, and does several things. I think there needs to be one to add SOC support (but see below), one to add planar formats, one to add MIPI, one for the second CCIC, etc. That will make them all easier to review. Yes. Your concern is reasonable, I can understand it. Actually, we ever try to split the patch into some smaller ones, but it looks will let thing be more complicated. So we keep the 2 big patches and look forward your comments and suggestions firstly. We will continue to discuss how to split them if you insist. The SOC camera stuff could maybe use a little more thought. Why does this driver *need* to be a SOC camera driver? If that is truly necessary (or sufficiently beneficial), can we get to the point where that's the only mode? I really dislike the two modes; we're essentially perpetuating the two-drivers concept in a #ifdef'd form; it would be good not to do that. Yes, #ifdef is indeed not a good method. We will continue to discuss how to remove them. Maybe I can describe that why we add SOC camera mode: SOC camera is optional for camera driver, so we try to keep the original method of marvell-ccic Just let user to select use SOC camera or not use it If there is truly some reason why both modes need to exist, can we arrange things so that the core doesn't know the difference? I'd like to see no new ifdefs there if possible, it already has way too many. That, I think, is how I'd like to go toward a cleaner, more reviewable, more maintainable solution. Make sense? Yes. We agree with you! :) Thanks, jon Thanks Albert Wang 86-21-61092656 -- 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/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core
-Original Message- From: Jonathan Corbet [mailto:cor...@lwn.net] Sent: Monday, 01 October, 2012 05:10 To: Albert Wang Cc: g.liakhovet...@gmx.de; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core On Sat, 29 Sep 2012 13:40:41 -0600 Jonathan Corbet cor...@lwn.net wrote: I'm glad this work is being done, but I have some high-level grumbles to start with. I was thinking on this over the weekend, and I realized that my response may have been a bit too short and grumpy. So I wanted to add one little thing: It's really great that Marvell is putting the time into doing this work, and, my gripes notwithstanding, you're doing it right. You've sent your code out, listened to the responses you've gotten, and done the work to try to address them. Quite a bit of progress has been made here, and I don't doubt this code will be ready for merging before too much longer. Please continue on this path; we do appreciate the work you're doing. Hi, Jonathan We have learnt so much from you and we still hope can get your help on improving our patches' quality. We hope the experts like you and Guennadi can continue to review our patches in the future. Thanks, jon Thanks Albert Wang 86-21-61092656 -- 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/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core
-Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Sunday, 30 September, 2012 07:31 To: Jonathan Corbet Cc: Albert Wang; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH 2/4] [media] marvell-ccic: core: add soc camera support on marvell-ccic mcam-core On Sat, 29 Sep 2012, Jonathan Corbet wrote: On Fri, 28 Sep 2012 21:47:20 +0800 Albert Wang twan...@marvell.com wrote: This patch adds the support of Soc Camera on marvell-ccic mcam-core. The Soc Camera mode does not compatible with current mode. Only one mode can be used at one time. To use Soc Camera, CONFIG_VIDEO_MMP_SOC_CAMERA should be defined. What's more, the platform driver should support Soc camera at the same time. Also add MIPI interface and dual CCICs support in Soc Camera mode. I'm glad this work is being done, but I have some high-level grumbles to start with. This patch is too big, and does several things. I think there needs to be one to add SOC support (but see below), one to add planar formats, one to add MIPI, one for the second CCIC, etc. That will make them all easier to review. The SOC camera stuff could maybe use a little more thought. Why does this driver *need* to be a SOC camera driver? It probably doesn't, but if the author wishes to do so - we can try to do this cleanly. If that is truly necessary (or sufficiently beneficial), can we get to the point where that's the only mode? I really dislike the two modes; we're essentially perpetuating the two-drivers concept in a #ifdef'd form; it would be good not to do that. If there is truly some reason why both modes need to exist, can we arrange things so that the core doesn't know the difference? I'd like to see no new ifdefs there if possible, it already has way too many. A strong +1. Ideally we should identify common code, add soc-camera mode as a separate file and re-use the common stuff. OK, we will discuss this method. That, I think, is how I'd like to go toward a cleaner, more reviewable, more maintainable solution. Make sense? Definitely! Thanks Guennadi Thanks, jon --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ Thanks Albert Wang 86-21-61092656 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
Hi Anatolij On Fri, 5 Oct 2012, Anatolij Gustschin wrote: Hi Guennadi, On Wed, 3 Oct 2012 00:09:29 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij +#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \ +!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE) No, we're not adding any preprocessor or run-time hardware dependencies to soc-camera or to any other generic code. I have no idea what those IFM O2D cameras are. If it's their common feature, that they cannot take any further I2C commands, while streaming, their drivers have to do that themselves. I'm not sure I understand you. To do what themselves? They - subdevice drivers of such IFM O2D cameras - should take care to avoid any I2C commands during a running read-out. Neither the bridge driver nor the framework core can or should know these details. This is just a generic call to a subdevice's .s_stream() method. What the driver does in it is totally its own business. Nobody says, that you have to issue I2C commands in it. Unfortunately you still haven't explained what IFM O2D cameras are and why they have that I2C command restriction. Or - looking at the keyboard - is O2D just a typo and it should have been I2C? The fact that many I2C commands are permitted during streaming doesn't necessary mean that an application must use them during streaming. Our camera application is aware of I2C bus access limitations during steaming and after streamon it doesn't use configurations resulting in I2C accesses to the sensor. But I'm not arguing for the ifdef here. But that's the only thing, that your patch is doing. So, this patch can be dropped? We are using mt9v022 subdevice driver and I'd really avoid creating new custom subdevice driver, duplicating the mt9v022 driver functionality. This custom duplicated driver also won't be accepted in mainline, I think. Correct. I was thinking about a proposal for adding I2C bus access limitation awareness to the mt9v022 subdev driver. I think I begin to understand. This is exactly why you need the snapshot mode in mt9v022, right? And in your camera host driver you issue a stream-off command on stream-on to switch into the snapshot mode, then you have to suppress the stream-on in soc-camera core. If I understand correctly, then this is broken. Your host driver will stop streaming on all sensor drivers and the ifdef will suppress the streamon from the soc-camera core, so, your host driver will only work on this specific board, where you have to use the snapshot mode on mt9v022. The proper solution, as I already suggested before, would be to implement a snapshot mode support. In that case the mt9v022 driver will be aware, that it has to work in the snapshot mode and will not switch over into the streaming mode. This topic has been raised several times on the mailing list, but until now nobody had a real need for a snapshot mode. The easiest way to do this would be to add a camera class control, however, I suspect, this is a much more complex topic, see, e.g. this recent thread: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/54079 Maybe you could review that thread and reply to it with your requirements? Thanks Guennadi In our case we enable the snapshot mode by calling subdevice's .s_stream() in the .start_streaming() of the capture driver (that means as part of vb2_streamon() in soc_camera_streamon()) and then configure the logic for read-out there. Here is the relevant part from soc_camera_streamon(): if (ici-ops-init_videobuf) ret = videobuf_streamon(icd-vb_vidq); else ret = vb2_streamon(icd-vb2_vidq, i); After that I2C access is not possible until .stop_streaming() in the capture driver. After enabling streaming in .s_stream() the subdevice driver will have to filter (optionaly) further I2C accesses and return success code for them so that soc_camera_streamon() finaly succeeds. Currently the return code of s_stream v4l2_subdev_call() is not checked: if (!ret) v4l2_subdev_call(sd, video, s_stream, 1); But for the case it will be fixed, we have to return success code in s_stream, at least. Otherwise VIDIOC_STREAMON will fail. Will you accept adding optional I2C access filtering to the mt9v022 subdev driver? Thanks, Anatolij --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 00/14] V4L2 DT support
Hi Sylwester On Fri, 5 Oct 2012, Sylwester Nawrocki wrote: Hi Guennadi, Any chance for a GIT tree including this patch series ? I'd like to see all these pieces put together and I don't seem to find any base tree that this series would have applied cleanly to. Ok, I pushed the patches to git://linuxtv.org/gliakhovetski/v4l-dvb.git dt-soc_camera Please, give it a go. Thanks Guennadi ...(20121005_media_for_v3.7-dt)$ git am -3 \[PATCH\ * Applying: i2c: add dummy inline functions for when CONFIG_OF_I2C(_MODULE) isn't defined Applying: of: add a dummy inline function for when CONFIG_OF is not defined Applying: OF: make a function pointer argument const Applying: media: add V4L2 DT binding documentation Applying: media: add a V4L2 OF parser Applying: media: soc-camera: prepare for asynchronous client probing Applying: media: soc-camera: support deferred probing of clients fatal: sha1 information is lacking or useless (drivers/media/platform/soc_camera/soc_camera.c). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0007 media: soc-camera: support deferred probing of clients When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. -- Thanks, Sylwester --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 04/14] media: add V4L2 DT binding documentation
Hi Guennadi,
Some comments inline.
On Thu, Sep 27, 2012 at 04:07:23PM +0200, Guennadi Liakhovetski wrote:
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Documentation/devicetree/bindings/media/v4l2.txt | 162
++
1 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
diff --git a/Documentation/devicetree/bindings/media/v4l2.txt
b/Documentation/devicetree/bindings/media/v4l2.txt
new file mode 100644
index 000..b8b3f41
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/v4l2.txt
@@ -0,0 +1,162 @@
+Video4Linux Version 2 (V4L2)
+
+General concept
+---
+
+Video pipelines consist of external devices, e.g. camera sensors, controlled
+over an I2C, SPI or UART bus, and SoC internal IP blocks, including video DMA
+engines and video data processors.
+
+SoC internal blocks are described by DT nodes, placed similarly to other SoC
+blocks. External devices are represented as child nodes of their respective
bus
+controller nodes, e.g. I2C.
+
+Data interfaces on all video devices are described by port child DT nodes.
+Configuration of a port depends on other devices participating in the data
+transfer and is described by link DT nodes, specified as children of the
+port nodes:
+
+/foo {
+ port@0 {
+ link@0 { ... };
+ link@1 { ... };
+ };
+ port@1 { ... };
+};
+
+If a port can be configured to work with more than one other device on the
same
+bus, a link child DT node must be provided for each of them. If more than
one
+port is present on a device or more than one link is connected to a port, a
+common scheme, using #address-cells, #size-cells and reg properties is
+used.
+
+Optional link properties:
+- remote: phandle to the other endpoint link DT node.
+- slave-mode: a boolean property, run the link in slave mode. Default is
master
+ mode.
+- data-shift: on parallel data busses, if data-width is used to specify the
+ number of data lines, data-shift can be used to specify which data lines
are
+ used, e.g. data-width=10; data-shift=2; means, that lines 9:2 are
used.
+- hsync-active: 1 or 0 for active-high or -low HSYNC signal polarity
+ respectively.
+- vsync-active: ditto for VSYNC. Note, that if HSYNC and VSYNC polarities are
+ not specified, embedded synchronisation may be required, where supported.
+- data-active: similar to HSYNC and VSYNC specifies data line polarity.
+- field-even-active: field signal level during the even field data
transmission.
+- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock pin.
+- data-lanes: array of serial, e.g. MIPI CSI-2, data hardware lane numbers in
+ the ascending order, beginning with logical lane 0.
+- clock-lanes: hardware lane number, used for the clock lane.
+- clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous
+ clock mode.
+
+Example:
+
+ ceu0: ceu@0xfe91 {
+ compatible = renesas,sh-mobile-ceu;
+ reg = 0xfe91 0xa0;
+ interrupts = 0x880;
+
+ mclk: master_clock {
+ compatible = renesas,ceu-clock;
+ #clock-cells = 1;
+ clock-frequency = 5000; /* max clock frequency
*/
+ clock-output-names = mclk;
+ };
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ceu0_1: link@1 {
+ reg = 1; /* local link # */
+ remote = ov772x_1_1; /* remote phandle */
+ bus-width = 8;/* used data lines */
+ data-shift = 0; /* lines 7:0 are used */
+
+ /* If [hv]sync-active are missing, embedded
bt.605 sync is used */
+ hsync-active = 1; /* active high */
+ vsync-active = 1; /* active high */
+ data-active = 1; /* active high */
+ pclk-sample = 1; /* rising */
+ };
+
+ ceu0_0: link@0 {
+ reg = 0;
+ remote = csi2_2;
+ immutable;
+ };
+ };
+ };
+
+ i2c0: i2c@0xfff2 {
+ ...
+ ov772x_1: camera@0x21 {
+ compatible = omnivision,ov772x;
+ reg = 0x21;
+ vddio-supply = regulator1;
+ vddcore-supply = regulator2;
+
+
RE: [PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic mmp-driver
-Original Message- From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Monday, 01 October, 2012 18:09 To: Albert Wang Cc: cor...@lwn.net; linux-media@vger.kernel.org; Libin Yang Subject: Re: [PATCH 3/4] [media] marvell-ccic: mmp: add soc camera support on marvell-ccic mmp-driver Hi Albert On Fri, 28 Sep 2012, Albert Wang wrote: From: Libin Yang lby...@marvell.com This patch adds the support of Soc Camera on marvell-ccic mmp-driver. The Soc Camera mode does not compatible with current mode. Only one mode can be used at one time. Again, once these patches are split into smaller ones reviewing them should become easier and new issues will likely arise, but please take a look at these comments so far. Yes, I understand your concern. We will continue to discuss how to split them. To enable Soc Camera on mmp: In Device Drivers -- Multimedia support: select Cameras/video grabbers support Then in Video capture adapters -- V4L platform devices -- Camera support on Marvell MMP: select Marvell MMP camera driver based on SOC_CAMERA Also in Video capture adapters -- V4L platform devices: select SoC camera support select the relevant sensor in target platform Also add MIPI interface and dual CCICs support in Soc Camera mode. Signed-off-by: Albert Wang twan...@marvell.com Signed-off-by: Libin Yang lby...@marvell.com --- drivers/media/platform/Makefile |4 +- drivers/media/platform/marvell-ccic/Kconfig | 22 +++ drivers/media/platform/marvell-ccic/Makefile |1 + drivers/media/platform/marvell-ccic/mmp-driver.c | 253 +++-- include/media/mmp-camera.h| 13 ++ 5 files changed, 233 insertions(+), 60 deletions(-) diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index b7da9fa..ca60607 100755 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -146,9 +146,6 @@ obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o -obj-$(CONFIG_VIDEO_CAFE_CCIC) += marvell-ccic/ -obj-$(CONFIG_VIDEO_MMP_CAMERA) += marvell-ccic/ - obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o obj-$(CONFIG_VIDEO_OMAP3) += omap3isp/ @@ -182,6 +179,7 @@ obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o obj-$(CONFIG_VIDEO_MX2) += mx2_camera.o obj-$(CONFIG_VIDEO_MX3) += mx3_camera.o obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o +obj-$(CONFIG_VIDEO_MARVELL_CCIC)+= marvell-ccic/ obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o diff --git a/drivers/media/platform/marvell-ccic/Kconfig b/drivers/media/platform/marvell-ccic/Kconfig index bf739e3..6e3eaa0 100755 --- a/drivers/media/platform/marvell-ccic/Kconfig +++ b/drivers/media/platform/marvell-ccic/Kconfig @@ -1,23 +1,45 @@ +config VIDEO_MARVELL_CCIC + tristate +config VIDEO_MRVL_SOC_CAMERA + tristate + config VIDEO_CAFE_CCIC tristate Marvell 88ALP01 (Cafe) CMOS Camera Controller support depends on PCI I2C VIDEO_V4L2 select VIDEO_OV7670 select VIDEOBUF2_VMALLOC select VIDEOBUF2_DMA_CONTIG +select VIDEO_MARVELL_CCIC ---help--- This is a video4linux2 driver for the Marvell 88ALP01 integrated CMOS camera controller. This is the controller found on first- generation OLPC systems. +choice +prompt Camera support on Marvell MMP +depends on ARCH_MMP VIDEO_V4L2 +optional config VIDEO_MMP_CAMERA tristate Marvell Armada 610 integrated camera controller support depends on ARCH_MMP I2C VIDEO_V4L2 select VIDEO_OV7670 select I2C_GPIO select VIDEOBUF2_DMA_SG +select VIDEO_MARVELL_CCIC ---help--- This is a Video4Linux2 driver for the integrated camera controller found on Marvell Armada 610 application processors (and likely beyond). This is the controller found in OLPC XO 1.75 systems. +config VIDEO_MMP_SOC_CAMERA +bool Marvell MMP camera driver based on SOC_CAMERA +depends on VIDEO_DEV SOC_CAMERA ARCH_MMP VIDEO_V4L2 +select VIDEOBUF2_DMA_CONTIG +select VIDEO_MARVELL_CCIC +select VIDEO_MRVL_SOC_CAMERA +---help--- + This is a Video4Linux2 driver for the Marvell Mobile Soc + PXA910/PXA688/PXA2128/PXA988 CCIC + (CMOS Camera Interface Controller) endchoice diff --git a/drivers/media/platform/marvell-ccic/Makefile b/drivers/media/platform/marvell-ccic/Makefile index 05a792c..d6ffd16 100755 --- a/drivers/media/platform/marvell-ccic/Makefile +++ b/drivers/media/platform/marvell-ccic/Makefile @@ -2,5 +2,6 @@ obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o cafe_ccic-y := cafe-driver.o mcam-core.o obj-$(CONFIG_VIDEO_MMP_CAMERA) += mmp_camera.o
[PATCH] media: soc-camera: update documentation
Update soc-camera documentation to reflect the current camera host API and
the use of the common V4L2 subdev API.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Documentation/video4linux/soc-camera.txt | 146 +++---
1 files changed, 75 insertions(+), 71 deletions(-)
diff --git a/Documentation/video4linux/soc-camera.txt
b/Documentation/video4linux/soc-camera.txt
index 3f87c7d..f62fcdb 100644
--- a/Documentation/video4linux/soc-camera.txt
+++ b/Documentation/video4linux/soc-camera.txt
@@ -9,32 +9,36 @@ The following terms are used in this document:
of connecting to a variety of systems and interfaces, typically uses i2c for
control and configuration, and a parallel or a serial bus for data.
- camera host - an interface, to which a camera is connected. Typically a
- specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx,
SuperH,
+ specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH,
AVR32, i.MX27, i.MX31.
- camera host bus - a connection between a camera host and a camera. Can be
- parallel or serial, consists of data and control lines, e.g., clock,
vertical
+ parallel or serial, consists of data and control lines, e.g. clock, vertical
and horizontal synchronization signals.
Purpose of the soc-camera subsystem
---
-The soc-camera subsystem provides a unified API between camera host drivers and
-camera sensor drivers. It implements a V4L2 interface to the user, currently
-only the mmap method is supported.
+The soc-camera subsystem initially provided a unified API between camera host
+drivers and camera sensor drivers. Later the soc-camera sensor API has been
+replaced with the V4L2 standard subdev API. This also made camera driver re-use
+with non-soc-camera hosts possible. The camera host API to the soc-camera core
+has been preserved.
-This subsystem has been written to connect drivers for System-on-Chip (SoC)
-video capture interfaces with drivers for CMOS camera sensor chips to enable
-the reuse of sensor drivers with various hosts. The subsystem has been designed
-to support multiple camera host interfaces and multiple cameras per interface,
-although most applications have only one camera sensor.
+Soc-camera implements a V4L2 interface to the user, currently only the mmap
+method is supported by host drivers. However, the soc-camera core also provides
+support for the read method.
+
+The subsystem has been designed to support multiple camera host interfaces and
+multiple cameras per interface, although most applications have only one camera
+sensor.
Existing drivers
-As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for
-PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor
drivers:
-mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver.
This
-list is not supposed to be updated, look for more examples in your tree.
+As of 3.7 there are seven host drivers in the mainline: atmel-isi.c,
+mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c,
+omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor
+drivers under drivers/media/i2c/soc_camera/.
Camera host API
---
@@ -45,38 +49,37 @@ soc_camera_host_register(struct soc_camera_host *);
function. The host object can be initialized as follows:
-static struct soc_camera_host pxa_soc_camera_host = {
- .drv_name = PXA_CAM_DRV_NAME,
- .ops= pxa_soc_camera_host_ops,
-};
+ struct soc_camera_host *ici;
+ ici-drv_name = DRV_NAME;
+ ici-ops= camera_host_ops;
+ ici-priv = pcdev;
+ ici-v4l2_dev.dev = pdev-dev;
+ ici-nr = pdev-id;
All camera host methods are passed in a struct soc_camera_host_ops:
-static struct soc_camera_host_ops pxa_soc_camera_host_ops = {
+static struct soc_camera_host_ops camera_host_ops = {
.owner = THIS_MODULE,
- .add= pxa_camera_add_device,
- .remove = pxa_camera_remove_device,
- .suspend= pxa_camera_suspend,
- .resume = pxa_camera_resume,
- .set_fmt_cap= pxa_camera_set_fmt_cap,
- .try_fmt_cap= pxa_camera_try_fmt_cap,
- .init_videobuf = pxa_camera_init_videobuf,
- .reqbufs= pxa_camera_reqbufs,
- .poll = pxa_camera_poll,
- .querycap = pxa_camera_querycap,
- .try_bus_param = pxa_camera_try_bus_param,
- .set_bus_param = pxa_camera_set_bus_param,
+ .add= camera_add_device,
+ .remove = camera_remove_device,
+ .set_fmt= camera_set_fmt_cap,
+ .try_fmt= camera_try_fmt_cap,
+ .init_videobuf2 = camera_init_videobuf2,
+ .poll = camera_poll,
+ .querycap = camera_querycap,
+
Re: [PATCH 04/14] media: add V4L2 DT binding documentation
Hi Sascha
On Fri, 5 Oct 2012, Sascha Hauer wrote:
Hi Guennadi,
Some comments inline.
On Thu, Sep 27, 2012 at 04:07:23PM +0200, Guennadi Liakhovetski wrote:
This patch adds a document, describing common V4L2 device tree bindings.
Co-authored-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Documentation/devicetree/bindings/media/v4l2.txt | 162
++
1 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/v4l2.txt
diff --git a/Documentation/devicetree/bindings/media/v4l2.txt
b/Documentation/devicetree/bindings/media/v4l2.txt
new file mode 100644
index 000..b8b3f41
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/v4l2.txt
@@ -0,0 +1,162 @@
+Video4Linux Version 2 (V4L2)
+
+General concept
+---
+
+Video pipelines consist of external devices, e.g. camera sensors,
controlled
+over an I2C, SPI or UART bus, and SoC internal IP blocks, including video
DMA
+engines and video data processors.
+
+SoC internal blocks are described by DT nodes, placed similarly to other
SoC
+blocks. External devices are represented as child nodes of their
respective bus
+controller nodes, e.g. I2C.
+
+Data interfaces on all video devices are described by port child DT
nodes.
+Configuration of a port depends on other devices participating in the data
+transfer and is described by link DT nodes, specified as children of the
+port nodes:
+
+/foo {
+ port@0 {
+ link@0 { ... };
+ link@1 { ... };
+ };
+ port@1 { ... };
+};
+
+If a port can be configured to work with more than one other device on the
same
+bus, a link child DT node must be provided for each of them. If more
than one
+port is present on a device or more than one link is connected to a port, a
+common scheme, using #address-cells, #size-cells and reg properties
is
+used.
+
+Optional link properties:
+- remote: phandle to the other endpoint link DT node.
+- slave-mode: a boolean property, run the link in slave mode. Default is
master
+ mode.
+- data-shift: on parallel data busses, if data-width is used to specify the
+ number of data lines, data-shift can be used to specify which data lines
are
+ used, e.g. data-width=10; data-shift=2; means, that lines 9:2 are
used.
+- hsync-active: 1 or 0 for active-high or -low HSYNC signal polarity
+ respectively.
+- vsync-active: ditto for VSYNC. Note, that if HSYNC and VSYNC polarities
are
+ not specified, embedded synchronisation may be required, where supported.
+- data-active: similar to HSYNC and VSYNC specifies data line polarity.
+- field-even-active: field signal level during the even field data
transmission.
+- pclk-sample: rising (1) or falling (0) edge to sample the pixel clock
pin.
+- data-lanes: array of serial, e.g. MIPI CSI-2, data hardware lane numbers
in
+ the ascending order, beginning with logical lane 0.
+- clock-lanes: hardware lane number, used for the clock lane.
+- clock-noncontinuous: a boolean property to allow MIPI CSI-2
non-continuous
+ clock mode.
+
+Example:
+
+ ceu0: ceu@0xfe91 {
+ compatible = renesas,sh-mobile-ceu;
+ reg = 0xfe91 0xa0;
+ interrupts = 0x880;
+
+ mclk: master_clock {
+ compatible = renesas,ceu-clock;
+ #clock-cells = 1;
+ clock-frequency = 5000; /* max clock frequency
*/
+ clock-output-names = mclk;
+ };
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ceu0_1: link@1 {
+ reg = 1; /* local link # */
+ remote = ov772x_1_1; /* remote phandle */
+ bus-width = 8;/* used data lines */
+ data-shift = 0; /* lines 7:0 are used */
+
+ /* If [hv]sync-active are missing, embedded
bt.605 sync is used */
+ hsync-active = 1; /* active high */
+ vsync-active = 1; /* active high */
+ data-active = 1; /* active high */
+ pclk-sample = 1; /* rising */
+ };
+
+ ceu0_0: link@0 {
+ reg = 0;
+ remote = csi2_2;
+ immutable;
+ };
+ };
+ };
+
+ i2c0: i2c@0xfff2 {
+ ...
+ ov772x_1: camera@0x21 {
+ compatible = omnivision,ov772x;
+ reg = 0x21;
+
Re: [PATCH 2/2] V4L: soc_camera: disable I2C subdev streamon for mpc52xx_csi
On Fri, 5 Oct 2012 16:31:58 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij On Fri, 5 Oct 2012, Anatolij Gustschin wrote: Hi Guennadi, On Wed, 3 Oct 2012 00:09:29 +0200 (CEST) Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Hi Anatolij +#if !defined(CONFIG_VIDEO_MPC52xx_CSI) \ +!defined(CONFIG_VIDEO_MPC52xx_CSI_MODULE) No, we're not adding any preprocessor or run-time hardware dependencies to soc-camera or to any other generic code. I have no idea what those IFM O2D cameras are. If it's their common feature, that they cannot take any further I2C commands, while streaming, their drivers have to do that themselves. I'm not sure I understand you. To do what themselves? They - subdevice drivers of such IFM O2D cameras - should take care to avoid any I2C commands during a running read-out. Neither the bridge driver nor the framework core can or should know these details. This is just a generic call to a subdevice's .s_stream() method. What the driver does in it is totally its own business. Nobody says, that you have to issue I2C commands in it. Unfortunately you still haven't explained what IFM O2D cameras are and why they have that I2C command restriction. This is not true. I did. And I did it even _before_ anyone has asked me to explain it. Please read the commit log of this patch again. The fact that many I2C commands are permitted during streaming doesn't necessary mean that an application must use them during streaming. Our camera application is aware of I2C bus access limitations during steaming and after streamon it doesn't use configurations resulting in I2C accesses to the sensor. But I'm not arguing for the ifdef here. But that's the only thing, that your patch is doing. So, this patch can be dropped? Only if there will be another possibility to isolate I2C access after streamon. Otherwise the capturing won't work. We are using mt9v022 subdevice driver and I'd really avoid creating new custom subdevice driver, duplicating the mt9v022 driver functionality. This custom duplicated driver also won't be accepted in mainline, I think. Correct. I was thinking about a proposal for adding I2C bus access limitation awareness to the mt9v022 subdev driver. I think I begin to understand. This is exactly why you need the snapshot mode in mt9v022, right? No! Not only. There are many different requirements for industrial camera applications. I.e. one requirement is to trigger a single frame on some external event and to capture exactly this triggered frame. Streaming mode is not suitable here. And in your camera host driver you issue a stream-off command on stream-on to switch into the snapshot mode, then you have to suppress the stream-on in soc-camera core. If I understand correctly, then this is broken. Your host driver will stop streaming on all sensor drivers and the ifdef will suppress the streamon from the soc-camera core, so, your host driver will only work on this specific board, where you have to use the snapshot mode on mt9v022. What is wrong with this? Nothing is broken at all. This host driver is written for this specific board family and is not used on other boards. It cannot be used on other boards at all since these do not provide needed sensor glue logic. Even if other sensor drivers should ever be used on this board (most probably it will never be the case), they have to be used in snapshot mode anyway. The proper solution, as I already suggested before, would be to implement a snapshot mode support. In that case the mt9v022 driver will be aware, that it has to work in the snapshot mode and will not switch over into the streaming mode. This topic has been raised several times on the mailing list, but until now nobody had a real need for a snapshot mode. The easiest way to do this would be to add a camera class control, however, I suspect, this is a much more complex topic, see, e.g. this recent thread: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/54079 Maybe you could review that thread and reply to it with your requirements? I did already read this thread partially. Unfortunately I do not have time for it now, maybe later. Thanks, Anatolij -- 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] Fixed list_del corruption in videobuf-core.c : videobuf_queue_cancel()
If there is a buffer with VIDEOBUF_QUEUED state it won't be deleted properly because the head of queue loses its elements by calling INIT_LIST_HEAD() before videobuf_streamoff(). --- drivers/media/video/omap/omap_vout.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 409da0f..f02eb8e 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -1738,8 +1738,8 @@ static int vidioc_streamoff(struct file *file, void *fh, enum v4l2_buf_type i) v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode in streamoff\n); - INIT_LIST_HEAD(vout-dma_queue); ret = videobuf_streamoff(vout-vbq); + INIT_LIST_HEAD(vout-dma_queue); return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: soc-camera: remove superfluous JPEG checking
Explicit checks for the JPEG pixel format in soc_mbus_bytes_per_line() and
soc_mbus_image_size() are superfluous, because also without them these
functions will perform correctly. The former will return 0 based on
packing == SOC_MBUS_PACKING_VARIABLE and the latter will simply multiply
the user-provided line length by the image height to obtain a frame buffer
size estimate. The original version of the media: soc_camera: don't clear
pix-sizeimage in JPEG mode patch was correct and my amendment, adding
these two checks was superfluous.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c
b/drivers/media/platform/soc_camera/soc_mediabus.c
index a397812..89dce09 100644
--- a/drivers/media/platform/soc_camera/soc_mediabus.c
+++ b/drivers/media/platform/soc_camera/soc_mediabus.c
@@ -378,9 +378,6 @@ EXPORT_SYMBOL(soc_mbus_samples_per_pixel);
s32 soc_mbus_bytes_per_line(u32 width, const struct soc_mbus_pixelfmt *mf)
{
- if (mf-fourcc == V4L2_PIX_FMT_JPEG)
- return 0;
-
if (mf-layout != SOC_MBUS_LAYOUT_PACKED)
return width * mf-bits_per_sample / 8;
@@ -403,9 +400,6 @@ EXPORT_SYMBOL(soc_mbus_bytes_per_line);
s32 soc_mbus_image_size(const struct soc_mbus_pixelfmt *mf,
u32 bytes_per_line, u32 height)
{
- if (mf-fourcc == V4L2_PIX_FMT_JPEG)
- return 0;
-
if (mf-layout == SOC_MBUS_LAYOUT_PACKED)
return bytes_per_line * height;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2 v6] of: add generic videomode description
On Thu, Oct 04, 2012 at 12:51:00PM -0600, Stephen Warren wrote:
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
Get videomode from devicetree in a format appropriate for the
backend. drm_display_mode and fb_videomode are supported atm.
Uses the display signal timings from of_display_timings
+++ b/drivers/of/of_videomode.c
+int videomode_from_timing(struct display_timings *disp, struct videomode
*vm,
+ st = display_timings_get(disp, index);
+
+ if (!st) {
It's a little odd to leave a blank line between those two lines.
Hm, well okay. That can be remedied
Only half of the code in this file seems OF-related; the routines to
convert a timing to a videomode or drm display mode seem like they'd be
useful outside device tree, so I wonder if putting them into
of_videomode.c is the correct thing to do. Still, it's probably not a
big deal.
I am not sure, what the appropriate way to do this is. I can split it up
(again).
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 04/14] media: add V4L2 DT binding documentation
On Fri, Oct 05, 2012 at 05:41:00PM +0200, Guennadi Liakhovetski wrote:
Hi Sascha
+
+ ceu0: ceu@0xfe91 {
+ compatible = renesas,sh-mobile-ceu;
+ reg = 0xfe91 0xa0;
+ interrupts = 0x880;
+
+ mclk: master_clock {
+ compatible = renesas,ceu-clock;
+ #clock-cells = 1;
+ clock-frequency = 5000; /* max clock frequency
*/
+ clock-output-names = mclk;
+ };
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ ceu0_1: link@1 {
+ reg = 1; /* local link # */
+ remote = ov772x_1_1; /* remote phandle */
+ bus-width = 8;/* used data lines */
+ data-shift = 0; /* lines 7:0 are used */
+
+ /* If [hv]sync-active are missing, embedded
bt.605 sync is used */
+ hsync-active = 1; /* active high */
+ vsync-active = 1; /* active high */
+ data-active = 1; /* active high */
+ pclk-sample = 1; /* rising */
+ };
+
+ ceu0_0: link@0 {
+ reg = 0;
+ remote = csi2_2;
+ immutable;
+ };
+ };
+ };
+
+ i2c0: i2c@0xfff2 {
+ ...
+ ov772x_1: camera@0x21 {
+ compatible = omnivision,ov772x;
+ reg = 0x21;
+ vddio-supply = regulator1;
+ vddcore-supply = regulator2;
+
+ clock-frequency = 2000;
+ clocks = mclk 0;
+ clock-names = xclk;
+
+ port {
+ /* With 1 link per port no need in addresses */
+ ov772x_1_1: link {
+ bus-width = 8;
+ remote = ceu0_1;
+ hsync-active = 1;
+ vsync-active = 0; /* who came up
with an inverter here?... */
+ data-active = 1;
+ pclk-sample = 1;
+ };
I currently do not understand why these properties are both in the sensor
and in the link. What happens if they conflict? Are inverters assumed
like suggested above? I think the bus can only have a single bus-width,
why allow multiple bus widths here?
Yes, these nodes represent port configuration of each party on a certain
link. And they can differ in certain properties, like - as you correctly
notice - in the case, when there's an inverter on a line. As for other
properties, some of them must be identical, like bus-width, still, they
have to be provided on both ends, because generally drivers have to be
able to perform all the required configuration based only on the
information from their own nodes, without looking at remote partner node
properties.
So the port associated to the ov772x_1 only describes how to configure
the ov772x and it's up to me to make sure that this configuration
matches the partner device. If I don't then it won't work but soc-camera
will happily continue.
Ok, that's good, I thought there would be some kind of matching
mechanism take place here. It may be worth to make this more explicit in
the docs.
+ reg = 0xffc9 0x1000;
+ interrupts = 0x17a0;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@1 {
+ compatible = renesas,csi2c; /* one of CSI2I and
CSI2C */
+ reg = 1; /* CSI-2 PHY #1 of 2:
PHY_S, PHY_M has port address 0, is unused */
+
+ csi2_1: link {
+ clock-lanes = 0;
+ data-lanes = 2, 1;
+ remote = imx074_1;
+ };
+ };
+ port@2 {
+ reg = 2; /* port 2: link to the
CEU */
+
+ csi2_2: link {
+ immutable;
+ remote = ceu0_0;
+ };
+ };
Maybe the example would be clearer if you split it up in two, one simple
case with the csi2_1 - imx074_1 and a more advanced with the link in
between.
With no link between two ports no connection is possible, so, only
examples with links make sense.
I should have said with the renesas,sh-mobile-ceu in between.
So simple example: csi2_1 -l- imx074_1
advanced: csi2_2 -l- ceu -l- ov772x
It took me some
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote: On 10/04/2012 11:59 AM, Steffen Trumtrar wrote: A patch description would be useful for something like this. Yes. Shame on me. diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 ... +Usage in backend + Everything before that point in the file looks fine to me. \o/ Everything after this point in the file seems to be Linux-specific implementation details. Does it really belong in the DT binding documentation, rather than some Linux-specific documentation file? I guess you are right about that. +struct drm_display_mode +=== + + +--+-+--+---+ + | | | | | ↑ + | | | | | | + | | | | | | + +--###--+---+ | I suspect the entire horizontal box above (and the entire vertical box all the way down the left-hand side) should be on the bottom/right instead of top/left. The reason I think this is because all of vsync_start, vsync_end, vdisplay have to be referenced to some known point, which is usually zero or the start of the timing definition, /or/ there would be some value indicating the size of the top marging/porch in order to say where those other values are referenced to. + | # ↑ ↑ ↑# | | | + | # | | |# | | | + | # | | |# | | | + | # | | |# | | | + | # | | |# | | | + | # | | | hdisplay # | | | + | #--++---# | | | + | # | | |# | | | + | # |vsync_start |# | | | + | # | | |# | | | + | # | |vsync_end |# | | | + | # | | |vdisplay# | | | + | # | | |# | | | + | # | | |# | | | + | # | | |# | | | vtotal + | # | | |# | | | + | # | | | hsync_start# | | | + | #--+-+--+--| | | + | # | | |# | | | + | # | | | hsync_end # | | | + | #--+-+--+--| | + | # | | ↓# | | | + +--|#|--+---+ | + | | | | | | | | + | | | | | | | | + | | ↓ | | | | | + +--+-+---+--+---+ | + | | | | | | | + | | | | | | | + | | ↓ | | | ↓ + +--+-+--+---+ + htotal + - diff --git a/drivers/of/of_display_timings.c b/drivers/of/of_display_timings.c +static int parse_property(struct device_node *np, char *name, + struct timing_entry *result) + if (cells == 1) + ret = of_property_read_u32_array(np, name, result-typ, cells); Should that branch not just set result-min/max to typ as well? Presumably it'd prevent
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On 10/04/2012 03:35 PM, Guennadi Liakhovetski wrote: Hi Steffen Sorry for chiming in so late in the game, but I've long been wanting to have a look at this and compare with what we do for V4L2, so, this seems a great opportunity to me:-) On Thu, 4 Oct 2012, Steffen Trumtrar wrote: diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt +timings-subnode +--- + +required properties: + - hactive, vactive: Display resolution + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in + lines + - clock: displayclock in Hz You're going to hate me for this, but eventually we want to actually reference clock objects in our DT bindings. For now, even if you don't want to actually add clock phandles and stuff here, I think, using the standard clock-frequency property would be much better! In a definition of a display timing, we will never need to use the clock binding; the clock binding would be used by the HW module that is generating a timing, not by the timing definition itself. That said, your comment about renaming the property to avoid any kind of conceptual conflict is still quite valid. This is bike-shedding, but pixel-clock might be more in line with typical video mode terminology, although there's certainly preference in DT for using the generic term clock-frequency that you proposed. Either is fine by me. +optional properties: + - hsync-active-high (bool): Hsync pulse is active high + - vsync-active-high (bool): Vsync pulse is active high For the above two we also considered using bool properties but eventually settled down with integer ones: - hsync-active = 1 for active-high and 0 for active low. This has the added advantage of being able to omit this property in the .dts, which then doesn't mean, that the polarity is active low, but rather, that the hsync line is not used on this hardware. So, maybe it would be good to use the same binding here too? I agree. This also covers the case where analog display connectors often use polarity to differentiate similar modes, yet digital connectors often always use a fixed polarity since the receiving device can measure the signal in more complete ways. If the board HW inverts these lines, the same property names can exist in the display controller itself, and the two values XORd together to yield the final output polarity. + - de-active-high (bool): Data-Enable pulse is active high + - pixelclk-inverted (bool): pixelclock is inverted We don't (yet) have a de-active property in V4L, don't know whether we'll ever have to distingsuish between what some datasheets call HREF and HSYNC in DT, but maybe similarly to the above an integer would be preferred. As for pixclk, we call the property pclk-sample and it's also an integer. Thinking about this more: de-active-high is likely to be a board-specific property and hence something in the display controller, not in the mode definition? + - interlaced (bool) Is interlaced a property of the hardware, i.e. of the board? Can the same display controller on one board require interlaced data and on another board - progressive? Interlace is a property of a display mode. It's quite possible for a particular display controller to switch between interlace and progressive output at run-time. For example, reconfiguring the output between 480i, 720p, 1080i, 1080p modes. Admittedly, if you're talking to a built-in LCD display, you're probably always going to be driving the single mode required by the panel, and that mode will likely always be progressive. However, since this binding attempts to describe any display timing, I think we still need this property per mode. BTW, I'm not very familiar with display interfaces, but for interlaced you probably sometimes use a field signal, whose polarity you also want to specify here? We use a field-even-active integer property for it. I think that's a property of the display controller itself, rather than an individual mode, although I'm not 100% certain. My assertion is that the physical interface that the display controller is driving will determine whether embedded or separate sync is used, and in the separate sync case, how the field signal is defined, and that all interlace modes driven over that interface will use the same field signal definition. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
...
+ for_each_child_of_node(timings_np, entry) {
+ struct signal_timing *st;
+
+ st = of_get_display_timing(entry);
+
+ if (!st)
+ continue;
I wonder if that shouldn't be an error?
In the sense of a pr_err not a -EINVAL I presume?! It is a little bit quiet in
case of a faulty spec, that is right.
I did mean return an error; if we try to parse something and can't,
shouldn't we return an error?
I suppose it may be possible to limp on and use whatever subset of modes
could be parsed and drop the others, which is what this code does, but
the code after the loop would definitely return an error if zero timings
were parseable.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On Thu, Oct 04, 2012 at 11:35:35PM +0200, Guennadi Liakhovetski wrote: Hi Steffen Sorry for chiming in so late in the game, but I've long been wanting to have a look at this and compare with what we do for V4L2, so, this seems a great opportunity to me:-) On Thu, 4 Oct 2012, Steffen Trumtrar wrote: Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de --- .../devicetree/bindings/video/display-timings.txt | 222 drivers/of/Kconfig |5 + drivers/of/Makefile|1 + drivers/of/of_display_timings.c| 183 include/linux/of_display_timings.h | 85 5 files changed, 496 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/display-timings.txt create mode 100644 drivers/of/of_display_timings.c create mode 100644 include/linux/of_display_timings.h diff --git a/Documentation/devicetree/bindings/video/display-timings.txt b/Documentation/devicetree/bindings/video/display-timings.txt new file mode 100644 index 000..45e39bd --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timings.txt @@ -0,0 +1,222 @@ +display-timings bindings +== + +display-timings-node + + +required properties: + - none + +optional properties: + - default-timing: the default timing value + +timings-subnode +--- + +required properties: + - hactive, vactive: Display resolution + - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in + lines + - clock: displayclock in Hz You're going to hate me for this, but eventually we want to actually reference clock objects in our DT bindings. For now, even if you don't want to actually add clock phandles and stuff here, I think, using the standard clock-frequency property would be much better! Well, that shouldn't be a big deal, the clock-frequency property I mean :-) + +optional properties: + - hsync-active-high (bool): Hsync pulse is active high + - vsync-active-high (bool): Vsync pulse is active high For the above two we also considered using bool properties but eventually settled down with integer ones: - hsync-active = 1 for active-high and 0 for active low. This has the added advantage of being able to omit this property in the .dts, which then doesn't mean, that the polarity is active low, but rather, that the hsync line is not used on this hardware. So, maybe it would be good to use the same binding here too? Never really thought about it that way. But the argument sounds convincing. + - de-active-high (bool): Data-Enable pulse is active high + - pixelclk-inverted (bool): pixelclock is inverted We don't (yet) have a de-active property in V4L, don't know whether we'll ever have to distingsuish between what some datasheets call HREF and HSYNC in DT, but maybe similarly to the above an integer would be preferred. As for pixclk, we call the property pclk-sample and it's also an integer. + - interlaced (bool) Is interlaced a property of the hardware, i.e. of the board? Can the same display controller on one board require interlaced data and on another board - progressive? BTW, I'm not very familiar with display interfaces, but for interlaced you probably sometimes use a field signal, whose polarity you also want to specify here? We use a field-even-active integer property for it. I don't really know about that; have to collect some info first. Thanks Guennadi Thank you. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 v6] of: add helper to parse display timings
On Fri, Oct 05, 2012 at 10:21:37AM -0600, Stephen Warren wrote:
On 10/05/2012 10:16 AM, Steffen Trumtrar wrote:
On Thu, Oct 04, 2012 at 12:47:16PM -0600, Stephen Warren wrote:
On 10/04/2012 11:59 AM, Steffen Trumtrar wrote:
...
+ for_each_child_of_node(timings_np, entry) {
+ struct signal_timing *st;
+
+ st = of_get_display_timing(entry);
+
+ if (!st)
+ continue;
I wonder if that shouldn't be an error?
In the sense of a pr_err not a -EINVAL I presume?! It is a little bit quiet
in
case of a faulty spec, that is right.
I did mean return an error; if we try to parse something and can't,
shouldn't we return an error?
I suppose it may be possible to limp on and use whatever subset of modes
could be parsed and drop the others, which is what this code does, but
the code after the loop would definitely return an error if zero timings
were parseable.
If a display supports multiple modes, I think it is better to have a working
mode (even if it is not the preferred one) than have none at all.
If there is no mode at all, that should be an error, right.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] media: add a V4L2 OF parser
On 10/05/2012 12:58 PM, Guennadi Liakhovetski wrote: One area that I do not yet completely understand is the i2c bus notifications (or asynchronous loading of i2c modules). I would have expected that using OF the i2c devices are still initialized before the host/bridge driver is initialized. But I gather that's not the case? No, it's not. I'm not sure, whether it depends on the order of devices in the .dts, but, I think, it's better to not have to mandate a certain order and I also seem to have seen devices being registered in different order with the same DT, but I'm not 100% sure about that. The device instantiation (and initialization) order is not something that is supposed to be ensured by a specific device tree source layout, IIUC. The initialization sequence is probably something that is specific to a particular operating system. I checked the device tree compiler but couldn't find if it is free to reorder anything when converting from the human readable device tree to its binary representation. The deferred probing was introduced in Linux to resolve resource inter-dependencies in case of FDT based booting AFAIK. If this deferred probing is a general problem, then I think we need a general solution as well that's part of the v4l2 core. That can be done, perhaps. But we can do it as a next step. As soon as we're happy with the OF implementation as such, we can commit that, possibly leaving soc-camera patches out for now, then we can think where to put async I2C handling. I would really like to see more than one user until we add any core code. No that it couldn't be changed afterwards, but it would be nice to ensure the concepts are right and proven in real life. -- 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 05/14] media: add a V4L2 OF parser
On Fri, Oct 05, 2012 at 08:30:59PM +0200, Sylwester Nawrocki wrote: The deferred probing was introduced in Linux to resolve resource inter-dependencies in case of FDT based booting AFAIK. It's completely unrelated to FDT, it's a general issue. There's no sane way to use hacks like link ordering to resolve boot time dependencies - start getting things like regulators connected to I2C or SPI controllers which may also use GPIOs for some signals and may be parents for other regulators and mapping out the dependency graph becomes unreasonably complicated. Deferred probing is designed to solve this problem by working things out dynamically at runtime. -- 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 10/14] media: soc-camera: support OF cameras
On 09/27/2012 04:07 PM, Guennadi Liakhovetski wrote:
With OF we aren't getting platform data any more. To minimise changes we
create all the missing data ourselves, including compulsory struct
soc_camera_link objects. Host-client linking is now done, based on the OF
data. Media bus numbers also have to be assigned dynamically.
Signed-off-by: Guennadi Liakhovetskig.liakhovet...@gmx.de
---
...
static int soc_camera_i2c_notify(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -1203,13 +1434,20 @@ static int soc_camera_i2c_notify(struct notifier_block
*nb,
struct v4l2_subdev *subdev;
int ret;
- if (client-addr != icl-board_info-addr ||
- client-adapter-nr != icl-i2c_adapter_id)
+ dev_dbg(dev, %s(%lu): %x on %u\n, __func__, action,
+ client-addr, client-adapter-nr);
+
+ if (!soc_camera_i2c_client_match(icl, client))
return NOTIFY_DONE;
switch (action) {
case BUS_NOTIFY_BIND_DRIVER:
client-dev.platform_data = icl;
+ if (icl-of_link) {
+ struct soc_camera_of_client *sofc =
container_of(icl-of_link,
+ struct soc_camera_of_client,
of_link);
+ soc_camera_of_i2c_ifill(sofc, client);
+ }
return NOTIFY_OK;
case BUS_NOTIFY_BOUND_DRIVER:
There is no need for different handling of this event as well ?
Further, there is code like:
adap = i2c_get_adapter(icl-i2c_adapter_id);
which is clearly not going to work in OF case. Could you clarify how
it is supposed to work ?
--
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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Oct 5 19:00:19 CEST 2012 git hash:2425bb3d4016ed95ce83a90b53bd92c7f31091e4 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: WARNINGS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-sh: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mxl111sf: revert patch: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
This reverts commits:
3fd7e4341e04f80e2605f56bbd8cb1e8b027901a
[media] mxl111sf: remove an unused variable
3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a
[media] mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
...as bug behind these is fixed by the DVB USB v2.
Cc: Michael Krufky mkru...@linuxtv.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..fcfe124 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -343,6 +343,7 @@ static int mxl111sf_ep6_streaming_ctrl(struct dvb_frontend
*fe, int onoff)
struct mxl111sf_state *state = fe_to_priv(fe);
struct mxl111sf_adap_state *adap_state = state-adap_state[fe-id];
int ret = 0;
+ u8 tmp;
deb_info(%s(%d)\n, __func__, onoff);
@@ -353,13 +354,15 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
adap_state-ep6_clockphase,
0, 0);
mxl_fail(ret);
-#if 0
} else {
ret = mxl111sf_disable_656_port(state);
mxl_fail(ret);
-#endif
}
+ mxl111sf_read_reg(state, 0x12, tmp);
+ tmp = ~0x04;
+ mxl111sf_write_reg(state, 0x12, tmp);
+
return ret;
}
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mxl111sf: revert patch: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
On Fri, Oct 5, 2012 at 4:44 PM, Antti Palosaari cr...@iki.fi wrote:
This reverts commits:
3fd7e4341e04f80e2605f56bbd8cb1e8b027901a
[media] mxl111sf: remove an unused variable
3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a
[media] mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
...as bug behind these is fixed by the DVB USB v2.
Cc: Michael Krufky mkru...@linuxtv.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..fcfe124 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -343,6 +343,7 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
struct mxl111sf_state *state = fe_to_priv(fe);
struct mxl111sf_adap_state *adap_state = state-adap_state[fe-id];
int ret = 0;
+ u8 tmp;
deb_info(%s(%d)\n, __func__, onoff);
@@ -353,13 +354,15 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
adap_state-ep6_clockphase,
0, 0);
mxl_fail(ret);
-#if 0
} else {
ret = mxl111sf_disable_656_port(state);
mxl_fail(ret);
-#endif
}
+ mxl111sf_read_reg(state, 0x12, tmp);
+ tmp = ~0x04;
+ mxl111sf_write_reg(state, 0x12, tmp);
+
return ret;
}
I disabled that code on purpose - its redundant. please do not apply
this patch.
-Mike
--
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] mxl111sf: revert patch: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
I was wondering if that fix USB host controller reset I am seeing but it
didn't :-(
Anyhow, that should be still fixed.
Oct 5 23:21:05 localhost kernel: [ 216.670807] hub 2-0:1.0: port 2
disabled by hub (EMI?), re-enabling...
Oct 5 23:21:05 localhost kernel: [ 216.670812] usb 2-2: USB
disconnect, device number 6
Oct 5 23:21:05 localhost kernel: [ 216.671022] dvb-usb: recv bulk
message failed: -108
Linux localhost.localdomain 3.5.4-2.fc17.x86_64 #1 SMP Wed Sep 26
21:58:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Same happens for latest 3.6/3.7 too:
Oct 5 23:28:37 localhost kernel: [ 319.837639] usb 2-2: dvb_usb_v2:
'Hauppauge WinTV-Aero-M' successfully initialized and connected
Oct 5 23:28:41 localhost kernel: [ 324.551834] hub 2-0:1.0: port 2
disabled by hub (EMI?), re-enabling...
Oct 5 23:28:41 localhost kernel: [ 324.551849] usb 2-2: USB
disconnect, device number 9
Oct 5 23:28:41 localhost kernel: [ 324.561541] usb 2-2: dvb_usb_v2:
usb_bulk_msg() failed=-71
Linux localhost.localdomain 3.6.0+ #4 SMP Fri Oct 5 23:09:53 EEST 2012
x86_64 x86_64 x86_64 GNU/Linux
I am quite sure it is some problem (race condition) when powering off
and starting frontends. It could be reproduced quite easily making
tuning attempts quickly for frontend 0 and 1. Usually zap -f 1; zap -f
0; zap -f 1; and kaboom, it reboots USB HCI. AMD SB700 USB HCI used.
When you do that fe switching slowly it does not happen.
regards
Antti
On 10/05/2012 11:44 PM, Antti Palosaari wrote:
This reverts commits:
3fd7e4341e04f80e2605f56bbd8cb1e8b027901a
[media] mxl111sf: remove an unused variable
3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a
[media] mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
...as bug behind these is fixed by the DVB USB v2.
Cc: Michael Krufky mkru...@linuxtv.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..fcfe124 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -343,6 +343,7 @@ static int mxl111sf_ep6_streaming_ctrl(struct dvb_frontend
*fe, int onoff)
struct mxl111sf_state *state = fe_to_priv(fe);
struct mxl111sf_adap_state *adap_state = state-adap_state[fe-id];
int ret = 0;
+ u8 tmp;
deb_info(%s(%d)\n, __func__, onoff);
@@ -353,13 +354,15 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
adap_state-ep6_clockphase,
0, 0);
mxl_fail(ret);
-#if 0
} else {
ret = mxl111sf_disable_656_port(state);
mxl_fail(ret);
-#endif
}
+ mxl111sf_read_reg(state, 0x12, tmp);
+ tmp = ~0x04;
+ mxl111sf_write_reg(state, 0x12, tmp);
+
return ret;
}
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mxl111sf: revert patch: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
On 10/05/2012 11:49 PM, Michael Krufky wrote:
On Fri, Oct 5, 2012 at 4:44 PM, Antti Palosaari cr...@iki.fi wrote:
This reverts commits:
3fd7e4341e04f80e2605f56bbd8cb1e8b027901a
[media] mxl111sf: remove an unused variable
3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a
[media] mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
...as bug behind these is fixed by the DVB USB v2.
Cc: Michael Krufky mkru...@linuxtv.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..fcfe124 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -343,6 +343,7 @@ static int mxl111sf_ep6_streaming_ctrl(struct dvb_frontend
*fe, int onoff)
struct mxl111sf_state *state = fe_to_priv(fe);
struct mxl111sf_adap_state *adap_state = state-adap_state[fe-id];
int ret = 0;
+ u8 tmp;
deb_info(%s(%d)\n, __func__, onoff);
@@ -353,13 +354,15 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
adap_state-ep6_clockphase,
0, 0);
mxl_fail(ret);
-#if 0
} else {
ret = mxl111sf_disable_656_port(state);
mxl_fail(ret);
-#endif
}
+ mxl111sf_read_reg(state, 0x12, tmp);
+ tmp = ~0x04;
+ mxl111sf_write_reg(state, 0x12, tmp);
+
return ret;
}
I disabled that code on purpose - its redundant. please do not apply
this patch.
According to comments you have added patch changelog you disabled it doe
to that bug:
[media] mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
Remove unnecessary register access in mxl111sf_ep6_streaming_ctrl()
This code breaks driver operation in kernel 3.3 and later, although
it works properly in 3.2 Disable register access to 0x12 for now.
are you saying there is some other reason than mentioned here? I am
quite 100% sure I fixed that bug in dvb-usb.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mxl111sf: revert patch: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
On Fri, Oct 5, 2012 at 4:54 PM, Antti Palosaari cr...@iki.fi wrote:
On 10/05/2012 11:49 PM, Michael Krufky wrote:
On Fri, Oct 5, 2012 at 4:44 PM, Antti Palosaari cr...@iki.fi wrote:
This reverts commits:
3fd7e4341e04f80e2605f56bbd8cb1e8b027901a
[media] mxl111sf: remove an unused variable
3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a
[media] mxl111sf: fix error on stream stop in
mxl111sf_ep6_streaming_ctrl()
...as bug behind these is fixed by the DVB USB v2.
Cc: Michael Krufky mkru...@linuxtv.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..fcfe124 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -343,6 +343,7 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
struct mxl111sf_state *state = fe_to_priv(fe);
struct mxl111sf_adap_state *adap_state =
state-adap_state[fe-id];
int ret = 0;
+ u8 tmp;
deb_info(%s(%d)\n, __func__, onoff);
@@ -353,13 +354,15 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
adap_state-ep6_clockphase,
0, 0);
mxl_fail(ret);
-#if 0
} else {
ret = mxl111sf_disable_656_port(state);
mxl_fail(ret);
-#endif
}
+ mxl111sf_read_reg(state, 0x12, tmp);
+ tmp = ~0x04;
+ mxl111sf_write_reg(state, 0x12, tmp);
+
return ret;
}
I disabled that code on purpose - its redundant. please do not apply
this patch.
According to comments you have added patch changelog you disabled it doe to
that bug:
[media] mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
Remove unnecessary register access in mxl111sf_ep6_streaming_ctrl()
This code breaks driver operation in kernel 3.3 and later, although
it works properly in 3.2 Disable register access to 0x12 for now.
are you saying there is some other reason than mentioned here? I am quite
100% sure I fixed that bug in dvb-usb.
regards
Antti
--
http://palosaari.fi/
Yup... there is indeed another reason. However, if you want to push a
new patch that just removes the #if 0's, that would be fine. Please
test first, of course.
Just a warning, MH support is broken now and I haven't yet had a
chance to track that down yet... Luckily, merge window rules dont
apply to regressions. (it worked in 3.5 w/ dvb-usb before the forced
change to 'dvb-usb-v2')
I plan to (hopefully) do a full qual this weekend and hopefully push
patches as needed.
-Mike
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
During the clock conversion for mx27 the per4_gate clock was missed to get registered as a dependency of mx2-camera driver. In the old mx27 clock driver we used to have: DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, csi_clk1, per4_clk); ,so does the same in the new clock driver. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- arch/arm/mach-imx/clk-imx27.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c index 3b6b640..5ef0f08 100644 --- a/arch/arm/mach-imx/clk-imx27.c +++ b/arch/arm/mach-imx/clk-imx27.c @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref) clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0); clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0); clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0); + clk_register_clkdev(clk[per4_gate], per, mx2-camera.0); clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc); clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc); clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc); -- 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 2/2] [media]: mx2_camera: Fix regression caused by clock conversion
Since mx27 transitioned to the commmon clock framework in 3.5, the correct way
to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
By not doing so the camera sensor does not probe correctly:
soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
mx2-camera mx2-camera.0: Camera driver attached to camera 0
ov2640 0-0030: Product ID error fb:fb
mx2-camera mx2-camera.0: Camera driver detached from camera 0
mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency:
6650
Adapt the mx2_camera driver to the new clock framework and make it functional
again.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/media/platform/soc_camera/mx2_camera.c | 42
1 file changed, 29 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/soc_camera/mx2_camera.c
b/drivers/media/platform/soc_camera/mx2_camera.c
index 0c0dd74..2c67969 100644
--- a/drivers/media/platform/soc_camera/mx2_camera.c
+++ b/drivers/media/platform/soc_camera/mx2_camera.c
@@ -272,8 +272,9 @@ struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
struct soc_camera_device *icd;
- struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
-
+ struct clk *clk_emma_ahb, *clk_emma_ipg;
+ struct clk *clk_csi_ahb, *clk_csi_per;
+
unsigned intirq_csi, irq_emma;
void __iomem*base_csi, *base_emma;
unsigned long base_dma;
@@ -435,7 +436,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev
*pcdev)
{
unsigned long flags;
- clk_disable_unprepare(pcdev-clk_csi);
+ clk_disable_unprepare(pcdev-clk_csi_ahb);
+ clk_disable_unprepare(pcdev-clk_csi_per);
writel(0, pcdev-base_csi + CSICR1);
if (cpu_is_mx27()) {
writel(0, pcdev-base_emma + PRP_CNTL);
@@ -463,7 +465,11 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
if (pcdev-icd)
return -EBUSY;
- ret = clk_prepare_enable(pcdev-clk_csi);
+ ret = clk_prepare_enable(pcdev-clk_csi_ahb);
+ if (ret 0)
+ return ret;
+
+ ret = clk_prepare_enable(pcdev-clk_csi_per);
if (ret 0)
return ret;
@@ -1736,13 +1742,21 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit;
}
- pcdev-clk_csi = clk_get(pdev-dev, ahb);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
+ pcdev-clk_csi_ahb = clk_get(pdev-dev, ahb);
+ if (IS_ERR(pcdev-clk_csi_ahb)) {
+ dev_err(pdev-dev, Could not get csi ahb clock\n);
+ err = PTR_ERR(pcdev-clk_csi_ahb);
goto exit_kfree;
}
+ pcdev-clk_csi_per = clk_get(pdev-dev, per);
+ if (IS_ERR(pcdev-clk_csi_per)) {
+ dev_err(pdev-dev, Could not get csi per clock\n);
+ err = PTR_ERR(pcdev-clk_csi_per);
+ goto exit_kfree;
+ }
+
+
pcdev-res_csi = res_csi;
pcdev-pdata = pdev-dev.platform_data;
if (pcdev-pdata) {
@@ -1750,12 +1764,12 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
pcdev-platform_flags = pcdev-pdata-flags;
- rate = clk_round_rate(pcdev-clk_csi, pcdev-pdata-clk * 2);
+ rate = clk_round_rate(pcdev-clk_csi_per, pcdev-pdata-clk *
2);
if (rate = 0) {
err = -ENODEV;
goto exit_dma_free;
}
- err = clk_set_rate(pcdev-clk_csi, rate);
+ err = clk_set_rate(pcdev-clk_csi_per, rate);
if (err 0)
goto exit_dma_free;
}
@@ -1827,7 +1841,7 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit_free_emma;
dev_info(pdev-dev, MX2 Camera (CSI) driver probed, clock frequency:
%ld\n,
- clk_get_rate(pcdev-clk_csi));
+ clk_get_rate(pcdev-clk_csi_per));
return 0;
@@ -1851,7 +1865,8 @@ exit_iounmap:
exit_release:
release_mem_region(res_csi-start, resource_size(res_csi));
exit_dma_free:
- clk_put(pcdev-clk_csi);
+ clk_put(pcdev-clk_csi_per);
+ clk_put(pcdev-clk_csi_ahb);
exit_kfree:
kfree(pcdev);
exit:
@@ -1865,7 +1880,8 @@ static int __devexit mx2_camera_remove(struct
platform_device *pdev)
struct mx2_camera_dev, soc_host);
struct resource *res;
- clk_put(pcdev-clk_csi);
+ clk_put(pcdev-clk_csi_per);
+ clk_put(pcdev-clk_csi_ahb);
if (cpu_is_mx25())
free_irq(pcdev-irq_csi, pcdev);
if (cpu_is_mx27())
--
1.7.9.5
--
To unsubscribe from this list: send
[PATCH] cxd2820r: silence compiler warning
drivers/media/dvb-frontends/cxd2820r_core.c: In function 'cxd2820r_attach':
drivers/media/dvb-frontends/cxd2820r_core.c:691:10: warning: unused variable
'gpio' [-Wunused-variable]
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/cxd2820r_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 4264864..9b658c1 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -688,7 +688,7 @@ struct dvb_frontend *cxd2820r_attach(const struct
cxd2820r_config *cfg,
{
struct cxd2820r_priv *priv;
int ret;
- u8 tmp, gpio[GPIO_COUNT];
+ u8 tmp;
priv = kzalloc(sizeof(struct cxd2820r_priv), GFP_KERNEL);
if (!priv) {
@@ -735,6 +735,7 @@ struct dvb_frontend *cxd2820r_attach(const struct
cxd2820r_config *cfg,
* Use static GPIO configuration if GPIOLIB is undefined.
* This is fallback condition.
*/
+ u8 gpio[GPIO_COUNT];
gpio[0] = (*gpio_chip_base 0) 0x07;
gpio[1] = (*gpio_chip_base 3) 0x07;
gpio[2] = 0;
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mxl111sf: revert patch: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
On 10/05/2012 11:58 PM, Michael Krufky wrote:
On Fri, Oct 5, 2012 at 4:54 PM, Antti Palosaari cr...@iki.fi wrote:
On 10/05/2012 11:49 PM, Michael Krufky wrote:
On Fri, Oct 5, 2012 at 4:44 PM, Antti Palosaari cr...@iki.fi wrote:
This reverts commits:
3fd7e4341e04f80e2605f56bbd8cb1e8b027901a
[media] mxl111sf: remove an unused variable
3be5bb71fbf18f83cb88b54a62a78e03e5a4f30a
[media] mxl111sf: fix error on stream stop in
mxl111sf_ep6_streaming_ctrl()
...as bug behind these is fixed by the DVB USB v2.
Cc: Michael Krufky mkru...@linuxtv.org
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..fcfe124 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -343,6 +343,7 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
struct mxl111sf_state *state = fe_to_priv(fe);
struct mxl111sf_adap_state *adap_state =
state-adap_state[fe-id];
int ret = 0;
+ u8 tmp;
deb_info(%s(%d)\n, __func__, onoff);
@@ -353,13 +354,15 @@ static int mxl111sf_ep6_streaming_ctrl(struct
dvb_frontend *fe, int onoff)
adap_state-ep6_clockphase,
0, 0);
mxl_fail(ret);
-#if 0
} else {
ret = mxl111sf_disable_656_port(state);
mxl_fail(ret);
-#endif
}
+ mxl111sf_read_reg(state, 0x12, tmp);
+ tmp = ~0x04;
+ mxl111sf_write_reg(state, 0x12, tmp);
+
return ret;
}
I disabled that code on purpose - its redundant. please do not apply
this patch.
According to comments you have added patch changelog you disabled it doe to
that bug:
[media] mxl111sf: fix error on stream stop in mxl111sf_ep6_streaming_ctrl()
Remove unnecessary register access in mxl111sf_ep6_streaming_ctrl()
This code breaks driver operation in kernel 3.3 and later, although
it works properly in 3.2 Disable register access to 0x12 for now.
are you saying there is some other reason than mentioned here? I am quite
100% sure I fixed that bug in dvb-usb.
regards
Antti
--
http://palosaari.fi/
Yup... there is indeed another reason. However, if you want to push a
new patch that just removes the #if 0's, that would be fine. Please
test first, of course.
Just a warning, MH support is broken now and I haven't yet had a
chance to track that down yet... Luckily, merge window rules dont
apply to regressions. (it worked in 3.5 w/ dvb-usb before the forced
change to 'dvb-usb-v2')
I plan to (hopefully) do a full qual this weekend and hopefully push
patches as needed.
I cannot test it properly with DVB-T as EP6 is not used for DVB-T. Only
some stupid dry rans. Did you saw yourself dvb-usb: error while
stopping stream. ? If yes, then you could likely test it. But in any
case, you know what that reg bit is and if it is necessary or not.
Likely not important.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx releases I2C adapter earlier than demod/tuner/sec
That is one bug fix could be nice to fix. It is potential change it Oopses Kernel when DVB sub-driver release is called with I2C-adaper == NULL. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx #0: submit of audio urb failed
That one is the other bug what I see when I plug em28xx device with analog support. After that error is seen it is not possible to unload modules until device is removed physically. I am quite sure that error hasn't been there very long. Before that error happens there is other bug - it mutes whole computer volume for a while. I asked that earlier too on IRC and it was said that it is likely ALSA bug. So it could not be fixed. But how about adding some option for dropping whole ALSA module as it is not even needed in many cases? The continuous crashes, when plug / unplug, I reported earlier are now gone. Those disappeared when DRX-K asynchronous firmware loading was removed. I suspect it was a DRX-K bug. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.7] small cxd2820r correction
The following changes since commit e32087bcc4daa29fd30cf7742ef9b522625a1690: [media] davinci: vpbe: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS (2012-10-05 14:29:20 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git for_v3.7_mauro-6 for you to fetch changes up to 345169a767696a1e54168d9f8a8581faeca23327: cxd2820r: silence compiler warning (2012-10-06 02:11:14 +0300) Antti Palosaari (1): cxd2820r: silence compiler warning drivers/media/dvb-frontends/cxd2820r_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: hvr-1600 fails frequently on multiple recordings
Have you checked on the Ubuntu Forums for any information about this? There's a thread about 0-byte recordings there, which might have some solutions for you. I had the same issue with analog recording a while back, and found that in my case, it was due to having a second hard drive listed as a storage directory. If the hard drive didn't spin up quick enough, the recording failed. Here's a link to the thread on their site: http://ubuntuforums.org/showthread.php?t=1687846 Hope this helps, and have a great day:) Patrick. On Wed, 2012-10-03 at 20:44 -0400, Brian J. Murrell wrote: I have a fairly new HVR-1600 which I have seen fail quite a number of times now when it's asked to record more than one channel on a clearqam multiplex. This time it was 3 recordings at once. There's nothing at all in the kernel ring buffer, just mythtv reports a failed recording. Usually one of the files being recorded to will only be 376 bytes long and the rest will be 0 bytes. I am running ubuntu's 3.2.0-27-generic kernel with what looks like a 1.5.1 cx18 driver. The card is either a: 14f1:5b7a Conexant Systems, Inc. CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast Audio Decoder or a: :0016 Internext Compression Inc iTVC16 (CX23416) Video Decoder (rev 01) Sorry. I don't recall which is which any more. But I really need to figure this out since failed recordings is causing all kinds of disappointment around here. I'm really at the end of my rope with it. Tomorrow morning I am going to demote this card to secondary duty and promote my HVR-950Q to primary duty since I never had this kind of grief with it. But even in secondary duty, it could very well be called upon to record multiple clearqam channels simultaneously so I would really like to get this figured out. Any ideas? Cheers, b. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] A driver for Si476x series of chips
This is a second version of the patchset originaly posted here: https://lkml.org/lkml/2012/9/13/590 To save everyone's time I'll repost the original description of it: This patchset contains a driver for a Silicon Laboratories 476x series of radio tuners. The driver itself is implemented as an MFD devices comprised of three parts: 1. Core device that provides all the other devices with basic functionality and locking scheme. 2. Radio device that translates between V4L2 subsystem requests into Core device commands. 3. Codec device that does similar to the earlier described task, but for ALSA SoC subsystem. This driver has been tested to work in two different sytems: 1. A custom Tegra-based ARM board(design is based on Harmony board) running linux kernel 3.1.10 kernel 2. A standalone USB-connected board that has a dedicated Cortex M3 working as a transparent USB to I2C bridge which was connected to a off-the-shelf x86-64 laptop running Ubuntu with 3.2.0 kernel. As far as SubmitChecklist is concerned following criteria should be satisfied: 2b, 3, 5, 7, 9, 10 Now it is made against git.linuxtv.org/media_tree.git repository instead of linux-stable. I tried to take into account all the flaws pointed by Mark and Hans, but since the amount of changes I had to made was not trivial I wouldn't be surprized if I missed something that was shown to me. I would like to appologize in advance if this patchset contains some unfixed problems pointed out in the previous version. Andrey Smirnov (6): Add header files and Kbuild plumbing for SI476x MFD core Add the main bulk of core driver for SI476x code Add commands abstraction layer for SI476X MFD Add chip properties handling code for SI476X MFD Add a V4L2 driver for SI476X MFD Add a codec driver for SI476X MFD drivers/media/radio/Kconfig| 17 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-si476x.c | 1159 drivers/mfd/Kconfig| 14 + drivers/mfd/Makefile |3 + drivers/mfd/si476x-cmd.c | 1493 drivers/mfd/si476x-i2c.c | 974 +++ drivers/mfd/si476x-prop.c | 477 include/linux/mfd/si476x-core.h| 529 + include/media/si476x.h | 449 +++ sound/soc/codecs/Kconfig |4 + sound/soc/codecs/Makefile |2 + sound/soc/si476x.c | 255 ++ 13 files changed, 5377 insertions(+) create mode 100644 drivers/media/radio/radio-si476x.c create mode 100644 drivers/mfd/si476x-cmd.c create mode 100644 drivers/mfd/si476x-i2c.c create mode 100644 drivers/mfd/si476x-prop.c create mode 100644 include/linux/mfd/si476x-core.h create mode 100644 include/media/si476x.h create mode 100644 sound/soc/si476x.c -- 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 v2 6/6] Add a codec driver for SI476X MFD
This commit add a sound codec driver for Silicon Laboratories 476x
series of AM/FM radio chips.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/si476x.c | 255 +
3 files changed, 261 insertions(+)
create mode 100644 sound/soc/codecs/si476x.c
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 9f8e859..37b2911 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -53,6 +53,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_PCM3008
select SND_SOC_RT5631 if I2C
select SND_SOC_SGTL5000 if I2C
+ select SND_SOC_SI476X if MFD_SI476X_CORE
select SND_SOC_SN95031 if INTEL_SCU_IPC
select SND_SOC_SPDIF
select SND_SOC_SSM2602 if SND_SOC_I2C_AND_SPI
@@ -272,6 +273,9 @@ config SND_SOC_RT5631
config SND_SOC_SGTL5000
tristate
+config SND_SOC_SI476X
+ tristate
+
config SND_SOC_SIGMADSP
tristate
select CRC32
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 34148bb..d9ed4e4 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -44,6 +44,7 @@ snd-soc-sgtl5000-objs := sgtl5000.o
snd-soc-alc5623-objs := alc5623.o
snd-soc-alc5632-objs := alc5632.o
snd-soc-sigmadsp-objs := sigmadsp.o
+snd-soc-si476x-objs := si476x.o
snd-soc-sn95031-objs := sn95031.o
snd-soc-spdif-tx-objs := spdif_transciever.o
snd-soc-spdif-rx-objs := spdif_receiver.o
@@ -161,6 +162,7 @@ obj-$(CONFIG_SND_SOC_PCM3008) += snd-soc-pcm3008.o
obj-$(CONFIG_SND_SOC_RT5631) += snd-soc-rt5631.o
obj-$(CONFIG_SND_SOC_SGTL5000) += snd-soc-sgtl5000.o
obj-$(CONFIG_SND_SOC_SIGMADSP) += snd-soc-sigmadsp.o
+obj-$(CONFIG_SND_SOC_SI476X) += snd-soc-si476x.o
obj-$(CONFIG_SND_SOC_SN95031) +=snd-soc-sn95031.o
obj-$(CONFIG_SND_SOC_SPDIF)+= snd-soc-spdif-rx.o snd-soc-spdif-tx.o
obj-$(CONFIG_SND_SOC_SSM2602) += snd-soc-ssm2602.o
diff --git a/sound/soc/codecs/si476x.c b/sound/soc/codecs/si476x.c
new file mode 100644
index 000..38145ba
--- /dev/null
+++ b/sound/soc/codecs/si476x.c
@@ -0,0 +1,255 @@
+#include linux/module.h
+#include linux/slab.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/initval.h
+
+#include linux/i2c.h
+
+#include linux/mfd/si476x-core.h
+
+enum si476x_audio_registers {
+ SI476X_DIGITAL_IO_OUTPUT_FORMAT = 0x0203,
+ SI476X_DIGITAL_IO_OUTPUT_SAMPLE_RATE= 0x0202,
+};
+
+enum si476x_digital_io_output_format {
+ SI476X_DIGITAL_IO_SLOT_SIZE_SHIFT = 11,
+ SI476X_DIGITAL_IO_SAMPLE_SIZE_SHIFT = 8,
+};
+
+#define SI476X_DIGITAL_IO_OUTPUT_WIDTH_MASK((0b111
SI476X_DIGITAL_IO_SLOT_SIZE_SHIFT) | \
+ (0b111
SI476X_DIGITAL_IO_SAMPLE_SIZE_SHIFT))
+#define SI476X_DIGITAL_IO_OUTPUT_FORMAT_MASK (0b110)
+
+enum si476x_daudio_formats {
+ SI476X_DAUDIO_MODE_I2S = (0x0 1),
+ SI476X_DAUDIO_MODE_DSP_A= (0x6 1),
+ SI476X_DAUDIO_MODE_DSP_B= (0x7 1),
+ SI476X_DAUDIO_MODE_LEFT_J = (0x8 1),
+ SI476X_DAUDIO_MODE_RIGHT_J = (0x9 1),
+
+ SI476X_DAUDIO_MODE_IB = (1 5),
+ SI476X_DAUDIO_MODE_IF = (1 6),
+};
+
+enum si476x_pcm_format {
+ SI476X_PCM_FORMAT_S8= 2,
+ SI476X_PCM_FORMAT_S16_LE= 4,
+ SI476X_PCM_FORMAT_S20_3LE = 5,
+ SI476X_PCM_FORMAT_S24_LE= 6,
+};
+
+static unsigned int si476x_codec_read(struct snd_soc_codec *codec,
+ unsigned int reg)
+{
+ int err;
+ struct si476x_core *core = codec-control_data;
+
+ si476x_core_lock(core);
+ err = si476x_core_cmd_get_property(core, reg);
+ si476x_core_unlock(core);
+
+ return err;
+}
+
+static int si476x_codec_write(struct snd_soc_codec *codec,
+ unsigned int reg, unsigned int val)
+{
+ int err;
+ struct si476x_core *core = codec-control_data;
+
+ si476x_core_lock(core);
+ err = si476x_core_cmd_set_property(core, reg, val);
+ si476x_core_unlock(core);
+
+ return err;
+}
+
+static int si476x_codec_set_dai_fmt(struct snd_soc_dai *codec_dai,
+ unsigned int fmt)
+{
+ int err;
+ u16 format = 0;
+
+ if ((fmt SND_SOC_DAIFMT_MASTER_MASK) != SND_SOC_DAIFMT_CBS_CFS)
+ return -EINVAL;
+
+ switch (fmt SND_SOC_DAIFMT_FORMAT_MASK) {
+ case SND_SOC_DAIFMT_DSP_A:
+ format |= SI476X_DAUDIO_MODE_DSP_A;
+ break;
+ case SND_SOC_DAIFMT_DSP_B:
+ format |= SI476X_DAUDIO_MODE_DSP_B;
+ break;
+ case SND_SOC_DAIFMT_I2S:
+ format |= SI476X_DAUDIO_MODE_I2S;
+ break;
+ case SND_SOC_DAIFMT_RIGHT_J:
+
[PATCH v2 3/6] Add commands abstraction layer for SI476X MFD
This patch adds all the functions used for exchanging commands with the chip. Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net --- drivers/mfd/si476x-cmd.c | 1493 ++ 1 file changed, 1493 insertions(+) create mode 100644 drivers/mfd/si476x-cmd.c diff --git a/drivers/mfd/si476x-cmd.c b/drivers/mfd/si476x-cmd.c new file mode 100644 index 000..f11cf58 --- /dev/null +++ b/drivers/mfd/si476x-cmd.c @@ -0,0 +1,1493 @@ +/* + * include/media/si476x-cmd.c -- Subroutines implementing command + * protocol of si476x series of chips + * + * Copyright (C) 2012 Innovative Converged Devices(ICD) + * + * Author: Andrey Smirnov andrey.smir...@convergeddevices.net + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ +#include linux/module.h +#include linux/completion.h +#include linux/delay.h +#include linux/atomic.h +#include linux/i2c.h +#include linux/device.h +#include linux/gpio.h +#include linux/videodev2.h + +#include media/si476x.h +#include linux/mfd/si476x-core.h + +#define msb(x) ((u8)((u16) x 8)) +#define lsb(x) ((u8)((u16) x 0x00FF)) + + + +#define CMD_POWER_UP 0x01 +#define CMD_POWER_UP_A10_NRESP 1 +#define CMD_POWER_UP_A10_NARGS 5 + +#define CMD_POWER_UP_A20_NRESP 1 +#define CMD_POWER_UP_A20_NARGS 5 + +#define POWER_UP_DELAY_MS 110 + +#define CMD_POWER_DOWN 0x11 +#define CMD_POWER_DOWN_A10_NRESP 1 + +#define CMD_POWER_DOWN_A20_NRESP 1 +#define CMD_POWER_DOWN_A20_NARGS 1 + +#define CMD_FUNC_INFO 0x12 +#define CMD_FUNC_INFO_NRESP7 + +#define CMD_SET_PROPERTY 0x13 +#define CMD_SET_PROPERTY_NARGS 5 +#define CMD_SET_PROPERTY_NRESP 1 + +#define CMD_GET_PROPERTY 0x14 +#define CMD_GET_PROPERTY_NARGS 3 +#define CMD_GET_PROPERTY_NRESP 4 + +#define CMD_AGC_STATUS 0x17 +#define CMD_AGC_STATUS_NRESP_A10 2 +#define CMD_AGC_STATUS_NRESP_A206 + +#define PIN_CFG_BYTE(x) (0x7F (x)) +#define CMD_DIG_AUDIO_PIN_CFG 0x18 +#define CMD_DIG_AUDIO_PIN_CFG_NARGS4 +#define CMD_DIG_AUDIO_PIN_CFG_NRESP5 + +#define CMD_ZIF_PIN_CFG0x19 +#define CMD_ZIF_PIN_CFG_NARGS 4 +#define CMD_ZIF_PIN_CFG_NRESP 5 + +#define CMD_IC_LINK_GPO_CTL_PIN_CFG0x1A +#define CMD_IC_LINK_GPO_CTL_PIN_CFG_NARGS 4 +#define CMD_IC_LINK_GPO_CTL_PIN_CFG_NRESP 5 + +#define CMD_ANA_AUDIO_PIN_CFG 0x1B +#define CMD_ANA_AUDIO_PIN_CFG_NARGS1 +#define CMD_ANA_AUDIO_PIN_CFG_NRESP2 + +#define CMD_INTB_PIN_CFG 0x1C +#define CMD_INTB_PIN_CFG_NARGS 2 +#define CMD_INTB_PIN_CFG_A10_NRESP 6 +#define CMD_INTB_PIN_CFG_A20_NRESP 3 + +#define CMD_FM_TUNE_FREQ 0x30 +#define CMD_FM_TUNE_FREQ_A10_NARGS 5 +#define CMD_FM_TUNE_FREQ_A20_NARGS 3 +#define CMD_FM_TUNE_FREQ_NRESP 1 + +#define CMD_FM_RSQ_STATUS 0x32 + +#define CMD_FM_RSQ_STATUS_A10_NARGS1 +#define CMD_FM_RSQ_STATUS_A10_NRESP17 +#define CMD_FM_RSQ_STATUS_A30_NARGS1 +#define CMD_FM_RSQ_STATUS_A30_NRESP23 + + +#define CMD_FM_SEEK_START 0x31 +#define CMD_FM_SEEK_START_NARGS1 +#define CMD_FM_SEEK_START_NRESP1 + +#define CMD_FM_RDS_STATUS 0x36 +#define CMD_FM_RDS_STATUS_NARGS1 +#define CMD_FM_RDS_STATUS_NRESP16 + +#define CMD_FM_RDS_BLOCKCOUNT 0x37 +#define CMD_FM_RDS_BLOCKCOUNT_NARGS1 +#define CMD_FM_RDS_BLOCKCOUNT_NRESP8 + +#define CMD_FM_PHASE_DIVERSITY 0x38 +#define CMD_FM_PHASE_DIVERSITY_NARGS 1 +#define CMD_FM_PHASE_DIVERSITY_NRESP 1 + +#define CMD_FM_PHASE_DIV_STATUS0x39 +#define CMD_FM_PHASE_DIV_STATUS_NRESP 2 + +#define CMD_AM_TUNE_FREQ 0x40 +#define CMD_AM_TUNE_FREQ_NARGS 3 +#define CMD_AM_TUNE_FREQ_NRESP 1 + +#define CMD_AM_RSQ_STATUS 0x42 +#define
[PATCH v2 5/6] Add a V4L2 driver for SI476X MFD
This commit adds a driver that exposes all the radio related
functionality of the Si476x series of chips via the V4L2 subsystem.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/media/radio/Kconfig| 17 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-si476x.c | 1153
3 files changed, 1171 insertions(+)
create mode 100644 drivers/media/radio/radio-si476x.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 8090b87..3c79d09 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -16,6 +16,23 @@ config RADIO_SI470X
bool Silicon Labs Si470x FM Radio Receiver support
depends on VIDEO_V4L2
+config RADIO_SI476X
+ tristate Silicon Laboratories Si476x I2C FM Radio
+ depends on I2C VIDEO_V4L2
+ select MFD_CORE
+ select MFD_SI476X_CORE
+ select SND_SOC_SI476X
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to v4l2 programs may be found at
+ file:Documentation/video4linux/API.html.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-si476x.
+
source drivers/media/radio/si470x/Kconfig
config USB_MR800
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index c03ce4f..c4618e0 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o
obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o
obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o
+obj-$(CONFIG_RADIO_SI476X) += radio-si476x.o
obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o
obj-$(CONFIG_USB_DSBR) += dsbr100.o
obj-$(CONFIG_RADIO_SI470X) += si470x/
diff --git a/drivers/media/radio/radio-si476x.c
b/drivers/media/radio/radio-si476x.c
new file mode 100644
index 000..2d943da
--- /dev/null
+++ b/drivers/media/radio/radio-si476x.c
@@ -0,0 +1,1153 @@
+#include linux/module.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/slab.h
+#include linux/atomic.h
+#include linux/videodev2.h
+#include linux/mutex.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-ctrls.h
+#include media/v4l2-event.h
+#include media/v4l2-device.h
+
+#include linux/mfd/si476x-core.h
+
+#define FM_FREQ_RANGE_LOW 6400
+#define FM_FREQ_RANGE_HIGH 10800
+
+#define AM_FREQ_RANGE_LOW52
+#define AM_FREQ_RANGE_HIGH 3000
+
+#define PWRLINEFLTR (1 8)
+
+#define FREQ_MUL (1000 / 625)
+
+#define DRIVER_NAME si476x-radio
+#define DRIVER_CARD SI476x AM/FM Receiver
+
+enum si476x_freq_bands {
+ SI476X_BAND_FM,
+ SI476X_BAND_AM,
+};
+
+static const struct v4l2_frequency_band si476x_bands[] = {
+ [SI476X_BAND_FM] = {
+ .type = V4L2_TUNER_RADIO,
+ .index = SI476X_BAND_FM,
+ .capability = V4L2_TUNER_CAP_LOW
+ | V4L2_TUNER_CAP_STEREO
+ | V4L2_TUNER_CAP_RDS
+ | V4L2_TUNER_CAP_RDS_BLOCK_IO
+ | V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 64 * FREQ_MUL,
+ .rangehigh = 108 * FREQ_MUL,
+ .modulation = V4L2_BAND_MODULATION_FM,
+ },
+ [SI476X_BAND_AM] = {
+ .type = V4L2_TUNER_RADIO,
+ .index = SI476X_BAND_AM,
+ .capability = V4L2_TUNER_CAP_LOW |
V4L2_TUNER_CAP_FREQ_BANDS,
+ .rangelow = 0.52 * FREQ_MUL,
+ .rangehigh = 30 * FREQ_MUL,
+ .modulation = V4L2_BAND_MODULATION_AM,
+ },
+};
+
+#define PRIVATE_CTL_IDX(x) (x - V4L2_CID_PRIVATE_BASE)
+
+static int si476x_s_ctrl(struct v4l2_ctrl *ctrl);
+
+static const char * const deemphasis[] = {
+ 75 us,
+ 50 us,
+};
+
+static const struct v4l2_ctrl_ops si476x_ctrl_ops = {
+ .s_ctrl = si476x_s_ctrl,
+};
+
+static const struct v4l2_ctrl_config si476x_ctrls[] = {
+ /*
+ Tuning parameters
+ 'max tune errors' is shared for both AM/FM mode of operation
+ */
+ {
+ .ops= si476x_ctrl_ops,
+ .id = SI476X_CID_RSSI_THRESHOLD,
+ .name = valid rssi threshold,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .min= -128,
+ .max= 127,
+ .step = 1,
+ },
+ {
+ .ops= si476x_ctrl_ops,
+ .id = SI476X_CID_SNR_THRESHOLD,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = valid snr threshold,
+ .min= -128,
+ .max= 127,
+
[PATCH v2 1/6] Add header files and Kbuild plumbing for SI476x MFD core
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.
The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two other drivers that represent radio and audio
codec subsystems of the chip.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile|3 +
include/linux/mfd/si476x-core.h | 529 +++
include/media/si476x.h | 449 +
4 files changed, 995 insertions(+)
create mode 100644 include/linux/mfd/si476x-core.h
create mode 100644 include/media/si476x.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b1a1462..3fab06d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -895,6 +895,20 @@ config MFD_WL1273_CORE
driver connects the radio-wl1273 V4L2 module and the wl1273
audio codec.
+config MFD_SI476X_CORE
+ tristate Support for Silicon Laboratories 4761/64/68 AM/FM radio.
+ depends on I2C
+ select MFD_CORE
+ default n
+ help
+ This is the core driver for the SI476x series of AM/FM radio. This MFD
+ driver connects the radio-si476x V4L2 module and the si476x
+ audio codec.
+
+ To compile this driver as a module, choose M here: the
+ module will be called si476x-core.
+
+
config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 79dd22d..942257b 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -132,3 +132,6 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+
+si476x-core-objs := si476x-cmd.o si476x-prop.o si476x-i2c.o
+obj-$(CONFIG_MFD_SI476X_CORE) += si476x-core.o
diff --git a/include/linux/mfd/si476x-core.h b/include/linux/mfd/si476x-core.h
new file mode 100644
index 000..eb6f52a
--- /dev/null
+++ b/include/linux/mfd/si476x-core.h
@@ -0,0 +1,529 @@
+/*
+ * include/media/si476x-core.h -- Common definitions for si476x core
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef SI476X_CORE_H
+#define SI476X_CORE_H
+
+#include linux/kfifo.h
+#include linux/atomic.h
+#include linux/i2c.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/videodev2.h
+
+#include media/si476x.h
+
+#ifdef DEBUG
+#define DBG_BUFFER(device, header, buffer, bcount) \
+ do {\
+ dev_info((device), header); \
+ print_hex_dump_bytes(,\
+DUMP_PREFIX_OFFSET,\
+buffer, bcount); \
+ } while (0)
+#else
+#define DBG_BUFFER(device, header, buffer, bcount) \
+ do {} while (0)
+#endif
+
+enum si476x_freq_suppoted_chips {
+ SI476X_CHIP_SI4761 = 1,
+ SI476X_CHIP_SI4762,
+ SI476X_CHIP_SI4763,
+ SI476X_CHIP_SI4764,
+ SI476X_CHIP_SI4768,
+ SI476X_CHIP_SI4769,
+};
+
+enum si476x_mfd_cells {
+ SI476X_RADIO_CELL = 0,
+ SI476X_CODEC_CELL,
+ SI476X_MFD_CELLS,
+};
+
+
+/**
+ * enum si476x_power_state - possible power state of the si476x
+ * device.
+ *
+ * @SI476X_POWER_DOWN: In this state all regulators are turned off
+ * and the reset line is pulled low. The device is completely
+ * inactive.
+ * @SI476X_POWER_UP_FULL: In this state all the power regualtors are
+ * turned on, reset line pulled high, IRQ line is enabled(polling is
+ * active for polling use scenario) and device is turned on with
+ * POWER_UP command. The device is ready to be used.
+ * @SI476X_POWER_INCONSISTENT: This state indicates that previous
+ * power down was inconsisten meaning some of he regulators wer not
+ * turned down and thus the consequent use of the device, without
+ * power-cycling it is impossible.
+ */
+enum si476x_power_state {
+
[PATCH v2 4/6] Add chip properties handling code for SI476X MFD
This patch adds code related to manipulation of the properties of
SI476X chips.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/mfd/si476x-prop.c | 477 +
1 file changed, 477 insertions(+)
create mode 100644 drivers/mfd/si476x-prop.c
diff --git a/drivers/mfd/si476x-prop.c b/drivers/mfd/si476x-prop.c
new file mode 100644
index 000..d633c08
--- /dev/null
+++ b/drivers/mfd/si476x-prop.c
@@ -0,0 +1,477 @@
+/*
+ * include/media/si476x-prop.c -- Subroutines to manipulate with
+ * properties of si476x chips
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ */
+#include linux/module.h
+
+#include media/si476x.h
+#include linux/mfd/si476x-core.h
+
+
+enum si476x_common_receiver_properties {
+ SI476X_PROP_INT_CTL_ENABLE = 0x,
+ SI476X_PROP_DIGITAL_IO_INPUT_SAMPLE_RATE= 0x0200,
+ SI476X_PROP_DIGITAL_IO_INPUT_FORMAT = 0x0201,
+ SI476X_PROP_DIGITAL_IO_OUTPUT_SAMPLE_RATE = 0x0202,
+ SI476X_PROP_DIGITAL_IO_OUTPUT_FORMAT= 0x0203,
+
+ SI476X_PROP_AUDIO_ANALOG_VOLUME = 0x0300,
+ SI476X_PROP_AUDIO_MUTE = 0x0301,
+
+ SI476X_PROP_ZIF_OUTPUT_CFG = 0x0600,
+
+ SI476X_PROP_SEEK_BAND_BOTTOM= 0x1100,
+ SI476X_PROP_SEEK_BAND_TOP = 0x1101,
+ SI476X_PROP_SEEK_FREQUENCY_SPACING = 0x1102,
+
+ SI476X_PROP_VALID_MAX_TUNE_ERROR= 0x2000,
+ SI476X_PROP_VALID_SNR_THRESHOLD = 0x2003,
+
+ SI476X_PROP_VALID_RSSI_THRESHOLD= 0x2004,
+};
+
+enum si476x_am_receiver_properties {
+ SI476X_PROP_AUDIO_PWR_LINE_FILTER = 0x0303,
+};
+
+enum si476x_fm_receiver_properties {
+ SI476X_PROP_AUDIO_DEEMPHASIS= 0x0302,
+
+ SI476X_PROP_FM_VALID_RSSI_TIME = 0x2001,
+ SI476X_PROP_FM_VALID_SNR_TIME = 0x2002,
+ SI476X_PROP_FM_VALID_AF_TIME= 0x2007,
+
+ SI476X_PROP_FM_RDS_INTERRUPT_SOURCE = 0x4000,
+ SI476X_PROP_FM_RDS_INTERRUPT_FIFO_COUNT = 0x4001,
+ SI476X_PROP_FM_RDS_CONFIG = 0x4002,
+};
+
+struct si476x_property_range {
+ u16 low, high;
+};
+
+static bool __element_is_in_array(u16 element, const u16 array[], size_t size)
+{
+ int i;
+
+ for (i = 0; i size; i++)
+ if (element == array[i])
+ return true;
+
+ return false;
+}
+
+static bool __element_is_in_range(u16 element,
+ const struct si476x_property_range range[],
+ size_t size)
+{
+ int i;
+
+ for (i = 0; i size; i++)
+ if (element = range[i].high element = range[i].low)
+ return true;
+
+ return false;
+}
+
+static bool si476x_core_is_valid_property_a10(struct si476x_core *core,
+ u16 property)
+{
+ static const u16 valid_properties[] = {
+ 0x,
+ 0x0500, 0x0501,
+ 0x0600,
+ 0x0709, 0x070C, 0x070D, 0x70E, 0x710,
+ 0x718, /* FIXME: Magic property */
+ 0x1207, 0x1208,
+ 0x2007,
+ 0x2300,
+ };
+
+ static const struct si476x_property_range valid_ranges[] = {
+ { 0x0200, 0x0203 },
+ { 0x0300, 0x0303 },
+ { 0x0400, 0x0404 },
+ { 0x0700, 0x0707 },
+ { 0x1100, 0x1102 },
+ { 0x1200, 0x1204 },
+ { 0x1300, 0x1306 },
+ { 0x2000, 0x2005 },
+ { 0x2100, 0x2104 },
+ { 0x2106, 0x2106 },
+ { 0x2200, 0x220E },
+ { 0x3100, 0x3104 },
+ { 0x3207, 0x320F },
+ { 0x3300, 0x3304 },
+ { 0x3500, 0x3517 },
+ { 0x3600, 0x3617 },
+ { 0x3700, 0x3717 },
+ { 0x4000, 0x4003 },
+ };
+
+ return __element_is_in_range(property, valid_ranges,
+ARRAY_SIZE(valid_ranges)) ||
+ __element_is_in_array(property, valid_properties,
+
[PATCH v2 2/6] Add the main bulk of core driver for SI476x code
This patch adds main part(out of three) of the I2C driver for the
core of MFD device.
Signed-off-by: Andrey Smirnov andrey.smir...@convergeddevices.net
---
drivers/mfd/si476x-i2c.c | 972 ++
1 file changed, 972 insertions(+)
create mode 100644 drivers/mfd/si476x-i2c.c
diff --git a/drivers/mfd/si476x-i2c.c b/drivers/mfd/si476x-i2c.c
new file mode 100644
index 000..ec79da5
--- /dev/null
+++ b/drivers/mfd/si476x-i2c.c
@@ -0,0 +1,972 @@
+/*
+ * include/media/si476x-i2c.c -- Core device driver for si476x MFD
+ * device
+ *
+ * Copyright (C) 2012 Innovative Converged Devices(ICD)
+ *
+ * Author: Andrey Smirnov andrey.smir...@convergeddevices.net
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+#include linux/module.h
+
+#include linux/slab.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/regulator/consumer.h
+#include linux/i2c.h
+#include linux/err.h
+
+#include linux/mfd/si476x-core.h
+
+/* Command Timeouts */
+#define DEFAULT_TIMEOUT10
+#define TIMEOUT_TUNE 70
+#define TIMEOUT_POWER_UP 33
+
+#define MAX_IO_ERRORS 10
+
+#define SI476X_DRIVER_RDS_FIFO_DEPTH 128
+
+#define SI476X_STATUS_POLL_US 0
+
+/**
+ * si476x_core_config_pinmux() - pin function configuration function
+ *
+ * @core: Core device structure
+ *
+ * Configure the functions of the pins of the radio chip.
+ *
+ * The function returns zero in case of succes or negative error code
+ * otherwise.
+ */
+static int si476x_core_config_pinmux(struct si476x_core *core)
+{
+ int err;
+ dev_dbg(core-client-dev, Configuring pinmux\n);
+ err = si476x_core_cmd_dig_audio_pin_cfg(core,
+ core-pinmux.dclk,
+ core-pinmux.dfs,
+ core-pinmux.dout,
+ core-pinmux.xout);
+ if (err 0) {
+ dev_err(core-client-dev,
+ Failed to configure digital audio pins(err = %d)\n,
+ err);
+ return err;
+ }
+
+ err = si476x_core_cmd_zif_pin_cfg(core,
+ core-pinmux.iqclk,
+ core-pinmux.iqfs,
+ core-pinmux.iout,
+ core-pinmux.qout);
+ if (err 0) {
+ dev_err(core-client-dev,
+ Failed to configure ZIF pins(err = %d)\n,
+ err);
+ return err;
+ }
+
+ err = si476x_core_cmd_ic_link_gpo_ctl_pin_cfg(core,
+ core-pinmux.icin,
+ core-pinmux.icip,
+ core-pinmux.icon,
+ core-pinmux.icop);
+ if (err 0) {
+ dev_err(core-client-dev,
+ Failed to configure IC-Link/GPO pins(err = %d)\n,
+ err);
+ return err;
+ }
+
+ err = si476x_core_cmd_ana_audio_pin_cfg(core,
+ core-pinmux.lrout);
+ if (err 0) {
+ dev_err(core-client-dev,
+ Failed to configure analog audio pins(err = %d)\n,
+ err);
+ return err;
+ }
+
+ err = si476x_core_cmd_intb_pin_cfg(core,
+ core-pinmux.intb,
+ core-pinmux.a1);
+ if (err 0) {
+ dev_err(core-client-dev,
+ Failed to configure interrupt pins(err = %d)\n,
+ err);
+ return err;
+ }
+
+ return 0;
+}
+
+static inline void si476x_schedule_polling_work(struct si476x_core *core)
+{
+ schedule_delayed_work(core-status_monitor,
+ usecs_to_jiffies(atomic_read(core-polling_interval)));
+}
+
+/**
+ * si476x_core_start() - early chip startup function
+ * @core: Core device structure
+ * @soft: When set, this flag forces soft startup, where soft
+ * power down is the one done by sending appropriate command instead
+ * of using reset pin of the tuner
+ *
+ * Perform required startup sequence to correctly power
+ * up the chip and
