Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support

[Laurent Pinchart]

Hi Loic,

I'm really happy to see this on the list :-)

On Mon, Mar 23, 2026 at 01:58:21PM +0100, Loic Poulain wrote:
> This RFC series introduces initial support for the Qualcomm CAMSS
> Offline Processing Engine (OPE), as found on Agatti-based platforms.
> Boards such as Arduino UNO-Q use this SoC family and will benefit
> from hardware-assisted image processing enabled by this work.
> 
> This represents the first step toward enabling image processing beyond
> raw capture on Qualcomm platforms by using hardware blocks for
> operations such as debayering, 3A, and scaling.

I assume you mean colour gains instead of 3A, based on what I can see in
the driver. I'm looking forward to hardware support for the rest of the
3A :-)

> The OPE sits outside the live capture pipeline. It operates on frames
> fetched from system memory and writes processed results back to memory.
> Because of this design, the OPE is not tied to any specific capture
> interface: frames may come from CAMSS RDI or PIX paths, or from any
> other producer capable of providing memory-backed buffers.
> 
> The hardware can sustain up to 580 megapixels per second, which is
> sufficient to process a 10MPix stream at 60 fps or to handle four
> parallel 2MPix (HD) streams at 60 fps.

Isn't 10 MPix/frame * 60 fps = 600 MPix/s, higher than 580 MPix/s ?

> The initial driver implementation relies on the V4L2 m2m framework
> to keep the design simple while already enabling practical offline
> processing workflows. This model also provides time-sharing across
> multiple contexts through its built-in scheduling.

I understand this decision, but that will need to change. In order to
enable support for more ISP processing blocks, we will need to introduce
parameter buffers. The rkisp1 and mali-c55 drivers are two examples of
how it can be done. If you need any help, please don't hesitate to reach
out.

> This first version is intentionally minimalistic. It provides a working
> configuration using a fixed set of static processing parameters, mainly
> to achieve correct and good-quality debayering.
> 
> Support for more advanced use-cases (dynamic parameters, statistics
> outputs, additional data endpoints) will require evolving the driver
> model beyond a pure m2m design. This may involve either moving away
> from m2m, as other ISP drivers do, or extending it to support auxiliary
> endpoints for parameters and statistics.

Ah, I should have read this before writing the above :-) Let's align the
userspace API of driver with the other ISP drivers.

> This series includes:
>   - dt-binding schema for CAMSS OPE
>   - initial CAMSS OPE driver
>   - QCM2290 device tree node describing the hardware block.
> 
> Feedback on the architecture and expected uAPI direction is especially
> welcome.
> 
> Loic Poulain (3):
>   dt-bindings: media: qcom: Add CAMSS Offline Processing Engine (OPE)
>   media: qcom: camss: Add CAMSS Offline Processing Engine driver
>   arm64: dts: qcom: qcm2290: Add CAMSS OPE node
> 
>  .../bindings/media/qcom,camss-ope.yaml        |   87 +
>  arch/arm64/boot/dts/qcom/agatti.dtsi          |   72 +
>  drivers/media/platform/qcom/camss/Makefile    |    4 +
>  drivers/media/platform/qcom/camss/camss-ope.c | 2058 +++++++++++++++++
>  4 files changed, 2221 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/qcom,camss-ope.yaml
>  create mode 100644 drivers/media/platform/qcom/camss/camss-ope.c

-- 
Regards,

Laurent Pinchart