Message ID | CAKnK67SK+CKBL-Dx0V0nyYtEWN3wp3D90M9irFCQOmqiX2fKPw@mail.gmail.com (mailing list archive) |
---|---|
State | Changes Requested, archived |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1SKatj-0003p3-1O for patchwork@linuxtv.org; Wed, 18 Apr 2012 21:50:39 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtp for <patchwork@linuxtv.org> id 1SKati-0001Zk-Ai; Wed, 18 Apr 2012 21:50:38 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753123Ab2DRTuf (ORCPT <rfc822;patchwork@linuxtv.org>); Wed, 18 Apr 2012 15:50:35 -0400 Received: from na3sys009aog119.obsmtp.com ([74.125.149.246]:58632 "EHLO na3sys009aog119.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752660Ab2DRTuf (ORCPT <rfc822;linux-media@vger.kernel.org>); Wed, 18 Apr 2012 15:50:35 -0400 Received: from mail-qc0-f174.google.com ([209.85.216.174]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKT48bCh6GoPKLB9OYicpweYbeQOgG9UuZ@postini.com; Wed, 18 Apr 2012 12:50:35 PDT Received: by qcro28 with SMTP id o28so4757864qcr.19 for <linux-media@vger.kernel.org>; Wed, 18 Apr 2012 12:50:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=SgHMpV0LTcsSkyOwMP0gg/jkTSsXVjo1w2Ryq0ae3e8=; b=DgrJIGSoZFPmmR66IB7PJCHiRlj1fnH4VPvYSLbCd+AZqa9X8DYc5uIHUjFJGK1hhf b22N3tsxKdqeA9Tn2yqm/sJhw3cQSvEC3p5Rgo6mm3jwgz+nHUIl/qgNcg6dBKWVuHFo qvMNaY/6G2KksIHKabDw9tD1nEykVFCzIHI+bYxIQ8PPWMI05L3SeN2AZIzFn2LrcHW7 rzwLqgSVVwaRwpe40MCu0Yxhr7WXXUwDV3upLVi8sdCafpeqxcgRv1J1s6SIVl3vcz9X jYP3VD+S8HnIazpaXZXgWH4vt2N5r3Aiql+p/XUes/N2ZCYGJp/wjoG2CVoY1pu8RNrx qqiw== Received: by 10.224.223.81 with SMTP id ij17mr5286457qab.97.1334778153995; Wed, 18 Apr 2012 12:42:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.74.130 with HTTP; Wed, 18 Apr 2012 12:42:12 -0700 (PDT) From: "Aguirre, Sergio" <saaguirre@ti.com> Date: Wed, 18 Apr 2012 14:42:12 -0500 Message-ID: <CAKnK67SK+CKBL-Dx0V0nyYtEWN3wp3D90M9irFCQOmqiX2fKPw@mail.gmail.com> Subject: [PATCH] v4l: soc-camera: Add support for enum_frameintervals ioctl To: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Cc: Linux Media Mailing List <linux-media@vger.kernel.org> Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnQiZAwJb7b95i2xr4TIrbrH+3U23igzfmhodvhmveeUx/gOpNde1RbYgQj0NspLHb8NDvZ Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.4.18.194218 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MSGID_ADDED_BY_MTA 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DATE_TZ_NEG_0500 0, URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS ' |
Commit Message
Aguirre Rodriguez, Sergio Alberto
April 18, 2012, 7:42 p.m. UTC
From: Sergio Aguirre <saaguirre@ti.com> Signed-off-by: Sergio Aguirre <saaguirre@ti.com> --- drivers/media/video/soc_camera.c | 37 +++++++++++++++++++++++++++++++++++++ include/media/soc_camera.h | 1 + 2 files changed, 38 insertions(+), 0 deletions(-)
Comments
Hi Sergio Sorry about the delay. On Wed, 18 Apr 2012, Aguirre, Sergio wrote: > From: Sergio Aguirre <saaguirre@ti.com> > > Signed-off-by: Sergio Aguirre <saaguirre@ti.com> > --- > drivers/media/video/soc_camera.c | 37 +++++++++++++++++++++++++++++++++++++ > include/media/soc_camera.h | 1 + > 2 files changed, 38 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c > index eb25756..62c8956 100644 > --- a/drivers/media/video/soc_camera.c > +++ b/drivers/media/video/soc_camera.c > @@ -266,6 +266,15 @@ static int soc_camera_enum_fsizes(struct file > *file, void *fh, > return ici->ops->enum_fsizes(icd, fsize); > } > > +static int soc_camera_enum_fivals(struct file *file, void *fh, "fivals" is a bit short for my taste. Yes, I know about the *_enum_fsizes() precedent in soc_camera.c, we should have used a more descriptive name for that too. So, maybe I'll push a patch to change that to enum_frmsizes() or enum_framesizes(). But that brings in a larger question, which is also the reason, why I added a couple more people to the CC: the following 3 operations in struct v4l2_subdev_video_ops don't make me particularly happy: int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum *fsize); int (*enum_frameintervals)(struct v4l2_subdev *sd, struct v4l2_frmivalenum *fival); int (*enum_mbus_fsizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum *fsize); The problems are: 1. enum_framesizes and enum_mbus_fsizes seem to be identical (yes, I see my Sob under the latter:-() 2. both struct v4l2_frmsizeenum and struct v4l2_frmivalenum are the structs, used in the respective V4L2 ioctl()s, and they both contain a field for a fourcc value, which doesn't make sense to subdevice drivers. So far the only driver combination in the mainline, that I see, that uses these operations is marvell-ccic & ov7670. These drivers just ignore the pixel format. Relatively recently enum_mbus_fsizes() has been added to soc-camera, and this patch is adding enum_frameintervals(). Both these implementations abuse the .pixel_format field to pass a media-bus code value in it to subdevice drivers. This sends meaningful information to subdevice drivers, but is really a hack, rather than a proper implementation. Any idea how to improve this? Shall we create mediabus clones of those structs with an mbus code instead of fourcc, and drop one of the above enum_framesizes() operations? Thanks Guennadi > + struct v4l2_frmivalenum *fival) > +{ > + struct soc_camera_device *icd = file->private_data; > + struct soc_camera_host *ici = to_soc_camera_host(icd->parent); > + > + return ici->ops->enum_fivals(icd, fival); > +} > + > static int soc_camera_reqbufs(struct file *file, void *priv, > struct v4l2_requestbuffers *p) > { > @@ -1266,6 +1275,31 @@ static int default_enum_fsizes(struct > soc_camera_device *icd, > return 0; > } > > +static int default_enum_fivals(struct soc_camera_device *icd, > + struct v4l2_frmivalenum *fival) > +{ > + int ret; > + struct v4l2_subdev *sd = soc_camera_to_subdev(icd); > + const struct soc_camera_format_xlate *xlate; > + __u32 pixfmt = fival->pixel_format; > + struct v4l2_frmivalenum fival_sd = *fival; > + > + xlate = soc_camera_xlate_by_fourcc(icd, pixfmt); > + if (!xlate) > + return -EINVAL; > + /* map xlate-code to pixel_format, sensor only handle xlate-code*/ > + fival_sd.pixel_format = xlate->code; > + > + ret = v4l2_subdev_call(sd, video, enum_frameintervals, &fival_sd); > + if (ret < 0) > + return ret; > + > + *fival = fival_sd; > + fival->pixel_format = pixfmt; > + > + return 0; > +} > + > int soc_camera_host_register(struct soc_camera_host *ici) > { > struct soc_camera_host *ix; > @@ -1297,6 +1331,8 @@ int soc_camera_host_register(struct soc_camera_host *ici) > ici->ops->get_parm = default_g_parm; > if (!ici->ops->enum_fsizes) > ici->ops->enum_fsizes = default_enum_fsizes; > + if (!ici->ops->enum_fivals) > + ici->ops->enum_fivals = default_enum_fivals; > > mutex_lock(&list_lock); > list_for_each_entry(ix, &hosts, list) { > @@ -1387,6 +1423,7 @@ static const struct v4l2_ioctl_ops > soc_camera_ioctl_ops = { > .vidioc_s_std = soc_camera_s_std, > .vidioc_g_std = soc_camera_g_std, > .vidioc_enum_framesizes = soc_camera_enum_fsizes, > + .vidioc_enum_frameintervals = soc_camera_enum_fivals, > .vidioc_reqbufs = soc_camera_reqbufs, > .vidioc_querybuf = soc_camera_querybuf, > .vidioc_qbuf = soc_camera_qbuf, > diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h > index b5c2b6c..0a3ac07 100644 > --- a/include/media/soc_camera.h > +++ b/include/media/soc_camera.h > @@ -98,6 +98,7 @@ struct soc_camera_host_ops { > int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *); > int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *); > int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum *); > + int (*enum_fivals)(struct soc_camera_device *, struct v4l2_frmivalenum *); > unsigned int (*poll)(struct file *, poll_table *); > }; > > -- > 1.7.5.4 > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Guennadi, No problem. On Fri, May 4, 2012 at 10:05 AM, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > Hi Sergio > > Sorry about the delay. > > On Wed, 18 Apr 2012, Aguirre, Sergio wrote: > >> From: Sergio Aguirre <saaguirre@ti.com> >> >> Signed-off-by: Sergio Aguirre <saaguirre@ti.com> >> --- >> drivers/media/video/soc_camera.c | 37 +++++++++++++++++++++++++++++++++++++ >> include/media/soc_camera.h | 1 + >> 2 files changed, 38 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c >> index eb25756..62c8956 100644 >> --- a/drivers/media/video/soc_camera.c >> +++ b/drivers/media/video/soc_camera.c >> @@ -266,6 +266,15 @@ static int soc_camera_enum_fsizes(struct file >> *file, void *fh, >> return ici->ops->enum_fsizes(icd, fsize); >> } >> >> +static int soc_camera_enum_fivals(struct file *file, void *fh, > > "fivals" is a bit short for my taste. Yes, I know about the > *_enum_fsizes() precedent in soc_camera.c, we should have used a more > descriptive name for that too. So, maybe I'll push a patch to change that > to enum_frmsizes() or enum_framesizes(). Agreed. > > But that brings in a larger question, which is also the reason, why I > added a couple more people to the CC: the following 3 operations in struct > v4l2_subdev_video_ops don't make me particularly happy: > > int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum *fsize); > int (*enum_frameintervals)(struct v4l2_subdev *sd, struct v4l2_frmivalenum *fival); > int (*enum_mbus_fsizes)(struct v4l2_subdev *sd, > struct v4l2_frmsizeenum *fsize); > > The problems are: > > 1. enum_framesizes and enum_mbus_fsizes seem to be identical (yes, I see > my Sob under the latter:-() Yeah, IMHO, the mbus one should go, since there's no mbus specific structure being handed as a parameter. > 2. both struct v4l2_frmsizeenum and struct v4l2_frmivalenum are the > structs, used in the respective V4L2 ioctl()s, and they both contain a > field for a fourcc value, which doesn't make sense to subdevice drivers. > So far the only driver combination in the mainline, that I see, that uses > these operations is marvell-ccic & ov7670. These drivers just ignore the > pixel format. Relatively recently enum_mbus_fsizes() has been added to > soc-camera, and this patch is adding enum_frameintervals(). Both these > implementations abuse the .pixel_format field to pass a media-bus code > value in it to subdevice drivers. This sends meaningful information to > subdevice drivers, but is really a hack, rather than a proper > implementation. True. > > Any idea how to improve this? Shall we create mediabus clones of those > structs with an mbus code instead of fourcc, and drop one of the above > enum_framesizes() operations? Well, to add more confusion to this.. :) We have this v4l2-subdev IOCTLs exported to userspace: #define VIDIOC_SUBDEV_ENUM_FRAME_SIZE \ _IOWR('V', 74, struct v4l2_subdev_frame_size_enum) #define VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL \ _IOWR('V', 75, struct v4l2_subdev_frame_interval_enum) Which in "drivers/media/video/v4l2-subdev.c", are translated to pad ops: - v4l2_subdev_call(... enum_frame_size ...); - v4l2_subdev_call(... enum_frame_interval ...); respectively. So, this is also another thing that's causing some confusion. Does soc_camera use pad ops? Regards, Sergio > > Thanks > Guennadi > >> + struct v4l2_frmivalenum *fival) >> +{ >> + struct soc_camera_device *icd = file->private_data; >> + struct soc_camera_host *ici = to_soc_camera_host(icd->parent); >> + >> + return ici->ops->enum_fivals(icd, fival); >> +} >> + >> static int soc_camera_reqbufs(struct file *file, void *priv, >> struct v4l2_requestbuffers *p) >> { >> @@ -1266,6 +1275,31 @@ static int default_enum_fsizes(struct >> soc_camera_device *icd, >> return 0; >> } >> >> +static int default_enum_fivals(struct soc_camera_device *icd, >> + struct v4l2_frmivalenum *fival) >> +{ >> + int ret; >> + struct v4l2_subdev *sd = soc_camera_to_subdev(icd); >> + const struct soc_camera_format_xlate *xlate; >> + __u32 pixfmt = fival->pixel_format; >> + struct v4l2_frmivalenum fival_sd = *fival; >> + >> + xlate = soc_camera_xlate_by_fourcc(icd, pixfmt); >> + if (!xlate) >> + return -EINVAL; >> + /* map xlate-code to pixel_format, sensor only handle xlate-code*/ >> + fival_sd.pixel_format = xlate->code; >> + >> + ret = v4l2_subdev_call(sd, video, enum_frameintervals, &fival_sd); >> + if (ret < 0) >> + return ret; >> + >> + *fival = fival_sd; >> + fival->pixel_format = pixfmt; >> + >> + return 0; >> +} >> + >> int soc_camera_host_register(struct soc_camera_host *ici) >> { >> struct soc_camera_host *ix; >> @@ -1297,6 +1331,8 @@ int soc_camera_host_register(struct soc_camera_host *ici) >> ici->ops->get_parm = default_g_parm; >> if (!ici->ops->enum_fsizes) >> ici->ops->enum_fsizes = default_enum_fsizes; >> + if (!ici->ops->enum_fivals) >> + ici->ops->enum_fivals = default_enum_fivals; >> >> mutex_lock(&list_lock); >> list_for_each_entry(ix, &hosts, list) { >> @@ -1387,6 +1423,7 @@ static const struct v4l2_ioctl_ops >> soc_camera_ioctl_ops = { >> .vidioc_s_std = soc_camera_s_std, >> .vidioc_g_std = soc_camera_g_std, >> .vidioc_enum_framesizes = soc_camera_enum_fsizes, >> + .vidioc_enum_frameintervals = soc_camera_enum_fivals, >> .vidioc_reqbufs = soc_camera_reqbufs, >> .vidioc_querybuf = soc_camera_querybuf, >> .vidioc_qbuf = soc_camera_qbuf, >> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h >> index b5c2b6c..0a3ac07 100644 >> --- a/include/media/soc_camera.h >> +++ b/include/media/soc_camera.h >> @@ -98,6 +98,7 @@ struct soc_camera_host_ops { >> int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *); >> int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *); >> int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum *); >> + int (*enum_fivals)(struct soc_camera_device *, struct v4l2_frmivalenum *); >> unsigned int (*poll)(struct file *, poll_table *); >> }; >> >> -- >> 1.7.5.4 >> > > --- > Guennadi Liakhovetski, Ph.D. > Freelance Open-Source Software Developer > http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 4 May 2012, Aguirre, Sergio wrote: > Hi Guennadi, > > No problem. > > On Fri, May 4, 2012 at 10:05 AM, Guennadi Liakhovetski > <g.liakhovetski@gmx.de> wrote: > > Hi Sergio > > > > Sorry about the delay. > > > > On Wed, 18 Apr 2012, Aguirre, Sergio wrote: > > > >> From: Sergio Aguirre <saaguirre@ti.com> > >> > >> Signed-off-by: Sergio Aguirre <saaguirre@ti.com> > >> --- > >> drivers/media/video/soc_camera.c | 37 +++++++++++++++++++++++++++++++++++++ > >> include/media/soc_camera.h | 1 + > >> 2 files changed, 38 insertions(+), 0 deletions(-) > >> > >> diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c > >> index eb25756..62c8956 100644 > >> --- a/drivers/media/video/soc_camera.c > >> +++ b/drivers/media/video/soc_camera.c > >> @@ -266,6 +266,15 @@ static int soc_camera_enum_fsizes(struct file > >> *file, void *fh, > >> return ici->ops->enum_fsizes(icd, fsize); > >> } > >> > >> +static int soc_camera_enum_fivals(struct file *file, void *fh, > > > > "fivals" is a bit short for my taste. Yes, I know about the > > *_enum_fsizes() precedent in soc_camera.c, we should have used a more > > descriptive name for that too. So, maybe I'll push a patch to change that > > to enum_frmsizes() or enum_framesizes(). > > Agreed. > > > > > But that brings in a larger question, which is also the reason, why I > > added a couple more people to the CC: the following 3 operations in struct > > v4l2_subdev_video_ops don't make me particularly happy: > > > > int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum *fsize); > > int (*enum_frameintervals)(struct v4l2_subdev *sd, struct v4l2_frmivalenum *fival); > > int (*enum_mbus_fsizes)(struct v4l2_subdev *sd, > > struct v4l2_frmsizeenum *fsize); > > > > The problems are: > > > > 1. enum_framesizes and enum_mbus_fsizes seem to be identical (yes, I see > > my Sob under the latter:-() > > Yeah, IMHO, the mbus one should go, since there's no mbus specific structure > being handed as a parameter. Right, we can do that. > > 2. both struct v4l2_frmsizeenum and struct v4l2_frmivalenum are the > > structs, used in the respective V4L2 ioctl()s, and they both contain a > > field for a fourcc value, which doesn't make sense to subdevice drivers. > > So far the only driver combination in the mainline, that I see, that uses > > these operations is marvell-ccic & ov7670. These drivers just ignore the > > pixel format. Relatively recently enum_mbus_fsizes() has been added to > > soc-camera, and this patch is adding enum_frameintervals(). Both these > > implementations abuse the .pixel_format field to pass a media-bus code > > value in it to subdevice drivers. This sends meaningful information to > > subdevice drivers, but is really a hack, rather than a proper > > implementation. > > True. > > > > > Any idea how to improve this? Shall we create mediabus clones of those > > structs with an mbus code instead of fourcc, and drop one of the above > > enum_framesizes() operations? > > Well, to add more confusion to this.. :) > > We have this v4l2-subdev IOCTLs exported to userspace: > > #define VIDIOC_SUBDEV_ENUM_FRAME_SIZE \ > _IOWR('V', 74, struct v4l2_subdev_frame_size_enum) > #define VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL \ > _IOWR('V', 75, struct v4l2_subdev_frame_interval_enum) > > Which in "drivers/media/video/v4l2-subdev.c", are translated to pad ops: > - v4l2_subdev_call(... enum_frame_size ...); > - v4l2_subdev_call(... enum_frame_interval ...); > > respectively. > > So, this is also another thing that's causing some confusion. Wow, didn't know about those. I was about to propose to use those in video subdev ops, but then I noticed: pad operations don't support stepwise enumerations. struct v4l2_subdev_frame_size_enum seems to implement continuous enumeration implicitly, with discrete being a particular degenerate case of it. struct v4l2_subdev_frame_interval_enum only implements discrete enumeration only. I personally don't have a problem with that, I'm not a big fan of these enumeration operations anyway, and AFAICS, the only subdevice driver, implementing those video operations is ov7670, and it implements only DISCRETE. So, would it be good enough for everyone to drop enum_mbus_fsizes() and to convert enum_frameintervals() and enum_framesizes() video operations to use structs from pad operations and just ignore the pad field? Any objections? > Does soc_camera use pad ops? No, not yet. > Regards, > Sergio Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c index eb25756..62c8956 100644 --- a/drivers/media/video/soc_camera.c +++ b/drivers/media/video/soc_camera.c @@ -266,6 +266,15 @@ static int soc_camera_enum_fsizes(struct file *file, void *fh, return ici->ops->enum_fsizes(icd, fsize); } +static int soc_camera_enum_fivals(struct file *file, void *fh, + struct v4l2_frmivalenum *fival) +{ + struct soc_camera_device *icd = file->private_data; + struct soc_camera_host *ici = to_soc_camera_host(icd->parent); + + return ici->ops->enum_fivals(icd, fival); +} + static int soc_camera_reqbufs(struct file *file, void *priv, struct v4l2_requestbuffers *p) { @@ -1266,6 +1275,31 @@ static int default_enum_fsizes(struct soc_camera_device *icd, return 0; } +static int default_enum_fivals(struct soc_camera_device *icd, + struct v4l2_frmivalenum *fival) +{ + int ret; + struct v4l2_subdev *sd = soc_camera_to_subdev(icd); + const struct soc_camera_format_xlate *xlate; + __u32 pixfmt = fival->pixel_format; + struct v4l2_frmivalenum fival_sd = *fival; + + xlate = soc_camera_xlate_by_fourcc(icd, pixfmt); + if (!xlate) + return -EINVAL; + /* map xlate-code to pixel_format, sensor only handle xlate-code*/ + fival_sd.pixel_format = xlate->code; + + ret = v4l2_subdev_call(sd, video, enum_frameintervals, &fival_sd); + if (ret < 0) + return ret; + + *fival = fival_sd; + fival->pixel_format = pixfmt; + + return 0; +} + int soc_camera_host_register(struct soc_camera_host *ici) { struct soc_camera_host *ix; @@ -1297,6 +1331,8 @@ int soc_camera_host_register(struct soc_camera_host *ici) ici->ops->get_parm = default_g_parm; if (!ici->ops->enum_fsizes) ici->ops->enum_fsizes = default_enum_fsizes; + if (!ici->ops->enum_fivals) + ici->ops->enum_fivals = default_enum_fivals; mutex_lock(&list_lock); list_for_each_entry(ix, &hosts, list) { @@ -1387,6 +1423,7 @@ static const struct v4l2_ioctl_ops soc_camera_ioctl_ops = { .vidioc_s_std = soc_camera_s_std, .vidioc_g_std = soc_camera_g_std, .vidioc_enum_framesizes = soc_camera_enum_fsizes, + .vidioc_enum_frameintervals = soc_camera_enum_fivals, .vidioc_reqbufs = soc_camera_reqbufs, .vidioc_querybuf = soc_camera_querybuf, .vidioc_qbuf = soc_camera_qbuf, diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h index b5c2b6c..0a3ac07 100644 --- a/include/media/soc_camera.h +++ b/include/media/soc_camera.h @@ -98,6 +98,7 @@ struct soc_camera_host_ops { int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *); int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *); int (*enum_fsizes)(struct soc_camera_device *, struct v4l2_frmsizeenum *); + int (*enum_fivals)(struct soc_camera_device *, struct v4l2_frmivalenum *); unsigned int (*poll)(struct file *, poll_table *); };