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

[Loic Poulain]

On Mon, Mar 30, 2026 at 4:33 PM Bryan O'Donoghue <bod@xxxxxxxxxx> wrote:
>
> On 30/03/2026 15:27, johannes.goede@xxxxxxxxxxxxxxxx wrote:
> >> 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.
> > CDM is a much lower-level API then what is expected from
> > a media-controller centric V4L2 driver. Basically the OPE
> > driver will export:
>
> My concern is about wrappering one thing inside of another thing and
> then stuffing it again back into CDM and doing the same on the way out.

I think there will always be some level of copying involved. That
said, we can pre‑build the CDM sequence in the drivers and only update
the variable values, which should avoid significant overhead.

If we start handling CDM formats directly on the user side, it would
require exposing a lot of low‑level knowledge there (such as register
layouts and offsets), and that would diverge from how other ISP
implementations are structured. I’m concerned this would increase
complexity and reduce portability.

> There are already 50 MMIO writes in the OPE ISR, I don't believe it is
> sustainable to keep adding MMIO into that.

Yes, I understand the concern. From our testing so far, however, this
has not shown to be an issue. In addition, a full reconfiguration
would only happen in specific cases, such as on explicit full
configuration changes or during context switching. We can certainly
look at implementing CDM, but at this stage it didn't seem to bring
significant benefits, so I prefered to focus on other functional
aspects, and revisit CDM once there is a clearer need, measurable
gain, or if it becomes part of the uAPI as discussed here.

> I'm aware of a project in qcom that did something with making the CDM
> format in libcamera and handed that off to kernel, recommend looking
> into that.

I will, thanks, I'm however, concerned about how acceptable this
approach would be to the wider community and to the maintainers.

Regards,
Loic