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.

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.

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.

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.

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

-- 
2.34.1

On 23/03/2026 12:58, Loic Poulain wrote:
> 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.

You need the other 50% of the kernel side - the generation of bayer 
statistics in the IFE, as well as generation of parameters to feed back 
into the OPE - which requires a user-space implementation too, so a lot 
of work there too.

I'd also say when we have an ICP we should be using it via the HFI 
protocol, thus burying all of the IPE/OPE BPS and CDM complexity in the 
firmware.

Understood Agatti has no ICP so you're limited to direct OPE/IFE 
register access here. For HFI capable platforms - the majority - HFI is 
the way to go.

I'll publish an RFC for Hamoa for that soonish so we can make sure both 
coexist.

---
bod

On Tue, Mar 24, 2026 at 1:54 PM Bryan O'Donoghue <bod@kernel.org> wrote:
>
> On 23/03/2026 12:58, Loic Poulain wrote:
> > 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.
>
> You need the other 50% of the kernel side - the generation of bayer
> statistics in the IFE, as well as generation of parameters to feed back
> into the OPE - which requires a user-space implementation too, so a lot
> of work there too.
>
> I'd also say when we have an ICP we should be using it via the HFI
> protocol, thus burying all of the IPE/OPE BPS and CDM complexity in the
> firmware.
>
> Understood Agatti has no ICP so you're limited to direct OPE/IFE
> register access here. For HFI capable platforms - the majority - HFI is
> the way to go.

Fully agree, this is exactly the point where we should sync and work
together on a proper solution.

As a follow‑up to this RFC, I already have several ongoing pieces that
aim to generalize the CAMSS ISP support, and I’d very much like to
discuss them with you:

- camss-isp-m2m: Generic M2M scheduling framework handling job dispatch
based on buffer readiness and enabled endpoints (frame input, output,
statistics, parameters).

- camss-isp-pipeline: Helper layer to construct complex media/ISP graphs
from a structural description (endpoints, links, etc.).

- camss-isp-params: Generic helper for handling ISP parameter buffers
(using v4l2-isp-params).

- camss-isp-stats: Generic helper framework for CAMSS statistics devices.

- camss-(isp-)ope: OPE‑specific logic only (register configuration, IRQ
handling, parameter‑to‑register translation).

This approach should significantly reduce the amount of
platform‑specific code required for future ISP blocks. It should also
allow you to integrate a camss-isp-hamoa (or similar) backend, or even
a camss-isp-hfi implementation for the M2M functions, without
duplicating the infrastructure.

So yes, let’s sync and agree on a shared/open development model and an
overall direction, possibly even a common tree, to ensure we stay
aligned and can collaborate effectively.

>
> I'll publish an RFC for Hamoa for that soonish so we can make sure both
> coexist.

Ack.

Regards,
Loic