[PATCH] media: vb2: dma contig allocator: use dma_addr instread of paddr
Use the correct 'dma_addr' name for the buffer address. 'paddr' suggested
that this is the physical address in system memory. For most ARM platforms
these two are the same, but this is not a generic rule. 'dma_addr' will
also point better to dma-mapping api.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
drivers/media/video/atmel-isi.c |2 +-
drivers/media/video/marvell-ccic/mcam-core.c |4 +-
drivers/media/video/mx3_camera.c |2 +-
drivers/media/video/s5p-fimc/fimc-core.c |6 ++--
drivers/media/video/s5p-mfc/s5p_mfc.c|4 +-
drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 10
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 30 +-
drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 14 ++--
drivers/media/video/s5p-tv/mixer_grp_layer.c |2 +-
drivers/media/video/s5p-tv/mixer_vp_layer.c |4 +-
drivers/media/video/sh_mobile_ceu_camera.c |2 +-
drivers/media/video/videobuf2-dma-contig.c | 16 +++---
include/media/videobuf2-dma-contig.h |6 ++--
13 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 5a4b2d7..7e1d789 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -341,7 +341,7 @@ static int buffer_prepare(struct vb2_buffer *vb)
/* Initialize the dma descriptor */
desc-p_fbd-fb_address =
- vb2_dma_contig_plane_paddr(vb, 0);
+ vb2_dma_contig_plane_dma_addr(vb, 0);
desc-p_fbd-next_fbd_address = 0;
set_dma_ctrl(desc-p_fbd, ISI_DMA_CTRL_WB);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 744cf37..7abe503 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -450,7 +450,7 @@ static void mcam_set_contig_buffer(struct mcam_camera *cam,
int frame)
buf = cam-vb_bufs[frame ^ 0x1];
cam-vb_bufs[frame] = buf;
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_paddr(buf-vb_buf, 0));
+ vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
set_bit(CF_SINGLE_BUFFER, cam-flags);
singles++;
return;
@@ -461,7 +461,7 @@ static void mcam_set_contig_buffer(struct mcam_camera *cam,
int frame)
buf = list_first_entry(cam-buffers, struct mcam_vb_buffer, queue);
list_del_init(buf-queue);
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_paddr(buf-vb_buf, 0));
+ vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
cam-vb_bufs[frame] = buf;
clear_bit(CF_SINGLE_BUFFER, cam-flags);
}
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 9ae7785..c8e958a 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -247,7 +247,7 @@ static int mx3_videobuf_prepare(struct vb2_buffer *vb)
}
if (buf-state == CSI_BUF_NEEDS_INIT) {
- sg_dma_address(sg) = vb2_dma_contig_plane_paddr(vb, 0);
+ sg_dma_address(sg) = vb2_dma_contig_plane_dma_addr(vb, 0);
sg_dma_len(sg) = new_size;
buf-txd = ichan-dma_chan.device-device_prep_slave_sg(
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 8152756..266d6b9 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -457,7 +457,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
dbg(memplanes= %d, colplanes= %d, pix_size= %d,
frame-fmt-memplanes, frame-fmt-colplanes, pix_size);
- paddr-y = vb2_dma_contig_plane_paddr(vb, 0);
+ paddr-y = vb2_dma_contig_plane_dma_addr(vb, 0);
if (frame-fmt-memplanes == 1) {
switch (frame-fmt-colplanes) {
@@ -485,10 +485,10 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
} else {
if (frame-fmt-memplanes = 2)
- paddr-cb = vb2_dma_contig_plane_paddr(vb, 1);
+ paddr-cb = vb2_dma_contig_plane_dma_addr(vb, 1);
if (frame-fmt-memplanes == 3)
- paddr-cr = vb2_dma_contig_plane_paddr(vb, 2);
+ paddr-cr = vb2_dma_contig_plane_dma_addr(vb, 2);
}
dbg(PHYS_ADDR: y= 0x%X cb= 0x%X cr= 0x%X ret= %d,
diff --git a/drivers/media/video/s5p-mfc/s5p_mfc.c
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
Hi Laurent,
Hi Tomasz,
On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
This patch fix the handling of data passed to V4L2 ioctls. The content of
the structures is not copied if the ioctl fails. It blocks ability to
obtain any information about occurred error other then errno code. This
patch fix this issue.
Does the V4L2 spec say anything on this topic ? We might have applications
that rely on the ioctl argument structure not being touched when a failure
occurs.
Ups.. I missed something. It looks that modifying ioctl content is
illegal if ioctl fails. The spec says:
When an ioctl that takes an output or read/write parameter fails, the
parameter remains unmodified. (v4l2 ioctl section)
However, there is probably a bug already present in V4L2 framework.
There are some ioctls that takes a pointer to an array as a field in the
argument struct.
The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF family.
The content of such an auxiliary arays is copied even if ioctl fails.
Please take a look to video_usercopy function in v4l2-ioctl.c. Therefore
I think that the spec is already violated. What is your opinion about
this problem?
Now back to selection case.
This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
return the best-hit rectangle if constraints could not be satisfied. The
ioctl return -ERANGE in this case. Using those return values the
application gets some feedback
on loosing constraints.
I could remove rectangle returning from the spec and s5p-tv code for now.
Regards,
Tomasz Stanislawski
Signed-off-by: Tomasz Stanislawskit.stanisl...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
drivers/media/video/v4l2-ioctl.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c index 543405b..9f54114 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -2490,8 +2490,6 @@ video_usercopy(struct file *file, unsigned int cmd,
unsigned long arg, err = -EFAULT;
goto out_array_args;
}
- if (err 0)
- goto out;
out_array_args:
/* Copy results into user buffer */
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
My comments are mainly about the documentation of the legacy bits.
On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
index 000..6808492
--- /dev/null
+++ b/Documentation/fb/api.txt
+2. Types and visuals
+
+
+Pixels are stored in memory in hardware-dependent formats. Applications need
+to be aware of the pixel storage format in order to write image data to the
+frame buffer memory in the format expected by the hardware.
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
+bits_per_pixel, grayscale, fourcc, red, green, blue and transp fields.
+
+The following types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+Color components (usually RGB or YUV) are packed together into macropixels
+that are stored in a single plane. The exact color components layout is
+described in a visual-dependent way.
+
+Frame buffer visuals that don't use multiple color components per pixel
+(such as monochrome and pseudo-color visuals) are reported as packed frame
+buffer types, even though they don't stricly speaking pack color components
+into macropixels.
That's because the packing is not about the color components, but about the
bits that represent a single pixel.
I.e. the bits that make up the pixel (the macropixel) are stored next
to each other
in memory.
+- FB_TYPE_PLANES
+
+Color components are stored in separate planes. Planes are located
+contiguously in memory.
The bits that make up a pixel are stored in separate planes. Planes are located
contiguously in memory.
- FB_TYPE_INTERLEAVED_PLANES
The bits that make up a pixel are stored in separate planes. Planes
are interleaved.
The interleave factor (the distance in bytes between the planes in
memory) is stored
in the type_aux field.
+- FB_VISUAL_MONO01
+
+Pixels are black or white and stored on one bit. A bit set to 1 represents a
+black pixel and a bit set to 0 a white pixel. Pixels are packed together in
+bytes with 8 pixels per byte.
Actually we do have drivers that use 8 bits per pixel for a monochrome visual.
Hence:
Pixels are black or white. A black pixel is represented by all
(typically one) bits
set to ones, a white pixel by all bits set to zeroes.
+FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only.
... so this may also not be true (but it is for all current drivers, IIRC).
There's a strict orthogonality between type (how is a pixel stored in memory)
and visual (how the bits that represent the pixel are interpreted and converted
to a color value).
Same comments for FB_VISUAL_MONO10
+- FB_VISUAL_TRUECOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a read-only lookup table for the corresponding value. Lookup tables
+are device-dependent, and provide linear or non-linear ramps.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields.
Storage format in memory is determined by the FB_TYPE_* value.
+- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR
+
+Pixel values are encoded as indices into a colormap that stores red, green
and
+blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR
+and read-write for FB_VISUAL_PSEUDOCOLOR.
+
+Each pixel value is stored in the number of bits reported by the variable
+screen information bits_per_pixel field. Pixels are contiguous in memory.
Whether pixels are contiguous in memory or not is determined by the
FB_TYPE_* value.
+FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with
+FB_TYPE_PACKED_PIXELS only.
Not true. Several drivers use bit planes or interleaved bitplanes.
+- FB_VISUAL_DIRECTCOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a programmable lookup table for the corresponding value.
+
+Each component is stored in memory according to the variable screen
+information red, green, blue and transp fields.
Each component is stored in a macropixel according to the variable screen
information red, green, blue and transp fields.
+- FB_VISUAL_FOURCC
+
+Pixels are stored in memory as described by the format FOURCC identifier
+stored in the variable screen information fourcc field.
... stored in memory and interpreted ...
+struct fb_var_screeninfo {
+ __u32 xres; /* visible resolution */
+ __u32 yres;
+ __u32 xres_virtual; /* virtual resolution */
+ __u32 yres_virtual;
+ __u32 xoffset; /* offset from virtual to visible */
+ __u32 yoffset;
Re: [PATCH 5/7 v5] V4L: vb2: add support for buffers of different sizes on a single queue
Hi Pawel
Thanks for the review.
On Sun, 28 Aug 2011, Pawel Osciak wrote:
Hi Guennadi,
On Wed, Aug 24, 2011 at 11:41, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
The two recently added ioctl()s VIDIOC_CREATE_BUFS and VIDIOC_PREPARE_BUF
allow user-space applications to allocate video buffers of different
sizes and hand them over to the driver for fast switching between
different frame formats. This patch adds support for buffers of different
sizes on the same buffer-queue to vb2.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Pawel Osciak pa...@osciak.com
Cc: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
drivers/media/video/videobuf2-core.c | 278
--
include/media/videobuf2-core.h | 31 +++--
2 files changed, 252 insertions(+), 57 deletions(-)
diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
index 8a81a89..fed6f2d 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
[snip]
/**
+ * vb2_create_bufs() - Allocate buffers and any required auxiliary structs
+ * @q: videobuf2 queue
+ * @create: creation parameters, passed from userspace to
vidioc_create_bufs
+ * handler in driver
+ *
+ * Should be called from vidioc_create_bufs ioctl handler of a driver.
+ * This function:
+ * 1) verifies parameter sanity
+ * 2) calls the .queue_setup() queue operation
+ * 3) performs any necessary memory allocations
+ *
+ * The return values from this function are intended to be directly
returned
+ * from vidioc_create_bufs handler in driver.
+ */
+int vb2_create_bufs(struct vb2_queue *q, struct v4l2_create_buffers
*create)
+{
+ unsigned int num_planes, num_buffers = create-count,
allocated_buffers;
+ unsigned long plane_sizes[VIDEO_MAX_PLANES];
+ int ret = 0;
+
+ if (q-fileio) {
+ dprintk(1, %s(): file io in progress\n, __func__);
+ return -EBUSY;
+ }
+
+ if (create-memory != V4L2_MEMORY_MMAP
+ create-memory != V4L2_MEMORY_USERPTR) {
+ dprintk(1, %s(): unsupported memory type\n, __func__);
+ return -EINVAL;
+ }
+
+ if (create-format.type != q-type) {
+ dprintk(1, %s(): requested type is incorrect\n, __func__);
+ return -EINVAL;
+ }
+
+ /*
+ * Make sure all the required memory ops for given memory type
+ * are available.
+ */
+ if (create-memory == V4L2_MEMORY_MMAP __verify_mmap_ops(q)) {
+ dprintk(1, %s(): MMAP for current setup unsupported\n,
__func__);
+ return -EINVAL;
+ }
+
+ if (create-memory == V4L2_MEMORY_USERPTR
__verify_userptr_ops(q)) {
+ dprintk(1, %s(): USERPTR for current setup unsupported\n,
__func__);
+ return -EINVAL;
+ }
+
+ if (q-num_buffers == VIDEO_MAX_FRAME) {
+ dprintk(1, %s(): maximum number of buffers already
allocated\n,
+ __func__);
+ return -ENOBUFS;
+ }
I think we should be verifying that q-num_buffers + create-count =
VIDEO_MAX_FRAME.
Yeah, something like that, thanks. Some of us didn't like this
VIDEO_MAX_FRAME limit at all, but as long as we have it, e-g-. as long as
struct vb2_queue::bufs[] is a fixed-size array with exactly that many
elements, we have to check for it. Increasing / eliminating it could be a
separate patch.
+
+ create-index = q-num_buffers;
+
+ if (!q-num_buffers) {
+ memset(q-alloc_ctx, 0, sizeof(q-alloc_ctx));
+ q-memory = create-memory;
+ }
+
+ /*
+ * Ask the driver, whether the requested number of buffers, planes
per
+ * buffer and their sizes are acceptable
+ */
+ ret = call_qop(q, queue_setup, q, create-format, num_buffers,
+ num_planes, plane_sizes, q-alloc_ctx);
I don't see you zeroing neither num_planes nor plane_sizes[] in
vb2_create_bufs and vb2_reqbufs. Since instead of always requiring the
driver to fill them, you've introduced the non-zero num_planes and/or
plane_sizes case (see my comment for queue_setup() documentation in
videobuf2-core.h), it looks to me that the drivers will be getting
random values in num_planes and plane_sizes in queue_setup() and will
have to attempt to use them. Ditto for all other qop calls to
queue_setup in this file (in vb2_reqbufs as well).
No, it's the documentation that's wrong:-) Both num_planes and
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert, Thanks for the review. On Monday 29 August 2011 10:13:07 Geert Uytterhoeven wrote: On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart wrote: [snip] +- FB_TYPE_PACKED_PIXELS + +Color components (usually RGB or YUV) are packed together into macropixels +that are stored in a single plane. The exact color components layout is +described in a visual-dependent way. + +Frame buffer visuals that don't use multiple color components per pixel +(such as monochrome and pseudo-color visuals) are reported as packed frame +buffer types, even though they don't stricly speaking pack color components +into macropixels. That's because the packing is not about the color components, but about the bits that represent a single pixel. I.e. the bits that make up the pixel (the macropixel) are stored next to each other in memory. OK, I've modified that last sentence to read Frame buffer visuals that don't use multiple color components per pixel (such as monochrome and pseudo-color visuals) are also reported as packed frame buffer types, as the bits that make up individual pixels are packed next to each other in memory. +- FB_TYPE_PLANES + +Color components are stored in separate planes. Planes are located +contiguously in memory. The bits that make up a pixel are stored in separate planes. Planes are located contiguously in memory. I'm not sure to agree with this. You make it sounds like FB_TYPE_PLANES stores each bit in a different plane. Is that really the case ? - FB_TYPE_INTERLEAVED_PLANES The bits that make up a pixel are stored in separate planes. Planes are interleaved. The interleave factor (the distance in bytes between the planes in memory) is stored in the type_aux field. That's a bit unclear to me. How are they interleaved ? +- FB_VISUAL_MONO01 + +Pixels are black or white and stored on one bit. A bit set to 1 represents a +black pixel and a bit set to 0 a white pixel. Pixels are packed together in +bytes with 8 pixels per byte. Actually we do have drivers that use 8 bits per pixel for a monochrome visual. Hence: Pixels are black or white. A black pixel is represented by all (typically one) bits set to ones, a white pixel by all bits set to zeroes. OK. I've rephrased it as Pixels are black or white and stored on a number of bits (typically one) specified by the variable screen information bpp field. Black pixels are represented by all bits set to 1 and white pixels by all bits set to 0. When the number of bits per pixel is smaller than 8, several pixels are packed together in a byte. +FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only. ... so this may also not be true (but it is for all current drivers, IIRC). There's a strict orthogonality between type (how is a pixel stored in memory) and visual (how the bits that represent the pixel are interpreted and converted to a color value). What about FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only. ? Same comments for FB_VISUAL_MONO10 Fixed the same way. +- FB_VISUAL_TRUECOLOR + +Pixels are broken into red, green and blue components, and each component +indexes a read-only lookup table for the corresponding value. Lookup tables +are device-dependent, and provide linear or non-linear ramps. + +Each component is stored in memory according to the variable screen +information red, green, blue and transp fields. Each component is stored in a macropixel according to the variable screen information red, green, blue and transp fields. Storage format in memory is determined by the FB_TYPE_* value. How so ? With FB_TYPE_PLANES and FB_VISUAL_TRUECOLOR for an RGB format, how are the R, G and B planes ordered ? Are color components packed or padded inside a plane ? I understand that the design goal was to have orthogonal FB_TYPE_* and FB_VISUAL_* values, but we're missing too much information for that to be truly generic. +- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR + +Pixel values are encoded as indices into a colormap that stores red, green and +blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR +and read-write for FB_VISUAL_PSEUDOCOLOR. + +Each pixel value is stored in the number of bits reported by the variable +screen information bits_per_pixel field. Pixels are contiguous in memory. Whether pixels are contiguous in memory or not is determined by the FB_TYPE_* value. How can they not be contiguous in memory ? Can you please give an example ? +FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR are used with +FB_TYPE_PACKED_PIXELS only. Not true. Several drivers use bit planes or interleaved bitplanes. How does that work ? +- FB_VISUAL_DIRECTCOLOR + +Pixels are broken into red, green and blue components, and each component +indexes a programmable lookup table for the corresponding value. + +Each component is stored in memory according to
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
Hi Tomasz,
On Monday 29 August 2011 10:01:58 Tomasz Stanislawski wrote:
On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
This patch fix the handling of data passed to V4L2 ioctls. The content
of the structures is not copied if the ioctl fails. It blocks ability
to obtain any information about occurred error other then errno code.
This patch fix this issue.
Does the V4L2 spec say anything on this topic ? We might have
applications that rely on the ioctl argument structure not being touched
when a failure occurs.
Ups.. I missed something. It looks that modifying ioctl content is
illegal if ioctl fails. The spec says:
When an ioctl that takes an output or read/write parameter fails, the
parameter remains unmodified. (v4l2 ioctl section)
However, there is probably a bug already present in V4L2 framework.
There are some ioctls that takes a pointer to an array as a field in the
argument struct.
The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF family.
The content of such an auxiliary arays is copied even if ioctl fails.
Please take a look to video_usercopy function in v4l2-ioctl.c. Therefore
I think that the spec is already violated. What is your opinion about
this problem?
I think it was a bad idea to state that a parameter remains unmodified when
the ioctl fails in the first place. I'm fine with not following that for new
ioctls, but applications might rely on it for existing ioctls.
Now back to selection case.
This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
return the best-hit rectangle if constraints could not be satisfied. The
ioctl return -ERANGE in this case. Using those return values the
application gets some feedback on loosing constraints.
Shouldn't that always be the case ? :-) VIDIOC_S_SELECTION should adjust the
rectangle up or down depending on the constraints and always return the best
match without any error.
I could remove rectangle returning from the spec and s5p-tv code for now.
--
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
[GIT PULL for v3.1-rc] OMAP_VOUT: Fix build failure
Hi Mauro, I missed this patch for last rc release, can you please queue up for next rc. The following changes since commit 55f9c40ff632d03c527d6a6ceddcda0a224587a6: Linus Torvalds (1): Merge git://git.kernel.org/.../davem/sparc are available in the git repository at: git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git for-linux-media-rc Archit Taneja (1): OMAP_VOUT: Fix build break caused by update_mode removal in DSS2 drivers/media/video/omap/omap_vout.c | 13 - 1 files changed, 0 insertions(+), 13 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: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Friday 26 August 2011 17:09:02 Mauro Carvalho Chehab wrote: Em 26-08-2011 11:16, Hans Verkuil escreveu: On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? Just as background information: the original idea was always that all v4l drivers would have a MC and that libv4l would use the information contained there as a helper (such as deciding which nodes would be the 'default' nodes for generic applications). This is something that libv4l won't do: it is up to the userspace application to choose the device node to open. I think this is one of our fundamental issues. Most applications are actually not interested in video nodes at all. What they want is a video device. Shouldn't libv4l should allow applications to enumerate video devices (as opposed to video nodes) and open them without caring about video nodes ? Ok, libv4l can have helper APIs for that, like the one I wrote, but even adding MC support on it may not solve the issues. Since there is only one MC device node for each piece of video hardware that would make it much easier to discover what hardware there is and what video nodes to use. I always liked that idea, although I know Mauro is opposed to having a MC for all v4l drivers. It doesn't make sense to add MC for all V4L drivers. Not all devices are like ivtv with lots of device drivers. In a matter of fact, most supported devices create just one video node. Adding MC support for those devices will just increase the drivers complexity without _any_ reason, as those devices are fully configurable using the existing ioctl's. Hans' proposal is to handle this in the V4L2 core for most drivers, so those drivers won't become more complex as they won't be modified at all. The MC API for those devices will only offer read-only enumeration, not link configuration. Also, as I said before, and implemented at xawtv and at a v4l-utils library, the code may use sysfs for simpler devices. It shouldn't be hard to implement a mc aware code there, although I don't think that MC API is useful to discover what nodes are meant to be used for TV, encoder, decoder, webcams, etc. The only type information it currently provides is: #define MEDIA_ENT_T_DEVNODE_V4L (MEDIA_ENT_T_DEVNODE + 1) #define MEDIA_ENT_T_DEVNODE_FB(MEDIA_ENT_T_DEVNODE + 2) #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) #define MEDIA_ENT_T_DEVNODE_DVB (MEDIA_ENT_T_DEVNODE + 4) So, a MC aware application also needs to be a hardware-dependent application, as it will need to use something else, like the media entity name, to discover for what purpose a media node is meant to be used. As Hans pointed out, this is because we haven't implemented more detailed information *yet*. It has always been a goal to provide more details through the MC API. While I am not opposed to creating such userspace maps I also think it is a bit of a poor-man's solution. The creation of per-type devices is part of the current API: radio and vbi nodes are examples of that (except that they aren't aliases, but real devices, but the idea is the same: different names for different types of usage). This would only work in a black-and-white world. Devices are often not just webcams or tv tuners. In particular I am worried that we get a lot of those mappings (just think of ivtv with
Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Hi Mauro, On Friday 26 August 2011 19:32:30 Mauro Carvalho Chehab wrote: Em 26-08-2011 12:29, Hans Verkuil escreveu: On Friday, August 26, 2011 17:09:02 Mauro Carvalho Chehab wrote: Em 26-08-2011 11:16, Hans Verkuil escreveu: On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? Just as background information: the original idea was always that all v4l drivers would have a MC and that libv4l would use the information contained there as a helper (such as deciding which nodes would be the 'default' nodes for generic applications). This is something that libv4l won't do: it is up to the userspace application to choose the device node to open. Ok, libv4l can have helper APIs for that, like the one I wrote, but even adding MC support on it may not solve the issues. Since there is only one MC device node for each piece of video hardware that would make it much easier to discover what hardware there is and what video nodes to use. I always liked that idea, although I know Mauro is opposed to having a MC for all v4l drivers. It doesn't make sense to add MC for all V4L drivers. Not all devices are like ivtv with lots of device drivers. In a matter of fact, most supported devices create just one video node. Adding MC support for those devices will just increase the drivers complexity without _any_ reason, as those devices are fully configurable using the existing ioctl's. It's for consistency so applications know what to expect. I've already said it before: We won't be implementing an API for a device just for consistency without any real reason. We have a real reason: providing a single API through which applications can enumerate devices and retrieve information such as device capabilities and relationships between devices. For all the simple drivers you'd just need some simple core support to add a MC. What I always thought would be handy is for applications to just iterate over all MCs and show which video/dvb/audio hardware the user has in its system. MC doesn't work for audio yet, *yet* as snd-usb-audio doesn't use it. So, it will fail for a large amount of devices whose audio is implemented using standard USB Audio Class. Adding MC support for it doesn't sound trivial, and won't offer any gain over the sysfs equivalent. Also, as I said before, and implemented at xawtv and at a v4l-utils library, the code may use sysfs for simpler devices. It shouldn't be hard to implement a mc aware code there, although I don't think that MC API is useful to discover what nodes are meant to be used for TV, encoder, decoder, webcams, etc. The only type information it currently provides is: #define MEDIA_ENT_T_DEVNODE_V4L(MEDIA_ENT_T_DEVNODE + 1) #define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2) #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) #define MEDIA_ENT_T_DEVNODE_DVB(MEDIA_ENT_T_DEVNODE + 4) That's because we never added meta information like that. As long as the MC is only used for SoC/complex drivers there is no point in adding such info. Even For SoC, such info would probably be useful. I agree, that's something we need. Most MC-related develop have been driven by products so far, this is just something we haven't implemented yet because there was no real need. It has
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent, On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Monday 29 August 2011 10:13:07 Geert Uytterhoeven wrote: On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart wrote: [snip] +- FB_TYPE_PACKED_PIXELS + +Color components (usually RGB or YUV) are packed together into macropixels +that are stored in a single plane. The exact color components layout is +described in a visual-dependent way. + +Frame buffer visuals that don't use multiple color components per pixel +(such as monochrome and pseudo-color visuals) are reported as packed frame +buffer types, even though they don't stricly speaking pack color components +into macropixels. That's because the packing is not about the color components, but about the bits that represent a single pixel. I.e. the bits that make up the pixel (the macropixel) are stored next to each other in memory. OK, I've modified that last sentence to read Frame buffer visuals that don't use multiple color components per pixel (such as monochrome and pseudo-color visuals) are also reported as packed frame buffer types, as the bits that make up individual pixels are packed next to each other in memory. Still not correct, as you don't grasp the concept of e.g. bitplanes yet (see below). The visual doesn't have anything to do with how the macropixels are stored in memory. +- FB_TYPE_PLANES + +Color components are stored in separate planes. Planes are located +contiguously in memory. The bits that make up a pixel are stored in separate planes. Planes are located contiguously in memory. I'm not sure to agree with this. You make it sounds like FB_TYPE_PLANES stores each bit in a different plane. Is that really the case ? Yes. First you store all first (fbdev does lack a way to specify little or big endian here) bits of each pixel in memory, contiguously. Then the second bit of each pixel, and so on. For 8 pixels (A - H) with 4 bits per pixel (0 - 3) (i.e. the first pixel is [A0 A1 A2 A3]), that would be like: A0 B0 C0 D0 E0 F0 G0 H0 A1 B1 C1 D1 E1 F1 G1 H1 A2 B2 C2 D2 E2 F2 G2 H2 A3 B3 C3 D3 E3 F3 G3 H3 http://en.wikipedia.org/wiki/Bit_plane http://en.wikipedia.org/wiki/Planar_(computer_graphics) http://en.wikipedia.org/wiki/Color_depth - FB_TYPE_INTERLEAVED_PLANES The bits that make up a pixel are stored in separate planes. Planes are interleaved. The interleave factor (the distance in bytes between the planes in memory) is stored in the type_aux field. That's a bit unclear to me. How are they interleaved ? Instead of storing the same bits of all pixels contiguously into memory, they are interleaved. Typically this is done per line (type_aux is the length of a line in bytes), or per word (Atari uses 2 bytes interleaving. E.g. for a 320 x 200 display, with FB_TYPE_PLANES, you would store 320 x 200 = 64000 first bits, followed 64000 second bits, and so on. With FB_TYPE_INTERLEAVED_PLANES and type_aux = 320 / 8 = 40, you store the first line of the screen as 320 first bits, followed by 320 second bits, and so on. Then the next line, as 320 first bits, followed by 320 second bits, and so on... Hence the bits that make up a pixel are spread across memory. It was useful in the days computers couldn't show many colors, and allows things like 5 or 6 bits per pixels. +- FB_VISUAL_MONO01 + +Pixels are black or white and stored on one bit. A bit set to 1 represents a +black pixel and a bit set to 0 a white pixel. Pixels are packed together in +bytes with 8 pixels per byte. Actually we do have drivers that use 8 bits per pixel for a monochrome visual. Hence: Pixels are black or white. A black pixel is represented by all (typically one) bits set to ones, a white pixel by all bits set to zeroes. OK. I've rephrased it as Pixels are black or white and stored on a number of bits (typically one) specified by the variable screen information bpp field. Black pixels are represented by all bits set to 1 and white pixels by all bits set to 0. When the number of bits per pixel is smaller than 8, several pixels are packed together in a byte. OK. +FB_VISUAL_MONO01 is used with FB_TYPE_PACKED_PIXELS only. ... so this may also not be true (but it is for all current drivers, IIRC). There's a strict orthogonality between type (how is a pixel stored in memory) and visual (how the bits that represent the pixel are interpreted and converted to a color value). What about FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only. ? stifb.c seems to use FB_TYPE_PLANES, but it uses bits_per_pixel is 1, so FB_TYPE_PACKED_PIXELS, FB_TYPE_PLANES, and FB_TYPE_INTERLEAVED_PLANES all degenerate to the same case anyway. +- FB_VISUAL_TRUECOLOR + +Pixels are broken into red, green and blue components, and each component +indexes a read-only lookup table for the corresponding value. Lookup tables +are device-dependent, and provide linear or non-linear
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert, On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote: On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote: On Monday 29 August 2011 10:13:07 Geert Uytterhoeven wrote: On Fri, Aug 19, 2011 at 11:37, Laurent Pinchart wrote: [snip] +- FB_TYPE_PACKED_PIXELS + +Color components (usually RGB or YUV) are packed together into macropixels +that are stored in a single plane. The exact color components layout is +described in a visual-dependent way. + +Frame buffer visuals that don't use multiple color components per pixel +(such as monochrome and pseudo-color visuals) are reported as packed frame +buffer types, even though they don't stricly speaking pack color components +into macropixels. That's because the packing is not about the color components, but about the bits that represent a single pixel. I.e. the bits that make up the pixel (the macropixel) are stored next to each other in memory. OK, I've modified that last sentence to read Frame buffer visuals that don't use multiple color components per pixel (such as monochrome and pseudo-color visuals) are also reported as packed frame buffer types, as the bits that make up individual pixels are packed next to each other in memory. Still not correct, as you don't grasp the concept of e.g. bitplanes yet (see below). The visual doesn't have anything to do with how the macropixels are stored in memory. +- FB_TYPE_PLANES + +Color components are stored in separate planes. Planes are located +contiguously in memory. The bits that make up a pixel are stored in separate planes. Planes are located contiguously in memory. I'm not sure to agree with this. You make it sounds like FB_TYPE_PLANES stores each bit in a different plane. Is that really the case ? Yes. First you store all first (fbdev does lack a way to specify little or big endian here) bits of each pixel in memory, contiguously. Then the second bit of each pixel, and so on. For 8 pixels (A - H) with 4 bits per pixel (0 - 3) (i.e. the first pixel is [A0 A1 A2 A3]), that would be like: A0 B0 C0 D0 E0 F0 G0 H0 A1 B1 C1 D1 E1 F1 G1 H1 A2 B2 C2 D2 E2 F2 G2 H2 A3 B3 C3 D3 E3 F3 G3 H3 http://en.wikipedia.org/wiki/Bit_plane http://en.wikipedia.org/wiki/Planar_(computer_graphics) http://en.wikipedia.org/wiki/Color_depth Thank you. That's clearer now. Planar formats in V4L2 are different, hence my initial confusion. If my understanding is now correct, a V4L2 planar YUV type where Y, U and V components are stored in separate byte-oriented planes, with each plane storing Y, U or V components packed (such as http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html), would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would be true for an RGB format where each component is stored in a separate plane with each plane sotring R, G or B packed. If the above is correct, what FB_TYPE_* should a driver report when using FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html) or V4L2_PIX_FMT_NV12 (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ? - FB_TYPE_INTERLEAVED_PLANES The bits that make up a pixel are stored in separate planes. Planes are interleaved. The interleave factor (the distance in bytes between the planes in memory) is stored in the type_aux field. That's a bit unclear to me. How are they interleaved ? Instead of storing the same bits of all pixels contiguously into memory, they are interleaved. Typically this is done per line (type_aux is the length of a line in bytes), or per word (Atari uses 2 bytes interleaving. E.g. for a 320 x 200 display, with FB_TYPE_PLANES, you would store 320 x 200 = 64000 first bits, followed 64000 second bits, and so on. With FB_TYPE_INTERLEAVED_PLANES and type_aux = 320 / 8 = 40, you store the first line of the screen as 320 first bits, followed by 320 second bits, and so on. Then the next line, as 320 first bits, followed by 320 second bits, and so on... Hence the bits that make up a pixel are spread across memory. It was useful in the days computers couldn't show many colors, and allows things like 5 or 6 bits per pixels. +- FB_VISUAL_MONO01 + +Pixels are black or white and stored on one bit. A bit set to 1 represents a +black pixel and a bit set to 0 a white pixel. Pixels are packed together in +bytes with 8 pixels per byte. Actually we do have drivers that use 8 bits per pixel for a monochrome visual. Hence: Pixels are black or white. A black pixel is represented by all (typically one) bits set to ones, a white pixel by all bits set to zeroes. OK. I've rephrased it as Pixels are black or white and stored on a number of bits (typically one) specified by the variable screen information bpp field. Black pixels are represented by all bits set to 1
Re: omap3isp and tvp5150 hangs
Hi Enrico,
On Friday 26 August 2011 17:02:59 Enrico wrote:
On Fri, Aug 26, 2011 at 12:52 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2011-08-26 04:42, Enrico wrote:
Hi,
i need some help to debug a kernel hang on an igep board (+ expansion)
when using omap3-isp and tvp5150 video capture. Kernel version is
mainline 3.0.1
I found that this driver is not compatible with the [new] v4l2_subdev
setup. In particular, it does not define any pads and the call to
media_entity_create_link()
in omap3isp/isp.c:1803 fires a BUG_ON() for this condition.
So basically what is needed is to implement pad functions and do
something like this:
static struct v4l2_subdev_pad_ops mt9v032_subdev_pad_ops = {
.enum_mbus_code = mt9v032_enum_mbus_code,
.enum_frame_size = mt9v032_enum_frame_size,
.get_fmt = mt9v032_get_format,
.set_fmt = mt9v032_set_format,
.get_crop = mt9v032_get_crop,
.set_crop = mt9v032_set_crop,
};
and add media init/cleanup functions? Can someone confirm this? Is
someone already working on this?
That's more or less it, yes. I'm not aware of anyone working on this.
--
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: Getting started with OMAP3 ISP
Hi Gary, On Thursday 25 August 2011 18:07:38 Gary Thomas wrote: Background: I have working video capture drivers based on the TI PSP codebase from 2.6.32. In particular, I managed to get a driver for the TVP5150 (analogue BT656) working with that kernel. Now I need to update to Linux 3.0, so I'm trying to get a driver working with the rewritten ISP code. Sadly, I'm having a hard time with this - probably just missing something basic. I've tried to clone the TVP514x driver which says that it works with the OMAP3 ISP code. I've updated it to use my decoder device, but I can't even seem to get into that code from user land. Here are the problems I've had so far: * udev doesn't create any video devices although they have been registered. I see a full set in /sys/class/video4linux # ls /sys/class/video4linux/ v4l-subdev0 v4l-subdev3 v4l-subdev6 video1 video4 v4l-subdev1 v4l-subdev4 v4l-subdev7 video2 video5 v4l-subdev2 v4l-subdev5 video0 video3 video6 It looks like a udev issue. I don't think that's related to the kernel drivers. Indeed, if I create /dev/videoX by hand, I can get somewhere, but I don't really understand how this is supposed to work. e.g. # v4l2-dbg --info /dev/video3 Driver info: Driver name : ispvideo Card type : OMAP3 ISP CCP2 input Bus info : media Driver version: 1 Capabilities : 0x0402 Video Output Streaming * If I try to grab video, the ISP layer gets a ton of warnings, but I never see it call down into my driver, e.g. to check the current format, etc. I have some of my own code from before which fails miserably (not a big surprise given the hack level of those programs). I tried something off-the-shelf which also fails pretty bad: # ffmpeg -t 10 -f video4linux2 -s 720x480 -r 30 -i /dev/video2 junk.mp4 I've read through Documentation/video4linux/omap3isp.txt without learning much about what might be wrong. Can someone give me some ideas/guidance, please? In a nutshell, you will first have to configure the OMAP3 ISP pipeline, and then capture video. Configuring the pipeline is done through the media controller API and the V4L2 subdev pad-level API. To experiment with those you can use the media-ctl command line application available at http://git.ideasonboard.org/?p=media- ctl.git;a=summary. You can run it with --print-dot and pipe the result to dot -Tps to get a postscript graphical view of your device. Here's a sample pipeline configuration to capture scaled-down YUV data from a sensor: ./media-ctl -r -l 'mt9t001 3-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:2-OMAP3 ISP preview:0[1], OMAP3 ISP preview:1-OMAP3 ISP resizer:0[1], OMAP3 ISP resizer:1-OMAP3 ISP resizer output:0[1]' ./media-ctl -f 'mt9t001 3-005d:0[SGRBG10 1024x768], OMAP3 ISP CCDC:2[SGRBG10 1024x767], OMAP3 ISP preview:1[YUYV 1006x759], OMAP3 ISP resizer:1[YUYV 800x600]' After configuring your pipeline you will be able to capture video using the V4L2 API on the device node at the output of the pipeline. -- 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
[...]
If my understanding is now correct, a V4L2 planar YUV type where Y, U and V
components are stored in separate byte-oriented planes, with each plane
storing Y, U or V components packed (such as http://linuxtv.org/downloads/v4l-
dvb-apis/V4L2-PIX-FMT-YUV422P.html), would be of neither FB_TYPE_PLANES nor
FB_TYPE_PACKED. The same would be true for an RGB format where each component
is stored in a separate plane with each plane sotring R, G or B packed.
Indeed. Currently this cannot be represented.
For ideas from the past, see e.g.
http://comments.gmane.org/gmane.linux.fbdev.devel/10951.
If the above is correct, what FB_TYPE_* should a driver report when using
FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P (http://linuxtv.org/downloads/v4l-
dvb-apis/V4L2-PIX-FMT-YUV422P.html) or V4L2_PIX_FMT_NV12
(http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?
We need new types for those. Or always use FOURCC for them.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert, On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote: On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote: On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote: On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote: [...] If my understanding is now correct, a V4L2 planar YUV type where Y, U and V components are stored in separate byte-oriented planes, with each plane storing Y, U or V components packed (such as http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html), would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would be true for an RGB format where each component is stored in a separate plane with each plane sotring R, G or B packed. Indeed. Currently this cannot be represented. Good, at least I now understand the situation :-) For ideas from the past, see e.g. http://comments.gmane.org/gmane.linux.fbdev.devel/10951. If the above is correct, what FB_TYPE_* should a driver report when using FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P (http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html) or V4L2_PIX_FMT_NV12 (http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ? We need new types for those. Or always use FOURCC for them. My proposal currently defined FB_VISUAL_FOURCC. What about adding FB_TYPE_FOURCC as well ? -- 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
On Mon, Aug 29, 2011 at 13:08, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote:
On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
[...]
If my understanding is now correct, a V4L2 planar YUV type where Y, U and
V components are stored in separate byte-oriented planes, with each
plane storing Y, U or V components packed (such as
http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html),
would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would be
true for an RGB format where each component is stored in a separate
plane with each plane sotring R, G or B packed.
Indeed. Currently this cannot be represented.
Good, at least I now understand the situation :-)
For ideas from the past, see e.g.
http://comments.gmane.org/gmane.linux.fbdev.devel/10951.
If the above is correct, what FB_TYPE_* should a driver report when using
FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P
(http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html)
or V4L2_PIX_FMT_NV12
(http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?
We need new types for those. Or always use FOURCC for them.
My proposal currently defined FB_VISUAL_FOURCC. What about adding
FB_TYPE_FOURCC as well ?
That may make sense.
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
- But what with modes that can be represented? Legacy software cannot
handle FB_{TYPE,VISUAL}_FOURCC.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] media: vb2: change queue initialization order
This patch changes the order of operations during stream on call. Now the
buffers are first queued to the driver and then the start_streaming method
is called.
This resolves the most common case when the driver needs to know buffer
addresses to enable dma engine and start streaming. Additional parameter
to start_streaming method have been added to simplify drivers code. The
driver are now obliged to check if the number of queued buffers is high
enough to enable hardware streaming. If not - it can return an error. In
such case all the buffers that have been pre-queued are invalidated.
This patch also updates all videobuf2 clients to work properly with the
changed order of operations.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
CC: Guennadi Liakhovetski g.liakhovet...@gmx.de
CC: Hans Verkuil hverk...@xs4all.nl
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: Sylwester Nawrocki s.nawro...@samsung.com
CC: Kamil Debski k.deb...@samsung.com
CC: Jonathan Corbet cor...@lwn.net
CC: Josh Wu josh...@atmel.com
CC: Hans de Goede hdego...@redhat.com
CC: Paul Mundt let...@linux-sh.org
---
Hello,
This is yet another version of the patch that introduces significant
changes in the vb2 streamon operation. I've decided to remove the
additional parameter to buf_queue callback and added a few cleanups here
and there. This patch also includes an update for all vb2 clients.
Please check if my change didn't break anything.
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
drivers/media/video/atmel-isi.c | 20 --
drivers/media/video/marvell-ccic/mcam-core.c |6 +-
drivers/media/video/pwc/pwc-if.c |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 65 +++---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|2 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c|2 +-
drivers/media/video/s5p-tv/mixer.h |2 -
drivers/media/video/s5p-tv/mixer_video.c | 22 +++---
drivers/media/video/videobuf2-core.c | 97 --
drivers/media/video/vivi.c |2 +-
include/media/videobuf2-core.h | 17 -
11 files changed, 131 insertions(+), 106 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7e1d789..4f4ee64 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -404,12 +404,13 @@ static void buffer_queue(struct vb2_buffer *vb)
if (isi-active == NULL) {
isi-active = buf;
- start_dma(isi, buf);
+ if (streaming)
+ start_dma(isi, buf);
}
spin_unlock_irqrestore(isi-lock, flags);
}
-static int start_streaming(struct vb2_queue *vq)
+static int start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
@@ -431,17 +432,26 @@ static int start_streaming(struct vb2_queue *vq)
ret = wait_event_interruptible(isi-vsync_wq,
isi-state != ISI_STATE_IDLE);
if (ret)
- return ret;
+ goto err;
- if (isi-state != ISI_STATE_READY)
- return -EIO;
+ if (isi-state != ISI_STATE_READY) {
+ ret = -EIO;
+ goto err;
+ }
spin_lock_irq(isi-lock);
isi-state = ISI_STATE_WAIT_SOF;
isi_writel(isi, ISI_INTDIS, ISI_SR_VSYNC);
+ if (count)
+ start_dma(isi, isi-active);
spin_unlock_irq(isi-lock);
return 0;
+err:
+ isi-active = NULL;
+ isi-sequence = 0;
+ INIT_LIST_HEAD(isi-video_buffer_list);
+ return ret;
}
/* abort streaming and wait for last buffer */
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 7abe503..1141b97 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -940,12 +940,14 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
/*
* These need to be called with the mutex held from vb2
*/
-static int mcam_vb_start_streaming(struct vb2_queue *vq)
+static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct mcam_camera *cam = vb2_get_drv_priv(vq);
- if (cam-state != S_IDLE)
+ if (cam-state != S_IDLE) {
+ INIT_LIST_HEAD(cam-buffers);
return -EINVAL;
+ }
cam-sequence = 0;
/*
* Videobuf2 sneakily hoards all the buffers and won't
diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index a7e4f56..360be22 100644
--- a/drivers/media/video/pwc/pwc-if.c
+++ b/drivers/media/video/pwc/pwc-if.c
@@ -816,7 +816,7 @@ static void
Re: [PATCH 4/5] [media] v4l: fix copying ioctl results on failure
On 08/29/2011 10:56 AM, Laurent Pinchart wrote:
Hi Tomasz,
On Monday 29 August 2011 10:01:58 Tomasz Stanislawski wrote:
On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
This patch fix the handling of data passed to V4L2 ioctls. The content
of the structures is not copied if the ioctl fails. It blocks ability
to obtain any information about occurred error other then errno code.
This patch fix this issue.
Does the V4L2 spec say anything on this topic ? We might have
applications that rely on the ioctl argument structure not being touched
when a failure occurs.
Ups.. I missed something. It looks that modifying ioctl content is
illegal if ioctl fails. The spec says:
When an ioctl that takes an output or read/write parameter fails, the
parameter remains unmodified. (v4l2 ioctl section)
However, there is probably a bug already present in V4L2 framework.
There are some ioctls that takes a pointer to an array as a field in the
argument struct.
The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF family.
The content of such an auxiliary arays is copied even if ioctl fails.
Please take a look to video_usercopy function in v4l2-ioctl.c. Therefore
I think that the spec is already violated. What is your opinion about
this problem?
I think it was a bad idea to state that a parameter remains unmodified when
the ioctl fails in the first place. I'm fine with not following that for new
ioctls, but applications might rely on it for existing ioctls.
Now back to selection case.
This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
return the best-hit rectangle if constraints could not be satisfied. The
ioctl return -ERANGE in this case. Using those return values the
application gets some feedback on loosing constraints.
Shouldn't that always be the case ? :-) VIDIOC_S_SELECTION should adjust the
rectangle up or down depending on the constraints and always return the best
match without any error.
ok.. but what to do if constraints could not be satisfied?
The configuration should not be applied to the hardware in such a case,
because it is not what the application desired.
Therefore the ioctl must fail ... somehow.
If the ioctl always succeed then the constraint flags becomes actually
the hints.
We may need TRY_SELECTION to test rectangles without applying it.
I thought that returning the best-hit rectangle by S_SELECTION might be
useful because
it gives the application some feedback on what the driver would accept.
I could remove rectangle returning from the spec and s5p-tv code for now.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 RESEND] media: vb2: change queue initialization order
This patch changes the order of operations during stream on call. Now the
buffers are first queued to the driver and then the start_streaming method
is called.
This resolves the most common case when the driver needs to know buffer
addresses to enable dma engine and start streaming. Additional parameter
to start_streaming method have been added to simplify drivers code. The
driver are now obliged to check if the number of queued buffers is high
enough to enable hardware streaming. If not - it can return an error. In
such case all the buffers that have been pre-queued are invalidated.
This patch also updates all videobuf2 clients to work properly with the
changed order of operations.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
CC: Guennadi Liakhovetski g.liakhovet...@gmx.de
CC: Hans Verkuil hverk...@xs4all.nl
CC: Tomasz Stanislawski t.stanisl...@samsung.com
CC: Sylwester Nawrocki s.nawro...@samsung.com
CC: Kamil Debski k.deb...@samsung.com
CC: Jonathan Corbet cor...@lwn.net
CC: Josh Wu josh...@atmel.com
CC: Hans de Goede hdego...@redhat.com
CC: Paul Mundt let...@linux-sh.org
---
Hello,
This is yet another version of the patch that introduces significant
changes in the vb2 streamon operation. I've decided to remove the
additional parameter to buf_queue callback and added a few cleanups here
and there. This patch also includes an update for all vb2 clients.
Please check if my change didn't break anything.
(I'm sorry for spamming, but previous version had wrong code for
atmel-isi driver).
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
drivers/media/video/atmel-isi.c | 20 --
drivers/media/video/marvell-ccic/mcam-core.c |6 +-
drivers/media/video/pwc/pwc-if.c |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 65 +++---
drivers/media/video/s5p-mfc/s5p_mfc_dec.c|2 +-
drivers/media/video/s5p-mfc/s5p_mfc_enc.c|2 +-
drivers/media/video/s5p-tv/mixer.h |2 -
drivers/media/video/s5p-tv/mixer_video.c | 22 +++---
drivers/media/video/videobuf2-core.c | 97 --
drivers/media/video/vivi.c |2 +-
include/media/videobuf2-core.h | 17 -
11 files changed, 131 insertions(+), 106 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 7e1d789..774715d 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -404,12 +404,13 @@ static void buffer_queue(struct vb2_buffer *vb)
if (isi-active == NULL) {
isi-active = buf;
- start_dma(isi, buf);
+ if (vb2_is_streaming(vb-vb2_queue))
+ start_dma(isi, buf);
}
spin_unlock_irqrestore(isi-lock, flags);
}
-static int start_streaming(struct vb2_queue *vq)
+static int start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct soc_camera_device *icd = soc_camera_from_vb2q(vq);
struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
@@ -431,17 +432,26 @@ static int start_streaming(struct vb2_queue *vq)
ret = wait_event_interruptible(isi-vsync_wq,
isi-state != ISI_STATE_IDLE);
if (ret)
- return ret;
+ goto err;
- if (isi-state != ISI_STATE_READY)
- return -EIO;
+ if (isi-state != ISI_STATE_READY) {
+ ret = -EIO;
+ goto err;
+ }
spin_lock_irq(isi-lock);
isi-state = ISI_STATE_WAIT_SOF;
isi_writel(isi, ISI_INTDIS, ISI_SR_VSYNC);
+ if (count)
+ start_dma(isi, isi-active);
spin_unlock_irq(isi-lock);
return 0;
+err:
+ isi-active = NULL;
+ isi-sequence = 0;
+ INIT_LIST_HEAD(isi-video_buffer_list);
+ return ret;
}
/* abort streaming and wait for last buffer */
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 7abe503..1141b97 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -940,12 +940,14 @@ static void mcam_vb_wait_finish(struct vb2_queue *vq)
/*
* These need to be called with the mutex held from vb2
*/
-static int mcam_vb_start_streaming(struct vb2_queue *vq)
+static int mcam_vb_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct mcam_camera *cam = vb2_get_drv_priv(vq);
- if (cam-state != S_IDLE)
+ if (cam-state != S_IDLE) {
+ INIT_LIST_HEAD(cam-buffers);
return -EINVAL;
+ }
cam-sequence = 0;
/*
* Videobuf2 sneakily hoards all the buffers and won't
diff --git a/drivers/media/video/pwc/pwc-if.c b/drivers/media/video/pwc/pwc-if.c
index a7e4f56..360be22 100644
---
Re: [PATCH v3] media: vb2: change queue initialization order
Hi Marek On Mon, 29 Aug 2011, Marek Szyprowski wrote: This patch changes the order of operations during stream on call. Now the buffers are first queued to the driver and then the start_streaming method is called. This resolves the most common case when the driver needs to know buffer addresses to enable dma engine and start streaming. Additional parameter to start_streaming method have been added to simplify drivers code. The driver are now obliged to check if the number of queued buffers is high enough to enable hardware streaming. If not - it can return an error. In such case all the buffers that have been pre-queued are invalidated. This patch also updates all videobuf2 clients to work properly with the changed order of operations. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: Pawel Osciak pa...@osciak.com CC: Guennadi Liakhovetski g.liakhovet...@gmx.de CC: Hans Verkuil hverk...@xs4all.nl CC: Tomasz Stanislawski t.stanisl...@samsung.com CC: Sylwester Nawrocki s.nawro...@samsung.com CC: Kamil Debski k.deb...@samsung.com CC: Jonathan Corbet cor...@lwn.net CC: Josh Wu josh...@atmel.com CC: Hans de Goede hdego...@redhat.com CC: Paul Mundt let...@linux-sh.org --- Hello, This is yet another version of the patch that introduces significant changes in the vb2 streamon operation. I've decided to remove the additional parameter to buf_queue callback and added a few cleanups here and there. This patch also includes an update for all vb2 clients. Just for the record: These are not all vb2 clients. A simple grep for something like vb2_ops gives you also drivers/media/video/mx3_camera.c drivers/media/video/sh_mobile_ceu_camera.c 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] media: Add support for arbitrary resolution for the ov5642 camera driver
Hi Laurent
On Sun, 28 Aug 2011, Laurent Pinchart wrote:
[snip]
@@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct i2c_client
*client) }
/* Find a data format by a pixel code in an array */
-static const struct ov5642_datafmt
- *ov5642_find_datafmt(enum v4l2_mbus_pixelcode code)
+static const struct ov5642_datafmt *ov5642_find_datafmt(enum
v4l2_mbus_pixelcode code) {
checkpatch.pl won't be happy.
Since the lift of the hard 80-char limit, I often find lines of 86 characters
more acceptable than their split versions.
[snip]
@@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd,
ov5642_try_fmt(sd, mf);
+ priv-out_size.width= mf-width;
+ priv-out_size.height = mf-height;
It looks like to me (but I may be wrong) that you achieve different
resolutions using cropping, not scaling. If that's correct you should
implement s_crop support and refuse changing the resolution through s_fmt.
As the patch explains (I think) on several occasions, currently only the
1:1 scale is supported, and it was our deliberate choice to implement this
using the scaling API
@@ -793,10 +868,12 @@ static int ov5642_g_fmt(struct v4l2_subdev *sd,
mf-code= fmt-code;
mf-colorspace = fmt-colorspace;
- mf-width = OV5642_WIDTH;
- mf-height = OV5642_HEIGHT;
+ mf-width = priv-out_size.width;
+ mf-height = priv-out_size.height;
mf-field = V4L2_FIELD_NONE;
+ dev_dbg(sd-v4l2_dev-dev, %s return width: %u heigth: %u\n, __func__,
+ mf-width, mf-height);
Isn't that a bit too verbose ? Printing the format in a debug message in the
s_fmt handler is useful, but maybe doing it in g_fmt is a bit too much.
This is a dev_dbg()... Personally, as long as they don't clutter the source
code needlessly, compile without warnings and have their typos fixed (;-))
I don't have problems with an odd instance, even if I don't really perceive
its output as particularly useful:-)
[snip]
+ dev_dbg(sd-v4l2_dev-dev, %s crop width: %u heigth: %u\n, __func__,
+ rect-width, rect-height);
Same comment as for g_fmt.
same reply:-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] media: vb2: change queue initialization order
Hello, On Monday, August 29, 2011 2:05 PM Guennadi Liakhovetski wrote: Hi Marek On Mon, 29 Aug 2011, Marek Szyprowski wrote: This patch changes the order of operations during stream on call. Now the buffers are first queued to the driver and then the start_streaming method is called. This resolves the most common case when the driver needs to know buffer addresses to enable dma engine and start streaming. Additional parameter to start_streaming method have been added to simplify drivers code. The driver are now obliged to check if the number of queued buffers is high enough to enable hardware streaming. If not - it can return an error. In such case all the buffers that have been pre-queued are invalidated. This patch also updates all videobuf2 clients to work properly with the changed order of operations. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: Pawel Osciak pa...@osciak.com CC: Guennadi Liakhovetski g.liakhovet...@gmx.de CC: Hans Verkuil hverk...@xs4all.nl CC: Tomasz Stanislawski t.stanisl...@samsung.com CC: Sylwester Nawrocki s.nawro...@samsung.com CC: Kamil Debski k.deb...@samsung.com CC: Jonathan Corbet cor...@lwn.net CC: Josh Wu josh...@atmel.com CC: Hans de Goede hdego...@redhat.com CC: Paul Mundt let...@linux-sh.org --- Hello, This is yet another version of the patch that introduces significant changes in the vb2 streamon operation. I've decided to remove the additional parameter to buf_queue callback and added a few cleanups here and there. This patch also includes an update for all vb2 clients. Just for the record: These are not all vb2 clients. A simple grep for something like vb2_ops gives you also drivers/media/video/mx3_camera.c drivers/media/video/sh_mobile_ceu_camera.c Yes, they are also vb2 clients, but since they don't use start_streaming() callback no changes were needed there. Same applies to mem2mem_testdev driver. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 3.2] dvb-usb: add ATSC support for the Hauppauge WinTV-Aero-M
Hello Mauro, Please pull from the aero-m branch of my mxl111sf tree to add ATSC support for the Hauppauge WinTV-Aero-M: The following changes since commit c9f88aa976b79a26561fb7754a1e0e00ff7626fe: Jose Alberto Reguero (1): [media] ttusb2: add support for the dvb-t part of CT-3650 v3 are available in the git repository at: http://git.linuxtv.org/mkrufky/mxl111sf.git aero-m Michael Krufky (2): dvb-usb: add ATSC support for the Hauppauge WinTV-Aero-M mxl111sf: Change adapter FE pointer as array of FE pointers. drivers/media/dvb/dvb-usb/Kconfig |8 + drivers/media/dvb/dvb-usb/Makefile |4 + drivers/media/dvb/dvb-usb/mxl111sf-gpio.c | 763 + drivers/media/dvb/dvb-usb/mxl111sf-gpio.h | 56 ++ drivers/media/dvb/dvb-usb/mxl111sf-i2c.c | 851 +++ drivers/media/dvb/dvb-usb/mxl111sf-i2c.h | 35 ++ drivers/media/dvb/dvb-usb/mxl111sf-phy.c | 342 +++ drivers/media/dvb/dvb-usb/mxl111sf-phy.h | 53 ++ drivers/media/dvb/dvb-usb/mxl111sf-reg.h | 179 ++ drivers/media/dvb/dvb-usb/mxl111sf-tuner.c | 476 drivers/media/dvb/dvb-usb/mxl111sf-tuner.h | 89 +++ drivers/media/dvb/dvb-usb/mxl111sf.c | 854 drivers/media/dvb/dvb-usb/mxl111sf.h | 158 + 13 files changed, 3868 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-gpio.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-gpio.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-i2c.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-i2c.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-phy.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-phy.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-reg.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-tuner.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf-tuner.h create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf.c create mode 100644 drivers/media/dvb/dvb-usb/mxl111sf.h Thanks regards, Michael Krufky -- 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: Add support for arbitrary resolution for the ov5642 camera driver
Hi Guennadi,
On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
On Sun, 28 Aug 2011, Laurent Pinchart wrote:
[snip]
@@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct
i2c_client *client) }
/* Find a data format by a pixel code in an array */
-static const struct ov5642_datafmt
- *ov5642_find_datafmt(enum v4l2_mbus_pixelcode code)
+static const struct ov5642_datafmt *ov5642_find_datafmt(enum
v4l2_mbus_pixelcode code) {
checkpatch.pl won't be happy.
Since the lift of the hard 80-char limit, I often find lines of 86
characters more acceptable than their split versions.
When has that been lifted ?
[snip]
@@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd,
ov5642_try_fmt(sd, mf);
+ priv-out_size.width= mf-width;
+ priv-out_size.height = mf-height;
It looks like to me (but I may be wrong) that you achieve different
resolutions using cropping, not scaling. If that's correct you should
implement s_crop support and refuse changing the resolution through
s_fmt.
As the patch explains (I think) on several occasions, currently only the
1:1 scale is supported, and it was our deliberate choice to implement this
using the scaling API
If you implement cropping, you should use the crop API, not the scaling API
:-)
@@ -793,10 +868,12 @@ static int ov5642_g_fmt(struct v4l2_subdev *sd,
mf-code= fmt-code;
mf-colorspace = fmt-colorspace;
- mf-width = OV5642_WIDTH;
- mf-height = OV5642_HEIGHT;
+ mf-width = priv-out_size.width;
+ mf-height = priv-out_size.height;
mf-field = V4L2_FIELD_NONE;
+ dev_dbg(sd-v4l2_dev-dev, %s return width: %u heigth: %u\n,
__func__, + mf-width, mf-height);
Isn't that a bit too verbose ? Printing the format in a debug message in
the s_fmt handler is useful, but maybe doing it in g_fmt is a bit too
much.
This is a dev_dbg()... Personally, as long as they don't clutter the source
code needlessly, compile without warnings and have their typos fixed (;-))
Removing it is a good way to fix the typo :-)
I don't have problems with an odd instance, even if I don't really perceive
its output as particularly useful:-)
--
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] media: Add support for arbitrary resolution for the ov5642 camera driver
On Mon, 29 Aug 2011, Laurent Pinchart wrote:
Hi Guennadi,
On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
On Sun, 28 Aug 2011, Laurent Pinchart wrote:
[snip]
@@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct
i2c_client *client) }
/* Find a data format by a pixel code in an array */
-static const struct ov5642_datafmt
- *ov5642_find_datafmt(enum v4l2_mbus_pixelcode
code)
+static const struct ov5642_datafmt *ov5642_find_datafmt(enum
v4l2_mbus_pixelcode code) {
checkpatch.pl won't be happy.
Since the lift of the hard 80-char limit, I often find lines of 86
characters more acceptable than their split versions.
When has that been lifted ?
Sorry, don't have a link at hand, a few months ago, either beginning of
this or end of last year, perhaps. There has been a lengthy discussion on
multiple lists, mainly lkml, the common mood was, that 80 chars wasn't
meaningful anymore, but I'm not sure what exact actions have been executed
to document this.
[snip]
@@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev *sd,
ov5642_try_fmt(sd, mf);
+ priv-out_size.width= mf-width;
+ priv-out_size.height = mf-height;
It looks like to me (but I may be wrong) that you achieve different
resolutions using cropping, not scaling. If that's correct you should
implement s_crop support and refuse changing the resolution through
s_fmt.
As the patch explains (I think) on several occasions, currently only the
1:1 scale is supported, and it was our deliberate choice to implement this
using the scaling API
If you implement cropping, you should use the crop API, not the scaling API
:-)
It's changing both - input and output sizes.
@@ -793,10 +868,12 @@ static int ov5642_g_fmt(struct v4l2_subdev *sd,
mf-code= fmt-code;
mf-colorspace = fmt-colorspace;
- mf-width = OV5642_WIDTH;
- mf-height = OV5642_HEIGHT;
+ mf-width = priv-out_size.width;
+ mf-height = priv-out_size.height;
mf-field = V4L2_FIELD_NONE;
+ dev_dbg(sd-v4l2_dev-dev, %s return width: %u heigth: %u\n,
__func__, + mf-width, mf-height);
Isn't that a bit too verbose ? Printing the format in a debug message in
the s_fmt handler is useful, but maybe doing it in g_fmt is a bit too
much.
This is a dev_dbg()... Personally, as long as they don't clutter the source
code needlessly, compile without warnings and have their typos fixed (;-))
Removing it is a good way to fix the typo :-)
I don't have problems with an odd instance, even if I don't really perceive
its output as particularly useful:-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] media: vb2: change queue initialization order
On Mon, 29 Aug 2011, Marek Szyprowski wrote: Hello, On Monday, August 29, 2011 2:05 PM Guennadi Liakhovetski wrote: Hi Marek On Mon, 29 Aug 2011, Marek Szyprowski wrote: This patch changes the order of operations during stream on call. Now the buffers are first queued to the driver and then the start_streaming method is called. This resolves the most common case when the driver needs to know buffer addresses to enable dma engine and start streaming. Additional parameter to start_streaming method have been added to simplify drivers code. The driver are now obliged to check if the number of queued buffers is high enough to enable hardware streaming. If not - it can return an error. In such case all the buffers that have been pre-queued are invalidated. This patch also updates all videobuf2 clients to work properly with the changed order of operations. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com CC: Pawel Osciak pa...@osciak.com CC: Guennadi Liakhovetski g.liakhovet...@gmx.de CC: Hans Verkuil hverk...@xs4all.nl CC: Tomasz Stanislawski t.stanisl...@samsung.com CC: Sylwester Nawrocki s.nawro...@samsung.com CC: Kamil Debski k.deb...@samsung.com CC: Jonathan Corbet cor...@lwn.net CC: Josh Wu josh...@atmel.com CC: Hans de Goede hdego...@redhat.com CC: Paul Mundt let...@linux-sh.org --- Hello, This is yet another version of the patch that introduces significant changes in the vb2 streamon operation. I've decided to remove the additional parameter to buf_queue callback and added a few cleanups here and there. This patch also includes an update for all vb2 clients. Just for the record: These are not all vb2 clients. A simple grep for something like vb2_ops gives you also drivers/media/video/mx3_camera.c drivers/media/video/sh_mobile_ceu_camera.c Yes, they are also vb2 clients, but since they don't use start_streaming() callback no changes were needed there. Same applies to mem2mem_testdev driver. Great, thanks for the explanation! 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] media: Add support for arbitrary resolution for the ov5642 camera driver
Hi Guennadi,
On Monday 29 August 2011 14:34:53 Guennadi Liakhovetski wrote:
On Mon, 29 Aug 2011, Laurent Pinchart wrote:
On Monday 29 August 2011 14:18:50 Guennadi Liakhovetski wrote:
On Sun, 28 Aug 2011, Laurent Pinchart wrote:
[snip]
@@ -593,8 +639,7 @@ static struct ov5642 *to_ov5642(const struct
i2c_client *client) }
/* Find a data format by a pixel code in an array */
-static const struct ov5642_datafmt
- *ov5642_find_datafmt(enum v4l2_mbus_pixelcode
code)
+static const struct ov5642_datafmt *ov5642_find_datafmt(enum
v4l2_mbus_pixelcode code) {
checkpatch.pl won't be happy.
Since the lift of the hard 80-char limit, I often find lines of 86
characters more acceptable than their split versions.
When has that been lifted ?
Sorry, don't have a link at hand, a few months ago, either beginning of
this or end of last year, perhaps. There has been a lengthy discussion on
multiple lists, mainly lkml, the common mood was, that 80 chars wasn't
meaningful anymore, but I'm not sure what exact actions have been executed
to document this.
I remember the discussion but I wasn't sure if anything had been decided and
set in stone.
[snip]
@@ -774,17 +839,27 @@ static int ov5642_s_fmt(struct v4l2_subdev
*sd,
ov5642_try_fmt(sd, mf);
+ priv-out_size.width= mf-width;
+ priv-out_size.height = mf-height;
It looks like to me (but I may be wrong) that you achieve different
resolutions using cropping, not scaling. If that's correct you should
implement s_crop support and refuse changing the resolution through
s_fmt.
As the patch explains (I think) on several occasions, currently only
the 1:1 scale is supported, and it was our deliberate choice to
implement this using the scaling API
If you implement cropping, you should use the crop API, not the scaling
API
:-)
It's changing both - input and output sizes.
Sure, but it's still cropping.
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert,
On Monday 29 August 2011 13:20:44 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 13:08, Laurent Pinchart wrote:
On Monday 29 August 2011 13:04:15 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 12:09, Laurent Pinchart wrote:
On Monday 29 August 2011 11:36:07 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 10:50, Laurent Pinchart wrote:
[...]
If my understanding is now correct, a V4L2 planar YUV type where Y, U
and V components are stored in separate byte-oriented planes, with
each plane storing Y, U or V components packed (such as
http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html),
would be of neither FB_TYPE_PLANES nor FB_TYPE_PACKED. The same would
be true for an RGB format where each component is stored in a
separate plane with each plane sotring R, G or B packed.
Indeed. Currently this cannot be represented.
Good, at least I now understand the situation :-)
For ideas from the past, see e.g.
http://comments.gmane.org/gmane.linux.fbdev.devel/10951.
If the above is correct, what FB_TYPE_* should a driver report when
using FB_VISUAL_FOURCC with V4L2_PIX_FMT_YUV422P
(http://linuxtv.org/downloads/v4l- dvb-apis/V4L2-PIX-FMT-YUV422P.html)
or V4L2_PIX_FMT_NV12
(http://linuxtv.org/downloads/v4l-dvb-apis/re25.html) for instance ?
We need new types for those. Or always use FOURCC for them.
My proposal currently defined FB_VISUAL_FOURCC. What about adding
FB_TYPE_FOURCC as well ?
That may make sense.
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
Definitely.
- But what with modes that can be represented? Legacy software cannot
handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is configured
using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a non-FOURCC
format, the driver will report non-FOURCC types and visuals.
--
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 4/5] [media] v4l: fix copying ioctl results on failure
Hi Tomasz,
On Monday 29 August 2011 13:55:31 Tomasz Stanislawski wrote:
On 08/29/2011 10:56 AM, Laurent Pinchart wrote:
On Monday 29 August 2011 10:01:58 Tomasz Stanislawski wrote:
On 08/26/2011 05:09 PM, Laurent Pinchart wrote:
On Friday 26 August 2011 15:06:06 Tomasz Stanislawski wrote:
This patch fix the handling of data passed to V4L2 ioctls. The
content of the structures is not copied if the ioctl fails. It
blocks ability to obtain any information about occurred error other
then errno code. This patch fix this issue.
Does the V4L2 spec say anything on this topic ? We might have
applications that rely on the ioctl argument structure not being
touched when a failure occurs.
Ups.. I missed something. It looks that modifying ioctl content is
illegal if ioctl fails. The spec says:
When an ioctl that takes an output or read/write parameter fails, the
parameter remains unmodified. (v4l2 ioctl section)
However, there is probably a bug already present in V4L2 framework.
There are some ioctls that takes a pointer to an array as a field in the
argument struct.
The examples are all VIDIOC_*_EXT_CTRLS and VIDIOC_{QUERY/DQ/Q}_BUF
family. The content of such an auxiliary arays is copied even if ioctl
fails. Please take a look to video_usercopy function in v4l2-ioctl.c.
Therefore I think that the spec is already violated. What is your
opinion about this problem?
I think it was a bad idea to state that a parameter remains unmodified
when the ioctl fails in the first place. I'm fine with not following
that for new ioctls, but applications might rely on it for existing
ioctls.
Now back to selection case.
This patch was added as proposition of fix to VIDIOC_S_SELECTION, to
return the best-hit rectangle if constraints could not be satisfied. The
ioctl return -ERANGE in this case. Using those return values the
application gets some feedback on loosing constraints.
Shouldn't that always be the case ? :-) VIDIOC_S_SELECTION should adjust
the rectangle up or down depending on the constraints and always return
the best match without any error.
ok.. but what to do if constraints could not be satisfied?
The configuration should not be applied to the hardware in such a case,
because it is not what the application desired.
Therefore the ioctl must fail ... somehow.
If the ioctl always succeed then the constraint flags becomes actually
the hints.
That's what currently happens with S_FMT. Is that behaviour too limited in
your opinion ?
We may need TRY_SELECTION to test rectangles without applying it.
I thought that returning the best-hit rectangle by S_SELECTION might be
useful because it gives the application some feedback on what the driver
would accept.
If we indeed need to fail with -ERANGE, I agree with you, the behaviour is
useful. It would make sense in that case to only update the parameter for a
specific set of ioctls. The V4L2 documentation will also need to be fixed.
--
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: [ANN] Meeting minutes of the Cambourne meeting
Hi Sylwester,
On Sunday 28 August 2011 13:28:23 Sylwester Nawrocki wrote:
On 08/08/2011 05:50 PM, Laurent Pinchart wrote:
Subdevs hierachy, Linux device model
Preliminary conclusions:
- With the move to device tree on ARM (and other platforms), I2C, SPI
and
platform subdevs should be created from board code, not from
bridge/host drivers.
- Bus notifiers should be used by bridge/host drivers to wait for all
required subdevs. V4L2 core should provide helper functions.
- struct clk should be used to handle clocks provided by hosts to
subdevs.
I have been investigating recently possible ways to correct the external
clock handling in Samsung FIMC driver and this led me up to the device
tree stuff. I.e. in order to be able to register any I2C client device
there is a need to enable its master clock at the v4l2 host/bridge driver.
To be completely generic, the subdev master clock can come from anywhere, not
only from the V4L2 host/bridge (although that's the usual case).
There is an issue that the v4l2_device (host)/v4l2_subdev hierarchy is not
reflected by the linux device tree model, e.g. the host might be a platform
device while the client an I2C client device. Thus a proper device/driver
registration order is not assured by the device driver core from v4l2 POV.
I thought about embedding some API in a struct v4l2_device for the subdevs
to be able to get their master clock(s) as they need it. But this would
work only when a v4l2_device and v4l2_subdev are matched (registered)
before I2C client's probe(), or alternatively
subdev_internal_ops::registered() callback, is called.
Currently such requirement is satisfied when the I2C client/v4l2 subdev
devices are registered from within a v4l2 bridge/host driver initialization
routine. But we may need to stop doing this to adhere to the DT rules.
Right, that's my understanding as well.
I guess above you didn't really mean to create subdevs from board code?
The I2C client registration is now done at the I2C bus drivers, using the
OF helpers to retrieve the child devices list from fdt.
I meant registering the I2C board information from board code (for non-DT
platforms) or from the device tree (for DT platforms) instead of V4L2
host/bridge drivers.
I guess we could try to create some sort of replacement for
v4l2_i2c_new_subdev_board() function in linux/drivers/of/* (of_i2c.c ?),
similar to of_i2c_register_devices().
But first we would have somehow to make sure the host drivers are registered
and initialized first. I'm not sure how to do it.
Plus such a new subdev registration method would have to obtain a relevant
struct v4l2_device object reference during the process; which is getting
a bit cumbersome..
Also, if we used a 'struct clk' to handle clocks provided by hosts to
subdevs, could we use any subdev operation callback to pass a reference to
such object from host to subdev? I doubt since the clock may be needed in
the subdev before it is allocated and fully initialized, (i.e. available
in the host).
If we have embedded a 'struct clk' pointer into struct v4l2_device, it
would have probably to be an array of clocks and the subdev would have to
be able to find out which clock applies to it.
So I thought about doing something like:
diff --git a/include/media/v4l2-device.h b/include/media/v4l2-device.h
index d61febf..9888f7d 100644
--- a/include/media/v4l2-device.h
+++ b/include/media/v4l2-device.h
@@ -54,6 +54,7 @@ struct v4l2_device {
/* notify callback called by some sub-devices. */
void (*notify)(struct v4l2_subdev *sd,
unsigned int notification, void *arg);
+ const struct clk * (*clock_get)(struct v4l2_subdev *sd);
/* The control handler. May be NULL. */
struct v4l2_ctrl_handler *ctrl_handler;
/* Device's priority state */
This would allow the host to return proper clock for a subdev.
But it won't work unless the initialization order is assured..
My idea was to let the kernel register all devices based on the DT or board
code. When the V4L2 host/bridge driver gets registered, it will then call a
V4L2 core function with a list of subdevs it needs. The V4L2 core would store
that information and react to bus notifier events to notify the V4L2
host/bridge driver when all subdevs are present. At that point the host/bridge
driver will get hold of all the subdevs and call (probably through the V4L2
core) their .registered operation. That's where the subdevs will get access to
their clock using clk_get().
This is really a rough idea, we will probably run into unexpected issues. I'm
not even sure if this can work out in the end, but I don't really see another
clean solution for now.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
Definitely.
- But what with modes that can be represented? Legacy software cannot
handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is configured
using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a non-FOURCC
format, the driver will report non-FOURCC types and visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool (fbset on
steroids).
Later the user runs a legacy application.
= Do not retain FOURCC across opening of /dev/fb*.
- Is there an easy way to force FOURCC reporting, so new apps don't have to
support parsing the legacy formats? This is useful for new apps that want to
support (a subset of) FOURCC modes only.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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
Usb digital TV
Hello, I am from Brazil and my english is not very good. First of all, I am new on the list. I work with embedded system development here in Brazil. I have a lot to learn but I expect to help too! I don't know if it is the right place to ask. Sorry if it is not. I have a i.mx28EVK board and I would like to get a usb digital tv module to work on it. It should work in 1seg. First of all I bought a two usb devices: - pixelview sbtvd hybrid - Leadership The first one uses driver cx231xx and the second one smsdvb. My board have a 2.6.35 kernel with specific paths from freescale. First off all I tried to plug the first device in my pc. It only worked with an newer kernel version 2.6.38 or with some specific pathes for brazil patterns in a 2.6.36. I was able to see some channels here. But It seems very dificult to me to port all these changes and make it work on my old 2.6.35 kernel. The second device has a strange behavior. It worked on my PC with older kernels like 2.6.32. It should work in my mx28 board too. But I cannot scan any channel!?!?!? In dmesg i got: [ 332.620053] smscore_set_device_mode: firmware download success: isdbt_nova_12mhz_b0.inp [ 332.620615] usbcore: registered new interface driver smsusb [ 350.721231] DVB: registering new adapter (Siano Nova B Digital Receiver) [ 350.724588] DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... In my /dev/dvb/adapter0 I have three devices: - demux0 - dvr0 - frontend0 If I tried to scan with: sudo w_scan -ft -x -c BR I got the follow messages: ERROR: Sorry - i couldn't get any working frequency/transponder Can someone help me with this last thing? It seems everything is ok but I cannot scan channel. It there some devices that has more chance to work on a 2.6.35 kernel version so I can just cross compile the driver to my mx28 board in a easier way? Thanks in advance. Gabriel Sartori -- 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert,
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
Definitely.
- But what with modes that can be represented? Legacy software cannot
handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a
non-FOURCC format, the driver will report non-FOURCC types and visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool (fbset on
steroids).
Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Later the user runs a legacy application.
= Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We have no
per-open fixed and variable screen info, and FB devices can be opened by
multiple applications at the same time.
- Is there an easy way to force FOURCC reporting, so new apps don't have
to support parsing the legacy formats? This is useful for new apps that
want to support (a subset of) FOURCC modes only.
Not at the moment.
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
Definitely.
- But what with modes that can be represented? Legacy software cannot
handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with a
non-FOURCC format, the driver will report non-FOURCC types and visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool (fbset on
steroids).
Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Yep.
Later the user runs a legacy application.
= Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We have no
per-open fixed and variable screen info, and FB devices can be opened by
multiple applications at the same time.
- Is there an easy way to force FOURCC reporting, so new apps don't have
to support parsing the legacy formats? This is useful for new apps that
want to support (a subset of) FOURCC modes only.
Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Geert,
On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
Definitely.
- But what with modes that can be represented? Legacy software
cannot handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with
a non-FOURCC format, the driver will report non-FOURCC types and
visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool (fbset on
steroids).
Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Yep.
Later the user runs a legacy application.
= Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We have
no per-open fixed and variable screen info, and FB devices can be opened
by multiple applications at the same time.
- Is there an easy way to force FOURCC reporting, so new apps don't
have to support parsing the legacy formats? This is useful for new apps
that want to support (a subset of) FOURCC modes only.
Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls for
the above two operations ?
--
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: Usb digital TV
Hi Gabriel, On 8/29/11, Gabriel Sartori gabriel.sart...@gmail.com wrote: It there some devices that has more chance to work on a 2.6.35 kernel version so I can just cross compile the driver to my mx28 board in a easier way? Thanks in advance. I suggest you using a device based on dib0700, I got it working on Linux = 2.6.35: https://acassis.wordpress.com/2009/09/18/watching-digital-tv-sbtvd-in-the-linux/ This same device working on i-MXT (Android 2.2 with Linux kernel 2.6.35): http://holoscopio.com/misc/androidtv/ Best Regards, Alan -- 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Laurent,
On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy way,
Definitely.
- But what with modes that can be represented? Legacy software
cannot handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called with
a non-FOURCC format, the driver will report non-FOURCC types and
visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool (fbset on
steroids).
Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Yep.
Later the user runs a legacy application.
= Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We have
no per-open fixed and variable screen info, and FB devices can be opened
by multiple applications at the same time.
- Is there an easy way to force FOURCC reporting, so new apps don't
have to support parsing the legacy formats? This is useful for new apps
that want to support (a subset of) FOURCC modes only.
Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls for
the above two operations ?
New ioctls to replace the FOURCC proposal.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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: Smart card reader support for Anysee DVB devices
Hi, 2011/8/17 Antti Palosaari cr...@iki.fi: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Regards, Istvan regards, Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Smart card reader support for Anysee DVB devices
On 08/29/2011 05:44 PM, István Váradi wrote: Hi, 2011/8/17 Antti Palosaaricr...@iki.fi: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, implementing new protocol is totally dead idea. It will never got any support. There is already such drivers, at least Infinity Unlimited USB Phoenix driver (iuu_phoenix.c). It uses USB-serial driver framework and some small emulation for Phoenix protocol. Look that driver to see which kind of complexity it adds. Anysee have *just* same situation. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Embedded device and the V4L2 API support - Was: [GIT PATCHES FOR 3.1] s5p-fimc and noon010pc30 driver updates
Em 29-08-2011 06:24, Laurent Pinchart escreveu: Hi Mauro, On Friday 26 August 2011 19:32:30 Mauro Carvalho Chehab wrote: Em 26-08-2011 12:29, Hans Verkuil escreveu: On Friday, August 26, 2011 17:09:02 Mauro Carvalho Chehab wrote: Em 26-08-2011 11:16, Hans Verkuil escreveu: On Friday, August 26, 2011 15:45:30 Laurent Pinchart wrote: On Thursday 25 August 2011 14:43:56 Mauro Carvalho Chehab wrote: Em 24-08-2011 19:29, Sakari Ailus escreveu: [snip] The question I still have on this is that how should the user know which video node to access on an embedded system with a camera: the OMAP 3 ISP, for example, contains some eight video nodes which have different ISP blocks connected to them. Likely two of these nodes are useful for a general purpose application based on which image format it requests. It would make sense to provide generic applications information only on those devices they may meaningfully use. IMO, we should create a namespace device mapping for video devices. What I mean is that we should keep the raw V4L2 devices as: /dev/video?? But also recommend the creation of a new userspace map, like: /dev/webcam?? /dev/tv?? ... with is an alias for the actual device. Something similar to dvd/cdrom aliases that already happen on most distros: lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrom - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 cdrw - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvd - sr0 lrwxrwxrwx 1 root root 3 Ago 24 12:14 dvdrw - sr0 I've been toying with a similar idea. libv4l currently wraps /dev/video* device nodes and assumes a 1:1 relationship between a video device node and a video device. Should this assumption be somehow removed, replaced by a video device concept that wouldn't be tied to a single video device node ? Just as background information: the original idea was always that all v4l drivers would have a MC and that libv4l would use the information contained there as a helper (such as deciding which nodes would be the 'default' nodes for generic applications). This is something that libv4l won't do: it is up to the userspace application to choose the device node to open. Ok, libv4l can have helper APIs for that, like the one I wrote, but even adding MC support on it may not solve the issues. Since there is only one MC device node for each piece of video hardware that would make it much easier to discover what hardware there is and what video nodes to use. I always liked that idea, although I know Mauro is opposed to having a MC for all v4l drivers. It doesn't make sense to add MC for all V4L drivers. Not all devices are like ivtv with lots of device drivers. In a matter of fact, most supported devices create just one video node. Adding MC support for those devices will just increase the drivers complexity without _any_ reason, as those devices are fully configurable using the existing ioctl's. It's for consistency so applications know what to expect. I've already said it before: We won't be implementing an API for a device just for consistency without any real reason. We have a real reason: providing a single API through which applications can enumerate devices and retrieve information such as device capabilities and relationships between devices. There's no need to enumerate the relationship for a device with just one video node, and where everything is configured via V4L2 API. Adding MC support will only make things confusing. Also, see bellow. For all the simple drivers you'd just need some simple core support to add a MC. What I always thought would be handy is for applications to just iterate over all MCs and show which video/dvb/audio hardware the user has in its system. MC doesn't work for audio yet, *yet* as snd-usb-audio doesn't use it. So, it will fail for a large amount of devices whose audio is implemented using standard USB Audio Class. Adding MC support for it doesn't sound trivial, and won't offer any gain over the sysfs equivalent. Also, as I said before, and implemented at xawtv and at a v4l-utils library, the code may use sysfs for simpler devices. It shouldn't be hard to implement a mc aware code there, although I don't think that MC API is useful to discover what nodes are meant to be used for TV, encoder, decoder, webcams, etc. The only type information it currently provides is: #define MEDIA_ENT_T_DEVNODE_V4L(MEDIA_ENT_T_DEVNODE + 1) #define MEDIA_ENT_T_DEVNODE_FB (MEDIA_ENT_T_DEVNODE + 2) #define MEDIA_ENT_T_DEVNODE_ALSA (MEDIA_ENT_T_DEVNODE + 3) #define MEDIA_ENT_T_DEVNODE_DVB(MEDIA_ENT_T_DEVNODE + 4) That's because we never added meta information like that. As long as the MC is only used for SoC/complex drivers there is no point in adding such info. Even For SoC, such info would probably be useful. I agree, that's something
[PATCH v2 0/8] RFC for Media Controller capture driver for DM365
changes from last patch set: 1. Made changes based on Sakari's feedback mainly: a. returned early to allow unindenting b. reformatting to shift the code to left where possible c. changed hex numbers to lower case d. corrected the defines according to module names. e. magic numbers removed. f. changed non-integer returning functions to void g. removed unwanted paranthses. h. fixed error codes. i. fixed some RESET_BIt code to what it was intended for. 2. reorganized the header files to move the kernel-only headers along with the c files and interface headers in the include folder. Manjunath Hadli (6): davinci: vpfe: add dm3xx IPIPEIF hardware support module davinci: vpfe: add support for CCDC hardware for dm365 davinci: vpfe: add ccdc driver with media controller interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: v4l2 capture driver with media interface davinci: vpfe: build infrastructure for dm365 Nagabhushana Netagunte (2): davinci: vpfe: add IPIPE hardware layer support davinci: vpfe: add IPIPE support for media controller driver drivers/media/video/davinci/Kconfig | 46 +- drivers/media/video/davinci/Makefile | 17 +- drivers/media/video/davinci/ccdc_hw_device.h | 10 +- drivers/media/video/davinci/ccdc_types.h | 43 + drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ drivers/media/video/davinci/dm365_ccdc.h | 88 + drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ drivers/media/video/davinci/dm365_def_para.c | 486 +++ drivers/media/video/davinci/dm365_def_para.h | 39 + drivers/media/video/davinci/dm365_ipipe.c | 3966 + drivers/media/video/davinci/dm365_ipipe.h | 300 ++ drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ drivers/media/video/davinci/dm365_ipipe_hw.h | 539 drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ drivers/media/video/davinci/imp_common.h | 85 + drivers/media/video/davinci/imp_hw_if.h | 178 ++ drivers/media/video/davinci/vpfe_capture.c| 793 + drivers/media/video/davinci/vpfe_capture.h| 104 + drivers/media/video/davinci/vpfe_ccdc.c | 813 + drivers/media/video/davinci/vpfe_ccdc.h | 85 + drivers/media/video/davinci/vpfe_video.c | 1712 +++ drivers/media/video/davinci/vpfe_video.h | 142 + include/linux/davinci_vpfe.h | 1223 include/linux/dm365_ccdc.h| 664 + include/linux/dm3xx_ipipeif.h | 64 + include/media/davinci/vpfe.h | 91 + 27 files changed, 14829 insertions(+), 11 deletions(-) create mode 100644 drivers/media/video/davinci/ccdc_types.h create mode 100644 drivers/media/video/davinci/dm365_ccdc.c create mode 100644 drivers/media/video/davinci/dm365_ccdc.h create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h create mode 100644 drivers/media/video/davinci/dm365_def_para.c create mode 100644 drivers/media/video/davinci/dm365_def_para.h create mode 100644 drivers/media/video/davinci/dm365_ipipe.c create mode 100644 drivers/media/video/davinci/dm365_ipipe.h create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h create mode 100644 drivers/media/video/davinci/imp_common.h create mode 100644 drivers/media/video/davinci/imp_hw_if.h create mode 100644 drivers/media/video/davinci/vpfe_capture.c create mode 100644 drivers/media/video/davinci/vpfe_capture.h create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h create mode 100644 drivers/media/video/davinci/vpfe_video.c create mode 100644 drivers/media/video/davinci/vpfe_video.h create mode 100644 include/linux/davinci_vpfe.h create mode 100644 include/linux/dm365_ccdc.h create mode 100644 include/linux/dm3xx_ipipeif.h create mode 100644 include/media/davinci/vpfe.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 v2 5/8] davinci: vpfe: add ccdc driver with media controller interface
Add the CCDC driver for davinci Dm3XX SoCs. The driver supports
CCDC as a media entity with 2 pads - 1 input and 1 output. The
driver implements streaming support and subdev interface. The
ccdc supports bayer and YUV formats.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/ccdc_hw_device.h | 10 +-
drivers/media/video/davinci/vpfe_ccdc.c | 813 ++
drivers/media/video/davinci/vpfe_ccdc.h | 85 +++
3 files changed, 901 insertions(+), 7 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c
create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
index 86b9b35..5394a06 100644
--- a/drivers/media/video/davinci/ccdc_hw_device.h
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -23,8 +23,8 @@
#ifdef __KERNEL__
#include linux/videodev2.h
#include linux/device.h
-#include media/davinci/vpfe_types.h
-#include media/davinci/ccdc_types.h
+#include ccdc_types.h
+#include media/davinci/vpfe.h
/*
* ccdc hw operations
@@ -57,7 +57,7 @@ struct ccdc_hw_ops {
*/
int (*get_params) (void *params);
/* Pointer to function to configure ccdc */
- int (*configure) (void);
+ int (*configure) (int mode);
/* Pointer to function to set buffer type */
int (*set_buftype) (enum ccdc_buftype buf_type);
@@ -102,9 +102,5 @@ struct ccdc_hw_device {
struct ccdc_hw_ops hw_ops;
};
-/* Used by CCDC module to register unregister with vpfe capture driver */
-int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
-void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
-
#endif
#endif
diff --git a/drivers/media/video/davinci/vpfe_ccdc.c
b/drivers/media/video/davinci/vpfe_ccdc.c
new file mode 100644
index 000..57d8b3d
--- /dev/null
+++ b/drivers/media/video/davinci/vpfe_ccdc.c
@@ -0,0 +1,813 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contributors:
+ * Manjunath Hadli manjunath.ha...@ti.com
+ * Nagabhushana Netagunte nagabhushana.netagu...@ti.com
+ */
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/v4l2-mediabus.h
+#include media/v4l2-device.h
+#include media/media-entity.h
+#include vpfe_capture.h
+
+#include ccdc_hw_device.h
+
+#define MAX_WIDTH 4096
+#define MAX_HEIGHT 4096
+
+static const unsigned int ccdc_fmts[] = {
+ V4L2_MBUS_FMT_Y8_1X8,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YUYV8_1X16,
+ V4L2_MBUS_FMT_YUYV10_1X20,
+ V4L2_MBUS_FMT_SBGGR10_1X10,
+};
+
+/*
+ * CCDC helper functions
+ */
+/* get field id in ccdc hardware */
+enum v4l2_field ccdc_get_fid(struct vpfe_device *vpfe_dev)
+{
+ struct vpfe_ccdc_device *ccdc = vpfe_dev-vpfe_ccdc;
+ struct ccdc_hw_device *ccdc_dev = ccdc-ccdc_dev;
+
+ return ccdc_dev-hw_ops.getfid();
+}
+
+/* Retrieve active or try pad format based on query */
+static struct v4l2_mbus_framefmt *
+__ccdc_get_format(struct vpfe_ccdc_device *ccdc, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+ if (which == V4L2_SUBDEV_FORMAT_TRY) {
+ struct v4l2_subdev_format fmt;
+
+ fmt.pad = pad;
+ fmt.which = which;
+
+ return v4l2_subdev_get_try_format(fh, pad);
+ } else
+ return ccdc-formats[pad];
+}
+
+/* configure format in ccdc hardware */
+static int vpfe_config_ccdc_format(struct vpfe_device *vpfe_dev,
+ unsigned int pad)
+{
+ struct ccdc_hw_device *ccdc_dev = vpfe_dev-vpfe_ccdc.ccdc_dev;
+ struct vpfe_ccdc_device *vpfe_ccdc = vpfe_dev-vpfe_ccdc;
+ enum ccdc_frmfmt frm_fmt = CCDC_FRMFMT_INTERLACED;
+ struct v4l2_pix_format format;
+ int ret = 0;
+
+ v4l2_fill_pix_format(format, vpfe_dev-vpfe_ccdc.formats[pad]);
+ mbus_to_pix(vpfe_dev-vpfe_ccdc.formats[pad], format);
+
+ if (ccdc_dev-hw_ops.set_pixel_format(
+ format.pixelformat) 0) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ couldn't set pix format in ccdc\n);
+ return
[PATCH v2 2/8] davinci: vpfe: add IPIPE hardware layer support
From: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
add dm365 IPIPE hardware support. IPIPE is the hardware IP which
implements the functionality required for resizer, previewer and
the associated feature support. This is built along with the vpfe
driver, and implements hardware setup including coeffcient
programming for various hardware filters, gamma, cfa and clock
enable.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++
drivers/media/video/davinci/dm365_ipipe_hw.h | 539 +++
2 files changed, 1488 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c
create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h
diff --git a/drivers/media/video/davinci/dm365_ipipe_hw.c
b/drivers/media/video/davinci/dm365_ipipe_hw.c
new file mode 100644
index 000..cb8f6e3
--- /dev/null
+++ b/drivers/media/video/davinci/dm365_ipipe_hw.c
@@ -0,0 +1,949 @@
+/*
+* Copyright (C) 2011 Texas Instruments Inc
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation version 2.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+*/
+#include linux/errno.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/v4l2-mediabus.h
+#include media/davinci/vpfe.h
+#include dm365_ipipe.h
+#include dm3xx_ipipeif.h
+#include dm365_ipipe_hw.h
+
+static void ipipe_clock_enable(void)
+{
+ /* enable IPIPE MMR for register write access */
+ regw_ip(IPIPE_GCK_MMR_DEFAULT, IPIPE_GCK_MMR);
+ /* enable the clock wb,cfa,dfc,d2f,pre modules */
+ regw_ip(IPIPE_GCK_PIX_DEFAULT, IPIPE_GCK_PIX);
+ /* enable RSZ MMR for register write access */
+}
+
+/* Set input channel format to either 420 Y or C format */
+void rsz_set_in_pix_format(unsigned char y_c)
+{
+ u32 val;
+
+ val = regr_rsz(RSZ_SRC_FMT1);
+ val |= y_c 1;
+ regw_rsz(val, RSZ_SRC_FMT1);
+}
+
+static void rsz_set_common_params(struct ipipe_params *params)
+{
+ struct rsz_common_params *rsz_common = params-rsz_common;
+ u32 val;
+
+ /* Set mode */
+ regw_rsz(params-ipipe_mode, RSZ_SRC_MODE);
+
+ /* data source selection and bypass */
+ val = (rsz_common-passthrough RSZ_BYPASS_SHIFT) |
+ rsz_common-source;
+
+ regw_rsz(val, RSZ_SRC_FMT0);
+ val = regr_rsz(RSZ_SRC_MODE);
+ /* src image selection */
+ val = (rsz_common-raw_flip 1) |
+ (rsz_common-src_img_fmt RSZ_SRC_IMG_FMT_SHIFT) |
+ ((rsz_common-y_c 1) RSZ_SRC_Y_C_SEL_SHIFT);
+
+ regw_rsz(val, RSZ_SRC_FMT1);
+ regw_rsz(rsz_common-vps IPIPE_RSZ_VPS_MASK, RSZ_SRC_VPS);
+ regw_rsz(rsz_common-hps IPIPE_RSZ_HPS_MASK, RSZ_SRC_HPS);
+ regw_rsz(rsz_common-vsz IPIPE_RSZ_VSZ_MASK, RSZ_SRC_VSZ);
+ regw_rsz(rsz_common-hsz IPIPE_RSZ_HSZ_MASK, RSZ_SRC_HSZ);
+ regw_rsz(rsz_common-yuv_y_min, RSZ_YUV_Y_MIN);
+ regw_rsz(rsz_common-yuv_y_max, RSZ_YUV_Y_MAX);
+ regw_rsz(rsz_common-yuv_c_min, RSZ_YUV_C_MIN);
+ regw_rsz(rsz_common-yuv_c_max, RSZ_YUV_C_MAX);
+ /* chromatic position */
+ regw_rsz(rsz_common-out_chr_pos, RSZ_YUV_PHS);
+ val = regr_rsz(RSZ_SRC_MODE);
+}
+
+static void rsz_set_rsz_regs(unsigned int rsz_id, struct ipipe_params *params)
+{
+ struct ipipe_rsz_rescale_param *rsc_params;
+ struct ipipe_ext_mem_param *ext_mem;
+ struct ipipe_rsz_resize2rgb *rgb;
+ u32 reg_base;
+ u32 val;
+
+ val = regr_rsz(RSZ_SEQ);
+ rsc_params = params-rsz_rsc_param[rsz_id];
+ rgb = params-rsz2rgb[rsz_id];
+ ext_mem = params-ext_mem_param[rsz_id];
+
+ if (rsz_id == RSZ_A) {
+ val = rsc_params-h_flip RSZA_H_FLIP_SHIFT;
+ val |= rsc_params-v_flip RSZA_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_A;
+ } else {
+ val = rsc_params-h_flip RSZB_H_FLIP_SHIFT;
+ val |= rsc_params-v_flip RSZB_V_FLIP_SHIFT;
+ reg_base = RSZ_EN_B;
+ }
+ /* update flip settings */
+ regw_rsz(val, RSZ_SEQ);
+
+ regw_rsz(rsc_params-mode, reg_base + RSZ_MODE);
+ val = (rsc_params-cen RSZ_CEN_SHIFT) | rsc_params-yen;
+ regw_rsz(val, reg_base + RSZ_420);
+ regw_rsz(rsc_params-i_vps RSZ_VPS_MASK, reg_base + RSZ_I_VPS);
+
[PATCH v2 8/8] davinci: vpfe: build infrastructure for dm365
add build infrastructure for dm365 specific modules such as IPIPE, AEW, AF. Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Nagabhushana Netagunte nagabhushana.netagu...@ti.com --- drivers/media/video/davinci/Kconfig | 46 - drivers/media/video/davinci/Makefile | 17 +++- 2 files changed, 59 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..6f6da53 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -11,6 +11,48 @@ config DISPLAY_DAVINCI_DM646X_EVM To compile this driver as a module, choose M here: the module will be called vpif_display. +config VIDEO_DM365_3A_HW + tristate DM365 Auto Focus, Auto Exposure/ White Balance HW module + depends on ARCH_DAVINCI_DM365 + help + DM365 Auto Focus, Auto Exposure and Auto White Balancing HW module + + This module has functions which configure AEW/AF hardware, high level + AF module and AEW module use these functionalities. It collects metrics + about the image or video data + +config VIDEO_DM365_AF + tristate DM365 Auto Focus Driver + depends on ARCH_DAVINCI_DM365 + select VIDEO_DM365_3A_HW + help + DM365 Auto Focus hardware module. + + Auto Focus driver is used to support control loop for Auto Focus. + It collects metrics about the image or video data. This provides + hooks to AF subdevice driver. + +config VIDEO_DM365_AEW + tristate DM365 Auto exposure /White Balance Driver + depends on ARCH_DAVINCI_DM365 + select VIDEO_DM365_3A_HW + help + DM365 Auto Exposure and Auto White Balance hardware module. + + This is used to support the control loops for Auto Exposure + and Auto White Balance. It collects metrics about the image + or video data + +config DM365_IPIPE + depends on ARCH_DAVINCI ARCH_DAVINCI_DM365 + tristate DM365 IPIPE + help + dm365 IPIPE hardware module. + + This is the hardware module that implements imp_hw_interface + for DM365. This hardware module provides previewer and resizer + functionality for image processing. + config CAPTURE_DAVINCI_DM646X_EVM tristate DM646x EVM Video Capture depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM @@ -51,7 +93,7 @@ config VIDEO_VPFE_CAPTURE config VIDEO_DM6446_CCDC tristate DM6446 CCDC HW module - depends on VIDEO_VPFE_CAPTURE + depends on VIDEO_VPFE_CAPTURE ARCH_DAVINCI_DM644x select VIDEO_VPSS_SYSTEM default y help @@ -80,7 +122,7 @@ config VIDEO_DM355_CCDC module will be called vpfe. config VIDEO_ISIF - tristate ISIF HW module + tristate DM365 ISIF HW module depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE select VIDEO_VPSS_SYSTEM default y diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..8544040 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -12,7 +12,20 @@ obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o # Capture: DM6446 and DM355 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o -obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o +obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o vpfe_ccdc.o \ + vpfe_resizer.o vpfe_previewer.o \ + vpfe_aew.o vpfe_af.o vpfe_video.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o -obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_ISIF) += dm365_ccdc.o + +dm365_a3_hw_driver-objs := dm365_a3_hw.o +obj-$(CONFIG_VIDEO_DM365_3A_HW) += dm365_a3_hw_driver.o +dm365_af_driver-objs := dm365_af.o +obj-$(CONFIG_VIDEO_DM365_AF)+= dm365_af_driver.o +dm365_aew_driver-objs := dm365_aew.o +obj-$(CONFIG_VIDEO_DM365_AEW) += dm365_aew_driver.o + +dm365_imp-objs := dm365_ipipe.o dm365_def_para.o \ +dm365_ipipe_hw.o dm3xx_ipipeif.o +obj-$(CONFIG_DM365_IPIPE) += dm365_imp.o -- 1.6.2.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
[PATCH v2 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
add support for dm3xx IPIPEIF hardware setup. This is the
lowest software layer for the dm3x vpfe driver which directly
accesses hardware. Add support for features like default
pixel correction, dark frame substraction and hardware setup.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/dm3xx_ipipeif.c | 317 +++
drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++
include/linux/dm3xx_ipipeif.h | 64 ++
3 files changed, 639 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c
create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h
create mode 100644 include/linux/dm3xx_ipipeif.h
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
b/drivers/media/video/davinci/dm3xx_ipipeif.c
new file mode 100644
index 000..ebc8895
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
@@ -0,0 +1,317 @@
+/*
+* Copyright (C) 2011 Texas Instruments Inc
+*
+* This program is free software; you can redistribute it and/or
+* modify it under the terms of the GNU General Public License as
+* published by the Free Software Foundation version 2.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+*
+* ipipe module to hold common functionality across DM355 and DM365
+*/
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/io.h
+#include linux/v4l2-mediabus.h
+#include media/davinci/vpfe.h
+#include dm3xx_ipipeif.h
+
+static void *__iomem ipipeif_base_addr;
+
+static inline u32 regr_if(u32 offset)
+{
+ return readl(ipipeif_base_addr + offset);
+}
+
+static inline void regw_if(u32 val, u32 offset)
+{
+ writel(val, ipipeif_base_addr + offset);
+}
+
+void ipipeif_set_enable(char en, unsigned int mode)
+{
+ regw_if(1, IPIPEIF_ENABLE);
+}
+
+u32 ipipeif_get_enable(void)
+{
+ return regr_if(IPIPEIF_ENABLE);
+}
+
+int ipipeif_set_address(struct ipipeif *params, unsigned int address)
+{
+ u32 val;
+
+ if (params-source == 0)
+ return -EINVAL;
+
+ val = (params-adofs 5) IPIPEIF_ADOFS_LSB_MASK;
+ regw_if(val, IPIPEIF_ADOFS);
+
+ /* lower sixteen bit */
+ val = (address IPIPEIF_ADDRL_SHIFT) IPIPEIF_ADDRL_MASK;
+ regw_if(val, IPIPEIF_ADDRL);
+
+ /* upper next seven bit */
+ val = (address IPIPEIF_ADDRU_SHIFT) IPIPEIF_ADDRU_MASK;
+ regw_if(val, IPIPEIF_ADDRU);
+
+ return 0;
+}
+
+static void ipipeif_config_dpc(struct ipipeif_dpc *dpc)
+{
+ u32 val;
+
+ /* Intialize val*/
+ val = 0;
+
+ if (dpc-en) {
+ val = (dpc-en 1) IPIPEIF_DPC2_EN_SHIFT;
+ val |= dpc-thr IPIPEIF_DPC2_THR_MASK;
+ }
+
+ regw_if(val, IPIPEIF_DPC2);
+}
+
+#define RD_DATA_15_2 0x7
+/* This function sets up IPIPEIF and is called from
+ * ipipe_hw_setup()
+ */
+int ipipeif_hw_setup(struct ipipeif *params, int device_type)
+{
+ enum v4l2_mbus_pixelcode isif_port_if;
+ unsigned int val;
+
+ if (params == NULL)
+ return -EINVAL;
+
+ /* Enable clock to IPIPEIF and IPIPE */
+ if (device_type == DM365)
+ vpss_enable_clock(VPSS_IPIPEIF_CLOCK, 1);
+
+ /* Combine all the fields to make CFG1 register of IPIPEIF */
+ val = params-mode ONESHOT_SHIFT;
+ val |= params-source INPSRC_SHIFT;
+ val |= params-clock_select CLKSEL_SHIFT;
+ val |= params-avg_filter AVGFILT_SHIFT;
+ val |= params-decimation DECIM_SHIFT;
+
+ if (device_type == DM355) {
+ val |= params-var.if_base.ialaw IALAW_SHIFT;
+ val |= params-var.if_base.pack_mode PACK8IN_SHIFT;
+ val |= params-var.if_base.clk_div CLKDIV_SHIFT;
+ val |= params-var.if_base.data_shift DATASFT_SHIFT;
+ } else {
+ /* DM365 IPIPE 5.1 */
+ val |= params-var.if_5_1.pack_mode PACK8IN_SHIFT;
+ val |= params-var.if_5_1.source1 INPSRC1_SHIFT;
+ if (params-source != IPIPEIF_SDRAM_YUV)
+ val |= params-var.if_5_1.data_shift DATASFT_SHIFT;
+ else
+ val = ~(RD_DATA_15_2 DATASFT_SHIFT);
+ }
+ regw_if(val, IPIPEIF_CFG1);
+
+ switch (params-source) {
+ case IPIPEIF_CCDC:
+ regw_if(params-gain, IPIPEIF_GAIN);
+ break;
+ case IPIPEIF_SDRAM_RAW:
+ case
[PATCH v2 6/8] davinci: vpfe: add v4l2 video driver support
add a generic video driver functionality to be used by all the vpfe
drivers for davinci SoCs. The functionality includes all the
standard v4l2 interfaces including streaming.
The video node interface can be used both as an input and output
node for both continuous and single shot modes.Also supports
dv_presets to include HD modes, wth support for both user pointer
IO and mmap.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/vpfe_video.c | 1712 ++
drivers/media/video/davinci/vpfe_video.h | 142 +++
2 files changed, 1854 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpfe_video.c
create mode 100644 drivers/media/video/davinci/vpfe_video.h
diff --git a/drivers/media/video/davinci/vpfe_video.c
b/drivers/media/video/davinci/vpfe_video.c
new file mode 100644
index 000..bb405fb
--- /dev/null
+++ b/drivers/media/video/davinci/vpfe_video.c
@@ -0,0 +1,1712 @@
+/*
+ * Copyright (C) 2011 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Contributors:-
+ * Manjunath Hadli manjunath.ha...@ti.com
+ * Nagabhushana Netagunte nagabhushana.netagu...@ti.com
+ */
+
+#include linux/platform_device.h
+#include linux/slab.h
+#include media/v4l2-common.h
+#include media/v4l2-mediabus.h
+#include media/media-entity.h
+#include media/media-device.h
+#include vpfe_capture.h
+#include mach/cputype.h
+#include ccdc_hw_device.h
+
+/* number of buffers supported in single-shot mode */
+#define SS_NUM_BUFFERS 1
+/* minimum number of buffers needed in cont-mode */
+#define CONT_MIN_NUM_BUFFERS 3
+
+static int debug;
+
+/* get v4l2 subdev pointer to external subdev which is active */
+static struct v4l2_subdev *vpfe_get_input_sd(struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video-vpfe_dev;
+ struct media_pad *remote;
+
+ remote = media_entity_remote_source(vpfe_dev-vpfe_ccdc.pads[0]);
+ if (remote == NULL) {
+ printk(KERN_ERR invalid media connection to ccdc\n);
+ return NULL;
+ }
+
+ return media_entity_to_v4l2_subdev(remote-entity);
+}
+
+/* updates external subdev(sensor/decoder) which is active */
+static int vpfe_update_current_ext_subdev(struct vpfe_video_device *video)
+{
+ struct vpfe_device *vpfe_dev = video-vpfe_dev;
+ struct vpfe_config *vpfe_cfg;
+ struct v4l2_subdev *subdev;
+ struct media_pad *remote;
+ int i;
+
+ remote = media_entity_remote_source(vpfe_dev-vpfe_ccdc.pads[0]);
+ if (remote == NULL) {
+ printk(KERN_ERR invalid media connection to ccdc\n);
+ return -1;
+ }
+
+ subdev = media_entity_to_v4l2_subdev(remote-entity);
+
+ vpfe_cfg = vpfe_dev-pdev-platform_data;
+
+ for (i = 0; i vpfe_cfg-num_subdevs; i++) {
+ if (!strcmp(vpfe_cfg-sub_devs[i].module_name, subdev-name)) {
+ video-current_ext_subdev = vpfe_cfg-sub_devs[i];
+ break;
+ }
+ }
+
+ /* if user not linked decoder/sensor to ccdc */
+ if (i == vpfe_cfg-num_subdevs) {
+ printk(KERN_ERR invalid media chain connection to ccdc\n);
+ return -1;
+ }
+
+ /* find the v4l2 subdev pointer */
+ for (i = 0; i vpfe_dev-num_ext_subdevs; i++) {
+ if (!strcmp(video-current_ext_subdev-module_name,
+ vpfe_dev-sd[i]-name))
+ video-current_ext_subdev-subdev = vpfe_dev-sd[i];
+ }
+
+ return 0;
+}
+
+/* get the subdev which is connected to the output video node */
+static struct v4l2_subdev *
+vpfe_video_remote_subdev(struct vpfe_video_device *video, u32 *pad)
+{
+ struct media_pad *remote;
+
+ remote = media_entity_remote_source(video-pad);
+
+ if (remote == NULL ||
+ remote-entity-type != MEDIA_ENT_T_V4L2_SUBDEV)
+ return NULL;
+
+ if (pad)
+ *pad = remote-index;
+
+ return media_entity_to_v4l2_subdev(remote-entity);
+}
+
+/* get the format set at ouput pad of the adjacent subdev */
+static int
+__vpfe_video_get_format(struct vpfe_video_device *video,
+ struct v4l2_format *format)
+{
+
Re: Smart card reader support for Anysee DVB devices
2011/8/29 Antti Palosaari cr...@iki.fi: On 08/29/2011 05:44 PM, István Váradi wrote: Hi, 2011/8/17 Antti Palosaaricr...@iki.fi: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, implementing new protocol is totally dead idea. It will never got any support. There is already such drivers, at least Infinity Unlimited USB Phoenix driver (iuu_phoenix.c). It uses USB-serial driver framework and some small emulation for Phoenix protocol. Look that driver to see which kind of complexity it adds. Anysee have *just* same situation. Phoenix/Smartmouse and CCID are quite different aren't they? So to support Phoenix I would need provide a USB serial device which talks the protocol, but there would be no need for a virtual USB HCI. Is that correct? Regards, Istvan regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH 1/8] davinci: vpfe: add dm3xx IPIPEIF hardware support module
Sakari,
I have sent a fresh patch-set with your comments fixed and and some
cleanup and reorg of my own- mainly the headers. Please review.
Also, I had to keep one of your comments without code change as I felt it was
Ok to keep it here as it is only a local variable which actually gets the info
from the device specific data structures. I removed the other however.
Looking forward for your comments on further patches as well.
-Manju
On Thu, Jul 14, 2011 at 00:20:50, Sakari Ailus wrote:
Hi Manju,
Thanks for the patchset!
I have a few comments on this patch below. I haven't read the rest of the
patches yet so I may have more comments on this one when I do that.
On Thu, Jun 30, 2011 at 06:43:10PM +0530, Manjunath Hadli wrote:
add support for dm3xx IPIPEIF hardware setup. This is the lowest
software layer for the dm3x vpfe driver which directly accesses
hardware. Add support for features like default pixel correction, dark
frame substraction and hardware setup.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Nagabhushana Netagunte nagabhushana.netagu...@ti.com
---
drivers/media/video/davinci/dm3xx_ipipeif.c | 368
+++
include/media/davinci/dm3xx_ipipeif.h | 292 +
2 files changed, 660 insertions(+), 0 deletions(-) create mode
100644 drivers/media/video/davinci/dm3xx_ipipeif.c
create mode 100644 include/media/davinci/dm3xx_ipipeif.h
diff --git a/drivers/media/video/davinci/dm3xx_ipipeif.c
b/drivers/media/video/davinci/dm3xx_ipipeif.c
new file mode 100644
index 000..36cb61b
--- /dev/null
+++ b/drivers/media/video/davinci/dm3xx_ipipeif.c
@@ -0,0 +1,368 @@
---code
+#include linux/kernel.h #include linux/platform_device.h #include
+linux/uaccess.h #include linux/io.h #include
+linux/v4l2-mediabus.h #include media/davinci/dm3xx_ipipeif.h
+
+#define DM355 0
+#define DM365 1
+
+static void *__iomem ipipeif_base_addr;
This looks device specific. What about using dev_set/get_drvdata and remove
this one?
This one is actually gotten from the platform data structure in the manner you
suggested but stored here for local usage.
+static int device_type;
Ditto. Both should be in a device specific struct.
This one I have removed.
+static inline u32 regr_if(u32 offset) {
+ return readl(ipipeif_base_addr + offset); }
+
+static inline void regw_if(u32 val, u32 offset) {
+ writel(val, ipipeif_base_addr + offset); }
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 0/8] RFC for Media Controller capture driver for DM365
Please treat the patches as RFC. Thx, -manju On Mon, Aug 29, 2011 at 20:37:11, Hadli, Manjunath wrote: changes from last patch set: 1. Made changes based on Sakari's feedback mainly: a. returned early to allow unindenting b. reformatting to shift the code to left where possible c. changed hex numbers to lower case d. corrected the defines according to module names. e. magic numbers removed. f. changed non-integer returning functions to void g. removed unwanted paranthses. h. fixed error codes. i. fixed some RESET_BIt code to what it was intended for. 2. reorganized the header files to move the kernel-only headers along with the c files and interface headers in the include folder. Manjunath Hadli (6): davinci: vpfe: add dm3xx IPIPEIF hardware support module davinci: vpfe: add support for CCDC hardware for dm365 davinci: vpfe: add ccdc driver with media controller interface davinci: vpfe: add v4l2 video driver support davinci: vpfe: v4l2 capture driver with media interface davinci: vpfe: build infrastructure for dm365 Nagabhushana Netagunte (2): davinci: vpfe: add IPIPE hardware layer support davinci: vpfe: add IPIPE support for media controller driver drivers/media/video/davinci/Kconfig | 46 +- drivers/media/video/davinci/Makefile | 17 +- drivers/media/video/davinci/ccdc_hw_device.h | 10 +- drivers/media/video/davinci/ccdc_types.h | 43 + drivers/media/video/davinci/dm365_ccdc.c | 1519 ++ drivers/media/video/davinci/dm365_ccdc.h | 88 + drivers/media/video/davinci/dm365_ccdc_regs.h | 309 ++ drivers/media/video/davinci/dm365_def_para.c | 486 +++ drivers/media/video/davinci/dm365_def_para.h | 39 + drivers/media/video/davinci/dm365_ipipe.c | 3966 + drivers/media/video/davinci/dm365_ipipe.h | 300 ++ drivers/media/video/davinci/dm365_ipipe_hw.c | 949 ++ drivers/media/video/davinci/dm365_ipipe_hw.h | 539 drivers/media/video/davinci/dm3xx_ipipeif.c | 317 ++ drivers/media/video/davinci/dm3xx_ipipeif.h | 258 ++ drivers/media/video/davinci/imp_common.h | 85 + drivers/media/video/davinci/imp_hw_if.h | 178 ++ drivers/media/video/davinci/vpfe_capture.c| 793 + drivers/media/video/davinci/vpfe_capture.h| 104 + drivers/media/video/davinci/vpfe_ccdc.c | 813 + drivers/media/video/davinci/vpfe_ccdc.h | 85 + drivers/media/video/davinci/vpfe_video.c | 1712 +++ drivers/media/video/davinci/vpfe_video.h | 142 + include/linux/davinci_vpfe.h | 1223 include/linux/dm365_ccdc.h| 664 + include/linux/dm3xx_ipipeif.h | 64 + include/media/davinci/vpfe.h | 91 + 27 files changed, 14829 insertions(+), 11 deletions(-) create mode 100644 drivers/media/video/davinci/ccdc_types.h create mode 100644 drivers/media/video/davinci/dm365_ccdc.c create mode 100644 drivers/media/video/davinci/dm365_ccdc.h create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h create mode 100644 drivers/media/video/davinci/dm365_def_para.c create mode 100644 drivers/media/video/davinci/dm365_def_para.h create mode 100644 drivers/media/video/davinci/dm365_ipipe.c create mode 100644 drivers/media/video/davinci/dm365_ipipe.h create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.c create mode 100644 drivers/media/video/davinci/dm365_ipipe_hw.h create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.c create mode 100644 drivers/media/video/davinci/dm3xx_ipipeif.h create mode 100644 drivers/media/video/davinci/imp_common.h create mode 100644 drivers/media/video/davinci/imp_hw_if.h create mode 100644 drivers/media/video/davinci/vpfe_capture.c create mode 100644 drivers/media/video/davinci/vpfe_capture.h create mode 100644 drivers/media/video/davinci/vpfe_ccdc.c create mode 100644 drivers/media/video/davinci/vpfe_ccdc.h create mode 100644 drivers/media/video/davinci/vpfe_video.c create mode 100644 drivers/media/video/davinci/vpfe_video.h create mode 100644 include/linux/davinci_vpfe.h create mode 100644 include/linux/dm365_ccdc.h create mode 100644 include/linux/dm3xx_ipipeif.h create mode 100644 include/media/davinci/vpfe.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
Re: [PATCH 1/2] dmaengine: ipu-idmac: add support for the DMA_PAUSE control
On Thu, 2011-08-25 at 18:45 +0200, Guennadi Liakhovetski wrote:
To support multi-size buffers in the mx3_camera V4L2 driver we have to be
able to stop DMA on a channel without releasing descriptors and completely
halting the hardware. Use the DMA_PAUSE control to implement this mode.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by Vinod Koul vinod.k...@linux.intel.com
Do you want this to go thru slave-dma or media tree?
--
~Vinod
---
drivers/dma/ipu/ipu_idmac.c | 65 +++---
1 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index c1a125e..42cdf1c 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1306,6 +1306,7 @@ static irqreturn_t idmac_interrupt(int irq, void
*dev_id)
ipu_submit_buffer(ichan, descnew, sgnew, ichan-active_buffer) 0)
{
callback = descnew-txd.callback;
callback_param = descnew-txd.callback_param;
+ list_del_init(descnew-list);
spin_unlock(ichan-lock);
if (callback)
callback(callback_param);
@@ -1427,39 +1428,58 @@ static int __idmac_control(struct dma_chan *chan,
enum dma_ctrl_cmd cmd,
{
struct idmac_channel *ichan = to_idmac_chan(chan);
struct idmac *idmac = to_idmac(chan-device);
+ struct ipu *ipu = to_ipu(idmac);
+ struct list_head *list, *tmp;
unsigned long flags;
int i;
- /* Only supports DMA_TERMINATE_ALL */
- if (cmd != DMA_TERMINATE_ALL)
- return -ENXIO;
+ switch (cmd) {
+ case DMA_PAUSE:
+ spin_lock_irqsave(ipu-lock, flags);
+ ipu_ic_disable_task(ipu, chan-chan_id);
- ipu_disable_channel(idmac, ichan,
- ichan-status = IPU_CHANNEL_ENABLED);
+ /* Return all descriptors into prepared state */
+ list_for_each_safe(list, tmp, ichan-queue)
+ list_del_init(list);
- tasklet_disable(to_ipu(idmac)-tasklet);
+ ichan-sg[0] = NULL;
+ ichan-sg[1] = NULL;
- /* ichan-queue is modified in ISR, have to spinlock */
- spin_lock_irqsave(ichan-lock, flags);
- list_splice_init(ichan-queue, ichan-free_list);
+ spin_unlock_irqrestore(ipu-lock, flags);
- if (ichan-desc)
- for (i = 0; i ichan-n_tx_desc; i++) {
- struct idmac_tx_desc *desc = ichan-desc + i;
- if (list_empty(desc-list))
- /* Descriptor was prepared, but not submitted */
- list_add(desc-list, ichan-free_list);
+ ichan-status = IPU_CHANNEL_INITIALIZED;
+ break;
+ case DMA_TERMINATE_ALL:
+ ipu_disable_channel(idmac, ichan,
+ ichan-status = IPU_CHANNEL_ENABLED);
- async_tx_clear_ack(desc-txd);
- }
+ tasklet_disable(ipu-tasklet);
- ichan-sg[0] = NULL;
- ichan-sg[1] = NULL;
- spin_unlock_irqrestore(ichan-lock, flags);
+ /* ichan-queue is modified in ISR, have to spinlock */
+ spin_lock_irqsave(ichan-lock, flags);
+ list_splice_init(ichan-queue, ichan-free_list);
- tasklet_enable(to_ipu(idmac)-tasklet);
+ if (ichan-desc)
+ for (i = 0; i ichan-n_tx_desc; i++) {
+ struct idmac_tx_desc *desc = ichan-desc + i;
+ if (list_empty(desc-list))
+ /* Descriptor was prepared, but not
submitted */
+ list_add(desc-list,
ichan-free_list);
- ichan-status = IPU_CHANNEL_INITIALIZED;
+ async_tx_clear_ack(desc-txd);
+ }
+
+ ichan-sg[0] = NULL;
+ ichan-sg[1] = NULL;
+ spin_unlock_irqrestore(ichan-lock, flags);
+
+ tasklet_enable(ipu-tasklet);
+
+ ichan-status = IPU_CHANNEL_INITIALIZED;
+ break;
+ default:
+ return -ENOSYS;
+ }
return 0;
}
@@ -1662,7 +1682,6 @@ static void __exit ipu_idmac_exit(struct ipu *ipu)
struct idmac_channel *ichan = ipu-channel + i;
idmac_control(ichan-dma_chan, DMA_TERMINATE_ALL, 0);
- idmac_prep_slave_sg(ichan-dma_chan, NULL, 0, DMA_NONE, 0);
}
dma_async_device_unregister(idmac-dma);
--
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: Smart card reader support for Anysee DVB devices
On 08/29/2011 06:13 PM, István Váradi wrote: 2011/8/29 Antti Palosaaricr...@iki.fi: On 08/29/2011 05:44 PM, István Váradi wrote: 2011/8/17 Antti Palosaaricr...@iki.fi: On 08/15/2011 02:14 PM, Antti Palosaari wrote: On 08/15/2011 02:51 AM, Antti Palosaari wrote: Biggest problem I see whole thing is poor application support. OpenCT is rather legacy but there is no good alternative. All this kind of serial drivers seems to be OpenCT currently. I wonder if it is possible to make virtual CCID device since CCID seems to be unfortunately the only interface SmartCard guys currently care. I studied scenario and looks like it is possible to implement way like, register virtual USB HCI (virtual motherboard USB controller) then register virtual PC/SC device to that which hooks all calls to HW via Anysee driver. Some glue surely needed for emulate PC/SC. I think there is not any such driver yet. Anyhow, there is virtual USB HCI driver currently in staging which can be used as example, or even use it to register virtual device. That kind of functionality surely needs more talking... It maybe that smartcard guys care only for CCID, but wouldn't it be an overkill to implement an emulation of that for the driver? It can be done, of course, but I think it would be much more complicated than the current one. Is it really necessary to put such complexity into the kernel? In my opinion, this should be handled in user-space. Only De facto serial smartcard protocol is so called Phoenix/Smartmouse, implementing new protocol is totally dead idea. It will never got any support. There is already such drivers, at least Infinity Unlimited USB Phoenix driver (iuu_phoenix.c). It uses USB-serial driver framework and some small emulation for Phoenix protocol. Look that driver to see which kind of complexity it adds. Anysee have *just* same situation. Phoenix/Smartmouse and CCID are quite different aren't they? So to support Phoenix I would need provide a USB serial device which talks the protocol, but there would be no need for a virtual USB HCI. Is that correct? Yes, CCID and serial are different interfaces. CCID is new interface specified by USB organization that needs hardware level interface profile like mass storage profile. Serial is block device interface (/dev/tty). Since Anysee device itself does not have CCID interface it is needed to make virtual USB device in order to get CCID support. I have never seen virtual USB devices like that, but there is VHCI in current kernel staging that actually does something like that over IP. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi,
On 08/29/2011 02:32 PM, Laurent Pinchart wrote:
Hi Geert,
On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy
way,
Definitely.
- But what with modes that can be represented? Legacy software
cannot handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
with a non-FOURCC format, the driver will report non-FOURCC types
and visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool (fbset on
steroids).
Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Yep.
Later the user runs a legacy application.
= Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We
have no per-open fixed and variable screen info, and FB devices can
be opened by multiple applications at the same time.
- Is there an easy way to force FOURCC reporting, so new apps don't
have to support parsing the legacy formats? This is useful for new
apps that want to support (a subset of) FOURCC modes only.
Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
Do you mean new ioctls to replace the FOURCC API proposal, or new ioctls
for the above two operations ?
New ioctls to replace the FOURCC proposal.
*sigh*...
I'd like other people's opinion on this before throwing everything away.
Florian, Magnus, Guennadi, others, what do you think ?
So, your issue is that some formats can be represented in the new and the old
way?
There are 2 simpler solutions I can think of:
(1) ignore it, just do it the way Laurent proposed. I understand that someone
might feel uneasy about applications that are trapped because they don't know
the new format but could work with the old one. But I think this is not a big
issue as many applications will just try to set their own mode. For those that
doesn't and rely on the previous mode that is set by fbset or similar, we could
change fbset to prefer the old format if available. But even if we don't do
this, I don't have a problem with a program failing because it sees an
unsuitable mode even if it supports the legacy mode. It's not a regression and
can be easily fixed in userspace.
(2) forbid it, just allow drivers to implement FOURCC for formats that cannot be
represented in the old scheme. This is my preferred solution if anyone has
problems with (1).
I don't see how IOCTLs would help here. The pixel format just belongs into var
and fix so it has to be represented there anyway and thus set through it. We
could do an IOCTL that always returns the FOURCC active at the moment, if such a
FOURCC exists, and always use the legacy API for representing it in var/fix, if
it exists. But as I see this is not what you thought about so please explain
what your IOCTLS would look like and how they would solve the problem.
And I don't think a in-kernel translation layer is a good idea. Yes, it sounds
interesting, but it's tricky and the result will be that the driver and
userspace will permanently see different var and fix structures. Seriously I
think changing every framebuffer driver out there would be easier and much saner
than trying to implement such a thing.
Best regards,
Florian Tobias Schandinat
--
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: [git:v4l-dvb/for_v3.2] [media] Fix wrong register mask in gspca/sonixj.c
Mauro: To be fair, this patch itself isn't sufficient to solve the problem described in the text provided. One other patch is necessary to get this goal accomplished, named, one published in this same thread in 2011-07-18. This later fix is now embedded in a wider patch provided by Jean-François Moine in 2011-08-10. I'd suggest to change the text below, if possible, mentioning only something like fix wrong register masking. Thanks, Luiz --- Em dom, 7/8/11, Mauro Carvalho Chehab mche...@redhat.com escreveu: De: Mauro Carvalho Chehab mche...@redhat.com Assunto: [git:v4l-dvb/for_v3.2] [media] Fix wrong register mask in gspca/sonixj.c Para: linuxtv-comm...@linuxtv.org Cc: Jean-François Moine moin...@free.fr, Luiz Carlos Ramos lramos.p...@yahoo.com.br Data: Domingo, 7 de Agosto de 2011, 9:03 This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] Fix wrong register mask in gspca/sonixj.c Author: Luiz Ramos luizzra...@yahoo.com.br Date: Thu Jul 14 23:08:39 2011 -0300 Hello, When migrating from Slackware 13.1 to 13.37 (kernel 2.6.33.x to 2.6.37.6), there was some sort of regression with the external webcam installed at the notebook (0x45:6128, SN9C325+OM6802). In the version 2.6.37.6, the images got *very* dark, making the webcam almost unusable, unless if used with direct sunlight. Tracing back what happened, I concluded that changeset 0e4d413af caused some sort of odd effects - including this - to this specific model. Signed-off-by: Luiz Carlos Ramos lramos.p...@yahoo.com.br Acked-by: Jean-François Moine moin...@free.fr Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com drivers/media/video/gspca/sonixj.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=d1520c58eb84ad1ec973a257cd835c948215aab5 diff --git a/drivers/media/video/gspca/sonixj.c b/drivers/media/video/gspca/sonixj.c index 81b8a60..2ad757d 100644 --- a/drivers/media/video/gspca/sonixj.c +++ b/drivers/media/video/gspca/sonixj.c @@ -2386,7 +2386,7 @@ static int sd_start(struct gspca_dev *gspca_dev) reg_w1(gspca_dev, 0x01, 0x22); msleep(100); reg01 = SCL_SEL_OD | S_PDN_INV; - reg17 = MCK_SIZE_MASK; + reg17 = ~MCK_SIZE_MASK; reg17 |= 0x04; /* clock / 4 */ break; } -- 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
Kconfig unmet dependency with RADIO_WL1273
Hi Matti, Johannes has just reported a problem in the Kconfig of radio-wl1273. It seems to select MFD_CORE, but if the platform doesn't support MFD, then MFD_SUPPORT won't be selected and this kind of warning will come out: warning: (OLPC_XO1_PM OLPC_XO1_SCI I2C_ISCH GPIO_SCH GPIO_RDC321X RADIO_WL1273) selects MFD_CORE which has unmet direct dependencies (MFD_SUPPORT) I guess it must depend on MFD_SUPPORT, right? If that's the correct solution, the following patch should fix the problem: diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 52798a1..e87f544 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -425,7 +425,7 @@ config RADIO_TIMBERDALE config RADIO_WL1273 tristate Texas Instruments WL1273 I2C FM Radio - depends on I2C VIDEO_V4L2 + depends on I2C VIDEO_V4L2 MFD_SUPPORT select MFD_CORE select MFD_WL1273_CORE select FW_LOADER The same problem is happening with other drivers too, so maybe there is a better solution to fix all problems at once. ;) Reported-by: Johannes Berg johan...@sipsolutions.net -- Cheers, Luca. -- 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: DD Cine CT DVB-C/T
On 08/25/2011 06:47 PM, Thomas Kaiser wrote:
Hi
Which modules do I have to build and install to use this card (DD Cine
CT DVB-C/T Rev. V6).
I checkd out:
hg clone http://linuxtv.org/hg/~endriss/media_build_experimental
I would like to build only the needed modules. What do I have to
select in make menuconfig?
Regards, Thomas
--
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
Looks like I took the wrong source...
static const struct pci_device_id ddb_id_tbl[] __devinitdata = {
DDB_ID(DDVID, 0x0002, DDVID, 0x0001, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0001, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0002, ddb_octopus_le),
DDB_ID(DDVID, 0x0003, DDVID, 0x0010, ddb_octopus),
DDB_ID(DDVID, 0x0003, DDVID, 0x0020, ddb_v6),
/* in case sub-ids got deleted in flash */
DDB_ID(DDVID, 0x0003, PCI_ANY_ID, PCI_ANY_ID, ddb_none),
{0}
};
My card has the _subdev 0x0030!
Where can I find the right source code for this card?
I am ready to help developing and testing.
Thomas
--
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: Kconfig unmet dependency with RADIO_WL1273
On Mon, 29 Aug 2011 20:02:38 +0300 Luciano Coelho wrote: Hi Matti, Johannes has just reported a problem in the Kconfig of radio-wl1273. It seems to select MFD_CORE, but if the platform doesn't support MFD, then MFD_SUPPORT won't be selected and this kind of warning will come out: warning: (OLPC_XO1_PM OLPC_XO1_SCI I2C_ISCH GPIO_SCH GPIO_RDC321X RADIO_WL1273) selects MFD_CORE which has unmet direct dependencies (MFD_SUPPORT) I guess it must depend on MFD_SUPPORT, right? If that's the correct solution, the following patch should fix the problem: diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 52798a1..e87f544 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -425,7 +425,7 @@ config RADIO_TIMBERDALE config RADIO_WL1273 tristate Texas Instruments WL1273 I2C FM Radio - depends on I2C VIDEO_V4L2 + depends on I2C VIDEO_V4L2 MFD_SUPPORT select MFD_CORE select MFD_WL1273_CORE select FW_LOADER The same problem is happening with other drivers too, so maybe there is a better solution to fix all problems at once. ;) Reported-by: Johannes Berg johan...@sipsolutions.net Yes, it can depend on MFD_SUPPORT or it can select both MFD_SUPPORT and MFD_CORE or we could do what Jean Delvare suggested last December and combine the MFD_SUPPORT and MFD_CORE symbols, like I2c does. I did a patch for that but never posted it. It's below, but probably needs a good bit of updating since this patch was made in January. --- From: Randy Dunlap rdun...@xenotime.net Combine MFD_SUPPORT (which only enabled the remainder of the MFD menu) and MFD_CORE. This allows other drivers to select MFD_CORE without needing to also select MFD_SUPPORT, which fixes some kconfig unmet dependency warnings. Modeled after I2C kconfig. Signed-off-by: Randy Dunlap rdun...@xenotime.net --- drivers/mfd/Kconfig | 42 -- 1 file changed, 4 insertions(+), 38 deletions(-) --- lnx-2637-rc5.orig/drivers/mfd/Kconfig +++ lnx-2637-rc5/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool Multifunction device drivers +menuconfig MFD_CORE + tristate Multifunction device drivers depends on HAS_IOMEM - default y help Multifunction devices embed several functions (e.g. GPIOs, touchscreens, keyboards, current regulators, power management chips, @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT This option alone does not add any kernel code. -if MFD_SUPPORT - -config MFD_CORE - tristate - default n +if MFD_CORE config MFD_88PM860X bool Support Marvell 88PM8606/88PM8607 depends on I2C=y GENERIC_HARDIRQS - select MFD_CORE help This supports for Marvell 88PM8606/88PM8607 Power Management IC. This includes the I2C driver and the core APIs _only_, you have to @@ -55,7 +49,6 @@ config MFD_SM501_GPIO config MFD_ASIC3 bool Support for Compaq ASIC3 depends on GENERIC_HARDIRQS GPIOLIB ARM - select MFD_CORE ---help--- This driver supports the ASIC3 multifunction chip found on many PDAs (mainly iPAQ and HTC based ones) @@ -63,7 +56,6 @@ config MFD_ASIC3 config MFD_SH_MOBILE_SDHI bool Support for SuperH Mobile SDHI depends on SUPERH || ARCH_SHMOBILE - select MFD_CORE select TMIO_MMC_DMA ---help--- This driver supports the SDHI hardware block found in many @@ -71,7 +63,6 @@ config MFD_SH_MOBILE_SDHI config MFD_DAVINCI_VOICECODEC tristate - select MFD_CORE config MFD_DM355EVM_MSP bool DaVinci DM355 EVM microcontroller @@ -91,7 +82,6 @@ config HTC_EGPIO config HTC_PASIC3 tristate HTC PASIC3 LED/DS1WM chip support - select MFD_CORE help This core driver provides register access for the LED/DS1WM chips labeled AIC2 and AIC3, found on HTC Blueangel and @@ -133,7 +123,6 @@ config TPS65010 config TPS6507X tristate TPS6507x Power Management / Touch Screen chips - select MFD_CORE depends on I2C help If you say yes here you get support for the TPS6507x series of @@ -183,7 +172,6 @@ config TWL4030_POWER config TWL4030_CODEC bool depends on TWL4030_CORE - select MFD_CORE default n config TWL6030_PWM @@ -198,7 +186,6 @@ config TWL6030_PWM config MFD_STMPE bool Support STMicroelectronics STMPE depends on I2C=y GENERIC_HARDIRQS - select MFD_CORE help Support for the STMPE family of I/O Expanders from STMicroelectronics. @@ -221,7 +208,6 @@ config MFD_STMPE config MFD_TC35892 bool Support Toshiba TC35892 depends on I2C=y GENERIC_HARDIRQS - select MFD_CORE help Support
[PATCH/WIP] tvp5150: add v4l2 subdev pad ops
Hi,
attached is a patch (i tested it with kernel 3.1rc3 but applies to
2.6.39 and 3.0 too) that makes the driver register with omap3-isp.
Copied mostly from mt9v032.c.
/dev/video* and v4l-subdev* are registered correctly.
Video capture is still NOT working but i think i'm close to make it
work so some help is welcome!
I'm testing it on an IGEP board with tvp5151 on expansion board.
Issues i see:
root@igep0020:~# ./media-ctl2 --set-format 'tvp5150 2-005c:0 [UYVY 720x628]'
Setting up format UYVY 720x628 on pad tvp5150 2-005c/0
Format set: UYVY 720x628
Setting up format UYVY 720x628 on pad OMAP3 ISP CCDC/0
Format set: SGRBG10 720x628
and
root@igep0020:~# gst-launch -ve v4l2src device=/dev/video2
queue-size=1 num-buffers=250 ! fakesink
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
getting controls attributes on device '/dev/video2'.
Additional debug info:
v4l2_calls.c(267): gst_v4l2_fill_lists ():
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Failed querying control 9963776 on device '/dev/video2'. (25 -
Inappropriate ioctl for device)
Setting pipeline to NULL ...
Freeing pipeline ...
Maybe the gstreamer issue could be caused by not being compiled with
the proper kernel headers.
media-ctl is compiled from latest ideasonboard git repo, i admit i am
not that sure that i compiled it with correct kernel headers. I don't
know why but every format i try to set on CCDC is always set to
SGRBG10.
I'm not sure that some parameters are correct (like V4L2_FILED_NONE,
colorspace, pixel format...), so i need someone to take a look. Are
the subdev_internal_ops (registered, open, close) needed?
I know the patch is not properly formatted for submission, i'll do
that when capture will work.
Thanks,
Enrico
diff --git a/drivers/media/video/tvp5150.c b/drivers/media/video/tvp5150.c
index e927d25..bf34e11 100644
--- a/drivers/media/video/tvp5150.c
+++ b/drivers/media/video/tvp5150.c
@@ -2,6 +2,7 @@
* tvp5150 - Texas Instruments TVP5150A/AM1 video decoder driver
*
* Copyright (c) 2005,2006 Mauro Carvalho Chehab (mche...@infradead.org)
+ * Copyright (c) 2011 Enrico Butera (ebut...@users.berlios.de)
* This code is placed under the terms of the GNU General Public License v2
*/
@@ -13,9 +14,30 @@
#include media/tvp5150.h
#include media/v4l2-chip-ident.h
#include media/v4l2-ctrls.h
+#include media/v4l2-mediabus.h
+#include media/v4l2-subdev.h
#include tvp5150_reg.h
+#define TVP5150_PIXEL_ARRAY_HEIGHT 628
+#define TVP5150_PIXEL_ARRAY_WIDTH 720
+
+#define TVP5150_WINDOW_WIDTH_MIN 1
+#define TVP5150_WINDOW_WIDTH_DEF 720
+#define TVP5150_WINDOW_WIDTH_MAX 720
+
+#define TVP5150_WINDOW_HEIGHT_MIN 1
+#define TVP5150_WINDOW_HEIGHT_DEF 628
+#define TVP5150_WINDOW_HEIGHT_MAX 628
+
+#define TVP5150_COLUMN_START_MIN 0
+#define TVP5150_COLUMN_START_DEF 0
+#define TVP5150_COLUMN_START_MAX 720
+
+#define TVP5150_ROW_START_MIN 0
+#define TVP5150_ROW_START_DEF 0
+#define TVP5150_ROW_START_MAX 628
+
MODULE_DESCRIPTION(Texas Instruments TVP5150A video decoder driver);
MODULE_AUTHOR(Mauro Carvalho Chehab);
MODULE_LICENSE(GPL);
@@ -28,6 +50,9 @@ MODULE_PARM_DESC(debug, Debug level (0-2));
struct tvp5150 {
struct v4l2_subdev sd;
struct v4l2_ctrl_handler hdl;
+ struct media_pad pad;
+ struct v4l2_mbus_framefmt format;
+ struct v4l2_rect crop;
v4l2_std_id norm; /* Current set standard */
u32 input;
@@ -779,6 +804,203 @@ static int tvp5150_s_ctrl(struct v4l2_ctrl *ctrl)
}
/
+ V4L2 subdev pad ops
+ /
+
+static struct v4l2_mbus_framefmt *
+__tvp5150_get_pad_format(struct tvp5150 *tvp5150, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+switch (which) {
+case V4L2_SUBDEV_FORMAT_TRY:
+return v4l2_subdev_get_try_format(fh, pad);
+case V4L2_SUBDEV_FORMAT_ACTIVE:
+return tvp5150-format;
+default:
+return NULL;
+}
+}
+
+static struct v4l2_rect *
+__tvp5150_get_pad_crop(struct tvp5150 *tvp5150, struct v4l2_subdev_fh *fh,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+switch (which) {
+case V4L2_SUBDEV_FORMAT_TRY:
+return v4l2_subdev_get_try_crop(fh, pad);
+case V4L2_SUBDEV_FORMAT_ACTIVE:
+return tvp5150-crop;
+default:
+return NULL;
+}
+}
+
+static int tvp5150_enum_mbus_code(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+if (code-index 0)
+return -EINVAL;
+
+code-code = V4L2_MBUS_FMT_UYVY8_1X16;
+return 0;
+}
+
+static int
Re: [PATCH 1/2] dmaengine: ipu-idmac: add support for the DMA_PAUSE control
On Mon, 29 Aug 2011, Vinod Koul wrote:
On Thu, 2011-08-25 at 18:45 +0200, Guennadi Liakhovetski wrote:
To support multi-size buffers in the mx3_camera V4L2 driver we have to be
able to stop DMA on a channel without releasing descriptors and completely
halting the hardware. Use the DMA_PAUSE control to implement this mode.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Acked-by Vinod Koul vinod.k...@linux.intel.com
Do you want this to go thru slave-dma or media tree?
With your above ack I can pull it together with the final form of patch
2/2, when it's ready, via media tree.
Thanks
Guennadi
--
~Vinod
---
drivers/dma/ipu/ipu_idmac.c | 65
+++---
1 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index c1a125e..42cdf1c 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1306,6 +1306,7 @@ static irqreturn_t idmac_interrupt(int irq, void
*dev_id)
ipu_submit_buffer(ichan, descnew, sgnew, ichan-active_buffer) 0)
{
callback = descnew-txd.callback;
callback_param = descnew-txd.callback_param;
+ list_del_init(descnew-list);
spin_unlock(ichan-lock);
if (callback)
callback(callback_param);
@@ -1427,39 +1428,58 @@ static int __idmac_control(struct dma_chan *chan,
enum dma_ctrl_cmd cmd,
{
struct idmac_channel *ichan = to_idmac_chan(chan);
struct idmac *idmac = to_idmac(chan-device);
+ struct ipu *ipu = to_ipu(idmac);
+ struct list_head *list, *tmp;
unsigned long flags;
int i;
- /* Only supports DMA_TERMINATE_ALL */
- if (cmd != DMA_TERMINATE_ALL)
- return -ENXIO;
+ switch (cmd) {
+ case DMA_PAUSE:
+ spin_lock_irqsave(ipu-lock, flags);
+ ipu_ic_disable_task(ipu, chan-chan_id);
- ipu_disable_channel(idmac, ichan,
- ichan-status = IPU_CHANNEL_ENABLED);
+ /* Return all descriptors into prepared state */
+ list_for_each_safe(list, tmp, ichan-queue)
+ list_del_init(list);
- tasklet_disable(to_ipu(idmac)-tasklet);
+ ichan-sg[0] = NULL;
+ ichan-sg[1] = NULL;
- /* ichan-queue is modified in ISR, have to spinlock */
- spin_lock_irqsave(ichan-lock, flags);
- list_splice_init(ichan-queue, ichan-free_list);
+ spin_unlock_irqrestore(ipu-lock, flags);
- if (ichan-desc)
- for (i = 0; i ichan-n_tx_desc; i++) {
- struct idmac_tx_desc *desc = ichan-desc + i;
- if (list_empty(desc-list))
- /* Descriptor was prepared, but not submitted */
- list_add(desc-list, ichan-free_list);
+ ichan-status = IPU_CHANNEL_INITIALIZED;
+ break;
+ case DMA_TERMINATE_ALL:
+ ipu_disable_channel(idmac, ichan,
+ ichan-status = IPU_CHANNEL_ENABLED);
- async_tx_clear_ack(desc-txd);
- }
+ tasklet_disable(ipu-tasklet);
- ichan-sg[0] = NULL;
- ichan-sg[1] = NULL;
- spin_unlock_irqrestore(ichan-lock, flags);
+ /* ichan-queue is modified in ISR, have to spinlock */
+ spin_lock_irqsave(ichan-lock, flags);
+ list_splice_init(ichan-queue, ichan-free_list);
- tasklet_enable(to_ipu(idmac)-tasklet);
+ if (ichan-desc)
+ for (i = 0; i ichan-n_tx_desc; i++) {
+ struct idmac_tx_desc *desc = ichan-desc + i;
+ if (list_empty(desc-list))
+ /* Descriptor was prepared, but not
submitted */
+ list_add(desc-list,
ichan-free_list);
- ichan-status = IPU_CHANNEL_INITIALIZED;
+ async_tx_clear_ack(desc-txd);
+ }
+
+ ichan-sg[0] = NULL;
+ ichan-sg[1] = NULL;
+ spin_unlock_irqrestore(ichan-lock, flags);
+
+ tasklet_enable(ipu-tasklet);
+
+ ichan-status = IPU_CHANNEL_INITIALIZED;
+ break;
+ default:
+ return -ENOSYS;
+ }
return 0;
}
@@ -1662,7 +1682,6 @@ static void __exit ipu_idmac_exit(struct ipu *ipu)
struct idmac_channel *ichan = ipu-channel + i;
idmac_control(ichan-dma_chan, DMA_TERMINATE_ALL, 0);
- idmac_prep_slave_sg(ichan-dma_chan, NULL, 0, DMA_NONE, 0);
}
dma_async_device_unregister(idmac-dma);
---
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
Re: [git:v4l-dvb/for_v3.2] [media] Fix wrong register mask in gspca/sonixj.c
On Mon, 29 Aug 2011 09:57:26 -0700 (PDT) Luiz Ramos lramos.p...@yahoo.com.br wrote: Mauro: To be fair, this patch itself isn't sufficient to solve the problem described in the text provided. One other patch is necessary to get this goal accomplished, named, one published in this same thread in 2011-07-18. This later fix is now embedded in a wider patch provided by Jean-François Moine in 2011-08-10. I'd suggest to change the text below, if possible, mentioning only something like fix wrong register masking. Hi Mauro, Sorry, I did not notice the automatic commit report. I submitted Luiz's patch and the darkness fix in 2 git patch requests on Wed, 10 Aug for 3.1 and on Fri, 12 Aug for 3.2: gspca - sonixj: Fix wrong register mask for sensor om6802 gspca - sonixj: Fix the darkness of sensor om6802 in 320x240 Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
Beloved
Beloved,I am Deborah Mannings.I write this email to you on my sick bed facing death.I have a substantial sum I would like you to help me distribute to the needy and helpless.God bless you as you reply through mann_...@yahoo.cn -- 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: usb_set_intfdata usage for two subdrivers
Am Montag, 29. August 2011, 05:54:36 schrieb Antti Palosaari: On 08/29/2011 03:36 AM, Greg KH wrote: On Mon, Aug 29, 2011 at 02:30:26AM +0300, Antti Palosaari wrote: I am trying to implement DVB USB device smartcard reader support using USB-serial. Really? Why? That doesn't seem to make sense, please explain more. Since it is old style serial smartcard reader, not CCID PC/SC as new readers. I see it a little bit overkill to register virtual HCI and virtual CCID device though it sounds interesting. There is already one such similar driver, iuu_phoenix, but without DVB support ;) Consider situation I have iuu_phoenix integrated to USB DVB device. Both using same USB enpoint, sharing hardware resources of communication. Look at struct dvb_usb_device. It has a struct input_dev embedded. I suggest you also add a serial device for smart cards. HTH Oliver -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013
2011/8/23 Jason Hecker jwhec...@gmail.com: Damn, this patch didn't help so maybe forget this patch. Tuner A is still messed up. Hello, thanks all to reply this post. I have no idea how to apply the patch on my Debian Squeeze. Can you help to apply the patch? Thanks your all your help. Best regards. -- Josu Lazkano -- 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] mfd: Combine MFD_SUPPORT and MFD_CORE
From: Randy Dunlap rdun...@xenotime.net Combine MFD_SUPPORT (which only enabled the remainder of the MFD menu) and MFD_CORE. This allows other drivers to select MFD_CORE without needing to also select MFD_SUPPORT, which fixes some kconfig unmet dependency warnings. Modeled after I2C kconfig. [Forward-ported to 3.1-rc4. This fixes a warning when some drivers, such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca] Signed-off-by: Randy Dunlap rdun...@xenotime.net Reported-by: Johannes Berg johan...@sipsolutions.net Cc: Jean Delvare kh...@linux-fr.org Cc: Tony Lindgren t...@atomide.com Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Luciano Coelho coe...@ti.com --- I guess this should fix the problem. I've simple forward-ported Randy's patch to the latest mainline kernel. I don't know via which tree this should go in, though. NOTE: I have *not* tested this very thoroughly. But at least omap2plus stuff seems to work okay with this change. MFD_SUPPORT is also selected by a couple of tile platforms defconfigs, but I guess the Kconfig system should take care of it. arch/arm/mach-omap2/Kconfig |2 +- drivers/gpio/Kconfig|3 +- drivers/mfd/Kconfig | 54 +++--- 3 files changed, 6 insertions(+), 53 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 57b66d5..1046923 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -14,7 +14,7 @@ config ARCH_OMAP2PLUS_TYPICAL select SERIAL_OMAP_CONSOLE select I2C select I2C_OMAP - select MFD_SUPPORT + select MFD_CORE select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index d539efd..fbc5fd4 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -180,7 +180,7 @@ config GPIO_SCH config GPIO_VX855 tristate VIA VX855/VX875 GPIO - depends on MFD_SUPPORT PCI + depends on PCI select MFD_CORE select MFD_VX855 help @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE config GPIO_RDC321X tristate RDC R-321x GPIO support depends on PCI - select MFD_SUPPORT select MFD_CORE select MFD_RDC321X help diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..1836cdf 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool Multifunction device drivers +menuconfig MFD_CORE + tristate Multifunction device drivers depends on HAS_IOMEM - default y help Multifunction devices embed several functions (e.g. GPIOs, touchscreens, keyboards, current regulators, power management chips, @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT This option alone does not add any kernel code. -if MFD_SUPPORT - -config MFD_CORE - tristate - default n +if MFD_CORE config MFD_88PM860X bool Support Marvell 88PM8606/88PM8607 depends on I2C=y GENERIC_HARDIRQS - select MFD_CORE help This supports for Marvell 88PM8606/88PM8607 Power Management IC. This includes the I2C driver and the core APIs _only_, you have to @@ -55,14 +49,12 @@ config MFD_SM501_GPIO config MFD_ASIC3 bool Support for Compaq ASIC3 depends on GENERIC_HARDIRQS GPIOLIB ARM - select MFD_CORE ---help--- This driver supports the ASIC3 multifunction chip found on many PDAs (mainly iPAQ and HTC based ones) config MFD_DAVINCI_VOICECODEC tristate - select MFD_CORE config MFD_DM355EVM_MSP bool DaVinci DM355 EVM microcontroller @@ -75,7 +67,6 @@ config MFD_DM355EVM_MSP config MFD_TI_SSP tristate TI Sequencer Serial Port support depends on ARCH_DAVINCI_TNETV107X - select MFD_CORE ---help--- Say Y here if you want support for the Sequencer Serial Port in a Texas Instruments TNETV107X SoC. @@ -93,7 +84,6 @@ config HTC_EGPIO config HTC_PASIC3 tristate HTC PASIC3 LED/DS1WM chip support - select MFD_CORE help This core driver provides register access for the LED/DS1WM chips labeled AIC2 and AIC3, found on HTC Blueangel and @@ -124,7 +114,6 @@ config TPS6105X tristate TPS61050/61052 Boost Converters depends on I2C select REGULATOR - select MFD_CORE select REGULATOR_FIXED_VOLTAGE help This option enables a driver for the TP61050/TPS61052 @@ -147,7 +136,6 @@ config TPS65010 config TPS6507X tristate TPS6507x Power Management / Touch Screen chips - select MFD_CORE depends on I2C help If you say yes here you get support for the TPS6507x
Re: [PATCH] mfd: Combine MFD_SUPPORT and MFD_CORE
On Mon, Aug 29, 2011 at 12:41 PM, Luciano Coelho coe...@ti.com wrote: From: Randy Dunlap rdun...@xenotime.net Combine MFD_SUPPORT (which only enabled the remainder of the MFD menu) and MFD_CORE. This allows other drivers to select MFD_CORE without needing to also select MFD_SUPPORT, which fixes some kconfig unmet dependency warnings. Modeled after I2C kconfig. [Forward-ported to 3.1-rc4. This fixes a warning when some drivers, such as RADIO_WL1273, are selected, but MFD_SUPPORT is not. -- Luca] Signed-off-by: Randy Dunlap rdun...@xenotime.net Reported-by: Johannes Berg johan...@sipsolutions.net Cc: Jean Delvare kh...@linux-fr.org Cc: Tony Lindgren t...@atomide.com Cc: Grant Likely grant.lik...@secretlab.ca Signed-off-by: Luciano Coelho coe...@ti.com okay by me. g. --- I guess this should fix the problem. I've simple forward-ported Randy's patch to the latest mainline kernel. I don't know via which tree this should go in, though. NOTE: I have *not* tested this very thoroughly. But at least omap2plus stuff seems to work okay with this change. MFD_SUPPORT is also selected by a couple of tile platforms defconfigs, but I guess the Kconfig system should take care of it. arch/arm/mach-omap2/Kconfig | 2 +- drivers/gpio/Kconfig | 3 +- drivers/mfd/Kconfig | 54 +++--- 3 files changed, 6 insertions(+), 53 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 57b66d5..1046923 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -14,7 +14,7 @@ config ARCH_OMAP2PLUS_TYPICAL select SERIAL_OMAP_CONSOLE select I2C select I2C_OMAP - select MFD_SUPPORT + select MFD_CORE select MENELAUS if ARCH_OMAP2 select TWL4030_CORE if ARCH_OMAP3 || ARCH_OMAP4 select TWL4030_POWER if ARCH_OMAP3 || ARCH_OMAP4 diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index d539efd..fbc5fd4 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -180,7 +180,7 @@ config GPIO_SCH config GPIO_VX855 tristate VIA VX855/VX875 GPIO - depends on MFD_SUPPORT PCI + depends on PCI select MFD_CORE select MFD_VX855 help @@ -417,7 +417,6 @@ config GPIO_TIMBERDALE config GPIO_RDC321X tristate RDC R-321x GPIO support depends on PCI - select MFD_SUPPORT select MFD_CORE select MFD_RDC321X help diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 21574bd..1836cdf 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -2,10 +2,9 @@ # Multifunction miscellaneous devices # -menuconfig MFD_SUPPORT - bool Multifunction device drivers +menuconfig MFD_CORE + tristate Multifunction device drivers depends on HAS_IOMEM - default y help Multifunction devices embed several functions (e.g. GPIOs, touchscreens, keyboards, current regulators, power management chips, @@ -18,16 +17,11 @@ menuconfig MFD_SUPPORT This option alone does not add any kernel code. -if MFD_SUPPORT - -config MFD_CORE - tristate - default n +if MFD_CORE config MFD_88PM860X bool Support Marvell 88PM8606/88PM8607 depends on I2C=y GENERIC_HARDIRQS - select MFD_CORE help This supports for Marvell 88PM8606/88PM8607 Power Management IC. This includes the I2C driver and the core APIs _only_, you have to @@ -55,14 +49,12 @@ config MFD_SM501_GPIO config MFD_ASIC3 bool Support for Compaq ASIC3 depends on GENERIC_HARDIRQS GPIOLIB ARM - select MFD_CORE ---help--- This driver supports the ASIC3 multifunction chip found on many PDAs (mainly iPAQ and HTC based ones) config MFD_DAVINCI_VOICECODEC tristate - select MFD_CORE config MFD_DM355EVM_MSP bool DaVinci DM355 EVM microcontroller @@ -75,7 +67,6 @@ config MFD_DM355EVM_MSP config MFD_TI_SSP tristate TI Sequencer Serial Port support depends on ARCH_DAVINCI_TNETV107X - select MFD_CORE ---help--- Say Y here if you want support for the Sequencer Serial Port in a Texas Instruments TNETV107X SoC. @@ -93,7 +84,6 @@ config HTC_EGPIO config HTC_PASIC3 tristate HTC PASIC3 LED/DS1WM chip support - select MFD_CORE help This core driver provides register access for the LED/DS1WM chips labeled AIC2 and AIC3, found on HTC Blueangel and @@ -124,7 +114,6 @@ config TPS6105X tristate TPS61050/61052 Boost Converters depends on I2C select REGULATOR - select MFD_CORE select REGULATOR_FIXED_VOLTAGE help This option enables a driver for the TP61050/TPS61052 @@ -147,7 +136,6 @@ config TPS65010 config TPS6507X tristate TPS6507x Power
[V4L2]decrement struct v4l2_device refcount on device urnegister
commit bedf8bcf6b4f90a6e31add3721a2e71877289381 introduced reference counting for struct v4l2_device. In v4l2_device_register() a call to kref_init() initializes reference count to 1, but in v4l2_device_unregister() there is no corresponding decrement. End result is that reference count never reaches zero and v4l2_device_release() is never called, not even on videodev module unload. Fix this by adding reference counter decrement to v4l2_device_unregister(). Signed-off-by: Maciej Szmigiero m...@o2.pl diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index c72856c..eb39af9 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -131,6 +131,8 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev) } #endif } + +v4l2_device_put(v4l2_dev); } EXPORT_SYMBOL_GPL(v4l2_device_unregister); -- 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
BUG: unable to handle kernel paging request at 6b6b6bcb (v4l2_device_disconnect+0x11/0x30)
Hi, I managed to produce an oops in 3.1.0-rc3-00270-g7a54f5e by unplugging a USB webcam. See below: eeepc kernel: [ 1263.874756] cheese[3402]: segfault at 58 ip 080630b6 sp afc2c840 error 4 in cheese[8048000+24000] eeepc kernel: [ 1393.419370] uvcvideo: Non-zero status (-84) in status completion handler. eeepc kernel: [ 1393.500719] usb 3-2: USB disconnect, device number 4 eeepc kernel: [ 1393.504351] uvcvideo: Failed to resubmit video URB (-19). eeepc kernel: [ 1495.428853] BUG: unable to handle kernel paging request at 6b6b6bcb eeepc kernel: [ 1495.429017] IP: [b0358d37] dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] *pde = eeepc kernel: [ 1495.429017] Oops: [#1] DEBUG_PAGEALLOC eeepc kernel: [ 1495.429017] eeepc kernel: [ 1495.429017] Pid: 3476, comm: cheese Not tainted 3.1.0-rc3-00270-g7a54f5e-dirty #485 ASUSTeK Computer INC. 900/900 eeepc kernel: [ 1495.429017] EIP: 0060:[b0358d37] EFLAGS: 00010202 CPU: 0 eeepc kernel: [ 1495.429017] EIP is at dev_get_drvdata+0x17/0x20 eeepc kernel: [ 1495.429017] EAX: 6b6b6b6b EBX: eb08d870 ECX: EDX: eb08d930 eeepc kernel: [ 1495.429017] ESI: eb08d870 EDI: eb08d870 EBP: d3249cac ESP: d3249cac eeepc kernel: [ 1495.429017] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068 eeepc kernel: [ 1495.429017] Process cheese (pid: 3476, ti=d3248000 task=df46d870 task.ti=d3248000) eeepc kernel: [ 1495.429017] Stack: eeepc kernel: [ 1495.429017] d3249cb8 b03e77a1 d307b840 d3249ccc b03e77d1 d307b840 eb08d870 eb08d830 eeepc kernel: [ 1495.429017] d3249ce4 b03ed3b7 0246 d307b840 eb08d870 d3021b80 d3249cec b03ed565 eeepc kernel: [ 1495.429017] d3249cfc b03e044d e8323d10 b06e013c d3249d18 b0355fb9 fffe d3249d1c eeepc kernel: [ 1495.429017] Call Trace: eeepc kernel: [ 1495.429017] [b03e77a1] v4l2_device_disconnect+0x11/0x30 eeepc kernel: [ 1495.429017] [b03e77d1] v4l2_device_unregister+0x11/0x50 eeepc kernel: [ 1495.429017] [b03ed3b7] uvc_delete+0x37/0x110 eeepc kernel: [ 1495.429017] [b03ed565] uvc_release+0x25/0x30 eeepc kernel: [ 1495.429017] [b03e044d] v4l2_device_release+0x9d/0xc0 eeepc kernel: [ 1495.429017] [b0355fb9] device_release+0x19/0x90 eeepc kernel: [ 1495.429017] [b03adfdc] ? usb_hcd_unlink_urb+0x7c/0x90 eeepc kernel: [ 1495.429017] [b026b99c] kobject_release+0x3c/0x90 eeepc kernel: [ 1495.429017] [b026b960] ? kobject_del+0x30/0x30 eeepc kernel: [ 1495.429017] [b026ca4c] kref_put+0x2c/0x60 eeepc kernel: [ 1495.429017] [b026b88d] kobject_put+0x1d/0x50 eeepc kernel: [ 1495.429017] [b03b2385] ? usb_autopm_put_interface+0x25/0x30 eeepc kernel: [ 1495.429017] [b03f0e5d] ? uvc_v4l2_release+0x5d/0xd0 eeepc kernel: [ 1495.429017] [b0355d2f] put_device+0xf/0x20 eeepc kernel: [ 1495.429017] [b03dfa96] v4l2_release+0x56/0x60 eeepc kernel: [ 1495.429017] [b019c8dc] fput+0xcc/0x220 eeepc kernel: [ 1495.429017] [b01990f4] filp_close+0x44/0x70 eeepc kernel: [ 1495.429017] [b012b238] put_files_struct+0x158/0x180 eeepc kernel: [ 1495.429017] [b012b100] ? put_files_struct+0x20/0x180 eeepc kernel: [ 1495.429017] [b012b2a0] exit_files+0x40/0x50 eeepc kernel: [ 1495.429017] [b012b9e7] do_exit+0x5a7/0x660 eeepc kernel: [ 1495.429017] [b0135f72] ? __dequeue_signal+0x12/0x120 eeepc kernel: [ 1495.429017] [b055edf2] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [b012badc] do_group_exit+0x3c/0xb0 eeepc kernel: [ 1495.429017] [b015792b] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [b013755f] get_signal_to_deliver+0x18f/0x570 eeepc kernel: [ 1495.429017] [b01020f7] do_signal+0x47/0x9e0 eeepc kernel: [ 1495.429017] [b055edf2] ? _raw_spin_unlock_irq+0x22/0x30 eeepc kernel: [ 1495.429017] [b015792b] ? trace_hardirqs_on+0xb/0x10 eeepc kernel: [ 1495.429017] [b0123300] ? T.1034+0x30/0xc0 eeepc kernel: [ 1495.429017] [b055c45f] ? schedule+0x29f/0x640 eeepc kernel: [ 1495.429017] [b0102ac8] do_notify_resume+0x38/0x40 eeepc kernel: [ 1495.429017] [b055f154] work_notifysig+0x9/0x11 eeepc kernel: [ 1495.429017] Code: e5 5d 83 f8 01 19 c0 f7 d0 83 e0 f0 c3 8d b4 26 00 00 00 00 55 85 c0 89 e5 75 09 31 c0 5d c3 90 8d 74 26 00 8b 40 04 85 c0 74 f0 8b 40 60 5d c3 8d 74 26 00 55 89 e5 53 89 c3 83 ec 04 8b 40 04 eeepc kernel: [ 1495.429017] EIP: [b0358d37] dev_get_drvdata+0x17/0x20 SS:ESP 0068:d3249cac eeepc kernel: [ 1495.429017] CR2: 6b6b6bcb eeepc kernel: [ 1495.466975] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: [ 1495.467860] uvcvideo: Failed to resubmit video URB (-27). eeepc kernel: last message repeated 3 times eeepc kernel: [ 1495.512610] ---[ end trace 73ec16848794e5a5 ]--- eeepc kernel: [ 1495.512620] Fixing recursive fault but reboot is needed! -- Sitsofe | http://sucs.org/~sits/ -- 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
[V4L2]decrement struct v4l2_device refcount on device unregister
commit bedf8bcf6b4f90a6e31add3721a2e71877289381 introduced reference counting for struct v4l2_device. In v4l2_device_register() a call to kref_init() initializes reference count to 1, but in v4l2_device_unregister() there is no corresponding decrement. End result is that reference count never reaches zero and v4l2_device_release() is never called, not even on videodev module unload. Fix this by adding reference counter decrement to v4l2_device_unregister(). Resending due to spurious newlines around the patch in previous message. Signed-off-by: Maciej Szmigiero m...@o2.pl diff --git a/drivers/media/video/v4l2-device.c b/drivers/media/video/v4l2-device.c index c72856c..eb39af9 100644 --- a/drivers/media/video/v4l2-device.c +++ b/drivers/media/video/v4l2-device.c @@ -131,6 +131,8 @@ void v4l2_device_unregister(struct v4l2_device *v4l2_dev) } #endif } + + v4l2_device_put(v4l2_dev); } EXPORT_SYMBOL_GPL(v4l2_device_unregister); -- 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: vb2: dma contig allocator: use dma_addr instread of paddr
On Mon, 29 Aug 2011, Marek Szyprowski wrote:
Use the correct 'dma_addr' name for the buffer address. 'paddr' suggested
that this is the physical address in system memory. For most ARM platforms
these two are the same, but this is not a generic rule. 'dma_addr' will
also point better to dma-mapping api.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Pawel Osciak pa...@osciak.com
For atmel-isi.c, mx3_camera.c, sh_mobile_ceu_camera.c:
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Thanks
Guennadi
---
drivers/media/video/atmel-isi.c |2 +-
drivers/media/video/marvell-ccic/mcam-core.c |4 +-
drivers/media/video/mx3_camera.c |2 +-
drivers/media/video/s5p-fimc/fimc-core.c |6 ++--
drivers/media/video/s5p-mfc/s5p_mfc.c|4 +-
drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 10
drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 30
+-
drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 14 ++--
drivers/media/video/s5p-tv/mixer_grp_layer.c |2 +-
drivers/media/video/s5p-tv/mixer_vp_layer.c |4 +-
drivers/media/video/sh_mobile_ceu_camera.c |2 +-
drivers/media/video/videobuf2-dma-contig.c | 16 +++---
include/media/videobuf2-dma-contig.h |6 ++--
13 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
index 5a4b2d7..7e1d789 100644
--- a/drivers/media/video/atmel-isi.c
+++ b/drivers/media/video/atmel-isi.c
@@ -341,7 +341,7 @@ static int buffer_prepare(struct vb2_buffer *vb)
/* Initialize the dma descriptor */
desc-p_fbd-fb_address =
- vb2_dma_contig_plane_paddr(vb, 0);
+ vb2_dma_contig_plane_dma_addr(vb, 0);
desc-p_fbd-next_fbd_address = 0;
set_dma_ctrl(desc-p_fbd, ISI_DMA_CTRL_WB);
diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
b/drivers/media/video/marvell-ccic/mcam-core.c
index 744cf37..7abe503 100644
--- a/drivers/media/video/marvell-ccic/mcam-core.c
+++ b/drivers/media/video/marvell-ccic/mcam-core.c
@@ -450,7 +450,7 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, int frame)
buf = cam-vb_bufs[frame ^ 0x1];
cam-vb_bufs[frame] = buf;
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_paddr(buf-vb_buf, 0));
+ vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
set_bit(CF_SINGLE_BUFFER, cam-flags);
singles++;
return;
@@ -461,7 +461,7 @@ static void mcam_set_contig_buffer(struct mcam_camera
*cam, int frame)
buf = list_first_entry(cam-buffers, struct mcam_vb_buffer, queue);
list_del_init(buf-queue);
mcam_reg_write(cam, frame == 0 ? REG_Y0BAR : REG_Y1BAR,
- vb2_dma_contig_plane_paddr(buf-vb_buf, 0));
+ vb2_dma_contig_plane_dma_addr(buf-vb_buf, 0));
cam-vb_bufs[frame] = buf;
clear_bit(CF_SINGLE_BUFFER, cam-flags);
}
diff --git a/drivers/media/video/mx3_camera.c
b/drivers/media/video/mx3_camera.c
index 9ae7785..c8e958a 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -247,7 +247,7 @@ static int mx3_videobuf_prepare(struct vb2_buffer *vb)
}
if (buf-state == CSI_BUF_NEEDS_INIT) {
- sg_dma_address(sg) = vb2_dma_contig_plane_paddr(vb, 0);
+ sg_dma_address(sg) = vb2_dma_contig_plane_dma_addr(vb, 0);
sg_dma_len(sg) = new_size;
buf-txd = ichan-dma_chan.device-device_prep_slave_sg(
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 8152756..266d6b9 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -457,7 +457,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
dbg(memplanes= %d, colplanes= %d, pix_size= %d,
frame-fmt-memplanes, frame-fmt-colplanes, pix_size);
- paddr-y = vb2_dma_contig_plane_paddr(vb, 0);
+ paddr-y = vb2_dma_contig_plane_dma_addr(vb, 0);
if (frame-fmt-memplanes == 1) {
switch (frame-fmt-colplanes) {
@@ -485,10 +485,10 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
} else {
if (frame-fmt-memplanes = 2)
- paddr-cb = vb2_dma_contig_plane_paddr(vb, 1);
+ paddr-cb = vb2_dma_contig_plane_dma_addr(vb, 1);
if (frame-fmt-memplanes == 3)
- paddr-cr = vb2_dma_contig_plane_paddr(vb,
Re: [ANN] Meeting minutes of the Cambourne meeting
On Mon, 29 Aug 2011, Laurent Pinchart wrote: [snip] My idea was to let the kernel register all devices based on the DT or board code. When the V4L2 host/bridge driver gets registered, it will then call a V4L2 core function with a list of subdevs it needs. The V4L2 core would store that information and react to bus notifier events to notify the V4L2 host/bridge driver when all subdevs are present. At that point the host/bridge driver will get hold of all the subdevs and call (probably through the V4L2 core) their .registered operation. That's where the subdevs will get access to their clock using clk_get(). Correct me, if I'm wrong, but this seems to be the case of sensor (and other i2c-client) drivers having to succeed their probe() methods without being able to actually access 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: [ANN] Meeting minutes of the Cambourne meeting
Hi Guennadi, On Tuesday 30 August 2011 00:20:09 Guennadi Liakhovetski wrote: On Mon, 29 Aug 2011, Laurent Pinchart wrote: [snip] My idea was to let the kernel register all devices based on the DT or board code. When the V4L2 host/bridge driver gets registered, it will then call a V4L2 core function with a list of subdevs it needs. The V4L2 core would store that information and react to bus notifier events to notify the V4L2 host/bridge driver when all subdevs are present. At that point the host/bridge driver will get hold of all the subdevs and call (probably through the V4L2 core) their .registered operation. That's where the subdevs will get access to their clock using clk_get(). Correct me, if I'm wrong, but this seems to be the case of sensor (and other i2c-client) drivers having to succeed their probe() methods without being able to actually access the hardware? That's right. I'd love to find a better way :-) Note that this is already the case for many subdev drivers that probe the hardware in the .registered() operation instead of the probe() method. -- 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: [ANN] Meeting minutes of the Cambourne meeting
On Tue, 30 Aug 2011, Laurent Pinchart wrote: Hi Guennadi, On Tuesday 30 August 2011 00:20:09 Guennadi Liakhovetski wrote: On Mon, 29 Aug 2011, Laurent Pinchart wrote: [snip] My idea was to let the kernel register all devices based on the DT or board code. When the V4L2 host/bridge driver gets registered, it will then call a V4L2 core function with a list of subdevs it needs. The V4L2 core would store that information and react to bus notifier events to notify the V4L2 host/bridge driver when all subdevs are present. At that point the host/bridge driver will get hold of all the subdevs and call (probably through the V4L2 core) their .registered operation. That's where the subdevs will get access to their clock using clk_get(). Correct me, if I'm wrong, but this seems to be the case of sensor (and other i2c-client) drivers having to succeed their probe() methods without being able to actually access the hardware? That's right. I'd love to find a better way :-) Note that this is already the case for many subdev drivers that probe the hardware in the .registered() operation instead of the probe() method. Then why do you think it is better, than adding devices from bridge drivers? Think about hotpluggable devices - drivers create devices all the time - USB etc. Why cannot we do the same? As a historic reference: soc-camera used to do this too before - probe without hardware access and really-probe after the host turns on the clock. Then we switched to registering devices later. I like the present approach better. 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/RFC v2 1/3] fbdev: Add FOURCC-based format configuration API
Hi Florian,
On Monday 29 August 2011 18:41:03 Florian Tobias Schandinat wrote:
On 08/29/2011 02:32 PM, Laurent Pinchart wrote:
On Monday 29 August 2011 16:26:02 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 16:17, Laurent Pinchart wrote:
On Monday 29 August 2011 16:14:38 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 15:34, Laurent Pinchart wrote:
On Monday 29 August 2011 15:09:04 Geert Uytterhoeven wrote:
On Mon, Aug 29, 2011 at 14:55, Laurent Pinchart wrote:
When will the driver report FB_{TYPE,VISUAL}_FOURCC?
- When using a mode that cannot be represented in the legacy
way,
Definitely.
- But what with modes that can be represented? Legacy software
cannot handle FB_{TYPE,VISUAL}_FOURCC.
My idea was to use FB_{TYPE,VISUAL}_FOURCC only when the mode is
configured using the FOURCC API. If FBIOPUT_VSCREENINFO is called
with a non-FOURCC format, the driver will report non-FOURCC types
and visuals.
Hmm, two use cases:
- The video mode is configured using a FOURCC-aware tool (fbset
on
steroids).
Such as http://git.ideasonboard.org/?p=fbdev-test.git;a=summary :-)
Yep.
Later the user runs a legacy application.
= Do not retain FOURCC across opening of /dev/fb*.
I know about that problem, but it's not that easy to work around. We
have no per-open fixed and variable screen info, and FB devices can
be opened by multiple applications at the same time.
- Is there an easy way to force FOURCC reporting, so new apps
don't
have to support parsing the legacy formats? This is useful for new
apps that want to support (a subset of) FOURCC modes only.
Not at the moment.
So perhaps we do need new ioctls instead...
That would also ease an in-kernel translation layer.
Do you mean new ioctls to replace the FOURCC API proposal, or new
ioctls for the above two operations ?
New ioctls to replace the FOURCC proposal.
*sigh*...
I'd like other people's opinion on this before throwing everything away.
Florian, Magnus, Guennadi, others, what do you think ?
So, your issue is that some formats can be represented in the new and the
old way? There are 2 simpler solutions I can think of:
(1) ignore it, just do it the way Laurent proposed. I understand that
someone might feel uneasy about applications that are trapped because they
don't know the new format but could work with the old one. But I think
this is not a big issue as many applications will just try to set their
own mode. For those that doesn't and rely on the previous mode that is set
by fbset or similar, we could change fbset to prefer the old format if
available. But even if we don't do this, I don't have a problem with a
program failing because it sees an unsuitable mode even if it supports the
legacy mode. It's not a regression and can be easily fixed in userspace.
I agree with you here. Issues should be fixed in userspace. I don't expect
many issues in practice, as fbdev is often used on systems where userspace
components are developed to work with each other (such as embedded systems).
If such a system is upgraded to use YUV support, all components will likely be
tested and upgraded.
(2) forbid it, just allow drivers to implement FOURCC for formats that
cannot be represented in the old scheme. This is my preferred solution if
anyone has problems with (1).
I'm tempted by that solution. Not that I have an issue with (1), but I'm
wondering if we should try to use the FOURCC API for all formats, or just for
formats that can't be represented by the current API. We currently have no
bitplane FOURCCs, and I'm not sure if it would be worth adding them.
BTW, do recent hardware still support planar (in the bitplane sense) frame
buffers ? If so, is that used in practice on recent devices ? If the answer is
no, (1) might be the best solution, with bit-planar formats supported by the
current API only, and all other formats supported by the FOURCC API.
I don't see how IOCTLs would help here. The pixel format just belongs into
var and fix so it has to be represented there anyway and thus set through
it. We could do an IOCTL that always returns the FOURCC active at the
moment, if such a FOURCC exists, and always use the legacy API for
representing it in var/fix, if it exists. But as I see this is not what
you thought about so please explain what your IOCTLS would look like and
how they would solve the problem.
And I don't think a in-kernel translation layer is a good idea. Yes, it
sounds interesting, but it's tricky and the result will be that the driver
and userspace will permanently see different var and fix structures.
Seriously I think changing every framebuffer driver out there would be
easier and much saner than trying to implement such a thing.
I agree.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the
RE: videobuf2 user pointer vma release seqeuence
Hello, On Tuesday, August 30, 2011 3:50 AM Tang, Yu wrote: As we are trying to adapt to videobuf2, we found here is the potential issue with user pointer VMA release sequence. It is not aligned with munmap syscalls behavior, (mm/mmap, remove_vma). In the current vb2_put_vma implementation, it will release the file first, then release VMA. If the file handle is closed, and vma is munmap by user space, then the file ref count could reach 0 and be freed before the VMA vm_ops-vm_close is called while vm_close is typically assume the file is valid when it's called. If it's agreed as valid concern, I will submit the fix as below soon. Thanks! You are definitely right! Thanks for pointing this bug! I will add your patch to my videobuf2 fixes branch. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
