[v3] cpuidle: add riscv cpuidle driver

Palmer Dabbelt palmer at dabbelt.com
Fri Nov 20 21:34:40 EST 2020


On Thu, 12 Nov 2020 08:28:09 PST (-0800), rafael at kernel.org wrote:
> On Fri, Sep 25, 2020 at 5:46 AM liush <liush at allwinnertech.com> wrote:
>>
>> This patch adds a simple cpuidle driver for RISC-V systems using
>> the WFI state. Other states will be supported in the future.
>>
>> Reported-by: kernel test robot <lkp at intel.com>
>
> This isn't needed in a patch adding a new driver.
>
>> Signed-off-by: liush <liush at allwinnertech.com>
>> ---
>> Changes in v3:
>> - fix the issue reported by kernel test robot
>>   "drivers/cpuidle/cpuidle-riscv.c:22:12: warning: no previous prototype
>>    for 'riscv_low_level_suspend_enter' [-Wmissing-prototypes]"
>> Changes in v2:
>> - call "mb()" before run "WFI" in cpu_do_idle
>> - modify commit description
>> - place "select CPU_IDLE" in alphabetical order
>> - replace "__asm__ __volatile__ ("wfi")" with "wait_for_interrupt()"
>> - delete "cpuidle.c",move "cpu_do_idle()" to cpuidle.h
>> - modify "arch_cpu_idle", "cpu_do_idle" can be called by
>>   "arch_cpu_idle"
>> - fix space/tab issues
>> - modify riscv_low_level_suspend_enter to __weak mode
>>
>>  arch/riscv/Kconfig               |  7 +++++
>>  arch/riscv/include/asm/cpuidle.h | 16 ++++++++++++
>>  arch/riscv/kernel/process.c      |  3 ++-
>>  drivers/cpuidle/Kconfig          |  5 ++++
>>  drivers/cpuidle/Kconfig.riscv    | 11 ++++++++
>>  drivers/cpuidle/Makefile         |  4 +++
>>  drivers/cpuidle/cpuidle-riscv.c  | 55 ++++++++++++++++++++++++++++++++++++++++
>>  7 files changed, 100 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/riscv/include/asm/cpuidle.h
>>  create mode 100644 drivers/cpuidle/Kconfig.riscv
>>  create mode 100644 drivers/cpuidle/cpuidle-riscv.c
>>
>> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
>> index df18372..799bf86 100644
>> --- a/arch/riscv/Kconfig
>> +++ b/arch/riscv/Kconfig
>> @@ -33,6 +33,7 @@ config RISCV
>>         select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
>>         select CLONE_BACKWARDS
>>         select COMMON_CLK
>> +       select CPU_IDLE
>>         select EDAC_SUPPORT
>>         select GENERIC_ARCH_TOPOLOGY if SMP
>>         select GENERIC_ATOMIC64 if !64BIT
>> @@ -407,6 +408,12 @@ config BUILTIN_DTB
>>         depends on RISCV_M_MODE
>>         depends on OF
>>
>> +menu "CPU Power Management"
>> +
>> +source "drivers/cpuidle/Kconfig"
>> +
>> +endmenu
>> +
>>  menu "Power management options"
>>
>>  source "kernel/power/Kconfig"
>> diff --git a/arch/riscv/include/asm/cpuidle.h b/arch/riscv/include/asm/cpuidle.h
>> new file mode 100644
>> index 00000000..599b810
>> --- /dev/null
>> +++ b/arch/riscv/include/asm/cpuidle.h
>> @@ -0,0 +1,16 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef __RISCV_CPUIDLE_H
>> +#define __RISCV_CPUIDLE_H
>> +
>> +static inline void cpu_do_idle(void)
>> +{
>> +       /*
>> +        * Add mb() here to ensure that all
>> +        * IO/MEM access are completed prior
>> +        * to enter WFI.
>> +        */
>> +       mb();
>
> Either the comment isn't precise enough, or this may not work as expected.
>
> The memory barrier prevents memory accesses occurring earlier in the
> code flow from being reordered (by the processor or by the compiler)
> after the function call below, but is this really needed?  That is,
> can they be reordered anyway?  If so, then why?
>
>> +       wait_for_interrupt();
>> +}
>> +
>> +#endif
>> diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
>> index 2b97c49..5431aaa 100644
>> --- a/arch/riscv/kernel/process.c
>> +++ b/arch/riscv/kernel/process.c
>> @@ -21,6 +21,7 @@
>>  #include <asm/string.h>
>>  #include <asm/switch_to.h>
>>  #include <asm/thread_info.h>
>> +#include <asm/cpuidle.h>
>>
>>  register unsigned long gp_in_global __asm__("gp");
>>
>> @@ -35,7 +36,7 @@ extern asmlinkage void ret_from_kernel_thread(void);
>>
>>  void arch_cpu_idle(void)
>>  {
>> -       wait_for_interrupt();
>> +       cpu_do_idle();
>>         local_irq_enable();
>>  }
>>
>> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
>> index c0aeedd..f6be0fd 100644
>> --- a/drivers/cpuidle/Kconfig
>> +++ b/drivers/cpuidle/Kconfig
>> @@ -62,6 +62,11 @@ depends on PPC
>>  source "drivers/cpuidle/Kconfig.powerpc"
>>  endmenu
>>
>> +menu "RISCV CPU Idle Drivers"
>> +depends on RISCV
>> +source "drivers/cpuidle/Kconfig.riscv"
>> +endmenu
>> +
>>  config HALTPOLL_CPUIDLE
>>         tristate "Halt poll cpuidle driver"
>>         depends on X86 && KVM_GUEST
>> diff --git a/drivers/cpuidle/Kconfig.riscv b/drivers/cpuidle/Kconfig.riscv
>> new file mode 100644
>> index 00000000..7bec059
>> --- /dev/null
>> +++ b/drivers/cpuidle/Kconfig.riscv
>> @@ -0,0 +1,11 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +#
>> +# RISCV CPU Idle drivers
>> +#
>> +config RISCV_CPUIDLE
>> +       bool "Generic RISCV CPU idle Driver"
>> +       select DT_IDLE_STATES
>> +       select CPU_IDLE_MULTIPLE_DRIVERS
>> +       help
>> +         Select this option to enable generic cpuidle driver for RISCV.
>> +         Now only support C0 State.
>> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
>> index 26bbc5e..4c83c4e 100644
>> --- a/drivers/cpuidle/Makefile
>> +++ b/drivers/cpuidle/Makefile
>> @@ -34,3 +34,7 @@ obj-$(CONFIG_MIPS_CPS_CPUIDLE)                += cpuidle-cps.o
>>  # POWERPC drivers
>>  obj-$(CONFIG_PSERIES_CPUIDLE)          += cpuidle-pseries.o
>>  obj-$(CONFIG_POWERNV_CPUIDLE)          += cpuidle-powernv.o
>> +
>> +###############################################################################
>> +# RISCV drivers
>> +obj-$(CONFIG_RISCV_CPUIDLE)            += cpuidle-riscv.o
>> diff --git a/drivers/cpuidle/cpuidle-riscv.c b/drivers/cpuidle/cpuidle-riscv.c
>> new file mode 100644
>> index 00000000..5dddcfa
>> --- /dev/null
>> +++ b/drivers/cpuidle/cpuidle-riscv.c
>> @@ -0,0 +1,55 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * RISC-V CPU idle driver.
>> + *
>> + * Copyright (C) 2020-2022 Allwinner Ltd
>> + *
>> + * Based on code - driver/cpuidle/cpuidle-at91.c
>> + *
>> + */
>> +#include <linux/cpuidle.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/cpu_pm.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/slab.h>
>> +#include <linux/platform_device.h>
>> +#include <asm/cpuidle.h>
>> +
>> +#define MAX_IDLE_STATES        1
>> +
>> +/* TODO: Implement deeper idle states */
>> +static int riscv_low_level_suspend_enter(int state)
>> +{
>> +       return 0;
>> +}
>> +
>> +/* Actual code that puts the SoC in different idle states */
>> +static int riscv_enter_idle(struct cpuidle_device *dev,
>> +                       struct cpuidle_driver *drv,
>> +                              int index)
>> +{
>> +       return CPU_PM_CPU_IDLE_ENTER_PARAM(riscv_low_level_suspend_enter,
>> +                                          index, 0);
>
> I'm not sure why this is needed at all.
>
> Because there is only one idle state, idx in __CPU_PM_CPU_IDLE_ENTER()
> will always be 0, so it'll always call cpu_do_idle(), so can't it be
> invoked directly from here?
>
> And since the arch_cpu_idle() is also WFI, why is the full-blown
> cpuidle driver needed at this point?

IIRC that was essentially the same feedback as I had on some earlier version of
this.  The ISA defines WFI and a handful of pause mechanisms, and while I'd be
happy to take a driver that selects between those I don't really see a reason
to unless there's some hardware that benefits from it.  I would definitely buy
the argument that those existing standard mechanisms are insufficient to build
a realistic chip, but without any concrete users it's very hard to reason about
any code -- that's true for standard extensions, but doubly so for anything
else.  In this case requiring an in-tree user may be a bit pedantic, as there's
really only one way to go about this sort of thing, but it's the generally
accepted approach in Linux and without an in-tree user it's very hard to
maintain the code.

I know it can be a headache to keep stuff like this out of tree, and while
we've accepted some stuff with only out of tree users I don't want to make that
a general policy.  Specifically I'm thinking of some helper functions for the
hypervisor extension that aren't properly used, but I consider that a bit of a
special case -- that's a standard RISC-V extension, and the ratification
process is just so glacially paced that it seems silly to make a bunch more
work for everyone when it comes to some simple refactoring.

In this case I don't really see such a concrete use case.  I suppose a driver
could be constructed for the WFM/pause type stuff, but I don't really see those
(at least as currently defined) being interesting for the Linux use case.
While obviously it'd be best to have any other idle scheme as a standard RISC-V
extension, I understand that is a long process and my guess would be that
(assuming the RISC-V stuff ever get taken seriously) we have a bunch of
non-standard schemes that arrive before an official standard shows up.  While I
don't really see any reason to do anything differently for an arbitrary idle
driver, it's impossible to reason about that sort of thing without some user of
the code.

So essentially: I'd be happy to take this if something used it, but without a
user I don't really see how I can.

Sorry!

>
>> +}
>> +
>> +static struct cpuidle_driver riscv_idle_driver = {
>> +       .name                   = "riscv_idle",
>> +       .owner                  = THIS_MODULE,
>> +       .states[0]              = {
>> +               .enter                  = riscv_enter_idle,
>> +               .exit_latency           = 1,
>> +               .target_residency       = 1,
>> +               .name                   = "WFI",
>> +               .desc                   = "RISCV WFI",
>> +       },
>> +       .state_count = MAX_IDLE_STATES,
>> +};
>> +
>> +static int __init riscv_cpuidle_init(void)
>> +{
>> +       return cpuidle_register(&riscv_idle_driver, NULL);
>> +}
>> +
>> +device_initcall(riscv_cpuidle_init);
>> --



More information about the linux-riscv mailing list