Documentation/devicetree/bindings/clock/qcom,a53pll.yaml | 2 -- 1 file changed, 2 deletions(-)
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(-)
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
--
2.34.1On 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-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 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
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
© 2016 - 2026 Red Hat, Inc.