All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil@xs4all.nl>
To: linux-media@vger.kernel.org
Cc: pawel@osciak.com, sakari.ailus@iki.fi, jh1009.sung@samsung.com,
	inki.dae@samsung.com, Hans Verkuil <hans.verkuil@cisco.com>
Subject: [PATCHv11 02/15] DocBook media: update VIDIOC_CREATE_BUFS documentation
Date: Fri, 20 Nov 2015 17:45:35 +0100	[thread overview]
Message-ID: <1448037948-36820-3-git-send-email-hverkuil@xs4all.nl> (raw)
In-Reply-To: <1448037948-36820-1-git-send-email-hverkuil@xs4all.nl>

From: Hans Verkuil <hans.verkuil@cisco.com>

During the Seoul media workshop we decided to relax the VIDIOC_CREATE_BUFS
specification so it would no longer require drivers to validate the format
field since almost no driver did that anyway.

Instead drivers use the buffer size(s) based on the format type and the
corresponding format fields and will ignore any other fields. If the size
cannot be used an error is returned, otherwise the size is used as-is.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
---
 .../DocBook/media/v4l/vidioc-create-bufs.xml       | 30 ++++++++++------------
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
index 8ffe74f..d81fa0d 100644
--- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
@@ -58,7 +58,7 @@
     <para>This ioctl is used to create buffers for <link linkend="mmap">memory
 mapped</link> or <link linkend="userp">user pointer</link> or <link
 linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in
-addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter
+addition to the &VIDIOC-REQBUFS; ioctl, when a tighter
 control over buffers is required. This ioctl can be called multiple times to
 create buffers of different sizes.</para>
 
@@ -71,30 +71,28 @@ zeroed.</para>
 
     <para>The <structfield>format</structfield> field specifies the image format
 that the buffers must be able to handle. The application has to fill in this
-&v4l2-format;. Usually this will be done using the
-<constant>VIDIOC_TRY_FMT</constant> or <constant>VIDIOC_G_FMT</constant> ioctl()
-to ensure that the requested format is supported by the driver. Unsupported
-formats will result in an error.</para>
+&v4l2-format;. Usually this will be done using the &VIDIOC-TRY-FMT; or &VIDIOC-G-FMT; ioctls
+to ensure that the requested format is supported by the driver.
+Based on the format's <structfield>type</structfield> field the requested buffer
+size (for single-planar) or plane sizes (for multi-planar formats) will be
+used for the allocated buffers. The driver may return an error if the size(s)
+are not supported by the hardware (usually because they are too small).</para>
 
     <para>The buffers created by this ioctl will have as minimum size the size
-defined by the <structfield>format.pix.sizeimage</structfield> field. If the
+defined by the <structfield>format.pix.sizeimage</structfield> field (or the
+corresponding fields for other format types). Usually if the
 <structfield>format.pix.sizeimage</structfield> field is less than the minimum
-required for the given format, then <structfield>sizeimage</structfield> will be
-increased by the driver to that minimum to allocate the buffers. If it is
-larger, then the value will be used as-is. The same applies to the
-<structfield>sizeimage</structfield> field of the
-<structname>v4l2_plane_pix_format</structname> structure in the case of
-multiplanar formats.</para>
+required for the given format, then an error will be returned since drivers will
+typically not allow this. If it is larger, then the value will be used as-is.
+In other words, the driver may reject the requested size, but if it is accepted
+the driver will use it unchanged.</para>
 
     <para>When the ioctl is called with a pointer to this structure the driver
 will attempt to allocate up to the requested number of buffers and store the
 actual number allocated and the starting index in the
 <structfield>count</structfield> and the <structfield>index</structfield> fields
 respectively. On return <structfield>count</structfield> can be smaller than
-the number requested. The driver may also increase buffer sizes if required,
-however, it will not update <structfield>sizeimage</structfield> field values.
-The user has to use <constant>VIDIOC_QUERYBUF</constant> to retrieve that
-information.</para>
+the number requested.</para>
 
     <table pgwide="1" frame="none" id="v4l2-create-buffers">
       <title>struct <structname>v4l2_create_buffers</structname></title>
-- 
2.6.2


  parent reply	other threads:[~2015-11-20 16:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-20 16:45 [PATCHv11 00/15] Refactoring Videobuf2 for common use Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 01/15] vb2: drop v4l2_format argument from queue_setup Hans Verkuil
2015-11-20 16:45 ` Hans Verkuil [this message]
2015-11-20 16:45 ` [PATCHv11 03/15] solo6x10: use v4l2_get_timestamp to fill in buffer timestamp Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 04/15] media: videobuf2: Move timestamp to vb2_buffer Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 05/15] media: videobuf2: Add copy_timestamp to struct vb2_queue Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 06/15] media: videobuf2: Separate vb2_poll() Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 07/15] media: videobuf2: last_buffer_queued is set at fill_v4l2_buffer() Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 08/15] media: videobuf2: Refactor vb2_fileio_data and vb2_thread Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 09/15] media: videobuf2: Move vb2_fileio_data and vb2_thread to core part Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 10/15] videobuf2-core.c: update module description Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 11/15] videobuf2-core: fill_user_buffer and copy_timestamp should return void Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 12/15] videobuf2-core: move __setup_lengths into __vb2_queue_alloc() Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 13/15] videobuf2-core: fill in q->bufs[vb->index] before buf_init() Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 14/15] videobuf2-core: call __setup_offsets " Hans Verkuil
2015-11-20 16:45 ` [PATCHv11 15/15] videobuf2-core: fix plane_sizes handling in VIDIOC_CREATE_BUFS Hans Verkuil
2015-11-30 14:15   ` Hans Verkuil
2015-12-09 13:13   ` Sakari Ailus

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=1448037948-36820-3-git-send-email-hverkuil@xs4all.nl \
    --to=hverkuil@xs4all.nl \
    --cc=hans.verkuil@cisco.com \
    --cc=inki.dae@samsung.com \
    --cc=jh1009.sung@samsung.com \
    --cc=linux-media@vger.kernel.org \
    --cc=pawel@osciak.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.