On Thu, Dec 07, 2017 at 03:05:23PM -0800, Palmer Dabbelt wrote: > RISC-V doesn't currently specify a mechanism for enabling or disabling > CPUs. Instead, we assume that all CPUs are enabled on boot, and if > someone wants to save power we instead put a CPU to sleep via a WFI > loop. Future systems may have an explicit mechanism for putting a CPU > to sleep, so we're standardizing the device tree entry for when that > happens. > > We're not defining a spin-table based interface to the firmware, as the > plan is to handle this entirely within the kernel instead. > > CC: Mark Rutland <mark.rutland@xxxxxxx> > Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxx> > --- > Documentation/devicetree/bindings/riscv/cpus.txt | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.txt b/Documentation/devicetree/bindings/riscv/cpus.txt > index adf7b7af5dc3..68f88eacc594 100644 > --- a/Documentation/devicetree/bindings/riscv/cpus.txt > +++ b/Documentation/devicetree/bindings/riscv/cpus.txt > @@ -82,6 +82,15 @@ described below. > Value type: <string> > Definition: Contains the RISC-V ISA string of this hart. These > ISA strings are defined by the RISC-V ISA manual. > + - cpu-enable-method: > + Usage: optional > + Value type: <stringlist> > + Definition: When absent, default is either "always-disabled" > + "always-enabled", depending on the current state > + of the CPU. How does one determine the state of other cpus? > + Must be one of: > + * "always-disabled": This CPU cannot be enabled. status = "disabled" already serves this purpose. > + * "always-enabled": This CPU cannot be disabled. I don't see how this can work unless the kernel is loaded prior to bringing all cpus out of reset. You have to halt cpus in some way until the kernel is loaded. > > Example: SiFive Freedom U540G Development Kit > --------------------------------------------- > -- > 2.13.6 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
