The patch series adds the support for dynamic CPU frequency switching
for FU540-C000 SoC on the HiFive Unleashed board. All the patches are
based on Paul Walmsley's work.
This series is based on Linux v5.7 and tested on HiFive unleashed board.
Yash Shah (3):
riscv: defconfig, Kconfig: enable CPU power management
riscv: dts: fu540-c000: define hart clocks
riscv: dts: HiFive Unleashed: define a default set of CPU OPPs
arch/riscv/Kconfig | 8 +++++
arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 5 +++
.../riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 38 ++++++++++++++++++++++
arch/riscv/configs/defconfig | 5 +++
4 files changed, 56 insertions(+)
--
2.7.4
Enable CPUFreq and CPUIdle for RISC-V systems to be configured with
Kconfig, and compile the kernel code to support it by default. This
will be used to support dynamic CPU frequency switching for the HiFive
Unleashed board, along with any future RISC-V boards that support
CPU power management.
Signed-off-by: Yash Shah <[email protected]>
---
arch/riscv/Kconfig | 8 ++++++++
arch/riscv/configs/defconfig | 5 +++++
2 files changed, 13 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a31e1a4..1c8443e 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -381,6 +381,14 @@ endchoice
endmenu
+menu "CPU Power Management"
+
+source "drivers/cpuidle/Kconfig"
+
+source "drivers/cpufreq/Kconfig"
+
+endmenu
+
menu "Power management options"
source "kernel/power/Kconfig"
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 4da4886..58f4bce 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -17,6 +17,11 @@ CONFIG_BPF_SYSCALL=y
CONFIG_SOC_SIFIVE=y
CONFIG_SOC_VIRT=y
CONFIG_SMP=y
+CONFIG_CPU_IDLE=y
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_STAT=y
+CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
+CONFIG_CPUFREQ_DT=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_NET=y
--
2.7.4
Declare that each hart defined in the FU540 DT data is clocked by the
COREPLL. This is in preparation for enabling CPUFreq for the
FU540-C000 SoC on the HiFive Unleashed board.
Signed-off-by: Yash Shah <[email protected]>
---
arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
index 7db8610..735e102 100644
--- a/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
+++ b/arch/riscv/boot/dts/sifive/fu540-c000.dtsi
@@ -30,6 +30,7 @@
i-cache-size = <16384>;
reg = <0>;
riscv,isa = "rv64imac";
+ clocks = <&prci PRCI_CLK_COREPLL>;
status = "disabled";
cpu0_intc: interrupt-controller {
#interrupt-cells = <1>;
@@ -55,6 +56,7 @@
riscv,isa = "rv64imafdc";
tlb-split;
next-level-cache = <&l2cache>;
+ clocks = <&prci PRCI_CLK_COREPLL>;
cpu1_intc: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -79,6 +81,7 @@
riscv,isa = "rv64imafdc";
tlb-split;
next-level-cache = <&l2cache>;
+ clocks = <&prci PRCI_CLK_COREPLL>;
cpu2_intc: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -103,6 +106,7 @@
riscv,isa = "rv64imafdc";
tlb-split;
next-level-cache = <&l2cache>;
+ clocks = <&prci PRCI_CLK_COREPLL>;
cpu3_intc: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
@@ -127,6 +131,7 @@
riscv,isa = "rv64imafdc";
tlb-split;
next-level-cache = <&l2cache>;
+ clocks = <&prci PRCI_CLK_COREPLL>;
cpu4_intc: interrupt-controller {
#interrupt-cells = <1>;
compatible = "riscv,cpu-intc";
--
2.7.4
Define a default set of CPU OPPs for the HiFive Unleashed with the
FU540-C000 SoC. This allows CPUFreq to be enabled for this board.
The FU540-C000 SoC PVT corners haven't been characterized separately
from the HiFive Unleashed board. Thus the OPPs are added to the board
DT file, rather than the SoC itself.
The specific selection of OPPs are designed to enable fast switching
by simply changing the CORE PLL output divider. The exception is the
1GHz OPP. Since the OPP code apparently requires that, upon kernel
start, the CPU clock frequency must have been set to an existing OPP
frequency, the 1GHz rate is present solely because the default HiFive
Unleashed bootloaders set the CPU to run at 1GHz before starting the
kernel.
Signed-off-by: Yash Shah <[email protected]>
---
.../riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 38 ++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
index 4a2729f..59db9c0 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
@@ -46,6 +46,44 @@
compatible = "gpio-restart";
gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
};
+
+ fu540_c000_opp_table: opp-table {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-350000000 {
+ opp-hz = /bits/ 64 <350000000>;
+ };
+ opp-700000000 {
+ opp-hz = /bits/ 64 <700000000>;
+ };
+ opp-999999999 {
+ opp-hz = /bits/ 64 <999999999>;
+ };
+ opp-1400000000 {
+ opp-hz = /bits/ 64 <1400000000>;
+ };
+ };
+};
+
+&cpu0 {
+ operating-points-v2 = <&fu540_c000_opp_table>;
+};
+
+&cpu1 {
+ operating-points-v2 = <&fu540_c000_opp_table>;
+};
+
+&cpu2 {
+ operating-points-v2 = <&fu540_c000_opp_table>;
+};
+
+&cpu3 {
+ operating-points-v2 = <&fu540_c000_opp_table>;
+};
+
+&cpu4 {
+ operating-points-v2 = <&fu540_c000_opp_table>;
};
&uart0 {
--
2.7.4
Yash Shah <[email protected]> 於 2020年6月16日 週二 下午8:01寫道：
>
> The patch series adds the support for dynamic CPU frequency switching
> for FU540-C000 SoC on the HiFive Unleashed board. All the patches are
> based on Paul Walmsley's work.
>
> This series is based on Linux v5.7 and tested on HiFive unleashed board.
>
> Yash Shah (3):
> riscv: defconfig, Kconfig: enable CPU power management
> riscv: dts: fu540-c000: define hart clocks
> riscv: dts: HiFive Unleashed: define a default set of CPU OPPs
>
> arch/riscv/Kconfig | 8 +++++
> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 5 +++
> .../riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 38 ++++++++++++++++++++++
> arch/riscv/configs/defconfig | 5 +++
> 4 files changed, 56 insertions(+)
>
Hi Yash,
Thank you for the patch. It works for me to test with cpufreq-ljt-stress-test.
Here is my log.
CPU stress test, which is doing JPEG decoding by libjpeg-turbo
at different cpufreq operating points.
Testing CPU 0
1400 MHz ............................................................ OK
999 MHz ............................................................ OK
700 MHz ............................................................ OK
350 MHz ............................................................ OK
Testing CPU 1
1400 MHz ............................................................ OK
999 MHz ............................................................ OK
700 MHz ............................................................ OK
350 MHz ............................................................ OK
Testing CPU 2
1400 MHz ............................................................ OK
999 MHz ............................................................ OK
700 MHz ............................................................ OK
350 MHz ............................................................ OK
Testing CPU 3
1400 MHz ............................................................ OK
999 MHz ............................................................ OK
700 MHz ............................................................ OK
350 MHz ............................................................ OK
Overall result : PASSED
Tested-by: Greentime Hu <[email protected]>
On Jun 16 2020, Yash Shah wrote:
> The patch series adds the support for dynamic CPU frequency switching
> for FU540-C000 SoC on the HiFive Unleashed board. All the patches are
> based on Paul Walmsley's work.
>
> This series is based on Linux v5.7 and tested on HiFive unleashed board.
I'm using that patch with 5.7.5.
It appears to interfer with serial output when using the ondemand
governor.
I also see soft lockups when using the performance governor:
[ 101.587527] rcu: INFO: rcu_sched self-detected stall on CPU
[ 101.592322] rcu: 0-...!: (932 ticks this GP) idle=11a/1/0x4000000000000004 softirq=4301/4301 fqs=4
[ 101.601432] (t=6001 jiffies g=4017 q=859)
[ 101.605514] rcu: rcu_sched kthread starved for 5984 jiffies! g4017 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=2
[ 101.615494] rcu: RCU grace-period kthread stack dump:
[ 101.620530] rcu_sched R running task 0 10 2 0x00000000
[ 101.627560] Call Trace:
[ 101.630004] [<ffffffe00085a7e2>] __schedule+0x25c/0x616
[ 101.635205] [<ffffffe00085abde>] schedule+0x42/0xb2
[ 101.640070] [<ffffffe00085d0ba>] schedule_timeout+0x56/0xb8
[ 101.645626] [<ffffffe000263c34>] rcu_gp_fqs_loop+0x208/0x248
[ 101.651266] [<ffffffe0002666de>] rcu_gp_kthread+0xc2/0xcc
[ 101.656651] [<ffffffe00022654e>] kthread+0xda/0xec
[ 101.661426] [<ffffffe00020140a>] ret_from_exception+0x0/0xc
[ 101.666977] Task dump for CPU 0:
[ 101.670187] loop0 R running task 0 655 2 0x00000008
[ 101.677218] Call Trace:
[ 101.679657] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa
[ 101.685036] [<ffffffe000202b76>] show_stack+0x2a/0x34
[ 101.690074] [<ffffffe0002319b0>] sched_show_task.part.0+0xc2/0xd2
[ 101.696154] [<ffffffe00022bb9c>] sched_show_task+0x64/0x66
[ 101.701618] [<ffffffe000231afe>] dump_cpu_task+0x3e/0x48
[ 101.706916] [<ffffffe000267762>] rcu_dump_cpu_stacks+0x94/0xce
[ 101.712731] [<ffffffe0002631f6>] print_cpu_stall+0x116/0x18a
[ 101.718375] [<ffffffe000264a46>] check_cpu_stall+0xcc/0x1a2
[ 101.723929] [<ffffffe000264b52>] rcu_pending.constprop.0+0x36/0xaa
[ 101.730094] [<ffffffe000266ab2>] rcu_sched_clock_irq+0xa6/0xea
[ 101.735913] [<ffffffe00026d1be>] update_process_times+0x1e/0x42
[ 101.741821] [<ffffffe0002793bc>] tick_sched_handle+0x26/0x52
[ 101.747456] [<ffffffe0002798fe>] tick_sched_timer+0x6a/0xd0
[ 101.753015] [<ffffffe00026d9be>] __run_hrtimer.constprop.0+0x50/0xe8
[ 101.759353] [<ffffffe00026da9e>] __hrtimer_run_queues+0x48/0x6c
[ 101.765254] [<ffffffe00026e410>] hrtimer_interrupt+0xca/0x1d4
[ 101.770985] [<ffffffe0006ceef8>] riscv_timer_interrupt+0x32/0x3a
[ 101.776976] [<ffffffe00085e17c>] do_IRQ+0xa4/0xb8
[ 101.781663] [<ffffffe00020140a>] ret_from_exception+0x0/0xc
Andreas.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Wed, Jul 1, 2020 at 1:41 PM Andreas Schwab <[email protected]> wrote:
>
> On Jun 16 2020, Yash Shah wrote:
>
> > The patch series adds the support for dynamic CPU frequency switching
> > for FU540-C000 SoC on the HiFive Unleashed board. All the patches are
> > based on Paul Walmsley's work.
> >
> > This series is based on Linux v5.7 and tested on HiFive unleashed board.
>
> I'm using that patch with 5.7.5.
>
> It appears to interfer with serial output when using the ondemand
> governor.
I do recall that userspace governor is the only one supported but this
might have changed before this patch was posted.
Yash, do you have more details?
>
> I also see soft lockups when using the performance governor:
>
> [ 101.587527] rcu: INFO: rcu_sched self-detected stall on CPU
> [ 101.592322] rcu: 0-...!: (932 ticks this GP) idle=11a/1/0x4000000000000004 softirq=4301/4301 fqs=4
> [ 101.601432] (t=6001 jiffies g=4017 q=859)
> [ 101.605514] rcu: rcu_sched kthread starved for 5984 jiffies! g4017 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=2
> [ 101.615494] rcu: RCU grace-period kthread stack dump:
> [ 101.620530] rcu_sched R running task 0 10 2 0x00000000
> [ 101.627560] Call Trace:
> [ 101.630004] [<ffffffe00085a7e2>] __schedule+0x25c/0x616
> [ 101.635205] [<ffffffe00085abde>] schedule+0x42/0xb2
> [ 101.640070] [<ffffffe00085d0ba>] schedule_timeout+0x56/0xb8
> [ 101.645626] [<ffffffe000263c34>] rcu_gp_fqs_loop+0x208/0x248
> [ 101.651266] [<ffffffe0002666de>] rcu_gp_kthread+0xc2/0xcc
> [ 101.656651] [<ffffffe00022654e>] kthread+0xda/0xec
> [ 101.661426] [<ffffffe00020140a>] ret_from_exception+0x0/0xc
> [ 101.666977] Task dump for CPU 0:
> [ 101.670187] loop0 R running task 0 655 2 0x00000008
> [ 101.677218] Call Trace:
> [ 101.679657] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa
> [ 101.685036] [<ffffffe000202b76>] show_stack+0x2a/0x34
> [ 101.690074] [<ffffffe0002319b0>] sched_show_task.part.0+0xc2/0xd2
> [ 101.696154] [<ffffffe00022bb9c>] sched_show_task+0x64/0x66
> [ 101.701618] [<ffffffe000231afe>] dump_cpu_task+0x3e/0x48
> [ 101.706916] [<ffffffe000267762>] rcu_dump_cpu_stacks+0x94/0xce
> [ 101.712731] [<ffffffe0002631f6>] print_cpu_stall+0x116/0x18a
> [ 101.718375] [<ffffffe000264a46>] check_cpu_stall+0xcc/0x1a2
> [ 101.723929] [<ffffffe000264b52>] rcu_pending.constprop.0+0x36/0xaa
> [ 101.730094] [<ffffffe000266ab2>] rcu_sched_clock_irq+0xa6/0xea
> [ 101.735913] [<ffffffe00026d1be>] update_process_times+0x1e/0x42
> [ 101.741821] [<ffffffe0002793bc>] tick_sched_handle+0x26/0x52
> [ 101.747456] [<ffffffe0002798fe>] tick_sched_timer+0x6a/0xd0
> [ 101.753015] [<ffffffe00026d9be>] __run_hrtimer.constprop.0+0x50/0xe8
> [ 101.759353] [<ffffffe00026da9e>] __hrtimer_run_queues+0x48/0x6c
> [ 101.765254] [<ffffffe00026e410>] hrtimer_interrupt+0xca/0x1d4
> [ 101.770985] [<ffffffe0006ceef8>] riscv_timer_interrupt+0x32/0x3a
> [ 101.776976] [<ffffffe00085e17c>] do_IRQ+0xa4/0xb8
> [ 101.781663] [<ffffffe00020140a>] ret_from_exception+0x0/0xc
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, [email protected]
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> -----Original Message-----
> From: David Abdurachmanov <[email protected]>
> Sent: 01 July 2020 17:34
> To: Andreas Schwab <[email protected]>
> Cc: Yash Shah <[email protected]>; [email protected]; Albert
> Ou <[email protected]>; Atish Patra <[email protected]>; Anup
> Patel <[email protected]>; [email protected]; linux-
> [email protected] List <[email protected]>; Green Wan
> <[email protected]>; Sachin Ghadi <[email protected]>;
> [email protected]; Palmer Dabbelt <[email protected]>;
> [email protected]; Paul Walmsley ( Sifive)
> <[email protected]>; Alistair Francis <[email protected]>;
> linux-riscv <[email protected]>; Bin Meng
> <[email protected]>
> Subject: Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Wed, Jul 1, 2020 at 1:41 PM Andreas Schwab <[email protected]> wrote:
> >
> > On Jun 16 2020, Yash Shah wrote:
> >
> > > The patch series adds the support for dynamic CPU frequency
> > > switching for FU540-C000 SoC on the HiFive Unleashed board. All the
> > > patches are based on Paul Walmsley's work.
> > >
> > > This series is based on Linux v5.7 and tested on HiFive unleashed board.
> >
> > I'm using that patch with 5.7.5.
> >
> > It appears to interfer with serial output when using the ondemand
> > governor.
>
> I do recall that userspace governor is the only one supported but this might
> have changed before this patch was posted.
>
> Yash, do you have more details?
Yes, you are right. The userspace governor is the only one supported.
- Yash
>
> >
> > I also see soft lockups when using the performance governor:
> >
> > [ 101.587527] rcu: INFO: rcu_sched self-detected stall on CPU
> > [ 101.592322] rcu: 0-...!: (932 ticks this GP)
> idle=11a/1/0x4000000000000004 softirq=4301/4301 fqs=4
> > [ 101.601432] (t=6001 jiffies g=4017 q=859) [ 101.605514] rcu:
> > rcu_sched kthread starved for 5984 jiffies! g4017 f0x0
> > RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=2 [ 101.615494] rcu: RCU grace-
> period kthread stack dump:
> > [ 101.620530] rcu_sched R running task 0 10 2 0x00000000
> > [ 101.627560] Call Trace:
> > [ 101.630004] [<ffffffe00085a7e2>] __schedule+0x25c/0x616 [
> > 101.635205] [<ffffffe00085abde>] schedule+0x42/0xb2 [ 101.640070]
> > [<ffffffe00085d0ba>] schedule_timeout+0x56/0xb8 [ 101.645626]
> > [<ffffffe000263c34>] rcu_gp_fqs_loop+0x208/0x248 [ 101.651266]
> > [<ffffffe0002666de>] rcu_gp_kthread+0xc2/0xcc [ 101.656651]
> > [<ffffffe00022654e>] kthread+0xda/0xec [ 101.661426]
> > [<ffffffe00020140a>] ret_from_exception+0x0/0xc [ 101.666977] Task
> > dump for CPU 0:
> > [ 101.670187] loop0 R running task 0 655 2 0x00000008
> > [ 101.677218] Call Trace:
> > [ 101.679657] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa [
> > 101.685036] [<ffffffe000202b76>] show_stack+0x2a/0x34 [ 101.690074]
> > [<ffffffe0002319b0>] sched_show_task.part.0+0xc2/0xd2 [ 101.696154]
> > [<ffffffe00022bb9c>] sched_show_task+0x64/0x66 [ 101.701618]
> > [<ffffffe000231afe>] dump_cpu_task+0x3e/0x48 [ 101.706916]
> > [<ffffffe000267762>] rcu_dump_cpu_stacks+0x94/0xce [ 101.712731]
> > [<ffffffe0002631f6>] print_cpu_stall+0x116/0x18a [ 101.718375]
> > [<ffffffe000264a46>] check_cpu_stall+0xcc/0x1a2 [ 101.723929]
> > [<ffffffe000264b52>] rcu_pending.constprop.0+0x36/0xaa [ 101.730094]
> > [<ffffffe000266ab2>] rcu_sched_clock_irq+0xa6/0xea [ 101.735913]
> > [<ffffffe00026d1be>] update_process_times+0x1e/0x42 [ 101.741821]
> > [<ffffffe0002793bc>] tick_sched_handle+0x26/0x52 [ 101.747456]
> > [<ffffffe0002798fe>] tick_sched_timer+0x6a/0xd0 [ 101.753015]
> > [<ffffffe00026d9be>] __run_hrtimer.constprop.0+0x50/0xe8
> > [ 101.759353] [<ffffffe00026da9e>] __hrtimer_run_queues+0x48/0x6c [
> > 101.765254] [<ffffffe00026e410>] hrtimer_interrupt+0xca/0x1d4 [
> > 101.770985] [<ffffffe0006ceef8>] riscv_timer_interrupt+0x32/0x3a [
> > 101.776976] [<ffffffe00085e17c>] do_IRQ+0xa4/0xb8 [ 101.781663]
> > [<ffffffe00020140a>] ret_from_exception+0x0/0xc
> >
> > Andreas.
> >
> > --
> > Andreas Schwab, SUSE Labs, [email protected] GPG Key fingerprint = 0196
> > BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something
> > completely different."
> >
> > _______________________________________________
> > linux-riscv mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Jul 03 2020, Yash Shah wrote:
> Yes, you are right. The userspace governor is the only one supported.
That doesn't make sense to me. How is the userspace governor different
from any other governor?
Andreas.
--
Andreas Schwab, SUSE Labs, [email protected]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Hi Andreas,
> -----Original Message-----
> From: Andreas Schwab <[email protected]>
> Sent: 01 July 2020 16:11
> To: Yash Shah <[email protected]>
> Cc: Paul Walmsley ( Sifive) <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Sachin Ghadi
> <[email protected]>; [email protected]; [email protected];
> [email protected]; Green Wan <[email protected]>;
> [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
>
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
>
> On Jun 16 2020, Yash Shah wrote:
>
> > The patch series adds the support for dynamic CPU frequency switching
> > for FU540-C000 SoC on the HiFive Unleashed board. All the patches are
> > based on Paul Walmsley's work.
> >
> > This series is based on Linux v5.7 and tested on HiFive unleashed board.
>
> I'm using that patch with 5.7.5.
>
> It appears to interfer with serial output when using the ondemand governor.
>
> I also see soft lockups when using the performance governor:
>
> [ 101.587527] rcu: INFO: rcu_sched self-detected stall on CPU
> [ 101.592322] rcu: 0-...!: (932 ticks this GP)
> idle=11a/1/0x4000000000000004 softirq=4301/4301 fqs=4
> [ 101.601432] (t=6001 jiffies g=4017 q=859) [ 101.605514] rcu: rcu_sched
> kthread starved for 5984 jiffies! g4017 f0x0 RCU_GP_WAIT_FQS(5) -
> >state=0x0 ->cpu=2 [ 101.615494] rcu: RCU grace-period kthread stack
> dump:
> [ 101.620530] rcu_sched R running task 0 10 2 0x00000000
> [ 101.627560] Call Trace:
> [ 101.630004] [<ffffffe00085a7e2>] __schedule+0x25c/0x616 [ 101.635205]
> [<ffffffe00085abde>] schedule+0x42/0xb2 [ 101.640070]
> [<ffffffe00085d0ba>] schedule_timeout+0x56/0xb8 [ 101.645626]
> [<ffffffe000263c34>] rcu_gp_fqs_loop+0x208/0x248 [ 101.651266]
> [<ffffffe0002666de>] rcu_gp_kthread+0xc2/0xcc [ 101.656651]
> [<ffffffe00022654e>] kthread+0xda/0xec [ 101.661426] [<ffffffe00020140a>]
> ret_from_exception+0x0/0xc [ 101.666977] Task dump for CPU 0:
> [ 101.670187] loop0 R running task 0 655 2 0x00000008
> [ 101.677218] Call Trace:
> [ 101.679657] [<ffffffe0002028ae>] walk_stackframe+0x0/0xaa [
> 101.685036] [<ffffffe000202b76>] show_stack+0x2a/0x34 [ 101.690074]
> [<ffffffe0002319b0>] sched_show_task.part.0+0xc2/0xd2 [ 101.696154]
> [<ffffffe00022bb9c>] sched_show_task+0x64/0x66 [ 101.701618]
> [<ffffffe000231afe>] dump_cpu_task+0x3e/0x48 [ 101.706916]
> [<ffffffe000267762>] rcu_dump_cpu_stacks+0x94/0xce [ 101.712731]
> [<ffffffe0002631f6>] print_cpu_stall+0x116/0x18a [ 101.718375]
> [<ffffffe000264a46>] check_cpu_stall+0xcc/0x1a2 [ 101.723929]
> [<ffffffe000264b52>] rcu_pending.constprop.0+0x36/0xaa [ 101.730094]
> [<ffffffe000266ab2>] rcu_sched_clock_irq+0xa6/0xea [ 101.735913]
> [<ffffffe00026d1be>] update_process_times+0x1e/0x42 [ 101.741821]
> [<ffffffe0002793bc>] tick_sched_handle+0x26/0x52 [ 101.747456]
> [<ffffffe0002798fe>] tick_sched_timer+0x6a/0xd0 [ 101.753015]
> [<ffffffe00026d9be>] __run_hrtimer.constprop.0+0x50/0xe8
> [ 101.759353] [<ffffffe00026da9e>] __hrtimer_run_queues+0x48/0x6c [
> 101.765254] [<ffffffe00026e410>] hrtimer_interrupt+0xca/0x1d4 [
> 101.770985] [<ffffffe0006ceef8>] riscv_timer_interrupt+0x32/0x3a [
> 101.776976] [<ffffffe00085e17c>] do_IRQ+0xa4/0xb8 [ 101.781663]
> [<ffffffe00020140a>] ret_from_exception+0x0/0xc
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, [email protected] GPG Key fingerprint = 0196
> BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something
> completely different."
I am looking into the issues you reported. I will update soon.
Thanks for testing.
- Yash
On Mon, 06 Jul 2020 01:15:42 PDT (-0700), [email protected] wrote:
> On Jul 03 2020, Yash Shah wrote:
>
>> Yes, you are right. The userspace governor is the only one supported.
>
> That doesn't make sense to me. How is the userspace governor different
> from any other governor?
It's not.
The issue here is that pretty much everything is on one clock, including all
the cores and the simple IO devices. These IO devices have programmable clock
dividers that need to mesh up with the input clock rate in order to operate
correctly. There's no way to do that atomicly WRT the device's clock, so we
have to pause device IO while messing with the clocks.
I bet there's some issue with 4cbd7814bbd5 ("tty: sifive: Finish transmission
before changing the clock") that's causing the serial to get corrupted, and I
guess I'd start with all the issues I pointed out in the patch text :).
Presumably we need to fix the SPI driver as well, in much the same fashion
(though hopefully with fewer hardware surprises to work around). I'd be way
more worried about ChipLink, as I don't know how that's clocked. IIRC Ethernet
has its own clock so it should be safe.
I'd be very skeptical about turning on dynamic frequency scaling for the HiFive
Unleashed, as it's probably just not worth chasing the long tail of bugs. Even
allowing the userspace governor is a bit sketchy, but given that it's a very
early dev board I assume these sorts of problems are expected.
If we do ever turn dynamic frequency scaling on it's not going to default to
allowing 1.4GHz, from what I saw speeds much over 1GHz don't work for most
people.
On Tue, Jun 16, 2020 at 8:01 PM Yash Shah <[email protected]> wrote:
>
> Declare that each hart defined in the FU540 DT data is clocked by the
> COREPLL. This is in preparation for enabling CPUFreq for the
> FU540-C000 SoC on the HiFive Unleashed board.
>
> Signed-off-by: Yash Shah <[email protected]>
> ---
> arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
Any idea of why this patch was not applied?
Regards,
Bin
On Wed, Jun 16, 2021 at 6:17 AM Bin Meng <[email protected]> wrote:
>
> On Tue, Jun 16, 2020 at 8:01 PM Yash Shah <[email protected]> wrote:
> >
> > Declare that each hart defined in the FU540 DT data is clocked by the
> > COREPLL. This is in preparation for enabling CPUFreq for the
> > FU540-C000 SoC on the HiFive Unleashed board.
> >
> > Signed-off-by: Yash Shah <[email protected]>
> > ---
> > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
>
> Any idea of why this patch was not applied?
There was a decision not to upstream CPUFreq stuff for Unleashed thus
the whole series probably was abandoned. Not all Unleashed can operate
in a stable way at 1.4GHz. IIRC other issues could exist. See Palmer
reply for the whole series.
david
>
> Regards,
> Bin
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Wed, Jun 16, 2021 at 11:14 PM David Abdurachmanov
<[email protected]> wrote:
>
> On Wed, Jun 16, 2021 at 6:17 AM Bin Meng <[email protected]> wrote:
> >
> > On Tue, Jun 16, 2020 at 8:01 PM Yash Shah <[email protected]> wrote:
> > >
> > > Declare that each hart defined in the FU540 DT data is clocked by the
> > > COREPLL. This is in preparation for enabling CPUFreq for the
> > > FU540-C000 SoC on the HiFive Unleashed board.
> > >
> > > Signed-off-by: Yash Shah <[email protected]>
> > > ---
> > > arch/riscv/boot/dts/sifive/fu540-c000.dtsi | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> >
> > Any idea of why this patch was not applied?
>
> There was a decision not to upstream CPUFreq stuff for Unleashed thus
> the whole series probably was abandoned. Not all Unleashed can operate
> in a stable way at 1.4GHz. IIRC other issues could exist. See Palmer
> reply for the whole series.
Thanks, but the DT change is still valid, and should be upstreamed.
Regards,
Bin