Hi Hans,

Thank you for the patch.

On Thursday 23 October 2014 13:21:28 Hans Verkuil wrote:
> From: Hans Verkuil <hans.verk...@cisco.com>
> 
> Document that drivers can access/modify the buffer contents in buf_prepare
> and buf_finish. That was not clearly stated before.
> 
> Signed-off-by: Hans Verkuil <hans.verk...@cisco.com>

Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>

> ---
>  include/media/videobuf2-core.h | 32 +++++++++++++++++---------------
>  1 file changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index 6ef2d01..70ace7c 100644
> --- a/include/media/videobuf2-core.h
> +++ b/include/media/videobuf2-core.h
> @@ -270,22 +270,24 @@ struct vb2_buffer {
>   *                   queue setup from completing successfully; optional.
>   * @buf_prepare:     called every time the buffer is queued from userspace
>   *                   and from the VIDIOC_PREPARE_BUF ioctl; drivers may
> - *                   perform any initialization required before each hardware
> - *                   operation in this callback; drivers that support
> - *                   VIDIOC_CREATE_BUFS must also validate the buffer size;
> - *                   if an error is returned, the buffer will not be queued
> - *                   in driver; optional.
> + *                   perform any initialization required before each
> + *                   hardware operation in this callback; drivers can
> + *                   access/modify the buffer here as it is still synced for
> + *                   the CPU; drivers that support VIDIOC_CREATE_BUFS must
> + *                   also validate the buffer size; if an error is returned,
> + *                   the buffer will not be queued in driver; optional.
>   * @buf_finish:              called before every dequeue of the buffer back 
> to
> - *                   userspace; drivers may perform any operations required
> - *                   before userspace accesses the buffer; optional. The
> - *                   buffer state can be one of the following: DONE and
> - *                   ERROR occur while streaming is in progress, and the
> - *                   PREPARED state occurs when the queue has been canceled
> - *                   and all pending buffers are being returned to their
> - *                   default DEQUEUED state. Typically you only have to do
> - *                   something if the state is VB2_BUF_STATE_DONE, since in
> - *                   all other cases the buffer contents will be ignored
> - *                   anyway.
> + *                   userspace; the buffer is synced for the CPU, so drivers
> + *                   can access/modify the buffer contents; drivers may
> + *                   perform any operations required before userspace
> + *                   accesses the buffer; optional. The buffer state can be
> + *                   one of the following: DONE and ERROR occur while
> + *                   streaming is in progress, and the PREPARED state occurs
> + *                   when the queue has been canceled and all pending
> + *                   buffers are being returned to their default DEQUEUED
> + *                   state. Typically you only have to do something if the
> + *                   state is VB2_BUF_STATE_DONE, since in all other cases
> + *                   the buffer contents will be ignored anyway.
>   * @buf_cleanup:     called once before the buffer is freed; drivers may
>   *                   perform any additional cleanup; optional.
>   * @start_streaming: called once to enter 'streaming' state; the driver 
may

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to