Em Thu, 27 Aug 2020 14:08:11 +0300 Sakari Ailus <sakari.ailus@xxxxxx> escreveu: > Hi Mauro, > > On Thu, Aug 27, 2020 at 09:21:47AM +0200, Mauro Carvalho Chehab wrote: > > Add a glossary of terms used within the media userspace API > > documentation, as several concepts are complex enough to cause > > misunderstandings. > > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> > > --- > > .../userspace-api/media/glossary.rst | 216 ++++++++++++++++++ > > Documentation/userspace-api/media/index.rst | 3 + > > 2 files changed, 219 insertions(+) > > create mode 100644 Documentation/userspace-api/media/glossary.rst > > > > diff --git a/Documentation/userspace-api/media/glossary.rst b/Documentation/userspace-api/media/glossary.rst > > new file mode 100644 > > index 000000000000..45f0933e03c0 > > --- /dev/null > > +++ b/Documentation/userspace-api/media/glossary.rst > > @@ -0,0 +1,216 @@ > > +.. SPDX-License-Identifier: GPL-2.0 OR GFDL-1.1-or-later > > + > > +.. For GPL-2.0, see LICENSES/preferred/GPL-2.0 > > +.. > > +.. For GFDL-1.1-or-later, see: > > +.. > > +.. Permission is granted to copy, distribute and/or modify this document > > +.. under the terms of the GNU Free Documentation License, Version 1.1 or > > +.. any later version published by the Free Software Foundation, with no > > +.. Invariant Sections, no Front-Cover Texts and no Back-Cover Texts. > > +.. A copy of the license is included at > > +.. Documentation/userspace-api/media/fdl-appendix.rst. > > + > > +======== > > +Glossary > > +======== > > + > > +.. note:: > > + > > + The goal of this section is to standardize the terms used within the media > > + userspace API documentation. This is Work In Progress. > > + > > +.. Please keep the glossary entries in alphabetical order > > + > > +.. glossary:: > > + > > + Bridge Driver > > + A :term:`device driver` that implements the main logic to talk with > > + media hardware. > > + > > + CEC API > > + **Consumer Electronics Control API** > > + > > + An API designed to receive and transmit data via an HDMI > > + CEC interface. > > + > > + See :ref:`cec`. > > + > > + Device Driver > > + Part of the Linux Kernel that implements support for a hardware > > + component. > > + > > + Device Node > > + A character device node in the file system used to control and > > + transfer data in and out of a Kernel driver. > > + > > + Digital TV API > > + **Previously known as DVB API** > > + > > + An API designed to control a subset of the :term:`Media Hardware` > > + that implements digital TV (e. g. DVB, ATSC, ISDB, etc). > > + > > + See :ref:`dvbapi`. > > + > > + DSP > > + **Digital Signal Processor** > > + > > + A specialized :term:`Microprocessor`, with its architecture > > + optimized for the operational needs of digital signal processing. > > + > > + FPGA > > + **Field-programmable Gate Array** > > + > > + An :term:`IC` circuit designed to be configured by a customer or > > + a designer after manufacturing. > > + > > + See https://en.wikipedia.org/wiki/Field-programmable_gate_array. > > + > > + Hardware Component > > + A subset of the :term:`media hardware`. For example an :term:`I²C` or > > + :term:`SPI` device, or an :term:`IP block` inside an > > + :term:`SoC` or :term:`FPGA`. > > + > > + Hardware Peripheral > > + A group of :term:`hardware components <hardware component>` that > > + together make a larger user-facing functional peripheral. For > > + instance, the :term:`SoC` :term:`ISP` :term:`IP block <ip block>` > > + and the external camera sensors together make a camera hardware > > + peripheral. > > + > > + Also known as :term:`peripheral`. > > + > > + I²C > > + **Inter-Integrated Circuit** > > + > > + A multi-master, multi-slave, packet switched, single-ended, > > + serial computer bus used to control some hardware components > > + like sub-device hardware components. > > + > > + See http://www.nxp.com/docs/en/user-guide/UM10204.pdf. > > + > > + IC > > + **Integrated circuit** > > + > > + A set of electronic circuits on one small flat piece of > > + semiconductor material, normally silicon. > > + > > + Also known as chip. > > + > > + IP Block > > + **Intellectual property core** > > + > > + In electronic design a semiconductor intellectual property core, > > + is a reusable unit of logic, cell, or integrated circuit layout > > + design that is the intellectual property of one party. > > + IP Blocks may be licensed to another party or can be owned > > + and used by a single party alone. > > + > > + See https://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core). > > + > > + ISP > > + **Image Signal Processor** > > + > > + A specialized processor that implements a set of algorithms for > > + processing image data. ISPs may implement algorithms for lens > > + shading correction, demosaicing, scaling and pixel format conversion > > + as well as produce statistics for the use of the control > > + algorithms (e.g. automatic exposure, white balance and focus). > > + > > + Media API > > + A set of userspace APIs used to control the media hardware. It is > > + composed by: > > + > > + - :term:`CEC API`; > > + - :term:`Digital TV API`; > > + - :term:`MC API`; > > + - :term:`RC API`; and > > + - :term:`V4L2 API`. > > + > > + See :doc:`index`. > > + > > + MC API > > + **Media Controller API** > > + > > + An API designed to expose and control the relationships between > > + multimedia devices and sub-devices. > > + > > + See :ref:`media_controller`. > > + > > + 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. Makes sense. Do you have some suggestion for the text?? > > The rest looks fine to me. Ok. Thanks, Mauro
