From patchwork Sun Feb 19 11:00:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dorota Czaplejewicz X-Patchwork-Id: 59140 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp810687wrn; Sun, 19 Feb 2023 03:46:46 -0800 (PST) X-Google-Smtp-Source: AK7set/Dfw7jovnfZ7p2OZJAFAlGpWd7gnZAqEFLbeseEVUH8ib2mwvOB8YGDBfEsCsV6qogtmz/ X-Received: by 2002:a05:6a20:2da9:b0:be:d4be:50a2 with SMTP id bf41-20020a056a202da900b000bed4be50a2mr5727723pzb.32.1676807206217; Sun, 19 Feb 2023 03:46:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676807206; cv=none; d=google.com; s=arc-20160816; b=Rq7YmNGRhd3co9dgu6PXuRJ6yChJMLSNIqsEenHON22amzpe9zGcgd4KsWJF9U3Ui2 A08UCct/sas3/UsgWxEvFZ4rUZ6fi2b16FTsw/y/8Ybb1DYuCJ0oKjBLMD/puOdUEBq7 ZFo5RLXk4RKA3iEmnpZzo9gmUnnxPcqJESEUtXr9ODwse2KooUgRItSICd9cYXPASWWy Dj8zDECW5YMJoNihGaaojzdG3BXxIkugx+KIjbgqwbQDUQQHpAZ7J/KmJBLl9lT8IdEF rI9DpLDE/BJtzZmbo04dpNduhWHI2Gt3i6k0tyvks7IffiSKFSEJ+NsgTIYACyMUk4gb LerA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:organization:message-id:subject:to :from:dkim-signature:date; bh=aWlg6h+MergNzkNWFWL0kAPhALRTsx/P2TwmF3x2noA=; b=eslFg3gdtYMbFnsqj2/EiWmwqEpQ/RrvNzuUx/4Mc0Yb1NfUSlWaFOoc3CgKTC3ZvU H+0OtOS67kz5s8GpEtElwnDSqFr9SytSd1zJuPJlJNjJBE6elW3q4z6yt3l8xAwVjV4f sJyKIpcFhP8L5y5rxl0SgPmvv02gt08UCvPJQjUphHuzB2HWXVozeVwjeyIWhz5GNuYG RH/khZlwwtiiLH+wyJ30AYGxezM7qMEkzceUg0m6HhI4jtksdCTdfF34Wic/lNTo8mKW GBF0SIFYAFzKAURgZMFFHfL/9VGOoGkKrFs3OMRglMJyAZIAjvCfkGkQiTRW/NSnDa5b Iw3A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@puri.sm header.s=comms header.b=d5Nz9T4O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=puri.sm Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r17-20020a632b11000000b00502b0163ab8si3821086pgr.147.2023.02.19.03.46.33; Sun, 19 Feb 2023 03:46:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@puri.sm header.s=comms header.b=d5Nz9T4O; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=puri.sm Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230132AbjBSLGy (ORCPT + 99 others); Sun, 19 Feb 2023 06:06:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbjBSLGx (ORCPT ); Sun, 19 Feb 2023 06:06:53 -0500 X-Greylist: delayed 334 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Sun, 19 Feb 2023 03:06:51 PST Received: from comms.puri.sm (comms.puri.sm [159.203.221.185]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD3A4EB64; Sun, 19 Feb 2023 03:06:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by comms.puri.sm (Postfix) with ESMTP id 37C55EBA6C; Sun, 19 Feb 2023 03:01:17 -0800 (PST) Received: from comms.puri.sm ([127.0.0.1]) by localhost (comms.puri.sm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsC8DmlStKXT; Sun, 19 Feb 2023 03:01:16 -0800 (PST) Date: Sun, 19 Feb 2023 12:00:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=puri.sm; s=comms; t=1676804476; bh=mbBNYPuhb2apsz5SvK8JsFBaH/EaefkZb9gM8EHx9Es=; h=Date:From:To:Subject:From; b=d5Nz9T4OG1OVB3vZY4On71vSHZKXwbaX+znvJnZfHCm0PvPfYKTyVv2Lyn0kwdiE/ CPH5lHyb6n0iSoFnslQFcAPh2YlGml6+3GtCm4Wg8Eoqh7oxmxTTLqGdfN6ZO+VgoL 58bh8YyWQH+nohltlgLw0KWqHbFLzCyVuRUcmtGgBKjcxMAUfvfFbID4yh9UY2a3vn kj8A82LHpcxI7Bm+M2qLlgYCTYTMQZoWYODFzxnwI9RwrtliCr4bez2KQ+obuJ4tvg wCxjvygkZFqp/npqvgCgqyJjC2P1DZeRarz8rPOXHBJK0RWpRyMUg5ykkHj8UwkYW5 H3AXOytSn6SDA== From: Dorota Czaplejewicz To: Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, kernel@puri.sm Subject: [PATCHv3 1/2 RESEND] doc/media api: Try to make enum usage clearer Message-ID: <20230219120034.5819b4ac.dorota.czaplejewicz@puri.sm> Organization: Purism MIME-Version: 1.0 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758259793095706394?= X-GMAIL-MSGID: =?utf-8?q?1758259793095706394?= This clarifies which side of the calls is responsible for doing what to which parts of the struct. This also explicitly states that repeating values are disallowed. It also expands the terse description of the access algorithm into more prose-like, active voice description, which trades conciseness for ease of comprehension. Added: mbus codes must not repeat Added: no holes in the enumeration Added: enumerations per what? Added: who fills in what in calls Changed: "zero" -> "0" Changed: "given" -> "specified" Still unclear how it works so didn't describe: "which". What is a "try format" vs "active format"? Signed-off-by: Dorota Czaplejewicz --- Hi, I took those patches out of the freezer. I made sure they still apply (they do), and corrected some errors pointed out by Jacopo in the previous round of reviews. Thanks, Dorota .../v4l/vidioc-subdev-enum-mbus-code.rst | 38 +++++++++++++------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst index 417f1a19bcc4..63bff24d0520 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-subdev-enum-mbus-code.rst @@ -31,15 +31,28 @@ Arguments Description =========== -To enumerate media bus formats available at a given sub-device pad -applications initialize the ``pad``, ``which`` and ``index`` fields of -struct -:c:type:`v4l2_subdev_mbus_code_enum` and -call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl with a pointer to this -structure. Drivers fill the rest of the structure or return an ``EINVAL`` -error code if either the ``pad`` or ``index`` are invalid. All media bus -formats are enumerable by beginning at index zero and incrementing by -one until ``EINVAL`` is returned. +This call is used by the application to access the enumeration +of media bus formats for the selected pad. + +The enumerations are defined by the driver, and indexed using the ``index`` field +of struct :c:type:`v4l2_subdev_mbus_code_enum`. +Each enumeration starts with the ``index`` of 0, and +the lowest invalid index marks the end of enumeration. + +Therefore, to enumerate media bus formats available at a given sub-device pad, +initialize the ``pad``, and ``which`` fields to desired values, +and set ``index`` to 0. +Then call the :ref:`VIDIOC_SUBDEV_ENUM_MBUS_CODE` ioctl +with a pointer to this structure. + +A successful call will return with the ``code`` field filled in +with a mbus code value. +Repeat with increasing ``index`` until ``EINVAL`` is received. +``EINVAL`` means that either ``pad`` is invalid, +or that there are no more codes available at this pad. + +The driver must not return the same value of ``code`` for different indices +at the same pad. Available media bus formats may depend on the current 'try' formats at other pads of the sub-device, as well as on the current active links. @@ -57,14 +70,15 @@ information about the try formats. * - __u32 - ``pad`` - - Pad number as reported by the media controller API. + - Pad number as reported by the media controller API. Filled in by the application. * - __u32 - ``index`` - - Number of the format in the enumeration, set by the application. + - Index of the mbus code in the enumeration belonging to the given pad. + Filled in by the application. * - __u32 - ``code`` - The media bus format code, as defined in - :ref:`v4l2-mbus-format`. + :ref:`v4l2-mbus-format`. Filled in by the driver. * - __u32 - ``which`` - Media bus format codes to be enumerated, from enum