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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

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.

> - 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.

> - 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.
> 
> Ack.

-- 
Regards,

Laurent Pinchart