On Mon, Apr 27, 2026 at 4:22 PM Konrad Dybcio <[email protected]> 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 <[email protected]> > > --- > > [...] > > > + 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
