On 4/27/26 10:33 PM, Loic Poulain wrote: > 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?
So, interconnect, or some internal, smaller version of it? Konrad
