From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D525C433E6 for ; Fri, 28 Aug 2020 10:50:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4429F2086A for ; Fri, 28 Aug 2020 10:50:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729153AbgH1Kus (ORCPT ); Fri, 28 Aug 2020 06:50:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728362AbgH1Kur (ORCPT ); Fri, 28 Aug 2020 06:50:47 -0400 Received: from hillosipuli.retiisi.org.uk (hillosipuli.retiisi.org.uk [IPv6:2a01:4f9:c010:4572::81:2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8D36C061264; Fri, 28 Aug 2020 03:50:46 -0700 (PDT) Received: from valkosipuli.localdomain (valkosipuli.retiisi.org.uk [IPv6:2a01:4f9:c010:4572::80:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by hillosipuli.retiisi.org.uk (Postfix) with ESMTPS id 19C78634C87; Fri, 28 Aug 2020 13:50:41 +0300 (EEST) Received: from sailus by valkosipuli.localdomain with local (Exim 4.92) (envelope-from ) id 1kBbxx-0000N6-0o; Fri, 28 Aug 2020 13:50:41 +0300 Date: Fri, 28 Aug 2020 13:50:41 +0300 From: Sakari Ailus To: Mauro Carvalho Chehab Cc: Linux Doc Mailing List , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-media@vger.kernel.org Subject: Re: [PATCH v10 3/4] media: docs: add glossary.rst with common terms used at V4L2 spec Message-ID: <20200828105040.GA844@valkosipuli.retiisi.org.uk> References: <20200827110811.GC851@valkosipuli.retiisi.org.uk> <20200828111100.669767fa@coco.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200828111100.669767fa@coco.lan> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mauro, On Fri, Aug 28, 2020 at 11:11:00AM +0200, Mauro Carvalho Chehab wrote: > Em Thu, 27 Aug 2020 14:08:11 +0300 > Sakari Ailus escreveu: > > > > + MC-centric > > > + :term:`V4L2 hardware` that requires a :term:`MC API`. > > > + > > > + Such hardware have ``V4L2_CAP_IO_MC`` device_caps field set > > > + (see :ref:`VIDIOC_QUERYCAP`). > > > + > > > + See :ref:`v4l2_hardware_control` for more details. > > > > I think this should be documented as referring to drivers, for it's a > > property of a driver, not hardware. > > > > There is hardware that better fits for MC-enabled drivers but still has > > V4L2-centric driver written for it. The matter is further complicated by > > e.g. raw camera systems that may consist of several different kinds of > > devices, including external ISPs. > > > > Say, a simple raw sensor + a CSI-2 receiver would fit for V4L2-centric > > model well, but add a more complex sensor or that external ISP and that no > > longer is the case. The CSI-2 receiver is still the same in both cases > > though. > > > > Similar comment on video-node-centric. > > I guess I got what you meant. I'm folding it with the following diff: > > diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst > index 45f0933e03c0..023bb561c406 100644 > --- a/Documentation/userspace-api/media/glossary.rst > +++ b/Documentation/userspace-api/media/glossary.rst > @@ -138,9 +138,9 @@ Glossary > See :ref:`media_controller`. > > MC-centric > - :term:`V4L2 hardware` that requires a :term:`MC API`. > + :term:`V4L2 hardware` device driver that requires :term:`MC API`. > > - Such hardware have ``V4L2_CAP_IO_MC`` device_caps field set > + Such drivers have ``V4L2_CAP_IO_MC`` device_caps field set > (see :ref:`VIDIOC_QUERYCAP`). > > See :ref:`v4l2_hardware_control` for more details. > @@ -203,9 +203,9 @@ Glossary > :term:`bridge driver`. See :ref:`subdev`. > > Video-node-centric > - V4L2 hardware that doesn't require a media controller to be used. > + V4L2 device driver that doesn't require a media controller to be used. > > - Such hardware have the ``V4L2_CAP_IO_MC`` device_caps field unset > + Such drivers have the ``V4L2_CAP_IO_MC`` device_caps field unset > (see :ref:`VIDIOC_QUERYCAP`). > > V4L2 Sub-device API Yes, something like that. I also looked at a few more terms such as "V4L2 hardware" that are a bit of an oxymoron. This isn't in current documentation so we should give them a little bit more thought before adding them. I'll reply to the latest patch. -- Kind regards, Sakari Ailus