From patchwork Thu Aug 24 12:07:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 9919919 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AEF2360349 for ; Thu, 24 Aug 2017 12:07:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 90F6820121 for ; Thu, 24 Aug 2017 12:07:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 857F8285CA; Thu, 24 Aug 2017 12:07:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8DEEA20121 for ; Thu, 24 Aug 2017 12:07:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752370AbdHXMHm (ORCPT ); Thu, 24 Aug 2017 08:07:42 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:35454 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752380AbdHXMHl (ORCPT ); Thu, 24 Aug 2017 08:07:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Sender:Message-Id:Date:Subject:Cc:To: From:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1vPa4WlA9uPSuCnnJGFkXuvG1aX5SPcB8RKVpmEmPOg=; b=iqTkwXcupGvx+DuIdv5tgZgaLZ yS9iG5ySKL4v4kOzLr3uZCq5is87g4gI1TmbnX7xczGGH1XqYwYdtPyKazXj+mPjT95JWMTE9H9SG eHCXmVRbJYtW3qMslHX7C2EvGLn2a8eVzc6YZZ9jIH5tOxJ6afrUQVxp9bLsIuhFB+RAAAeUr9rJt clQuaEqZFj1Kd9HcpWh8DFMOtqzftqOfI0IxRgiJS5pmGZlT2LFwAj+Q7NpmIceNGvTXVeKlpE08Q nDhuXPcrbjotx15FzQrq34D3Toaq/7SiRX7Zm5TvVoJrQDJIdQ5h/sSVbh0ZHuFTbvAUZXYbXMG7j TeWi2pJQ==; Received: from [2804:18:1035:4593:41cf:4173:4909:96b5] (helo=smtp.w2.samsung.com) by bombadil.infradead.org with esmtpsa (Exim 4.87 #1 (Red Hat Linux)) id 1dkqvE-0003Ls-6f; Thu, 24 Aug 2017 12:07:40 +0000 Received: from mchehab by smtp.w2.samsung.com with local (Exim 4.89) (envelope-from ) id 1dkqvA-0007ex-1M; Thu, 24 Aug 2017 09:07:36 -0300 From: Mauro Carvalho Chehab To: Linux Media Mailing List , Linux Doc Mailing List Cc: "mchehab@s-opensource.com" , Mauro Carvalho Chehab , Mauro Carvalho Chehab Subject: [PATCH RFC v2] media: open.rst: document devnode-centric and mc-centric types Date: Thu, 24 Aug 2017 09:07:35 -0300 Message-Id: <779378fa18f93929547665467990ff9284a60521.1503576451.git.mchehab@osg.samsung.com> X-Mailer: git-send-email 2.13.5 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: "mchehab@s-opensource.com" 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 never made it clear, at the V4L2 spec, about the differences between both types. Let's document them with the current implementation. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/v4l/open.rst | 47 +++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/Documentation/media/uapi/v4l/open.rst b/Documentation/media/uapi/v4l/open.rst index afd116edb40d..cf522d9bb53c 100644 --- a/Documentation/media/uapi/v4l/open.rst +++ b/Documentation/media/uapi/v4l/open.rst @@ -6,6 +6,53 @@ Opening and Closing Devices *************************** +Types of V4L2 device control +============================ + +V4L2 devices are usually complex: they're implemented via a main driver and +often several additional drivers. The main driver always exposes one or +more **V4L2 device** devnodes (see :ref:`v4l2_device_naming`). The other +devices are called **V4L2 sub-devices**. They are usually controlled via a +serial bus (I2C or SMBus). + +When V4L2 started, there was only one type of device control. The entire +device was controlled via the **V4L2 device nodes**. We refer to this +kind of control as **V4L2 device-centric** (or, simply, **device-centric**). + +Since the end of 2010, a new type of V4L2 device control was added in order +to support complex devices that are common on embedded systems. Those +devices are controlled mainly via the media controller and sub-devices. +So, they're called: **media controller centric** (or, simply, +"**mc-centric**"). + +On **device-centric** control, the device and their corresponding hardware +pipelines are controlled via the **V4L2 device** node. They may optionally +expose the hardware pipelines via the +:ref:`media controller API `. + +On a **mc-centric**, before using the V4L2 device, it is required to +set the hardware pipelines via the +:ref:`media controller API `. On those devices, the +sub-devices' configuration can be controlled via the +:ref:`sub-device API `, with creates one device node per sub device. + +In summary, on **mc-centric** devices: + +- The **V4L2 device** node is mainly responsible for controlling the + streaming features; +- The **media controller device** is responsible to setup the pipelines + and image settings (like size and format); +- The **V4L2 sub-devices** are responsible for sub-device + specific settings. + +.. note:: + + It is forbidden for **device-centric** devices to expose V4L2 + sub-devices via :ref:`sub-device API `, although this + might change in the future. + + +.. _v4l2_device_naming: Device Naming =============