From patchwork Mon Nov 10 12:49:16 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans Verkuil X-Patchwork-Id: 5266241 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E39AF9F2ED for ; Mon, 10 Nov 2014 12:54:07 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 1F47920173 for ; Mon, 10 Nov 2014 12:54:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 32C1E20166 for ; Mon, 10 Nov 2014 12:54:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752623AbaKJMtk (ORCPT ); Mon, 10 Nov 2014 07:49:40 -0500 Received: from lb3-smtp-cloud6.xs4all.net ([194.109.24.31]:48785 "EHLO lb3-smtp-cloud6.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752577AbaKJMti (ORCPT ); Mon, 10 Nov 2014 07:49:38 -0500 Received: from tschai.lan ([173.38.208.170]) by smtp-cloud6.xs4all.net with ESMTP id DopZ1p00B3h7Shp01opcub; Mon, 10 Nov 2014 13:49:36 +0100 Received: from tschai.cisco.com (localhost [127.0.0.1]) by tschai.lan (Postfix) with ESMTPSA id D663C2A13B1; Mon, 10 Nov 2014 13:49:32 +0100 (CET) From: Hans Verkuil To: linux-media@vger.kernel.org Cc: m.szyprowski@samsung.com, pawel@osciak.com, Hans Verkuil Subject: [RFCv6 PATCH 01/16] videobuf2-core.h: improve documentation Date: Mon, 10 Nov 2014 13:49:16 +0100 Message-Id: <1415623771-29634-2-git-send-email-hverkuil@xs4all.nl> X-Mailer: git-send-email 2.1.1 In-Reply-To: <1415623771-29634-1-git-send-email-hverkuil@xs4all.nl> References: <1415623771-29634-1-git-send-email-hverkuil@xs4all.nl> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Hans Verkuil 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 --- 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