diff mbox series

[v5,1/4] cpufreq: qcom-nvmem: add support for IPQ8074

Message ID 20230930102218.229613-1-robimarko@gmail.com
State New
Headers show
Series [v5,1/4] cpufreq: qcom-nvmem: add support for IPQ8074 | expand

Commit Message

Robert Marko Sept. 30, 2023, 10:21 a.m. UTC
IPQ8074 comes in 2 families:
* IPQ8070A/IPQ8071A (Acorn) up to 1.4GHz
* IPQ8072A/IPQ8074A/IPQ8076A/IPQ8078A (Hawkeye) up to 2.2GHz

So, in order to be able to share one OPP table lets add support for IPQ8074
family based of SMEM SoC ID-s as speedbin fuse is always 0 on IPQ8074.

IPQ8074 compatible is blacklisted from DT platdev as the cpufreq device
will get created by NVMEM CPUFreq driver.

Signed-off-by: Robert Marko <robimarko@gmail.com>
---
Changes in v4:
* Add support for IPQ8174 (Oak) family

Changes in v3:
* Use enum for SoC versions

Changes in v2:
* Print an error if SMEM ID is not part of the IPQ8074 family
and restrict the speed to Acorn variant (1.4GHz)

 drivers/cpufreq/cpufreq-dt-platdev.c |  1 +
 drivers/cpufreq/qcom-cpufreq-nvmem.c | 45 ++++++++++++++++++++++++++++
 2 files changed, 46 insertions(+)

Comments

Rob Herring (Arm) Oct. 2, 2023, 7:02 p.m. UTC | #1
On Sat, 30 Sep 2023 12:21:17 +0200, Robert Marko wrote:
> From: Christian Marangi <ansuelsmth@gmail.com>
> 
> Document named opp-microvolt property for opp-v2-kryo-cpu schema.
> This property is used to declare multiple voltage ranges selected on the
> different values read from efuses. The selection is done based on the
> speed pvs values and the named opp-microvolt property is selected by the
> qcom-cpufreq-nvmem driver.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Signed-off-by: Robert Marko <robimarko@gmail.com>
> ---
> Changes v5:
> * Fix typo in opp items
> 
> Changes v4:
> * Address comments from Rob (meaning of pvs, drop of
>   driver specific info, drop of legacy single voltage OPP,
>   better specify max regulators supported)
> 
>  .../bindings/opp/opp-v2-kryo-cpu.yaml         | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 

Reviewed-by: Rob Herring <robh@kernel.org>
Dmitry Baryshkov Oct. 2, 2023, 7:07 p.m. UTC | #2
On Sat, 30 Sept 2023 at 13:22, Robert Marko <robimarko@gmail.com> wrote:
>
> From: Christian Marangi <ansuelsmth@gmail.com>
>
> Document named opp-microvolt property for opp-v2-kryo-cpu schema.
> This property is used to declare multiple voltage ranges selected on the
> different values read from efuses. The selection is done based on the
> speed pvs values and the named opp-microvolt property is selected by the
> qcom-cpufreq-nvmem driver.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Signed-off-by: Robert Marko <robimarko@gmail.com>
> ---
> Changes v5:
> * Fix typo in opp items
>
> Changes v4:
> * Address comments from Rob (meaning of pvs, drop of
>   driver specific info, drop of legacy single voltage OPP,
>   better specify max regulators supported)
>
>  .../bindings/opp/opp-v2-kryo-cpu.yaml         | 39 +++++++++++++++++++
>  1 file changed, 39 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> index 27ea7eca73e5..8d2a47e9a854 100644
> --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> @@ -65,6 +65,12 @@ patternProperties:
>            5:  MSM8996SG, speedbin 1
>            6:  MSM8996SG, speedbin 2
>            7-31:  unused
> +
> +          Bitmap for IPQ806X SoC:
> +          0:  IPQ8062
> +          1:  IPQ8064/IPQ8066/IPQ8068
> +          2:  IPQ8065/IPQ8069
> +          3-31:  unused
>          enum: [0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,
>                 0x9, 0xd, 0xe, 0xf,
>                 0x10, 0x20, 0x30, 0x70]
> @@ -73,6 +79,23 @@ patternProperties:
>
>        required-opps: true
>
> +    patternProperties:
> +      '^opp-microvolt-speed[0-9]+-pvs[0-9]+$':
> +        description: |
> +          Named opp-microvolt property following the same generic
> +          binding for named opp-microvolt.
> +
> +          The correct voltage range is selected based on the values
> +          in the efuse for the speed and the pvs (power variable
> +          scaling).

