| Message ID | 1393922965-15967-8-git-send-email-archit@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Archit, On 03/04/14 09:49, Archit Taneja wrote: > Add selection ioctl ops. For VPE, cropping makes sense only for the input to > VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense > only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers). > > For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output > in a rectangle within the capture buffer. For the OUTPUT type, V4L2_SEL_TGT_CROP > results in selecting a rectangle region within the source buffer. > > Setting the crop/compose rectangles should successfully result in > re-configuration of registers which are affected when either source or > destination dimensions change, set_srcdst_params() is called for this purpose. > > Signed-off-by: Archit Taneja <archit@ti.com> > --- > drivers/media/platform/ti-vpe/vpe.c | 142 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 142 insertions(+) > > diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c > index 03a6846..b938590 100644 > --- a/drivers/media/platform/ti-vpe/vpe.c > +++ b/drivers/media/platform/ti-vpe/vpe.c > @@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx *ctx, > { > switch (type) { > case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE: > + case V4L2_BUF_TYPE_VIDEO_OUTPUT: > return &ctx->q_data[Q_DATA_SRC]; > case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE: > + case V4L2_BUF_TYPE_VIDEO_CAPTURE: I noticed that the querycap implementation is wrong. It reports V4L2_CAP_VIDEO_M2M instead of V4L2_CAP_VIDEO_M2M_MPLANE. This driver is using the multiplanar formats, so the M2M_MPLANE cap should be set. This should be a separate patch. BTW, did you test the driver with the v4l2-compliance tool? The latest version (http://git.linuxtv.org/v4l-utils.git) has m2m support. However, if you want to test streaming (the -s option), then you will probably need to base your kernel on this tree: http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/vb2-part1 That branch contains a pile of fixes for vb2 and without that v4l2-compliance -s will fail a number of tests. > return &ctx->q_data[Q_DATA_DST]; > default: > BUG(); > @@ -1585,6 +1587,143 @@ static int vpe_s_fmt(struct file *file, void *priv, struct v4l2_format *f) > return set_srcdst_params(ctx); > } > > +static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection *s) > +{ > + struct vpe_q_data *q_data; > + > + if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) && > + (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)) > + return -EINVAL; > + > + q_data = get_q_data(ctx, s->type); > + if (!q_data) > + return -EINVAL; > + > + switch (s->target) { > + case V4L2_SEL_TGT_COMPOSE: > + case V4L2_SEL_TGT_COMPOSE_DEFAULT: > + case V4L2_SEL_TGT_COMPOSE_BOUNDS: > + /* > + * COMPOSE target is only valid for capture buffer type, for > + * output buffer type, assign existing crop parameters to the > + * selection rectangle > + */ > + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) { > + break; > + } else { No need for the 'else' keywork here. > + s->r = q_data->c_rect; > + return 0; > + } > + > + case V4L2_SEL_TGT_CROP: > + case V4L2_SEL_TGT_CROP_DEFAULT: > + case V4L2_SEL_TGT_CROP_BOUNDS: > + /* > + * CROP target is only valid for output buffer type, for capture > + * buffer type, assign existing compose parameters to the > + * selection rectangle > + */ > + if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) { > + break; > + } else { Ditto. > + s->r = q_data->c_rect; > + return 0; > + } > + default: > + return -EINVAL; > + } > + > + if (s->r.top < 0 || s->r.left < 0) { > + vpe_err(ctx->dev, "negative values for top and left\n"); > + s->r.top = s->r.left = 0; > + } > + > + v4l_bound_align_image(&s->r.width, MIN_W, q_data->width, 1, > + &s->r.height, MIN_H, q_data->height, H_ALIGN, S_ALIGN); > + > + /* adjust left/top if cropping rectangle is out of bounds */ > + if (s->r.left + s->r.width > q_data->width) > + s->r.left = q_data->width - s->r.width; > + if (s->r.top + s->r.height > q_data->height) > + s->r.top = q_data->height - s->r.height; > + > + return 0; > +} > + > +static int vpe_g_selection(struct file *file, void *fh, > + struct v4l2_selection *s) > +{ > + struct vpe_ctx *ctx = file2ctx(file); > + struct vpe_q_data *q_data; > + > + if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) && > + (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)) > + return -EINVAL; > + > + q_data = get_q_data(ctx, s->type); > + if (!q_data) > + return -EINVAL; > + > + switch (s->target) { > + /* return width and height from S_FMT of the respective buffer type */ > + case V4L2_SEL_TGT_COMPOSE_DEFAULT: > + case V4L2_SEL_TGT_COMPOSE_BOUNDS: > + case V4L2_SEL_TGT_CROP_BOUNDS: > + case V4L2_SEL_TGT_CROP_DEFAULT: > + s->r.left = 0; > + s->r.top = 0; > + s->r.width = q_data->width; > + s->r.height = q_data->height; > + return 0; > + > + /* > + * CROP target holds for the output buffer type, and COMPOSE target > + * holds for the capture buffer type. We still return the c_rect params > + * for both the target types. > + */ > + case V4L2_SEL_TGT_COMPOSE: > + case V4L2_SEL_TGT_CROP: > + s->r.left = q_data->c_rect.left; > + s->r.top = q_data->c_rect.top; > + s->r.width = q_data->c_rect.width; > + s->r.height = q_data->c_rect.height; > + return 0; > + } > + > + return -EINVAL; > +} > + > + > +static int vpe_s_selection(struct file *file, void *fh, > + struct v4l2_selection *s) > +{ > + struct vpe_ctx *ctx = file2ctx(file); > + struct vpe_q_data *q_data; > + struct v4l2_selection sel = *s; > + int ret; > + > + ret = __vpe_try_selection(ctx, &sel); > + if (ret) > + return ret; > + > + q_data = get_q_data(ctx, sel.type); > + if (!q_data) > + return -EINVAL; > + > + if ((q_data->c_rect.left == sel.r.left) && > + (q_data->c_rect.top == sel.r.top) && > + (q_data->c_rect.width == sel.r.width) && > + (q_data->c_rect.height == sel.r.height)) { > + vpe_dbg(ctx->dev, > + "requested crop/compose values are already set\n"); > + return 0; > + } > + > + q_data->c_rect = sel.r; > + > + return set_srcdst_params(ctx); > +} > + > static int vpe_reqbufs(struct file *file, void *priv, > struct v4l2_requestbuffers *reqbufs) > { > @@ -1672,6 +1811,9 @@ 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_g_selection = vpe_g_selection, > + .vidioc_s_selection = vpe_s_selection, > + > .vidioc_reqbufs = vpe_reqbufs, > .vidioc_querybuf = vpe_querybuf, > > Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Tuesday 04 March 2014 03:10 PM, Hans Verkuil wrote: > Hi Archit, > > On 03/04/14 09:49, Archit Taneja wrote: >> Add selection ioctl ops. For VPE, cropping makes sense only for the input to >> VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense >> only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers). >> >> For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output >> in a rectangle within the capture buffer. For the OUTPUT type, V4L2_SEL_TGT_CROP >> results in selecting a rectangle region within the source buffer. >> >> Setting the crop/compose rectangles should successfully result in >> re-configuration of registers which are affected when either source or >> destination dimensions change, set_srcdst_params() is called for this purpose. >> >> Signed-off-by: Archit Taneja <archit@ti.com> >> --- >> drivers/media/platform/ti-vpe/vpe.c | 142 ++++++++++++++++++++++++++++++++++++ >> 1 file changed, 142 insertions(+) >> >> diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c >> index 03a6846..b938590 100644 >> --- a/drivers/media/platform/ti-vpe/vpe.c >> +++ b/drivers/media/platform/ti-vpe/vpe.c >> @@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx *ctx, >> { >> switch (type) { >> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE: >> + case V4L2_BUF_TYPE_VIDEO_OUTPUT: >> return &ctx->q_data[Q_DATA_SRC]; >> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE: >> + case V4L2_BUF_TYPE_VIDEO_CAPTURE: > > I noticed that the querycap implementation is wrong. It reports > V4L2_CAP_VIDEO_M2M instead of V4L2_CAP_VIDEO_M2M_MPLANE. > > This driver is using the multiplanar formats, so the M2M_MPLANE cap should > be set. > > This should be a separate patch. Thanks for pointing this out, I'll make a patch for that. > > BTW, did you test the driver with the v4l2-compliance tool? The latest version > (http://git.linuxtv.org/v4l-utils.git) has m2m support. > I haven't tested it with this yet. > However, if you want to test streaming (the -s option), then you will probably > need to base your kernel on this tree: > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/vb2-part1 I can give it a try. It'll probably take a bit more time to try this out. I'll need to port some minor DRA7x stuff. Kamil, Do you think you have some more time for the m2m pull request? > > That branch contains a pile of fixes for vb2 and without that v4l2-compliance -s > will fail a number of tests. > >> return &ctx->q_data[Q_DATA_DST]; >> default: >> BUG(); >> @@ -1585,6 +1587,143 @@ static int vpe_s_fmt(struct file *file, void *priv, struct v4l2_format *f) >> return set_srcdst_params(ctx); >> } >> >> +static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection *s) >> +{ >> + struct vpe_q_data *q_data; >> + >> + if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) && >> + (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)) >> + return -EINVAL; >> + >> + q_data = get_q_data(ctx, s->type); >> + if (!q_data) >> + return -EINVAL; >> + >> + switch (s->target) { >> + case V4L2_SEL_TGT_COMPOSE: >> + case V4L2_SEL_TGT_COMPOSE_DEFAULT: >> + case V4L2_SEL_TGT_COMPOSE_BOUNDS: >> + /* >> + * COMPOSE target is only valid for capture buffer type, for >> + * output buffer type, assign existing crop parameters to the >> + * selection rectangle >> + */ >> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) { >> + break; >> + } else { > > No need for the 'else' keywork here. > >> + s->r = q_data->c_rect; >> + return 0; >> + } >> + >> + case V4L2_SEL_TGT_CROP: >> + case V4L2_SEL_TGT_CROP_DEFAULT: >> + case V4L2_SEL_TGT_CROP_BOUNDS: >> + /* >> + * CROP target is only valid for output buffer type, for capture >> + * buffer type, assign existing compose parameters to the >> + * selection rectangle >> + */ >> + if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) { >> + break; >> + } else { > > Ditto. Thanks. I'll fix these. I had a minor question about the selection API: Are the V4L2_SET_TGT_CROP/COMPOSE_DEFAULT and the corresponding 'BOUNDS' targets supposed to be used with VIDIOC_S_SELECTION? If so, what's the expect behaviour? Thanks, Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/04/14 12:25, Archit Taneja wrote: > I had a minor question about the selection API: > > Are the V4L2_SET_TGT_CROP/COMPOSE_DEFAULT and the corresponding > 'BOUNDS' targets supposed to be used with VIDIOC_S_SELECTION? If so, > what's the expect behaviour? No, those are read only in practice. So only used with G_SELECTION, never with S_SELECTION. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Archit, > From: Archit Taneja [mailto:archit@ti.com] > Sent: Tuesday, March 04, 2014 12:25 PM > > Hi, > > On Tuesday 04 March 2014 03:10 PM, Hans Verkuil wrote: > > Hi Archit, > > > > On 03/04/14 09:49, Archit Taneja wrote: > >> Add selection ioctl ops. For VPE, cropping makes sense only for the > >> input to VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and > >> composing makes sense only for the output of VPE(or > V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers). > >> > >> For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing > the > >> output in a rectangle within the capture buffer. For the OUTPUT > type, > >> V4L2_SEL_TGT_CROP results in selecting a rectangle region within the > source buffer. > >> > >> Setting the crop/compose rectangles should successfully result in > >> re-configuration of registers which are affected when either source > >> or destination dimensions change, set_srcdst_params() is called for > this purpose. > >> > >> Signed-off-by: Archit Taneja <archit@ti.com> > >> --- > >> drivers/media/platform/ti-vpe/vpe.c | 142 > ++++++++++++++++++++++++++++++++++++ > >> 1 file changed, 142 insertions(+) > >> > >> diff --git a/drivers/media/platform/ti-vpe/vpe.c > >> b/drivers/media/platform/ti-vpe/vpe.c > >> index 03a6846..b938590 100644 > >> --- a/drivers/media/platform/ti-vpe/vpe.c > >> +++ b/drivers/media/platform/ti-vpe/vpe.c > >> @@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct > vpe_ctx *ctx, > >> { > >> switch (type) { > >> case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE: > >> + case V4L2_BUF_TYPE_VIDEO_OUTPUT: > >> return &ctx->q_data[Q_DATA_SRC]; > >> case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE: > >> + case V4L2_BUF_TYPE_VIDEO_CAPTURE: > > > > I noticed that the querycap implementation is wrong. It reports > > V4L2_CAP_VIDEO_M2M instead of V4L2_CAP_VIDEO_M2M_MPLANE. > > > > This driver is using the multiplanar formats, so the M2M_MPLANE cap > > should be set. > > > > This should be a separate patch. > > Thanks for pointing this out, I'll make a patch for that. > > > > > BTW, did you test the driver with the v4l2-compliance tool? The > latest > > version > > (http://git.linuxtv.org/v4l-utils.git) has m2m support. > > > > I haven't tested it with this yet. > > > However, if you want to test streaming (the -s option), then you will > > probably need to base your kernel on this tree: > > > > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/vb2 > > -part1 > > I can give it a try. It'll probably take a bit more time to try this > out. I'll need to port some minor DRA7x stuff. > > Kamil, > > Do you think you have some more time for the m2m pull request? Yes, I would like to send the final pull request at the beginning of the coming week. > > > > That branch contains a pile of fixes for vb2 and without that > > v4l2-compliance -s will fail a number of tests. > > > >> return &ctx->q_data[Q_DATA_DST]; > >> default: > >> BUG(); > >> @@ -1585,6 +1587,143 @@ static int vpe_s_fmt(struct file *file, void > *priv, struct v4l2_format *f) > >> return set_srcdst_params(ctx); > >> } > >> > >> +static int __vpe_try_selection(struct vpe_ctx *ctx, struct > >> +v4l2_selection *s) { > >> + struct vpe_q_data *q_data; > >> + > >> + if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) && > >> + (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)) > >> + return -EINVAL; > >> + > >> + q_data = get_q_data(ctx, s->type); > >> + if (!q_data) > >> + return -EINVAL; > >> + > >> + switch (s->target) { > >> + case V4L2_SEL_TGT_COMPOSE: > >> + case V4L2_SEL_TGT_COMPOSE_DEFAULT: > >> + case V4L2_SEL_TGT_COMPOSE_BOUNDS: > >> + /* > >> + * COMPOSE target is only valid for capture buffer type, > for > >> + * output buffer type, assign existing crop parameters to > the > >> + * selection rectangle > >> + */ > >> + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) { > >> + break; > >> + } else { > > > > No need for the 'else' keywork here. > > > >> + s->r = q_data->c_rect; > >> + return 0; > >> + } > >> + > >> + case V4L2_SEL_TGT_CROP: > >> + case V4L2_SEL_TGT_CROP_DEFAULT: > >> + case V4L2_SEL_TGT_CROP_BOUNDS: > >> + /* > >> + * CROP target is only valid for output buffer type, for > capture > >> + * buffer type, assign existing compose parameters to the > >> + * selection rectangle > >> + */ > >> + if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) { > >> + break; > >> + } else { > > > > Ditto. > > > Thanks. I'll fix these. > > I had a minor question about the selection API: > > Are the V4L2_SET_TGT_CROP/COMPOSE_DEFAULT and the corresponding > 'BOUNDS' > targets supposed to be used with VIDIOC_S_SELECTION? If so, what's the > expect behaviour? > > Thanks, > Archit Best wishes,
Hi Hans, On Tuesday 04 March 2014 05:05 PM, Hans Verkuil wrote: > On 03/04/14 12:25, Archit Taneja wrote: >> I had a minor question about the selection API: >> >> Are the V4L2_SET_TGT_CROP/COMPOSE_DEFAULT and the corresponding >> 'BOUNDS' targets supposed to be used with VIDIOC_S_SELECTION? If so, >> what's the expect behaviour? > > No, those are read only in practice. So only used with G_SELECTION, never > with S_SELECTION. <snip> I tried the v4l2-compliance thing. It's awesome! And a bit annoying too when it comes to fixing little things needed for compliance :). But it's required, and I hope to fix these eventually. After a few small fixes in the driver, I get the results as below. I am debugging the cause of try_fmt and s_fmt failures. I'm not sure why the streaming test fails with MMAP, the logs of my driver show that a successful mem2mem transaction happened. I tried this on the 'vb2-part1' branch as you suggested. Do you think I can go ahead with posting the v3 patch set for 3.15, and work on fixing the compliance issue for the -rc fixes? Thanks, Archit # ./utils/v4l2-compliance/v4l2-compliance -v --streaming=10 root@localhost:~/source_trees/v4l-utils# Driver Info: Driver name : vpe Card type : vpe Bus info : platform:vpe Driver version: 3.14.0 Capabilities : 0x84004000 Video Memory-to-Memory Multiplanar Streaming Device Capabilities Device Caps : 0x04004000 Video Memory-to-Memory Multiplanar Streaming Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Control ioctls: info: checking v4l2_queryctrl of control 'User Controls' (0x00980001) info: checking v4l2_queryctrl of control 'Buffers Per Transaction' (0x00981950) info: checking v4l2_queryctrl of control 'Buffers Per Transaction' (0x08000000) test VIDIOC_QUERYCTRL/MENU: OK info: checking control 'User Controls' (0x00980001) info: checking control 'Buffers Per Transaction' (0x00981950) test VIDIOC_G/S_CTRL: OK info: checking extended control 'User Controls' (0x00980001) info: checking extended control 'Buffers Per Transaction' (0x00981950) test VIDIOC_G/S/TRY_EXT_CTRLS: OK info: checking control event 'User Controls' (0x00980001) info: checking control event 'Buffers Per Transaction' (0x00981950) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 1 Private Controls: 1 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) Format ioctls: info: found 8 formats for buftype 9 info: found 4 formats for buftype 10 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK (Not Supported) test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK fail: v4l2-test-formats.cpp(614): Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT test VIDIOC_TRY_FMT: FAIL warn: v4l2-test-formats.cpp(834): S_FMT cannot handle an invalid pixelformat. warn: v4l2-test-formats.cpp(835): This may or may not be a problem. For more information see: warn: v4l2-test-formats.cpp(836): http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html fail: v4l2-test-formats.cpp(420): pix_mp.reserved not zeroed fail: v4l2-test-formats.cpp(851): Video Capture Multiplanar is valid, but no S_FMT was implemented test VIDIOC_S_FMT: FAIL test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: info: test buftype Video Capture Multiplanar warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS not supported info: test buftype Video Output Multiplanar warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS not supported test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK (Not Supported) test read/write: OK (Not Supported) Video Capture Multiplanar (polling): Buffer: 0 Sequence: 0 Field: Top Timestamp: 113.178208s fail: v4l2-test-buffers.cpp(222): buf.field != cur_fmt.fmt.pix.field fail: v4l2-test-buffers.cpp(630): checkQueryBuf(node, buf, bufs.type, bufs.memory, buf.index, Dequeued, last_seq) fail: v4l2-test-buffers.cpp(1038): captureBufs(node, bufs, m2m_bufs, frame_count, true) test MMAP: FAIL test USERPTR: OK (Not Supported) test DMABUF: Cannot test, specify --expbuf-device Total: 40, Succeeded: 37, Failed: 3, Warnings: 5 [1]+ Exit 1 ./utils/v4l2-compliance/v4l2-compliance -v --streaming=10 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/07/2014 12:50 PM, Archit Taneja wrote: > Hi Hans, > > On Tuesday 04 March 2014 05:05 PM, Hans Verkuil wrote: >> On 03/04/14 12:25, Archit Taneja wrote: >>> I had a minor question about the selection API: >>> >>> Are the V4L2_SET_TGT_CROP/COMPOSE_DEFAULT and the corresponding >>> 'BOUNDS' targets supposed to be used with VIDIOC_S_SELECTION? If so, >>> what's the expect behaviour? >> >> No, those are read only in practice. So only used with G_SELECTION, never >> with S_SELECTION. > > <snip> > > I tried the v4l2-compliance thing. It's awesome! And a bit annoying too > when it comes to fixing little things needed for compliance :). But it's > required, and I hope to fix these eventually. > > After a few small fixes in the driver, I get the results as below. I am > debugging the cause of try_fmt and s_fmt failures. I'm not sure why the > streaming test fails with MMAP, the logs of my driver show that a > successful mem2mem transaction happened. > > I tried this on the 'vb2-part1' branch as you suggested. > > Do you think I can go ahead with posting the v3 patch set for 3.15, and > work on fixing the compliance issue for the -rc fixes? It's fine to upstream this in staging, but while not all compliance errors are fixed it can't go to drivers/media. I'm tightening the screws on that since v4l2-compliance is getting to be such a powerful tool for ensuring the driver complies. > > Thanks, > Archit > > # ./utils/v4l2-compliance/v4l2-compliance -v --streaming=10 > root@localhost:~/source_trees/v4l-utils# Driver Info: > Driver name : vpe > Card type : vpe > Bus info : platform:vpe > Driver version: 3.14.0 > Capabilities : 0x84004000 > Video Memory-to-Memory Multiplanar > Streaming > Device Capabilities > Device Caps : 0x04004000 > Video Memory-to-Memory Multiplanar > Streaming > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK (Not Supported) > > Input ioctls: > test VIDIOC_G/S_TUNER: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 0 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Control ioctls: > info: checking v4l2_queryctrl of control 'User > Controls' (0x00980001) > info: checking v4l2_queryctrl of control 'Buffers Per > Transaction' (0x00981950) > info: checking v4l2_queryctrl of control 'Buffers Per > Transaction' (0x08000000) > test VIDIOC_QUERYCTRL/MENU: OK > info: checking control 'User Controls' (0x00980001) > info: checking control 'Buffers Per Transaction' > (0x00981950) > test VIDIOC_G/S_CTRL: OK > info: checking extended control 'User Controls' > (0x00980001) > info: checking extended control 'Buffers Per > Transaction' (0x00981950) > test VIDIOC_G/S/TRY_EXT_CTRLS: OK > info: checking control event 'User Controls' (0x00980001) > info: checking control event 'Buffers Per Transaction' > (0x00981950) > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 1 Private Controls: 1 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > > Format ioctls: > info: found 8 formats for buftype 9 > info: found 4 formats for buftype 10 > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > test VIDIOC_G/S_PARM: OK (Not Supported) > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > fail: v4l2-test-formats.cpp(614): Video Capture > Multiplanar: TRY_FMT(G_FMT) != G_FMT > test VIDIOC_TRY_FMT: FAIL > warn: v4l2-test-formats.cpp(834): S_FMT cannot handle > an invalid pixelformat. > warn: v4l2-test-formats.cpp(835): This may or may not > be a problem. For more information see: > warn: v4l2-test-formats.cpp(836): > http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html > fail: v4l2-test-formats.cpp(420): pix_mp.reserved not > zeroed This is easy enough to fix. > fail: v4l2-test-formats.cpp(851): Video Capture > Multiplanar is valid, but no S_FMT was implemented For the FMT things: run with -T: that gives nice traces. You can also set the debug flag: echo 2 >/sys/class/video4linux/video0/debug to see all ioctls in more detail. > test VIDIOC_S_FMT: FAIL > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > > Codec ioctls: > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls: > info: test buftype Video Capture Multiplanar > warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS > not supported > info: test buftype Video Output Multiplanar > warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS > not supported > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > test VIDIOC_EXPBUF: OK (Not Supported) > test read/write: OK (Not Supported) > Video Capture Multiplanar (polling): > Buffer: 0 Sequence: 0 Field: Top Timestamp: 113.178208s > fail: v4l2-test-buffers.cpp(222): buf.field != > cur_fmt.fmt.pix.field Definitely needs to be fixed, you probably just don't set the field at all. > fail: v4l2-test-buffers.cpp(630): checkQueryBuf(node, > buf, bufs.type, bufs.memory, buf.index, Dequeued, last_seq) > fail: v4l2-test-buffers.cpp(1038): captureBufs(node, > bufs, m2m_bufs, frame_count, true) > test MMAP: FAIL > test USERPTR: OK (Not Supported) > test DMABUF: Cannot test, specify --expbuf-device > > Total: 40, Succeeded: 37, Failed: 3, Warnings: 5 > > [1]+ Exit 1 ./utils/v4l2-compliance/v4l2-compliance -v > --streaming=10 Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Friday 07 March 2014 06:29 PM, Hans Verkuil wrote: >> >> Do you think I can go ahead with posting the v3 patch set for 3.15, and >> work on fixing the compliance issue for the -rc fixes? > > It's fine to upstream this in staging, but while not all compliance errors > are fixed it can't go to drivers/media. I'm tightening the screws on that > since v4l2-compliance is getting to be such a powerful tool for ensuring > the driver complies. > But the vpe driver is already in drivers/media. How do I push these patches if the vpe drivers is not in staging? <snip> >> Multiplanar: TRY_FMT(G_FMT) != G_FMT >> test VIDIOC_TRY_FMT: FAIL >> warn: v4l2-test-formats.cpp(834): S_FMT cannot handle >> an invalid pixelformat. >> warn: v4l2-test-formats.cpp(835): This may or may not >> be a problem. For more information see: >> warn: v4l2-test-formats.cpp(836): >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html >> fail: v4l2-test-formats.cpp(420): pix_mp.reserved not >> zeroed > > This is easy enough to fix. > >> fail: v4l2-test-formats.cpp(851): Video Capture >> Multiplanar is valid, but no S_FMT was implemented > > For the FMT things: run with -T: that gives nice traces. You can also > set the debug flag: echo 2 >/sys/class/video4linux/video0/debug to see all > ioctls in more detail. Thanks for the tip, will try this. > >> test VIDIOC_S_FMT: FAIL >> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) >> >> Codec ioctls: >> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) >> test VIDIOC_G_ENC_INDEX: OK (Not Supported) >> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) >> >> Buffer ioctls: >> info: test buftype Video Capture Multiplanar >> warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS >> not supported >> info: test buftype Video Output Multiplanar >> warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS >> not supported >> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK >> test VIDIOC_EXPBUF: OK (Not Supported) >> test read/write: OK (Not Supported) >> Video Capture Multiplanar (polling): >> Buffer: 0 Sequence: 0 Field: Top Timestamp: 113.178208s >> fail: v4l2-test-buffers.cpp(222): buf.field != >> cur_fmt.fmt.pix.field > > Definitely needs to be fixed, you probably just don't set the field at all. The VPE output is always progressive. But yes, I should still set the field parameter to something. Thanks, Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/07/2014 02:22 PM, Archit Taneja wrote: > Hi, > > On Friday 07 March 2014 06:29 PM, Hans Verkuil wrote: >>> >>> Do you think I can go ahead with posting the v3 patch set for 3.15, and >>> work on fixing the compliance issue for the -rc fixes? >> >> It's fine to upstream this in staging, but while not all compliance errors >> are fixed it can't go to drivers/media. I'm tightening the screws on that >> since v4l2-compliance is getting to be such a powerful tool for ensuring >> the driver complies. >> > > But the vpe driver is already in drivers/media. How do I push these > patches if the vpe drivers is not in staging? Oops, sorry. I got confused with Benoit's AM437x ti-vpfe patch :-) Disregard what I said, it's OK to upstream it. But if you could just spend some hours fixing the problems, that would really be best. > > <snip> > >>> Multiplanar: TRY_FMT(G_FMT) != G_FMT >>> test VIDIOC_TRY_FMT: FAIL >>> warn: v4l2-test-formats.cpp(834): S_FMT cannot handle >>> an invalid pixelformat. >>> warn: v4l2-test-formats.cpp(835): This may or may not >>> be a problem. For more information see: >>> warn: v4l2-test-formats.cpp(836): >>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html >>> fail: v4l2-test-formats.cpp(420): pix_mp.reserved not >>> zeroed >> >> This is easy enough to fix. >> >>> fail: v4l2-test-formats.cpp(851): Video Capture >>> Multiplanar is valid, but no S_FMT was implemented >> >> For the FMT things: run with -T: that gives nice traces. You can also >> set the debug flag: echo 2 >/sys/class/video4linux/video0/debug to see all >> ioctls in more detail. > > Thanks for the tip, will try this. > >> >>> test VIDIOC_S_FMT: FAIL >>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) >>> >>> Codec ioctls: >>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) >>> test VIDIOC_G_ENC_INDEX: OK (Not Supported) >>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) >>> >>> Buffer ioctls: >>> info: test buftype Video Capture Multiplanar >>> warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS >>> not supported >>> info: test buftype Video Output Multiplanar >>> warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS >>> not supported >>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK >>> test VIDIOC_EXPBUF: OK (Not Supported) >>> test read/write: OK (Not Supported) >>> Video Capture Multiplanar (polling): >>> Buffer: 0 Sequence: 0 Field: Top Timestamp: 113.178208s >>> fail: v4l2-test-buffers.cpp(222): buf.field != >>> cur_fmt.fmt.pix.field >> >> Definitely needs to be fixed, you probably just don't set the field at all. > > The VPE output is always progressive. But yes, I should still set the > field parameter to something. V4L2_FIELD_NONE is the correct field setting for that. Regards, Hans > > Thanks, > Archit > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 07 March 2014 07:02 PM, Hans Verkuil wrote: > On 03/07/2014 02:22 PM, Archit Taneja wrote: >> Hi, >> >> On Friday 07 March 2014 06:29 PM, Hans Verkuil wrote: >>>> >>>> Do you think I can go ahead with posting the v3 patch set for 3.15, and >>>> work on fixing the compliance issue for the -rc fixes? >>> >>> It's fine to upstream this in staging, but while not all compliance errors >>> are fixed it can't go to drivers/media. I'm tightening the screws on that >>> since v4l2-compliance is getting to be such a powerful tool for ensuring >>> the driver complies. >>> >> >> But the vpe driver is already in drivers/media. How do I push these >> patches if the vpe drivers is not in staging? > > Oops, sorry. I got confused with Benoit's AM437x ti-vpfe patch :-) > > Disregard what I said, it's OK to upstream it. But if you could just spend > some hours fixing the problems, that would really be best. Sure, I'll try to fix these issues and then post a v3. > >> >> <snip> >> >>>> Multiplanar: TRY_FMT(G_FMT) != G_FMT >>>> test VIDIOC_TRY_FMT: FAIL >>>> warn: v4l2-test-formats.cpp(834): S_FMT cannot handle >>>> an invalid pixelformat. >>>> warn: v4l2-test-formats.cpp(835): This may or may not >>>> be a problem. For more information see: >>>> warn: v4l2-test-formats.cpp(836): >>>> http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html >>>> fail: v4l2-test-formats.cpp(420): pix_mp.reserved not >>>> zeroed >>> >>> This is easy enough to fix. >>> >>>> fail: v4l2-test-formats.cpp(851): Video Capture >>>> Multiplanar is valid, but no S_FMT was implemented >>> >>> For the FMT things: run with -T: that gives nice traces. You can also >>> set the debug flag: echo 2 >/sys/class/video4linux/video0/debug to see all >>> ioctls in more detail. >> >> Thanks for the tip, will try this. >> >>> >>>> test VIDIOC_S_FMT: FAIL >>>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) >>>> >>>> Codec ioctls: >>>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) >>>> test VIDIOC_G_ENC_INDEX: OK (Not Supported) >>>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) >>>> >>>> Buffer ioctls: >>>> info: test buftype Video Capture Multiplanar >>>> warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS >>>> not supported >>>> info: test buftype Video Output Multiplanar >>>> warn: v4l2-test-buffers.cpp(403): VIDIOC_CREATE_BUFS >>>> not supported >>>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK >>>> test VIDIOC_EXPBUF: OK (Not Supported) >>>> test read/write: OK (Not Supported) >>>> Video Capture Multiplanar (polling): >>>> Buffer: 0 Sequence: 0 Field: Top Timestamp: 113.178208s >>>> fail: v4l2-test-buffers.cpp(222): buf.field != >>>> cur_fmt.fmt.pix.field >>> >>> Definitely needs to be fixed, you probably just don't set the field at all. >> >> The VPE output is always progressive. But yes, I should still set the >> field parameter to something. > > V4L2_FIELD_NONE is the correct field setting for that. I checked the driver, it isn't setting it to V4L2_FIELD_NONE. Will fix this. Archit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c index 03a6846..b938590 100644 --- a/drivers/media/platform/ti-vpe/vpe.c +++ b/drivers/media/platform/ti-vpe/vpe.c @@ -410,8 +410,10 @@ static struct vpe_q_data *get_q_data(struct vpe_ctx *ctx, { switch (type) { case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE: + case V4L2_BUF_TYPE_VIDEO_OUTPUT: return &ctx->q_data[Q_DATA_SRC]; case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE: + case V4L2_BUF_TYPE_VIDEO_CAPTURE: return &ctx->q_data[Q_DATA_DST]; default: BUG(); @@ -1585,6 +1587,143 @@ static int vpe_s_fmt(struct file *file, void *priv, struct v4l2_format *f) return set_srcdst_params(ctx); } +static int __vpe_try_selection(struct vpe_ctx *ctx, struct v4l2_selection *s) +{ + struct vpe_q_data *q_data; + + if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) && + (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)) + return -EINVAL; + + q_data = get_q_data(ctx, s->type); + if (!q_data) + return -EINVAL; + + switch (s->target) { + case V4L2_SEL_TGT_COMPOSE: + case V4L2_SEL_TGT_COMPOSE_DEFAULT: + case V4L2_SEL_TGT_COMPOSE_BOUNDS: + /* + * COMPOSE target is only valid for capture buffer type, for + * output buffer type, assign existing crop parameters to the + * selection rectangle + */ + if (s->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) { + break; + } else { + s->r = q_data->c_rect; + return 0; + } + + case V4L2_SEL_TGT_CROP: + case V4L2_SEL_TGT_CROP_DEFAULT: + case V4L2_SEL_TGT_CROP_BOUNDS: + /* + * CROP target is only valid for output buffer type, for capture + * buffer type, assign existing compose parameters to the + * selection rectangle + */ + if (s->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) { + break; + } else { + s->r = q_data->c_rect; + return 0; + } + default: + return -EINVAL; + } + + if (s->r.top < 0 || s->r.left < 0) { + vpe_err(ctx->dev, "negative values for top and left\n"); + s->r.top = s->r.left = 0; + } + + v4l_bound_align_image(&s->r.width, MIN_W, q_data->width, 1, + &s->r.height, MIN_H, q_data->height, H_ALIGN, S_ALIGN); + + /* adjust left/top if cropping rectangle is out of bounds */ + if (s->r.left + s->r.width > q_data->width) + s->r.left = q_data->width - s->r.width; + if (s->r.top + s->r.height > q_data->height) + s->r.top = q_data->height - s->r.height; + + return 0; +} + +static int vpe_g_selection(struct file *file, void *fh, + struct v4l2_selection *s) +{ + struct vpe_ctx *ctx = file2ctx(file); + struct vpe_q_data *q_data; + + if ((s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE) && + (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT)) + return -EINVAL; + + q_data = get_q_data(ctx, s->type); + if (!q_data) + return -EINVAL; + + switch (s->target) { + /* return width and height from S_FMT of the respective buffer type */ + case V4L2_SEL_TGT_COMPOSE_DEFAULT: + case V4L2_SEL_TGT_COMPOSE_BOUNDS: + case V4L2_SEL_TGT_CROP_BOUNDS: + case V4L2_SEL_TGT_CROP_DEFAULT: + s->r.left = 0; + s->r.top = 0; + s->r.width = q_data->width; + s->r.height = q_data->height; + return 0; + + /* + * CROP target holds for the output buffer type, and COMPOSE target + * holds for the capture buffer type. We still return the c_rect params + * for both the target types. + */ + case V4L2_SEL_TGT_COMPOSE: + case V4L2_SEL_TGT_CROP: + s->r.left = q_data->c_rect.left; + s->r.top = q_data->c_rect.top; + s->r.width = q_data->c_rect.width; + s->r.height = q_data->c_rect.height; + return 0; + } + + return -EINVAL; +} + + +static int vpe_s_selection(struct file *file, void *fh, + struct v4l2_selection *s) +{ + struct vpe_ctx *ctx = file2ctx(file); + struct vpe_q_data *q_data; + struct v4l2_selection sel = *s; + int ret; + + ret = __vpe_try_selection(ctx, &sel); + if (ret) + return ret; + + q_data = get_q_data(ctx, sel.type); + if (!q_data) + return -EINVAL; + + if ((q_data->c_rect.left == sel.r.left) && + (q_data->c_rect.top == sel.r.top) && + (q_data->c_rect.width == sel.r.width) && + (q_data->c_rect.height == sel.r.height)) { + vpe_dbg(ctx->dev, + "requested crop/compose values are already set\n"); + return 0; + } + + q_data->c_rect = sel.r; + + return set_srcdst_params(ctx); +} + static int vpe_reqbufs(struct file *file, void *priv, struct v4l2_requestbuffers *reqbufs) { @@ -1672,6 +1811,9 @@ 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_g_selection = vpe_g_selection, + .vidioc_s_selection = vpe_s_selection, + .vidioc_reqbufs = vpe_reqbufs, .vidioc_querybuf = vpe_querybuf,
Add selection ioctl ops. For VPE, cropping makes sense only for the input to VPE(or V4L2_BUF_TYPE_VIDEO_OUTPUT/MPLANE buffers) and composing makes sense only for the output of VPE(or V4L2_BUF_TYPE_VIDEO_CAPTURE/MPLANE buffers). For the CAPTURE type, V4L2_SEL_TGT_COMPOSE results in VPE writing the output in a rectangle within the capture buffer. For the OUTPUT type, V4L2_SEL_TGT_CROP results in selecting a rectangle region within the source buffer. Setting the crop/compose rectangles should successfully result in re-configuration of registers which are affected when either source or destination dimensions change, set_srcdst_params() is called for this purpose. Signed-off-by: Archit Taneja <archit@ti.com> --- drivers/media/platform/ti-vpe/vpe.c | 142 ++++++++++++++++++++++++++++++++++++ 1 file changed, 142 insertions(+)