| Message ID | 20230113145859.82868-1-krzysztof.kozlowski@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | dt-bindings: clock: qcom,a53pll: drop operating-points-v2 | expand |
On 13/01/2023 21:28, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >> The CPU PLL clock node does not use OPP tables (neither driver). > > What device is qcom_a53pll_get_freq_tbl() operating on? On its own, internal table. While of course driver could be converted to operating-points-v2, no one did it within last 5 years, so why it should happen now? Best regards, Krzysztof
On Fri, 13 Jan 2023 15:58:59 +0100, Krzysztof Kozlowski wrote: > The CPU PLL clock node does not use OPP tables (neither driver). > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > --- > Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 2 -- > 1 file changed, 2 deletions(-) > Acked-by: Rob Herring <robh@kernel.org>
Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) > On 13/01/2023 21:28, Stephen Boyd wrote: > > Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) > >> The CPU PLL clock node does not use OPP tables (neither driver). > > > > What device is qcom_a53pll_get_freq_tbl() operating on? > > On its own, internal table. While of course driver could be converted to > operating-points-v2, no one did it within last 5 years, so why it should > happen now? > The property was added mid 2021 by Shawn[1], that's not 5 years ago. I guess there were plans to add an OPP table that never happened[2]? Is Shawn still working on this? If not, we should revert the OPP code out of the driver. [1] https://lore.kernel.org/all/20210704024032.11559-4-shawn.guo@linaro.org/ [2] https://lore.kernel.org/all/20210709021334.GB11342@dragon/
On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: > Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) > > On 13/01/2023 21:28, Stephen Boyd wrote: > > > Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) > > >> The CPU PLL clock node does not use OPP tables (neither driver). > > > > > > What device is qcom_a53pll_get_freq_tbl() operating on? > > > > On its own, internal table. While of course driver could be converted to > > operating-points-v2, no one did it within last 5 years, so why it should > > happen now? > > > > The property was added mid 2021 by Shawn[1], that's not 5 years ago. I > guess there were plans to add an OPP table that never happened[2]? Is > Shawn still working on this? If not, we should revert the OPP code out > of the driver. > @Bryan, what do you think about this? Thanks, Bjorn > [1] https://lore.kernel.org/all/20210704024032.11559-4-shawn.guo@linaro.org/ > [2] https://lore.kernel.org/all/20210709021334.GB11342@dragon/
On 19/01/2023 03:11, Bjorn Andersson wrote: > On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: >> Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) >>> On 13/01/2023 21:28, Stephen Boyd wrote: >>>> Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >>>>> The CPU PLL clock node does not use OPP tables (neither driver). >>>> >>>> What device is qcom_a53pll_get_freq_tbl() operating on? >>> >>> On its own, internal table. While of course driver could be converted to >>> operating-points-v2, no one did it within last 5 years, so why it should >>> happen now? >>> >> >> The property was added mid 2021 by Shawn[1], that's not 5 years ago. I >> guess there were plans to add an OPP table that never happened[2]? Is >> Shawn still working on this? If not, we should revert the OPP code out >> of the driver. >> > > @Bryan, what do you think about this? I'd be in favour of starting the CPR patchset instead, which depends on the opps. I think @Fabien has been waiting on the core 8939 dtsi, I also think the dtsi is close enough to merge that we could reasonably initiate the CPR stuff. --- bod
On 19/01/2023 11:55, Bryan O'Donoghue wrote: > On 19/01/2023 03:11, Bjorn Andersson wrote: >> On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: >>> Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) >>>> On 13/01/2023 21:28, Stephen Boyd wrote: >>>>> Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >>>>>> The CPU PLL clock node does not use OPP tables (neither driver). >>>>> >>>>> What device is qcom_a53pll_get_freq_tbl() operating on? >>>> >>>> On its own, internal table. While of course driver could be converted to >>>> operating-points-v2, no one did it within last 5 years, so why it should >>>> happen now? >>>> >>> >>> The property was added mid 2021 by Shawn[1], that's not 5 years ago. I >>> guess there were plans to add an OPP table that never happened[2]? Is >>> Shawn still working on this? If not, we should revert the OPP code out >>> of the driver. >>> >> >> @Bryan, what do you think about this? > > I'd be in favour of starting the CPR patchset instead, which depends on > the opps. > > I think @Fabien has been waiting on the core 8939 dtsi, I also think the > dtsi is close enough to merge that we could reasonably initiate the CPR > stuff. So you would make use of operating-points-v2 property? Then probably we also miss opp-table, but anyway this patch can be dropped then. Best regards, Krzysztof
On 19/01/2023 11:04, Krzysztof Kozlowski wrote: > On 19/01/2023 11:55, Bryan O'Donoghue wrote: >> On 19/01/2023 03:11, Bjorn Andersson wrote: >>> On Wed, Jan 18, 2023 at 11:11:00AM -0800, Stephen Boyd wrote: >>>> Quoting Krzysztof Kozlowski (2023-01-15 06:35:23) >>>>> On 13/01/2023 21:28, Stephen Boyd wrote: >>>>>> Quoting Krzysztof Kozlowski (2023-01-13 06:58:59) >>>>>>> The CPU PLL clock node does not use OPP tables (neither driver). >>>>>> >>>>>> What device is qcom_a53pll_get_freq_tbl() operating on? >>>>> >>>>> On its own, internal table. While of course driver could be converted to >>>>> operating-points-v2, no one did it within last 5 years, so why it should >>>>> happen now? >>>>> >>>> >>>> The property was added mid 2021 by Shawn[1], that's not 5 years ago. I >>>> guess there were plans to add an OPP table that never happened[2]? Is >>>> Shawn still working on this? If not, we should revert the OPP code out >>>> of the driver. >>>> >>> >>> @Bryan, what do you think about this? >> >> I'd be in favour of starting the CPR patchset instead, which depends on >> the opps. >> >> I think @Fabien has been waiting on the core 8939 dtsi, I also think the >> dtsi is close enough to merge that we could reasonably initiate the CPR >> stuff. > > So you would make use of operating-points-v2 property? Then probably we > also miss opp-table, but anyway this patch can be dropped then. > > Best regards, > Krzysztof > Yep. Looks something like this. CPU2: cpu@102 { device_type = "cpu"; compatible = "arm,cortex-a53", "arm,armv8"; reg = <0x102>; next-level-cache = <&L2_1>; enable-method = "qcom,kpss-acc-v2"; qcom,acc = <&acc2>; qcom,saw = <&saw2>; clocks = <&apcs1>; operating-points-v2 = <&cluster1_opp_table>; power-domains = <&cpr>; power-domain-names = "cpr"; #cooling-cells = <2>; capacity-dmips-mhz = <1024>; }; cluster1_opp_table: cluster1-opp-table { compatible = "operating-points-v2-qcom-cpu"; opp-shared; /* Used by qcom-cpufreq-nvmem.c */ nvmem-cells = <&cpr_efuse_speedbin_pvs>; nvmem-cell-names = "cpr_efuse_speedbin_pvs"; opp-200000000 { opp-hz = /bits/ 64 <200000000>; opp-supported-hw = <0x3f>; required-opps = <&cpr_opp3>; }; opp-345600000 { opp-hz = /bits/ 64 <345600000>; opp-supported-hw = <0x3f>; required-opps = <&cpr_opp3>; }; }; cpr_opp_table: cpr-opp-table { compatible = "operating-points-v2-qcom-level"; cpr_opp1: opp1 { opp-hz = /bits/ 64 <200000000>; opp-level = <1>; qcom,opp-fuse-level = <1>; }; cpr_opp2: opp2 { opp-hz = /bits/ 64 <345600000>; opp-level = <2>; qcom,opp-fuse-level = <1>; }; cpr_opp3: opp3 { opp-hz = /bits/ 64 <400000000>; opp-level = <3>; qcom,opp-fuse-level = <1>; }; }; /* etc */ }; --- bod
diff --git a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml index 525ebaa93c85..6bf70af948d7 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a53pll.yaml @@ -35,8 +35,6 @@ properties: items: - const: xo - operating-points-v2: true - required: - compatible - reg
The CPU PLL clock node does not use OPP tables (neither driver). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 2 -- 1 file changed, 2 deletions(-)