Re: [PULL] video_visstrim for 3.6
On 31 July 2012 00:42, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 26-07-2012 06:36, Javier Martin escreveu: Hi Mauro, this pull request is composed of two series that provide support for two mem2mem devices: - 'm2m-deinterlace' video deinterlacer - 'coda video codec' I've included platform support for them too. The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: https://github.com/jmartinc/video_visstrim.git for_3.6 for you to fetch changes up to 9bb10266da63ae7f8f198573e099580e9f98f4e8: i.MX27: Visstrim_M10: Add support for deinterlacing driver. (2012-07-26 10:57:30 +0200) Javier Martin (5): i.MX: coda: Add platform support for coda in i.MX27. media: coda: Add driver for Coda video codec. Visstrim M10: Add support for Coda. media: Add mem2mem deinterlacing driver. i.MX27: Visstrim_M10: Add support for deinterlacing driver. arch/arm/mach-imx/clk-imx27.c |4 +- arch/arm/mach-imx/devices-imx27.h |4 + arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 49 +- arch/arm/plat-mxc/devices/Kconfig |6 +- arch/arm/plat-mxc/devices/Makefile |1 + arch/arm/plat-mxc/devices/platform-imx27-coda.c | 37 + arch/arm/plat-mxc/include/mach/devices-common.h |8 + I need ARM maintainer's ack for the patches that touch the above files. Regards, Mauro Sascha or Russell, could you please give me an ACK for the following patches? i.MX27: Visstrim_M10: Add support for deinterlacing driver. (http://www.spinics.net/lists/linux-media/msg50223.html) Visstrim M10: Add support for Coda.. (http://patchwork.linuxtv.org/patch/13286/) Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/15] Integration of videobuf2 with dmabuf
Hi Tomasz!
What is the status of this? If it is stable, then it might be a good idea to
rebase to the latest for_v3.6 and make a pull request for 3.6.
Regards,
Hans
On Thu June 14 2012 15:37:34 Tomasz Stanislawski wrote:
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4]. This patchset depends on new scatterlist
constructor [5].
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.drivers.video-input-infrastructure/36354/focus=36355
[4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
[5]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/47983
Laurent Pinchart (2):
v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
v4l: vb2-dma-contig: Reorder functions
Marek Szyprowski (2):
v4l: vb2: add prepare/finish callbacks to allocators
v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
Sumit Semwal (4):
v4l: Add DMABUF as a memory type
v4l: vb2: add support for shared buffer (dma_buf)
v4l: vb: remove warnings about MEMORY_DMABUF
v4l: vb2-dma-contig: add support for dma_buf importing
Tomasz Stanislawski (7):
Documentation: media: description of DMABUF importing in V4L2
v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
v4l: vb2-dma-contig: add support for scatterlist in userptr mode
v4l: vb2-vmalloc: add support for dmabuf importing
v4l: vivi: support for dmabuf importing
v4l: s5p-tv: mixer: support for dmabuf importing
v4l: s5p-fimc: support for dmabuf importing
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 179
.../DocBook/media/v4l/vidioc-create-bufs.xml |3 +-
Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 15 +
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml | 47 +-
drivers/media/video/Kconfig|1 +
drivers/media/video/s5p-fimc/Kconfig |1 +
drivers/media/video/s5p-fimc/fimc-capture.c
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Thu June 14 2012 16:32:23 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 |6 ++
include/linux/videodev2.h | 26 ++
include/media/v4l2-ioctl.h|2 ++
5 files changed, 36 insertions(+)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index d33ab18..141e745 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -970,6 +970,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 5ccbd46..6bf6307 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -597,6 +597,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 31fc2ad..a73b14e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -212,6 +212,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO(VIDIOC_S_FBUF, INFO_FL_PRIO),
IOCTL_INFO(VIDIOC_OVERLAY, INFO_FL_PRIO),
IOCTL_INFO(VIDIOC_QBUF, 0),
+ IOCTL_INFO(VIDIOC_EXPBUF, 0),
IOCTL_INFO(VIDIOC_DQBUF, 0),
IOCTL_INFO(VIDIOC_STREAMON, INFO_FL_PRIO),
IOCTL_INFO(VIDIOC_STREAMOFF, INFO_FL_PRIO),
@@ -957,6 +958,11 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+ case VIDIOC_EXPBUF:
+ {
+ ret = ops-vidioc_expbuf(file, fh, arg);
+ break;
+ }
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 51b20f4..e8893a5 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -684,6 +684,31 @@ 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)
+ * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
struct
+ * v4l2_buffer::m.offset (for single-plane formats) or
+ * v4l2_plane::m.offset (for multi-planar formats)
+ * @flags: flags for newly created file, currently only O_CLOEXEC is
+ * supported, refer to manual of open syscall for more details
+ *
+ * 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. Therefore this field should not be used for any other extensions.
+ */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
+ __u32 mem_offset;
This should be a union identical to the m union in v4l2_plane, together with a
u32 memory field. That way you can just copy memory and m from v4l2_plane/buffer
and call expbuf. If new memory types are added in the future, then you don't
need
to change this struct.
For that matter, wouldn't it be useful to support exporting a userptr buffer at
some point in the future?
BTW, this patch series needs to be rebased to the latest for_v3.6. Quite a few
core things have changed when it comes to adding new ioctls.
Regards,
Hans
+ __u32 flags;
+ __u32 reserved[12];
+};
+
/*
* O V E R L A Y P R E V I E W
*/
@@ -2553,6
Re: [PATCHv7 00/15] Integration of videobuf2 with dmabuf
On Tue July 31 2012 08:23:15 Hans Verkuil wrote:
Hi Tomasz!
What is the status of this? If it is stable, then it might be a good idea to
rebase to the latest for_v3.6 and make a pull request for 3.6.
BTW, while rebasing also fix two typos in patch 9 and 15:
s/usefull/useful/
Regards,
Hans
Regards,
Hans
On Thu June 14 2012 15:37:34 Tomasz Stanislawski wrote:
Hello everyone,
This patchset adds support for DMABUF [2] importing to V4L2 stack.
The support for DMABUF exporting was moved to separate patchset
due to dependency on patches for DMA mapping redesign by
Marek Szyprowski [4]. This patchset depends on new scatterlist
constructor [5].
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.drivers.video-input-infrastructure/36354/focus=36355
[4] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
[5]
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/47983
Laurent Pinchart (2):
v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc
v4l: vb2-dma-contig: Reorder functions
Marek Szyprowski (2):
v4l: vb2: add prepare/finish callbacks to allocators
v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
Sumit Semwal (4):
v4l: Add DMABUF as a memory type
v4l: vb2: add support for shared buffer (dma_buf)
v4l: vb: remove warnings about MEMORY_DMABUF
v4l: vb2-dma-contig: add support for dma_buf importing
Tomasz Stanislawski (7):
Documentation: media: description of DMABUF importing in V4L2
v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
v4l: vb2-dma-contig: add support for scatterlist in userptr mode
v4l: vb2-vmalloc: add support for dmabuf importing
v4l: vivi: support for dmabuf importing
v4l: s5p-tv: mixer: support for dmabuf importing
v4l: s5p-fimc: support for dmabuf importing
Documentation/DocBook/media/v4l/compat.xml |4 +
Documentation/DocBook/media/v4l/io.xml | 179
.../DocBook/media/v4l/vidioc-create-bufs.xml |3 +-
Re: [PATCH] media: mx3_camera: buf_init() add buffer state check
Hi Alex
On Mon, 30 Jul 2012, Alex Gershgorin wrote:
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the
problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/mx3_camera.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index f13643d..950a8fe 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
Sorry, don't understand. As we see in the thread, mentioned above, the
Oops happened in mx3_videobuf_release(). If my analysis was correct in
that thread, that Oops happened, when .buf_cleanup() was called without
.buf_init() being called. This your patch modifies mx3_videobuf_init().
which isn't even called in the problem case. How does this help?
Thanks
Guennadi
struct mx3_camera_dev *mx3_cam = ici-priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(buf-queue);
- sg_init_table(buf-sg, 1);
+ if (buf-state != CSI_BUF_PREPARED) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(buf-queue);
+ sg_init_table(buf-sg, 1);
- buf-state = CSI_BUF_NEEDS_INIT;
+ buf-state = CSI_BUF_NEEDS_INIT;
- mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}
--
1.7.0.4
---
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
[GIT PULL FOR v3.6] Remove V4L2_FL_LOCK_ALL_FOPS
Hi Mauro, I hope this can still be applied to 3.6. This patch series was pending a fix for s5p-fimc which is now merged, so this can now be pulled in. It removes the legacy V4L2_FL_LOCK_ALL_FOPS flag, simplifying the locking code. It's rebased to the latest for_v3.6 branch but otherwise unchanged. Regards, Hans The following changes since commit 24ed693da0cefede7382d498dd5e9a83f0a21c38: [media] DVB: dib0700, remove double \n's from log (2012-07-31 00:36:03 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git removeflag3 for you to fetch changes up to 0bcee95388e4aaa1877a797880d485b083794945: v4l2-dev: remove V4L2_FL_LOCK_ALL_FOPS (2012-07-31 09:02:25 +0200) Hans Verkuil (24): ivtv: remove V4L2_FL_LOCK_ALL_FOPS saa7146: remove V4L2_FL_LOCK_ALL_FOPS cpia2: remove V4L2_FL_LOCK_ALL_FOPS usbvision: remove V4L2_FL_LOCK_ALL_FOPS em28xx: remove V4L2_FL_LOCK_ALL_FOPS tm6000: remove V4L2_FL_LOCK_ALL_FOPS dt3155v4l: remove V4L2_FL_LOCK_ALL_FOPS wl128x: remove V4L2_FL_LOCK_ALL_FOPS fsl-viu: remove V4L2_FL_LOCK_ALL_FOPS s2255drv: remove V4L2_FL_LOCK_ALL_FOPS vpbe_display: remove V4L2_FL_LOCK_ALL_FOPS mx2_emmaprp: remove V4L2_FL_LOCK_ALL_FOPS sh_vou: remove V4L2_FL_LOCK_ALL_FOPS bfin_capture: remove V4L2_FL_LOCK_ALL_FOPS cx231xx: remove V4L2_FL_LOCK_ALL_FOPS soc_camera: remove V4L2_FL_LOCK_ALL_FOPS s5p-jpeg: remove V4L2_FL_LOCK_ALL_FOPS s5p-g2d: remove V4L2_FL_LOCK_ALL_FOPS s5p-tv: remove V4L2_FL_LOCK_ALL_FOPS s5p-mfc: remove V4L2_FL_LOCK_ALL_FOPS vpif_display: remove V4L2_FL_LOCK_ALL_FOPS vpif_capture: remove V4L2_FL_LOCK_ALL_FOPS mem2mem_testdev: remove V4L2_FL_LOCK_ALL_FOPS v4l2-dev: remove V4L2_FL_LOCK_ALL_FOPS drivers/media/common/saa7146_core.c |8 drivers/media/common/saa7146_fops.c | 55 +++ drivers/media/radio/wl128x/fmdrv_v4l2.c | 38 ++ drivers/media/video/blackfin/bfin_capture.c | 17 +++-- drivers/media/video/cpia2/cpia2_v4l.c | 39 --- drivers/media/video/cx231xx/cx231xx-video.c | 47 --- drivers/media/video/davinci/vpbe_display.c | 22 +++--- drivers/media/video/davinci/vpif_capture.c | 28 drivers/media/video/davinci/vpif_display.c | 34 +++--- drivers/media/video/em28xx/em28xx-video.c | 52 +++- drivers/media/video/fsl-viu.c | 27 ++- drivers/media/video/ivtv/ivtv-fileops.c | 52 ++-- drivers/media/video/ivtv/ivtv-streams.c |4 drivers/media/video/mem2mem_testdev.c | 29 - drivers/media/video/mx2_emmaprp.c | 28 ++-- drivers/media/video/s2255drv.c | 42 +- drivers/media/video/s5p-g2d/g2d.c | 27 +-- drivers/media/video/s5p-jpeg/jpeg-core.c| 34 -- drivers/media/video/s5p-mfc/s5p_mfc.c | 19 +-- drivers/media/video/s5p-tv/mixer_video.c| 29 + drivers/media/video/sh_vou.c| 25 +++-- drivers/media/video/soc_camera.c| 31 --- drivers/media/video/tm6000/tm6000-video.c | 52 +++- drivers/media/video/usbvision/usbvision-video.c | 42 -- drivers/media/video/v4l2-dev.c | 51 --- drivers/media/video/videobuf2-core.c| 21 +++-- drivers/staging/media/dt3155v4l/dt3155v4l.c | 29 ++--- include/media/saa7146.h |4 include/media/v4l2-dev.h|3 --- 29 files changed, 594 insertions(+), 295 deletions(-) -- 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] [media] davinci: vpfe: Add documentation
Hi Laurent,
On Friday 27 July 2012 04:19 PM, Laurent Pinchart wrote:
Hi Manjunath,
On Friday 27 July 2012 05:49:24 Hadli, Manjunath wrote:
On Thu, Jul 26, 2012 at 05:55:31, Laurent Pinchart wrote:
On Tuesday 17 July 2012 10:43:54 Hadli, Manjunath wrote:
On Sun, Jul 15, 2012 at 18:16:25, Laurent Pinchart wrote:
On Wednesday 11 July 2012 21:09:26 Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
[snip]
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports
standard V4L2
+IOCTLs and controls where possible and practical. Much of the
functions provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the
blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+ Sets/Gets the parameters required by the previewer module
+Parameter:
+ /**
+* struct prev_module_param- structure to configure preview
modules
+* @version: Version of the preview module
Who is responsible for filling this field, the application or the
driver ?
The application is responsible for filling this info. He would enumerate
the capabilities first and set them using S_PARAM/G_PARAM.
And what's the point of the application setting the version field ? How
does the driver use it ?
The version may not be required. Will remove it.
+* @len: Length of the module config structure
+* @module_id: Module id
+* @param: pointer to module config parameter.
What is module_id for ? What does param point to ?
There are a lot of tiny modules in the previewer/resizer which are
enumerated as individual modules. The param points to the parameter set
that the module expects to be set.
Why don't you implement something similar to
VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS instead ?
I feel if we implement direct IOCTLS there might be many of them. To make
sure than independent of the number of internal modules present, having the
same IOCTL used for all modules is a good idea.
You can set several parameters using a single ioctl, much like
VPFE_CMD_S_CCDC_RAW_PARAMS does. You don't need one ioctl per parameter.
PREV_ENUM_CAP, PREV_[GS]_PARAM and PREV_[GS]_CONFIG are essentially
reinventing V4L2 controls, and I don't think that's a good idea.
Ok. I looked into this, and found that the structure needed to pass
all the parameters is going to be huge. just to avoid a big structure
from the user space, I propose:
Having a union of structures and a parameter identifying the structure.
In that way, we will remove the enumeration and all the other
things except for a SET and GET, much like the CCDC_RAW_PARAMS
like you suggested. So essentially we will have only 2 IOCTLS for setting
the private params/configs and remove the rest. I hope that was your
point and this proposal will solve it?
+*/
+ struct prev_module_param {
+ char version[IMP_MAX_NAME_SIZE];
Is there a need to express the version as a string instead of an
integer ?
It could be integer. It is generally a fixed point num, and easy to read
it as a string than an integer. Can I keep it as a string?
Let's first decide whether a version field is needed at all :-)
Will remove.
+ unsigned short len;
+ unsigned short module_id;
+ void *param;
+ };
+
+2: IOCTL: PREV_S_CONFIG/PREV_G_CONFIG
+Description:
+ Sets/Gets the configuration required by the previewer channel
+Parameter:
+ /**
+* struct prev_channel_config - structure for configuring the
previewer
channel
+* @len: Length of the user configuration
+* @config: pointer to either single shot config or continuous
+*/
+ struct prev_channel_config {
+ unsigned short len;
+ void *config;
+ };
What's the difference between parameters and configuration ? What does
config point to ?
Config is setting which is required for a subdev to function based on
what it is set for (single shot/continuous.) common to all platforms.
Parameters are the settings for individual small sub-ips which might be
slightly different from one platform to another. Config points to
prev_single_shot_config or prev_continuous_config currently defined in
linux/dm3656ipipe.h. I think we will move it to a common location.
Why don't you implement something similar to
VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS here as well (same
for the resizer configuration ioctls) ?
Ditto.
+
+3: IOCTL: PREV_ENUM_CAP
+Description:
+ Queries the modules available in the image processor for preview
the
+ input image.
+Parameter:
+ /**
+
Re: [PATCH] mt9v022: Add support for mt9v024
Hi Alex
Thanks for the patch, comments below.
On Mon, 30 Jul 2012, Alex Gershgorin wrote:
This patch has been successfully tested
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 28 ++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 99937c9..38d6944 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1013,7 +1013,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate mt9v022 support
+ tristate mt9v022 and mt9v024 support
depends on SOC_CAMERA I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index bf63417..d2c1ab1 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -26,7 +26,7 @@
* The platform has to define ctruct i2c_board_info objects and link to them
* from struct soc_camera_link
*/
-
+static s32 chip_id;
No, this should be per instance. Please, add it to struct mt9v022.
static char *sensor_type;
module_param(sensor_type, charp, S_IRUGO);
MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or \monochrome\);
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH 0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH 0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -185,7 +189,9 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+ ret = reg_write(client, (chip_id == 0x1324) ?
I would use a macro something like
#define is_mt9v024(p) (p-chip_id == 0x1324)
same everywhere below
+ MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+ MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
Hm, with just 2 registers different it almost isn't worth it, but still...
(1) if someone uses this driver as a template, or (2) if we add more
sensors or more registers, whose addresses also are different, I think, we
better do it properly. How about
/* only registers with different addresses on different mt9v02x sensors */
struct mt9v02x_register {
u8 max_total_shutter_width;
u8 pixclk_fv_lv;
};
static const struct mt9v02x_register mt9v022_register = {
.max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
.pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
};
static const struct mt9v02x_register mt9v024_register = {
.max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
.pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
};
struct mt9v022 {
...
const struct mt9v02x_register *reg;
...
};
and then in this case just do
+ ret = reg_write(client, mt9v022-reg-max_total_shutter_width,
480);
etc.?
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,8 +244,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
if (ret = 0) {
if (ret 1) /* Autoexposure */
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
- rect.height + mt9v022-y_skip_top + 43);
+ ret = reg_write(client, (chip_id == 0x1324) ?
+ MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+ MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ rect.height + mt9v022-y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
rect.height + mt9v022-y_skip_top + 43);
@@ -566,18 +574,17 @@ static int mt9v022_video_probe(struct i2c_client
*client)
{
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
- s32 data;
int ret;
unsigned long flags;
/* Read out the chip version register */
- data = reg_read(client, MT9V022_CHIP_VERSION);
+ chip_id = reg_read(client, MT9V022_CHIP_VERSION);
/* must be 0x1311 or 0x1313 */
- if (data != 0x1311 data != 0x1313) {
+ if (chip_id != 0x1311 chip_id != 0x1313
Re: [PATCH 1/2] [media] s5k6aa: Use devm_kzalloc function
Hi Sachin, On 07/26/2012 08:23 AM, Sachin Kamat wrote: devm_kzalloc() eliminates the need to free explicitly thereby making the code a bit simpler. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Thanks for the patch. Since I have nothing more for a pull request right now, Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- 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] Add support for Prof Revolution DVB-S2 8000 PCI-E card
On 07/31/2012 05:08 AM, Mauro Carvalho Chehab wrote: Em 26-07-2012 15:08, Mariusz Bialonczyk escreveu: The device is based on STV0903 demodulator, STB6100 tuner and CX23885 chipset; subsystem id: 8000:3034 Signed-off-by: Mariusz Bialonczyk ma...@skyboo.net This is the second time I see this patch. It seems very similar to the one sent by Wojciech. So, who is the author of this patch? Hi! Wojciech Myrda's patch was based on original producer patch from here: http://www.proftuners.com/sites/default/files/prof8000_0.patch From my diagnose (diff original and his patch) he rebased it to take into account later kernel sources. You ask him to post it again with Signed-off-by line, but he doesn't respond for over a year (at least to linux media mailing list). My patch uses stv090x frontend instead and I assumed that I can ommit additional signed-off-by lines in this case. If it is not ok, please tell me and I will prepare second patch with additional Signed-off-by lines. regards! -- Mariusz Białończyk jabber/e-mail: ma...@skyboo.net http://manio.skyboo.net -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] media: mx3_camera: buf_init() add buffer state check
Hi Guennadi,
On Mon, 30 Jul 2012, Alex Gershgorin wrote:
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the
problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/mx3_camera.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index f13643d..950a8fe 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
Sorry, don't understand. As we see in the thread, mentioned above, the
Oops happened in mx3_videobuf_release(). If my analysis was correct in
that thread, that Oops happened, when .buf_cleanup() was called without
.buf_init() being called. This your patch modifies mx3_videobuf_init().
which isn't even called in the problem case. How does this help?
Sorry for not quite a clear explanation, I will explain in more details.
if you divide the report into two parts:
1) USERPTR method Oops happened as a result discontiguous memory allocation
2) USERPTR method use framebuffer memory allocation video starting, but after a
few seconds the video freezes.
if we consider the first part of the report, your analysis is absolutely
correct and unfortunately this patch does not solve the problems mentioned
in the thread.
This patch solves a problem that is described in the second part of the
report.
struct mx3_camera_dev *mx3_cam = ici-priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(buf-queue);
- sg_init_table(buf-sg, 1);
+ if (buf-state != CSI_BUF_PREPARED) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(buf-queue);
+ sg_init_table(buf-sg, 1);
- buf-state = CSI_BUF_NEEDS_INIT;
+ buf-state = CSI_BUF_NEEDS_INIT;
- mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}
--
1.7.0.4
Regards,
Alex
--
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/3] drivers/media/radio/radio-timb.c: use devm_ functions
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/media/radio/radio-timb.c |8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
index 7052adc..09fc560 100644
--- a/drivers/media/radio/radio-timb.c
+++ b/drivers/media/radio/radio-timb.c
@@ -157,7 +157,7 @@ static int __devinit timbradio_probe(struct platform_device
*pdev)
goto err;
}
- tr = kzalloc(sizeof(*tr), GFP_KERNEL);
+ tr = devm_kzalloc(pdev-dev, sizeof(*tr), GFP_KERNEL);
if (!tr) {
err = -ENOMEM;
goto err;
@@ -177,7 +177,7 @@ static int __devinit timbradio_probe(struct platform_device
*pdev)
strlcpy(tr-v4l2_dev.name, DRIVER_NAME, sizeof(tr-v4l2_dev.name));
err = v4l2_device_register(NULL, tr-v4l2_dev);
if (err)
- goto err_v4l2_dev;
+ goto err;
tr-video_dev.v4l2_dev = tr-v4l2_dev;
@@ -195,8 +195,6 @@ static int __devinit timbradio_probe(struct platform_device
*pdev)
err_video_req:
video_device_release_empty(tr-video_dev);
v4l2_device_unregister(tr-v4l2_dev);
-err_v4l2_dev:
- kfree(tr);
err:
dev_err(pdev-dev, Failed to register: %d\n, err);
@@ -212,8 +210,6 @@ static int __devexit timbradio_remove(struct
platform_device *pdev)
v4l2_device_unregister(tr-v4l2_dev);
- kfree(tr);
-
return 0;
}
--
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 3/3] drivers/media/radio/radio-wl1273.c: use devm_ functions
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
In two cases, the original memory allocation function was kmalloc, which
has been changed to a zeroing allocation to benefit from the devm function.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/media/radio/radio-wl1273.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index e8428f5..a22ad1c 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -1983,9 +1983,6 @@ static int wl1273_fm_radio_remove(struct platform_device
*pdev)
v4l2_ctrl_handler_free(radio-ctrl_handler);
video_unregister_device(radio-videodev);
v4l2_device_unregister(radio-v4l2dev);
- kfree(radio-buffer);
- kfree(radio-write_buf);
- kfree(radio);
return 0;
}
@@ -2005,7 +2002,7 @@ static int __devinit wl1273_fm_radio_probe(struct
platform_device *pdev)
goto pdata_err;
}
- radio = kzalloc(sizeof(*radio), GFP_KERNEL);
+ radio = devm_kzalloc(pdev-dev, sizeof(*radio), GFP_KERNEL);
if (!radio) {
r = -ENOMEM;
goto pdata_err;
@@ -2013,11 +2010,11 @@ static int __devinit wl1273_fm_radio_probe(struct
platform_device *pdev)
/* RDS buffer allocation */
radio-buf_size = rds_buf * RDS_BLOCK_SIZE;
- radio-buffer = kmalloc(radio-buf_size, GFP_KERNEL);
+ radio-buffer = devm_kzalloc(pdev-dev, radio-buf_size, GFP_KERNEL);
if (!radio-buffer) {
pr_err(Cannot allocate memory for RDS buffer.\n);
r = -ENOMEM;
- goto err_kmalloc;
+ goto pdata_err;
}
radio-core = *core;
@@ -2043,7 +2040,7 @@ static int __devinit wl1273_fm_radio_probe(struct
platform_device *pdev)
if (r) {
dev_err(radio-dev, WL1273_FM_DRIVER_NAME
: Cannot get platform data\n);
- goto err_resources;
+ goto pdata_err;
}
dev_dbg(radio-dev, irq: %d\n, radio-core-client-irq);
@@ -2061,13 +2058,13 @@ static int __devinit wl1273_fm_radio_probe(struct
platform_device *pdev)
dev_err(radio-dev, WL1273_FM_DRIVER_NAME : Core WL1273 IRQ
not configured);
r = -EINVAL;
- goto err_resources;
+ goto pdata_err;
}
init_completion(radio-busy);
init_waitqueue_head(radio-read_queue);
- radio-write_buf = kmalloc(256, GFP_KERNEL);
+ radio-write_buf = devm_kzalloc(pdev-dev, 256, GFP_KERNEL);
if (!radio-write_buf) {
r = -ENOMEM;
goto write_buf_err;
@@ -2080,7 +2077,7 @@ static int __devinit wl1273_fm_radio_probe(struct
platform_device *pdev)
r = v4l2_device_register(pdev-dev, radio-v4l2dev);
if (r) {
dev_err(pdev-dev, Cannot register v4l2_device.\n);
- goto device_register_err;
+ goto write_buf_err;
}
/* V4L2 configuration */
@@ -2135,16 +2132,10 @@ static int __devinit wl1273_fm_radio_probe(struct
platform_device *pdev)
handler_init_err:
v4l2_ctrl_handler_free(radio-ctrl_handler);
v4l2_device_unregister(radio-v4l2dev);
-device_register_err:
- kfree(radio-write_buf);
write_buf_err:
free_irq(radio-core-client-irq, radio);
err_request_irq:
radio-core-pdata-free_resources();
-err_resources:
- kfree(radio-buffer);
-err_kmalloc:
- kfree(radio);
pdata_err:
return r;
}
--
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/3] drivers/media/radio/radio-si4713.c: use devm_ functions
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/media/radio/radio-si4713.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/media/radio/radio-si4713.c
b/drivers/media/radio/radio-si4713.c
index c54210c..5f366d1 100644
--- a/drivers/media/radio/radio-si4713.c
+++ b/drivers/media/radio/radio-si4713.c
@@ -268,7 +268,7 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
goto exit;
}
- rsdev = kzalloc(sizeof *rsdev, GFP_KERNEL);
+ rsdev = devm_kzalloc(pdev-dev, sizeof(*rsdev), GFP_KERNEL);
if (!rsdev) {
dev_err(pdev-dev, Failed to alloc video device.\n);
rval = -ENOMEM;
@@ -278,7 +278,7 @@ static int radio_si4713_pdriver_probe(struct
platform_device *pdev)
rval = v4l2_device_register(pdev-dev, rsdev-v4l2_dev);
if (rval) {
dev_err(pdev-dev, Failed to register v4l2 device.\n);
- goto free_rsdev;
+ goto exit;
}
adapter = i2c_get_adapter(pdata-i2c_bus);
@@ -322,8 +322,6 @@ put_adapter:
i2c_put_adapter(adapter);
unregister_v4l2_dev:
v4l2_device_unregister(rsdev-v4l2_dev);
-free_rsdev:
- kfree(rsdev);
exit:
return rval;
}
@@ -342,7 +340,6 @@ static int __exit radio_si4713_pdriver_remove(struct
platform_device *pdev)
video_unregister_device(rsdev-radio_dev);
i2c_put_adapter(client-adapter);
v4l2_device_unregister(rsdev-v4l2_dev);
- kfree(rsdev);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] media DT bindings
On Fri, 27 Jul 2012, Laurent Pinchart wrote:
Hi Sylwester,
On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
[snip]
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg =0xfe91 0xa0;
interrupts =0x880;
bus-width =16;/* #lines routed on the
board */
clock-frequency =5000;/* max clock */
#address-cells =1;
#size-cells =0;
...
ov772x-1 = {
reg =0;
This property might be redundant, we already have the client phandle
pointing to ov772x@0x21-0, which has all interesting properties inside
it. Other than there is probably no reasonable usage for it under
ceu0@0xfe91 node ?
client =ov772x@0x21-0;
local-pad = parallel-sink;
remote-pad = parallel-source;
I'm not sure I like that. Is it really needed when we already have
the child/parent properties around ?
I think it is. Both the host and the client can have multiple pads (e.g.,
parallel / serial). These properties specify which pads are used and make
the translation between DT data and our subdev / pad APIs simpler.
OK, sorry, but isn't it all about just specifying what sort of data bus
is used ? :-)
In some (many/most ?) cases probably, but not in all of them.
What about merging the client and remote-pad properties ? The resulting
property would then reference a pad with ov772x@0x21-0 0.
What would the 0 parameter mean then? Pad #0? But aren't these numbers
device specific? Maybe not a huge deal, but these numbers are defind by
the driver, right? Not the DT itself. So, drivers then will have to take
care not to change their pad numbering. Whereas using strings, we can fix
strings in the common V4L DT spec and keep them standard across devices
and drivers. Then drivers might be less likely to change these assignments
randomly;-)
[snip]
I'd like just to point one detail here, as sensor subdev drivers control
their voltage regulators and RESET/STANDBY (gpio) signals, they should
also be able to control the master clock. In order to ensure proper power
up/down sequences. It is a bad practice to enable clocks before voltage
supplies are switched on and we shouldn't have that as a general
assumption at the kernel frameworks.
One possible solution would be to have host/bridge drivers to register
a clkdev entry for I2C client device, so it can acquire the clock through
just clk_get(). We would have to ensure the clock is not tried to be
accessed before it is registered by a bridge. This would require to add
clock handling code to all sensor/encoder subdev drivers though..
I thik it's a good practice to add clock management to subdevs anyway, and
the
common clock framework should make that easy (or at least not too difficult).
We can migrate subdevs one by one as we add DT support for them.
Yes, this would be good.
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: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
On Thu, 26 Jul 2012, Laurent Pinchart wrote: Hi Sylwester, On Tuesday 17 July 2012 20:16:23 Sylwester Nawrocki wrote: On 07/16/2012 10:55 AM, Guennadi Liakhovetski wrote: Hi Sylwester Thanks for your comments to my RFC and for pointing out to this your earlier patch series. Unfortunately, I missed in in May, let me try to provide some thoughts about this, we should really try to converge our proposals. Maybe a discussion at KS would help too. Thank you for the review. I was happy to see your RFC, as previously there seemed to be not much interest in DT among the media guys. Certainly, we need to work on a common approach to ensure interoperability of existing drivers and to avoid having people inventing different bindings for common features. I would also expect some share of device specific bindings, as diversity of media devices is significant. I'd be great to discuss these things at KS, especially support for proper suspend/resume sequences. Also having common sessions with other subsystems folks, like ASoC, for example, might be a good idea. I'm not sure if I'll be travelling to the KS though. :) On Fri, 25 May 2012, Sylwester Nawrocki wrote: s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC (camera host interface DMA engine and image processor). This patch adds support for instantiating the MIPI-CSIS devices from DT and parsing all SoC and board specific properties from device tree. The MIPI DPHY control callback is now called directly from within the driver, the platform code must ensure this callback does the right thing for each SoC. The cell-index property is used to ensure proper signal routing, from physical camera port, through MIPI-CSI2 receiver to the DMA engine (FIMC?). It's also helpful in exposing the device topology in user space at /dev/media? devnode (Media Controller API). This patch also defines a common property (data-lanes) for MIPI-CSI receivers and transmitters. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- Documentation/devicetree/bindings/video/mipi.txt |5 + .../bindings/video/samsung-mipi-csis.txt | 47 ++ drivers/media/video/s5p-fimc/mipi-csis.c | 97 +++- drivers/media/video/s5p-fimc/mipi-csis.h |1 + 4 files changed, 126 insertions(+), 24 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/mipi.txt create mode 100644 Documentation/devicetree/bindings/video/samsung-mipi-csis.txt diff --git a/Documentation/devicetree/bindings/video/mipi.txt b/Documentation/devicetree/bindings/video/mipi.txt new file mode 100644 index 000..5aed285 --- /dev/null +++ b/Documentation/devicetree/bindings/video/mipi.txt @@ -0,0 +1,5 @@ +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters + + - data-lanes : number of differential data lanes wired and actively used in +communication between the transmitter and the receiver, this +excludes the clock lane; Wouldn't it be better to use the standard bus-width DT property? I can't see any problems with using bus-width. It seems sufficient and could indeed be better, without a need to invent new MIPI-CSI specific names. That was my first RFC on that and my perspective wasn't probably broad enough. :) What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane = 0; clock-lanes for uniformity? data-lanes = 2 3 1; Are there transmitters, that can reroute lanes too? Thanks Guennadi For receivers that can't reroute lanes internally, the data-lanes property would be need to specify lanes in sequence. data-lanes = 1 2 3; -- Regards, Laurent Pinchart --- 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: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Thu, 26 Jul 2012, Laurent Pinchart wrote: Hi Sylwester, On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? 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] mt9v022: Add support for mt9v024
Hi Guennadi,
Thanks for the patch, comments below.
Thanks for you comments.
On Mon, 30 Jul 2012, Alex Gershgorin wrote:
This patch has been successfully tested
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/mt9v022.c | 28 ++--
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 99937c9..38d6944 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -1013,7 +1013,7 @@ config SOC_CAMERA_MT9T112
This driver supports MT9T112 cameras from Aptina.
config SOC_CAMERA_MT9V022
- tristate mt9v022 support
+ tristate mt9v022 and mt9v024 support
depends on SOC_CAMERA I2C
select GPIO_PCA953X if MT9V022_PCA9536_SWITCH
help
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index bf63417..d2c1ab1 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -26,7 +26,7 @@
* The platform has to define ctruct i2c_board_info objects and link to them
* from struct soc_camera_link
*/
-
+static s32 chip_id;
No, this should be per instance. Please, add it to struct mt9v022.
static char *sensor_type;
module_param(sensor_type, charp, S_IRUGO);
MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or \monochrome\);
@@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or
\monochrome\);
#define MT9V022_AEC_AGC_ENABLE 0xAF
#define MT9V022_MAX_TOTAL_SHUTTER_WIDTH 0xBD
+/* mt9v024 partial list register addresses changes with respect to mt9v022 */
+#define MT9V024_PIXCLK_FV_LV 0x72
+#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH 0xAD
+
/* Progressive scan, master, defaults */
#define MT9V022_CHIP_CONTROL_DEFAULT 0x188
@@ -185,7 +189,9 @@ static int mt9v022_init(struct i2c_client *client)
if (!ret)
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480);
if (!ret)
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
+ ret = reg_write(client, (chip_id == 0x1324) ?
I would use a macro something like
#define is_mt9v024(p) (p-chip_id == 0x1324)
same everywhere below
+ MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+ MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480);
Hm, with just 2 registers different it almost isn't worth it, but still...
There is little more than two registers and also added new registers
if you're interested I can send you the document.
(1) if someone uses this driver as a template, or (2) if we add more
sensors or more registers, whose addresses also are different, I think, we
better do it properly. How about
/* only registers with different addresses on different mt9v02x sensors */
struct mt9v02x_register {
u8 max_total_shutter_width;
u8 pixclk_fv_lv;
};
static const struct mt9v02x_register mt9v022_register = {
.max_total_shutter_width= MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
.pixclk_fv_lv = MT9V022_PIXCLK_FV_LV,
};
static const struct mt9v02x_register mt9v024_register = {
.max_total_shutter_width= MT9V024_MAX_TOTAL_SHUTTER_WIDTH,
.pixclk_fv_lv = MT9V024_PIXCLK_FV_LV,
};
struct mt9v022 {
...
const struct mt9v02x_register *reg;
...
};
and then in this case just do
+ ret = reg_write(client,
mt9v022-reg-max_total_shutter_width, 480);
etc.?
I accept your corrections and suggestions in the near future
I will send an updated version of this patch.
Regards,
Alex
if (!ret)
/* default - auto */
ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1);
@@ -238,8 +244,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct
v4l2_crop *a)
ret = reg_read(client, MT9V022_AEC_AGC_ENABLE);
if (ret = 0) {
if (ret 1) /* Autoexposure */
- ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
- rect.height + mt9v022-y_skip_top + 43);
+ ret = reg_write(client, (chip_id == 0x1324) ?
+ MT9V024_MAX_TOTAL_SHUTTER_WIDTH :
+ MT9V022_MAX_TOTAL_SHUTTER_WIDTH,
+ rect.height + mt9v022-y_skip_top + 43);
else
ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH,
rect.height + mt9v022-y_skip_top + 43);
@@ -566,18 +574,17 @@ static int mt9v022_video_probe(struct i2c_client
*client)
{
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct soc_camera_link *icl = soc_camera_i2c_to_link(client);
- s32 data;
int ret;
unsigned long flags;
/* Read out the chip version register */
Re: [PATCH] Add support for Prof Revolution DVB-S2 8000 PCI-E card
Em 31-07-2012 05:32, Mariusz Bialonczyk escreveu: On 07/31/2012 05:08 AM, Mauro Carvalho Chehab wrote: Em 26-07-2012 15:08, Mariusz Bialonczyk escreveu: The device is based on STV0903 demodulator, STB6100 tuner and CX23885 chipset; subsystem id: 8000:3034 Signed-off-by: Mariusz Bialonczyk ma...@skyboo.net This is the second time I see this patch. It seems very similar to the one sent by Wojciech. So, who is the author of this patch? Hi! Wojciech Myrda's patch was based on original producer patch from here: http://www.proftuners.com/sites/default/files/prof8000_0.patch Hmm... it seems that the original producer worked for the manufacturers of this board, as the patch is posted there... An ack from them to allow adding it at Kernel seems to be required. From my diagnose (diff original and his patch) he rebased it to take into account later kernel sources. You ask him to post it again with Signed-off-by line, but he doesn't respond for over a year (at least to linux media mailing list). My patch uses stv090x frontend instead and I assumed that I can ommit additional signed-off-by lines in this case. Rebased patches should be mentioning their origin. In a matter of fact, you need to add a From: field at the beginning of the body of the email, with the original author there, even without his SOB (Signed-off-by). It should be noticed that SOB means: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. So, in the case of a patch made by someone else who didn't sign, the SOB means: (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. If it is not ok, please tell me and I will prepare second patch with additional Signed-off-by lines. regards! Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] winbond-cir: Fix initialization
The serial driver will detect the winbond cir device as a serial port,
since it looks exactly like a serial port unless you know what it is
from the PNP ID.
Winbond CIR 00:04: Region 0x2f8-0x2ff already in use!
Winbond CIR 00:04: disabled
Winbond CIR: probe of 00:04 failed with error -16
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/winbond-cir.c | 21 -
drivers/tty/serial/8250/8250.c | 1 +
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 54ee348..20a0bbb 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -55,6 +55,7 @@
#include linux/slab.h
#include linux/wait.h
#include linux/sched.h
+#include linux/serial_8250.h
#include media/rc-core.h
#define DRVNAME winbond-cir
@@ -957,6 +958,7 @@ wbcir_probe(struct pnp_dev *device, const struct
pnp_device_id *dev_id)
struct device *dev = device-dev;
struct wbcir_data *data;
int err;
+ struct resource *io;
if (!(pnp_port_len(device, 0) == EHFUNC_IOMEM_LEN
pnp_port_len(device, 1) == WAKEUP_IOMEM_LEN
@@ -1049,7 +1051,24 @@ wbcir_probe(struct pnp_dev *device, const struct
pnp_device_id *dev_id)
goto exit_release_wbase;
}
- if (!request_region(data-sbase, SP_IOMEM_LEN, DRVNAME)) {
+ io = request_region(data-sbase, SP_IOMEM_LEN, DRVNAME);
+
+ /*
+* The winbond cir device looks exactly like an NS16550A serial port
+* unless you know what it is. We've got here via the PNP ID.
+*/
+#ifdef CONFIG_SERIAL_8250
+ if (!io) {
+ struct uart_port port = { .iobase = data-sbase };
+ int line = serial8250_find_port(port);
+ if (line = 0) {
+ serial8250_unregister_port(line);
+
+ io = request_region(data-sbase, SP_IOMEM_LEN, DRVNAME);
+ }
+ }
+#endif
+ if (!io) {
dev_err(dev, Region 0x%lx-0x%lx already in use!\n,
data-sbase, data-sbase + SP_IOMEM_LEN - 1);
err = -EBUSY;
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 5c27f7e..d38615f 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -2914,6 +2914,7 @@ int serial8250_find_port(struct uart_port *p)
}
return -ENODEV;
}
+EXPORT_SYMBOL(serial8250_find_port);
#define SERIAL8250_CONSOLE serial8250_console
#else
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] nec-decoder: fix NEC decoding for Pioneer Laserdisc CU-700 remote
This remote sends a header pulse of 8150us followed by a space of 4000us.
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/ir-nec-decoder.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 3c9431a..2ca509e 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -70,7 +70,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
if (!ev.pulse)
break;
- if (eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT / 2)) {
+ if (eq_margin(ev.duration, NEC_HEADER_PULSE, NEC_UNIT * 2)) {
data-is_nec_x = false;
data-necx_repeat = false;
} else if (eq_margin(ev.duration, NECX_HEADER_PULSE, NEC_UNIT /
2))
@@ -86,7 +86,7 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
if (ev.pulse)
break;
- if (eq_margin(ev.duration, NEC_HEADER_SPACE, NEC_UNIT / 2)) {
+ if (eq_margin(ev.duration, NEC_HEADER_SPACE, NEC_UNIT)) {
data-state = STATE_BIT_PULSE;
return 0;
} else if (eq_margin(ev.duration, NEC_REPEAT_SPACE, NEC_UNIT /
2)) {
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] iguanair: various fixes
This fixes:
- rx_overflow while holding down any down button on a nec remote
- suspend/resume
- stop receiver on rmmod
- advertise rx_resolution and timeout properly
- code simplify
- ignore unsupported firmware versions
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/Kconfig| 8 +-
drivers/media/rc/iguanair.c | 206 ++--
2 files changed, 107 insertions(+), 107 deletions(-)
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 5180390..fa1745c 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -264,8 +264,12 @@ config IR_IGUANA
depends on RC_CORE
select USB
---help---
- Say Y here if you want to use the IgaunaWorks USB IR Transceiver.
- Both infrared receive and send are supported.
+ Say Y here if you want to use the IguanaWorks USB IR Transceiver.
+ Both infrared receive and send are supported. If you want to
+ change the ID or the pin config, use the user space driver from
+ IguanaWorks.
+
+ Only firmware 0x0205 and later is supported.
To compile this driver as a module, choose M here: the module will
be called iguanair.
diff --git a/drivers/media/rc/iguanair.c b/drivers/media/rc/iguanair.c
index 5e2eaf8..aa7f34f 100644
--- a/drivers/media/rc/iguanair.c
+++ b/drivers/media/rc/iguanair.c
@@ -35,9 +35,9 @@ struct iguanair {
struct device *dev;
struct usb_device *udev;
- int pipe_in, pipe_out;
+ int pipe_out;
+ uint16_t version;
uint8_t bufsize;
- uint8_t version[2];
struct mutex lock;
@@ -61,20 +61,21 @@ struct iguanair {
};
#define CMD_GET_VERSION0x01
-#define CMD_GET_BUFSIZE0x11
#define CMD_GET_FEATURES 0x10
+#define CMD_GET_BUFSIZE0x11
+#define CMD_RECEIVER_ON0x12
+#define CMD_RECEIVER_OFF 0x14
#define CMD_SEND 0x15
-#define CMD_EXECUTE0x1f
+#define CMD_GET_ID 0x1f
#define CMD_RX_OVERFLOW0x31
#define CMD_TX_OVERFLOW0x32
-#define CMD_RECEIVER_ON0x12
-#define CMD_RECEIVER_OFF 0x14
#define DIR_IN 0xdc
#define DIR_OUT0xcd
#define MAX_PACKET_SIZE8u
#define TIMEOUT1000
+#define RX_RESOLUTION 21330
struct packet {
uint16_t start;
@@ -82,11 +83,6 @@ struct packet {
uint8_t cmd;
};
-struct response_packet {
- struct packet header;
- uint8_t data[4];
-};
-
struct send_packet {
struct packet header;
uint8_t length;
@@ -96,10 +92,46 @@ struct send_packet {
uint8_t payload[0];
};
+/*
+ * The hardware advertises a polling interval of 10ms. This is far too
+ * slow and will cause regular rx overflows.
+ */
+static int int_urb_interval(struct usb_device *udev)
+{
+ switch (udev-speed) {
+ case USB_SPEED_HIGH:
+ return 4;
+ case USB_SPEED_LOW:
+ return 1;
+ case USB_SPEED_FULL:
+ default:
+ return 1;
+ }
+}
+
static void process_ir_data(struct iguanair *ir, unsigned len)
{
if (len = 4 ir-buf_in[0] == 0 ir-buf_in[1] == 0) {
switch (ir-buf_in[3]) {
+ case CMD_GET_VERSION:
+ if (len == 6) {
+ ir-version = (ir-buf_in[5] 8) |
+ ir-buf_in[4];
+ complete(ir-completion);
+ }
+ break;
+ case CMD_GET_BUFSIZE:
+ if (len = 5) {
+ ir-bufsize = ir-buf_in[4];
+ complete(ir-completion);
+ }
+ break;
+ case CMD_GET_FEATURES:
+ if (len 5) {
+ ir-cycle_overhead = ir-buf_in[5];
+ complete(ir-completion);
+ }
+ break;
case CMD_TX_OVERFLOW:
ir-tx_overflow = true;
case CMD_RECEIVER_OFF:
@@ -109,6 +141,7 @@ static void process_ir_data(struct iguanair *ir, unsigned
len)
break;
case CMD_RX_OVERFLOW:
dev_warn(ir-dev, receive overflow\n);
+ ir_raw_event_reset(ir-rc);
break;
default:
dev_warn(ir-dev, control code %02x received\n,
@@ -128,7 +161,7 @@ static void process_ir_data(struct iguanair *ir, unsigned
len)
} else {
rawir.pulse = (ir-buf_in[i] 0x80) == 0;
rawir.duration =
RE: [PATCH] media: mx3_camera: buf_init() add buffer state check
On Tue, 31 Jul 2012, Alex Gershgorin wrote:
Hi Guennadi,
On Mon, 30 Jul 2012, Alex Gershgorin wrote:
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the
problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/mx3_camera.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index f13643d..950a8fe 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
Sorry, don't understand. As we see in the thread, mentioned above, the
Oops happened in mx3_videobuf_release(). If my analysis was correct in
that thread, that Oops happened, when .buf_cleanup() was called without
.buf_init() being called. This your patch modifies mx3_videobuf_init().
which isn't even called in the problem case. How does this help?
Sorry for not quite a clear explanation, I will explain in more details.
if you divide the report into two parts:
1) USERPTR method Oops happened as a result discontiguous memory allocation
2) USERPTR method use framebuffer memory allocation video starting, but after
a few seconds the video freezes.
if we consider the first part of the report, your analysis is absolutely
correct and unfortunately this patch does not solve the problems mentioned
in the thread.
This patch solves a problem that is described in the second part of the
report.
Ok, I understand now what this patch fixes, but I still don't understand
what the problem is and how this patch fixes it. AFAICS, there should be
nothing wrong with calling mx3_videobuf_init() each time a buffer gets
queued. I suspect, it's just one of those 4 lines of code, that you put
under if (buf-state != CSI_BUF_PREPARED), that breaks it. Could you
please try to find out which exactly line it is? Just try to use your if
(...) with each of them separately. My guess goes for
buf-state = CSI_BUF_NEEDS_INIT;
but it would help if you could verify it.
Thanks
Guennadi
struct mx3_camera_dev *mx3_cam = ici-priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(buf-queue);
- sg_init_table(buf-sg, 1);
+ if (buf-state != CSI_BUF_PREPARED) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(buf-queue);
+ sg_init_table(buf-sg, 1);
- buf-state = CSI_BUF_NEEDS_INIT;
+ buf-state = CSI_BUF_NEEDS_INIT;
- mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}
--
1.7.0.4
Regards,
Alex
---
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: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Guennadi, On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
On Fri, 27 Jul 2012, Laurent Pinchart wrote: Hi Sylwester, On Thursday 26 July 2012 21:51:30 Sylwester Nawrocki wrote: On 07/26/2012 04:38 PM, Laurent Pinchart wrote: --- /dev/null +++ b/Documentation/devicetree/bindings/video/mipi.txt @@ -0,0 +1,5 @@ +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters + + - data-lanes : number of differential data lanes wired and actively used in + communication between the transmitter and the receiver, this + excludes the clock lane; Wouldn't it be better to use the standard bus-width DT property? I can't see any problems with using bus-width. It seems sufficient and could indeed be better, without a need to invent new MIPI-CSI specific names. That was my first RFC on that and my perspective wasn't probably broad enough. :) What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane =0; data-lanes =2 3 1; Sounds good to me. And the clock-lane could be made optional, as not all devices would need it. However, as far as I can see, there is currently no generic API for handling this kind of data structure. E.g. number of cells for the interrupts property is specified with an additional #interrupt-cells property. It would have been much easier to handle something like: data-lanes = 2, 3, 1; i.e. an array of the lane indexes. I'm fine with that. ...on a second thought: shouldn't this be handled by pinctrl? Or is it some CSI-2 module internal lane switching, not the global SoC pin function configuration? Thanks Guennadi For receivers that can't reroute lanes internally, the data-lanes property would be need to specify lanes in sequence. data-lanes =1 2 3; In this case we would be only interested in the number of cells in this property, but how it could be retrieved ? With an array, it could have been calculated from property length returned by of_property_find() (divided by sizof(u32)). Agreed. -- Regards, Laurent Pinchart --- 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: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
Hi Guennadi, On Tuesday 31 July 2012 12:58:50 Guennadi Liakhovetski wrote: On Fri, 27 Jul 2012, Laurent Pinchart wrote: On Thursday 26 July 2012 21:51:30 Sylwester Nawrocki wrote: On 07/26/2012 04:38 PM, Laurent Pinchart wrote: --- /dev/null +++ b/Documentation/devicetree/bindings/video/mipi.txt @@ -0,0 +1,5 @@ +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters + + - data-lanes : number of differential data lanes wired and actively used in +communication between the transmitter and the receiver, this +excludes the clock lane; Wouldn't it be better to use the standard bus-width DT property? I can't see any problems with using bus-width. It seems sufficient and could indeed be better, without a need to invent new MIPI-CSI specific names. That was my first RFC on that and my perspective wasn't probably broad enough. :) What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane =0; data-lanes =2 3 1; Sounds good to me. And the clock-lane could be made optional, as not all devices would need it. However, as far as I can see, there is currently no generic API for handling this kind of data structure. E.g. number of cells for the interrupts property is specified with an additional #interrupt-cells property. It would have been much easier to handle something like: data-lanes = 2, 3, 1; i.e. an array of the lane indexes. I'm fine with that. ...on a second thought: shouldn't this be handled by pinctrl? Or is it some CSI-2 module internal lane switching, not the global SoC pin function configuration? On the hardware I came across, it's handled by the CSI2 receiver, not the SoC pinmux feature. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] video_visstrim for 3.6
Hi Mauro, just in case Sascha's ACK doesn't make it on time. Could you just merge the following patches and drop the rest? . media: coda: Add driver for Coda video codec. media: Add mem2mem deinterlacing driver. We did a great effort to push Coda driver for 3.6 and it would be a pity we finally missed that deadline. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Tue, 31 Jul 2012, Laurent Pinchart wrote: Hi Guennadi, On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. 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 v7 1/2] media: add new mediabus format enums for dm365
Hi Hans and Laurent, On Mon, Jul 30, 2012 at 09:19:13PM +0200, Hans Verkuil wrote: On Mon July 30 2012 21:06:33 Laurent Pinchart wrote: Hi Hans, On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: On Sat July 28 2012 00:01:24 Sakari Ailus wrote: On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..75dc275 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -504,6 +504,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry +
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Guennadi, On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365
On Tue 31 July 2012 13:17:50 Sakari Ailus wrote: Hi Hans and Laurent, On Mon, Jul 30, 2012 at 09:19:13PM +0200, Hans Verkuil wrote: On Mon July 30 2012 21:06:33 Laurent Pinchart wrote: Hi Hans, On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: On Sat July 28 2012 00:01:24 Sakari Ailus wrote: On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..75dc275 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of the -DPCM compression and the number of bits per compressed pixel component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -504,6 +504,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 +
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Tue, 31 Jul 2012, Laurent Pinchart wrote: Hi Guennadi, On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git-tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. 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 v7 1/2] media: add new mediabus format enums for dm365
Hi Hans, Hans Verkuil wrote: On Tue 31 July 2012 13:17:50 Sakari Ailus wrote: Hi Hans and Laurent, On Mon, Jul 30, 2012 at 09:19:13PM +0200, Hans Verkuil wrote: ... And make a new pixel format if you have hardware that doesn't use zero? I think it's overkill IMHO. Could be. But I've seen only zero being used. Applications that need to process raw bayer images optimally are often very hardware specific anyway, adding the assumption that the dummy bits are zero isn't a big deal. The same might not apply as universally to yuv colour space but on the other hand one extra and operation just won't take that much time either. My experience is with encoders and decoders. Anyway, we're not using this format, and neither will we ever upstream a pixel or mbus format since it is all highly specific to our products, so there is no point in upstreaming. So I am actually OK with saying that these bits should be 0, provided 'D' is replaced by 'Z'. But I still think keeping it 'D' and allowing for any value is more generic and I expect that it is sufficient. I'm fine with defining the bits are dummy. I just wanted we make an informed decision on this, and as far as I see that's now been reached. Acked-by: Sakari Ailus sakari.ai...@iki.fi OK, then we all agree to keep PATCHv7 as is? Yes. If we later see that we need to use the format (I was thinking in-memory formats instead of media bus pixel codes, but apparently replied to this patch instead) to tell especially the unused bits are zero we can start creating more formats, but I feel it's unlikely we'd get there. Kind regards, -- Sakari Ailus sakari.ai...@iki.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: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Guennadi, On Tuesday 31 July 2012 13:29:55 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git- tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Hans,
On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
On Thu June 14 2012 16:32:23 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 |6 ++
include/linux/videodev2.h | 26
++
include/media/v4l2-ioctl.h|2 ++
5 files changed, 36 insertions(+)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c index d33ab18..141e745 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -970,6 +970,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 5ccbd46..6bf6307 100644
--- a/drivers/media/video/v4l2-dev.c
+++ b/drivers/media/video/v4l2-dev.c
@@ -597,6 +597,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 31fc2ad..a73b14e 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -212,6 +212,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO(VIDIOC_S_FBUF, INFO_FL_PRIO),
IOCTL_INFO(VIDIOC_OVERLAY, INFO_FL_PRIO),
IOCTL_INFO(VIDIOC_QBUF, 0),
+ IOCTL_INFO(VIDIOC_EXPBUF, 0),
IOCTL_INFO(VIDIOC_DQBUF, 0),
IOCTL_INFO(VIDIOC_STREAMON, INFO_FL_PRIO),
IOCTL_INFO(VIDIOC_STREAMOFF, INFO_FL_PRIO),
@@ -957,6 +958,11 @@ static long __video_do_ioctl(struct file *file,
dbgbuf(cmd, vfd, p);
break;
}
+ case VIDIOC_EXPBUF:
+ {
+ ret = ops-vidioc_expbuf(file, fh, arg);
+ break;
+ }
case VIDIOC_DQBUF:
{
struct v4l2_buffer *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 51b20f4..e8893a5 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -684,6 +684,31 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
#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)
+ * @mem_offset:buffer memory offset as returned by VIDIOC_QUERYBUF in
struct + * v4l2_buffer::m.offset (for single-plane formats) or
+ * v4l2_plane::m.offset (for multi-planar formats)
+ * @flags: flags for newly created file, currently only O_CLOEXEC is
+ * supported, refer to manual of open syscall for more details
+ *
+ * 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. Therefore this field
should not be used for any other extensions. + */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
+ __u32 mem_offset;
This should be a union identical to the m union in v4l2_plane, together with
a u32 memory field. That way you can just copy memory and m from
v4l2_plane/buffer and call expbuf. If new memory types are added in the
future, then you don't need to change this struct.
OK, reserved0 could be replace by __u32 memory. Could we have other dma-buf
export types in the future not corresponding to a memory type ? I don't see
any use case right now though.
For that matter, wouldn't it be useful to support exporting a userptr
[PATCH v4 0/5] Add new driver for generic scaler
This patch adds support for the gscaler device which is a new device for scaling and color space conversion on EXYNOS5 SoCs. This device supports the followings as key feature. 1) Input image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, TILE 2) Output image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, YUV444 3) Input rotation - 0/90/180/270 degree, X/Y Flip 4) Scale ratio - 1/16 scale down to 8 scale up 5) CSC - RGB to YUV / YUV to RGB 6) Size - 2048 x 2048 for tile or rotation - 4800 x 3344 other case changes since v3: - Rebased on latest media-tree git, branch staging/for_v3.6. http://linuxtv.org/git/media_tree.git - Addressed review comments from Sylwester Nawrocki http://patchwork.linuxtv.org/patch/13465/ http://patchwork.linuxtv.org/patch/13469/ http://patchwork.linuxtv.org/patch/13479/ http://patchwork.linuxtv.org/patch/13467/ http://patchwork.linuxtv.org/patch/13468/ Note: This patch set is based on the following two patches 1] V4L: Remove _ACTIVE from the selection target name definitions 2] v4l: add fourcc definitions for new formats Shaik Ameer Basha (2): v4l: Add new YVU420 multi planar fourcc definition media: gscaler: Add Makefile for G-Scaler Driver Sungchun Kang (3): media: gscaler: Add new driver for generic scaler media: gscaler: Add core functionality for the G-Scaler driver media: gscaler: Add m2m functionality for the G-Scaler driver Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml | 154 +++ Documentation/DocBook/media/v4l/pixfmt.xml |1 + drivers/media/video/Kconfig|8 + drivers/media/video/Makefile |2 + drivers/media/video/exynos-gsc/Makefile|3 + drivers/media/video/exynos-gsc/gsc-core.c | 1263 drivers/media/video/exynos-gsc/gsc-core.h | 537 + drivers/media/video/exynos-gsc/gsc-m2m.c | 772 drivers/media/video/exynos-gsc/gsc-regs.c | 431 +++ drivers/media/video/exynos-gsc/gsc-regs.h | 172 +++ include/linux/videodev2.h |1 + 11 files changed, 3344 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml create mode 100644 drivers/media/video/exynos-gsc/Makefile create mode 100644 drivers/media/video/exynos-gsc/gsc-core.c create mode 100644 drivers/media/video/exynos-gsc/gsc-core.h create mode 100644 drivers/media/video/exynos-gsc/gsc-m2m.c create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.c create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.h -- 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 v4 1/5] v4l: Add new YVU420 multi planar fourcc definition
This patch adds the following new fourcc definition.
For multiplanar YCrCb
- V4L2_PIX_FMT_YVU420M - 'YM21'
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml | 154
Documentation/DocBook/media/v4l/pixfmt.xml |1 +
include/linux/videodev2.h |1 +
3 files changed, 156 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
new file mode 100644
index 000..2330667
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
@@ -0,0 +1,154 @@
+refentry id=V4L2-PIX-FMT-YVU420M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_YVU420M ('YM21')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_YVU420M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_YVU420/constant
+ with planes non contiguous in memory. /refpurpose
+ /refnamediv
+
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar format, as opposed to a packed format.
+The three components are separated into three sub-images or planes.
+
+The Y plane is first. The Y plane has one byte per pixel. The Cr data
+constitutes the second plane which is half the width and half
+the height of the Y plane (and of the image). Each Cr belongs to four
+pixels, a two-by-two square of the image. For example,
+Crsubscript0/subscript belongs to Y'subscript00/subscript,
+Y'subscript01/subscript, Y'subscript10/subscript, and
+Y'subscript11/subscript. The Cb data, just like the Cr plane, constitutes
+the third plane. /para
+
+ paraIf the Y plane has pad bytes after each row, then the Cr
+and Cb planes have half as many pad bytes after their rows. In other
+words, two Cx rows (including padding) is exactly as long as one Y row
+(including padding)./para
+
+ paraconstantV4L2_PIX_FMT_YVU420M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ example
+ titleconstantV4L2_PIX_FMT_YVU420M/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ rowentry/entry/row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCrsubscript00/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;2:/entry
+ entryCrsubscript10/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ rowentry/entry/row
+ row
+ entrystart2nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ /row
+ row
+ entrystart2nbsp;+nbsp;2:/entry
+ entryCbsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ /row
+ /tbody
+ /tgroup
+ /informaltable
+ /para
+ /formalpara
+
+
[PATCH v4 2/5] media: gscaler: Add new driver for generic scaler
From: Sungchun Kang sungchun.k...@samsung.com
This patch adds support for G-Scaler (Generic Scaler) device which is a
new device for scaling and color space conversion on EXYNOS5 SoCs. This
patch adds the code for register definitions and register operations.
This device supports the followings as key feature.
1) Input image format
- RGB888/565, YUV422 1P/2P, YUV420 2P/3P, TILE
2) Output image format
- RGB888/565, YUV422 1P/2P, YUV420 2P/3P, YUV444
3) Input rotation
- 0/90/180/270 degree, X/Y Flip
4) Scale ratio
- 1/16 scale down to 8 scale up
5) CSC
- RGB to YUV / YUV to RGB
6) Size
- 2048 x 2048 for tile or rotation
- 4800 x 3344 other case
Signed-off-by: Hynwoong Kim khw0178@samsung.com
Signed-off-by: Sungchun Kang sungchun.k...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/video/exynos-gsc/gsc-regs.c | 431 +
drivers/media/video/exynos-gsc/gsc-regs.h | 172
2 files changed, 603 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.c
create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.h
diff --git a/drivers/media/video/exynos-gsc/gsc-regs.c
b/drivers/media/video/exynos-gsc/gsc-regs.c
new file mode 100644
index 000..27f5126
--- /dev/null
+++ b/drivers/media/video/exynos-gsc/gsc-regs.c
@@ -0,0 +1,431 @@
+/*
+ * Copyright (c) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series G-Scaler driver
+ *
+ * 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, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/io.h
+#include linux/delay.h
+#include mach/map.h
+
+#include gsc-core.h
+
+void gsc_hw_set_sw_reset(struct gsc_dev *dev)
+{
+ writel(GSC_SW_RESET_SRESET, dev-regs + GSC_SW_RESET);
+}
+
+int gsc_wait_reset(struct gsc_dev *dev)
+{
+ unsigned long end = jiffies + msecs_to_jiffies(50);
+ u32 cfg;
+
+ while (time_before(jiffies, end)) {
+ cfg = readl(dev-regs + GSC_SW_RESET);
+ if (!cfg)
+ return 0;
+ usleep_range(10, 20);
+ }
+
+ return -EBUSY;
+}
+
+void gsc_hw_set_frm_done_irq_mask(struct gsc_dev *dev, bool mask)
+{
+ u32 cfg;
+
+ cfg = readl(dev-regs + GSC_IRQ);
+ if (mask)
+ cfg |= GSC_IRQ_FRMDONE_MASK;
+ else
+ cfg = ~GSC_IRQ_FRMDONE_MASK;
+ writel(cfg, dev-regs + GSC_IRQ);
+}
+
+void gsc_hw_set_gsc_irq_enable(struct gsc_dev *dev, bool mask)
+{
+ u32 cfg;
+
+ cfg = readl(dev-regs + GSC_IRQ);
+ if (mask)
+ cfg |= GSC_IRQ_ENABLE;
+ else
+ cfg = ~GSC_IRQ_ENABLE;
+ writel(cfg, dev-regs + GSC_IRQ);
+}
+
+void gsc_hw_set_input_buf_masking(struct gsc_dev *dev, u32 shift,
+ bool enable)
+{
+ u32 cfg = readl(dev-regs + GSC_IN_BASE_ADDR_Y_MASK);
+ u32 mask = 1 shift;
+
+ cfg = ~mask;
+ cfg |= enable shift;
+
+ writel(cfg, dev-regs + GSC_IN_BASE_ADDR_Y_MASK);
+ writel(cfg, dev-regs + GSC_IN_BASE_ADDR_CB_MASK);
+ writel(cfg, dev-regs + GSC_IN_BASE_ADDR_CR_MASK);
+}
+
+void gsc_hw_set_output_buf_masking(struct gsc_dev *dev, u32 shift,
+ bool enable)
+{
+ u32 cfg = readl(dev-regs + GSC_OUT_BASE_ADDR_Y_MASK);
+ u32 mask = 1 shift;
+
+ cfg = ~mask;
+ cfg |= enable shift;
+
+ writel(cfg, dev-regs + GSC_OUT_BASE_ADDR_Y_MASK);
+ writel(cfg, dev-regs + GSC_OUT_BASE_ADDR_CB_MASK);
+ writel(cfg, dev-regs + GSC_OUT_BASE_ADDR_CR_MASK);
+}
+
+void gsc_hw_set_input_addr(struct gsc_dev *dev, struct gsc_addr *addr,
+ int index)
+{
+ pr_debug(src_buf[%d]: 0x%X, cb: 0x%X, cr: 0x%X, index,
+ addr-y, addr-cb, addr-cr);
+ writel(addr-y, dev-regs + GSC_IN_BASE_ADDR_Y(index));
+ writel(addr-cb, dev-regs + GSC_IN_BASE_ADDR_CB(index));
+ writel(addr-cr, dev-regs + GSC_IN_BASE_ADDR_CR(index));
+
+}
+
+void gsc_hw_set_output_addr(struct gsc_dev *dev,
+struct gsc_addr *addr, int index)
+{
+ pr_debug(dst_buf[%d]: 0x%X, cb: 0x%X, cr: 0x%X,
+ index, addr-y, addr-cb, addr-cr);
+ writel(addr-y, dev-regs + GSC_OUT_BASE_ADDR_Y(index));
+ writel(addr-cb, dev-regs + GSC_OUT_BASE_ADDR_CB(index));
+ writel(addr-cr, dev-regs + GSC_OUT_BASE_ADDR_CR(index));
+}
+
+void gsc_hw_set_input_path(struct gsc_ctx *ctx)
+{
+ struct gsc_dev *dev = ctx-gsc_dev;
+
+ u32 cfg = readl(dev-regs + GSC_IN_CON);
+ cfg = ~(GSC_IN_PATH_MASK | GSC_IN_LOCAL_SEL_MASK);
+
+ if (ctx-in_path == GSC_DMA)
+
[PATCH v4 3/5] media: gscaler: Add core functionality for the G-Scaler driver
From: Sungchun Kang sungchun.k...@samsung.com
This patch adds the core functionality for the G-Scaler driver.
Signed-off-by: Hynwoong Kim khw0178@samsung.com
Signed-off-by: Sungchun Kang sungchun.k...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/video/exynos-gsc/gsc-core.c | 1263 +
drivers/media/video/exynos-gsc/gsc-core.h | 537
2 files changed, 1800 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos-gsc/gsc-core.c
create mode 100644 drivers/media/video/exynos-gsc/gsc-core.h
diff --git a/drivers/media/video/exynos-gsc/gsc-core.c
b/drivers/media/video/exynos-gsc/gsc-core.c
new file mode 100644
index 000..defd14d
--- /dev/null
+++ b/drivers/media/video/exynos-gsc/gsc-core.c
@@ -0,0 +1,1263 @@
+/*
+ * Copyright (c) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series G-Scaler driver
+ *
+ * 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, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/version.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/bug.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/list.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/of.h
+#include media/v4l2-ioctl.h
+
+#include gsc-core.h
+
+#define GSC_CLOCK_GATE_NAMEgscl
+
+static const struct gsc_fmt gsc_formats[] = {
+ {
+ .name = RGB565,
+ .pixelformat= V4L2_PIX_FMT_RGB565X,
+ .depth = { 16 },
+ .color = GSC_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ }, {
+ .name = XRGB-8-8-8-8, 32 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB32,
+ .depth = { 32 },
+ .color = GSC_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ }, {
+ .name = YUV 4:2:2 packed, YCbYCr,
+ .pixelformat= V4L2_PIX_FMT_YUYV,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
+ }, {
+ .name = YUV 4:2:2 packed, CbYCrY,
+ .pixelformat= V4L2_PIX_FMT_UYVY,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_C,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ }, {
+ .name = YUV 4:2:2 packed, CrYCbY,
+ .pixelformat= V4L2_PIX_FMT_VYUY,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_C,
+ .corder = GSC_CRCB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_VYUY8_2X8,
+ }, {
+ .name = YUV 4:2:2 packed, YCrYCb,
+ .pixelformat= V4L2_PIX_FMT_YVYU,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CRCB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_YVYU8_2X8,
+ }, {
+ .name = YUV 4:4:4 planar, YCbYCr,
+ .pixelformat= V4L2_PIX_FMT_YUV32,
+ .depth = { 32 },
+ .color = GSC_YUV444,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 1,
+ }, {
+ .name = YUV 4:2:2 planar, Y/Cb/Cr,
+ .pixelformat= V4L2_PIX_FMT_YUV422P,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 3,
+ }, {
+ .name = YUV 4:2:2 planar, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV16,
+
[PATCH v4 4/5] media: gscaler: Add m2m functionality for the G-Scaler driver
From: Sungchun Kang sungchun.k...@samsung.com
This patch adds the memory to memory (m2m) interface functionality
for the G-Scaler driver.
Signed-off-by: Hynwoong Kim khw0178@samsung.com
Signed-off-by: Sungchun Kang sungchun.k...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/video/exynos-gsc/gsc-m2m.c | 772 ++
1 files changed, 772 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos-gsc/gsc-m2m.c
diff --git a/drivers/media/video/exynos-gsc/gsc-m2m.c
b/drivers/media/video/exynos-gsc/gsc-m2m.c
new file mode 100644
index 000..d7ecdb8
--- /dev/null
+++ b/drivers/media/video/exynos-gsc/gsc-m2m.c
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series G-Scaler driver
+ *
+ * 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, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/version.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/bug.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/list.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+
+#include media/v4l2-ioctl.h
+
+#include gsc-core.h
+
+static int gsc_m2m_ctx_stop_req(struct gsc_ctx *ctx)
+{
+ struct gsc_ctx *curr_ctx;
+ struct gsc_dev *gsc = ctx-gsc_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(gsc-m2m.m2m_dev);
+ if (!gsc_m2m_pending(gsc) || (curr_ctx != ctx))
+ return 0;
+
+ gsc_ctx_state_lock_set(GSC_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(gsc-irq_queue,
+ !gsc_ctx_state_is_set(GSC_CTX_STOP_REQ, ctx),
+ GSC_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct gsc_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(ctx-gsc_dev-pdev-dev);
+ return ret 0 ? 0 : ret;
+}
+
+static int gsc_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct gsc_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = gsc_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(ctx-gsc_dev-pdev-dev);
+
+ return 0;
+}
+
+void gsc_m2m_job_finish(struct gsc_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx-m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+ if (src_vb dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+ v4l2_m2m_buf_done(dst_vb, vb_state);
+
+ v4l2_m2m_job_finish(ctx-gsc_dev-m2m.m2m_dev,
+ ctx-m2m_ctx);
+ }
+}
+
+
+static void gsc_m2m_job_abort(void *priv)
+{
+ struct gsc_ctx *ctx = priv;
+ int ret;
+
+ ret = gsc_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
+int gsc_fill_addr(struct gsc_ctx *ctx)
+{
+ struct gsc_frame *s_frame, *d_frame;
+ struct vb2_buffer *vb = NULL;
+ int ret;
+
+ s_frame = ctx-s_frame;
+ d_frame = ctx-d_frame;
+
+ vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
+ ret = gsc_prepare_addr(ctx, vb, s_frame, s_frame-addr);
+ if (ret)
+ return ret;
+
+ vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ return gsc_prepare_addr(ctx, vb, d_frame, d_frame-addr);
+}
+
+static void gsc_m2m_device_run(void *priv)
+{
+ struct gsc_ctx *ctx = priv;
+ struct gsc_dev *gsc;
+ unsigned long flags;
+ u32 ret;
+ bool is_set = false;
+
+ if (WARN(!ctx, null hardware context\n))
+ return;
+
+ gsc = ctx-gsc_dev;
+ spin_lock_irqsave(gsc-slock, flags);
+
+ set_bit(ST_M2M_PEND, gsc-state);
+
+ /* Reconfigure hardware if the context has changed. */
+ if (gsc-m2m.ctx != ctx) {
+ pr_debug(gsc-m2m.ctx = 0x%p, current_ctx = 0x%p,
+ gsc-m2m.ctx, ctx);
+ ctx-state |= GSC_PARAMS;
+ gsc-m2m.ctx = ctx;
+ }
+
+ is_set = (ctx-state GSC_CTX_STOP_REQ) ? 1 : 0;
+ ctx-state = ~GSC_CTX_STOP_REQ;
+ if (is_set) {
+ wake_up(gsc-irq_queue);
+ goto put_device;
+ }
+
+ ret = gsc_fill_addr(ctx);
+ if (ret) {
+ pr_err(Wrong address);
+
[PATCH v4 5/5] media: gscaler: Add Makefile for G-Scaler Driver
This patch adds the Makefile for G-Scaler driver. Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/media/video/Kconfig |8 drivers/media/video/Makefile|2 ++ drivers/media/video/exynos-gsc/Makefile |3 +++ 3 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/exynos-gsc/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 99937c9..36efda9 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1215,4 +1215,12 @@ config VIDEO_MX2_EMMAPRP memory to memory. Operations include resizing and format conversion. +config VIDEO_SAMSUNG_EXYNOS_GSC +tristate Samsung Exynos G-Scaler driver +depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P +select VIDEOBUF2_DMA_CONTIG +select V4L2_MEM2MEM_DEV +help +This is v4l2 based G-Scaler driver for EXYNOS5 + endif # V4L_MEM2MEM_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index d209de0..763e8b4 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -195,6 +195,8 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/ +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ + obj-$(CONFIG_BLACKFIN) += blackfin/ obj-$(CONFIG_ARCH_DAVINCI) += davinci/ diff --git a/drivers/media/video/exynos-gsc/Makefile b/drivers/media/video/exynos-gsc/Makefile new file mode 100644 index 000..e9d7f8a --- /dev/null +++ b/drivers/media/video/exynos-gsc/Makefile @@ -0,0 +1,3 @@ +gsc-objs := gsc-core.o gsc-m2m.o gsc-regs.o + +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += gsc.o -- 1.7.0.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: [RFC] media DT bindings
Hi Guennadi,
On Tuesday 31 July 2012 11:26:27 Guennadi Liakhovetski wrote:
On Fri, 27 Jul 2012, Laurent Pinchart wrote:
Hi Sylwester,
On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
[snip]
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg =0xfe91 0xa0;
interrupts =0x880;
bus-width =16;/* #lines routed on the
board */
clock-frequency =5000;/* max clock */
#address-cells =1;
#size-cells =0;
...
ov772x-1 = {
reg =0;
This property might be redundant, we already have the client phandle
pointing to ov772x@0x21-0, which has all interesting properties inside
it. Other than there is probably no reasonable usage for it under
ceu0@0xfe91 node ?
client =ov772x@0x21-0;
local-pad = parallel-sink;
remote-pad = parallel-source;
I'm not sure I like that. Is it really needed when we already have
the child/parent properties around ?
I think it is. Both the host and the client can have multiple pads
(e.g.,
parallel / serial). These properties specify which pads are used and
make
the translation between DT data and our subdev / pad APIs simpler.
OK, sorry, but isn't it all about just specifying what sort of data bus
is used ? :-)
In some (many/most ?) cases probably, but not in all of them.
What about merging the client and remote-pad properties ? The resulting
property would then reference a pad with ov772x@0x21-0 0.
What would the 0 parameter mean then? Pad #0?
Yes.
But aren't these numbers device specific? Maybe not a huge deal, but these
numbers are defind by the driver, right? Not the DT itself. So, drivers then
will have to take care not to change their pad numbering. Whereas using
strings, we can fix strings in the common V4L DT spec and keep them standard
across devices and drivers. Then drivers might be less likely to change
these assignments randomly ;-)
Userspace applications usually rely on pad numbers as well, so I consider them
as more or less part of the ABI. If we really need to, we could add a DT pad
number - media controller pad number conversion in the driver, that would be
less expensive than pad name - pad number conversion (especially since it
would be skipped in most cases).
[snip]
I'd like just to point one detail here, as sensor subdev drivers control
their voltage regulators and RESET/STANDBY (gpio) signals, they should
also be able to control the master clock. In order to ensure proper
power
up/down sequences. It is a bad practice to enable clocks before voltage
supplies are switched on and we shouldn't have that as a general
assumption at the kernel frameworks.
One possible solution would be to have host/bridge drivers to register
a clkdev entry for I2C client device, so it can acquire the clock
through
just clk_get(). We would have to ensure the clock is not tried to be
accessed before it is registered by a bridge. This would require to add
clock handling code to all sensor/encoder subdev drivers though..
I thik it's a good practice to add clock management to subdevs anyway, and
the common clock framework should make that easy (or at least not too
difficult). We can migrate subdevs one by one as we add DT support for
them.
Yes, this would be good.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Tue 31 July 2012 13:56:14 Laurent Pinchart wrote:
Hi Hans,
On Tuesday 31 July 2012 08:33:56 Hans Verkuil wrote:
On Thu June 14 2012 16:32:23 Tomasz Stanislawski wrote:
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file
descriptor + *
+ * @fd: file descriptor associated with DMABUF (set by driver)
+ * @mem_offset: buffer memory offset as returned by VIDIOC_QUERYBUF in
struct + *v4l2_buffer::m.offset (for single-plane
formats) or
+ * v4l2_plane::m.offset (for multi-planar formats)
+ * @flags: flags for newly created file, currently only O_CLOEXEC
is
+ * supported, refer to manual of open syscall for more
details
+ *
+ * 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. Therefore this field
should not be used for any other extensions. + */
+struct v4l2_exportbuffer {
+ __u32 fd;
+ __u32 reserved0;
+ __u32 mem_offset;
This should be a union identical to the m union in v4l2_plane, together with
a u32 memory field. That way you can just copy memory and m from
v4l2_plane/buffer and call expbuf. If new memory types are added in the
future, then you don't need to change this struct.
OK, reserved0 could be replace by __u32 memory. Could we have other dma-buf
export types in the future not corresponding to a memory type ? I don't see
any use case right now though.
The memory type should be all you need. And the union is also needed since the
userptr value is unsigned long, thus ensuring that you have 64-bits available
for pointer types in the future. That's really my main point: the union should
have the same size as the union in v4l2_buffer/plane, allowing for the same
size pointers or whatever to be added in the future.
For that matter, wouldn't it be useful to support exporting a userptr buffer
at some point in the future?
Shouldn't USERPTR usage be discouraged once we get dma-buf support ?
Why? It's perfectly fine to use it and it's not going away.
I'm not saying that we should support exporting a userptr buffer as a dmabuf fd,
but I'm just wondering if that is possible at all and how difficult it would be.
Regards,
Hans
BTW, this patch series needs to be rebased to the latest for_v3.6. Quite a
few core things have changed when it comes to adding new ioctls.
--
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: [media-ctl PATCH 1/1] libv4l2subdev: Add v4l2_subdev_enum_mbus_code()
Hi Laurent,
On Tue, Jul 31, 2012 at 01:38:41PM +0200, Laurent Pinchart wrote:
Thanks for the patch.
Thanks for the comments!
On Tuesday 31 July 2012 01:16:00 Sakari Ailus wrote:
v4l2_subdev_enum_mbus_code() enumerates over supported media bus formats on
a pad.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
src/v4l2subdev.c | 23 +++
src/v4l2subdev.h | 14 ++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
index d60bd7e..6b6df0a 100644
--- a/src/v4l2subdev.c
+++ b/src/v4l2subdev.c
@@ -58,6 +58,29 @@ void v4l2_subdev_close(struct media_entity *entity)
entity-fd = -1;
}
+int v4l2_subdev_enum_mbus_code(struct media_entity *entity,
+ uint32_t *code, uint32_t pad, uint32_t index)
I would use unsigned int for the pad and index arguments to match the other
functions. We could then fix all of them in one go to use stdint types to
match the kernel API types.
I'm fine with that.
+{
+ struct v4l2_subdev_mbus_code_enum c;
+ int ret;
+
+ ret = v4l2_subdev_open(entity);
+ if (ret 0)
+ return ret;
+
+ memset(c, 0, sizeof(c));
+ c.pad = pad;
+ c.index = index;
+
+ ret = ioctl(entity-fd, VIDIOC_SUBDEV_ENUM_MBUS_CODE, c);
+ if (ret 0)
+ return -errno;
+
+ *code = c.code;
+
+ return 0;
+}
What about a higher-level API that would enumerate all formats and return a
list/array ?
The information could be stored to media entities. We could add a V4L2
subdev pointer to media entities, and have the information stored there the
first time this function is called. How about that?
On source pads the pixel code is obviously possibly dependent on the pixel
code on the sink pad so I need to store mappings from sink pad pixel code to
a list of source pad pixel code, but can it have other dependencies? None
come to mind right now, though.
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] media: gscaler: Add m2m functionality for the G-Scaler driver
On Tue 31 July 2012 14:12:32 Shaik Ameer Basha wrote:
From: Sungchun Kang sungchun.k...@samsung.com
This patch adds the memory to memory (m2m) interface functionality
for the G-Scaler driver.
Signed-off-by: Hynwoong Kim khw0178@samsung.com
Signed-off-by: Sungchun Kang sungchun.k...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/video/exynos-gsc/gsc-m2m.c | 772
++
1 files changed, 772 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos-gsc/gsc-m2m.c
diff --git a/drivers/media/video/exynos-gsc/gsc-m2m.c
b/drivers/media/video/exynos-gsc/gsc-m2m.c
new file mode 100644
index 000..d7ecdb8
--- /dev/null
+++ b/drivers/media/video/exynos-gsc/gsc-m2m.c
+static int gsc_m2m_querycap(struct file *file, void *fh,
+struct v4l2_capability *cap)
+{
+ struct gsc_ctx *ctx = fh_to_ctx(fh);
+ struct gsc_dev *gsc = ctx-gsc_dev;
+
+ strlcpy(cap-driver, gsc-pdev-name, sizeof(cap-driver));
+ strlcpy(cap-card, gsc-pdev-name, sizeof(cap-card));
+ strlcpy(cap-bus_info, platform, sizeof(cap-bus_info));
+ cap-device_caps = V4L2_CAP_STREAMING |
+ V4L2_CAP_VIDEO_CAPTURE_MPLANE |
+ V4L2_CAP_VIDEO_OUTPUT_MPLANE;
Yesterday the new V4L2_CAP_M2M_PLANE was added. You should add this
capability here. It is up to you to decide whether to remove the
CAPTURE_MPLANE and OUTPUT_MPLANE caps at the same time, or leave them for
a bit until any applications have had the chance to use the new M2M capability.
Combining the capture and output caps caused problems since apps would misdetect
this as a normal capture device instead of an M2M device. It's only for a
transition time that all three caps are allowed.
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: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Tue, 31 Jul 2012, Laurent Pinchart wrote: Hi Guennadi, On Tuesday 31 July 2012 13:29:55 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Laurent Pinchart wrote: On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote: On Thu, 26 Jul 2012, Laurent Pinchart wrote: On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote: On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote: On Fri, 25 May 2012, Sylwester Nawrocki wrote: The driver initializes all board related properties except the s_power() callback to board code. The platforms that require this callback are not supported by this driver yet for CONFIG_OF=y. Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewiczb.zolnier...@samsung.com Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com --- .../bindings/camera/samsung-s5k6aafx.txt | 57 + drivers/media/video/s5k6aa.c | 129 ++-- 2 files changed, 146 insertions(+), 40 deletions(-) create mode 100644 Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt new file mode 100644 index 000..6685a9c --- /dev/null +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t xt @@ -0,0 +1,57 @@ +Samsung S5K6AAFX camera sensor +-- + +Required properties: + +- compatible : samsung,s5k6aafx; +- reg : base address of the device on I2C bus; You said you ended up putting your sensors outside of I2C busses, is this one of changes, that are present in your git- tree but not in this series? No, I must have been not clear enough on that. Our idea was to keep I2C slave device nodes as an I2C controller's child nodes, according to the current convention. The 'sensor' nodes (the 'camera''s children) would only contain a phandle to a respective I2C slave node. This implies that we cannot access I2C bus in I2C client's device probe() callback. An actual H/W access could begin only from within and after invocation of v4l2_subdev .registered callback.. That's how I've envisioned the DT bindings for sensors as well, this sounds good. The real challenge will be to get hold of the subdev to register it without race conditions. Hrm... That's how early pre-subdev versions of soc-camera used to work, that's where all the device_video_probe() functions come from. But then we switched to dynamic i2c device registration. Do we want to switch all drivers back now?... Couldn't we temporarily use references from subdevs to hosts until the clock API is available? I don't think that requires a reference from subdevs to hosts in the DT. The subdev will need the host to be probed before a clock can be available so you won't be able to access the hardware in the probe() function in the generic case. You will need to wait until the registered() subdev operation is called, at which point the host can be accessed through the v4l2_device. Sure, I understand, but that's exactly what we wanted to avoid - succeeding client's i2c .probe() without even touching the hardware. But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in host's probe() is to only do it in a BUS_NOTIFY_BIND_DRIVER notifier. But how do we find out, that probing failed? No notifier is called in this case. We could use a time-out, but that's ugly. I think, we could ever request a new notifier for this case. We could also require client
Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
On 07/31/2012 01:05 PM, Laurent Pinchart wrote: What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane =0; data-lanes =2 3 1; Sounds good to me. And the clock-lane could be made optional, as not all devices would need it. However, as far as I can see, there is currently no generic API for handling this kind of data structure. E.g. number of cells for the interrupts property is specified with an additional #interrupt-cells property. It would have been much easier to handle something like: data-lanes = 2, 3, 1; i.e. an array of the lane indexes. I'm fine with that. ...on a second thought: shouldn't this be handled by pinctrl? Or is it some CSI-2 module internal lane switching, not the global SoC pin function configuration? On the hardware I came across, it's handled by the CSI2 receiver, not the SoC pinmux feature. Same here. Is there any hardware known to mux those MIPI-CSI D-PHY high speed differential signals with general purpose IO pins ? Or are there mostly dedicated pins used ? However, if there are cases the lane configuration is done solely at CSI2 receiver level, there seems little point in involving the pinctrl API. -- 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: [RFC] media DT bindings
On Tue, 31 Jul 2012, Laurent Pinchart wrote:
Hi Guennadi,
On Tuesday 31 July 2012 11:26:27 Guennadi Liakhovetski wrote:
On Fri, 27 Jul 2012, Laurent Pinchart wrote:
Hi Sylwester,
On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
[snip]
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg =0xfe91 0xa0;
interrupts =0x880;
bus-width =16;/* #lines routed on the
board */
clock-frequency =5000;/* max clock */
#address-cells =1;
#size-cells =0;
...
ov772x-1 = {
reg =0;
This property might be redundant, we already have the client phandle
pointing to ov772x@0x21-0, which has all interesting properties inside
it. Other than there is probably no reasonable usage for it under
ceu0@0xfe91 node ?
client =ov772x@0x21-0;
local-pad = parallel-sink;
remote-pad = parallel-source;
I'm not sure I like that. Is it really needed when we already have
the child/parent properties around ?
I think it is. Both the host and the client can have multiple pads
(e.g.,
parallel / serial). These properties specify which pads are used and
make
the translation between DT data and our subdev / pad APIs simpler.
OK, sorry, but isn't it all about just specifying what sort of data bus
is used ? :-)
In some (many/most ?) cases probably, but not in all of them.
What about merging the client and remote-pad properties ? The resulting
property would then reference a pad with ov772x@0x21-0 0.
What would the 0 parameter mean then? Pad #0?
Yes.
But aren't these numbers device specific? Maybe not a huge deal, but these
numbers are defind by the driver, right? Not the DT itself. So, drivers then
will have to take care not to change their pad numbering. Whereas using
strings, we can fix strings in the common V4L DT spec and keep them standard
across devices and drivers. Then drivers might be less likely to change
these assignments randomly ;-)
Userspace applications usually rely on pad numbers as well, so I consider
them
as more or less part of the ABI. If we really need to, we could add a DT pad
number - media controller pad number conversion in the driver, that would be
less expensive than pad name - pad number conversion (especially since it
would be skipped in most cases).
Ok, then, how about
#address-cells = 1;
#size-cells = 0;
...
ov772x-1 = {
reg = 1; /* local pad # */
client = ov772x@0x21-0 0;/* remote phandle and
pad */
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: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in Hmm, wouldn't it be the client that turns a clock on/off when needed ? I'd like to preserve this functionality, so client drivers can have full control on the power up/down sequences. While we are trying to improve the current situation... host's probe() is to only do it in a BUS_NOTIFY_BIND_DRIVER notifier. But how do we find out, that probing failed? No notifier is called in this case. We could use a time-out, but that's ugly. I think, we could ever request a new notifier for this case. We could also require client drivers to call a V4L2 function in this case, but that's not very pretty either. -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Tue, Jul 31, 2012 at 7:11 AM, Hans Verkuil hverk...@xs4all.nl wrote: For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? Why? It's perfectly fine to use it and it's not going away. I'm not saying that we should support exporting a userptr buffer as a dmabuf fd, but I'm just wondering if that is possible at all and how difficult it would be. it seems not terribly safe, since you don't really have much control over where the memory comes from w/ userptr. I'm more in favor of discouraging usage of userptr BR, -R -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On Tue, 31 Jul 2012, Sylwester Nawrocki wrote: On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in Hmm, wouldn't it be the client that turns a clock on/off when needed ? I'd like to preserve this functionality, so client drivers can have full control on the power up/down sequences. While we are trying to improve the current situation... Eventually, when the clock API is available - yes, the client would just call clk_enable() / clk_disable(). But for now isn't it host's job to do that? Or you want to add new API for that? Thanks Guennadi host's probe() is to only do it in a BUS_NOTIFY_BIND_DRIVER notifier. But how do we find out, that probing failed? No notifier is called in this case. We could use a time-out, but that's ugly. I think, we could ever request a new notifier for this case. We could also require client drivers to call a V4L2 function in this case, but that's not very pretty either. --- 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: [PULL] video_visstrim for 3.6
On Tue, Jul 31, 2012 at 08:13:59AM +0200, javier Martin wrote: On 31 July 2012 00:42, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 26-07-2012 06:36, Javier Martin escreveu: Hi Mauro, this pull request is composed of two series that provide support for two mem2mem devices: - 'm2m-deinterlace' video deinterlacer - 'coda video codec' I've included platform support for them too. The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: https://github.com/jmartinc/video_visstrim.git for_3.6 for you to fetch changes up to 9bb10266da63ae7f8f198573e099580e9f98f4e8: i.MX27: Visstrim_M10: Add support for deinterlacing driver. (2012-07-26 10:57:30 +0200) Javier Martin (5): i.MX: coda: Add platform support for coda in i.MX27. media: coda: Add driver for Coda video codec. Visstrim M10: Add support for Coda. media: Add mem2mem deinterlacing driver. i.MX27: Visstrim_M10: Add support for deinterlacing driver. arch/arm/mach-imx/clk-imx27.c |4 +- arch/arm/mach-imx/devices-imx27.h |4 + arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 49 +- arch/arm/plat-mxc/devices/Kconfig |6 +- arch/arm/plat-mxc/devices/Makefile |1 + arch/arm/plat-mxc/devices/platform-imx27-coda.c | 37 + arch/arm/plat-mxc/include/mach/devices-common.h |8 + I need ARM maintainer's ack for the patches that touch the above files. Generally: Acked-by: Sascha Hauer s.ha...@pengutronix.de I think that these are quite late for this merge window though. The pull request should have been out before the 3.5 Release. Sascha -- 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
[PATCH v5 3/5] media: gscaler: Add core functionality for the G-Scaler driver
From: Sungchun Kang sungchun.k...@samsung.com
This patch adds the core functionality for the G-Scaler driver.
Signed-off-by: Hynwoong Kim khw0178@samsung.com
Signed-off-by: Sungchun Kang sungchun.k...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/video/exynos-gsc/gsc-core.c | 1254 +
drivers/media/video/exynos-gsc/gsc-core.h | 532
2 files changed, 1786 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos-gsc/gsc-core.c
create mode 100644 drivers/media/video/exynos-gsc/gsc-core.h
diff --git a/drivers/media/video/exynos-gsc/gsc-core.c
b/drivers/media/video/exynos-gsc/gsc-core.c
new file mode 100644
index 000..d6f0b63
--- /dev/null
+++ b/drivers/media/video/exynos-gsc/gsc-core.c
@@ -0,0 +1,1254 @@
+/*
+ * Copyright (c) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series G-Scaler driver
+ *
+ * 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, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/version.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/bug.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/list.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/of.h
+#include media/v4l2-ioctl.h
+
+#include gsc-core.h
+
+#define GSC_CLOCK_GATE_NAMEgscl
+
+static const struct gsc_fmt gsc_formats[] = {
+ {
+ .name = RGB565,
+ .pixelformat= V4L2_PIX_FMT_RGB565X,
+ .depth = { 16 },
+ .color = GSC_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ }, {
+ .name = XRGB-8-8-8-8, 32 bpp,
+ .pixelformat= V4L2_PIX_FMT_RGB32,
+ .depth = { 32 },
+ .color = GSC_RGB,
+ .num_planes = 1,
+ .num_comp = 1,
+ }, {
+ .name = YUV 4:2:2 packed, YCbYCr,
+ .pixelformat= V4L2_PIX_FMT_YUYV,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_YUYV8_2X8,
+ }, {
+ .name = YUV 4:2:2 packed, CbYCrY,
+ .pixelformat= V4L2_PIX_FMT_UYVY,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_C,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_UYVY8_2X8,
+ }, {
+ .name = YUV 4:2:2 packed, CrYCbY,
+ .pixelformat= V4L2_PIX_FMT_VYUY,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_C,
+ .corder = GSC_CRCB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_VYUY8_2X8,
+ }, {
+ .name = YUV 4:2:2 packed, YCrYCb,
+ .pixelformat= V4L2_PIX_FMT_YVYU,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CRCB,
+ .num_planes = 1,
+ .num_comp = 1,
+ .mbus_code = V4L2_MBUS_FMT_YVYU8_2X8,
+ }, {
+ .name = YUV 4:4:4 planar, YCbYCr,
+ .pixelformat= V4L2_PIX_FMT_YUV32,
+ .depth = { 32 },
+ .color = GSC_YUV444,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 1,
+ }, {
+ .name = YUV 4:2:2 planar, Y/Cb/Cr,
+ .pixelformat= V4L2_PIX_FMT_YUV422P,
+ .depth = { 16 },
+ .color = GSC_YUV422,
+ .yorder = GSC_LSB_Y,
+ .corder = GSC_CBCR,
+ .num_planes = 1,
+ .num_comp = 3,
+ }, {
+ .name = YUV 4:2:2 planar, Y/CbCr,
+ .pixelformat= V4L2_PIX_FMT_NV16,
+
[PATCH v5 5/5] media: gscaler: Add Makefile for G-Scaler Driver
This patch adds the Makefile for G-Scaler driver. Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com --- drivers/media/video/Kconfig |8 drivers/media/video/Makefile|2 ++ drivers/media/video/exynos-gsc/Makefile |3 +++ 3 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/exynos-gsc/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index c128fac..9cf143a 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1260,4 +1260,12 @@ config VIDEO_MX2_EMMAPRP memory to memory. Operations include resizing and format conversion. +config VIDEO_SAMSUNG_EXYNOS_GSC +tristate Samsung Exynos G-Scaler driver +depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P +select VIDEOBUF2_DMA_CONTIG +select V4L2_MEM2MEM_DEV +help +This is v4l2 based G-Scaler driver for EXYNOS5 + endif # V4L_MEM2MEM_DRIVERS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index b7da9fa..3954f28 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -196,6 +196,8 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/ +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ + obj-$(CONFIG_BLACKFIN) += blackfin/ obj-$(CONFIG_ARCH_DAVINCI) += davinci/ diff --git a/drivers/media/video/exynos-gsc/Makefile b/drivers/media/video/exynos-gsc/Makefile new file mode 100644 index 000..e9d7f8a --- /dev/null +++ b/drivers/media/video/exynos-gsc/Makefile @@ -0,0 +1,3 @@ +gsc-objs := gsc-core.o gsc-m2m.o gsc-regs.o + +obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += gsc.o -- 1.7.0.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: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
On 07/31/2012 02:59 PM, Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Sylwester Nawrocki wrote: On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in Hmm, wouldn't it be the client that turns a clock on/off when needed ? I'd like to preserve this functionality, so client drivers can have full control on the power up/down sequences. While we are trying to improve the current situation... Eventually, when the clock API is available - yes, the client would just call clk_enable() / clk_disable(). But for now isn't it host's job to do that? Or you want to add new API for that? Indeed, looking at existing drivers, the clocks' handling is now mostly done in the host drivers. Only the omap3isp appears to do the right thing, i.e. delegating control over the clock to client drivers, but it does it with platform_data callbacks. We've already discussed adding a new API for that, http://www.mail-archive.com/linux-media@vger.kernel.org/msg35359.html However using common clock API and binding a clock to client device (either DT based or not) sounds like a best approach to me. Waiting for the common clock API to be generally available maybe we could add some clock ops at the v4l2_device ? Just a humble suggestion, I'm not sure whether it is really good and needed or not. -- 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
[PATCH v5 0/5] Add new driver for generic scaler
This patch adds support for the gscaler device which is a new device for scaling and color space conversion on EXYNOS5 SoCs. This device supports the followings as key feature. 1) Input image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, TILE 2) Output image format - RGB888/565, YUV422 1P/2P, YUV420 2P/3P, YUV444 3) Input rotation - 0/90/180/270 degree, X/Y Flip 4) Scale ratio - 1/16 scale down to 8 scale up 5) CSC - RGB to YUV / YUV to RGB 6) Size - 2048 x 2048 for tile or rotation - 4800 x 3344 other case changes since v4: - Rebased on latest media-tree git, branch staging/for_v3.6. http://linuxtv.org/git/media_tree.git - Addressed review comments from Hans Verkuil http://www.mail-archive.com/linux-media@vger.kernel.org/msg49754.html - Removed the v4l: Add fourcc definitions for new formats patch dependency. Shaik Ameer Basha (2): v4l: Add new YVU420 multi planar fourcc definition media: gscaler: Add Makefile for G-Scaler Driver Sungchun Kang (3): media: gscaler: Add new driver for generic scaler media: gscaler: Add core functionality for the G-Scaler driver media: gscaler: Add m2m functionality for the G-Scaler driver Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml | 154 +++ Documentation/DocBook/media/v4l/pixfmt.xml |1 + drivers/media/video/Kconfig|8 + drivers/media/video/Makefile |2 + drivers/media/video/exynos-gsc/Makefile|3 + drivers/media/video/exynos-gsc/gsc-core.c | 1254 drivers/media/video/exynos-gsc/gsc-core.h | 532 + drivers/media/video/exynos-gsc/gsc-m2m.c | 771 drivers/media/video/exynos-gsc/gsc-regs.c | 425 +++ drivers/media/video/exynos-gsc/gsc-regs.h | 172 +++ include/linux/videodev2.h |1 + 11 files changed, 3323 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml create mode 100644 drivers/media/video/exynos-gsc/Makefile create mode 100644 drivers/media/video/exynos-gsc/gsc-core.c create mode 100644 drivers/media/video/exynos-gsc/gsc-core.h create mode 100644 drivers/media/video/exynos-gsc/gsc-m2m.c create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.c create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.h -- 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 v5 4/5] media: gscaler: Add m2m functionality for the G-Scaler driver
From: Sungchun Kang sungchun.k...@samsung.com
This patch adds the memory to memory (m2m) interface functionality
for the G-Scaler driver.
Signed-off-by: Hynwoong Kim khw0178@samsung.com
Signed-off-by: Sungchun Kang sungchun.k...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/video/exynos-gsc/gsc-m2m.c | 771 ++
1 files changed, 771 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos-gsc/gsc-m2m.c
diff --git a/drivers/media/video/exynos-gsc/gsc-m2m.c
b/drivers/media/video/exynos-gsc/gsc-m2m.c
new file mode 100644
index 000..ea14aba
--- /dev/null
+++ b/drivers/media/video/exynos-gsc/gsc-m2m.c
@@ -0,0 +1,771 @@
+/*
+ * Copyright (c) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series G-Scaler driver
+ *
+ * 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, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/version.h
+#include linux/types.h
+#include linux/errno.h
+#include linux/bug.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/list.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+
+#include media/v4l2-ioctl.h
+
+#include gsc-core.h
+
+static int gsc_m2m_ctx_stop_req(struct gsc_ctx *ctx)
+{
+ struct gsc_ctx *curr_ctx;
+ struct gsc_dev *gsc = ctx-gsc_dev;
+ int ret;
+
+ curr_ctx = v4l2_m2m_get_curr_priv(gsc-m2m.m2m_dev);
+ if (!gsc_m2m_pending(gsc) || (curr_ctx != ctx))
+ return 0;
+
+ gsc_ctx_state_lock_set(GSC_CTX_STOP_REQ, ctx);
+ ret = wait_event_timeout(gsc-irq_queue,
+ !gsc_ctx_state_is_set(GSC_CTX_STOP_REQ, ctx),
+ GSC_SHUTDOWN_TIMEOUT);
+
+ return ret == 0 ? -ETIMEDOUT : ret;
+}
+
+static int gsc_m2m_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct gsc_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = pm_runtime_get_sync(ctx-gsc_dev-pdev-dev);
+ return ret 0 ? 0 : ret;
+}
+
+static int gsc_m2m_stop_streaming(struct vb2_queue *q)
+{
+ struct gsc_ctx *ctx = q-drv_priv;
+ int ret;
+
+ ret = gsc_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+
+ pm_runtime_put(ctx-gsc_dev-pdev-dev);
+
+ return 0;
+}
+
+void gsc_m2m_job_finish(struct gsc_ctx *ctx, int vb_state)
+{
+ struct vb2_buffer *src_vb, *dst_vb;
+
+ if (!ctx || !ctx-m2m_ctx)
+ return;
+
+ src_vb = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
+ dst_vb = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
+
+ if (src_vb dst_vb) {
+ v4l2_m2m_buf_done(src_vb, vb_state);
+ v4l2_m2m_buf_done(dst_vb, vb_state);
+
+ v4l2_m2m_job_finish(ctx-gsc_dev-m2m.m2m_dev,
+ ctx-m2m_ctx);
+ }
+}
+
+
+static void gsc_m2m_job_abort(void *priv)
+{
+ struct gsc_ctx *ctx = priv;
+ int ret;
+
+ ret = gsc_m2m_ctx_stop_req(ctx);
+ if (ret == -ETIMEDOUT)
+ gsc_m2m_job_finish(ctx, VB2_BUF_STATE_ERROR);
+}
+
+int gsc_fill_addr(struct gsc_ctx *ctx)
+{
+ struct gsc_frame *s_frame, *d_frame;
+ struct vb2_buffer *vb = NULL;
+ int ret;
+
+ s_frame = ctx-s_frame;
+ d_frame = ctx-d_frame;
+
+ vb = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
+ ret = gsc_prepare_addr(ctx, vb, s_frame, s_frame-addr);
+ if (ret)
+ return ret;
+
+ vb = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ return gsc_prepare_addr(ctx, vb, d_frame, d_frame-addr);
+}
+
+static void gsc_m2m_device_run(void *priv)
+{
+ struct gsc_ctx *ctx = priv;
+ struct gsc_dev *gsc;
+ unsigned long flags;
+ u32 ret;
+ bool is_set = false;
+
+ if (WARN(!ctx, null hardware context\n))
+ return;
+
+ gsc = ctx-gsc_dev;
+ spin_lock_irqsave(gsc-slock, flags);
+
+ set_bit(ST_M2M_PEND, gsc-state);
+
+ /* Reconfigure hardware if the context has changed. */
+ if (gsc-m2m.ctx != ctx) {
+ pr_debug(gsc-m2m.ctx = 0x%p, current_ctx = 0x%p,
+ gsc-m2m.ctx, ctx);
+ ctx-state |= GSC_PARAMS;
+ gsc-m2m.ctx = ctx;
+ }
+
+ is_set = (ctx-state GSC_CTX_STOP_REQ) ? 1 : 0;
+ ctx-state = ~GSC_CTX_STOP_REQ;
+ if (is_set) {
+ wake_up(gsc-irq_queue);
+ goto put_device;
+ }
+
+ ret = gsc_fill_addr(ctx);
+ if (ret) {
+ pr_err(Wrong address);
+
[PATCH v5 1/5] v4l: Add new YVU420 multi planar fourcc definition
This patch adds the following new fourcc definition.
For multiplanar YCrCb
- V4L2_PIX_FMT_YVU420M - 'YM21'
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
---
Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml | 154
Documentation/DocBook/media/v4l/pixfmt.xml |1 +
include/linux/videodev2.h |1 +
3 files changed, 156 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
new file mode 100644
index 000..2330667
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml
@@ -0,0 +1,154 @@
+refentry id=V4L2-PIX-FMT-YVU420M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_YVU420M ('YM21')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_YVU420M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_YVU420/constant
+ with planes non contiguous in memory. /refpurpose
+ /refnamediv
+
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar format, as opposed to a packed format.
+The three components are separated into three sub-images or planes.
+
+The Y plane is first. The Y plane has one byte per pixel. The Cr data
+constitutes the second plane which is half the width and half
+the height of the Y plane (and of the image). Each Cr belongs to four
+pixels, a two-by-two square of the image. For example,
+Crsubscript0/subscript belongs to Y'subscript00/subscript,
+Y'subscript01/subscript, Y'subscript10/subscript, and
+Y'subscript11/subscript. The Cb data, just like the Cr plane, constitutes
+the third plane. /para
+
+ paraIf the Y plane has pad bytes after each row, then the Cr
+and Cb planes have half as many pad bytes after their rows. In other
+words, two Cx rows (including padding) is exactly as long as one Y row
+(including padding)./para
+
+ paraconstantV4L2_PIX_FMT_YVU420M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ example
+ titleconstantV4L2_PIX_FMT_YVU420M/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ rowentry/entry/row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCrsubscript00/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;2:/entry
+ entryCrsubscript10/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+ rowentry/entry/row
+ row
+ entrystart2nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ /row
+ row
+ entrystart2nbsp;+nbsp;2:/entry
+ entryCbsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ /row
+ /tbody
+ /tgroup
+ /informaltable
+ /para
+ /formalpara
+
+
[PATCH v5 2/5] media: gscaler: Add new driver for generic scaler
From: Sungchun Kang sungchun.k...@samsung.com
This patch adds support for G-Scaler (Generic Scaler) device which is a
new device for scaling and color space conversion on EXYNOS5 SoCs. This
patch adds the code for register definitions and register operations.
This device supports the followings as key feature.
1) Input image format
- RGB888/565, YUV422 1P/2P, YUV420 2P/3P, TILE
2) Output image format
- RGB888/565, YUV422 1P/2P, YUV420 2P/3P, YUV444
3) Input rotation
- 0/90/180/270 degree, X/Y Flip
4) Scale ratio
- 1/16 scale down to 8 scale up
5) CSC
- RGB to YUV / YUV to RGB
6) Size
- 2048 x 2048 for tile or rotation
- 4800 x 3344 other case
Signed-off-by: Hynwoong Kim khw0178@samsung.com
Signed-off-by: Sungchun Kang sungchun.k...@samsung.com
Signed-off-by: Shaik Ameer Basha shaik.am...@samsung.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/video/exynos-gsc/gsc-regs.c | 425 +
drivers/media/video/exynos-gsc/gsc-regs.h | 172
2 files changed, 597 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.c
create mode 100644 drivers/media/video/exynos-gsc/gsc-regs.h
diff --git a/drivers/media/video/exynos-gsc/gsc-regs.c
b/drivers/media/video/exynos-gsc/gsc-regs.c
new file mode 100644
index 000..0d8625f
--- /dev/null
+++ b/drivers/media/video/exynos-gsc/gsc-regs.c
@@ -0,0 +1,425 @@
+/*
+ * Copyright (c) 2011 - 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung EXYNOS5 SoC series G-Scaler driver
+ *
+ * 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, either version 2 of the License,
+ * or (at your option) any later version.
+ */
+
+#include linux/io.h
+#include linux/delay.h
+#include mach/map.h
+
+#include gsc-core.h
+
+void gsc_hw_set_sw_reset(struct gsc_dev *dev)
+{
+ writel(GSC_SW_RESET_SRESET, dev-regs + GSC_SW_RESET);
+}
+
+int gsc_wait_reset(struct gsc_dev *dev)
+{
+ unsigned long end = jiffies + msecs_to_jiffies(50);
+ u32 cfg;
+
+ while (time_before(jiffies, end)) {
+ cfg = readl(dev-regs + GSC_SW_RESET);
+ if (!cfg)
+ return 0;
+ usleep_range(10, 20);
+ }
+
+ return -EBUSY;
+}
+
+void gsc_hw_set_frm_done_irq_mask(struct gsc_dev *dev, bool mask)
+{
+ u32 cfg;
+
+ cfg = readl(dev-regs + GSC_IRQ);
+ if (mask)
+ cfg |= GSC_IRQ_FRMDONE_MASK;
+ else
+ cfg = ~GSC_IRQ_FRMDONE_MASK;
+ writel(cfg, dev-regs + GSC_IRQ);
+}
+
+void gsc_hw_set_gsc_irq_enable(struct gsc_dev *dev, bool mask)
+{
+ u32 cfg;
+
+ cfg = readl(dev-regs + GSC_IRQ);
+ if (mask)
+ cfg |= GSC_IRQ_ENABLE;
+ else
+ cfg = ~GSC_IRQ_ENABLE;
+ writel(cfg, dev-regs + GSC_IRQ);
+}
+
+void gsc_hw_set_input_buf_masking(struct gsc_dev *dev, u32 shift,
+ bool enable)
+{
+ u32 cfg = readl(dev-regs + GSC_IN_BASE_ADDR_Y_MASK);
+ u32 mask = 1 shift;
+
+ cfg = ~mask;
+ cfg |= enable shift;
+
+ writel(cfg, dev-regs + GSC_IN_BASE_ADDR_Y_MASK);
+ writel(cfg, dev-regs + GSC_IN_BASE_ADDR_CB_MASK);
+ writel(cfg, dev-regs + GSC_IN_BASE_ADDR_CR_MASK);
+}
+
+void gsc_hw_set_output_buf_masking(struct gsc_dev *dev, u32 shift,
+ bool enable)
+{
+ u32 cfg = readl(dev-regs + GSC_OUT_BASE_ADDR_Y_MASK);
+ u32 mask = 1 shift;
+
+ cfg = ~mask;
+ cfg |= enable shift;
+
+ writel(cfg, dev-regs + GSC_OUT_BASE_ADDR_Y_MASK);
+ writel(cfg, dev-regs + GSC_OUT_BASE_ADDR_CB_MASK);
+ writel(cfg, dev-regs + GSC_OUT_BASE_ADDR_CR_MASK);
+}
+
+void gsc_hw_set_input_addr(struct gsc_dev *dev, struct gsc_addr *addr,
+ int index)
+{
+ pr_debug(src_buf[%d]: 0x%X, cb: 0x%X, cr: 0x%X, index,
+ addr-y, addr-cb, addr-cr);
+ writel(addr-y, dev-regs + GSC_IN_BASE_ADDR_Y(index));
+ writel(addr-cb, dev-regs + GSC_IN_BASE_ADDR_CB(index));
+ writel(addr-cr, dev-regs + GSC_IN_BASE_ADDR_CR(index));
+
+}
+
+void gsc_hw_set_output_addr(struct gsc_dev *dev,
+struct gsc_addr *addr, int index)
+{
+ pr_debug(dst_buf[%d]: 0x%X, cb: 0x%X, cr: 0x%X,
+ index, addr-y, addr-cb, addr-cr);
+ writel(addr-y, dev-regs + GSC_OUT_BASE_ADDR_Y(index));
+ writel(addr-cb, dev-regs + GSC_OUT_BASE_ADDR_CB(index));
+ writel(addr-cr, dev-regs + GSC_OUT_BASE_ADDR_CR(index));
+}
+
+void gsc_hw_set_input_path(struct gsc_ctx *ctx)
+{
+ struct gsc_dev *dev = ctx-gsc_dev;
+
+ u32 cfg = readl(dev-regs + GSC_IN_CON);
+ cfg = ~(GSC_IN_PATH_MASK | GSC_IN_LOCAL_SEL_MASK);
+
+ if (ctx-in_path == GSC_DMA)
+
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. I am not sure DMABUF even supports transmitting data efficiently to userspace. In my understanding, it's meant for transmitting data between DSP's bypassing userspace entirely, in other words the exact opposite of what USERBUF does. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. hmm, this sounds like the problem is device pre-allocating buffers? Anyways, last time I looked, the vb2 core supported changing dmabuf fd each time you QBUF, in a similar way to what you can do w/ userptr. So that seems to get you the advantages you miss w/ mmap without the pitfalls of userptr. I am not sure DMABUF even supports transmitting data efficiently to userspace. In my understanding, it's meant for transmitting data between DSP's bypassing userspace entirely, in other words the exact opposite of what USERBUF does. well, dmabuf's can be mmap'd.. so it is more a matter of where the buffer gets allocated, malloc() or from some driver (v4l2 or other). There are a *ton* of ways userspace allocated memory can go badly, esp. if the hw has special requirements about memory (GFP_DMA32 in a system w/ PAE/LPAE, certain ranges of memory, certain alignment of memory, etc). BR, -R -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 17:03:52 Rob Clark, vous avez écrit : On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont r...@remlab.net wrote: Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. hmm, this sounds like the problem is device pre-allocating buffers? Basically, yes. Anyways, last time I looked, the vb2 core supported changing dmabuf fd each time you QBUF, in a similar way to what you can do w/ userptr. So that seems to get you the advantages you miss w/ mmap without the pitfalls of userptr. It might work albeit with a higher system calls count overhead. But what about libv4l2 transparent format conversion? Emulated USERBUF, with MMAP in the back-end would provide by far the least overhead. I don't see how DMABUF would work there. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: mx2_camera: Fix clock handling for i.MX27.
Hi Javier
Thanks for the patch. Let me try to understand what it is doing, please,
correct any my mistakes.
On Thu, 26 Jul 2012, Javier Martin wrote:
This driver wasn't converted to the new clock framework
(e038ed50a4a767add205094c035b6943e7b30140).
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/mx2_camera.c | 67
++
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c
b/drivers/media/video/mx2_camera.c
index 3c38b5f..88dcae6 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -273,7 +273,7 @@ struct mx2_camera_dev {
struct device *dev;
struct soc_camera_host soc_host;
struct soc_camera_device *icd;
- struct clk *clk_csi, *clk_emma;
+ struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
unsigned intirq_csi, irq_emma;
void __iomem*base_csi, *base_emma;
@@ -436,7 +436,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev
*pcdev)
{
unsigned long flags;
- clk_disable(pcdev-clk_csi);
+ if (cpu_is_mx27())
+ clk_disable_unprepare(pcdev-clk_csi);
This tells me, there are already 2 things going on here:
1. add clock-(un)prepare operations to enable / disable. Is this a problem
atm? is the driver non-functional without this change or is it just an API
correctness change? I thought you replied to this already, but
unfortunately I couldn't find that your reply again, sorry.
2. use clocks only on i.MX27
writel(0, pcdev-base_csi + CSICR1);
if (cpu_is_mx27()) {
writel(0, pcdev-base_emma + PRP_CNTL);
@@ -464,9 +465,11 @@ static int mx2_camera_add_device(struct
soc_camera_device *icd)
if (pcdev-icd)
return -EBUSY;
- ret = clk_enable(pcdev-clk_csi);
- if (ret 0)
- return ret;
+ if (cpu_is_mx27()) {
+ ret = clk_prepare_enable(pcdev-clk_csi);
+ if (ret 0)
+ return ret;
+ }
Same two as above.
csicr1 = CSICR1_MCLKEN;
@@ -1675,23 +1678,12 @@ static int __devinit mx27_camera_emma_init(struct
mx2_camera_dev *pcdev)
goto exit_iounmap;
}
- pcdev-clk_emma = clk_get(NULL, emma);
- if (IS_ERR(pcdev-clk_emma)) {
- err = PTR_ERR(pcdev-clk_emma);
- goto exit_free_irq;
- }
-
- clk_enable(pcdev-clk_emma);
-
err = mx27_camera_emma_prp_reset(pcdev);
if (err)
- goto exit_clk_emma_put;
+ goto exit_free_irq;
return err;
-exit_clk_emma_put:
- clk_disable(pcdev-clk_emma);
- clk_put(pcdev-clk_emma);
exit_free_irq:
free_irq(pcdev-irq_emma, pcdev);
exit_iounmap:
@@ -1714,6 +1706,7 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
res_csi = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq_csi = platform_get_irq(pdev, 0);
+
if (res_csi == NULL || irq_csi 0) {
dev_err(pdev-dev, Missing platform resources data\n);
err = -ENODEV;
@@ -1727,11 +1720,26 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit;
}
- pcdev-clk_csi = clk_get(pdev-dev, NULL);
- if (IS_ERR(pcdev-clk_csi)) {
- dev_err(pdev-dev, Could not get csi clock\n);
- err = PTR_ERR(pcdev-clk_csi);
- goto exit_kfree;
+ if (cpu_is_mx27()) {
+ pcdev-clk_csi = devm_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);
+ goto exit_kfree;
+ }
+ pcdev-clk_emma_ipg = devm_clk_get(pdev-dev, emma-ipg);
+ if (IS_ERR(pcdev-clk_emma_ipg)) {
+ err = PTR_ERR(pcdev-clk_emma_ipg);
+ goto exit_kfree;
+ }
+ pcdev-clk_emma_ahb = devm_clk_get(pdev-dev, emma-ahb);
+ if (IS_ERR(pcdev-clk_emma_ahb)) {
+ err = PTR_ERR(pcdev-clk_emma_ahb);
+ goto exit_kfree;
+ }
+ clk_prepare_enable(pcdev-clk_csi);
+ clk_prepare_enable(pcdev-clk_emma_ipg);
+ clk_prepare_enable(pcdev-clk_emma_ahb);
}
pcdev-res_csi = res_csi;
This does:
1. add clock-(un)prepare operations to enable / disable.
2. use clocks only on i.MX27
3. switch to managed clock requesting
4. groups clk_get(_devm)() and clk_prepare(_enable)() calls together
@@ -1827,8 +1835,8 @@ exit_free_emma:
eallocctx:
if (cpu_is_mx27()) {
free_irq(pcdev-irq_emma, pcdev);
- clk_disable(pcdev-clk_emma);
-
[GIT PULL for 3.6-rc1] media updates part 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus For the second part of media patches: - radio API: add support to work with radio frequency bands; - new AM/FM radio drivers: radio-shark, radio-shark2; - new Remote Controller USB driver: iguanair; - conversion of several drivers to the v4l2 core control framework; - new board additions at existing drivers; - the remaining (and vast majority of the patches) are due to drivers/DocBook fixes/cleanups. - - The following changes since commit 2cefabc00ffdc1f22f960df946ae41b163081d5e: v4l: Export v4l2-common.h in include/linux/Kbuild (2012-07-12 03:27:39 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to 4d98015eef6fa97b0cbba7310041ab75b223524b: [media] tlg2300: Declare MODULE_FIRMWARE usage (2012-07-30 23:46:53 -0300) - Alan Cox (3): [media] ov9640: fix missing break [media] cx25821,medusa: incorrect check on decoder type [media] az6007: fix incorrect memcpy Anton Blanchard (3): [media] cx23885: Silence unknown command warnings [media] winbond-cir: Fix txandrx module info [media] winbond-cir: Initialise timeout, driver_type and allowed_protos Antonio Ospite (2): [media] gspca_kinect: remove traces of the gspca control mechanism [media] gspca_ov534: Convert to the control framework Dan Carpenter (4): [media] tvp5150: signedness bug in tvp5150_selmux() [media] tuner-xc2028: fix = vs == typo [media] tuner-xc2028: unlock on error in xc2028_get_afc() [media] dib8000: move dereference after check for NULL Daniel Drake (1): [media] via-camera: pass correct format settings to sensor David Dillow (1): [media] cx231xx: don't DMA to random addresses Devendra Naga (2): [media] staging/media/dt3155v4l: use module_pci_driver macro [media] staging/media/solo6x10: use module_pci_driver macro Devin Heitmueller (6): [media] cx25840: fix regression in HVR-1800 analog support [media] cx25840: fix regression in analog support hue/saturation controls [media] cx25840: fix regression in HVR-1800 analog audio [media] cx25840: fix vsrc/hsrc usage on cx23888 designs [media] cx23885: make analog support work for HVR_1250 (cx23885 variant) [media] cx23885: add support for HVR-1255 analog (cx23888 variant) Douglas Bagnall (1): [media] Avoid sysfs oops when an rc_dev's raw device is absent Dror Cohen (1): [media] media/video: vpif: fixed vpfe-vpif typo Du, Changbin (1): [media] rc: ati_remote.c: code style fixing Duan Jiong (2): [media] smiapp-core.c: remove duplicated include [media] pms.c: remove duplicated include Emil Goode (1): [media] lirc: fix non-ANSI function declaration warning Ezequiel García (11): [media] saa7164: Remove useless struct i2c_algo_bit_data [media] cx23885: Remove useless struct i2c_algo_bit_data [media] cx231xx: Remove useless struct i2c_algo_bit_data [media] cx25821: Remove useless struct i2c_algo_bit_data [media] saa7164: Remove unused saa7164_call_i2c_clients() [media] saa7164: Replace struct memcpy with struct assignment [media] cx23885: Replace struct memcpy with struct assignment [media] cx231xx: Replace struct memcpy with struct assignment [media] cx25821: Replace struct memcpy with struct assignment [media] v4l2-dev.c: Move video_put() after debug printk [media] cx25821: Remove bad strcpy to read-only char* Federico Vaga (1): [media] adv7180.c: convert to v4l2 control framework Fengguang Wu (1): [media] pms: fix build error in pms_probe() Hans Verkuil (49): [media] Fix VIDIOC_TRY_EXT_CTRLS regression [media] gspca-conex: convert to the control framework [media] gspca-cpia1: convert to the control framework [media] gspca-etoms: convert to the control framework [media] gspca-jeilinj: convert to the control framework [media] gspca-konica: convert to the control framework [media] gspca-mr97310a: convert to the control framework [media] nw80x: convert to the control framework [media] ov519: convert to the control framework [media] ov534_9: convert to the control framework [media] es401: convert to the control framework [media] spca1528: convert to the control framework [media] spca500: convert to the control framework [media] spca501: convert to the control framework [media] gspca-spca501: remove old function prototypes [media] spca505: convert to the control framework [media] spca506: convert to the control framework [media] spca508: convert to
Re: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Hi Rémi, On Tuesday 31 July 2012 16:39:00 Rémi Denis-Courmont wrote: Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. Could you please share your use case(s) with us ? I am not sure DMABUF even supports transmitting data efficiently to userspace. In my understanding, it's meant for transmitting data between DSP's bypassing userspace entirely, in other words the exact opposite of what USERBUF does. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for July 31 (media/radio-tea5777)
On 07/30/2012 10:26 PM, Stephen Rothwell wrote: Hi all, Changes since 20120730: on i386: drivers/built-in.o: In function `radio_tea5777_set_freq': radio-tea5777.c:(.text+0x4d8704): undefined reference to `__udivdi3' -- ~Randy -- 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: mx2_camera: Fix clock handling for i.MX27.
Hi Guennadi,
On Tue, Jul 31, 2012 at 05:14:25PM +0200, Guennadi Liakhovetski wrote:
Hi Javier
@@ -436,7 +436,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev
*pcdev)
{
unsigned long flags;
- clk_disable(pcdev-clk_csi);
+ if (cpu_is_mx27())
+ clk_disable_unprepare(pcdev-clk_csi);
This tells me, there are already 2 things going on here:
1. add clock-(un)prepare operations to enable / disable. Is this a problem
atm? is the driver non-functional without this change or is it just an API
correctness change? I thought you replied to this already, but
unfortunately I couldn't find that your reply again, sorry.
Since the common clock framework clk_prepare is mandatory.
Sascha
--
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: set default protocol for TerraTec Cinergy XXS to nec
On 07/30/2012 06:13 PM, Mauro Carvalho Chehab wrote:
Em 16-07-2012 17:22, Toralf Förster escreveu:
For a TerraTec Cinergy XXS USB stick (Bus 001 Device 008: ID 0ccd:00ab
TerraTec Electronic GmbH )
I've to switch the protocol every time after plugin to get (at least few)
keys working :
$ sudo ir-keytable --protocol=nec --sysdev=`ir-keytable 21 | head -n 1 |
cut -f5 -d'/'`
/me wonders whether nec should be set as the default for this key in
kernel or not
It makes sense to patch it to use the nec protocol. If not all keys are
working, it also makes
sense to fix the kernel table to handle all codes, or to point to a new table
where all
Terratec keys are defined.
Could you please write such patch?
Thank you!
Mauro
I tried it, but the attached (naive) approach doesn't work.
The kernel dmesg shows kernel: Registered IR keymap rc-dib0700-nec
but keys aren't recognized.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 510001d..46215cc 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -4276,8 +4276,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
},
{ Terratec Cinergy T USB XXS (HD)/ T3,
{ dib0700_usb_id_table[33],
- dib0700_usb_id_table[52],
- dib0700_usb_id_table[60], NULL},
+ dib0700_usb_id_table[52], NULL},
{ NULL },
},
{ TechniSat AirStar TeleStick 2,
@@ -4301,6 +4300,45 @@ struct dvb_usb_device_properties dib0700_devices[] = {
.change_protocol = dib0700_change_protocol,
},
}, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
+
+ .num_adapters = 1,
+ .adapter = {
+ {
+ .num_frontends = 1,
+ .fe = {{
+.caps = DVB_USB_ADAP_HAS_PID_FILTER | DVB_USB_ADAP_PID_FILTER_CAN_BE_TURNED_OFF,
+.pid_filter_count = 32,
+.pid_filter = stk70x0p_pid_filter,
+.pid_filter_ctrl = stk70x0p_pid_filter_ctrl,
+.frontend_attach = stk7770p_frontend_attach,
+.tuner_attach = dib7770p_tuner_attach,
+
+DIB0700_DEFAULT_STREAMING_CONFIG(0x02),
+ }},
+.size_of_priv =
+ sizeof(struct dib0700_adapter_state),
+ },
+ },
+
+ .num_device_descs = 1,
+ .devices = {
+ { Terratec Cinergy T USB XXS (HD)/ T3 _2,
+{ dib0700_usb_id_table[60], NULL},
+{ NULL },
+ },
+ },
+
+ .rc.core = {
+ .rc_interval = DEFAULT_RC_INTERVAL,
+ .rc_codes = RC_MAP_DIB0700_NEC_TABLE,
+ .module_name = dib0700,
+ .rc_query = dib0700_rc_query_old_firmware,
+ .allowed_protos = RC_TYPE_RC5 |
+ RC_TYPE_RC6 |
+ RC_TYPE_NEC,
+ .change_protocol = dib0700_change_protocol,
+ },
+ }, { DIB0700_DEFAULT_DEVICE_PROPERTIES,
.num_adapters = 1,
.adapter = {
{
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Em 17-07-2012 19:46, Laurent Pinchart escreveu: Hi Mauro, On Tuesday 17 July 2012 14:30:53 Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. Great news! The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. Sakari and I will spend time on the long-awaited media controller library in a couple of weeks, I hope to have results to present during the summit. Great! Depending on the audience, I would also be interested in getting feedback from SoC vendors who are not (yet) active in the V4L2 community on our approach and how we could best help them. This could include discussions about Android, as I believe we need to push V4L2 on that platform. Guennadi's recent work on an Android V4L2 camera library is a good first step in that direction. Excelent idea. I'll be adding it at the topics proposal summary. Thanks, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Em 21-07-2012 02:06, Guennadi Liakhovetski escreveu: Hi Mauro On Tue, 17 Jul 2012, Guennadi Liakhovetski wrote: Hi Mauro On Tue, 17 Jul 2012, Mauro Carvalho Chehab wrote: As we did in 2012, we're planning to do a media summit again at KS/2012. The KS/2012 will happen in San Diego, CA, US, between Aug 26-28, just before the LinuxCon North America. In order to do it, I'd like to know who is interested on participate, and to get proposals about what subjects will be discussed there, in order to start planning the agenda. I'd love to attend, especially since, as you have seen, I've started doing some work on V4L DT bindings, but so far it very much looks like I won't be able to do so unfortunately. Things change and sometimes also to the better:-) Looks like I'll be able to attend actually. So, please add me to the list. Great to know! Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Media summit/KS-2012 proposals
In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media summit/KS-2012 proposals
Em 31-07-2012 14:58, Mauro Carvalho Chehab escreveu: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Of course I am missing something: for the DT, ALSA and ARM proposals, we'll need attendants from those subsystems ;) Are there other proposals or people intending to participate? Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [PATCHv2 3/9] v4l: add buffer exporting via dmabuf
Le mardi 31 juillet 2012 19:28:12 Laurent Pinchart, vous avez écrit : Hi Rémi, On Tuesday 31 July 2012 16:39:00 Rémi Denis-Courmont wrote: Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : For that matter, wouldn't it be useful to support exporting a userptr buffer at some point in the future? Shouldn't USERPTR usage be discouraged once we get dma-buf support ? USERPTR, where available, is currently the only way to perform zero-copy from kernel to userspace. READWRITE does not support zero-copy at all. MMAP only supports zero-copy if userspace knows a boundary on the number of concurrent buffers *and* the device can deal with that number of buffers; in general, MMAP requires memory copying. Could you please share your use case(s) with us ? I want to receive the video buffers in user space for processing. Typically processing is software encoding or conversion. That's what virtually any V4L application does on the desktop... -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- 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: [Workshop-2011] Media summit at the Kernel Summit - was: Fwd: Re: [Ksummit-2012-discuss] Organising Mini Summits within the Kernel Summit
Em 24-07-2012 21:17, Naveen KRISHNAMURTHY escreveu: Hello Mauro, We would like to participate in the media summit at San Diego. Can you please reserve 2 seats for us. Who are you planning to send to the media summit? If possible we would like to reserve a session to present how we have used the linuxTV to model our devices and support our use cases. We will also consolidate and pass on a list of questions related to spec ambiguities and hope to get it clarified during the summit! Can you please confirm back on the feasibility of our attendance? I'll be doing it along this week. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Workshop-2011] Media summit/KS-2012 proposals
Mauro, Can you add Sri Deevi to the list too? Thanks, Palash -Original Message- From: workshop-2011-boun...@linuxtv.org [mailto:workshop-2011-boun...@linuxtv.org] On Behalf Of Mauro Carvalho Chehab Sent: Tuesday, July 31, 2012 10:58 AM To: workshop-2...@linuxtv.org; Linux Media Mailing List Subject: [Workshop-2011] Media summit/KS-2012 proposals In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback - how to help them to go upstream - Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Regards, Mauro ___ Workshop-2011 mailing list workshop-2...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/workshop-2011 Conexant E-mail Firewall (Conexant.Com) made the following annotations - ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** - -- 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: Media summit/KS-2012 proposals
Hi I would like to participate in the workshop. Can you please add me to the list ? Thanks Sri Mensagem original Assunto: Media summit/KS-2012 proposals Data: Tue, 31 Jul 2012 14:58:23 -0300 De: Mauro Carvalho Chehab mche...@redhat.com Para: workshop-2...@linuxtv.org, Linux Media Mailing List linux-media@vger.kernel.org In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback - how to help them to go upstream - Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Regards, Mauro Conexant E-mail Firewall (Conexant.Com) made the following annotations - ** Legal Disclaimer This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you. ** - -- 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:Tue Jul 31 19:00:24 CEST 2012 git hash:24ed693da0cefede7382d498dd5e9a83f0a21c38 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: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS 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: ERRORS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS 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: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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
RE: [PATCH] media: mx3_camera: buf_init() add buffer state check
Hi Guennadi,
On Mon, 30 Jul 2012, Alex Gershgorin wrote:
This patch check the state of the buffer when calling buf_init() method.
The thread
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587
also includes report witch can show the problem. This patch solved the
problem.
Both MMAP and USERPTR methods was successfully tested.
Signed-off-by: Alex Gershgorin al...@meprolight.com
---
drivers/media/video/mx3_camera.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index f13643d..950a8fe 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb)
Sorry, don't understand. As we see in the thread, mentioned above, the
Oops happened in mx3_videobuf_release(). If my analysis was correct in
that thread, that Oops happened, when .buf_cleanup() was called without
.buf_init() being called. This your patch modifies mx3_videobuf_init().
which isn't even called in the problem case. How does this help?
Sorry for not quite a clear explanation, I will explain in more details.
if you divide the report into two parts:
1) USERPTR method Oops happened as a result discontiguous memory allocation
2) USERPTR method use framebuffer memory allocation video starting, but after
a few seconds the video freezes.
if we consider the first part of the report, your analysis is absolutely
correct and unfortunately this patch does not solve the problems mentioned
in the thread.
This patch solves a problem that is described in the second part of the
report.
Ok, I understand now what this patch fixes, but I still don't understand
what the problem is and how this patch fixes it. AFAICS, there should be
nothing wrong with calling mx3_videobuf_init() each time a buffer gets
queued.
I only see the problem when the user implements USERPTR method :-)
I suspect, it's just one of those 4 lines of code, that you put
under if (buf-state != CSI_BUF_PREPARED), that breaks it. Could you
I think the best way to make sure this solves the problem is to test it, and
that is what I did :-)
please try to find out which exactly line it is? Just try to use your if
(...) with each of them separately. My guess goes for
buf-state = CSI_BUF_NEEDS_INIT;
but it would help if you could verify it.
mx3_camera uses slave dma API of the dmaengine.
In MMAP and USERPTR methods, the buffer which had been prepared already
have a descriptor for transaction and does not need additional descriptor.
If user implement MMAP method, there is no problem because
mx3_videobuf_init() happens at REQBUFS time
and we have only one descriptor for transaction per video buffer.
As you mentioned, In case of USERPTR method mx3_videobuf_init() happens at QBUF
time.
In my opinion there are two problems:
1) During QBUF there is no need to get a new descriptor for the transaction if
it has been already obtained.
2) The second problem derives from the first as the number of descriptors for
each channel is limited and very quickly
we reach the maximum permitted number of descriptors. As a results of that,
the video freezes.
This patch solves the two problems.
Regards,
Alex
struct mx3_camera_dev *mx3_cam = ici-priv;
struct mx3_camera_buffer *buf = to_mx3_vb(vb);
- /* This is for locking debugging only */
- INIT_LIST_HEAD(buf-queue);
- sg_init_table(buf-sg, 1);
+ if (buf-state != CSI_BUF_PREPARED) {
+ /* This is for locking debugging only */
+ INIT_LIST_HEAD(buf-queue);
+ sg_init_table(buf-sg, 1);
- buf-state = CSI_BUF_NEEDS_INIT;
+ buf-state = CSI_BUF_NEEDS_INIT;
- mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ mx3_cam-buf_total += vb2_plane_size(vb, 0);
+ }
return 0;
}
--
1.7.0.4
Regards,
Alex
---
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: [Workshop-2011] Media summit/KS-2012 proposals
Hi Mauro, On Tuesday 31 July 2012 14:58:23 Mauro Carvalho Chehab wrote: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|== === Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media ControllerSteven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? I think Hans Verkuil is. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 RESEND] [media] dvb: add support for Thomson DTT7520X
[media] dvb: add support for Thomson DTT7520X
Add support for Thomson DTT7520X pll needed by
ngene card Terratec Cynergy 2400i DT
Signed-off-by: Patrice Chotard patricechot...@free.fr
---
drivers/media/dvb/frontends/dvb-pll.c | 26 ++
drivers/media/dvb/frontends/dvb-pll.h |1 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/frontends/dvb-pll.c
b/drivers/media/dvb/frontends/dvb-pll.c
index 1ab3483..6d8fe88 100644
--- a/drivers/media/dvb/frontends/dvb-pll.c
+++ b/drivers/media/dvb/frontends/dvb-pll.c
@@ -116,6 +116,31 @@ static struct dvb_pll_desc dvb_pll_thomson_dtt759x = {
},
};
+static void thomson_dtt7520x_bw(struct dvb_frontend *fe, u8 *buf)
+{
+ u32 bw = fe-dtv_property_cache.bandwidth_hz;
+ if (bw == 800)
+ buf[3] ^= 0x10;
+}
+
+static struct dvb_pll_desc dvb_pll_thomson_dtt7520x = {
+ .name = Thomson dtt7520x,
+ .min = 18500,
+ .max = 9,
+ .set = thomson_dtt7520x_bw,
+ .iffreq = 3617,
+ .count = 7,
+ .entries = {
+ { 30500, 17, 0xb4, 0x12 },
+ { 40500, 17, 0xbc, 0x12 },
+ { 44500, 17, 0xbc, 0x12 },
+ { 46500, 17, 0xf4, 0x18 },
+ { 73500, 17, 0xfc, 0x18 },
+ { 83500, 17, 0xbc, 0x18 },
+ { 9, 17, 0xfc, 0x18 },
+ },
+};
+
static struct dvb_pll_desc dvb_pll_lg_z201 = {
.name = LG z201,
.min = 17400,
@@ -513,6 +538,7 @@ static struct dvb_pll_desc *pll_list[] = {
[DVB_PLL_UNDEFINED] = NULL,
[DVB_PLL_THOMSON_DTT7579]= dvb_pll_thomson_dtt7579,
[DVB_PLL_THOMSON_DTT759X]= dvb_pll_thomson_dtt759x,
+ [DVB_PLL_THOMSON_DTT7520X] = dvb_pll_thomson_dtt7520x,
[DVB_PLL_LG_Z201]= dvb_pll_lg_z201,
[DVB_PLL_UNKNOWN_1] = dvb_pll_unknown_1,
[DVB_PLL_TUA6010XS] = dvb_pll_tua6010xs,
diff --git a/drivers/media/dvb/frontends/dvb-pll.h
b/drivers/media/dvb/frontends/dvb-pll.h
index 0869643..4de754f 100644
--- a/drivers/media/dvb/frontends/dvb-pll.h
+++ b/drivers/media/dvb/frontends/dvb-pll.h
@@ -27,6 +27,7 @@
#define DVB_PLL_SAMSUNG_TBDU18132 16
#define DVB_PLL_SAMSUNG_TBMU24112 17
#define DVB_PLL_TDEE4 18
+#define DVB_PLL_THOMSON_DTT7520X 19
/**
* Attach a dvb-pll to the supplied frontend structure.
-- 1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats
Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16
and V4L2_PIX_FMT_NV24 formats.
Existing h/w IPs, such as decoders, operate on such separate luma and chroma
buffers.
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
include/linux/videodev2.h| 2 +
4 files changed, 352 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with
planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and of
the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+
[RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats
Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16
and V4L2_PIX_FMT_NV24 formats.
Existing h/w IPs, such as decoders, operate on such separate luma and chroma
buffers.
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182 +++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
include/linux/videodev2.h| 2 +
4 files changed, 352 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with
planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and of
the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;4:/entry
+ entryCbsubscript10/subscript/entry
+ entryCrsubscript10/subscript/entry
+ entryCbsubscript11/subscript/entry
+ entryCrsubscript11/subscript/entry
+ /row
+
[PATCH 2/2 RESEND] [media] ngene: add support for Terratec Cynergy 2400i, Dual DVB-T
[media] ngene: add support for Terratec Cynergy 2400i Dual DVB-T
This code is based on ngene initial check-in
(dae52d009fc950b5c209260d50fcc000f5becd3c)
Signed-off-by: Patrice Chotard patricechot...@free.fr
---
drivers/media/dvb/ngene/ngene-cards.c | 263 +
1 files changed, 263 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index 7539a5d..08c610f 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -42,6 +42,8 @@
#include mt2131.h
#include tda18271c2dd.h
#include drxk.h
+#include drxd.h
+#include dvb-pll.h
//
@@ -312,6 +314,235 @@ static int demod_attach_lg330x(struct ngene_channel *chan)
return (chan-fe) ? 0 : -ENODEV;
}
+static int demod_attach_drxd(struct ngene_channel *chan)
+{
+ struct drxd_config *feconf;
+
+ feconf = chan-dev-card_info-fe_config[chan-number];
+
+ chan-fe = dvb_attach(drxd_attach, feconf, chan,
+ chan-i2c_adapter, chan-dev-pci_dev-dev);
+ if (!chan-fe) {
+ pr_err(No DRXD found!\n);
+ return -ENODEV;
+ }
+
+ if (!dvb_attach(dvb_pll_attach, chan-fe, feconf-pll_address,
+ chan-i2c_adapter,
+ feconf-pll_type)) {
+ pr_err(No pll(%d) found!\n, feconf-pll_type);
+ return -ENODEV;
+ }
+ return 0;
+}
+
+//
+/* EEPROM TAGS **/
+//
+
+#define MICNG_EE_START 0x0100
+#define MICNG_EE_END0x0FF0
+
+#define MICNG_EETAG_END00x
+#define MICNG_EETAG_END10x
+
+/* 0x0001 - 0x000F reserved for housekeeping */
+/* 0x - 0xFFFE reserved for housekeeping */
+
+/* Micronas assigned tags
+ EEProm tags for hardware support */
+
+#define MICNG_EETAG_DRXD1_OSCDEVIATION 0x1000 /* 2 Bytes data */
+#define MICNG_EETAG_DRXD2_OSCDEVIATION 0x1001 /* 2 Bytes data */
+
+#define MICNG_EETAG_MT2060_1_1STIF 0x1100 /* 2 Bytes data */
+#define MICNG_EETAG_MT2060_2_1STIF 0x1101 /* 2 Bytes data */
+
+/* Tag range for OEMs */
+
+#define MICNG_EETAG_OEM_FIRST 0xC000
+#define MICNG_EETAG_OEM_LAST 0xFFEF
+
+static int i2c_write_eeprom(struct i2c_adapter *adapter,
+ u8 adr, u16 reg, u8 data)
+{
+ u8 m[3] = {(reg 8), (reg 0xff), data};
+ struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m,
+ .len = sizeof(m)};
+
+ if (i2c_transfer(adapter, msg, 1) != 1) {
+ pr_err(DEVICE_NAME : Error writing EEPROM!\n);
+ return -EIO;
+ }
+ return 0;
+}
+
+static int i2c_read_eeprom(struct i2c_adapter *adapter,
+ u8 adr, u16 reg, u8 *data, int len)
+{
+ u8 msg[2] = {(reg 8), (reg 0xff)};
+ struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+ .buf = msg, .len = 2 },
+ {.addr = adr, .flags = I2C_M_RD,
+ .buf = data, .len = len} };
+
+ if (i2c_transfer(adapter, msgs, 2) != 2) {
+ pr_err(DEVICE_NAME : Error reading EEPROM\n);
+ return -EIO;
+ }
+ return 0;
+}
+
+static int ReadEEProm(struct i2c_adapter *adapter,
+ u16 Tag, u32 MaxLen, u8 *data, u32 *pLength)
+{
+ int status = 0;
+ u16 Addr = MICNG_EE_START, Length, tag = 0;
+ u8 EETag[3];
+
+ while (Addr + sizeof(u16) + 1 MICNG_EE_END) {
+ if (i2c_read_eeprom(adapter, 0x50, Addr, EETag, sizeof(EETag)))
+ return -1;
+ tag = (EETag[0] 8) | EETag[1];
+ if (tag == MICNG_EETAG_END0 || tag == MICNG_EETAG_END1)
+ return -1;
+ if (tag == Tag)
+ break;
+ Addr += sizeof(u16) + 1 + EETag[2];
+ }
+ if (Addr + sizeof(u16) + 1 + EETag[2] MICNG_EE_END) {
+ pr_err(DEVICE_NAME
+ : Reached EOEE @ Tag = %04x Length = %3d\n,
+ tag, EETag[2]);
+ return -1;
+ }
+ Length = EETag[2];
+ if (Length MaxLen)
+ Length = (u16) MaxLen;
+ if (Length 0) {
+ Addr += sizeof(u16) + 1;
+ status = i2c_read_eeprom(adapter, 0x50, Addr, data, Length);
+ if (!status) {
+ *pLength = EETag[2];
+ if (Length EETag[2])
+ ; /*status=STATUS_BUFFER_OVERFLOW; */
+ }
+ }
+ return status;
+}
+
+static int WriteEEProm(struct i2c_adapter
[Q] stk1160 on arm raspberrypi (but with issues)
Hi, I received some reports of stk1160 working on the world famous ARM raspberrypi devices; with some changes to current code: https://github.com/ezequielgarcia/stk1160-standalone/issues/5 This gently user did some changes on my suggestion and then could capture a png with mplayer. However the image looks a little corrupted: http://postimage.org/image/ksg9ji8d5/ 1. I'd like to ask, if someone can (just looking at the capture) guess the origin of the corruption: memory or bandwidth? 2. Also, I wonder if someone could explain me a bit, about DMA_NONCOHERENT config. I know you're probably very busy right now, so I don't expect tons of answers; but I'm sure many of you will be happy to know this is (sort of) working on an ARM device. Thanks, Ezequiel. -- 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
Reporting signal overload condition for tuners?
Hi there, Quick question: we don't currently have any way to report to userland that a tuning is failing due to signal overload, right? There are some tuner chips out there which can detect this condition, and being able to report it back to userland would make it much easier to inform the user that he/she needs to stick an attenuator inline. Has anybody given any thought to this before? Perhaps use up the last available bit in fe_status for DVB? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: Tree for July 31 (media/radio-tea5777)
Em 31-07-2012 14:22, Randy Dunlap escreveu: drivers/built-in.o: In function `radio_tea5777_set_freq': radio-tea5777.c:(.text+0x4d8704): undefined reference to `__udivdi3' The patch below should fix it. Thanks for reporting it! Regards, Mauro [media] radio-tea5777: use library for 64bits div From: Mauro Carvalho Chehab mche...@redhat.com drivers/built-in.o: In function `radio_tea5777_set_freq': radio-tea5777.c:(.text+0x4d8704): undefined reference to `__udivdi3' Reported-by: Randy Dunlap rdun...@xenotime.net Cc: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/radio/radio-tea5777.c b/drivers/media/radio/radio-tea5777.c index 3e12179..5bc9fa6 100644 --- a/drivers/media/radio/radio-tea5777.c +++ b/drivers/media/radio/radio-tea5777.c @@ -33,6 +33,7 @@ #include media/v4l2-fh.h #include media/v4l2-ioctl.h #include media/v4l2-event.h +#include asm/div64.h #include radio-tea5777.h MODULE_AUTHOR(Hans de Goede pe...@perex.cz); @@ -158,10 +159,11 @@ static int radio_tea5777_set_freq(struct radio_tea5777 *tea) int res; freq = clamp_t(u32, tea-freq, - TEA5777_FM_RANGELOW, TEA5777_FM_RANGEHIGH); - freq = (freq + 8) / 16; /* to kHz */ + TEA5777_FM_RANGELOW, TEA5777_FM_RANGEHIGH) + 8; + do_div(freq, 16); /* to kHz */ - freq = (freq - TEA5777_FM_IF) / TEA5777_FM_FREQ_STEP; + freq -= TEA5777_FM_IF; + do_div(freq, TEA5777_FM_FREQ_STEP); tea-write_reg = ~(TEA5777_W_FM_PLL_MASK | TEA5777_W_FM_FREF_MASK); tea-write_reg |= freq TEA5777_W_FM_PLL_SHIFT; -- 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: [RESEND,media] v4l2: define V4L2_PIX_FMT_NV16M and V4L2_PIX_FMT_NV24M pixel formats
Hi Ilyes,
Em 31-07-2012 16:40, Ilyes Gouta escreveu:
Define the two new V4L2_PIX_FMT_NV16M (4:2:2 two-buffers) and
V4L2_PIX_FMT_NV24M (4:4:4 two-buffers)
pixel formats, the non-contiguous variants of the existing V4L2_PIX_FMT_NV16
and V4L2_PIX_FMT_NV24 formats.
Existing h/w IPs, such as decoders, operate on such separate luma and chroma
buffers.
We only add new stuff at API when a driver is using, in order to avoid
overriding the
Kernel with unused stuff. So, please submit this patch when you're ready to
submit
the driver that is using it.
Also, in the particular case of newer pixel formats, it may make sense to submit
a patch to v4l-utils, if the new format(s) is(are) the only one(s) available for
userspace to retrieve the data.
Thanks,
Mauro
Signed-off-by: Ilyes Gouta ilyes.go...@gmail.com
---
Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 166 +
Documentation/DocBook/media/v4l/pixfmt-nv24m.xml | 182
+++
Documentation/DocBook/media/v4l/pixfmt.xml | 2 +
include/linux/videodev2.h| 2 +
4 files changed, 352 insertions(+)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24m.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
new file mode 100644
index 000..76e48bf
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -0,0 +1,166 @@
+refentry id=V4L2-PIX-FMT-NV16M
+ refmeta
+ refentrytitleV4L2_PIX_FMT_NV16M ('NM16')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname constantV4L2_PIX_FMT_NV16M/constant/refname
+ refpurposeVariation of constantV4L2_PIX_FMT_NV16/constant with
planes
+ non contiguous in memory. /refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThis is a multi-planar, two-plane version of the YUV 4:2:2 format.
+The three components are separated into two sub-images or planes.
+constantV4L2_PIX_FMT_NV16M/constant differs from
constantV4L2_PIX_FMT_NV16
+/constant in that the two planes are non-contiguous in memory, i.e. the
chroma
+plane do not necessarily immediately follows the luma plane.
+The luminance data occupies the first plane. The Y plane has one byte per
pixel.
+In the second plane there is a chrominance data with alternating chroma
samples.
+The CbCr plane has the same width and height, in bytes, as the Y plane (and
of the image).
+Each CbCr pair belongs to two pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Ysubscript00/subscript, Y'subscript01/subscript. /para
+
+ paraconstantV4L2_PIX_FMT_NV16M/constant is intended to be
+used only in drivers and applications that support the multi-planar API,
+described in xref linkend=planar-apis/. /para
+
+ paraIf the Y plane has pad bytes after each row, then the
+CbCr plane has as many pad bytes after its rows./para
+
+ example
+ titleconstantV4L2_PIX_FMT_NV16M/constant 4 times; 4 pixel
image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystart0nbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;8:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystart0nbsp;+nbsp;12:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entry/entry
+ /row
+ row
+ entrystart1nbsp;+nbsp;0:/entry
+ entryCbsubscript00/subscript/entry
+
[PATCH 1/3 RFC] [media] adv7180: remove {query/g_/s_}ctrl
Signed-off-by: Federico Vaga federico.v...@gmail.com
---
drivers/media/video/adv7180.c | 3 ---
1 file modificato, 3 rimozioni(-)
diff --git a/drivers/media/video/adv7180.c b/drivers/media/video/adv7180.c
index 07bb550..bcc7d60 100644
--- a/drivers/media/video/adv7180.c
+++ b/drivers/media/video/adv7180.c
@@ -402,9 +402,6 @@ static const struct v4l2_subdev_video_ops adv7180_video_ops
= {
static const struct v4l2_subdev_core_ops adv7180_core_ops = {
.g_chip_ident = adv7180_g_chip_ident,
.s_std = adv7180_s_std,
- .queryctrl = v4l2_subdev_queryctrl,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
};
static const struct v4l2_subdev_ops adv7180_ops = {
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Update STA2X11 to videobuf2 and control framework
As suggested I moved the Video Buffer Input (VIP) of the STA2X11 board to the
videobuf2. This patch series is an RFC.
The first patch is just an update to the adv7180 because the VIP (the only
user) now use the control framework so query{g_|s_|ctrl} are not necessery.
The second patch adds a new memory allocator for the videobuf2. I name it
videobuf2-dma-streaming but I think streaming is not the best choice, so
suggestions are welcome. My inspiration for this buffer come from
videobuf-dma-contig (cached) version. After I made this buffer I found the
videobuf2-dma-nc made by Jonathan Corbet and I improve the allocator with
some suggestions (http://patchwork.linuxtv.org/patch/7441/). The VIP doesn't
work with videobu2-dma-contig and I think this solution is easier the sg.
The third patch updates the VIP to videobuf2 and control framework. I made also
some restyling to the driver and change some mechanism so I take the ownership
of the driver and I add the copyright of ST Microelectronics. Some trivial
code is unchanged. The patch probably needs some extra update and probably,
you will give me many suggestions.
I add the control framework to the VIP but without any control. I add it to
inherit controls from adv7180.
--
Federico Vaga
--
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
Update VIP to videobuf2 and control framework
As suggested I moved the Video Buffer Input (VIP) of the STA2X11 board to the
videobuf2. This patch series is an RFC.
The first patch is just an update to the adv7180 because the VIP (the only
user) now use the control framework so query{g_|s_|ctrl} are not necessery.
The second patch adds a new memory allocator for the videobuf2. I name it
videobuf2-dma-streaming but I think streaming is not the best choice, so
suggestions are welcome. My inspiration for this buffer come from
videobuf-dma-contig (cached) version. After I made this buffer I found the
videobuf2-dma-nc made by Jonathan Corbet and I improve the allocator with
some suggestions (http://patchwork.linuxtv.org/patch/7441/). The VIP doesn't
work with videobu2-dma-contig and I think this solution is easier the sg.
The third patch updates the VIP to videobuf2 and control framework. I made also
some restyling to the driver and change some mechanism so I take the ownership
of the driver and I add the copyright of ST Microelectronics. Some trivial
code is unchanged. The patch probably needs some extra update.
I add the control framework to the VIP but without any control. I add it to
inherit controls from adv7180.
--
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/3] [media] adv7180: remove {query/g_/s_}ctrl
Signed-off-by: Federico Vaga federico.v...@gmail.com
---
drivers/media/video/adv7180.c | 3 ---
1 file modificato, 3 rimozioni(-)
diff --git a/drivers/media/video/adv7180.c b/drivers/media/video/adv7180.c
index 07bb550..bcc7d60 100644
--- a/drivers/media/video/adv7180.c
+++ b/drivers/media/video/adv7180.c
@@ -402,9 +402,6 @@ static const struct v4l2_subdev_video_ops adv7180_video_ops
= {
static const struct v4l2_subdev_core_ops adv7180_core_ops = {
.g_chip_ident = adv7180_g_chip_ident,
.s_std = adv7180_s_std,
- .queryctrl = v4l2_subdev_queryctrl,
- .g_ctrl = v4l2_subdev_g_ctrl,
- .s_ctrl = v4l2_subdev_s_ctrl,
};
static const struct v4l2_subdev_ops adv7180_ops = {
--
1.7.11.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [media] videobuf2-dma-streaming: new videobuf2 memory allocator
Signed-off-by: Federico Vaga federico.v...@gmail.com
---
drivers/media/video/Kconfig | 6 +-
drivers/media/video/Makefile | 1 +
drivers/media/video/videobuf2-dma-streaming.c | 187 ++
include/media/videobuf2-dma-streaming.h | 24
4 file modificati, 217 inserzioni(+). 1 rimozione(-)
create mode 100644 drivers/media/video/videobuf2-dma-streaming.c
create mode 100644 include/media/videobuf2-dma-streaming.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index be6d718..6c60b59 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -59,6 +59,10 @@ config VIDEOBUF2_DMA_NC
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
tristate
+config VIDEOBUF2_DMA_STREAMING
+ select VIDEOBUF2_CORE
+ select VIDEOBUF2_MEMOPS
+ tristate
config VIDEOBUF2_VMALLOC
select VIDEOBUF2_CORE
@@ -844,7 +848,7 @@ config STA2X11_VIP
tristate STA2X11 VIP Video For Linux
depends on STA2X11
select VIDEO_ADV7180 if VIDEO_HELPER_CHIPS_AUTO
- select VIDEOBUF_DMA_CONTIG
+ select VIDEOBUF2_DMA_STREAMING
depends on PCI VIDEO_V4L2 VIRT_TO_BUS
help
Say Y for support for STA2X11 VIP (Video Input Port) capture
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 30234af..c1a08b9e 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -140,6 +140,7 @@ obj-$(CONFIG_VIDEOBUF2_VMALLOC) +=
videobuf2-vmalloc.o
obj-$(CONFIG_VIDEOBUF2_DMA_CONTIG) += videobuf2-dma-contig.o
obj-$(CONFIG_VIDEOBUF2_DMA_SG) += videobuf2-dma-sg.o
obj-$(CONFIG_VIDEOBUF2_DMA_NC) += videobuf2-dma-nc.o
+obj-$(CONFIG_VIDEOBUF2_DMA_STREAMING) += videobuf2-dma-streaming.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
diff --git a/drivers/media/video/videobuf2-dma-streaming.c
b/drivers/media/video/videobuf2-dma-streaming.c
new file mode 100644
index 000..d96d3d9
--- /dev/null
+++ b/drivers/media/video/videobuf2-dma-streaming.c
@@ -0,0 +1,187 @@
+/*
+ * videobuf2-dma-streaming.c - DMA streaming memory allocator for videobuf2
+ *
+ * Copyright (C) 2012 Federico Vaga federico.v...@gmail.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/module.h
+#include linux/slab.h
+#include linux/pagemap.h
+#include linux/dma-mapping.h
+
+#include media/videobuf2-core.h
+#include media/videobuf2-dma-streaming.h
+#include media/videobuf2-memops.h
+
+struct vb2_streaming_conf {
+ struct device *dev;
+};
+struct vb2_streaming_buf {
+ struct vb2_streaming_conf *conf;
+ void*vaddr;
+
+ dma_addr_t dma_handle;
+
+ unsigned long size;
+ struct vm_area_struct *vma;
+
+ atomic_trefcount;
+ struct vb2_vmarea_handler handler;
+};
+
+static void vb2_dma_streaming_put(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ if (atomic_dec_and_test(buf-refcount)) {
+ dma_unmap_single(buf-conf-dev, buf-dma_handle, buf-size,
+DMA_FROM_DEVICE);
+ free_pages_exact(buf-vaddr, buf-size);
+ kfree(buf);
+ }
+
+}
+
+static void *vb2_dma_streaming_alloc(void *alloc_ctx, unsigned long size)
+{
+ struct vb2_streaming_conf *conf = alloc_ctx;
+ struct vb2_streaming_buf *buf;
+ int err;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+ buf-vaddr = alloc_pages_exact(size, GFP_KERNEL | GFP_DMA);
+ if (!buf-vaddr) {
+ err = -ENOMEM;
+ goto out;
+ }
+ buf-dma_handle = dma_map_single(conf-dev, buf-vaddr, size,
+DMA_FROM_DEVICE);
+ err = dma_mapping_error(conf-dev, buf-dma_handle);
+ if (err) {
+ dev_err(conf-dev, dma_map_single failed\n);
+
+ free_pages_exact(buf-vaddr, size);
+ buf-vaddr = NULL;
+ goto out_pages;
+ }
+ buf-conf = conf;
+ buf-size = size;
+ buf-handler.refcount = buf-refcount;
+ buf-handler.put = vb2_dma_streaming_put;
+ buf-handler.arg = buf;
+
+ atomic_inc(buf-refcount);
+ return buf;
+
+out_pages:
+ free_pages_exact(buf-vaddr, buf-size);
+out:
+ kfree(buf);
+ return ERR_PTR(err);
+}
+
+static void *vb2_dma_streaming_cookie(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
+ return (void *)buf-dma_handle;
+}
+
+static void *vb2_dma_streaming_vaddr(void *buf_priv)
+{
+ struct vb2_streaming_buf *buf = buf_priv;
+
[PATCH 3/3] [media] sta2x11_vip: convert to videobuf2 and control framework
Signed-off-by: Federico Vaga federico.v...@gmail.com
Acked-by: Giancarlo Asnaghi giancarlo.asna...@st.com
---
drivers/media/video/sta2x11_vip.c | 1134 ++---
1 file modificato, 410 inserzioni(+), 724 rimozioni(-)
diff --git a/drivers/media/video/sta2x11_vip.c
b/drivers/media/video/sta2x11_vip.c
index 4c10205..5a75718 100644
--- a/drivers/media/video/sta2x11_vip.c
+++ b/drivers/media/video/sta2x11_vip.c
@@ -1,6 +1,7 @@
/*
* This is the driver for the STA2x11 Video Input Port.
*
+ * Copyright (C) 2012 ST Microelectronics
* Copyright (C) 2010 WindRiver Systems, Inc.
*
* This program is free software; you can redistribute it and/or modify it
@@ -19,36 +20,28 @@
* The full GNU General Public License is included in this distribution in
* the file called COPYING.
*
- * Author: Andreas Kies andreas.k...@windriver.com
- * Vlad Lungu vlad.lu...@windriver.com
- *
*/
#include linux/types.h
#include linux/kernel.h
#include linux/module.h
#include linux/init.h
-#include linux/vmalloc.h
-
#include linux/videodev2.h
-
#include linux/kmod.h
-
#include linux/pci.h
#include linux/interrupt.h
-#include linux/mutex.h
#include linux/io.h
#include linux/gpio.h
#include linux/i2c.h
#include linux/delay.h
#include media/v4l2-common.h
#include media/v4l2-device.h
+#include media/v4l2-ctrls.h
#include media/v4l2-ioctl.h
-#include media/videobuf-dma-contig.h
+#include media/videobuf2-dma-streaming.h
#include sta2x11_vip.h
-#define DRV_NAME sta2x11_vip
#define DRV_VERSION 1.3
#ifndef PCI_DEVICE_ID_STMICRO_VIP
@@ -63,8 +56,8 @@
#define DVP_TFS0x08
#define DVP_BFO0x0C
#define DVP_BFS0x10
-#define DVP_VTP 0x14
-#define DVP_VBP 0x18
+#define DVP_VTP0x14
+#define DVP_VBP0x18
#define DVP_VMP0x1C
#define DVP_ITM0x98
#define DVP_ITS0x9C
@@ -84,43 +77,20 @@
#define DVP_HLFLN_SD 0x0001
-#define REG_WRITE(vip, reg, value) iowrite32((value), (vip-iomem)+(reg))
-#define REG_READ(vip, reg) ioread32((vip-iomem)+(reg))
-
#define SAVE_COUNT 8
#define AUX_COUNT 3
#define IRQ_COUNT 1
-/**
- * struct sta2x11_vip - All internal data for one instance of device
- * @v4l2_dev: device registered in v4l layer
- * @video_dev: properties of our device
- * @pdev: PCI device
- * @adapter: contains I2C adapter information
- * @register_save_area: All relevant register are saved here during suspend
- * @decoder: contains information about video DAC
- * @format: pixel format, fixed UYVY
- * @std: video standard (e.g. PAL/NTSC)
- * @input: input line for video signal ( 0 or 1 )
- * @users: Number of open of device ( max. 1 )
- * @disabled: Device is in power down state
- * @mutex: ensures exclusive opening of device
- * @slock: for excluse acces of registers
- * @vb_vidq: queue maintained by videobuf layer
- * @capture: linked list of capture buffer
- * @active: struct videobuf_buffer currently beingg filled
- * @started: device is ready to capture frame
- * @closing: device will be shut down
- * @tcount: Number of top frames
- * @bcount: Number of bottom frames
- * @overflow: Number of FIFO overflows
- * @mem_spare: small buffer of unused frame
- * @dma_spare: dma addres of mem_spare
- * @iomem: hardware base address
- * @config: I2C and gpio config from platform
- *
- * All non-local data is accessed via this structure.
- */
+
+struct vip_buffer {
+ struct vb2_buffer vb;
+ struct list_headlist;
+ dma_addr_t dma;
+};
+static inline struct vip_buffer *to_vip_buffer(struct vb2_buffer *vb2)
+{
+ return container_of(vb2, struct vip_buffer, vb);
+}
struct sta2x11_vip {
struct v4l2_device v4l2_dev;
@@ -129,21 +99,28 @@ struct sta2x11_vip {
struct i2c_adapter *adapter;
unsigned int register_save_area[IRQ_COUNT + SAVE_COUNT + AUX_COUNT];
struct v4l2_subdev *decoder;
- struct v4l2_pix_format format;
- v4l2_std_id std;
- unsigned int input;
- int users;
- int disabled;
- struct mutex mutex; /* exclusive access during open */
- spinlock_t slock; /* spin lock for hardware and queue access */
- struct videobuf_queue vb_vidq;
- struct list_head capture;
- struct videobuf_buffer *active;
- int started, closing, tcount, bcount;
+ struct v4l2_ctrl_handler ctrl_hdl;
+
+
+ struct v4l2_pix_format format; /* pixel format, fixed UYVY */
+ v4l2_std_id std;/* Video standard (PAL/NTSC)*/
+ unsigned int input; /* Input line (0 or 1) */
+ int disabled; /* 1 disabled 0 enabled */
+ spinlock_t slock; /* spin lock for hardware */
+
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct vb2_queue vb_vidq; /* queue maintaned by videobuf2 */
+ struct list_head buffer_list; /* list of buffers */
+ unsigned int
Re: linux-next: Tree for July 31 (media/radio-tea5777)
On 07/31/2012 12:56 PM, Mauro Carvalho Chehab wrote: Em 31-07-2012 14:22, Randy Dunlap escreveu: drivers/built-in.o: In function `radio_tea5777_set_freq': radio-tea5777.c:(.text+0x4d8704): undefined reference to `__udivdi3' The patch below should fix it. Thanks for reporting it! Regards, Mauro [media] radio-tea5777: use library for 64bits div From: Mauro Carvalho Chehab mche...@redhat.com drivers/built-in.o: In function `radio_tea5777_set_freq': radio-tea5777.c:(.text+0x4d8704): undefined reference to `__udivdi3' Reported-by: Randy Dunlap rdun...@xenotime.net Cc: Hans de Goede hdego...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Randy Dunlap rdun...@xenotime.net Thanks. diff --git a/drivers/media/radio/radio-tea5777.c b/drivers/media/radio/radio-tea5777.c index 3e12179..5bc9fa6 100644 --- a/drivers/media/radio/radio-tea5777.c +++ b/drivers/media/radio/radio-tea5777.c @@ -33,6 +33,7 @@ #include media/v4l2-fh.h #include media/v4l2-ioctl.h #include media/v4l2-event.h +#include asm/div64.h #include radio-tea5777.h MODULE_AUTHOR(Hans de Goede pe...@perex.cz); @@ -158,10 +159,11 @@ static int radio_tea5777_set_freq(struct radio_tea5777 *tea) int res; freq = clamp_t(u32, tea-freq, -TEA5777_FM_RANGELOW, TEA5777_FM_RANGEHIGH); - freq = (freq + 8) / 16; /* to kHz */ +TEA5777_FM_RANGELOW, TEA5777_FM_RANGEHIGH) + 8; + do_div(freq, 16); /* to kHz */ - freq = (freq - TEA5777_FM_IF) / TEA5777_FM_FREQ_STEP; + freq -= TEA5777_FM_IF; + do_div(freq, TEA5777_FM_FREQ_STEP); tea-write_reg = ~(TEA5777_W_FM_PLL_MASK | TEA5777_W_FM_FREF_MASK); tea-write_reg |= freq TEA5777_W_FM_PLL_SHIFT; -- -- ~Randy -- 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/3] [media] adv7180: remove {query/g_/s_}ctrl
I'm sorry for the email duplication, I press the wrong key on git-send email. Ignore these emails. Sorry -- Federico Vaga -- 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: Update VIP to videobuf2 and control framework
I use git send-email command to send patches but I think I made a
mistake. If something
is wrong or confused please tell me and I try to resend all the
patches hopefully without mistake. Sorry again.
2012/7/31 Federico Vaga federico.v...@gmail.com:
As suggested I moved the Video Buffer Input (VIP) of the STA2X11 board to the
videobuf2. This patch series is an RFC.
The first patch is just an update to the adv7180 because the VIP (the only
user) now use the control framework so query{g_|s_|ctrl} are not necessery.
The second patch adds a new memory allocator for the videobuf2. I name it
videobuf2-dma-streaming but I think streaming is not the best choice, so
suggestions are welcome. My inspiration for this buffer come from
videobuf-dma-contig (cached) version. After I made this buffer I found the
videobuf2-dma-nc made by Jonathan Corbet and I improve the allocator with
some suggestions (http://patchwork.linuxtv.org/patch/7441/). The VIP doesn't
work with videobu2-dma-contig and I think this solution is easier the sg.
The third patch updates the VIP to videobuf2 and control framework. I made
also
some restyling to the driver and change some mechanism so I take the ownership
of the driver and I add the copyright of ST Microelectronics. Some trivial
code is unchanged. The patch probably needs some extra update.
I add the control framework to the VIP but without any control. I add it to
inherit controls from adv7180.
--
Federico Vaga
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] media DT bindings
Hi Guennadi,
On Tuesday 31 July 2012 14:39:07 Guennadi Liakhovetski wrote:
On Tue, 31 Jul 2012, Laurent Pinchart wrote:
On Tuesday 31 July 2012 11:26:27 Guennadi Liakhovetski wrote:
On Fri, 27 Jul 2012, Laurent Pinchart wrote:
On Wednesday 18 July 2012 19:00:15 Sylwester Nawrocki wrote:
On 07/16/2012 01:41 PM, Guennadi Liakhovetski wrote:
[snip]
An sh-mobile CEU DT node could look like
ceu0@0xfe91 = {
compatible = renesas,sh-mobile-ceu;
reg =0xfe91 0xa0;
interrupts =0x880;
bus-width =16;/* #lines routed on the
board */
clock-frequency =5000;/* max clock */
#address-cells =1;
#size-cells =0;
...
ov772x-1 = {
reg =0;
This property might be redundant, we already have the client
phandle pointing to ov772x@0x21-0, which has all interesting
properties inside it. Other than there is probably no reasonable
usage for it under ceu0@0xfe91 node ?
client =ov772x@0x21-0;
local-pad = parallel-sink;
remote-pad = parallel-source;
I'm not sure I like that. Is it really needed when we already
have the child/parent properties around ?
I think it is. Both the host and the client can have multiple pads
(e.g., parallel / serial). These properties specify which pads are
used and make the translation between DT data and our subdev / pad
APIs simpler.
OK, sorry, but isn't it all about just specifying what sort of data
bus is used ? :-)
In some (many/most ?) cases probably, but not in all of them.
What about merging the client and remote-pad properties ? The
resulting property would then reference a pad with ov772x@0x21-0 0.
What would the 0 parameter mean then? Pad #0?
Yes.
But aren't these numbers device specific? Maybe not a huge deal, but
these numbers are defind by the driver, right? Not the DT itself. So,
drivers then will have to take care not to change their pad numbering.
Whereas using strings, we can fix strings in the common V4L DT spec and
keep them standard across devices and drivers. Then drivers might be
less likely to change these assignments randomly ;-)
Userspace applications usually rely on pad numbers as well, so I consider
them as more or less part of the ABI. If we really need to, we could add
a DT pad number - media controller pad number conversion in the driver,
that would be less expensive than pad name - pad number conversion
(especially since it would be skipped in most cases).
Ok, then, how about
#address-cells = 1;
#size-cells = 0;
...
ov772x-1 = {
reg = 1; /* local pad # */
client = ov772x@0x21-0 0;/* remote phandle and
pad */
The client property looks good, but isn't such a usage of the reg property an
abuse ? Maybe the local pad # should be a device-specific property. Many hosts
won't need it, and on others it would actually need to reference a subdev, not
just a pad.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
Hi Sylwester, On Tuesday 31 July 2012 14:38:35 Sylwester Nawrocki wrote: On 07/31/2012 01:05 PM, Laurent Pinchart wrote: What about CSI receivers that can reroute the lanes internally ? We would need to specify lane indices for each lane then, maybe with something like clock-lane =0; data-lanes =2 3 1; Sounds good to me. And the clock-lane could be made optional, as not all devices would need it. However, as far as I can see, there is currently no generic API for handling this kind of data structure. E.g. number of cells for the interrupts property is specified with an additional #interrupt-cells property. It would have been much easier to handle something like: data-lanes = 2, 3, 1; i.e. an array of the lane indexes. I'm fine with that. ...on a second thought: shouldn't this be handled by pinctrl? Or is it some CSI-2 module internal lane switching, not the global SoC pin function configuration? On the hardware I came across, it's handled by the CSI2 receiver, not the SoC pinmux feature. Same here. Is there any hardware known to mux those MIPI-CSI D-PHY high speed differential signals with general purpose IO pins ? Or are there mostly dedicated pins used ? The OMAP3 multiplexes the CSI pins with other functions. However, if there are cases the lane configuration is done solely at CSI2 receiver level, there seems little point in involving the pinctrl API. The OMAP3 handles lane routing in the CSI2 receiver. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation
Hi Sylwester, On Tuesday 31 July 2012 15:28:52 Sylwester Nawrocki wrote: On 07/31/2012 02:59 PM, Guennadi Liakhovetski wrote: On Tue, 31 Jul 2012, Sylwester Nawrocki wrote: On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote: But should we allow host probe() to succeed if the sensor isn't present ? I think we should, yes. The host hardware is there and functional - whether or not all or some of the clients are failing. Theoretically clients can also be hot-plugged. Whether and how many video device nodes we create, that's a different question. I think I can agree with you on this (although I could change my mind if this architecture turns out to result in unsolvable technical issues). That will involve a lot of work though. There's however at least one more gotcha that occurs to me with this approach: if clients fail to probe, how do we find out about that and turn clocks back off? One improvement to turning clocks on immediately in Hmm, wouldn't it be the client that turns a clock on/off when needed ? I'd like to preserve this functionality, so client drivers can have full control on the power up/down sequences. While we are trying to improve the current situation... Eventually, when the clock API is available - yes, the client would just call clk_enable() / clk_disable(). But for now isn't it host's job to do that? Or you want to add new API for that? Indeed, looking at existing drivers, the clocks' handling is now mostly done in the host drivers. Only the omap3isp appears to do the right thing, i.e. delegating control over the clock to client drivers, but it does it with platform_data callbacks. We've already discussed adding a new API for that, http://www.mail-archive.com/linux-media@vger.kernel.org/msg35359.html However using common clock API and binding a clock to client device (either DT based or not) sounds like a best approach to me. Waiting for the common clock API to be generally available maybe we could add some clock ops at the v4l2_device ? Just a humble suggestion, I'm not sure whether it is really good and needed or not. I'm fine with that (or something similar) as an interim solution. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-ctl PATCH 1/1] libv4l2subdev: Add v4l2_subdev_enum_mbus_code()
Hi Sakari,
On Tuesday 31 July 2012 15:17:04 Sakari Ailus wrote:
On Tue, Jul 31, 2012 at 01:38:41PM +0200, Laurent Pinchart wrote:
On Tuesday 31 July 2012 01:16:00 Sakari Ailus wrote:
v4l2_subdev_enum_mbus_code() enumerates over supported media bus formats
on a pad.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
src/v4l2subdev.c | 23 +++
src/v4l2subdev.h | 14 ++
2 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c
index d60bd7e..6b6df0a 100644
--- a/src/v4l2subdev.c
+++ b/src/v4l2subdev.c
@@ -58,6 +58,29 @@ void v4l2_subdev_close(struct media_entity *entity)
entity-fd = -1;
}
+int v4l2_subdev_enum_mbus_code(struct media_entity *entity,
+uint32_t *code, uint32_t pad, uint32_t index)
I would use unsigned int for the pad and index arguments to match the
other functions. We could then fix all of them in one go to use stdint
types to match the kernel API types.
I'm fine with that.
+{
+ struct v4l2_subdev_mbus_code_enum c;
+ int ret;
+
+ ret = v4l2_subdev_open(entity);
+ if (ret 0)
+ return ret;
+
+ memset(c, 0, sizeof(c));
+ c.pad = pad;
+ c.index = index;
+
+ ret = ioctl(entity-fd, VIDIOC_SUBDEV_ENUM_MBUS_CODE, c);
+ if (ret 0)
+ return -errno;
+
+ *code = c.code;
+
+ return 0;
+}
What about a higher-level API that would enumerate all formats and return
a list/array ?
The information could be stored to media entities. We could add a V4L2
subdev pointer to media entities, and have the information stored there the
first time this function is called. How about that?
On source pads the pixel code is obviously possibly dependent on the pixel
code on the sink pad so I need to store mappings from sink pad pixel code to
a list of source pad pixel code, but can it have other dependencies? None
come to mind right now, though.
I would make this function store the enumerated mbus codes in the media
entity, as the codes on a source pad could depend on the selected code on a
sink pad. I would instead make the function allocate an array, fill it with
media bus codes and return it. The caller would be responsible for freeing it
(possibly later, after storing it).
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
