From: Sylwester Nawrocki <snjw23@gmail.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
Hans Verkuil <hverkuil@xs4all.nl>
Subject: Re: RFC: Negotiating frame buffer size between sensor subdevs and bridge devices
Date: Sat, 20 Aug 2011 23:10:26 +0200 [thread overview]
Message-ID: <4E5022C2.2000705@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.1108171942480.2773@axis700.grange>
On 08/17/2011 07:43 PM, Guennadi Liakhovetski wrote:
> On Wed, 17 Aug 2011, Sakari Ailus wrote:
>> On Thu, Jul 28, 2011 at 07:04:11PM +0200, Sylwester Nawrocki wrote:
...
>>> In order to let the host drivers query or configure subdevs with required
>>> frame buffer size one of the following changes could be done at V4L2 API:
>>>
>>> 1. Add a 'sizeimage' field in struct v4l2_mbus_framefmt and make subdev
>>> drivers optionally set/adjust it when setting or getting the format with
>>> set_fmt/get_fmt pad level ops (and s/g_mbus_fmt ?)
>>> There could be two situations:
>>> - effective required frame buffer size is specified by the sensor and the
>>> host driver relies on that value when allocating a buffer;
>>> - the host driver forces some arbitrary buffer size and the sensor performs
>>> any required action to limit transmitted amount of data to that amount
>>> of data;
>>> Both cases could be covered similarly as it's done with VIDIOC_S_FMT.
>>>
>>> Introducing 'sizeimage' field is making the media bus format struct looking
>>> more similar to struct v4l2_pix_format and not quite in line with media bus
>>> format meaning, i.e. describing data on a physical bus, not in the memory.
>>> The other option I can think of is to create separate subdev video ops.
>>> 2. Add new s/g_sizeimage subdev video operations
...
>> I prefer this second approach over the first once since the maxiumu size of
>> the image in bytes really isn't a property of the bus.
>
> Call that field framesamples and already it fits quite well with the
> notion of data on the bus and not in memory. Wouldn't this work?
Hmm...that might be exactly what we need.
That was also an initial Hans' proposal when we recently discussed it.
At least such an information should be sufficient for handling JPEG, where
the effective buffer size might be calculated from a media bus pixel code
and a number of samples per frame.
--
Regards,
Sylwester
next prev parent reply other threads:[~2011-08-20 21:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-28 17:04 RFC: Negotiating frame buffer size between sensor subdevs and bridge devices Sylwester Nawrocki
2011-08-16 22:25 ` Sakari Ailus
2011-08-17 17:43 ` Guennadi Liakhovetski
2011-08-20 21:10 ` Sylwester Nawrocki [this message]
2011-08-17 20:22 ` Sylwester Nawrocki
2011-08-18 20:32 ` Sakari Ailus
2011-08-19 13:13 ` Sylwester Nawrocki
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=4E5022C2.2000705@gmail.com \
--to=snjw23@gmail.com \
--cc=g.liakhovetski@gmx.de \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=sakari.ailus@iki.fi \
/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).