| /Documentation/leds/ |
| D | ledtrig-transient.rst | 7 specifying how long a state to be on, and the second for how long the state
9 in on state, followed by a delay_off value that specifies how long the LED
10 should stay in off state. The on and off cycle repeats until the trigger
12 features that require an on or off state to be held just once and then stay in
13 the original state forever.
16 set a timer to hold a state, however when user space application crashes or
18 state permanently.
27 class device, the LED state does not change.
30 trigger will be called, and LED state is changed to LED_OFF.
32 Driver suspend changes the LED state to LED_OFF and resume doesn't change
[all …]
|
| /Documentation/devicetree/bindings/powerpc/opal/ |
| D | power-mgt.txt | 10 Typically each idle state has the following associated properties:
12 - name: The name of the idle state as defined by the firmware.
15 extent of state-loss, whether timebase is stopped on this
18 - exit-latency: The latency involved in transitioning the state of the
22 this idle state in order to accrue power-savings
29 provides the value of that property for the idle state associated with
33 "ibm,cpu-idle-state-names" and "ibm,cpu-idle-state-flags" are
37 - ibm,cpu-idle-state-names:
40 - ibm,cpu-idle-state-flags:
49 0x00010000 /* This is a nap state (POWER7,POWER8) */
[all …]
|
| /Documentation/livepatch/ |
| D | system-state.rst | 2 System State Changes
14 change the system behavior or state so that it is no longer safe to
19 This is where the livepatch system state tracking gets useful. It
22 - store data needed to manipulate and restore the system state
28 1. Livepatch system state API
31 The state of the system might get modified either by several livepatch callbacks
35 Each modified state is described by struct klp_state, see
46 - Non-zero number used to identify the affected system state.
50 - Number describing the variant of the system state change that
53 The state can be manipulated using two functions:
[all …]
|
| /Documentation/devicetree/bindings/arm/msm/ |
| D | qcom,idle-state.txt | 3 ARM provides idle-state node to define the cpuidle states, as defined in [1].
16 trigger to execute the SPM state machine. The SPM state machine waits for the
19 the SPM state machine out of its wait, the next step is to ensure that the
21 execution. This state is defined as a generic ARM WFI state by the ARM cpuidle
22 driver and is not defined in the DT. The SPM state machine should be
23 configured to execute this state by default and after executing every other
24 state below.
26 Retention: Retention is a low power state where the core is clock gated and
31 state. Retention may have a slightly higher latency than Standby.
35 to indicate a core entering a power down state without consulting any other
[all …]
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | freezer-subsystem.rst | 16 quiescent state. Once the tasks are quiescent another task can
58 cgroup has its own state (self-state) and the state inherited from the
59 parent (parent-state). Iff both states are THAWED, the cgroup is
64 * freezer.state: Read-write.
66 When read, returns the effective state of the cgroup - "THAWED",
70 FREEZING cgroup transitions into FROZEN state when all tasks
76 When written, sets the self-state of the cgroup. Two values are
78 if not already freezing, enters FREEZING state along with all its
81 If THAWED is written, the self-state of the cgroup is changed to
82 THAWED. Note that the effective state may not change to THAWED if
[all …]
|
| /Documentation/arm/ |
| D | cluster-pm-race-avoidance.rst | 48 Each cluster and CPU is assigned a state, as follows:
71 The CPU or cluster has committed to moving to the UP state.
77 level. A CPU in this state is not necessarily being used
82 state. It may be part way through the process of teardown and
87 The CPU states are described in the "CPU state" section, below.
89 Each cluster is also assigned a state, but it is necessary to split the
90 state value into two parts (the "cluster" state and "inbound" state) and
92 CPUs in the cluster simultaneously modifying the state. The cluster-
93 level states are described in the "Cluster state" section.
96 discussion, the state names are given a `CPU_` prefix for the CPU states,
[all …]
|
| /Documentation/devicetree/bindings/power/ |
| D | domain-idle-state.yaml | 4 $id: http://devicetree.org/schemas/power/domain-idle-state.yaml#
13 A domain idle state node represents the state parameters that will be used to
14 select the state when there are no active components in the PM domain.
24 Each state node represents a domain idle state description.
28 const: domain-idle-state
33 state. Note that, the exit-latency-us duration may be guaranteed only
39 state.
44 state will yield power benefits, after overcoming the overhead while
45 entering the idle state.
60 compatible = "domain-idle-state";
|
| /Documentation/device-mapper/ |
| D | dm-bow.txt | 5 data that is overwritten. The changes can then be committed by a simple state
9 dm_bow has three states, set by writing ‘1’ or ‘2’ to /sys/block/dm-?/bow/state.
10 It is only possible to go from state 0 (initial state) to state 1, and then from
11 state 1 to state 2.
13 State 0: dm_bow collects all trims to the device and assumes that these mark
16 FITRIM ioctl on the file system then switch to state 1. These trims are not
19 State 1: All writes to the device cause the underlying data to be backed up to
22 without dm_bow, so the device is always in a good final state. The exception is
24 we are in this state and to allow rollback. See below for all details. If there
27 State 2: The transition to state 2 triggers replacing the special sector 0 with
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | cpuidle.rst | 44 enter an idle state, that applies to the processor as a whole.
52 enter an idle state, that applies to the core that asked for it in the first
57 remaining core asks the processor to enter an idle state, that may trigger it
58 to put the whole larger unit into an idle state which also will affect the
69 time management perspective and if the processor is asked to enter an idle state
72 core also have asked the processor to enter an idle state. In that situation,
73 the core may be put into an idle state individually or a larger unit containing
74 it may be put into an idle state as a whole (if the other cores within the
106 idle states, or there is not enough time to spend in an idle state before the
119 idle time management subsystem called ``CPUIdle`` to select an idle state for
[all …]
|
| D | sleep-states.rst | 35 working state), such that the processors can spend time in their deepest idle
38 The system is woken up from this state by in-band interrupts, so theoretically
39 any devices that can cause interrupts to be generated in the working state can
42 This state can be used on platforms without support for :ref:`standby <standby>`
52 This state, if supported, offers moderate, but real, energy savings, while
53 providing a relatively straightforward transition back to the working state. No
54 operating state is lost (the system core logic retains power), so the system can
60 are suspended during transitions into this state. For this reason, it should
62 the resume latency will generally be greater than for that state.
64 The set of devices that can wake up the system from this state usually is
[all …]
|
| D | strategies.rst | 20 designated devices, triggering a transition to the ``working state`` in which
22 is affected by the state changes, this strategy is referred to as the
25 The other strategy, referred to as the :doc:`working-state power management
26 <working-state>`, is based on adjusting the power states of individual hardware
27 components of the system, as needed, in the working state. In consequence, if
28 this strategy is in use, the working state of the system usually does not
41 state from the physical system configuration and power draw perspective, but
43 for the same system in a sleep state. However, transitions from sleep states
44 back to the working state can only be started by a limited set of devices, so
45 typically the system can spend much more time in a sleep state than it can be
[all …]
|
| /Documentation/filesystems/caching/ |
| D | object.rst | 13 (*) Object management state machine.
93 Object Management State Machine
96 Within FS-Cache, each active object is managed by its own individual state
97 machine. The state for an object is kept in the fscache_object struct, in
98 object->state. A cookie may point to a set of objects that are in different
101 Each state has an action associated with it that is invoked when the machine
102 wakes up in that state. There are four logical sets of states:
112 and that update the state of objects.
120 When a state has finished processing, it will usually set the mask of events in
135 particular work item. These state actions may be doing sequences of
[all …]
|
| /Documentation/trace/ |
| D | events-power.rst | 8 - Power state switch which reports events related to suspend (S-states),
18 1. Power state switch events
28 cpu_idle "state=%lu cpu_id=%lu"
29 cpu_frequency "state=%lu cpu_id=%lu"
36 machine_suspend "state=%lu"
39 Note: the value of '-1' or '4294967295' for state means an exit from the current state,
41 enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id())
42 means that the system exits the previous idle state.
44 The event which has 'state=4294967295' in the trace is very important to the user
45 space tools which are using it to detect the end of the current state, and so to
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | acpi-lid.rst | 14 Platforms containing lids convey lid state (open/close) to OSPMs
16 Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
18 report the "current" state of the lid as either "opened" or "closed".
30 The _LID control method is described to return the "current" lid state.
32 the lid state upon the last lid notification instead of returning the lid
33 state upon the last _LID evaluation. There won't be difference when the
37 There are platforms always retun "closed" as initial lid state.
39 Restrictions of the lid state change notifications
42 There are buggy AML tables never notifying when the lid device state is
45 state is changed to "closed". The "closed" notification is normally used to
[all …]
|
| /Documentation/input/devices/ |
| D | rotary-encoder.rst | 16 a stable state with both outputs high (half-period mode) and some have
17 a stable state in all steps (quarter-period mode).
46 Events / state machine
49 In half-period mode, state a) and c) above are used to determine the
50 rotational direction based on the last stable state. Events are reported in
51 states b) and d) given that the new stable state is different from the last
56 a) Rising edge on channel A, channel B in low state
57 This state is used to recognize a clockwise turn
59 b) Rising edge on channel B, channel A in high state
60 When entering this state, the encoder is put into 'armed' state,
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-extcon | 31 What: /sys/class/extcon/.../state
35 The /sys/class/extcon/.../state shows and stores the cable
44 # cat state
54 In order to update the state of an extcon device, enter a hex
55 state number starting with 0x::
57 # echo 0xHEX > state
59 This updates the whole state of the extcon device.
63 It is recommended to use this "global" state interface if
64 you need to set the value atomically. The later state
75 What: /sys/class/extcon/.../cable.x/state
[all …]
|
| D | sysfs-class-remoteproc | 10 stopped (using /sys/class/remoteproc/.../state) and write a new filename.
12 What: /sys/class/remoteproc/.../state
15 Description: Remote processor state
17 Reports the state of the remote processor, which will be one of:
30 "running" is the normal state of an available remote processor
36 unknown state.
38 Writing this file controls the state of the remote processor.
47 transition to "running" state.
50 return it to the "offline" state.
60 up the usage in modifying the 'firmware' or 'state' files.
[all …]
|
| /Documentation/networking/ |
| D | operstates.rst | 11 Linux distinguishes between administrative and operational state of an
12 interface. Administrative state is the result of "ip link set dev
19 to be performed before user data can be transferred. Operational state
23 influence operational state. To accommodate this, operational state is
25 a RFC2863 compatible state that is derived from these flags, a policy,
32 Both admin and operational state can be queried via the netlink
37 These values contain interface state:
43 Interface is in RFC2863 operational state UP or UNKNOWN. This is for
56 contains RFC2863 state of the interface in numeric representation:
59 Interface is in unknown state, neither driver nor userspace has set
[all …]
|
| D | xfrm_proc.rst | 32 No state is found
47 State is expired
50 State has mismatch option
54 State is invalid
71 State hasn't been fully acquired before use
88 No state is found
101 State is expired
113 State is invalid, perhaps expired
|
| /Documentation/devicetree/bindings/regulator/ |
| D | tps62360-regulator.txt | 20 - ti,vsel0-state-high: Initial state of vsel0 input is high.
21 If this property is missing, then assume the state as low (0).
22 - ti,vsel1-state-high: Initial state of vsel1 input is high.
23 If this property is missing, then assume the state as low (0).
39 ti,vsel0-state-high;
40 ti,vsel1-state-high;
|
| D | mcp16502-regulator.txt | 44 regulator-state-standby {
49 regulator-state-mem {
63 regulator-state-standby {
68 regulator-state-mem {
82 regulator-state-standby {
87 regulator-state-mem {
101 regulator-state-standby {
106 regulator-state-mem {
118 regulator-state-standby {
122 regulator-state-mem {
[all …]
|
| /Documentation/devicetree/bindings/leds/ |
| D | register-bit-led.txt | 26 - default-state: (optional) The initial state of the LED
41 default-state = "on";
49 default-state = "off";
57 default-state = "off";
64 default-state = "off";
71 default-state = "off";
78 default-state = "off";
85 default-state = "off";
92 default-state = "off";
|
| /Documentation/sphinx/ |
| D | kernel_abi.py | 87 doc = self.state.document
174 kernellog.info(self.state.document.settings.env.app, "%s: parsed %i lines" % (fname, n))
183 with switch_source_input(self.state, content):
184 self.state.nested_parse(content, 0, node, match_titles=1)
186 … buf = self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter
188 self.state.memo.title_styles = []
189 self.state.memo.section_level = 0
190 self.state.memo.reporter = AutodocReporter(content, self.state.memo.reporter)
192 self.state.nested_parse(content, 0, node, match_titles=1)
194 … self.state.memo.title_styles, self.state.memo.section_level, self.state.memo.reporter = buf
|
| /Documentation/devicetree/bindings/soc/qcom/ |
| D | qcom,smsm.txt | 1 Qualcomm Shared Memory State Machine
3 The Shared Memory State Machine facilitates broadcasting of single bit state
5 assigned 32 bits of state that can be modified. A processor can through a
43 Each processor's state bits are described by a subnode of the smsm device node.
45 processor's state bits or the local processors bits. The node names are not
54 - #qcom,smem-state-cells:
62 Definition: marks the entry as a interrupt-controller and the state bits
74 to signal changes of its state bits
94 #qcom,smem-state-cells = <1>;
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | pinctrl-bindings.txt | 4 such as pull-up/down, tri-state, drive-strength etc are designated as pin
15 need to reconfigure pins at run-time, for example to tri-state pins when the
21 for client device device tree nodes to map those state names to the pin
25 For example, a pin controller may set up its own "active" state when the
35 For each client device individually, every pin state is assigned an integer
36 ID. These numbers start at 0, and are contiguous. For each state ID, a unique
37 property exists to define the pin configuration. Each state may also be
42 defined in its device tree node, and whether to define the set of state
43 IDs that must be provided, or whether to define the set of state names that
51 controllers may be configured, or so that a state may be built
[all …]
|