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@xxxxxxxxxxx> 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
