Patch Detail
Show a patch.
GET /api/1.1/patches/20954/?format=api
{ "id": 20954, "url": "https://patchwork.libcamera.org/api/1.1/patches/20954/?format=api", "web_url": "https://patchwork.libcamera.org/patch/20954/", "project": { "id": 1, "url": "https://patchwork.libcamera.org/api/1.1/projects/1/?format=api", "name": "libcamera", "link_name": "libcamera", "list_id": "libcamera_core", "list_email": "libcamera-devel@lists.libcamera.org", "web_url": "", "scm_url": "", "webscm_url": "" }, "msgid": "<20240819160921.468981-6-dan.scally@ideasonboard.com>", "date": "2024-08-19T16:09:19", "name": "[v3,5/7] Documentation: Remove libcamera architecture from introduction.rst", "commit_ref": null, "pull_url": null, "state": "superseded", "archived": false, "hash": "bb208178d1872892f0d07fe2b09185bcfd291741", "submitter": { "id": 156, "url": "https://patchwork.libcamera.org/api/1.1/people/156/?format=api", "name": "Dan Scally", "email": "dan.scally@ideasonboard.com" }, "delegate": null, "mbox": "https://patchwork.libcamera.org/patch/20954/mbox/", "series": [ { "id": 4527, "url": "https://patchwork.libcamera.org/api/1.1/series/4527/?format=api", "web_url": "https://patchwork.libcamera.org/project/libcamera/list/?series=4527", "date": "2024-08-19T16:09:14", "name": "Documentation improvements", "version": 3, "mbox": "https://patchwork.libcamera.org/series/4527/mbox/" } ], "comments": "https://patchwork.libcamera.org/api/patches/20954/comments/", "check": "pending", "checks": "https://patchwork.libcamera.org/api/patches/20954/checks/", "tags": {}, "headers": { "Return-Path": "<libcamera-devel-bounces@lists.libcamera.org>", "X-Original-To": "parsemail@patchwork.libcamera.org", "Delivered-To": "parsemail@patchwork.libcamera.org", "Received": [ "from lancelot.ideasonboard.com (lancelot.ideasonboard.com\n\t[92.243.16.209])\n\tby patchwork.libcamera.org (Postfix) with ESMTPS id DE234BDB13\n\tfor <parsemail@patchwork.libcamera.org>;\n\tMon, 19 Aug 2024 16:09:52 +0000 (UTC)", "from lancelot.ideasonboard.com (localhost [IPv6:::1])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTP id 03B35633C1;\n\tMon, 19 Aug 2024 18:09:48 +0200 (CEST)", "from perceval.ideasonboard.com (perceval.ideasonboard.com\n\t[IPv6:2001:4b98:dc2:55:216:3eff:fef7:d647])\n\tby lancelot.ideasonboard.com (Postfix) with ESMTPS id 168E4633C1\n\tfor <libcamera-devel@lists.libcamera.org>;\n\tMon, 19 Aug 2024 18:09:37 +0200 (CEST)", "from mail.ideasonboard.com\n\t(cpc141996-chfd3-2-0-cust928.12-3.cable.virginm.net [86.13.91.161])\n\tby perceval.ideasonboard.com (Postfix) with ESMTPSA id B11915A5;\n\tMon, 19 Aug 2024 18:08:35 +0200 (CEST)" ], "Authentication-Results": "lancelot.ideasonboard.com; dkim=pass (1024-bit key;\n\tunprotected) header.d=ideasonboard.com header.i=@ideasonboard.com\n\theader.b=\"iFX4TQKw\"; dkim-atps=neutral", "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com;\n\ts=mail; t=1724083715;\n\tbh=TrDc01eO9c+sVGG5O8dzL1QpNFMM5onIzd0IOK2lLR4=;\n\th=From:To:Cc:Subject:Date:In-Reply-To:References:From;\n\tb=iFX4TQKw7jz1uccpsQBP8nlUsqH6ZxC2MEoYAKGBBGgnrCYMRe83V8roTJn36jOJO\n\t0xe2dfuAS6Oxt93YcgUt7BvP7dQkrzdwwR0aN/1u4sRqNJ3O+AukJhyR2qFnfu/4wv\n\tgb+39TIxvc4p4OuCbH2a+TmgNxBe42Sr/Xb4XMQk=", "From": "Daniel Scally <dan.scally@ideasonboard.com>", "To": "libcamera-devel@lists.libcamera.org", "Cc": "Daniel Scally <dan.scally@ideasonboard.com>", "Subject": "[PATCH v3 5/7] Documentation: Remove libcamera architecture from\n\tintroduction.rst", "Date": "Mon, 19 Aug 2024 17:09:19 +0100", "Message-Id": "<20240819160921.468981-6-dan.scally@ideasonboard.com>", "X-Mailer": "git-send-email 2.34.1", "In-Reply-To": "<20240819160921.468981-1-dan.scally@ideasonboard.com>", "References": "<20240819160921.468981-1-dan.scally@ideasonboard.com>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-BeenThere": "libcamera-devel@lists.libcamera.org", "X-Mailman-Version": "2.1.29", "Precedence": "list", "List-Id": "<libcamera-devel.lists.libcamera.org>", "List-Unsubscribe": "<https://lists.libcamera.org/options/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=unsubscribe>", "List-Archive": "<https://lists.libcamera.org/pipermail/libcamera-devel/>", "List-Post": "<mailto:libcamera-devel@lists.libcamera.org>", "List-Help": "<mailto:libcamera-devel-request@lists.libcamera.org?subject=help>", "List-Subscribe": "<https://lists.libcamera.org/listinfo/libcamera-devel>,\n\t<mailto:libcamera-devel-request@lists.libcamera.org?subject=subscribe>", "Errors-To": "libcamera-devel-bounces@lists.libcamera.org", "Sender": "\"libcamera-devel\" <libcamera-devel-bounces@lists.libcamera.org>" }, "content": "The libcamera Architecture section of the introduction is largely a\nduplicate of the section broken out from docs.rst. Remove it from the\nintroduction.rst file and consolidate anything that wasn't duplicated\ninto libcamera_architecture.rst. Take the opportunity to expand the\nlist of Platform Support which is now a bit out of date.\n\nSigned-off-by: Daniel Scally <dan.scally@ideasonboard.com>\n---\nChanges since v2:\n\n\t- Reworked to change libcamera architecture section instead of camera\n\t stack. DDropped R-b\n\t- Updated the list of supported platforms on the new libcamera\n\t architecture page\n\nChanges since v1:\n\n\t- None\n\n Documentation/guides/introduction.rst | 156 +-------------\n Documentation/libcamera_architecture.rst | 261 ++++++++++++-----------\n 2 files changed, 141 insertions(+), 276 deletions(-)", "diff": "diff --git a/Documentation/guides/introduction.rst b/Documentation/guides/introduction.rst\nindex d1e67654..12d1b7d4 100644\n--- a/Documentation/guides/introduction.rst\n+++ b/Documentation/guides/introduction.rst\n@@ -26,10 +26,8 @@ desirable results from the camera.\n .. _Media Controller: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/mediactl/media-controller.html\n \n \n-In this developers guide, we will explore the internal `Architecture`_ of\n-the libcamera library with its components. The current `Platform Support`_ is\n-detailed, as well as an overview of the `Licensing`_ requirements of the\n-project.\n+In this developers guide the `Licensing`_ requirements of the project are\n+detailed.\n \n This introduction is followed by a walkthrough tutorial to newcomers wishing to\n support a new platform with the `Pipeline Handler Writers Guide`_ and for those\n@@ -41,156 +39,6 @@ provides a tutorial of the key APIs exposed by libcamera.\n \n .. TODO: Correctly link to the other articles of the guide\n \n-Architecture\n-------------\n-\n-While offering a unified API towards upper layers, and presenting itself as a\n-single library, libcamera isn't monolithic. It exposes multiple components\n-through its public API and is built around a set of separate helpers internally.\n-Hardware abstractions are handled through the use of device-specific components\n-where required and dynamically loadable plugins are used to separate image\n-processing algorithms from the core libcamera codebase.\n-\n-::\n-\n- --------------------------< libcamera Public API >---------------------------\n- ^ ^\n- | |\n- v v\n- +-------------+ +---------------------------------------------------+\n- | Camera | | Camera Device |\n- | Manager | | +-----------------------------------------------+ |\n- +-------------+ | | Device-Agnostic | |\n- ^ | | | |\n- | | | +--------------------------+ |\n- | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n- | | | | { +-----------------+ } |\n- | | | | } | //// Image //// | { |\n- | | | | <-> | / Processing // | } |\n- | | | | } | / Algorithms // | { |\n- | | | | { +-----------------+ } |\n- | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n- | | | | ========================== |\n- | | | | +-----------------+ |\n- | | | | | // Pipeline /// | |\n- | | | | <-> | /// Handler /// | |\n- | | | | | /////////////// | |\n- | | +--------------------+ +-----------------+ |\n- | | Device-Specific |\n- | +---------------------------------------------------+\n- | ^ ^\n- | | |\n- v v v\n- +--------------------------------------------------------------------+\n- | Helpers and Support Classes |\n- | +-------------+ +-------------+ +-------------+ +-------------+ |\n- | | MC & V4L2 | | Buffers | | Sandboxing | | Plugins | |\n- | | Support | | Allocator | | IPC | | Manager | |\n- | +-------------+ +-------------+ +-------------+ +-------------+ |\n- | +-------------+ +-------------+ |\n- | | Pipeline | | ... | |\n- | | Runner | | | |\n- | +-------------+ +-------------+ |\n- +--------------------------------------------------------------------+\n-\n- /// Device-Specific Components\n- ~~~ Sandboxing\n-\n-\n-Camera Manager\n- The Camera Manager enumerates cameras and instantiates Pipeline Handlers to\n- manage each Camera that libcamera supports. The Camera Manager supports\n- hotplug detection and notification events when supported by the underlying\n- kernel devices.\n-\n- There is only ever one instance of the Camera Manager running per application.\n- Each application's instance of the Camera Manager ensures that only a single\n- application can take control of a camera device at once.\n-\n- Read the `Camera Manager API`_ documentation for more details.\n-\n-.. _Camera Manager API: https://libcamera.org/api-html/classlibcamera_1_1CameraManager.html\n-\n-Camera Device\n- The Camera class represents a single item of camera hardware that is capable\n- of producing one or more image streams, and provides the API to interact with\n- the underlying device.\n-\n- If a system has multiple instances of the same hardware attached, each has its\n- own instance of the camera class.\n-\n- The API exposes full control of the device to upper layers of libcamera through\n- the public API, making it the highest level object libcamera exposes, and the\n- object that all other API operations interact with from configuration to\n- capture.\n-\n- Read the `Camera API`_ documentation for more details.\n-\n-.. _Camera API: https://libcamera.org/api-html/classlibcamera_1_1Camera.html\n-\n-Pipeline Handler\n- The Pipeline Handler manages the complex pipelines exposed by the kernel\n- drivers through the Media Controller and V4L2 APIs. It abstracts pipeline\n- handling to hide device-specific details from the rest of the library, and\n- implements both pipeline configuration based on stream configuration, and\n- pipeline runtime execution and scheduling when needed by the device.\n-\n- The Pipeline Handler lives in the same process as the rest of the library, and\n- has access to all helpers and kernel camera-related devices.\n-\n- Hardware abstraction is handled by device specific Pipeline Handlers which are\n- derived from the Pipeline Handler base class allowing commonality to be shared\n- among the implementations.\n-\n- Derived pipeline handlers create Camera device instances based on the devices\n- they detect and support on the running system, and are responsible for\n- managing the interactions with a camera device.\n-\n- More details can be found in the `PipelineHandler API`_ documentation, and the\n- `Pipeline Handler Writers Guide`_.\n-\n-.. _PipelineHandler API: https://libcamera.org/api-html/classlibcamera_1_1PipelineHandler.html\n-\n-Image Processing Algorithms\n- An image processing algorithm (IPA) component is a loadable plugin that\n- implements 3A (Auto-Exposure, Auto-White Balance, and Auto-Focus) and other\n- algorithms.\n-\n- The algorithms run on the CPU and interact with the camera devices through the\n- Pipeline Handler to control hardware image processing based on the parameters\n- supplied by upper layers, maintaining state and closing the control loop\n- of the ISP.\n-\n- The component is sandboxed and can only interact with libcamera through the\n- API provided by the Pipeline Handler and an IPA has no direct access to kernel\n- camera devices.\n-\n- Open source IPA modules built with libcamera can be run in the same process\n- space as libcamera, however external IPA modules are run in a separate process\n- from the main libcamera process. IPA modules have a restricted view of the\n- system, including no access to networking APIs and limited access to file\n- systems.\n-\n- IPA modules are only required for platforms and devices with an ISP controlled\n- by the host CPU. Camera sensors which have an integrated ISP are not\n- controlled through the IPA module.\n-\n-Platform Support\n-----------------\n-\n-The library currently supports the following hardware platforms specifically\n-with dedicated pipeline handlers:\n-\n- - Intel IPU3 (ipu3)\n- - Rockchip RK3399 (rkisp1)\n- - RaspberryPi 3 and 4 (rpi/vc4)\n-\n-Furthermore, generic platform support is provided for the following:\n-\n- - USB video device class cameras (uvcvideo)\n- - iMX7, Allwinner Sun6i (simple)\n- - Virtual media controller driver for test use cases (vimc)\n-\n Licensing\n ---------\n \ndiff --git a/Documentation/libcamera_architecture.rst b/Documentation/libcamera_architecture.rst\nindex 1258db23..699a1347 100644\n--- a/Documentation/libcamera_architecture.rst\n+++ b/Documentation/libcamera_architecture.rst\n@@ -5,134 +5,151 @@\n libcamera Architecture\n ======================\n \n+While offering a unified API towards upper layers, and presenting itself as a\n+single library, libcamera isn't monolithic. It exposes multiple components\n+through its public API and is built around a set of separate helpers internally.\n+Hardware abstractions are handled through the use of device-specific components\n+where required and dynamically loadable plugins are used to separate image\n+processing algorithms from the core libcamera codebase.\n+\n ::\n \n- ---------------------------< libcamera Public API >---------------------------\n- ^ ^\n- | |\n- v v\n- +-------------+ +-------------------------------------------------+\n- | Camera | | Camera Device |\n- | Devices | | +---------------------------------------------+ |\n- | Manager | | | Device-Agnostic | |\n- +-------------+ | | | |\n- ^ | | +------------------------+ |\n- | | | | ~~~~~~~~~~~~~~~~~~~~~ |\n- | | | | { +---------------+ } |\n- | | | | } | ////Image//// | { |\n- | | | | <-> | /Processing// | } |\n- | | | | } | /Algorithms// | { |\n- | | | | { +---------------+ } |\n- | | | | ~~~~~~~~~~~~~~~~~~~~~ |\n- | | | | ======================== |\n- | | | | +---------------+ |\n- | | | | | //Pipeline/// | |\n- | | | | <-> | ///Handler/// | |\n- | | | | | ///////////// | |\n- | | +--------------------+ +---------------+ |\n- | | Device-Specific |\n- | +-------------------------------------------------+\n- | ^ ^\n- | | |\n- v v v\n- +--------------------------------------------------------------------+\n- | Helpers and Support Classes |\n- | +-------------+ +-------------+ +-------------+ +-------------+ |\n- | | MC & V4L2 | | Buffers | | Sandboxing | | Plugins | |\n- | | Support | | Allocator | | IPC | | Manager | |\n- | +-------------+ +-------------+ +-------------+ +-------------+ |\n- | +-------------+ +-------------+ |\n- | | Pipeline | | ... | |\n- | | Runner | | | |\n- | +-------------+ +-------------+ |\n- +--------------------------------------------------------------------+\n-\n- /// Device-Specific Components\n- ~~~ Sandboxing\n-\n-While offering a unified API towards upper layers, and presenting\n-itself as a single library, libcamera isn't monolithic. It exposes\n-multiple components through its public API, is built around a set of\n-separate helpers internally, uses device-specific components and can\n-load dynamic plugins.\n-\n-Camera Devices Manager\n- The Camera Devices Manager provides a view of available cameras\n- in the system. It performs cold enumeration and runtime camera\n- management, and supports a hotplug notification mechanism in its\n- public API.\n-\n- To avoid the cost associated with cold enumeration of all devices\n- at application start, and to arbitrate concurrent access to camera\n- devices, the Camera Devices Manager could later be split to a\n- separate service, possibly with integration in platform-specific\n- device management.\n+ --------------------------< libcamera Public API >---------------------------\n+ ^ ^\n+ | |\n+ v v\n+ +-------------+ +---------------------------------------------------+\n+ | Camera | | Camera Device |\n+ | Manager | | +-----------------------------------------------+ |\n+ +-------------+ | | Device-Agnostic | |\n+ ^ | | | |\n+ | | | +--------------------------+ |\n+ | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n+ | | | | { +-----------------+ } |\n+ | | | | } | //// Image //// | { |\n+ | | | | <-> | / Processing // | } |\n+ | | | | } | / Algorithms // | { |\n+ | | | | { +-----------------+ } |\n+ | | | | ~~~~~~~~~~~~~~~~~~~~~~~ |\n+ | | | | ========================== |\n+ | | | | +-----------------+ |\n+ | | | | | // Pipeline /// | |\n+ | | | | <-> | /// Handler /// | |\n+ | | | | | /////////////// | |\n+ | | +--------------------+ +-----------------+ |\n+ | | Device-Specific |\n+ | +---------------------------------------------------+\n+ | ^ ^\n+ | | |\n+ v v v\n+ +--------------------------------------------------------------------+\n+ | Helpers and Support Classes |\n+ | +-------------+ +-------------+ +-------------+ +-------------+ |\n+ | | MC & V4L2 | | Buffers | | Sandboxing | | Plugins | |\n+ | | Support | | Allocator | | IPC | | Manager | |\n+ | +-------------+ +-------------+ +-------------+ +-------------+ |\n+ | +-------------+ +-------------+ |\n+ | | Pipeline | | ... | |\n+ | | Runner | | | |\n+ | +-------------+ +-------------+ |\n+ +--------------------------------------------------------------------+\n+\n+ /// Device-Specific Components\n+ ~~~ Sandboxing\n+\n+\n+Camera Manager\n+ The Camera Manager enumerates cameras and instantiates Pipeline Handlers to\n+ manage each Camera that libcamera supports. The Camera Manager supports\n+ hotplug detection and notification events when supported by the underlying\n+ kernel devices.\n+\n+ There is only ever one instance of the Camera Manager running per application.\n+ Each application's instance of the Camera Manager ensures that only a single\n+ application can take control of a camera device at once.\n+\n+ Read the `Camera Manager API`_ documentation for more details.\n+\n+.. _Camera Manager API: https://libcamera.org/api-html/classlibcamera_1_1CameraManager.html\n \n Camera Device\n- The Camera Device represents a camera device to upper layers. It\n- exposes full control of the device through the public API, and is\n- thus the highest level object exposed by libcamera.\n+ The Camera class represents a single item of camera hardware that is capable\n+ of producing one or more image streams, and provides the API to interact with\n+ the underlying device.\n+\n+ If a system has multiple instances of the same hardware attached, each has its\n+ own instance of the camera class.\n+\n+ The API exposes full control of the device to upper layers of libcamera through\n+ the public API, making it the highest level object libcamera exposes, and the\n+ object that all other API operations interact with from configuration to\n+ capture.\n \n- Camera Device instances are created by the Camera Devices\n- Manager. An optional function to create new instances could be exposed\n- through the public API to speed up initialization when the upper\n- layer knows how to directly address camera devices present in the\n- system.\n+ Read the `Camera API`_ documentation for more details.\n+\n+.. _Camera API: https://libcamera.org/api-html/classlibcamera_1_1Camera.html\n \n Pipeline Handler\n- The Pipeline Handler manages complex pipelines exposed by the kernel drivers\n- through the Media Controller and V4L2 APIs. It abstracts pipeline handling to\n- hide device-specific details to the rest of the library, and implements both\n- pipeline configuration based on stream configuration, and pipeline runtime\n- execution and scheduling when needed by the device.\n-\n- This component is device-specific and is part of the libcamera code base. As\n- such it is covered by the same free software license as the rest of libcamera\n- and needs to be contributed upstream by device vendors. The Pipeline Handler\n- lives in the same process as the rest of the library, and has access to all\n- helpers and kernel camera-related devices.\n+ The Pipeline Handler manages the complex pipelines exposed by the kernel\n+ drivers through the Media Controller and V4L2 APIs. It abstracts pipeline\n+ handling to hide device-specific details from the rest of the library, and\n+ implements both pipeline configuration based on stream configuration, and\n+ pipeline runtime execution and scheduling when needed by the device.\n+\n+ The Pipeline Handler lives in the same process as the rest of the library, and\n+ has access to all helpers and kernel camera-related devices.\n+\n+ Hardware abstraction is handled by device specific Pipeline Handlers which are\n+ derived from the Pipeline Handler base class allowing commonality to be shared\n+ among the implementations.\n+\n+ Derived pipeline handlers create Camera device instances based on the devices\n+ they detect and support on the running system, and are responsible for\n+ managing the interactions with a camera device.\n+\n+ More details can be found in the `PipelineHandler API`_ documentation, and the\n+ :doc:`Pipeline Handler Writers Guide <guides/pipeline-handler>`.\n+\n+.. _PipelineHandler API: https://libcamera.org/api-html/classlibcamera_1_1PipelineHandler.html\n \n Image Processing Algorithms\n- Together with the hardware image processing and hardware statistics\n- collection, the Image Processing Algorithms implement 3A (Auto-Exposure,\n- Auto-White Balance and Auto-Focus) and other algorithms. They run on the CPU\n- and interact with the kernel camera devices to control hardware image\n- processing based on the parameters supplied by upper layers, closing the\n- control loop of the ISP.\n-\n- This component is device-specific and is loaded as an external plugin. It can\n- be part of the libcamera code base, in which case it is covered by the same\n- license, or provided externally as an open-source or closed-source component.\n-\n- The component is sandboxed and can only interact with libcamera through\n- internal APIs specifically marked as such. In particular it will have no\n- direct access to kernel camera devices, and all its accesses to image and\n- metadata will be mediated by dmabuf instances explicitly passed to the\n- component. The component must be prepared to run in a process separate from\n- the main libcamera process, and to have a very restricted view of the system,\n- including no access to networking APIs and limited access to file systems.\n-\n- The sandboxing mechanism isn't defined by libcamera. One example\n- implementation will be provided as part of the project, and platforms vendors\n- will be able to provide their own sandboxing mechanism as a plugin.\n-\n- libcamera should provide a basic implementation of Image Processing\n- Algorithms, to serve as a reference for the internal API. Device vendors are\n- expected to provide a full-fledged implementation compatible with their\n- Pipeline Handler. One goal of the libcamera project is to create an\n- environment in which the community will be able to compete with the\n- closed-source vendor binaries and develop a high quality open source\n- implementation.\n-\n-Helpers and Support Classes\n- While Pipeline Handlers are device-specific, implementations are expected to\n- share code due to usage of identical APIs towards the kernel camera drivers\n- and the Image Processing Algorithms. This includes without limitation handling\n- of the MC and V4L2 APIs, buffer management through dmabuf, and pipeline\n- discovery, configuration and scheduling. Such code will be factored out to\n- helpers when applicable.\n-\n- Other parts of libcamera will also benefit from factoring code out to\n- self-contained support classes, even if such code is present only once in the\n- code base, in order to keep the source code clean and easy to read. This\n- should be the case for instance for plugin management.\n+ An image processing algorithm (IPA) component is a loadable plugin that\n+ implements 3A (Auto-Exposure, Auto-White Balance, and Auto-Focus) and other\n+ algorithms.\n+\n+ The algorithms run on the CPU and interact with the camera devices through the\n+ Pipeline Handler to control hardware image processing based on the parameters\n+ supplied by upper layers, maintaining state and closing the control loop\n+ of the ISP.\n+\n+ The component is sandboxed and can only interact with libcamera through the\n+ API provided by the Pipeline Handler and an IPA has no direct access to kernel\n+ camera devices.\n+\n+ Open source IPA modules built with libcamera can be run in the same process\n+ space as libcamera, however external IPA modules are run in a separate process\n+ from the main libcamera process. IPA modules have a restricted view of the\n+ system, including no access to networking APIs and limited access to file\n+ systems.\n+\n+ IPA modules are only required for platforms and devices with an ISP controlled\n+ by the host CPU. Camera sensors which have an integrated ISP are not\n+ controlled through the IPA module.\n+\n+Platform Support\n+----------------\n+\n+The library currently supports the following hardware platforms specifically\n+with dedicated pipeline handlers:\n+\n+ - Arm Mali-C55\n+ - Intel IPU3 (ipu3)\n+ - NXP i.MX8MP (imx8-isi and rkisp1)\n+ - Rockchip RK3399 (rkisp1)\n+ - RaspberryPi 3, 4 and zero (rpi/vc4)\n+\n+Furthermore, generic platform support is provided for the following:\n+\n+ - USB video device class cameras (uvcvideo)\n+ - iMX7, IPU6, Allwinner Sun6i (simple)\n+ - Virtual media controller driver for test use cases (vimc)\n", "prefixes": [ "v3", "5/7" ] }