From: javier.martin@vista-silicon.com (javier Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] media: coda: Add driver for Coda video codec.
Date: Mon, 9 Jul 2012 10:21:44 +0200 [thread overview]
Message-ID: <CACKLOr3w3ZFHnpEr5=mTdSFWk0WBZnHXVceMvds3EyRnf=vbtg@mail.gmail.com> (raw)
In-Reply-To: <1341821944.2489.16.camel@pizza.hi.pengutronix.de>
On 9 July 2012 10:19, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Montag, den 09.07.2012, 10:07 +0200 schrieb javier Martin:
> [...]
>> >> +static int vidioc_s_parm(struct file *file, void *priv, struct v4l2_streamparm *a)
>> >> +{
>> >> + struct coda_ctx *ctx = fh_to_ctx(priv);
>> >> +
>> >> + if (a->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
>> >> + if (a->parm.output.timeperframe.numerator != 1) {
>> >> + v4l2_err(&ctx->dev->v4l2_dev,
>> >> + "FPS numerator must be 1\n");
>> >> + return -EINVAL;
>> >> + }
>> >> + ctx->params.framerate =
>> >> + a->parm.output.timeperframe.denominator;
>> >> + } else {
>> >> + v4l2_err(&ctx->dev->v4l2_dev,
>> >> + "Setting FPS is only possible for the output queue\n");
>> >> + return -EINVAL;
>> >
>> > Why disallow setting timeperframe on the capture side? Shouldn't it
>> > rather succeed without setting anything and return the current context's
>> > frame rate instead?
>> >
>> >> + }
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static int vidioc_g_parm(struct file *file, void *priv, struct v4l2_streamparm *a)
>> >> +{
>> >> + struct coda_ctx *ctx = fh_to_ctx(priv);
>> >> +
>> >> + if (a->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
>> >> + a->parm.output.timeperframe.denominator =
>> >> + ctx->params.framerate;
>> >> + a->parm.output.timeperframe.numerator = 1;
>> >> + } else {
>> >> + v4l2_err(&ctx->dev->v4l2_dev,
>> >> + "Getting FPS is only possible for the output queue\n");
>> >
>> > The nominal capture side timeperframe should match that of the output
>> > side.
>> >
>> > Actually, I'm not sure if this needs to be implemented at all, since
>> > V4L2_CAP_TIMEPERFRAME is not set and capture frame dropping / output
>> > frame duplication is not supported.
>>
>> I am just following the steps of Samsung here:
>>
>> http://lxr.linux.no/#linux+v3.4.4/drivers/media/video/s5p-mfc/s5p_mfc_enc.c#L1439
>> http://lxr.linux.no/#linux+v3.4.4/drivers/media/video/s5p-mfc/s5p_mfc_opr.c#L775
>>
>
> I don't think this is completely correct either. According to the V4L2
> spec, setting timeperframe from an application is meant to make the
> driver skip or duplicate frames to save bandwidth:
>
> http://v4l2spec.bytesex.org/spec-single/v4l2.html#VIDIOC-G-PARM
>
> So returning -EINVAL is not necessarily incorrect, as we can choose not
> to support this ioctl - but claiming support for the output side (and
> then doing nothing) but returning an error on the capture side seems a
> bit inconsistent to me.
I'll remove it since we don't use it either way.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
next prev parent reply other threads:[~2012-07-09 8:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-06 12:57 [PATCH 0/3] Add support for 'Coda' video codec IP Javier Martin
2012-07-06 12:57 ` [PATCH 1/3] i.MX: coda: Add platform support for coda in i.MX27 Javier Martin
2012-07-06 12:57 ` [PATCH 2/3] media: coda: Add driver for Coda video codec Javier Martin
2012-07-06 17:48 ` Russell King - ARM Linux
2012-07-09 6:45 ` Philipp Zabel
2012-07-09 8:07 ` javier Martin
2012-07-09 8:19 ` Philipp Zabel
2012-07-09 8:21 ` javier Martin [this message]
2012-07-09 8:14 ` javier Martin
2012-07-09 8:29 ` Philipp Zabel
2012-07-06 12:57 ` [PATCH 3/3] Visstrim M10: Add support for Coda Javier Martin
2012-07-06 17:47 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CACKLOr3w3ZFHnpEr5=mTdSFWk0WBZnHXVceMvds3EyRnf=vbtg@mail.gmail.com' \
--to=javier.martin@vista-silicon.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).