Add i.MX8QXP CPU opp table to support cpufreq.
Signed-off-by: Anson Huang <[email protected]>
---
No change since V3.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 4021f25..593e2db 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -34,6 +34,10 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&A35_L2>;
+ clocks = <&clk IMX_A35_CLK>;
+ clock-latency = <61036>;
+ #cooling-cells = <2>;
+ operating-points-v2 = <&a35_0_opp_table>;
};
A35_1: cpu@1 {
@@ -42,6 +46,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&A35_L2>;
+ operating-points-v2 = <&a35_0_opp_table>;
};
A35_2: cpu@2 {
@@ -50,6 +55,7 @@
reg = <0x0 0x2>;
enable-method = "psci";
next-level-cache = <&A35_L2>;
+ operating-points-v2 = <&a35_0_opp_table>;
};
A35_3: cpu@3 {
@@ -58,6 +64,7 @@
reg = <0x0 0x3>;
enable-method = "psci";
next-level-cache = <&A35_L2>;
+ operating-points-v2 = <&a35_0_opp_table>;
};
A35_L2: l2-cache0 {
@@ -65,6 +72,24 @@
};
};
+ a35_0_opp_table: opp-table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-900000000 {
+ opp-hz = /bits/ 64 <900000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <150000>;
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <1100000>;
+ clock-latency-ns = <150000>;
+ opp-suspend;
+ };
+ };
+
gic: interrupt-controller@51a00000 {
compatible = "arm,gic-v3";
reg = <0x0 0x51a00000 0 0x10000>, /* GIC Dist */
--
2.7.4
On NXP's i.MX SoCs with system controller inside, CPU frequency
scaling can ONLY be done by system controller firmware, and it
can ONLY be requested from secure mode, so Linux kernel has to
call ARM SMC to trap to ARM-Trusted-Firmware to request system
controller firmware to do CPU frequency scaling.
This patch adds i.MX system controller CPU frequency scaling support,
it reuses cpufreq-dt driver and implement the CPU frequency scaling
inside SCU clock driver.
Signed-off-by: Anson Huang <[email protected]>
---
Changes since V3:
- use different clk ops for CPU clock to avoid runtime check in clk_set_rate;
- use rsrc_id to determine whether it is CPU frequency change and also to get
cluster ID for SMC call.
---
drivers/clk/imx/clk-scu.c | 35 ++++++++++++++++++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/imx/clk-scu.c b/drivers/clk/imx/clk-scu.c
index 7ccf7ed..c234a6e 100644
--- a/drivers/clk/imx/clk-scu.c
+++ b/drivers/clk/imx/clk-scu.c
@@ -4,12 +4,17 @@
* Dong Aisheng <[email protected]>
*/
+#include <dt-bindings/firmware/imx/rsrc.h>
+#include <linux/arm-smccc.h>
#include <linux/clk-provider.h>
#include <linux/err.h>
#include <linux/slab.h>
#include "clk-scu.h"
+#define IMX_SIP_CPUFREQ 0xC2000001
+#define IMX_SIP_SET_CPUFREQ 0x00
+
static struct imx_sc_ipc *ccm_ipc_handle;
/*
@@ -145,6 +150,23 @@ static long clk_scu_round_rate(struct clk_hw *hw, unsigned long rate,
return rate;
}
+static int clk_scu_atf_set_cpu_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_scu *clk = to_clk_scu(hw);
+ struct arm_smccc_res res;
+ unsigned long cluster_id;
+
+ if (clk->rsrc_id == IMX_SC_R_A35)
+ cluster_id = 0;
+
+ /* CPU frequency scaling can ONLY be done by ARM-Trusted-Firmware */
+ arm_smccc_smc(IMX_SIP_CPUFREQ, IMX_SIP_SET_CPUFREQ,
+ cluster_id, rate, 0, 0, 0, 0, &res);
+
+ return 0;
+}
+
/*
* clk_scu_set_rate - Set rate for a SCU clock
* @hw: clock to change rate for
@@ -232,6 +254,14 @@ static const struct clk_ops clk_scu_ops = {
.unprepare = clk_scu_unprepare,
};
+static const struct clk_ops clk_scu_cpu_ops = {
+ .recalc_rate = clk_scu_recalc_rate,
+ .round_rate = clk_scu_round_rate,
+ .set_rate = clk_scu_atf_set_cpu_rate,
+ .prepare = clk_scu_prepare,
+ .unprepare = clk_scu_unprepare,
+};
+
struct clk_hw *imx_clk_scu(const char *name, u32 rsrc_id, u8 clk_type)
{
struct clk_init_data init;
@@ -247,7 +277,10 @@ struct clk_hw *imx_clk_scu(const char *name, u32 rsrc_id, u8 clk_type)
clk->clk_type = clk_type;
init.name = name;
- init.ops = &clk_scu_ops;
+ if (rsrc_id == IMX_SC_R_A35)
+ init.ops = &clk_scu_cpu_ops;
+ else
+ init.ops = &clk_scu_ops;
init.num_parents = 0;
/*
* Note on MX8, the clocks are tightly coupled with power domain
--
2.7.4
On 14-02-19, 01:54, Anson Huang wrote:
> Add i.MX8QXP CPU opp table to support cpufreq.
>
> Signed-off-by: Anson Huang <[email protected]>
> ---
> No change since V3.
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index 4021f25..593e2db 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -34,6 +34,10 @@
> reg = <0x0 0x0>;
> enable-method = "psci";
> next-level-cache = <&A35_L2>;
> + clocks = <&clk IMX_A35_CLK>;
> + clock-latency = <61036>;
Who uses this value ? And why is it different from the one mentioned
in the OPP table ?
> + #cooling-cells = <2>;
clocks and cooling-cells must be defined for all the CPUs.
> + operating-points-v2 = <&a35_0_opp_table>;
> };
>
> A35_1: cpu@1 {
> @@ -42,6 +46,7 @@
> reg = <0x0 0x1>;
> enable-method = "psci";
> next-level-cache = <&A35_L2>;
> + operating-points-v2 = <&a35_0_opp_table>;
> };
>
> A35_2: cpu@2 {
> @@ -50,6 +55,7 @@
> reg = <0x0 0x2>;
> enable-method = "psci";
> next-level-cache = <&A35_L2>;
> + operating-points-v2 = <&a35_0_opp_table>;
> };
>
> A35_3: cpu@3 {
> @@ -58,6 +64,7 @@
> reg = <0x0 0x3>;
> enable-method = "psci";
> next-level-cache = <&A35_L2>;
> + operating-points-v2 = <&a35_0_opp_table>;
> };
>
> A35_L2: l2-cache0 {
> @@ -65,6 +72,24 @@
> };
> };
>
> + a35_0_opp_table: opp-table {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-900000000 {
> + opp-hz = /bits/ 64 <900000000>;
> + opp-microvolt = <1000000>;
> + clock-latency-ns = <150000>;
> + };
> +
> + opp-1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt = <1100000>;
> + clock-latency-ns = <150000>;
> + opp-suspend;
You want to go to a higher frequency on suspend ?
> + };
> + };
> +
> gic: interrupt-controller@51a00000 {
> compatible = "arm,gic-v3";
> reg = <0x0 0x51a00000 0 0x10000>, /* GIC Dist */
> --
> 2.7.4
--
viresh
Hi, Viresh
Best Regards!
Anson Huang
> -----Original Message-----
> From: Viresh Kumar [mailto:[email protected]]
> Sent: 2019??2??14?? 15:13
> To: Anson Huang <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Aisheng Dong
> <[email protected]>; Daniel Baluta <[email protected]>;
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; dl-linux-imx <linux-
> [email protected]>
> Subject: Re: [PATCH V4 1/2] arm64: dts: freescale: imx8qxp: add cpu opp
> table
>
> On 14-02-19, 01:54, Anson Huang wrote:
> > Add i.MX8QXP CPU opp table to support cpufreq.
> >
> > Signed-off-by: Anson Huang <[email protected]>
> > ---
> > No change since V3.
> > ---
> > arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 25
> > +++++++++++++++++++++++++
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > index 4021f25..593e2db 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> > @@ -34,6 +34,10 @@
> > reg = <0x0 0x0>;
> > enable-method = "psci";
> > next-level-cache = <&A35_L2>;
> > + clocks = <&clk IMX_A35_CLK>;
> > + clock-latency = <61036>;
>
> Who uses this value ? And why is it different from the one mentioned in the
> OPP table ?
Sorry, forgot to remove it. Will remove it in next version.
>
> > + #cooling-cells = <2>;
>
> clocks and cooling-cells must be defined for all the CPUs.
OK.
>
> > + operating-points-v2 = <&a35_0_opp_table>;
> > };
> >
> > A35_1: cpu@1 {
> > @@ -42,6 +46,7 @@
> > reg = <0x0 0x1>;
> > enable-method = "psci";
> > next-level-cache = <&A35_L2>;
> > + operating-points-v2 = <&a35_0_opp_table>;
> > };
> >
> > A35_2: cpu@2 {
> > @@ -50,6 +55,7 @@
> > reg = <0x0 0x2>;
> > enable-method = "psci";
> > next-level-cache = <&A35_L2>;
> > + operating-points-v2 = <&a35_0_opp_table>;
> > };
> >
> > A35_3: cpu@3 {
> > @@ -58,6 +64,7 @@
> > reg = <0x0 0x3>;
> > enable-method = "psci";
> > next-level-cache = <&A35_L2>;
> > + operating-points-v2 = <&a35_0_opp_table>;
> > };
> >
> > A35_L2: l2-cache0 {
> > @@ -65,6 +72,24 @@
> > };
> > };
> >
> > + a35_0_opp_table: opp-table {
> > + compatible = "operating-points-v2";
> > + opp-shared;
> > +
> > + opp-900000000 {
> > + opp-hz = /bits/ 64 <900000000>;
> > + opp-microvolt = <1000000>;
> > + clock-latency-ns = <150000>;
> > + };
> > +
> > + opp-1200000000 {
> > + opp-hz = /bits/ 64 <1200000000>;
> > + opp-microvolt = <1100000>;
> > + clock-latency-ns = <150000>;
> > + opp-suspend;
>
> You want to go to a higher frequency on suspend ?
Yes, on most of i.MX SoCs, we always use highest frequency for suspend to reduce
the suspend/resume latency.
Thanks,
Anson.
>
> > + };
> > + };
> > +
> > gic: interrupt-controller@51a00000 {
> > compatible = "arm,gic-v3";
> > reg = <0x0 0x51a00000 0 0x10000>, /* GIC Dist */
> > --
> > 2.7.4
>
> --
> viresh
Quoting Anson Huang (2019-02-13 17:54:08)
> On NXP's i.MX SoCs with system controller inside, CPU frequency
> scaling can ONLY be done by system controller firmware, and it
> can ONLY be requested from secure mode, so Linux kernel has to
> call ARM SMC to trap to ARM-Trusted-Firmware to request system
> controller firmware to do CPU frequency scaling.
>
> This patch adds i.MX system controller CPU frequency scaling support,
> it reuses cpufreq-dt driver and implement the CPU frequency scaling
> inside SCU clock driver.
>
> Signed-off-by: Anson Huang <[email protected]>
> ---
Acked-by: Stephen Boyd <[email protected]>
Unless you wanted me to pick this patch up into clk-next?
Hi, Stephen
Best Regards!
Anson Huang
> -----Original Message-----
> From: Stephen Boyd [mailto:[email protected]]
> Sent: 2019年2月16日 7:58
> To: [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Aisheng Dong
> <[email protected]>; Anson Huang <[email protected]>; Daniel
> Baluta <[email protected]>
> Cc: dl-linux-imx <[email protected]>
> Subject: Re: [PATCH V4 2/2] clk: imx: scu: add cpu frequency scaling support
>
> Quoting Anson Huang (2019-02-13 17:54:08)
> > On NXP's i.MX SoCs with system controller inside, CPU frequency
> > scaling can ONLY be done by system controller firmware, and it can
> > ONLY be requested from secure mode, so Linux kernel has to call ARM
> > SMC to trap to ARM-Trusted-Firmware to request system controller
> > firmware to do CPU frequency scaling.
> >
> > This patch adds i.MX system controller CPU frequency scaling support,
> > it reuses cpufreq-dt driver and implement the CPU frequency scaling
> > inside SCU clock driver.
> >
> > Signed-off-by: Anson Huang <[email protected]>
> > ---
>
> Acked-by: Stephen Boyd <[email protected]>
>
> Unless you wanted me to pick this patch up into clk-next?
Yes, please, we want to support cpu-freq scaling in Linux next tree ASAP.
Thanks,
Anson.
Quoting Anson Huang (2019-02-13 17:54:08)
> On NXP's i.MX SoCs with system controller inside, CPU frequency
> scaling can ONLY be done by system controller firmware, and it
> can ONLY be requested from secure mode, so Linux kernel has to
> call ARM SMC to trap to ARM-Trusted-Firmware to request system
> controller firmware to do CPU frequency scaling.
>
> This patch adds i.MX system controller CPU frequency scaling support,
> it reuses cpufreq-dt driver and implement the CPU frequency scaling
> inside SCU clock driver.
>
> Signed-off-by: Anson Huang <[email protected]>
> ---
> Changes since V3:
> - use different clk ops for CPU clock to avoid runtime check in clk_set_rate;
> - use rsrc_id to determine whether it is CPU frequency change and also to get
> cluster ID for SMC call.
This directly conflicts with a patch to add get/set parent support from
Aisheng Dong. Can you please work together and rebase the patch on top
of that patch (which is in clk-next) and resend this?
Hi, Stephen
Best Regards!
Anson Huang
> -----Original Message-----
> From: Stephen Boyd [mailto:[email protected]]
> Sent: 2019年2月22日 4:48
> To: [email protected]; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Aisheng Dong
> <[email protected]>; Anson Huang <[email protected]>; Daniel
> Baluta <[email protected]>
> Cc: dl-linux-imx <[email protected]>
> Subject: Re: [PATCH V4 2/2] clk: imx: scu: add cpu frequency scaling support
>
> Quoting Anson Huang (2019-02-13 17:54:08)
> > On NXP's i.MX SoCs with system controller inside, CPU frequency
> > scaling can ONLY be done by system controller firmware, and it can
> > ONLY be requested from secure mode, so Linux kernel has to call ARM
> > SMC to trap to ARM-Trusted-Firmware to request system controller
> > firmware to do CPU frequency scaling.
> >
> > This patch adds i.MX system controller CPU frequency scaling support,
> > it reuses cpufreq-dt driver and implement the CPU frequency scaling
> > inside SCU clock driver.
> >
> > Signed-off-by: Anson Huang <[email protected]>
> > ---
> > Changes since V3:
> > - use different clk ops for CPU clock to avoid runtime check in
> clk_set_rate;
> > - use rsrc_id to determine whether it is CPU frequency change and also
> to get
> > cluster ID for SMC call.
>
> This directly conflicts with a patch to add get/set parent support from
> Aisheng Dong. Can you please work together and rebase the patch on top of
> that patch (which is in clk-next) and resend this?
I have resent the patch set based on top of clk-next and tested the function.
Please apply this resent patch, https://patchwork.kernel.org/patch/10825085/
Thanks,
Anson.