Re: [PATCH v2 10/14] dt-bindings: media: qcom: Add CAMSS Offline Processing Engine (OPE)

[Loic Poulain]

On Mon, Apr 27, 2026 at 4:22 PM Konrad Dybcio
<konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
>
> On 4/27/26 2:43 PM, Loic Poulain wrote:
> > Add Devicetree binding documentation for the Qualcomm Camera Subsystem
> > Offline Processing Engine (OPE) found on platforms such as Agatti.
> > The OPE is a memory-to-memory image processing block which operates
> > on frames read from and written back to system memory.
> >
> > Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxxxxxxxxx>
> > ---
>
> [...]
>
> > +        clocks = <&gcc GCC_CAMSS_OPE_CLK>,
> > +                 <&gcc GCC_CAMSS_OPE_AHB_CLK>,
> > +                 <&gcc GCC_CAMSS_NRT_AXI_CLK>;
>
> Should the two AXI clocks be aggregated by camss-top instead?
>
> Otherwise we run the risk of the OPE driver setting a rate of A
> and another sub-device setting a rate of B

On qcm2290, OPE appears to be the only consumer of the NRT AXI clock,
while the capture path (VFE/TFE) relies on the RT AXI clock. That
said, this may not always be the case and these clocks (AXI / NRT‑AXI
/ RT‑AXI) seem like they could reasonably be managed at the
camss-bus/top level.

The open question is how the NRT AXI clock should be enabled when
required? enabling them unconditionally (similar to other camss PM
clocks), introducing a dedicated CAMSS top‑level interface for voting,
or leveraging an existing framework to handle this?

Regards,
Loic