Documentation/devicetree/bindings/cpu/idle-states.yaml

Source file repositories/reference/linux-study-clean/Documentation/devicetree/bindings/cpu/idle-states.yaml

File Facts

System
Linux kernel
Corpus path
Documentation/devicetree/bindings/cpu/idle-states.yaml
Extension
.yaml
Size
34811 bytes
Lines
929
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: configuration, schema, or hardware description
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/cpu/idle-states.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Idle states

maintainers:
  - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
  - Anup Patel <anup@brainfault.org>

description: |+
  ==========================================
  1 - Introduction
  ==========================================

  ARM and RISC-V systems contain HW capable of managing power consumption
  dynamically, where cores can be put in different low-power states (ranging
  from simple wfi to power gating) according to OS PM policies. The CPU states
  representing the range of dynamic idle states that a processor can enter at
  run-time, can be specified through device tree bindings representing the
  parameters required to enter/exit specific idle states on a given processor.

  ==========================================
  2 - ARM idle states
  ==========================================

  According to the Server Base System Architecture document (SBSA, [3]), the
  power states an ARM CPU can be put into are identified by the following list:

  - Running
  - Idle_standby
  - Idle_retention
  - Sleep
  - Off

  The power states described in the SBSA document define the basic CPU states on
  top of which ARM platforms implement power management schemes that allow an OS
  PM implementation to put the processor in different idle states (which include
  states listed above; "off" state is not an idle state since it does not have
  wake-up capabilities, hence it is not considered in this document).

  Idle state parameters (e.g. entry latency) are platform specific and need to
  be characterized with bindings that provide the required information to OS PM
  code so that it can build the required tables and use them at runtime.

  The device tree binding definition for ARM idle states is the subject of this
  document.

  ==========================================
  3 - RISC-V idle states
  ==========================================

  On RISC-V systems, the HARTs (or CPUs) [6] can be put in platform specific
  suspend (or idle) states (ranging from simple WFI, power gating, etc). The
  RISC-V SBI v0.3 (or higher) [7] hart state management extension provides a
  standard mechanism for OS to request HART state transitions.

  The platform specific suspend (or idle) states of a hart can be either
  retentive or non-rententive in nature. A retentive suspend state will
  preserve HART registers and CSR values for all privilege modes whereas
  a non-retentive suspend state will not preserve HART registers and CSR
  values.

  ===========================================
  4 - idle-states definitions
  ===========================================

  Idle states are characterized for a specific system through a set of

Annotation

Implementation Notes