* [PATCH 1/3] riscv: defconfig, Kconfig: enable CPU power management
2020-06-16 12:01 [PATCH 0/3] Dynamic CPU frequency switching for the HiFive Yash Shah
@ 2020-06-16 12:01 ` Yash Shah
2020-06-16 12:01 ` [PATCH 2/3] riscv: dts: fu540-c000: define hart clocks Yash Shah
` (3 subsequent siblings)
4 siblings, 0 replies; 14+ messages in thread
From: Yash Shah @ 2020-06-16 12:01 UTC (permalink / raw)
To: paul.walmsley, palmer, robh+dt, linux-riscv, linux-kernel,
devicetree, sachin.ghadi
Cc: aou, anup, lollivier, green.wan, atish.patra, Yash Shah,
alistair.francis, deepa.kernel, bmeng.cn
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 <yash.shah@sifive.com>
---
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* [PATCH 2/3] riscv: dts: fu540-c000: define hart clocks
2020-06-16 12:01 [PATCH 0/3] Dynamic CPU frequency switching for the HiFive Yash Shah
2020-06-16 12:01 ` [PATCH 1/3] riscv: defconfig, Kconfig: enable CPU power management Yash Shah
@ 2020-06-16 12:01 ` Yash Shah
2021-06-16 3:16 ` Bin Meng
2020-06-16 12:01 ` [PATCH 3/3] riscv: dts: HiFive Unleashed: define a default set of CPU OPPs Yash Shah
` (2 subsequent siblings)
4 siblings, 1 reply; 14+ messages in thread
From: Yash Shah @ 2020-06-16 12:01 UTC (permalink / raw)
To: paul.walmsley, palmer, robh+dt, linux-riscv, linux-kernel,
devicetree, sachin.ghadi
Cc: aou, anup, lollivier, green.wan, atish.patra, Yash Shah,
alistair.francis, deepa.kernel, bmeng.cn
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 <yash.shah@sifive.com>
---
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
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH 2/3] riscv: dts: fu540-c000: define hart clocks
2020-06-16 12:01 ` [PATCH 2/3] riscv: dts: fu540-c000: define hart clocks Yash Shah
@ 2021-06-16 3:16 ` Bin Meng
2021-06-16 15:13 ` David Abdurachmanov
0 siblings, 1 reply; 14+ messages in thread
From: Bin Meng @ 2021-06-16 3:16 UTC (permalink / raw)
To: Yash Shah
Cc: Paul Walmsley, Palmer Dabbelt, Rob Herring, linux-riscv,
linux-kernel, devicetree, sachin.ghadi, Albert Ou, Green Wan,
Atish Patra, Anup Patel, Alistair Francis, lollivier,
deepa.kernel
On Tue, Jun 16, 2020 at 8:01 PM Yash Shah <yash.shah@sifive.com> 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 <yash.shah@sifive.com>
> ---
> 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] riscv: dts: fu540-c000: define hart clocks
2021-06-16 3:16 ` Bin Meng
@ 2021-06-16 15:13 ` David Abdurachmanov
2021-06-16 22:56 ` Bin Meng
0 siblings, 1 reply; 14+ messages in thread
From: David Abdurachmanov @ 2021-06-16 15:13 UTC (permalink / raw)
To: Bin Meng
Cc: Yash Shah, Paul Walmsley, Palmer Dabbelt, Rob Herring,
linux-riscv, linux-kernel, devicetree, Sachin Ghadi, Albert Ou,
Green Wan, Atish Patra, Anup Patel, Alistair Francis, lollivier,
deepa.kernel
On Wed, Jun 16, 2021 at 6:17 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Tue, Jun 16, 2020 at 8:01 PM Yash Shah <yash.shah@sifive.com> 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 <yash.shah@sifive.com>
> > ---
> > 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
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] riscv: dts: fu540-c000: define hart clocks
2021-06-16 15:13 ` David Abdurachmanov
@ 2021-06-16 22:56 ` Bin Meng
0 siblings, 0 replies; 14+ messages in thread
From: Bin Meng @ 2021-06-16 22:56 UTC (permalink / raw)
To: David Abdurachmanov
Cc: Yash Shah, Paul Walmsley, Palmer Dabbelt, Rob Herring,
linux-riscv, linux-kernel, devicetree, Sachin Ghadi, Albert Ou,
Green Wan, Atish Patra, Anup Patel, Alistair Francis, lollivier,
deepa.kernel
On Wed, Jun 16, 2021 at 11:14 PM David Abdurachmanov
<david.abdurachmanov@gmail.com> wrote:
>
> On Wed, Jun 16, 2021 at 6:17 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > On Tue, Jun 16, 2020 at 8:01 PM Yash Shah <yash.shah@sifive.com> 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 <yash.shah@sifive.com>
> > > ---
> > > 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 3/3] riscv: dts: HiFive Unleashed: define a default set of CPU OPPs
2020-06-16 12:01 [PATCH 0/3] Dynamic CPU frequency switching for the HiFive Yash Shah
2020-06-16 12:01 ` [PATCH 1/3] riscv: defconfig, Kconfig: enable CPU power management Yash Shah
2020-06-16 12:01 ` [PATCH 2/3] riscv: dts: fu540-c000: define hart clocks Yash Shah
@ 2020-06-16 12:01 ` Yash Shah
2020-06-29 9:30 ` [PATCH 0/3] Dynamic CPU frequency switching for the HiFive Greentime Hu
2020-07-01 10:40 ` Andreas Schwab
4 siblings, 0 replies; 14+ messages in thread
From: Yash Shah @ 2020-06-16 12:01 UTC (permalink / raw)
To: paul.walmsley, palmer, robh+dt, linux-riscv, linux-kernel,
devicetree, sachin.ghadi
Cc: aou, anup, lollivier, green.wan, atish.patra, Yash Shah,
alistair.francis, deepa.kernel, bmeng.cn
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 <yash.shah@sifive.com>
---
.../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
^ permalink raw reply related [flat|nested] 14+ messages in thread* Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
2020-06-16 12:01 [PATCH 0/3] Dynamic CPU frequency switching for the HiFive Yash Shah
` (2 preceding siblings ...)
2020-06-16 12:01 ` [PATCH 3/3] riscv: dts: HiFive Unleashed: define a default set of CPU OPPs Yash Shah
@ 2020-06-29 9:30 ` Greentime Hu
2020-07-01 10:40 ` Andreas Schwab
4 siblings, 0 replies; 14+ messages in thread
From: Greentime Hu @ 2020-06-29 9:30 UTC (permalink / raw)
To: Yash Shah
Cc: devicetree, Albert Ou, Atish Patra, Anup Patel, lollivier,
Linux Kernel Mailing List, Green Wan, sachin.ghadi, robh+dt,
Palmer Dabbelt, deepa.kernel, Paul Walmsley, alistair.francis,
linux-riscv, bmeng.cn
Yash Shah <yash.shah@sifive.com> 於 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 <greentime.hu@sifive.com>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
2020-06-16 12:01 [PATCH 0/3] Dynamic CPU frequency switching for the HiFive Yash Shah
` (3 preceding siblings ...)
2020-06-29 9:30 ` [PATCH 0/3] Dynamic CPU frequency switching for the HiFive Greentime Hu
@ 2020-07-01 10:40 ` Andreas Schwab
2020-07-01 12:04 ` David Abdurachmanov
2020-07-08 12:06 ` Yash Shah
4 siblings, 2 replies; 14+ messages in thread
From: Andreas Schwab @ 2020-07-01 10:40 UTC (permalink / raw)
To: Yash Shah
Cc: devicetree, aou, atish.patra, anup, lollivier, linux-kernel,
green.wan, sachin.ghadi, robh+dt, palmer, deepa.kernel,
paul.walmsley, alistair.francis, linux-riscv, bmeng.cn
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, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
2020-07-01 10:40 ` Andreas Schwab
@ 2020-07-01 12:04 ` David Abdurachmanov
2020-07-03 5:53 ` Yash Shah
2020-07-08 12:06 ` Yash Shah
1 sibling, 1 reply; 14+ messages in thread
From: David Abdurachmanov @ 2020-07-01 12:04 UTC (permalink / raw)
To: Andreas Schwab
Cc: devicetree, Albert Ou, Sachin Ghadi, Anup Patel, lollivier,
linux-kernel@vger.kernel.org List, green.wan, Atish Patra,
Yash Shah, robh+dt, Palmer Dabbelt, deepa.kernel, Paul Walmsley,
Alistair Francis, linux-riscv, Bin Meng
On Wed, Jul 1, 2020 at 1:41 PM Andreas Schwab <schwab@suse.de> 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, schwab@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
2020-07-01 12:04 ` David Abdurachmanov
@ 2020-07-03 5:53 ` Yash Shah
2020-07-06 8:15 ` Andreas Schwab
0 siblings, 1 reply; 14+ messages in thread
From: Yash Shah @ 2020-07-03 5:53 UTC (permalink / raw)
To: David Abdurachmanov, Andreas Schwab
Cc: devicetree, Albert Ou, Sachin Ghadi, Anup Patel, lollivier,
linux-kernel@vger.kernel.org List, Green Wan, Atish Patra,
robh+dt, Palmer Dabbelt, deepa.kernel, Paul Walmsley ( Sifive),
Alistair Francis, linux-riscv, Bin Meng
> -----Original Message-----
> From: David Abdurachmanov <david.abdurachmanov@gmail.com>
> Sent: 01 July 2020 17:34
> To: Andreas Schwab <schwab@suse.de>
> Cc: Yash Shah <yash.shah@sifive.com>; devicetree@vger.kernel.org; Albert
> Ou <aou@eecs.berkeley.edu>; Atish Patra <atish.patra@wdc.com>; Anup
> Patel <anup@brainfault.org>; lollivier@baylibre.com; linux-
> kernel@vger.kernel.org List <linux-kernel@vger.kernel.org>; Green Wan
> <green.wan@sifive.com>; Sachin Ghadi <sachin.ghadi@sifive.com>;
> robh+dt@kernel.org; Palmer Dabbelt <palmer@dabbelt.com>;
> deepa.kernel@gmail.com; Paul Walmsley ( Sifive)
> <paul.walmsley@sifive.com>; Alistair Francis <alistair.francis@wdc.com>;
> linux-riscv <linux-riscv@lists.infradead.org>; Bin Meng
> <bmeng.cn@gmail.com>
> 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 <schwab@suse.de> 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, schwab@suse.de GPG Key fingerprint = 0196
> > BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something
> > completely different."
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
2020-07-03 5:53 ` Yash Shah
@ 2020-07-06 8:15 ` Andreas Schwab
2020-07-09 20:48 ` Palmer Dabbelt
0 siblings, 1 reply; 14+ messages in thread
From: Andreas Schwab @ 2020-07-06 8:15 UTC (permalink / raw)
To: Yash Shah
Cc: devicetree, Albert Ou, David Abdurachmanov, Anup Patel,
lollivier, linux-kernel@vger.kernel.org List, Green Wan,
Atish Patra, robh+dt, Palmer Dabbelt, Sachin Ghadi,
Paul Walmsley ( Sifive),
Alistair Francis, linux-riscv, Bin Meng, deepa.kernel
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, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
2020-07-06 8:15 ` Andreas Schwab
@ 2020-07-09 20:48 ` Palmer Dabbelt
0 siblings, 0 replies; 14+ messages in thread
From: Palmer Dabbelt @ 2020-07-09 20:48 UTC (permalink / raw)
To: schwab
Cc: devicetree, aou, david.abdurachmanov, anup, lollivier,
linux-kernel, green.wan, Atish Patra, yash.shah, robh+dt,
Alistair Francis, sachin.ghadi, Paul Walmsley, linux-riscv,
bmeng.cn, deepa.kernel
On Mon, 06 Jul 2020 01:15:42 PDT (-0700), schwab@suse.de 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.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH 0/3] Dynamic CPU frequency switching for the HiFive
2020-07-01 10:40 ` Andreas Schwab
2020-07-01 12:04 ` David Abdurachmanov
@ 2020-07-08 12:06 ` Yash Shah
1 sibling, 0 replies; 14+ messages in thread
From: Yash Shah @ 2020-07-08 12:06 UTC (permalink / raw)
To: Andreas Schwab
Cc: devicetree, aou, atish.patra, anup, lollivier, linux-kernel,
Green Wan, Sachin Ghadi, robh+dt, palmer, deepa.kernel,
Paul Walmsley ( Sifive),
alistair.francis, linux-riscv, bmeng.cn
Hi Andreas,
> -----Original Message-----
> From: Andreas Schwab <schwab@suse.de>
> Sent: 01 July 2020 16:11
> To: Yash Shah <yash.shah@sifive.com>
> Cc: Paul Walmsley ( Sifive) <paul.walmsley@sifive.com>;
> palmer@dabbelt.com; robh+dt@kernel.org; linux-riscv@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicetree@vger.kernel.org; Sachin Ghadi
> <sachin.ghadi@sifive.com>; aou@eecs.berkeley.edu; anup@brainfault.org;
> lollivier@baylibre.com; Green Wan <green.wan@sifive.com>;
> atish.patra@wdc.com; alistair.francis@wdc.com; deepa.kernel@gmail.com;
> bmeng.cn@gmail.com
> 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, schwab@suse.de 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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply [flat|nested] 14+ messages in thread