Documentation/admin-guide/media/raspberrypi-pisp-be.rst
Source file repositories/reference/linux-study-clean/Documentation/admin-guide/media/raspberrypi-pisp-be.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/admin-guide/media/raspberrypi-pisp-be.rst- Extension
.rst- Size
- 4660 bytes
- Lines
- 110
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
=========================================================
Raspberry Pi PiSP Back End Memory-to-Memory ISP (pisp-be)
=========================================================
The PiSP Back End
=================
The PiSP Back End is a memory-to-memory Image Signal Processor (ISP) which reads
image data from DRAM memory and performs image processing as specified by the
application through the parameters in a configuration buffer, before writing
pixel data back to memory through two distinct output channels.
The ISP registers and programming model are documented in the `Raspberry Pi
Image Signal Processor (PiSP) Specification document`_
The PiSP Back End ISP processes images in tiles. The handling of image
tessellation and the computation of low-level configuration parameters is
realized by a free software library called `libpisp
<https://github.com/raspberrypi/libpisp>`_.
The full image processing pipeline, which involves capturing RAW Bayer data from
an image sensor through a MIPI CSI-2 compatible capture interface, storing them
in DRAM memory and processing them in the PiSP Back End to obtain images usable
by an application is implemented in `libcamera <https://libcamera.org>`_ as
part of the Raspberry Pi platform support.
The pisp-be driver
==================
The Raspberry Pi PiSP Back End (pisp-be) driver is located under
drivers/media/platform/raspberrypi/pisp-be. It uses the `V4L2 API` to register
a number of video capture and output devices, the `V4L2 subdev API` to register
a subdevice for the ISP that connects the video devices in a single media graph
realized using the `Media Controller (MC) API`.
The media topology registered by the `pisp-be` driver is represented below:
.. _pips-be-topology:
.. kernel-figure:: raspberrypi-pisp-be.dot
:alt: Diagram of the default media pipeline topology
:align: center
The media graph registers the following video device nodes:
- pispbe-input: output device for images to be submitted to the ISP for
processing.
- pispbe-tdn_input: output device for temporal denoise.
- pispbe-stitch_input: output device for image stitching (HDR).
- pispbe-output0: first capture device for processed images.
- pispbe-output1: second capture device for processed images.
- pispbe-tdn_output: capture device for temporal denoise.
- pispbe-stitch_output: capture device for image stitching (HDR).
- pispbe-config: output device for ISP configuration parameters.
pispbe-input
------------
Images to be processed by the ISP are queued to the `pispbe-input` output device
node. For a list of image formats supported as input to the ISP refer to the
`Raspberry Pi Image Signal Processor (PiSP) Specification document`_.
pispbe-tdn_input, pispbe-tdn_output
-----------------------------------
The `pispbe-tdn_input` output video device receives images to be processed by
the temporal denoise block which are captured from the `pispbe-tdn_output`
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.