Received: by 10.223.185.116 with SMTP id b49csp320451wrg; Tue, 20 Feb 2018 22:03:23 -0800 (PST) X-Google-Smtp-Source: AH8x226mqWFoe4CZB/h4LvJjs3oD6TQTMlOD/bcBoCCMczQzmzunxRS7spB3mGq3/Iwi/ckAkcFp X-Received: by 10.99.126.19 with SMTP id z19mr1802118pgc.108.1519193003033; Tue, 20 Feb 2018 22:03:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519193002; cv=none; d=google.com; s=arc-20160816; b=shsxErEDE6hubsHGaeCW33e+Ns7mTfrPSz6hvNJ+rFTYBo4MXKnEeoR5AORMSeXqYX L3s3F/Cv425MVL1ezkOsQpCEF6C3bfdH1nYCGHx7SI2udpEjenA1TxZMpYz1y6Uec083 5cplHdg2FpZJP2iNuMO9amqrZEK+wbx4xVkrgon9Nni3xa90xRJzLM+y7B7XUCCN8bo+ x/VTfQkLfcb+US6dIoYnNgzncV1GHQsqOz5CrDskLXiJNF/BELKAqDIHBTAlnAhgrRoC Bc6Z93txfjkfL2gTuhSE1+34qcCkcQpV1O2YCv5i84LDxvMgdGthVk770yVJcWrm8QTi ZHGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=FnIYiKoYdBpJRb9JeH8dPcfvMRHNsCPpx5aGIGnJcnE=; b=cpBZ7+GJ+sGPaU21qlNZzdX6SoJAqwcJyy6RqKDYEaOXq8BMNSNpsniOmtlUfKgXkJ 4R3kv21/3xtHBUku3wYw1SqcGIP7WO2YTa0ZlREaRfHmnfaP3rM3c91YvsSKStirCJcr th9q7FlcLQLkCxWxo425IU7qVyriSHtjaFy8IAr+Ji8QzM12rMWmPav+UEaxHNDodKpf xy4K6VlESg87xNwXkme/bIK346LOoXau1DQKlgoHH85txhYL+eq3YUHKYqfLkP1EvlN4 Ui5AqFK6w91+sM+MrpMDZD8v6iEj9lbQ9oRImGFPmHn2wLF2u031YjLZLHApvMV5ccIU o5CQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZfmbaQm7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i187si696739pfe.384.2018.02.20.22.03.08; Tue, 20 Feb 2018 22:03:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZfmbaQm7; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751740AbeBUGCP (ORCPT + 99 others); Wed, 21 Feb 2018 01:02:15 -0500 Received: from mail-it0-f65.google.com ([209.85.214.65]:39158 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274AbeBUGCK (ORCPT ); Wed, 21 Feb 2018 01:02:10 -0500 Received: by mail-it0-f65.google.com with SMTP id l187so956554ith.4 for ; Tue, 20 Feb 2018 22:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FnIYiKoYdBpJRb9JeH8dPcfvMRHNsCPpx5aGIGnJcnE=; b=ZfmbaQm79MfOblFNO97AfVysF320W/1P4CLrC6btzx9FmgsvbihbxIN0I/Czr4zxvS bh+/6EljfBx94gIN6JtK/FXYLw1TaWG5DJHHq3GqZS1VRl2EgUTNbxZI4iml1YCTBbRI L3RW2eHDK/K7/ncV/8AQF855eKBt9VC2U3uCo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FnIYiKoYdBpJRb9JeH8dPcfvMRHNsCPpx5aGIGnJcnE=; b=jVC4rrtgYS22sdAKhdky6RpX9q3C2Edm9hw9nsxQ36umPpE7FD0Ugxq4bnvnM59Rfm +fUn6Xp9/WBc7VGlWubUBaIvAKrVZeQ7S93Xoqld5vQenmtqYY/9/y5FlbCg3evG8zy2 G5x6/DfmoETvwUr3MfLuS2/PwqVbgvN6eC5u3Nx4D/sAKY1d+x+itsMuYdCKGi+SEZ0v ZQcg3enf12zTzDsMoG8RQimikZAnWp1B4fgc5chvbqv9anosO51VIfCBsIkdz5LDI9mF HmdB4UVzzcCtDKxvAv09PBqiFTdRTILX4PcsR8lTGKK6pZFRIFk6/wefB3XrajVNMFnt ouAA== X-Gm-Message-State: APf1xPCUuSClPd70dUwrWOoezky+IktG3O3qsb+ONQMDat27nfgW9p/j OjhM2SfQ7MCq3CDNneZqQ7RXe5rpj6k= X-Received: by 10.36.94.65 with SMTP id h62mr387311itb.144.1519192929050; Tue, 20 Feb 2018 22:02:09 -0800 (PST) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id a123sm25280822ioa.78.2018.02.20.22.02.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 22:02:07 -0800 (PST) Received: by mail-it0-f54.google.com with SMTP id v194so981031itb.0 for ; Tue, 20 Feb 2018 22:02:07 -0800 (PST) X-Received: by 10.36.192.131 with SMTP id u125mr1840561itf.119.1519192926974; Tue, 20 Feb 2018 22:02:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.105.131 with HTTP; Tue, 20 Feb 2018 22:01:46 -0800 (PST) In-Reply-To: <86ad101f-f400-c7fd-2aa5-4dc618973f3d@xs4all.nl> References: <20180220044425.169493-1-acourbot@chromium.org> <20180220044425.169493-14-acourbot@chromium.org> <86ad101f-f400-c7fd-2aa5-4dc618973f3d@xs4all.nl> From: Alexandre Courbot Date: Wed, 21 Feb 2018 15:01:46 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFCv4 13/21] media: videobuf2-v4l2: support for requests To: Hans Verkuil Cc: Mauro Carvalho Chehab , Laurent Pinchart , Pawel Osciak , Marek Szyprowski , Tomasz Figa , Sakari Ailus , Gustavo Padovan , Linux Media Mailing List , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 21, 2018 at 1:18 AM, Hans Verkuil wrote: > On 02/20/2018 05:44 AM, Alexandre Courbot wrote: >> Add a new vb2_qbuf_request() (a request-aware version of vb2_qbuf()) >> that request-aware drivers can call to queue a buffer into a request >> instead of directly into the vb2 queue if relevent. >> >> This function expects that drivers invoking it are using instances of >> v4l2_request_entity and v4l2_request_entity_data to describe their >> entity and entity data respectively. >> >> Also add the vb2_request_submit() helper function which drivers can >> invoke in order to queue all the buffers previously queued into a >> request into the regular vb2 queue. >> >> Signed-off-by: Alexandre Courbot >> --- >> .../media/common/videobuf2/videobuf2-v4l2.c | 129 +++++++++++++++++- >> include/media/videobuf2-v4l2.h | 59 ++++++++ >> 2 files changed, 187 insertions(+), 1 deletion(-) >> > > > >> @@ -776,10 +899,14 @@ EXPORT_SYMBOL_GPL(vb2_ioctl_querybuf); >> int vb2_ioctl_qbuf(struct file *file, void *priv, struct v4l2_buffer *p) >> { >> struct video_device *vdev = video_devdata(file); >> + struct v4l2_fh *fh = NULL; >> + >> + if (test_bit(V4L2_FL_USES_V4L2_FH, &vdev->flags)) >> + fh = file->private_data; > > No need for this. All drivers using vb2 will also use v4l2_fh. Fixed. > >> >> if (vb2_queue_is_busy(vdev, file)) >> return -EBUSY; >> - return vb2_qbuf(vdev->queue, p); >> + return vb2_qbuf_request(vdev->queue, p, fh ? fh->entity : NULL); >> } >> EXPORT_SYMBOL_GPL(vb2_ioctl_qbuf); >> >> diff --git a/include/media/videobuf2-v4l2.h b/include/media/videobuf2-v4l2.h >> index 3d5e2d739f05..d4dfa266a0da 100644 >> --- a/include/media/videobuf2-v4l2.h >> +++ b/include/media/videobuf2-v4l2.h >> @@ -23,6 +23,12 @@ >> #error VB2_MAX_PLANES != VIDEO_MAX_PLANES >> #endif >> >> +struct media_entity; >> +struct v4l2_fh; >> +struct media_request; >> +struct media_request_entity; >> +struct v4l2_request_entity_data; >> + >> /** >> * struct vb2_v4l2_buffer - video buffer information for v4l2. >> * >> @@ -116,6 +122,59 @@ int vb2_prepare_buf(struct vb2_queue *q, struct v4l2_buffer *b); >> */ >> int vb2_qbuf(struct vb2_queue *q, struct v4l2_buffer *b); >> >> +#if IS_ENABLED(CONFIG_MEDIA_REQUEST_API) >> + >> +/** >> + * vb2_qbuf_request() - Queue a buffer, with request support >> + * @q: pointer to &struct vb2_queue with videobuf2 queue. >> + * @b: buffer structure passed from userspace to >> + * &v4l2_ioctl_ops->vidioc_qbuf handler in driver >> + * @entity: request entity to queue for if requests are used. >> + * >> + * Should be called from &v4l2_ioctl_ops->vidioc_qbuf handler of a driver. >> + * >> + * If requests are not in use, calling this is equivalent to calling vb2_qbuf(). >> + * >> + * If the request_fd member of b is set, then the buffer represented by b is >> + * queued in the request instead of the vb2 queue. The buffer will be passed >> + * to the vb2 queue when the request is submitted. > > I would definitely also prepare the buffer at this time. That way you'll see any > errors relating to the prepare early on. I was wondering about that, so glad to have your opinion on this. Will make sure buffers are prepared before queuing them to a request. > >> + * >> + * The return values from this function are intended to be directly returned >> + * from &v4l2_ioctl_ops->vidioc_qbuf handler in driver. >> + */ >> +int vb2_qbuf_request(struct vb2_queue *q, struct v4l2_buffer *b, >> + struct media_request_entity *entity); >> + >> +/** >> + * vb2_request_submit() - Queue all the buffers in a v4l2 request. >> + * @data: request entity data to queue buffers of >> + * >> + * This function should be called from the media_request_entity_ops::submit >> + * hook for instances of media_request_v4l2_entity_data. It will immediately >> + * queue all the request-bound buffers to their respective vb2 queues. >> + * >> + * Errors from vb2_core_qbuf() are returned if something happened. Also, since >> + * v4l2 request entities require at least one buffer for the request to trigger, >> + * this function will return -EINVAL if no buffer have been bound at all for >> + * this entity. >> + */ >> +int vb2_request_submit(struct v4l2_request_entity_data *data); >> + >> +#else /* CONFIG_MEDIA_REQUEST_API */ >> + >> +static inline int vb2_qbuf_request(struct vb2_queue *q, struct v4l2_buffer *b, >> + struct media_request_entity *entity) >> +{ >> + return vb2_qbuf(q, b); >> +} >> + >> +static inline int vb2_request_submit(struct v4l2_request_entity_data *data) >> +{ >> + return -ENOTSUPP; >> +} >> + >> +#endif /* CONFIG_MEDIA_REQUEST_API */ >> + >> /** >> * vb2_expbuf() - Export a buffer as a file descriptor >> * @q: pointer to &struct vb2_queue with videobuf2 queue. >> > > Regards, > > Hans