Messages in this thread |  | | Date | Sun, 5 Apr 2026 22:57:44 +0300 | | From | Laurent Pinchart <> | | Subject | Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support |
| |
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
|  |