Received: by 10.223.176.46 with SMTP id f43csp285094wra; Thu, 25 Jan 2018 22:05:40 -0800 (PST) X-Google-Smtp-Source: AH8x2263h3oOaQA3ZlbsVewf84UPZqIt4TgZkIxRxOa/bzywiLQuwxotsDaQ2uXTNsDrnaPdBD8L X-Received: by 2002:a17:902:8607:: with SMTP id f7-v6mr13685167plo.273.1516946740330; Thu, 25 Jan 2018 22:05:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516946740; cv=none; d=google.com; s=arc-20160816; b=foVUDXSDH4IhtRWZvZJRGrb0riPNlHkar3yp8StE31ireAavGZLo2KZCc8Ndr4Lllf Ex+Nz1v5a4P9ni7xKGCs+n9yU8Iovp4S/5MNTO2jtv7fWiqe2nSqAeZfrDBsJj6jHorh YMU8ss2lxn3JC5qE0B2vnSOSSWxZj1zb6NC7LTlPVSx2at2xE4EREo/Sm+JnkGaWHxXT Q/U0C9uatXkxAKAkx31+TwNUPbVNtUAH7xNbCxy/g+9stPgm0IhqNELsa+jm/AHn5zAs 11G2IDwpezEOB8loNKz5VfvtTJbNJGI9j+GxtgKh4Cwhonzts7/wsjmSq6N2dGXARK2e II+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=uiib1sSDXiHCe4qOTiEpxQfSJWfBNtUv+4qRT75oW8g=; b=CSN8fLDCu/W+90MNQPISDneui2MnmbjqLPWtnA9LoO70CH/N8XgufGd2aspSKSI6x6 OpSaasR6ywrGAk2ex57Qa6SKf6nJr9B9xN4CpGGh+xlJP5bzg2yZVZLv7Q/pHZnXlAU/ ZASQFnfUwuycEguad1tWcdmsSAXu8Q0swJ/3udoaor3+fj6PDs8jlfoFR7m0Svgvn3Wa ISnM6J++pBejmVboga1NisU+qfUH6vL8/x3J3Q2xHEbbG+8NcWUGbckZLsn6CNpU01uF /LMtlRgKBB2IfmBqJ/lMfyNzpwbfsM3WAhOd14Jg1xTev6ThrZKy9qWk8YG5rFdNIm6b cJcw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=ZYnaOkjI; 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 w2si2561470pgp.680.2018.01.25.22.05.25; Thu, 25 Jan 2018 22:05:40 -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=ZYnaOkjI; 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 S1752014AbeAZGD6 (ORCPT + 99 others); Fri, 26 Jan 2018 01:03:58 -0500 Received: from mail-pg0-f68.google.com ([74.125.83.68]:33091 "EHLO mail-pg0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751902AbeAZGC4 (ORCPT ); Fri, 26 Jan 2018 01:02:56 -0500 Received: by mail-pg0-f68.google.com with SMTP id u1so6624459pgr.0 for ; Thu, 25 Jan 2018 22:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=uiib1sSDXiHCe4qOTiEpxQfSJWfBNtUv+4qRT75oW8g=; b=ZYnaOkjIkNLcrVYHXQ17HdLY5ryRDWodNgz/sMAcL1fjHmLvEkPON10joHy0kM+ycL eUeyDE5W6zMi7ARQGaYsb1EwCntIZurHm3klTJgZgbEuwWa4YEYrHP1qRaWGpHLsNvME NBb9dvRSZpx2ZGRDNpsPJgDDtx5EaiQDRK/tM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=uiib1sSDXiHCe4qOTiEpxQfSJWfBNtUv+4qRT75oW8g=; b=azSIUlVTCOggLup79IreHDMZoQvmo1vm7oM7qWXB6A4yb35ekpcOc4RqiAi0E5XeeV KAEmx7ZexvGkR4fDmrVrcFEWvzzLh1U27udzZkPC8DazbJ1wgxM1fpzG9CuCBhHKOHAQ gz4BXvke/5iBAxOCyVa7K1a7xAGlJ9p2Eo6og1+BBF/KTMvp8Eo9AraGYGeNHcDMbemj KQ17qeQD8kHqp4ylho6u5c5EyRT+lAsGiWG0BanBOPwrpzaNtHJAuemim7qpIRRHN/4J Mea3iIteGYfYWYT4vJmLYDtyBijP22RYmqdAFvxDuP+4TvKJCCeKXDTBeN71gT/bNf0P 3qeg== X-Gm-Message-State: AKwxyte0wtDrnu+WwzcSVhZuejhGh0jAAJGea1WMwa4bganfo8l9qxfX e8recuPkjsn4Bf99w3iNda5Chg== X-Received: by 10.101.88.206 with SMTP id e14mr14909407pgu.441.1516946575674; Thu, 25 Jan 2018 22:02:55 -0800 (PST) Received: from acourbot.tok.corp.google.com ([2401:fa00:4:1002:a6cd:a898:e07b:a331]) by smtp.gmail.com with ESMTPSA id j3sm14543201pfh.39.2018.01.25.22.02.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 22:02:55 -0800 (PST) From: Alexandre Courbot To: Mauro Carvalho Chehab , Hans Verkuil , Laurent Pinchart , Pawel Osciak , Marek Szyprowski , Tomasz Figa , Sakari Ailus , Gustavo Padovan Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, Laurent Pinchart , Alexandre Courbot Subject: [RFC PATCH 5/8] media: Document the media request API Date: Fri, 26 Jan 2018 15:02:13 +0900 Message-Id: <20180126060216.147918-6-acourbot@chromium.org> X-Mailer: git-send-email 2.16.0.rc1.238.g530d649a79-goog In-Reply-To: <20180126060216.147918-1-acourbot@chromium.org> References: <20180126060216.147918-1-acourbot@chromium.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Laurent Pinchart The media request API is made of a new ioctl to implement request management. Document it. Signed-off-by: Laurent Pinchart [acourbot@chromium.org: adapt for newest API] Signed-off-by: Alexandre Courbot --- Documentation/media/uapi/mediactl/media-funcs.rst | 1 + .../media/uapi/mediactl/media-ioc-request-cmd.rst | 140 +++++++++++++++++++++ 2 files changed, 141 insertions(+) create mode 100644 Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst diff --git a/Documentation/media/uapi/mediactl/media-funcs.rst b/Documentation/media/uapi/mediactl/media-funcs.rst index 076856501cdb..e3a45d82ffcb 100644 --- a/Documentation/media/uapi/mediactl/media-funcs.rst +++ b/Documentation/media/uapi/mediactl/media-funcs.rst @@ -15,4 +15,5 @@ Function Reference media-ioc-g-topology media-ioc-enum-entities media-ioc-enum-links + media-ioc-request-cmd media-ioc-setup-link diff --git a/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst new file mode 100644 index 000000000000..17223e8170e9 --- /dev/null +++ b/Documentation/media/uapi/mediactl/media-ioc-request-cmd.rst @@ -0,0 +1,140 @@ +.. -*- coding: utf-8; mode: rst -*- + +.. _media_ioc_request_cmd: + +*************************** +ioctl MEDIA_IOC_REQUEST_CMD +*************************** + +Name +==== + +MEDIA_IOC_REQUEST_CMD - Manage media device requests + + +Synopsis +======== + +.. c:function:: int ioctl( int fd, MEDIA_IOC_REQUEST_CMD, struct media_request_cmd *argp ) + :name: MEDIA_IOC_REQUEST_CMD + + +Arguments +========= + +``fd`` + File descriptor returned by :ref:`open() `. + +``argp`` + + +Description +=========== + +The MEDIA_IOC_REQUEST_CMD ioctl allow applications to manage media device +requests. A request is an object that can group media device configuration +parameters, including subsystem-specific parameters, in order to apply all the +parameters atomically. Applications are responsible for allocating and +deleting requests, filling them with configuration parameters submitting them. + +Request operations are performed by calling the MEDIA_IOC_REQUEST_CMD ioctl +with a pointer to a struct :c:type:`media_request_cmd` with the cmd field set +to the appropriate command. :ref:`media-request-command` lists the commands +supported by the ioctl. + +The struct :c:type:`media_request_cmd` request field contains the file +descriptorof the request on which the command operates. For the +``MEDIA_REQ_CMD_ALLOC`` command the field is set to zero by applications and +filled by the driver. For all other commands the field is set by applications +and left untouched by the driver. + +To allocate a new request applications use the ``MEDIA_REQ_CMD_ALLOC`` +command. The driver will allocate a new request and return its ID in the +request field. + +Requests are reference-counted. A newly allocated request is referenced +by the returned file descriptor, and can be later referenced by +subsystem-specific operations. Requests will thus be automatically deleted +when they're not longer used after the returned file descriptor is closed. + +If a request isn't needed applications can delete it by calling ``close()`` +on it. The driver will drop the file handle reference. The request will not +be usable through the MEDIA_IOC_REQUEST_CMD ioctl anymore, but will only be +deleted when the last reference is released. If no other reference exists when +``close()`` is invoked the request will be deleted immediately. + +After creating a request applications should fill it with configuration +parameters. This is performed through subsystem-specific request APIs outside +the scope of the media controller API. See the appropriate subsystem APIs for +more information, including how they interact with the MEDIA_IOC_REQUEST_CMD +ioctl. + +Once a request contains all the desired configuration parameters it can be +submitted using the ``MEDIA_REQ_CMD_SUBMIT`` command. This will let the +buffers queued for the request be passed to their respective drivers, which +will then apply the request's parameters before processing them. + +Once a request has been queued applications are not allowed to modify its +configuration parameters until the request has been fully processed. Any +attempt to do so will result in the related subsystem API returning an error. +The application that submitted the request can wait for its completion by +polling on the request's file descriptor. + +Once a request has completed, it can be reused. The ``MEDIA_REQ_CMD_REINIT`` +command will bring it back to its initial state, so it can be prepared and +submitted again. + +.. c:type:: media_request_cmd + +.. flat-table:: struct media_request_cmd + :header-rows: 0 + :stub-columns: 0 + :widths: 1 2 8 + + * - __u32 + - ``cmd`` + - Command, set by the application. See below for the list of supported + commands. + * - __u32 + - ``fd`` + - Request FD, set by the driver for the MEDIA_REQ_CMD_ALLOC command and + by the application for all other commands. + + +.. _media-request-command: + +.. cssclass:: longtable + +.. flat-table:: Media request commands + :header-rows: 0 + :stub-columns: 0 + + * .. _MEDIA-REQ-CMD-ALLOC: + + - ``MEDIA_REQ_CMD_ALLOC`` + - Allocate a new request. + * .. _MEDIA-REQ-CMD-SUBMIT: + + - ``MEDIA_REQ_CMD_SUBMIT`` + - Submit a request to be processed. + * .. _MEDIA-REQ-CMD-QUEUE: + + - ``MEDIA_REQ_CMD_REINIT`` + - Reinitializes a completed request. + + +Return Value +============ + +On success 0 is returned, on error -1 and the ``errno`` variable is set +appropriately. The generic error codes are described at the +:ref:`Generic Error Codes ` chapter. + +EINVAL + The struct :c:type:`media_request_cmd` specifies an invalid command or + references a non-existing request. + +ENOSYS + The struct :c:type:`media_request_cmd` specifies the + ``MEDIA_REQ_CMD_QUEUE`` or ``MEDIA_REQ_CMD_APPLY`` command and that + command isn't implemented by the device. -- 2.16.0.rc1.238.g530d649a79-goog