I suppose that simple 'true' schema should be enough since this is
already mostly described in opp/opp-v2-base.yaml

> +        minItems: 1
> +        maxItems: 4 # Up to 4 regulators: Core, Mem, Dig and HFPLL
> +        items:
> +          items:
> +            - description: nominal voltage
> +            - description: minimum voltage
> +            - description: maximum voltage
> +
>      required:
>        - opp-hz
>
> @@ -258,6 +281,22 @@ examples:
>              };
>          };
>
> +        /* Dummy opp table to give example for named opp-microvolt */
> +        opp-table-2 {
> +            compatible = "operating-points-v2-kryo-cpu";
> +            nvmem-cells = <&speedbin_efuse>;
> +
> +            opp-384000000 {
> +                opp-hz = /bits/ 64 <384000000>;
> +                opp-microvolt-speed0-pvs0 = <1000000 950000 1050000>;
> +                opp-microvolt-speed0-pvs1 = <925000 878750 971250>;
> +                opp-microvolt-speed0-pvs2 = <875000 831250 918750>;
> +                opp-microvolt-speed0-pvs3 = <800000 760000 840000>;
> +                opp-supported-hw = <0x7>;
> +                clock-latency-ns = <100000>;
> +            };
> +        };
> +
>          smem {
>              compatible = "qcom,smem";
>              memory-region = <&smem_mem>;
> --
> 2.41.0
>
Christian Marangi Oct. 2, 2023, 7:10 p.m. UTC | #3
On Mon, Oct 02, 2023 at 10:07:44PM +0300, Dmitry Baryshkov wrote:
> On Sat, 30 Sept 2023 at 13:22, Robert Marko <robimarko@gmail.com> wrote:
> >
> > From: Christian Marangi <ansuelsmth@gmail.com>
> >
> > Document named opp-microvolt property for opp-v2-kryo-cpu schema.
> > This property is used to declare multiple voltage ranges selected on the
> > different values read from efuses. The selection is done based on the
> > speed pvs values and the named opp-microvolt property is selected by the
> > qcom-cpufreq-nvmem driver.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > Signed-off-by: Robert Marko <robimarko@gmail.com>
> > ---
> > Changes v5:
> > * Fix typo in opp items
> >
> > Changes v4:
> > * Address comments from Rob (meaning of pvs, drop of
> >   driver specific info, drop of legacy single voltage OPP,
> >   better specify max regulators supported)
> >
> >  .../bindings/opp/opp-v2-kryo-cpu.yaml         | 39 +++++++++++++++++++
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> > index 27ea7eca73e5..8d2a47e9a854 100644
> > --- a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> > +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml
> > @@ -65,6 +65,12 @@ patternProperties:
> >            5:  MSM8996SG, speedbin 1
> >            6:  MSM8996SG, speedbin 2
> >            7-31:  unused
> > +
> > +          Bitmap for IPQ806X SoC:
> > +          0:  IPQ8062
> > +          1:  IPQ8064/IPQ8066/IPQ8068
> > +          2:  IPQ8065/IPQ8069
> > +          3-31:  unused
> >          enum: [0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,
> >                 0x9, 0xd, 0xe, 0xf,
> >                 0x10, 0x20, 0x30, 0x70]
> > @@ -73,6 +79,23 @@ patternProperties:
> >
> >        required-opps: true
> >
> > +    patternProperties:
> > +      '^opp-microvolt-speed[0-9]+-pvs[0-9]+$':
> > +        description: |
> > +          Named opp-microvolt property following the same generic
> > +          binding for named opp-microvolt.
> > +
> > +          The correct voltage range is selected based on the values
> > +          in the efuse for the speed and the pvs (power variable
> > +          scaling).
> 
> I suppose that simple 'true' schema should be enough since this is
> already mostly described in opp/opp-v2-base.yaml
>

Mhhh an example of the following implementation?

> > +        minItems: 1
> > +        maxItems: 4 # Up to 4 regulators: Core, Mem, Dig and HFPLL
> > +        items:
> > +          items:
> > +            - description: nominal voltage
> > +            - description: minimum voltage
> > +            - description: maximum voltage
> > +
> >      required:
> >        - opp-hz
> >
> > @@ -258,6 +281,22 @@ examples:
> >              };
> >          };
> >
> > +        /* Dummy opp table to give example for named opp-microvolt */
> > +        opp-table-2 {
> > +            compatible = "operating-points-v2-kryo-cpu";
> > +            nvmem-cells = <&speedbin_efuse>;
> > +
> > +            opp-384000000 {
> > +                opp-hz = /bits/ 64 <384000000>;
> > +                opp-microvolt-speed0-pvs0 = <1000000 950000 1050000>;
> > +                opp-microvolt-speed0-pvs1 = <925000 878750 971250>;
> > +                opp-microvolt-speed0-pvs2 = <875000 831250 918750>;
> > +                opp-microvolt-speed0-pvs3 = <800000 760000 840000>;
> > +                opp-supported-hw = <0x7>;
> > +                clock-latency-ns = <100000>;
> > +            };
> > +        };
> > +
> >          smem {
> >              compatible = "qcom,smem";
> >              memory-region = <&smem_mem>;
> > --
> > 2.41.0
> >
> 
> 
> -- 
> With best wishes
> Dmitry
Viresh Kumar Oct. 10, 2023, 7:14 a.m. UTC | #4
On 02-10-23, 21:10, Christian Marangi wrote:
> On Mon, Oct 02, 2023 at 10:07:44PM +0300, Dmitry Baryshkov wrote:
> > On Sat, 30 Sept 2023 at 13:22, Robert Marko <robimarko@gmail.com> wrote:
> > I suppose that simple 'true' schema should be enough since this is
> > already mostly described in opp/opp-v2-base.yaml
> >
> 
> Mhhh an example of the following implementation?

Documentation/devicetree/bindings/opp/allwinner,sun50i-h6-operating-points.yaml
Viresh Kumar Oct. 10, 2023, 7:18 a.m. UTC | #5
On 02-10-23, 22:07, Dmitry Baryshkov wrote:
> I suppose that simple 'true' schema should be enough since this is
> already mostly described in opp/opp-v2-base.yaml

Dmitry, Konrad,

Can you guys review the other patches in the series, since you are
also actively working on this driver ?
Konrad Dybcio Oct. 10, 2023, 1:34 p.m. UTC | #6
On 9/30/23 12:21, Robert Marko wrote:
> IPQ8074 comes in 2 families:
> * IPQ8070A/IPQ8071A (Acorn) up to 1.4GHz
> * IPQ8072A/IPQ8074A/IPQ8076A/IPQ8078A (Hawkeye) up to 2.2GHz
> 
> So, in order to be able to share one OPP table lets add support for IPQ8074
> family based of SMEM SoC ID-s as speedbin fuse is always 0 on IPQ8074.
> 
> IPQ8074 compatible is blacklisted from DT platdev as the cpufreq device
> will get created by NVMEM CPUFreq driver.
> 
> Signed-off-by: Robert Marko <robimarko@gmail.com>
> ---
> Changes in v4:
> * Add support for IPQ8174 (Oak) family
> 
> Changes in v3:
> * Use enum for SoC versions
> 
> Changes in v2:
> * Print an error if SMEM ID is not part of the IPQ8074 family
> and restrict the speed to Acorn variant (1.4GHz)
> 
>   drivers/cpufreq/cpufreq-dt-platdev.c |  1 +
>   drivers/cpufreq/qcom-cpufreq-nvmem.c | 45 ++++++++++++++++++++++++++++
>   2 files changed, 46 insertions(+)
> 
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
> index 2016d47889c0..157c91b9962c 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -180,6 +180,7 @@ static const struct of_device_id blocklist[] __initconst = {
>   	{ .compatible = "ti,am62a7", },
>   
>   	{ .compatible = "qcom,ipq8064", },
> +	{ .compatible = "qcom,ipq8074", },
>   	{ .compatible = "qcom,apq8064", },
>   	{ .compatible = "qcom,msm8974", },
>   	{ .compatible = "qcom,msm8960", },
Generally this lands in a separate commit, but I guess since Viresh 
takes changes to both of the files, it's even better..

Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Konrad
Konrad Dybcio Oct. 10, 2023, 1:40 p.m. UTC | #7
On 9/30/23 12:21, Robert Marko wrote:
> From: Christian Marangi <ansuelsmth@gmail.com>
> 
> Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
> Use opp-supported-hw binding to correctly enable and disable the
> frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
> 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
> 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Signed-off-by: Robert Marko <robimarko@gmail.com>
> ---
Christian/Robert, can you provide a downstream source for this?

Konrad
Christian Marangi Oct. 10, 2023, 2:15 p.m. UTC | #8
On Tue, Oct 10, 2023 at 03:40:32PM +0200, Konrad Dybcio wrote:
> 
> 
> On 9/30/23 12:21, Robert Marko wrote:
> > From: Christian Marangi <ansuelsmth@gmail.com>
> > 
> > Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
> > Use opp-supported-hw binding to correctly enable and disable the
> > frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
> > 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
> > 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
> > 
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > Signed-off-by: Robert Marko <robimarko@gmail.com>
> > ---
> Christian/Robert, can you provide a downstream source for this?
> 

Sure, consider that everything is with +/-5%.

Qsdk ships with these values but I will link a more secure source that
is from a very old qsdk source where march-msm was still used instead of
dt.

Here the source [1]. Confirmed by internal verification and also other
qsdk. At first view you might be scared by confusion but...

- _lite = ipq8062
- nothing = ipq8064
- tn_3 = ipq8065

and the psv are both in number and slow, nominal, fast and faster and
they all reflect efuse values.

There is on the left frequency and on the right voltage.

[1] https://github.com/Getnear/R7800/blob/master/git_home/linux.git/sourcecode/arch/arm/mach-msm/acpuclock-ipq806x.c
Konrad Dybcio Oct. 10, 2023, 7:52 p.m. UTC | #9
On 10/10/23 16:15, Christian Marangi wrote:
> On Tue, Oct 10, 2023 at 03:40:32PM +0200, Konrad Dybcio wrote:
>>
>>
>> On 9/30/23 12:21, Robert Marko wrote:
>>> From: Christian Marangi <ansuelsmth@gmail.com>
>>>
>>> Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
>>> Use opp-supported-hw binding to correctly enable and disable the
>>> frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
>>> 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
>>> 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>> Signed-off-by: Robert Marko <robimarko@gmail.com>
>>> ---
>> Christian/Robert, can you provide a downstream source for this?
>>
> 
> Sure, consider that everything is with +/-5%.
Hm, so you're e.g. putting ipq8062 384MHz voltage for PVS3 equal to 
0.95*800000 = 760000, but I'm not sure if it's a good idea?

The comment in downstream:

"These are based on +/-5% Margin on the VDD_APCx that is advertised in 
our Datasheet across Temperature"

suggests this is already not very accurate, and betting that the lower 
threshold works on all chips is probably not the best idea.

Konrad
Konrad Dybcio Oct. 10, 2023, 7:55 p.m. UTC | #10
On 9/30/23 12:21, Robert Marko wrote:
> From: Christian Marangi <ansuelsmth@gmail.com>
> 
> Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
> Use opp-supported-hw binding to correctly enable and disable the
> frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
> 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
> 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> Signed-off-by: Robert Marko <robimarko@gmail.com>
> ---
> Changes v4:
> * Add OPP DTS patch for IPQ8064
> 
>   arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi | 30 +++++++++++
>   arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi | 67 ++++++++++++++++++++++++
>   arch/arm/boot/dts/qcom/qcom-ipq8065.dtsi | 65 +++++++++++++++++++++++
>   3 files changed, 162 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi b/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi
> index 5d3ebd3e2e51..72d9782c3d6f 100644
> --- a/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi
> +++ b/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi
> @@ -6,3 +6,33 @@ / {
>   	model = "Qualcomm Technologies, Inc. IPQ8062";
>   	compatible = "qcom,ipq8062", "qcom,ipq8064";
>   };
> +
> +&opp_table_cpu {
> +	opp-384000000 {
> +		opp-microvolt-speed0-pvs0 = <1000000 950000 1050000>;
> +		opp-microvolt-speed0-pvs1 = <925000 878750 971250>;
> +		opp-microvolt-speed0-pvs2 = <875000 831250 918750>;
> +		opp-microvolt-speed0-pvs3 = <800000 760000 840000>;
We can just make use of opp-supported-hw and define opp-384...-0, 
opp-384..-1 etc. with a valid corresponding bitmask in opp-supported-hw

otherwise it's somewhat confusing to follow, I think..

Konrad
Christian Marangi Oct. 10, 2023, 8 p.m. UTC | #11
On Tue, Oct 10, 2023 at 09:52:50PM +0200, Konrad Dybcio wrote:
> 
> 
> On 10/10/23 16:15, Christian Marangi wrote:
> > On Tue, Oct 10, 2023 at 03:40:32PM +0200, Konrad Dybcio wrote:
> > > 
> > > 
> > > On 9/30/23 12:21, Robert Marko wrote:
> > > > From: Christian Marangi <ansuelsmth@gmail.com>
> > > > 
> > > > Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
> > > > Use opp-supported-hw binding to correctly enable and disable the
> > > > frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
> > > > 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
> > > > 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
> > > > 
> > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > Signed-off-by: Robert Marko <robimarko@gmail.com>
> > > > ---
> > > Christian/Robert, can you provide a downstream source for this?
> > > 
> > 
> > Sure, consider that everything is with +/-5%.
> Hm, so you're e.g. putting ipq8062 384MHz voltage for PVS3 equal to
> 0.95*800000 = 760000, but I'm not sure if it's a good idea?
> 
> The comment in downstream:
> 
> "These are based on +/-5% Margin on the VDD_APCx that is advertised in our
> Datasheet across Temperature"
> 
> suggests this is already not very accurate, and betting that the lower
> threshold works on all chips is probably not the best idea.
>

Consider that everything is driven by the rpm. The original qsdk used the
same approach of taking the value, apply +-5% and pass it as a voltage
triplet to the rpm regulator. Also the driver have ranges so it
autodecide the best voltage in the range of the voltage triplet based on
the one supported by the regulator. Normally the normal voltage is
always used.
Christian Marangi Oct. 10, 2023, 8:05 p.m. UTC | #12
On Tue, Oct 10, 2023 at 09:55:26PM +0200, Konrad Dybcio wrote:
> 
> 
> On 9/30/23 12:21, Robert Marko wrote:
> > From: Christian Marangi <ansuelsmth@gmail.com>
> > 
> > Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
> > Use opp-supported-hw binding to correctly enable and disable the
> > frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
> > 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
> > 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
> > 
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > Signed-off-by: Robert Marko <robimarko@gmail.com>
> > ---
> > Changes v4:
> > * Add OPP DTS patch for IPQ8064
> > 
> >   arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi | 30 +++++++++++
> >   arch/arm/boot/dts/qcom/qcom-ipq8064.dtsi | 67 ++++++++++++++++++++++++
> >   arch/arm/boot/dts/qcom/qcom-ipq8065.dtsi | 65 +++++++++++++++++++++++
> >   3 files changed, 162 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi b/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi
> > index 5d3ebd3e2e51..72d9782c3d6f 100644
> > --- a/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi
> > +++ b/arch/arm/boot/dts/qcom/qcom-ipq8062.dtsi
> > @@ -6,3 +6,33 @@ / {
> >   	model = "Qualcomm Technologies, Inc. IPQ8062";
> >   	compatible = "qcom,ipq8062", "qcom,ipq8064";
> >   };
> > +
> > +&opp_table_cpu {
> > +	opp-384000000 {
> > +		opp-microvolt-speed0-pvs0 = <1000000 950000 1050000>;
> > +		opp-microvolt-speed0-pvs1 = <925000 878750 971250>;
> > +		opp-microvolt-speed0-pvs2 = <875000 831250 918750>;
> > +		opp-microvolt-speed0-pvs3 = <800000 760000 840000>;
> We can just make use of opp-supported-hw and define opp-384...-0,
> opp-384..-1 etc. with a valid corresponding bitmask in opp-supported-hw
> 
> otherwise it's somewhat confusing to follow, I think..
>

Ehh should we really double the nodes for ipq8062 and ipq8065?
The idea here was to overwrite the one since the pvs always match and at
worst(ipq8065) have 7 pvs instead of 4. From the system it would be
easier to read since only one table is present in the final dts and not
2 and referring to the opp-supported-hw.

The original idea was to declare one opp table and reuse pvs version (by
faking it with hardcoded values) to put additional pvs for ipq8062 and
ipq8065, but Dmitry didn't like it and asked to move the opp in
different dtsi.
Konrad Dybcio Oct. 10, 2023, 9:17 p.m. UTC | #13
On 10/10/23 22:00, Christian Marangi wrote:
> On Tue, Oct 10, 2023 at 09:52:50PM +0200, Konrad Dybcio wrote:
>>
>>
>> On 10/10/23 16:15, Christian Marangi wrote:
>>> On Tue, Oct 10, 2023 at 03:40:32PM +0200, Konrad Dybcio wrote:
>>>>
>>>>
>>>> On 9/30/23 12:21, Robert Marko wrote:
>>>>> From: Christian Marangi <ansuelsmth@gmail.com>
>>>>>
>>>>> Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
>>>>> Use opp-supported-hw binding to correctly enable and disable the
>>>>> frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
>>>>> 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
>>>>> 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
>>>>>
>>>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>>>> Signed-off-by: Robert Marko <robimarko@gmail.com>
>>>>> ---
>>>> Christian/Robert, can you provide a downstream source for this?
>>>>
>>>
>>> Sure, consider that everything is with +/-5%.
>> Hm, so you're e.g. putting ipq8062 384MHz voltage for PVS3 equal to
>> 0.95*800000 = 760000, but I'm not sure if it's a good idea?
>>
>> The comment in downstream:
>>
>> "These are based on +/-5% Margin on the VDD_APCx that is advertised in our
>> Datasheet across Temperature"
>>
>> suggests this is already not very accurate, and betting that the lower
>> threshold works on all chips is probably not the best idea.
>>
> 
> Consider that everything is driven by the rpm. The original qsdk used the
> same approach of taking the value, apply +-5% and pass it as a voltage
> triplet to the rpm regulator. Also the driver have ranges so it
> autodecide the best voltage in the range of the voltage triplet based on
> the one supported by the regulator. Normally the normal voltage is
> always used.
Eeh? So you pass any half-random value to it and RPM edits it in flight?

Please be more specific, I'm not very familiar with this platform

Konrad
Christian Marangi Oct. 10, 2023, 9:50 p.m. UTC | #14
On Tue, Oct 10, 2023 at 11:17:34PM +0200, Konrad Dybcio wrote:
> 
> 
> On 10/10/23 22:00, Christian Marangi wrote:
> > On Tue, Oct 10, 2023 at 09:52:50PM +0200, Konrad Dybcio wrote:
> > > 
> > > 
> > > On 10/10/23 16:15, Christian Marangi wrote:
> > > > On Tue, Oct 10, 2023 at 03:40:32PM +0200, Konrad Dybcio wrote:
> > > > > 
> > > > > 
> > > > > On 9/30/23 12:21, Robert Marko wrote:
> > > > > > From: Christian Marangi <ansuelsmth@gmail.com>
> > > > > > 
> > > > > > Add CPU OPP table for IPQ8062, IPQ8064 and IPQ8065 SoC.
> > > > > > Use opp-supported-hw binding to correctly enable and disable the
> > > > > > frequency as IPQ8062 supports up to 1.0Ghz, IPQ8064 supports up to
> > > > > > 1.4GHz with 1.2GHz as an additional frequency and IPQ8065 supports
> > > > > > 1.7GHZ but doesn't have 1.2GHZ frequency and has to be disabled.
> > > > > > 
> > > > > > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > > > > > Signed-off-by: Robert Marko <robimarko@gmail.com>
> > > > > > ---
> > > > > Christian/Robert, can you provide a downstream source for this?
> > > > > 
> > > > 
> > > > Sure, consider that everything is with +/-5%.
> > > Hm, so you're e.g. putting ipq8062 384MHz voltage for PVS3 equal to
> > > 0.95*800000 = 760000, but I'm not sure if it's a good idea?
> > > 
> > > The comment in downstream:
> > > 
> > > "These are based on +/-5% Margin on the VDD_APCx that is advertised in our
> > > Datasheet across Temperature"
> > > 
> > > suggests this is already not very accurate, and betting that the lower
> > > threshold works on all chips is probably not the best idea.
> > > 
> > 
> > Consider that everything is driven by the rpm. The original qsdk used the
> > same approach of taking the value, apply +-5% and pass it as a voltage
> > triplet to the rpm regulator. Also the driver have ranges so it
> > autodecide the best voltage in the range of the voltage triplet based on
> > the one supported by the regulator. Normally the normal voltage is
> > always used.
> Eeh? So you pass any half-random value to it and RPM edits it in flight?
> 
> Please be more specific, I'm not very familiar with this platform
> 

Sorry, probably I was a bit confusing.

ipq806x mount on 99% of the devices (this is the suggested design by
qcom) smb208 regulator. These have selector and step since not every
voltage is supported. So the closest one is selected in the range of the
provided min and max.

Most of the time the normal voltage is correctly used by sometimes an
higher one is used. The ranges are described here [1].

Consider that in later version of the qsdk where the moved to DT
definition, they started using OPP v1 where voltage-tollerance binding
is used. The voltage-tollerance was set to 5.

You can find how this value was used for OPPv1 here [2].

As you can see they internally calculate the min and max value and set
them. OPP v2 dropped this and make the dev directly provide min and max.

Effectively we pass the same voltage values.

For the voltage and how it's set, we use cpufreq-dt where if an attached
regulator is found, the set_voltage_triplet is used by providing normal
min and max value and then internally the best value is selected. This
same implementation was used in the qsdk source when they moved to dt
implementation.

Hope it's more clear now how the voltages are set on this platform.
For the RPM part, the voltage is requested but there isn't a direct
control of the system on the regulator since everything is handled by
RPM so there is also that extra step.

[1] https://elixir.bootlin.com/linux/latest/source/drivers/regulator/qcom_rpm-regulator.c#L178
[2] https://elixir.bootlin.com/linux/latest/source/drivers/opp/core.c#L1956
Viresh Kumar Oct. 11, 2023, 5:25 a.m. UTC | #15
On 30-09-23, 12:21, Robert Marko wrote:
> IPQ8074 comes in 2 families:
> * IPQ8070A/IPQ8071A (Acorn) up to 1.4GHz
> * IPQ8072A/IPQ8074A/IPQ8076A/IPQ8078A (Hawkeye) up to 2.2GHz
> 
> So, in order to be able to share one OPP table lets add support for IPQ8074
> family based of SMEM SoC ID-s as speedbin fuse is always 0 on IPQ8074.
> 
> IPQ8074 compatible is blacklisted from DT platdev as the cpufreq device
> will get created by NVMEM CPUFreq driver.
> 
> Signed-off-by: Robert Marko <robimarko@gmail.com>
> ---
> Changes in v4:
> * Add support for IPQ8174 (Oak) family

Doesn't apply cleanly over my branch anymore, please resend. Thanks.
diff mbox series

Patch

diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 2016d47889c0..157c91b9962c 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -180,6 +180,7 @@  static const struct of_device_id blocklist[] __initconst = {
 	{ .compatible = "ti,am62a7", },
 
 	{ .compatible = "qcom,ipq8064", },
+	{ .compatible = "qcom,ipq8074", },
 	{ .compatible = "qcom,apq8064", },
 	{ .compatible = "qcom,msm8974", },
 	{ .compatible = "qcom,msm8960", },
diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
index 84d7033e5efe..ba9e1d60e5b5 100644
--- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
+++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
@@ -30,6 +30,11 @@ 
 
 #include <dt-bindings/arm/qcom,ids.h>
 
+enum ipq8074_versions {
+	IPQ8074_HAWKEYE_VERSION = 0,
+	IPQ8074_ACORN_VERSION,
+};
+
 struct qcom_cpufreq_drv;
 
 struct qcom_cpufreq_match_data {
@@ -203,6 +208,41 @@  static int qcom_cpufreq_krait_name_version(struct device *cpu_dev,
 	return ret;
 }
 
+static int qcom_cpufreq_ipq8074_name_version(struct device *cpu_dev,
+					     struct nvmem_cell *speedbin_nvmem,
+					     char **pvs_name,
+					     struct qcom_cpufreq_drv *drv)
+{
+	u32 msm_id;
+	int ret;
+	*pvs_name = NULL;
+
+	ret = qcom_smem_get_soc_id(&msm_id);
+	if (ret)
+		return ret;
+
+	switch (msm_id) {
+	case QCOM_ID_IPQ8070A:
+	case QCOM_ID_IPQ8071A:
+		drv->versions = BIT(IPQ8074_ACORN_VERSION);
+		break;
+	case QCOM_ID_IPQ8072A:
+	case QCOM_ID_IPQ8074A:
+	case QCOM_ID_IPQ8076A:
+	case QCOM_ID_IPQ8078A:
+		drv->versions = BIT(IPQ8074_HAWKEYE_VERSION);
+		break;
+	default:
+		dev_err(cpu_dev,
+			"SoC ID %u is not part of IPQ8074 family, limiting to 1.4GHz!\n",
+			msm_id);
+		drv->versions = BIT(IPQ8074_ACORN_VERSION);
+		break;
+	}
+
+	return 0;
+}
+
 static const struct qcom_cpufreq_match_data match_data_kryo = {
 	.get_version = qcom_cpufreq_kryo_name_version,
 };
@@ -217,6 +257,10 @@  static const struct qcom_cpufreq_match_data match_data_qcs404 = {
 	.genpd_names = qcs404_genpd_names,
 };
 
+static const struct qcom_cpufreq_match_data match_data_ipq8074 = {
+	.get_version = qcom_cpufreq_ipq8074_name_version,
+};
+
 static int qcom_cpufreq_probe(struct platform_device *pdev)
 {
 	struct qcom_cpufreq_drv *drv;
@@ -360,6 +404,7 @@  static const struct of_device_id qcom_cpufreq_match_list[] __initconst = {
 	{ .compatible = "qcom,msm8996", .data = &match_data_kryo },
 	{ .compatible = "qcom,qcs404", .data = &match_data_qcs404 },
 	{ .compatible = "qcom,ipq8064", .data = &match_data_krait },
+	{ .compatible = "qcom,ipq8074", .data = &match_data_ipq8074 },
 	{ .compatible = "qcom,apq8064", .data = &match_data_krait },
 	{ .compatible = "qcom,msm8974", .data = &match_data_krait },
 	{ .compatible = "qcom,msm8960", .data = &match_data_krait },