Re: [PATCH 2/2] arm64: dts: qcom: Add cpu scaling clock node

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

On 20.01.2025 11:57 AM, Taniya Das wrote:
> 
> 
> On 1/20/2025 4:06 PM, Dmitry Baryshkov wrote:
>> On Mon, 20 Jan 2025 at 12:34, Taniya Das <quic_tdas@quicinc.com> wrote:
>>>
>>>
>>>
>>> On 1/20/2025 2:16 PM, Dmitry Baryshkov wrote:
>>>>>> This doesn't follow the bindings, does it?
>>>>> I will add and re-use the closest target compatible.
>>>>>
>>>>>>> +          reg = <0 0x18323000 0 0x1400>,
>>>>>>> +                <0 0x18325800 0 0x1400>;
>>>>>>> +          reg-names = "freq-domain0", "freq-domain1";
>>>>>>> +
>>>>>>> +          clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>;
>>>>>>> +          clock-names = "xo", "alternate";
>>>>>> Are the DCVSH interrupts?
>>>>>>
>>>>> This target does not have DCVSH interrupts directly connected to the
>>>>> CPUFREQ-HW.
>>>> So, does it require a separate LMH driver, like the one used for sdm845?
>>>
>>> I will check how it is handled on QCS615 as it is closer to SC7180 and I
>>> didn't see any LMH handling there as well.
>>
>> At least sm6150-thermal.dtsi declares two LMH blocks.
> 
> QCS615 also has 2 LMH blocks, but the handling of interrupts will be done from the LMH driver, integration with CPUFREQ-HW driver is still under evaluation.

Currently platforms from the 8150 era, using drivers/thermal/qcom/lmh.c
expose the LMH device as an irqchip and pass the per-instance IRQ it
provides to cpufreq, instead of the latter directly consuming a GIC irq

Konrad