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

[Bryan O'Donoghue]

On 30/03/2026 14:46, johannes.goede@xxxxxxxxxxxxxxxx wrote:
> > > And then your CCMv1 or CCMv2 helper will get called with
> > > the matching parameter-data.
> > This leads to userspace having to know exact format for each hardware
> > version, which is not nice. At the very least it should be possible to
> > accept CCMv1 buffers and covert them to CCMv2 when required.
> Yes, but a new ISP may also have a different pipeline altogether
> with e.g. more then one preview/viewfinder output vs one viewfinder
> output for current hw, etc.

My scoping on HFI shows that the IQ structures between Kona and later 
versions have pretty stable data-structures.

It might be worthwhile for the non-HFI version to implement those 
structures.

I keep mentioning CDM. Its also possible to construct the buffer in the 
format the CDM would require and hand that from user-space into the kernel.

That would save alot of overhead translating from one format to another.

That's another reason I bring up CDM again and again. We probably don't 
want to fix to the wrong format for OPE, introduce the CDM and then find 
we have to map from one format to another for large and complex data 
over and over again for each frame or every N frames.

TBH I think the CDM should happen for this system and in that vein is 
there any reason not to pack the data in the order the CDM will want ?

So probably in fact IQ structs are not the right thing for OPE+IFE.

---
bod