From: Michael Jones <michael.jones@matrix-vision.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-media@vger.kernel.org,
Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
Subject: Re: [RFC] omap3-isp G_FMT & ENUM_FMT
Date: Fri, 27 Jul 2012 11:07:50 +0200 [thread overview]
Message-ID: <50125A66.80104@matrix-vision.de> (raw)
In-Reply-To: <7135672.xS20ZCiE6C@avalon>
Hi Laurent,
On 07/27/2012 01:32 AM, Laurent Pinchart wrote:
> Hi Michael,
>
> On Thursday 26 July 2012 16:22:17 Michael Jones wrote:
>> On 07/26/2012 04:05 PM, Laurent Pinchart wrote:
>>> On Thursday 26 July 2012 13:59:54 Michael Jones wrote:
>>>> Hello,
>>>>
>>>> I would like to (re)submit a couple of patches to support V4L2 behavior
>>>> at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they
>>>> require some discussion first.
>>>
>>> Indeed.
>>>
>>> The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does
>>> today is to hack around a restriction in the V4L2 API. We needed a way to
>>> preallocate and possibly prequeue buffers for snapshot, which wasn't
>>> possible in a standard-compliant way back then.
>>>
>>> The situation has since changed, and we now have the VIDIOC_CREATE_BUFS
>>> and VIDIOC_PREPARE_BUF ioctls. My plan is to
>>>
>>> - port the OMAP3 ISP driver to videobuf2
>>> - implement support for CREATE_BUFS and PREPARE_BUF
>>> - fix the G_FMT/S_FMT/ENUM_FMT behaviour
>>
>> What will the G_FMT/S_FMT/ENUM_FMT behavior be then? Can you contrast
>> it with the behavior of my patches? If the behavior will be the same
>> for user space, and your proposed changes won't be in very soon, can we
>> use my patches until you make your changes?
>
> At the moment the driver accepts any format you give it in a S_FMT call,
> regardless of the format of the connected pad. The reason for that is to allow
> VIDIOC_REQBUFS to allocate buffers for an arbitrary size.
>
> With CREATE_BUFS and PREPARE_BUFS support, G_FMT, S_FMT and ENUM_FMT should
> return the format of the connected pad.
>
OK, so this sounds like the same behavior I'd like to add before
CREATE_BUFS and PREPARE_BUFS support is in. My other question was if
this is the case, can we use my approach until your planned changes are in?
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
next prev parent reply other threads:[~2012-07-27 9:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 11:59 [RFC] omap3-isp G_FMT & ENUM_FMT Michael Jones
2012-07-26 11:59 ` [PATCH 1/2] [media] omap3isp: implement ENUM_FMT Michael Jones
2012-07-26 11:59 ` [PATCH 2/2] [media] omap3isp: support G_FMT Michael Jones
2012-07-26 12:10 ` [RFC] omap3-isp G_FMT & ENUM_FMT Hans Verkuil
2012-07-26 14:05 ` Laurent Pinchart
2012-07-26 14:22 ` Michael Jones
2012-07-26 23:32 ` Laurent Pinchart
2012-07-27 9:07 ` Michael Jones [this message]
2012-07-27 9:35 ` Laurent Pinchart
2012-07-27 11:31 ` Michael Jones
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=50125A66.80104@matrix-vision.de \
--to=michael.jones@matrix-vision.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@maxwell.research.nokia.com \
/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).