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

[Loic Poulain]

Hi Laurent,

On Sun, Apr 5, 2026 at 9:48 PM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
>
> On Tue, Mar 24, 2026 at 05:16:21PM +0100, Loic Poulain wrote:
> > On Tue, Mar 24, 2026 at 1:54 PM Bryan O'Donoghue 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.
>
> I don't necessarily agree with that. There are pros and cons for using
> HFI on platforms that have an ICP. If correctly written, a firmware can
> improve the throughput in multi-camera use cases by reprogramming the
> time-multiplexed OPE faster. On the other hand, in use cases that don't
> require pushing the platform to its limits, dealing with a closed-source
> firmware often causes lots of issues.

Yes, we need to further explore the ICP (MCU-based offload) solution
before drawing any conclusions, especially to assess how complex it is
to leverage or bypass. That said, the current platform (Agatti/OPE)
does not support it anyway.

> We should aim at supporting both direct ISP access and HFI with the same
> userspace API, even on a single platform. Which option to start with is
> an open question that we should discuss.
>
> > 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).
>
> This should be generic, not limited to camss. v4l2-isp is a good
> candidate.
>
> > - camss-isp-pipeline: Helper layer to construct complex media/ISP graphs
> > from a structural description (endpoints, links, etc.).
>
> That also doesn't seem specific to camss.

Yes, architecturally this is not CAMSS‑specific. However, the current
implementation may rely on certain assumptions or shortcuts that do
not hold across all general offline ISP use cases. With some effort,
it should be possible to generalize them  [1] [2] .

[1] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-pipeline.c
[2] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-m2m.c

>
> > - camss-isp-params: Generic helper for handling ISP parameter buffers
> > (using v4l2-isp-params).
>
> I'm curious to know what camss-specific helpers you envision there.

Nothing too complex initially, just a parser built on the v4l2‑isp
helpers, along with a few handler callbacks [3]. This is something
I’ll discuss with Bryan, as we definitely want to reuse the same
format and parser for both inline and offline ISPs (as well as for
stats).

[3] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-params.c


>
> > - camss-isp-stats: Generic helper framework for CAMSS statistics devices.
>
> Same.
>
> > - 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.
>
> Let's schedule a call to kickstart those discussions. Many people are on
> Easter vacation this week, next week could be a good candidate.
>
> > > I'll publish an RFC for Hamoa for that soonish so we can make sure both
> > > coexist.