Re: [PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver
Hi Archit!
On 03/03/2014 08:33 AM, Archit Taneja wrote:
> Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE,
> or
> the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
>
> For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
> whole image itself, hence making crop dimensions same as the pix dimensions.
>
> Setting the crop successfully should result in re-configuration of those
> registers which are affected when either source or destination dimensions
> change, set_srcdst_params() is called for this purpose.
>
> Some standard crop parameter checks are done in __vpe_try_crop().
Please use the selection ops instead: if you implement cropping with those then
you'll
support both the selection API and the old cropping API will be implemented by
the v4l2
core using the selection ops. Two for the price of one...
Regards,
Hans
>
> Signed-off-by: Archit Taneja
> ---
> drivers/media/platform/ti-vpe/vpe.c | 96
> +
> 1 file changed, 96 insertions(+)
>
> diff --git a/drivers/media/platform/ti-vpe/vpe.c
> b/drivers/media/platform/ti-vpe/vpe.c
> index 6acdcd8..c6778f4 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -1585,6 +1585,98 @@ static int vpe_s_fmt(struct file *file, void *priv,
> struct v4l2_format *f)
> return set_srcdst_params(ctx);
> }
>
> +static int __vpe_try_crop(struct vpe_ctx *ctx, struct v4l2_crop *cr)
> +{
> + struct vpe_q_data *q_data;
> +
> + q_data = get_q_data(ctx, cr->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + /* we don't support crop on capture plane */
> + if (cr->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + cr->c.top = cr->c.left = 0;
> + cr->c.width = q_data->width;
> + cr->c.height = q_data->height;
> + return 0;
> + }
> +
> + if (cr->c.top < 0 || cr->c.left < 0) {
> + vpe_err(ctx->dev, "negative values for top and left\n");
> + cr->c.top = cr->c.left = 0;
> + }
> +
> + v4l_bound_align_image(&cr->c.width, MIN_W, q_data->width, 1,
> + &cr->c.height, MIN_H, q_data->height, H_ALIGN, S_ALIGN);
> +
> + /* adjust left/top if cropping rectangle is out of bounds */
> + if (cr->c.left + cr->c.width > q_data->width)
> + cr->c.left = q_data->width - cr->c.width;
> + if (cr->c.top + cr->c.height > q_data->height)
> + cr->c.top = q_data->height - cr->c.height;
> +
> + return 0;
> +}
> +
> +static int vpe_cropcap(struct file *file, void *priv, struct v4l2_cropcap
> *cr)
> +{
> + struct vpe_ctx *ctx = file2ctx(file);
> + struct vpe_q_data *q_data;
> +
> + q_data = get_q_data(ctx, cr->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + cr->bounds.left = 0;
> + cr->bounds.top = 0;
> + cr->bounds.width = q_data->width;
> + cr->bounds.height = q_data->height;
> + cr->defrect = cr->bounds;
> +
> + return 0;
> +}
> +
> +static int vpe_g_crop(struct file *file, void *fh, struct v4l2_crop *cr)
> +{
> + struct vpe_ctx *ctx = file2ctx(file);
> + struct vpe_q_data *q_data;
> +
> + q_data = get_q_data(ctx, cr->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + cr->c = q_data->c_rect;
> +
> + return 0;
> +}
> +
> +static int vpe_s_crop(struct file *file, void *priv,
> + const struct v4l2_crop *crop)
> +{
> + struct vpe_ctx *ctx = file2ctx(file);
> + struct vpe_q_data *q_data;
> + struct v4l2_crop cr = *crop;
> + int ret;
> +
> + ret = __vpe_try_crop(ctx, &cr);
> + if (ret)
> + return ret;
> +
> + q_data = get_q_data(ctx, cr.type);
> +
> + if ((q_data->c_rect.left == cr.c.left) &&
> + (q_data->c_rect.top == cr.c.top) &&
> + (q_data->c_rect.width == cr.c.width) &&
> + (q_data->c_rect.height == cr.c.height)) {
> + vpe_dbg(ctx->dev, "requested crop values are already set\n");
> + return 0;
> + }
> +
> + q_data->c_rect = cr.c;
> +
> + return set_srcdst_params(ctx);
> +}
> +
> static int vpe_reqbufs(struct file *file, void *priv,
> struct v4l2_requestbuffers *reqbufs)
> {
> @@ -1672,6 +1764,10 @@ static const struct v4l2_ioctl_ops vpe_ioctl_ops = {
> .vidioc_try_fmt_vid_out_mplane = vpe_try_fmt,
> .vidioc_s_fmt_vid_out_mplane= vpe_s_fmt,
>
> + .vidioc_cropcap = vpe_cropcap,
> + .vidioc_g_crop = vpe_g_crop,
> + .vidioc_s_crop = vpe_s_crop,
> +
> .vidioc_reqbufs = vpe_reqbufs,
> .vidioc_querybuf= vpe_querybuf,
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.h
[PATCH 2/7] v4l: ti-vpe: register video device only when firmware is loaded
vpe fops(vpe_open in particular) should be called only when VPDMA firmware
is loaded. File operations on the video device are possible the moment it is
registered.
Currently, we register the video device for VPE at driver probe, after calling
a vpdma helper to initialize VPDMA and load firmware. This function is
non-blocking(it calls request_firmware_nowait()), and doesn't ensure that the
firmware is actually loaded when it returns.
We remove the device registration from vpe probe, and move it to a callback
provided by the vpe driver to the vpdma library, through vpdma_create().
The ready field in vpdma_data is no longer needed since we always have firmware
loaded before the device is registered.
A minor problem with this approach is that if the video_register_device
fails(which doesn't really happen), the vpe platform device would be registered.
however, there won't be any v4l2 device corresponding to it.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/vpdma.c | 8 +++--
drivers/media/platform/ti-vpe/vpdma.h | 7 +++--
drivers/media/platform/ti-vpe/vpe.c | 55 ---
3 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index e8175e7..73dd38e 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -781,7 +781,7 @@ static void vpdma_firmware_cb(const struct firmware *f,
void *context)
/* already initialized */
if (read_field_reg(vpdma, VPDMA_LIST_ATTR, VPDMA_LIST_RDY_MASK,
VPDMA_LIST_RDY_SHFT)) {
- vpdma->ready = true;
+ vpdma->cb(vpdma->pdev);
return;
}
@@ -811,7 +811,7 @@ static void vpdma_firmware_cb(const struct firmware *f,
void *context)
goto free_buf;
}
- vpdma->ready = true;
+ vpdma->cb(vpdma->pdev);
free_buf:
vpdma_unmap_desc_buf(vpdma, &fw_dma_buf);
@@ -839,7 +839,8 @@ static int vpdma_load_firmware(struct vpdma_data *vpdma)
return 0;
}
-struct vpdma_data *vpdma_create(struct platform_device *pdev)
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev))
{
struct resource *res;
struct vpdma_data *vpdma;
@@ -854,6 +855,7 @@ struct vpdma_data *vpdma_create(struct platform_device
*pdev)
}
vpdma->pdev = pdev;
+ vpdma->cb = cb;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vpdma");
if (res == NULL) {
diff --git a/drivers/media/platform/ti-vpe/vpdma.h
b/drivers/media/platform/ti-vpe/vpdma.h
index cf40f11..bf5f8bb 100644
--- a/drivers/media/platform/ti-vpe/vpdma.h
+++ b/drivers/media/platform/ti-vpe/vpdma.h
@@ -35,8 +35,8 @@ struct vpdma_data {
struct platform_device *pdev;
- /* tells whether vpdma firmware is loaded or not */
- bool ready;
+ /* callback to VPE driver when the firmware is loaded */
+ void (*cb)(struct platform_device *pdev);
};
enum vpdma_data_format_type {
@@ -208,6 +208,7 @@ void vpdma_set_frame_start_event(struct vpdma_data *vpdma,
void vpdma_dump_regs(struct vpdma_data *vpdma);
/* initialize vpdma, passed with VPE's platform device pointer */
-struct vpdma_data *vpdma_create(struct platform_device *pdev);
+struct vpdma_data *vpdma_create(struct platform_device *pdev,
+ void (*cb)(struct platform_device *pdev));
#endif
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 623e59e..4243687 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1815,11 +1815,6 @@ static int vpe_open(struct file *file)
vpe_dbg(dev, "vpe_open\n");
- if (!dev->vpdma->ready) {
- vpe_err(dev, "vpdma firmware not loaded\n");
- return -ENODEV;
- }
-
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
@@ -2037,10 +2032,40 @@ static void vpe_runtime_put(struct platform_device
*pdev)
WARN_ON(r < 0 && r != -ENOSYS);
}
+static void vpe_fw_cb(struct platform_device *pdev)
+{
+ struct vpe_dev *dev = platform_get_drvdata(pdev);
+ struct video_device *vfd;
+ int ret;
+
+ vfd = &dev->vfd;
+ *vfd = vpe_videodev;
+ vfd->lock = &dev->dev_mutex;
+ vfd->v4l2_dev = &dev->v4l2_dev;
+
+ ret = video_register_device(vfd, VFL_TYPE_GRABBER, 0);
+ if (ret) {
+ vpe_err(dev, "Failed to register video device\n");
+
+ vpe_set_clock_enable(dev, 0);
+ vpe_runtime_put(pdev);
+ pm_runtime_disable(&pdev->dev);
+ v4l2_m2m_release(dev->m2m_dev);
+ vb2_dma_contig_cleanup_ctx(dev->alloc_ctx);
+ v4l2_device_unregister(&dev->v4l2_dev);
+
+ return;
+ }
+
+
[PATCH 6/7] v4l: ti-vpe: Fix some params in VPE data descriptors
Some parameters of the VPE descriptors were understood incorrectly. They are now
fixed. The fixes are explained as follows:
- When adding an inbound data descriptor to the VPDMA descriptor list, we intend
to use c_rect as the cropped region fetched by VPDMA. Therefore, c_rect->width
shouldn't be used to calculate the line stride, the original image width
should be used for that. We add a 'width' argument which gives the buffer
width in memory.
- frame_width and frame_height describe the complete width and height of the
client to which the channel is connected. If there are multiple channels
fetching data and providing to the same client, the above 2 arguments should
be the width and height of the region covered by all the channels. In the case
where there is only one channel providing pixel data to the client
(like in VPE), frame_width and frame_height should be the cropped width and
cropped height respectively. The calculation of these params is done in the
vpe driver now.
- start_h and start_v is also used in the case of multiple channels to describe
where each channel should start filling pixel data. We don't use this in VPE,
and pass 0s to the vpdma_add_in_dtd() helper.
- Some minor changes are made to the vpdma_add_out_dtd() helper. The c_rect
param is removed since cropping isn't possible for outbound data, and 'width'
is added to calculate the line stride.
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/vpdma.c | 50 ++-
drivers/media/platform/ti-vpe/vpdma.h | 9 ---
drivers/media/platform/ti-vpe/vpe.c | 16 +++
3 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpdma.c
b/drivers/media/platform/ti-vpe/vpdma.c
index 73dd38e..7248f16 100644
--- a/drivers/media/platform/ti-vpe/vpdma.c
+++ b/drivers/media/platform/ti-vpe/vpdma.c
@@ -614,8 +614,15 @@ static void dump_dtd(struct vpdma_dtd *dtd)
/*
* append an outbound data transfer descriptor to the given descriptor list,
* this sets up a 'client to memory' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * flags: VPDMA flags to configure some descriptor fileds
*/
-void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct v4l2_rect *c_rect,
+void vpdma_add_out_dtd(struct vpdma_desc_list *list, int width,
const struct vpdma_data_format *fmt, dma_addr_t dma_addr,
enum vpdma_channel chan, u32 flags)
{
@@ -633,8 +640,7 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list, struct
v4l2_rect *c_rect,
fmt->data_type == DATA_TYPE_C420)
depth = 8;
- stride = ALIGN((depth * c_rect->width) >> 3, VPDMA_STRIDE_ALIGN);
- dma_addr += (c_rect->left * depth) >> 3;
+ stride = ALIGN((depth * width) >> 3, VPDMA_STRIDE_ALIGN);
dtd = list->next;
WARN_ON((void *)(dtd + 1) > (list->buf.addr + list->buf.size));
@@ -664,31 +670,48 @@ void vpdma_add_out_dtd(struct vpdma_desc_list *list,
struct v4l2_rect *c_rect,
/*
* append an inbound data transfer descriptor to the given descriptor list,
* this sets up a 'memory to client' VPDMA transfer for the given VPDMA channel
+ *
+ * @list: vpdma desc list to which we add this decriptor
+ * @width: width of the image in pixels in memory(not the cropped width)
+ * @c_rect: crop params of input image
+ * @fmt: vpdma data format of the buffer
+ * dma_addr: dma address as seen by VPDMA
+ * chan: VPDMA channel
+ * field: top or bottom field info of the input image
+ * flags: VPDMA flags to configure some descriptor fileds
+ * frame_width/height: the complete width/height of the image presented to the
+ * client (this makes sense when multiple channels are
+ * connected to the same client, forming a larger frame)
+ * start_h, start_v: position where the given channel starts providing pixel
+ * data to the client (makes sense when multiple channels
+ * contribute to the client)
*/
-void vpdma_add_in_dtd(struct vpdma_desc_list *list, int frame_width,
- int frame_height, struct v4l2_rect *c_rect,
+void vpdma_add_in_dtd(struct vpdma_desc_list *list, int width,
+ const struct v4l2_rect *c_rect,
const struct vpdma_data_format *fmt, dma_addr_t dma_addr,
- enum vpdma_channel chan, int field, u32 flags)
+ enum vpdma_channel chan, int field, u32 flags, int frame_width,
+ int frame_height, int start_h, int start_v)
{
int priority = 0;
int notify = 1;
int depth = fmt->depth;
int channel, next_chan;
+ struct v4l2_rect rect = *c_rect;
int stride;
- int height = c_
[PATCH 7/7] v4l: ti-vpe: Add crop support in VPE driver
Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.
For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.
Setting the crop successfully should result in re-configuration of those
registers which are affected when either source or destination dimensions
change, set_srcdst_params() is called for this purpose.
Some standard crop parameter checks are done in __vpe_try_crop().
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/vpe.c | 96 +
1 file changed, 96 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 6acdcd8..c6778f4 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1585,6 +1585,98 @@ static int vpe_s_fmt(struct file *file, void *priv,
struct v4l2_format *f)
return set_srcdst_params(ctx);
}
+static int __vpe_try_crop(struct vpe_ctx *ctx, struct v4l2_crop *cr)
+{
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr->type);
+ if (!q_data)
+ return -EINVAL;
+
+ /* we don't support crop on capture plane */
+ if (cr->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+ cr->c.top = cr->c.left = 0;
+ cr->c.width = q_data->width;
+ cr->c.height = q_data->height;
+ return 0;
+ }
+
+ if (cr->c.top < 0 || cr->c.left < 0) {
+ vpe_err(ctx->dev, "negative values for top and left\n");
+ cr->c.top = cr->c.left = 0;
+ }
+
+ v4l_bound_align_image(&cr->c.width, MIN_W, q_data->width, 1,
+ &cr->c.height, MIN_H, q_data->height, H_ALIGN, S_ALIGN);
+
+ /* adjust left/top if cropping rectangle is out of bounds */
+ if (cr->c.left + cr->c.width > q_data->width)
+ cr->c.left = q_data->width - cr->c.width;
+ if (cr->c.top + cr->c.height > q_data->height)
+ cr->c.top = q_data->height - cr->c.height;
+
+ return 0;
+}
+
+static int vpe_cropcap(struct file *file, void *priv, struct v4l2_cropcap *cr)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr->type);
+ if (!q_data)
+ return -EINVAL;
+
+ cr->bounds.left = 0;
+ cr->bounds.top = 0;
+ cr->bounds.width = q_data->width;
+ cr->bounds.height = q_data->height;
+ cr->defrect = cr->bounds;
+
+ return 0;
+}
+
+static int vpe_g_crop(struct file *file, void *fh, struct v4l2_crop *cr)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+
+ q_data = get_q_data(ctx, cr->type);
+ if (!q_data)
+ return -EINVAL;
+
+ cr->c = q_data->c_rect;
+
+ return 0;
+}
+
+static int vpe_s_crop(struct file *file, void *priv,
+ const struct v4l2_crop *crop)
+{
+ struct vpe_ctx *ctx = file2ctx(file);
+ struct vpe_q_data *q_data;
+ struct v4l2_crop cr = *crop;
+ int ret;
+
+ ret = __vpe_try_crop(ctx, &cr);
+ if (ret)
+ return ret;
+
+ q_data = get_q_data(ctx, cr.type);
+
+ if ((q_data->c_rect.left == cr.c.left) &&
+ (q_data->c_rect.top == cr.c.top) &&
+ (q_data->c_rect.width == cr.c.width) &&
+ (q_data->c_rect.height == cr.c.height)) {
+ vpe_dbg(ctx->dev, "requested crop values are already set\n");
+ return 0;
+ }
+
+ q_data->c_rect = cr.c;
+
+ return set_srcdst_params(ctx);
+}
+
static int vpe_reqbufs(struct file *file, void *priv,
struct v4l2_requestbuffers *reqbufs)
{
@@ -1672,6 +1764,10 @@ static const struct v4l2_ioctl_ops vpe_ioctl_ops = {
.vidioc_try_fmt_vid_out_mplane = vpe_try_fmt,
.vidioc_s_fmt_vid_out_mplane= vpe_s_fmt,
+ .vidioc_cropcap = vpe_cropcap,
+ .vidioc_g_crop = vpe_g_crop,
+ .vidioc_s_crop = vpe_s_crop,
+
.vidioc_reqbufs = vpe_reqbufs,
.vidioc_querybuf= vpe_querybuf,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] v4l: ti-vpe: Some VPE fixes and enhancements
This patch set mainly consists of minor fixes for the VPE driver. These fixes ensure the following: - The VPE module can be inserted and removed successively. - Make sure that smaller resolutions like qcif work correctly. - Prevent race condition between firmware loading and an open call to the v4l2 device. - Prevent the possibility of output m2m queue not having sufficient 'ready' buffers. - Some VPDMA data descriptor fields weren't understood correctly before. They are now used correctly. The rest of the patches add some minor features like DMA buf support and cropping. Reference branch: g...@github.com:boddob/linux.git vpe_for_315 Archit Taneja (7): v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs v4l: ti-vpe: register video device only when firmware is loaded v4l: ti-vpe: Use video_device_release_empty v4l: ti-vpe: Allow DMABUF buffer type support v4l: ti-vpe: Allow usage of smaller images v4l: ti-vpe: Fix some params in VPE data descriptors v4l: ti-vpe: Add crop support in VPE driver drivers/media/platform/ti-vpe/vpdma.c | 58 --- drivers/media/platform/ti-vpe/vpdma.h | 16 +-- drivers/media/platform/ti-vpe/vpe.c | 180 +++--- 3 files changed, 198 insertions(+), 56 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] v4l: ti-vpe: Allow usage of smaller images
The minimum width and height for VPE input/output was kept as 128 pixels. VPE doesn't have a constraint on the image height, it requires the image width to be atleast 16 bytes. Change the minimum supported dimensions to 32x32. This allows us to de-interlace qcif content. A smaller image size than 32x32 didn't make much sense, so stopped at this. Signed-off-by: Archit Taneja --- drivers/media/platform/ti-vpe/vpe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 915029b..3a610a6 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -49,8 +49,8 @@ #define VPE_MODULE_NAME "vpe" /* minimum and maximum frame sizes */ -#define MIN_W 128 -#define MIN_H 128 +#define MIN_W 32 +#define MIN_H 32 #define MAX_W 1920 #define MAX_H 1080 -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] v4l: ti-vpe: Use video_device_release_empty
The video_device struct is currently embedded in the driver data struct vpe_dev.
A vpe_dev instance is allocated by the driver, and the memory for the vfd is a
part of this struct.
The v4l2 core, however, manages the removal of the vfd region, through the
video_device's .release() op, which currently is the helper
video_device_release. This causes memory corruption, and leads to issues when
we try to re-insert the vpe module.
Use the video_device_release_empty helper function instead
Signed-off-by: Archit Taneja
---
drivers/media/platform/ti-vpe/vpe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 4243687..bb275f4 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -1998,7 +1998,7 @@ static struct video_device vpe_videodev = {
.fops = &vpe_fops,
.ioctl_ops = &vpe_ioctl_ops,
.minor = -1,
- .release= video_device_release,
+ .release= video_device_release_empty,
.vfl_dir= VFL_DIR_M2M,
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] v4l: ti-vpe: Make sure in job_ready that we have the needed number of dst_bufs
VPE has a ctrl parameter which decides how many mem to mem transactions the active job from the job queue can perform. The driver's job_ready() made sure that the number of ready source buffers are sufficient for the job to execute successfully. But it didn't make sure if there are sufficient ready destination buffers in the capture queue for the VPE output. If the time taken by VPE to process a single frame is really slow, then it's possible that we don't need to imply such a restriction on the dst queue, but really fast transactions(small resolution, no de-interlacing) may cause us to hit the condition where we don't have any free buffers for the VPE to write on. Add the extra check in job_ready() to make sure we have the sufficient amount of destination buffers. Signed-off-by: Archit Taneja --- drivers/media/platform/ti-vpe/vpe.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 1296c53..623e59e 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -887,6 +887,9 @@ static int job_ready(void *priv) if (v4l2_m2m_num_src_bufs_ready(ctx->m2m_ctx) < needed) return 0; + if (v4l2_m2m_num_dst_bufs_ready(ctx->m2m_ctx) < needed) + return 0; + return 1; } -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] v4l: ti-vpe: Allow DMABUF buffer type support
For OMAP and DRA7x, we generally allocate video and graphics buffers through omapdrm since the corresponding omap-gem driver provides DMM-Tiler backed contiguous buffers. omapdrm is a dma-buf exporter. These buffers are used by other drivers in the video pipeline. Add VB2_DMABUF flag to the io_modes of the vb2 output and capture queues. This allows the driver to import dma shared buffers. Signed-off-by: Archit Taneja --- drivers/media/platform/ti-vpe/vpe.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index bb275f4..915029b 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -1768,7 +1768,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, memset(src_vq, 0, sizeof(*src_vq)); src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE; - src_vq->io_modes = VB2_MMAP; + src_vq->io_modes = VB2_MMAP | VB2_DMABUF; src_vq->drv_priv = ctx; src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer); src_vq->ops = &vpe_qops; @@ -1781,7 +1781,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq, memset(dst_vq, 0, sizeof(*dst_vq)); dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; - dst_vq->io_modes = VB2_MMAP; + dst_vq->io_modes = VB2_MMAP | VB2_DMABUF; dst_vq->drv_priv = ctx; dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer); dst_vq->ops = &vpe_qops; -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEWv3 PATCH 15/17] vb2: call buf_finish after the state check.
On Fri, Feb 28, 2014 at 06:42:13PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > Don't call buf_finish unless we know that the buffer is in a valid state. > > Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEWv3 PATCH 13/17] vb2: replace BUG by WARN_ON
On Fri, Feb 28, 2014 at 06:42:11PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > No need to oops for this, WARN_ON is good enough. > > Signed-off-by: Hans Verkuil I agree; BUG() is better for something that's always (or almost so) executed. Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEWv3 PATCH 06/17] vb2: call buf_finish from __queue_cancel.
On Mon, Mar 03, 2014 at 08:28:05AM +0200, Sakari Ailus wrote: > On Fri, Feb 28, 2014 at 06:42:04PM +0100, Hans Verkuil wrote: > > From: Hans Verkuil > > > > If a queue was canceled, then the buf_finish op was never called for the > > pending buffers. So add this call to queue_cancel. Before calling buf_finish > > set the buffer state to PREPARED, which is the correct state. That way the > > states DONE and ERROR will only be seen in buf_finish if streaming is in > > progress. > > > > Since buf_finish can now be called from non-streaming state we need to > > adapt the handful of drivers that actually need to know this. > > > > Signed-off-by: Hans Verkuil > > Acked-by: Sakari Ailus You can replace this by: Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEWv3 PATCH 12/17] vb2: properly clean up PREPARED and QUEUED buffers
On Fri, Feb 28, 2014 at 06:42:10PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > If __reqbufs was called then existing buffers are freed. However, if that > happens without ever having started STREAMON, but if buffers have been queued, > then the buf_finish op is never called. > > Add a call to __vb2_queue_cancel in __reqbufs so that these buffers are > cleaned up there as well. > > Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEWv3 PATCH 06/17] vb2: call buf_finish from __queue_cancel.
On Fri, Feb 28, 2014 at 06:42:04PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > If a queue was canceled, then the buf_finish op was never called for the > pending buffers. So add this call to queue_cancel. Before calling buf_finish > set the buffer state to PREPARED, which is the correct state. That way the > states DONE and ERROR will only be seen in buf_finish if streaming is in > progress. > > Since buf_finish can now be called from non-streaming state we need to > adapt the handful of drivers that actually need to know this. > > Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unknown EM2800 video grabber (card=0)
> No idea what's going wrong here, but this dmesg output is definitely > incomplete. > Or maybe you modifed the driver and messed things up ? ;-) My guess is that it's not actually an em28xx device at all (and the doc the user is referring to refers to some device by the manufacturer with the same name). Open it up and send us some hi-res photos of the PCB. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEWv3 PATCH 03/17] vb2: fix PREPARE_BUF regression
On Sat, Mar 1, 2014 at 2:42 AM, Hans Verkuil wrote:
> Fix an incorrect test in vb2_internal_qbuf() where only DEQUEUED buffers
> are allowed. But PREPARED buffers are also OK.
>
> Introduced by commit 4138111a27859dcc56a5592c804dd16bb12a23d1
> ("vb2: simplify qbuf/prepare_buf by removing callback").
>
> Signed-off-by: Hans Verkuil
> Acked-by: Laurent Pinchart
Acked-by: Pawel Osciak
> ---
> drivers/media/v4l2-core/videobuf2-core.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index f1a2857c..909f367 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1420,11 +1420,6 @@ static int vb2_internal_qbuf(struct vb2_queue *q,
> struct v4l2_buffer *b)
> return ret;
>
> vb = q->bufs[b->index];
> - if (vb->state != VB2_BUF_STATE_DEQUEUED) {
> - dprintk(1, "%s(): invalid buffer state %d\n", __func__,
> - vb->state);
> - return -EINVAL;
> - }
>
> switch (vb->state) {
> case VB2_BUF_STATE_DEQUEUED:
> @@ -1438,7 +1433,8 @@ static int vb2_internal_qbuf(struct vb2_queue *q,
> struct v4l2_buffer *b)
> dprintk(1, "qbuf: buffer still being prepared\n");
> return -EINVAL;
> default:
> - dprintk(1, "qbuf: buffer already in use\n");
> + dprintk(1, "%s(): invalid buffer state %d\n", __func__,
> + vb->state);
> return -EINVAL;
> }
>
> --
> 1.9.rc1
>
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEWv3 PATCH 01/17] vb2: Check if there are buffers before streamon
On Sat, Mar 1, 2014 at 2:41 AM, Hans Verkuil wrote:
> From: Ricardo Ribalda Delgado
>
> This patch adds a test preventing streamon() if there is no buffer
> ready.
>
> Without this patch, a user could call streamon() before
> preparing any buffer. This leads to a situation where if he calls
> close() before calling streamoff() the device is kept streaming.
>
> Signed-off-by: Ricardo Ribalda Delgado
> Signed-off-by: Hans Verkuil
Acked-by: Pawel Osciak
> ---
> drivers/media/v4l2-core/videobuf2-core.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 5a5fb7f..a127925 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1776,6 +1776,11 @@ static int vb2_internal_streamon(struct vb2_queue *q,
> enum v4l2_buf_type type)
> return 0;
> }
>
> + if (!q->num_buffers) {
> + dprintk(1, "streamon: no buffers have been allocated\n");
> + return -EINVAL;
> + }
> +
> /*
> * If any buffers were queued before streamon,
> * we can now pass them to driver for processing.
> --
> 1.9.rc1
>
--
Best regards,
Pawel Osciak
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Mar 3 04:00:26 CET 2014 git branch: test git hash: a06b429df49bb50ec1e671123a45147a1d1a6186 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-6.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-i686: OK linux-3.14-rc1-i686: OK linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-x86_64: OK linux-3.14-rc1-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unknown EM2800 video grabber (card=0)
Am 01.03.2014 10:32, schrieb Jacob Korf: > Hi there, > > I'm trying this video capture stick from Conceptronic, the Home Video > Creator, but I'm not getting it to work with Linux. I'm using kernel > version 3.13.5 and I'm on Arch Linux. More information and specs here: > http://www.conceptronic.net/product.php?id=322&linkid=294. According to specsheet, it's a em2862 device. You will need to figure out which demodulator it uses. > > This is the output from lsusb -v: > > Bus 001 Device 005: ID 1d19:6108 Dexatek Technology Ltd. > Couldn't open device, some information will be missing > Device Descriptor: > bLength18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 239 Miscellaneous Device > bDeviceSubClass 2 ? > bDeviceProtocol 1 Interface Association > bMaxPacketSize064 > idVendor 0x1d19 Dexatek Technology Ltd. > idProduct 0x6108 > bcdDevice 40.01 > iManufacturer 1 > iProduct2 > iSerial 3 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 248 > bNumInterfaces 6 6 interfaces ??? > bConfigurationValue 1 > iConfiguration 4 > bmAttributes 0x80 > (Bus Powered) > MaxPower 500mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass255 Vendor Specific Subclass > bInterfaceProtocol255 Vendor Specific Protocol > iInterface 32 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x8e EP 14 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0020 1x 32 bytes > bInterval 4 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x0e EP 14 OUT > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0020 1x 32 bytes > bInterval 4 > Interface Association: > bLength 8 > bDescriptorType11 > bFirstInterface 1 > bInterfaceCount 5 > bFunctionClass255 Vendor Specific Class > bFunctionSubClass 255 Vendor Specific Subclass > bFunctionProtocol 255 Vendor Specific Protocol > iFunction 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber1 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass255 Vendor Specific Subclass > bInterfaceProtocol255 Vendor Specific Protocol > iInterface 7 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x8f EP 15 IN > bmAttributes3 > Transfer TypeInterrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 7 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber2 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass255 Vendor Specific Subclass > bInterfaceProtocol255 Vendor Specific Protocol > iInterface 20 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x83 EP 3 IN > bmAttributes2 > Transfer TypeBulk > Synch Type None > Usage Type Data > wMaxPacketSize 0x0200 1x 512 bytes > bInterval 0 > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber2 > bAlternateSetting 1 > bNumEndpoints 1 > bInterfaceClass 255 Vendor Specific Class > bInterfaceSubClass255 Vendor Specific Subclass > bInterfaceProtocol255 Vendor Specific Protocol > iInterfa
Re: [PATCH v2] omap3isp: Fix kerneldoc for _module_sync_is_stopping and isp_isr()
Hi Peter,
Thank you for the patch.
On Friday 28 February 2014 18:36:07 Peter Meerwald wrote:
> use the correct name in the comment describing function
> omap3isp_module_sync_is_stopping()
>
> isp_isr() never returned IRQ_NONE, remove the comment saying so
>
> Signed-off-by: Peter Meerwald
Acked-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/media/platform/omap3isp/isp.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index 5807185..d60a4b7 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -588,9 +588,6 @@ static void isp_isr_sbl(struct isp_device *isp)
> * @_isp: Pointer to the OMAP3 ISP device
> *
> * Handles the corresponding callback if plugged in.
> - *
> - * Returns IRQ_HANDLED when IRQ was correctly handled, or IRQ_NONE when the
> - * IRQ wasn't handled.
> */
> static irqreturn_t isp_isr(int irq, void *_isp)
> {
> @@ -1420,7 +1417,7 @@ int omap3isp_module_sync_idle(struct media_entity *me,
> wait_queue_head_t *wait, }
>
> /*
> - * omap3isp_module_sync_is_stopped - Helper to verify if module was
> stopping + * omap3isp_module_sync_is_stopping - Helper to verify if module
> was stopping * @wait: ISP submodule's wait queue for streamoff/interrupt
> synchronization * @stopping: flag which tells module wants to stop
> *
--
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: Support for Empia 2980 video/audio capture chip set
Am 27.02.2014 02:47, schrieb Keith Lawson: > On Mon, Feb 24, 2014 at 06:38:59PM +0100, Frank Schäfer wrote: >> Am 06.02.2014 13:57, schrieb Keith Lawson: >>> On Mon, Jan 20, 2014 at 09:08:25PM +0100, Frank Schäfer wrote: On 17.01.2014 01:11, Keith Lawson wrote: > On Wed, Jan 15, 2014 at 10:37:44PM +0100, Frank Schäfer wrote: >> Am 14.01.2014 01:48, schrieb Keith Lawson: >>> On 2014-01-12 11:56, Frank Schäfer wrote: >>> On 09.01.2014 02:02, Keith Lawson wrote: > Hello, I sent the following message to the linux-usb mailing list > and they suggested I try here. I'm trying to get a "Dazzle Video > Capture USB V1.0" video capture card working on a Linux device but > it doesn't > look like the chip set is supported yet. I believe this card is the > next version of the Pinnacle VC100 capture card that worked with the > em28xx kernel module. The hardware vendor that sold the card says that > this device has an Empia 2980 chip set in it so I'm inquiring about > support for that chip set. I'm just wondering about the best > approach for getting the new chip supported in the kernel. Is this > something the > em28xx maintainers would naturally address in time or can I assist > in getting this into the kernel? Here's dmesg from the Debian box > I'm working on: [ 3198.920619] usb 3-1: new high-speed USB device > number 5 > usingxhci_hcd [ 3198.939394] usb 3-1: New USB device found, > idVendor=1b80,idProduct=e60a [ 3198.939399] usb 3-1: New USB device > strings: Mfr=0, Product=1,SerialNumber=2 [ 3198.939403] usb 3-1: > Product: Dazzle > Video Capture USB Audio Device [ 3198.939405] usb 3-1: SerialNumber: > 0 l440:~$ uname -a Linux l440 3.10-3-amd64 #1 SMP Debian 3.10.11-1 > (2013-09-10) x86_64 GNU/Linux If this isn't the appropriate list to > ask > this question please point me in the right direction. Thanks, Keith The em28xx is indeed the dedicated driver for this device, but it's hard to say how much work would be necessary to add support for it. We currently don't support any em29xx chip yet, but in theory it is just an extended em28xx device. Whatever that means when it comes to the low level stuff... ;) >>> What's the best route to get support for this chip added then? Should >>> I start working on a patch myself or will this just happen during the >>> course of development of the em28xx module? I'm a developer but >>> haven't done any kernel hacking so this would likely be a steep >>> learning curve for me. >> Can you create USB-Traces of the Windows driver and send us the output >> of "lsusb -v -d 1b80:e60a" for this device ? >> That will give us a hint how much work will be needed. > For the USB-trace will the Win7 logman output do or is there a Win7 > 64-bit utility like usbsnoop I should use? AFAIK the logman output doesn't contain any transferred data. SniffUSB would be preferred, but AFAIK it doesn't work with Win 7. You may also want to try USBPcap (http://desowin.org/usbpcap/), but I don't know if it runs on the 64bit version of Win 7. There are also various commercial USB-Sniffers and some of them are providing a free trial period/version. In any case we need a readable (text) sniffing output. >>> Thanks for the pointer. I used USBPcap and exported text out of wireshark. >>> >>> Here's the capture of connecting the device: >>> >>> https://www.libertas-tech.com/dazzle_usb_connect.txt >>> >>> Here's a capture of the device recording a 1 minute video. This one is >>> almost 700 meg so you probably don't want to try and open it in a browser: >>> >>> https://www.libertas-tech.com/dazzle_recording_video.txt >>> >>> I can arrange to get one of these devices in the hands of a developer if >>> that would help too. >> Sorry for the delay, I'm currently burried under lots other stuff... > No worries. I know that feeling all too well. > >> I haven't finished evaluating these logs yet, but so far I can say that >> there's a lot of known stuff but also much new/unknown stuff. >> Which capturing settings (resolution, video format, ...) did you use for >> these logs ? > Someone else did the capture for me since I didn't have a Windows box it > would work on. He had it connected to a video camera but didn't have an audio > connection so there's no sound. > > Here's the settings from the Pinnical software. > > The properties of the video are: > > Codec IPB MPEG-2 MP@ML 4:2:0 > Bitrate 8000 kBit/s > Duration 00:00:05.10 > Color Depth16 Bit > Frame Aspect4:3 > AlphaNo > Dimensions720 x 480 px > Pixel Aspect 0.89 > Framestart 0 > Frames
Re: [PATCH 0/3] media/drx39xyj: fix DJH_DEBUG path null pointer dereferences, and compile errors.
Em Sat, 01 Mar 2014 07:57:42 -0300 Mauro Carvalho Chehab escreveu: > Hi Devin, > > Em Fri, 28 Feb 2014 19:13:16 -0500 > Devin Heitmueller escreveu: > > > Seems kind of strange that I wasn't on the CC for this, since I was the > > original author of all that code (in fact, DJH are my initials). > > > > Mauro, did you strip off my authorship when you pulled the patches from my > > tree? > > Thanks for warning me about that! > > Not sure what happened there. The original branch were added back in 2012, > with the sole reason to provide a way for Patrick Dickey to catch a few > patches I made on that time with some CodingStyle fixes: > > http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j > > There, your name was there as an extra weird "Committer" tag on those > changesets: > > http://git.linuxtv.org/mchehab/experimental.git/commit/24d5ed7b19cc19f807264d7d4d56ab48e5cab230 > > http://git.linuxtv.org/mchehab/experimental.git/commit/0440897f72b9cf82b8f576fae292b0567ad88239 > > The second one also contained a "Tag: tip" on it. So, I suspect that > something wrong happened when I imported it (either from your tree or > from some email sent by you or by Patrick). Probably, some broken > hg-import scripting. > > Anyway, I rebased my tree, fixing those issues, at: > > http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-v3 > > I also added a credit at the first patch for Patrick's fixes that > I suspect it was merged somehow there, based on the comments he > posted at the mailing list when he sent his 25-patches series: > https://lwn.net/Articles/467301/ > > Please let me know if you find any other issues on it. Anyway, I'll post > the patches from my experimental branch at the ML before merging them > upstream, in order to get a proper review. > > Before that happen, however, I need to fix a serious bug that is > preventing to watch TV with this frontend, that it is there since the > first patch. > > To be sure that this is a driver issue, I tested the driver on > another OS using the original PCTV driver, and it worked. > > However, since the first working version of this driver, it > is randomly losing MPEG TS packets. > > The bug is intermittent: every time it sets up VSB reception, it loses > different MPEG TS tables. Sometimes, not a single TS packet is received, > but, most of the time, it gets ~ 1/10 of the expected number of packets. Partially found and fixed it with this patch: http://git.linuxtv.org/mchehab/experimental.git/commitdiff/5cc6dca273e51494c17df5e488aaf223732edb38 After that, it properly receives data at the right rate (~19Mbps) as generated by DTA-2111. However, there are still some weird things happening there... While the bit rate is ~ 19 Mbps, and adding a printk just before calling dvb_dmx_swfilter() to print the rate is showing the right bitrate (The signal generator shows it as 19.392.659 bps): [86213.084891] em28xx_dvb_urb_data_copy: 19428.672 kbps [86214.087737] em28xx_dvb_urb_data_copy: 19431.680 kbps [86215.090586] em28xx_dvb_urb_data_copy: 19431.680 kbps [86216.093433] em28xx_dvb_urb_data_copy: 19431.680 kbps [86217.096280] em28xx_dvb_urb_data_copy: 19431.680 kbps [86218.099126] em28xx_dvb_urb_data_copy: 19431.680 kbps [86219.101971] em28xx_dvb_urb_data_copy: 19431.680 kbps [86220.104814] em28xx_dvb_urb_data_copy: 19431.680 kbps [86221.107659] em28xx_dvb_urb_data_copy: 19431.680 kbps [86222.110519] em28xx_dvb_urb_data_copy: 19430.176 kbps [86223.113351] em28xx_dvb_urb_data_copy: 19431.680 kbps [86224.116200] em28xx_dvb_urb_data_copy: 19431.680 kbps [86225.119047] em28xx_dvb_urb_data_copy: 19431.680 kbps Using dvbv5-zap on monitor mode only shows about 6.3 Mbps: PID FREQ SPEED TOTAL 05b6 1.33 p/s 2.0 Kbps2 KB 06a5 4.57 p/s 6.7 Kbps 10 KB 07cf 4.40 p/s 6.5 Kbps9 KB 0a93 1200.38 p/s 1763.1 Kbps 2651 KB 0f75 2.66 p/s 3.9 Kbps5 KB 1743 5.49 p/s 8.1 Kbps 12 KB 18c4 1205.04 p/s 1769.9 Kbps 2661 KB 197a 4.65 p/s 6.8 Kbps 10 KB 1c15 4.99 p/s 7.3 Kbps 11 KB 1c68 1286.40 p/s 1889.4 Kbps 2841 KB 1d4b 4.32 p/s 6.3 Kbps9 KB 1fb2 4.07 p/s 6.0 Kbps8 KB 1fff 2.33 p/s 3.4 Kbps5 KB TOT4319.15 p/s 6343.7 Kbps 9541 KB Lock (0x1f) Signal= 71.00% C/N= 0.42% UCB= 273 postBER= 0 It seems that most of the packets are without the 0x47 sync byte there. In order to compare with another frontend, this is what it is seen with WinTV Aero-A (model 72251, rev D3F0): PID FREQ SPEED TOTAL 15.87 p/s 23.3 Kbps 29 KB 0010 6.39 p/s 9.4 Kbps 11 KB 0011 11754.82 p/s 17264.9 Kbps21617 KB 0014312.27 p/s458.6 Kbps 574 KB 0015156.03 p/s229.2 Kbps 286 KB 001f 1.70 p/s 2.5 Kbps3 KB
[GIT PULL FOR v3.15] DocBook build fix
Hi Mauro, Here's a trivial fix for the DocBook build. Please pull. The following changes since commit a06b429df49bb50ec1e671123a45147a1d1a6186: [media] au0828: rework GPIO management for HVR-950q (2014-02-28 15:21:31 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git v4l2-doc-fix for you to fetch changes up to 8a7beb0cc41415f50c13bedc4dc13a4a49895839: v4l: Trivial documentation fix (2014-03-02 17:23:36 +0200) Sakari Ailus (1): v4l: Trivial documentation fix Documentation/DocBook/media/v4l/controls.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.15] Fix buffer timestamp documentation, add new timestamp flags
Hi Mauro,
Here's the long overdue timestamp flag patchset. Buffers are stamped at
frame end now by default, and a new timestamp source buffer flag mask is
introduced. Some fixes to a few mem2mem drivers are also included.
Changes since the review: fix documentation build in io.xml in the last
patch; xref linkend tag was missing the final slash ("/"); it's now there.
Please pull.
The following changes since commit a06b429df49bb50ec1e671123a45147a1d1a6186:
[media] au0828: rework GPIO management for HVR-950q (2014-02-28 15:21:31
-0300)
are available in the git repository at:
ssh://linuxtv.org/git/sailus/media_tree.git timestamp-buf-ready
for you to fetch changes up to 98ff8bb775df6f5990a56ac90f0957670a1991a5:
v4l: Document timestamp buffer flag behaviour (2014-03-02 17:31:38 +0200)
Hans Verkuil (1):
vb2: fix timecode and flags handling for output buffers
Sakari Ailus (10):
v4l: Document timestamp behaviour to correspond to reality
v4l: Use full 32 bits for buffer flags
v4l: Rename vb2_queue.timestamp_type as timestamp_flags
v4l: Timestamp flags will soon contain timestamp source, not just type
v4l: Add timestamp source flags, mask and document them
v4l: Handle buffer timestamp flags correctly
uvcvideo: Tell the user space we're using start-of-exposure timestamps
exynos-gsc, m2m-deinterlace, mx2_emmaprp: Copy v4l2_buffer data from src
to dst
v4l: Copy timestamp source flags to destination on m2m devices
v4l: Document timestamp buffer flag behaviour
Documentation/DocBook/media/v4l/io.xml | 124 ++--
drivers/media/parport/bw-qcam.c|2 +-
drivers/media/platform/blackfin/bfin_capture.c |2 +-
drivers/media/platform/coda.c |7 +-
drivers/media/platform/davinci/vpbe_display.c |2 +-
drivers/media/platform/davinci/vpif_capture.c |2 +-
drivers/media/platform/davinci/vpif_display.c |2 +-
drivers/media/platform/exynos-gsc/gsc-m2m.c| 12 +-
drivers/media/platform/exynos4-is/fimc-capture.c |2 +-
drivers/media/platform/exynos4-is/fimc-lite.c |2 +-
drivers/media/platform/exynos4-is/fimc-m2m.c |7 +-
drivers/media/platform/m2m-deinterlace.c | 11 +-
drivers/media/platform/mem2mem_testdev.c |7 +-
drivers/media/platform/mx2_emmaprp.c | 13 +-
drivers/media/platform/s3c-camif/camif-capture.c |2 +-
drivers/media/platform/s5p-g2d/g2d.c |7 +-
drivers/media/platform/s5p-jpeg/jpeg-core.c|7 +-
drivers/media/platform/s5p-mfc/s5p_mfc.c |9 +-
drivers/media/platform/soc_camera/atmel-isi.c |2 +-
drivers/media/platform/soc_camera/mx2_camera.c |2 +-
drivers/media/platform/soc_camera/mx3_camera.c |2 +-
drivers/media/platform/soc_camera/rcar_vin.c |2 +-
.../platform/soc_camera/sh_mobile_ceu_camera.c |2 +-
drivers/media/platform/ti-vpe/vpe.c|6 +-
drivers/media/platform/vivi.c |2 +-
drivers/media/platform/vsp1/vsp1_video.c |2 +-
drivers/media/usb/em28xx/em28xx-video.c|4 +-
drivers/media/usb/pwc/pwc-if.c |2 +-
drivers/media/usb/stk1160/stk1160-v4l.c|2 +-
drivers/media/usb/usbtv/usbtv-video.c |2 +-
drivers/media/usb/uvc/uvc_queue.c |3 +-
drivers/media/v4l2-core/videobuf2-core.c | 64 +-
include/media/videobuf2-core.h |4 +-
include/uapi/linux/videodev2.h | 42 ---
34 files changed, 236 insertions(+), 127 deletions(-)
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] v4l: Trivial documentation fix
Remove one quotation mark. This fixes DocBook documentation build. Signed-off-by: Sakari Ailus --- Documentation/DocBook/media/v4l/controls.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 0e1770c..b7f3feb 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2259,7 +2259,7 @@ VBV buffer control. - + V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE integer -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] s5p-fimc: Remove reference to outdated macro
On 02/12/2014 11:08 AM, Paul Bolle wrote:
The Kconfig symbol S5P_SETUP_MIPIPHY was removed in v3.13. Remove a
reference to its macro from a list of Kconfig options.
Signed-off-by: Paul Bolle
---
See commit e66f233dc7f7 ("ARM: Samsung: Remove the MIPI PHY setup
code"). Should one or more options be added to replace
S5P_SETUP_MIPIPHY? I couldn't say. It's safe to remove this one anyway.
Thanks, patch applied.
There has been also a related patch posted for the MIPI CSIS/DSIM PHY
driver: http://www.spinics.net/lists/linux-samsung-soc/msg26773.html
Documentation/video4linux/fimc.txt | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/video4linux/fimc.txt
b/Documentation/video4linux/fimc.txt
index e51f1b5..7d6e160 100644
--- a/Documentation/video4linux/fimc.txt
+++ b/Documentation/video4linux/fimc.txt
@@ -151,9 +151,8 @@ CONFIG_S5P_DEV_FIMC1 \
CONFIG_S5P_DEV_FIMC2 |optional
CONFIG_S5P_DEV_FIMC3 |
CONFIG_S5P_SETUP_FIMC /
-CONFIG_S5P_SETUP_MIPIPHY \
-CONFIG_S5P_DEV_CSIS0 | optional for MIPI-CSI interface
-CONFIG_S5P_DEV_CSIS1 /
+CONFIG_S5P_DEV_CSIS0 \optional for MIPI-CSI interface
+CONFIG_S5P_DEV_CSIS1 /
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media DocBook: fix NV16M description.
Hi Hans, Thank you for the patch. On Sunday 02 March 2014 10:43:12 Hans Verkuil wrote: > The NV16M description contained some copy-and-paste text from NV12M, > suggesting that this format is a 4:2:0 format when it really is a > 4:2:2 format. > > Fixed the text. > > Signed-off-by: Hans Verkuil Acked-by: Laurent Pinchart > --- > Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 9 - > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml > b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml index c51d5a4..fb2b5e3 > 100644 > --- a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml > +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml > @@ -12,18 +12,17 @@ > > Description > > - This is a multi-planar, two-plane version of the YUV 4:2:0 format. > + This is a multi-planar, two-plane version of the YUV 4:2:2 format. > The three components are separated into two sub-images or planes. > V4L2_PIX_FMT_NV16M differs from > V4L2_PIX_FMT_NV16 in that the two planes are > non-contiguous in memory, i.e. the chroma -plane does not necessarily > immediately follows the luma plane. > +plane does not necessarily immediately follow the luma plane. > The luminance data occupies the first plane. The Y plane has one byte per > pixel. In the second plane there is chrominance data with alternating > chroma samples. The CbCr plane is the same width and height, in bytes, as > the Y plane. -Each CbCr pair belongs to four pixels. For example, > +Each CbCr pair belongs to two pixels. For example, > Cb0/Cr0 belongs to > -Y'00, Y'01, > -Y'10, Y'11. > +Y'00, Y'01. > V4L2_PIX_FMT_NV61M is the same as > V4L2_PIX_FMT_NV16M except the Cb and Cr bytes are > swapped, the CrCb plane starts with a Cr byte. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media DocBook: fix NV16M description.
The NV16M description contained some copy-and-paste text from NV12M, suggesting that this format is a 4:2:0 format when it really is a 4:2:2 format. Fixed the text. Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/pixfmt-nv16m.xml | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml index c51d5a4..fb2b5e3 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml @@ -12,18 +12,17 @@ Description - This is a multi-planar, two-plane version of the YUV 4:2:0 format. + This is a multi-planar, two-plane version of the YUV 4:2:2 format. The three components are separated into two sub-images or planes. V4L2_PIX_FMT_NV16M differs from V4L2_PIX_FMT_NV16 in that the two planes are non-contiguous in memory, i.e. the chroma -plane does not necessarily immediately follows the luma plane. +plane does not necessarily immediately follow the luma plane. The luminance data occupies the first plane. The Y plane has one byte per pixel. In the second plane there is chrominance data with alternating chroma samples. The CbCr plane is the same width and height, in bytes, as the Y plane. -Each CbCr pair belongs to four pixels. For example, +Each CbCr pair belongs to two pixels. For example, Cb0/Cr0 belongs to -Y'00, Y'01, -Y'10, Y'11. +Y'00, Y'01. V4L2_PIX_FMT_NV61M is the same as V4L2_PIX_FMT_NV16M except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte. -- 1.9.rc1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
