Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver

Hi Dmitry,

On 24-Mar-26 22:27, Dmitry Baryshkov wrote:

On Tue, Mar 24, 2026 at 11:00:21AM +0000, Bryan O'Donoghue wrote:

quoted

On 23/03/2026 15:31, Loic Poulain wrote:

<snip>

quoted

quoted

As far as I understand, CDM could also be implemented in a generic way
within CAMSS, since other CAMSS blocks make use of CDM as well.
This is something we should discuss further.

My concern is even conservatively if each module adds another 10 ? writes by
the time we get to denoising, sharpening, lens shade correction, those
writes could easily look more like 100.

What user-space should submit is well documented data-structures which then
get translated into CDM buffers by the OPE and IFE for the various bits of
the pipeline.

I hope here you have accent on the well-documented (ideally some kind of
the vendor-independent ABI).

The plan is to use the new extensible generic v4l2 ISP parameters
API for this:

https://docs.kernel.org/6.19/driver-api/media/v4l2-isp.html

What this does is basically divide the parameter buffer (which
is just a mmap-able bunch of bytes) into variable sized packets/
blocks with each block having a small header, with a type field.

And then we can have say CCMv1 type for the CCM on the OPE and
if with some future hardware the format of the CCM (say different
fixpoint format) ever changes we can simply define a new CCMv2
and then the parameter buffer can be filled with different
versions of different parameter blocks depending on the hw.

And on the kernel side there are helpers to parse this, you
simply pass a list of the types the current hw supports
+ per type data-callback functions.

And then your CCMv1 or CCMv2 helper will get called with
the matching parameter-data.

So this way we can easily add new hw support without needing
to change the existing API, we can simply extend the list
of parameter types as needed.

Regards,

Hans