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

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

On Sun, Apr 05, 2026 at 09:15:47PM +0100, Bryan O'Donoghue wrote:
> On 05/04/2026 21:11, Laurent Pinchart wrote:
> > The mali-c55 driver does this, it translates the ISP parameters buffers
> > to a list of register values in userspace context, when the buffer is
> > queued. In the IRQ handler, it then either copies those values to
> > registers with MMIO writes, or use a DMA engine, depending on the
> > platform. The rppx1 driver does something similar, with a different
> > format for the buffer containing the register values.
> > 
> > I think this architecture could be replicated here. This translation in
> > userspace context ensures that work at IRQ time is limited. The driver
> > can use whatever DMA engine is available depending on the platform, and
> > we can also force usage of MMIO for debugging or development purpose.
> > That way, development of ISP features is decoupled from development of
> > CDM support, enabling parallel development if desired, and faster
> > plaform enablement that allows starting the userspace side of the work
> > quicker.
> 
> I think that's a reasonable plan.
> 
> We make the buffer in user-space which could be used by CDM but stage 
> the implementation.

My proposal is to use an abstraction for the ISP parameters buffer, with
logical parameters, and translate that to the CDM buffer in kernelspace,
but in userspace context instead of IRQ handler context.

> That way if CDM proves too hard, we can do MMIO for a while, and then 
> transition to CDM if/when.
> 
> For me though I really think translating between formats is storing up pain.

-- 
Regards,

Laurent Pinchart