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

[Loic Poulain]

On Tue, Mar 24, 2026 at 1:54 PM Bryan O'Donoghue <bod@xxxxxxxxxx> 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