From patchwork Fri May 8 13:10:37 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 209892 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=-15.1 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=ham 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 1AEECC38A2A for ; Fri, 8 May 2020 13:10:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E8C13249EC for ; Fri, 8 May 2020 13:10:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588943443; bh=5auvOo0cz4Mvuw96bMWyk5KHEpjwFSVVuFxTn6gbhZo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=DMDR2Fy+rSW0O9eVuM1cuLAYiDyNcPMBj6vgqP5Sp+FP4lxGXgJlyukJ6+Yq/Qto6 gFeDs7RMSIhbVllWng6q8Lu3h1omcltzIcHLrsAMw6Fc0Sy2ES0dCAARFfWbbblfO0 /BtmmVC6/RtzedcM+mDaC/YIdWf+yny4MEHpV/Pw= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730485AbgEHNKn (ORCPT ); Fri, 8 May 2020 09:10:43 -0400 Received: from mail.kernel.org ([198.145.29.99]:60500 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728787AbgEHNKm (ORCPT ); Fri, 8 May 2020 09:10:42 -0400 Received: from mail.kernel.org (ip5f5ad5c5.dynamic.kabel-deutschland.de [95.90.213.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 93A52249D3; Fri, 8 May 2020 13:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588943440; bh=5auvOo0cz4Mvuw96bMWyk5KHEpjwFSVVuFxTn6gbhZo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gX75Ai6Dswv7vYjL4lzKXWXn4NDfjgD9MoKyOMnR5sZ3Z1S3psJ6DrIlf0uL8NAtj VleRZ2XNkl2tCV5bIikX89wy43rysfu01ZJBGOEab1mRry0KpRPKUbEqNevAfwXVgR T/dny8iZ1ovE/VgKe6TkWEAOnH813Rxb0a+UpEyk= Received: from mchehab by mail.kernel.org with local (Exim 4.93) (envelope-from ) id 1jX2ly-000Z9L-HI; Fri, 08 May 2020 15:10:38 +0200 From: Mauro Carvalho Chehab To: Linux Media Mailing List Cc: Mauro Carvalho Chehab , Hans Verkuil , Laurent Pinchart , Sakari Ailus , Hans Verkuil Subject: [PATCH v9 5/5] media: open.rst: document mc-centric and video-node-centric Date: Fri, 8 May 2020 15:10:37 +0200 Message-Id: <4fe37ecf19ad62f3c2ba6af31de81ec724fead16.1588943181.git.mchehab+huawei@kernel.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: References: MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org When we added support for omap3, back in 2010, we added a new type of V4L2 devices that aren't fully controlled via the V4L2 device node. Yet, we have never clearly documented in the V4L2 specification the differences between the two types. Let's document them based on the the current implementation. Signed-off-by: Mauro Carvalho Chehab --- .../userspace-api/media/v4l/open.rst | 54 ++++++++++++++++--- 1 file changed, 48 insertions(+), 6 deletions(-) diff --git a/Documentation/userspace-api/media/v4l/open.rst b/Documentation/userspace-api/media/v4l/open.rst index ee4c8f123815..8a9f766ab855 100644 --- a/Documentation/userspace-api/media/v4l/open.rst +++ b/Documentation/userspace-api/media/v4l/open.rst @@ -13,6 +13,48 @@ Opening and Closing Devices *************************** +.. _v4l2_hardware_control: + +Controlling a hardware peripheral via V4L2 +========================================== + +V4L2 hardware peripheral is usually complex: support for it is +implemented via a bridge driver and often by several additional drivers. +The bridge driver exposes one or more V4L2 device nodes +(see :ref:`v4l2_device_naming`). + +There are other drivers providing support for other components of +the hardware, with may also expose device nodes, called V4L2 sub-devices. + +When such V4L2 sub-devices are exposed, they allow controlling +other hardware components - usually connected via a serial bus (like +I²C, SMBus or SPI). Depending on the bridge driver, those sub-devices +can be controlled indirectly via the bridge driver or explicitly via +the :ref:`Media Controller ` and via the +:ref:`V4L2 sub-devices `. + +The devices that require the use of the +:ref:`Media Controller ` are called **MC-centric** +devices. The devices that are fully controlled via V4L2 device nodes +are called **video-node-centric**. + +Userspace can check if a V4L2 hardware peripheral is MC-centric by +calling :ref:`VIDIOC_QUERYCAP` and checking the +:ref:`device_caps field `. + +If the device returns ``V4L2_CAP_IO_MC`` flag at ``device_caps``, +it is MC-centric, otherwise, it is video-node-centric. + +It is required for MC-centric hardware to identify the V4L2 +sub-devices and to configure the pipelines via the +:ref:`media controller API ` before using the peripheral. +Also, the sub-devices' configuration shall be controlled via the +:ref:`sub-device API `. + +.. note:: + + A video-node-centric may still provide a both media-controller and + sub-device interfaces as well. .. _v4l2_device_naming: @@ -109,7 +151,7 @@ Related Devices Devices can support several functions. For example video capturing, VBI capturing and radio support. -The V4L2 API creates different nodes for each of these functions. +The V4L2 API creates different V4L2 device nodes for each of these functions. The V4L2 API was designed with the idea that one device node could support all functions. However, in practice this never worked: this @@ -119,17 +161,17 @@ switching a device node between different functions only works when using the streaming I/O API, not with the :ref:`read() `/\ :ref:`write() ` API. -Today each device node supports just one function. +Today each V4L2 device node supports just one function. Besides video input or output the hardware may also support audio sampling or playback. If so, these functions are implemented as ALSA PCM devices with optional ALSA audio mixer devices. One problem with all these devices is that the V4L2 API makes no -provisions to find these related devices. Some really complex devices -use the Media Controller (see :ref:`media_controller`) which can be -used for this purpose. But most drivers do not use it, and while some -code exists that uses sysfs to discover related devices (see +provisions to find these related V4L2 device nodes. Some really complex +hardware use the Media Controller (see :ref:`media_controller`) which can +be used for this purpose. But several drivers do not use it, and while some +code exists that uses sysfs to discover related V4L2 device nodes (see libmedia_dev in the `v4l-utils `__ git repository), there is no library yet that can provide a single API