Re: [RFC PATCH 3/3] arm64: dts: qcom: qcm2290: Add CAMSS OPE node

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 3/23/26 5:31 PM, Loic Poulain wrote:
> Hi Konrad,
> 
> On Mon, Mar 23, 2026 at 2:24 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 3/23/26 1:58 PM, Loic Poulain wrote:
>>> Add the Qualcomm CAMSS Offline Processing Engine (OPE) node for
>>> QCM2290. The OPE is a memory-to-memory image processing block used in
>>> offline imaging pipelines.
>>>
>>> The node includes register regions, clocks, interconnects, IOMMU
>>> mappings, power domains, interrupts, and an associated OPP table.
>>>
>>> At the moment we assign a fixed rate to GCC_CAMSS_AXI_CLK since this
>>> clock is shared across multiple CAMSS components and there is currently
>>> no support for dynamically scaling it.
>>>
>>> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
>>> ---

[...]

>> Similarly, in the arbitrary choice of indices, I think putting "core"
>> first is "neat"
> 
> Ok, I thought alphabetical ordering was preferred?

I believe that was Vladimir's misinterpretation of the DTS coding style
(which is admittedly convoluted so I don't really blame him)


>>> +                     assigned-clocks = <&gcc GCC_CAMSS_AXI_CLK>;
>>> +                     assigned-clock-rates = <300000000>;
>>
>> I really think we shouldn't be doing this here for a clock that covers
>> so much hw
> 
> Yes, so we probably need some camss framework to scale this, or move
> this assigned value to camss main node for now.

We do need some sort of a backfeeding mechanism to let camss aggregate
various requests coming from the clients if we want to prevent having to
run things at TURBO all the time, so resolving that early would be a good
idea, even if a little inconvenient..

[...]

>>> +                             opp-580000000 {
>>> +                                     opp-hz = /bits/ 64 <580000000>;
>>> +                                     required-opps = <&rpmpd_opp_turbo>;
>>> +                                     turbo-mode;
>>
>> Are we going to act on this property? Otherwise I think it's just a naming
>> collision with Qualcomm's TURBO (which may? have previously??? had some
>> special implications)
> 
> 588 MHz is categorized as the "Max Turbo" frequency for the OPE core clock.
> At some point we may want to enable this only under specific conditions.
> For now, the OPE driver does not make use of this property.

Fair, we can always get rid of it later if it turns out unnecessary

Konrad