Searched full:system (Results 1 – 25 of 1516) sorted by relevance
12345678910>>...61
| /Documentation/devicetree/bindings/arm/hisilicon/controller/ |
| D | sysctrl.yaml | 7 title: Hisilicon system controller
13 The Hisilicon system controller is used on many Hisilicon boards, it can be
14 used to assist the slave core startup, reboot the system, etc.
16 There are some variants of the Hisilicon system controller, such as HiP01,
17 Hi3519, Hi6220 system controller, each of them is mostly compatible with the
18 Hisilicon system controller, but some same registers located at different
19 offset. In addition, the HiP01 system controller has some specific control
22 The compatible names of each system controller are as follows:
23 Hisilicon system controller --> hisilicon,sysctrl
24 HiP01 system controller --> hisilicon,hip01-sysctrl
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices-memory | 1 What: /sys/devices/system/memory
5 The /sys/devices/system/memory contains a snapshot of the
12 What: /sys/devices/system/memory/memoryX/removable
16 The file /sys/devices/system/memory/memoryX/removable
24 What: /sys/devices/system/memory/memoryX/phys_device
28 The file /sys/devices/system/memory/memoryX/phys_device
33 What: /sys/devices/system/memory/memoryX/phys_index
37 The file /sys/devices/system/memory/memoryX/phys_index
42 What: /sys/devices/system/memory/memoryX/state
46 The file /sys/devices/system/memory/memoryX/state
[all …]
|
| D | sysfs-devices-system-cpu | 1 What: /sys/devices/system/cpu/
10 /sys/devices/system/cpu/cpu#/
12 What: /sys/devices/system/cpu/kernel_max
13 /sys/devices/system/cpu/offline
14 /sys/devices/system/cpu/online
15 /sys/devices/system/cpu/possible
16 /sys/devices/system/cpu/present
35 the system.
40 What: /sys/devices/system/cpu/probe
41 /sys/devices/system/cpu/release
[all …]
|
| D | sysfs-devices-edac | 1 What: /sys/devices/system/edac/mc/mc*/reset_counters
12 What: /sys/devices/system/edac/mc/mc*/seconds_since_reset
19 What: /sys/devices/system/edac/mc/mc*/mc_name
25 What: /sys/devices/system/edac/mc/mc*/size_mb
31 What: /sys/devices/system/edac/mc/mc*/ue_count
37 increment, since EDAC will panic the system
39 What: /sys/devices/system/edac/mc/mc*/ue_noinfo_count
46 What: /sys/devices/system/edac/mc/mc*/ce_count
54 such information to the system administrator.
56 What: /sys/devices/system/edac/mc/mc*/ce_noinfo_count
[all …]
|
| D | sysfs-firmware-opal-powercap | 9 What: /sys/firmware/opal/powercap/system-powercap
10 /sys/firmware/opal/powercap/system-powercap/powercap-min
11 /sys/firmware/opal/powercap/system-powercap/powercap-max
12 /sys/firmware/opal/powercap/system-powercap/powercap-current
15 Description: System powercap directory and attributes applicable for
28 powercap set on the system. Writing to this file
|
| /Documentation/admin-guide/pm/ |
| D | sleep-states.rst | 5 System Sleep States
13 Sleep states are global low-power states of the entire system in which user
14 space code cannot be executed and the overall system activity is significantly
22 the Linux kernel can support up to four system sleep states, including
23 hibernation and up to three variants of system suspend. The sleep states that
31 This is a generic, pure software, light-weight variant of system suspend (also
36 states while the system is suspended.
38 The system is woken up from this state by in-band interrupts, so theoretically
44 deeper system suspend variants to provide reduced resume latency. It is always
54 operating state is lost (the system core logic retains power), so the system can
[all …]
|
| D | strategies.rst | 15 One of them is based on using global low-power states of the whole system in
16 which user space code cannot be executed and the overall system activity is
18 kernel puts the system into one of these states when requested by user space
19 and the system stays in it until a special signal is received from one of
21 user space code can run. Because sleep states are global and the whole system
23 :doc:`system-wide power management <system-wide>`.
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
30 a metastate covering a range of different power states of the system in which
37 If all of the system components are active, the system as a whole is regarded as
[all …]
|
| D | suspend-flows.rst | 5 System Suspend Code Flows
12 At least one global system-wide transition needs to be carried out for the
13 system to get from the working state into one of the supported
16 referred to as *system-wide suspend* (or simply *system suspend*) states, need
19 For those sleep states, the transition from the working state of the system into
20 the target sleep state is referred to as *system suspend* too (in the majority
21 of cases, whether this means a transition or a sleep state of the system should
23 working state is referred to as *system resume*.
26 different sleep states of the system are quite similar, but there are some
45 The following steps are taken in order to transition the system from the working
[all …]
|
| /Documentation/livepatch/ |
| D | system-state.rst | 2 System State Changes
5 Some users are really reluctant to reboot a system. This brings the need
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
46 - Non-zero number used to identify the affected system state.
50 - Number describing the variant of the system state change that
68 The system state version is used to prevent loading incompatible livepatches.
[all …]
|
| /Documentation/devicetree/bindings/iommu/ |
| D | samsung,sysmmu.yaml | 7 title: Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit)
13 Samsung's Exynos architecture contains System MMUs that enables scattered
17 System MMU is an IOMMU and supports identical translation table format to
19 permissions, shareability and security protection. In addition, System MMU has
23 System MMUs are in many to one relation with peripheral devices, i.e. single
24 peripheral device might have multiple System MMUs (usually one for each bus
25 master), but one System MMU can handle transactions from only one peripheral
26 device. The relation between a System MMU and the peripheral device needs to be
29 MFC in all Exynos SoCs and FIMD, M2M Scalers and G2D in Exynos5420 has 2 System
31 * MFC has one System MMU on its left and right bus.
[all …]
|
| /Documentation/process/ |
| D | adding-syscalls.rst | 4 Adding a New System Call
7 This document describes what's involved in adding a new system call to the
12 System Call Alternatives
15 The first thing to consider when adding a new system call is whether one of
16 the alternatives might be suitable instead. Although system calls are the
35 - If you're just exposing runtime system information, a new node in sysfs
43 :manpage:`fcntl(2)` is a multiplexing system call that hides a lot of complexity, so
49 with :manpage:`fcntl(2)`, this system call is a complicated multiplexor so
57 A new system call forms part of the API of the kernel, and has to be supported
63 together with the corresponding follow-up system calls --
[all …]
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices-node | 1 What: /sys/devices/system/node/possible
7 What: /sys/devices/system/node/online
13 What: /sys/devices/system/node/has_normal_memory
19 What: /sys/devices/system/node/has_cpu
25 What: /sys/devices/system/node/has_high_memory
32 What: /sys/devices/system/node/nodeX
40 What: /sys/devices/system/node/nodeX/cpumap
46 What: /sys/devices/system/node/nodeX/cpulist
52 What: /sys/devices/system/node/nodeX/meminfo
59 What: /sys/devices/system/node/nodeX/numastat
[all …]
|
| D | sysfs-devices-system-xen_memory | 1 What: /sys/devices/system/xen_memory/xen_memory0/max_retry_count
11 What: /sys/devices/system/xen_memory/xen_memory0/max_schedule_delay
19 What: /sys/devices/system/xen_memory/xen_memory0/retry_count
30 What: /sys/devices/system/xen_memory/xen_memory0/schedule_delay
41 What: /sys/devices/system/xen_memory/xen_memory0/target
49 What: /sys/devices/system/xen_memory/xen_memory0/target_kb
56 What: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
64 What: /sys/devices/system/xen_memory/xen_memory0/info/high_kb
71 What: /sys/devices/system/xen_memory/xen_memory0/info/low_kb
79 What: /sys/devices/system/xen_memory/xen_memory0/scrub_pages
|
| /Documentation/devicetree/bindings/sram/ |
| D | allwinner,sun4i-a10-system-control.yaml | 4 $id: http://devicetree.org/schemas/sram/allwinner,sun4i-a10-system-control.yaml#
7 title: Allwinner A10 System Control Device Tree Bindings
29 - const: allwinner,sun4i-a10-system-control
30 - const: allwinner,sun5i-a13-system-control
32 - const: allwinner,sun7i-a20-system-control
33 - const: allwinner,sun4i-a10-system-control
34 - const: allwinner,sun8i-a23-system-control
35 - const: allwinner,sun8i-h3-system-control
37 - const: allwinner,sun8i-v3s-system-control
38 - const: allwinner,sun8i-h3-system-control
[all …]
|
| /Documentation/devicetree/bindings/arm/marvell/ |
| D | mvebu-system-controller.txt | 1 MVEBU System Controller
8 - "marvell,orion-system-controller"
9 - "marvell,armada-370-xp-system-controller"
10 - "marvell,armada-375-system-controller"
11 - reg: Should contain system controller registers location and length.
15 system-controller@d0018200 {
16 compatible = "marvell,armada-370-xp-system-controller";
|
| /Documentation/admin-guide/mm/ |
| D | numaperf.rst | 12 A system supports such heterogeneous memory by grouping each memory type
47 # symlinks -v /sys/devices/system/node/nodeX/access0/targets/
48 relative: /sys/devices/system/node/nodeX/access0/targets/nodeY -> ../../nodeY
50 # symlinks -v /sys/devices/system/node/nodeY/access0/initiators/
51 relative: /sys/devices/system/node/nodeY/access0/initiators/nodeX -> ../../nodeX
70 the system provides these attributes, the kernel exports them under the
74 /sys/devices/system/node/nodeY/access0/initiators/
82 # tree -P "read*|write*" /sys/devices/system/node/nodeY/access0/initiators/
83 /sys/devices/system/node/nodeY/access0/initiators/
103 System memory may be constructed in a hierarchy of elements with various
[all …]
|
| /Documentation/power/ |
| D | suspend-and-interrupts.rst | 2 System Suspend and Device Interrupts
12 Device interrupt request lines (IRQs) are generally disabled during system
29 Device IRQs are re-enabled during system resume, right before the "early" phase
37 There are interrupts that can legitimately trigger during the entire system
47 interrupt will wake the system from a suspended state -- for such cases it is
58 System Wakeup Interrupts, enable_irq_wake() and disable_irq_wake()
61 System wakeup interrupts generally need to be configured to wake up the system
67 during system sleep so as to trigger a system wakeup when needed. For example,
69 handling system wakeup events. Then, if a given interrupt line is supposed to
70 wake up the system from sleep sates, the corresponding input of that interrupt
[all …]
|
| /Documentation/userspace-api/ |
| D | seccomp_filter.rst | 8 A large number of system calls are exposed to every userland process
10 As system calls change and mature, bugs are found and eradicated. A
12 of available system calls. The resulting set reduces the total kernel
13 surface exposed to the application. System call filtering is meant for
17 incoming system calls. The filter is expressed as a Berkeley Packet
19 operated on is related to the system call being made: system call
20 number and the system call arguments. This allows for expressive
21 filtering of system calls using a filter program language with a long
25 to time-of-check-time-of-use (TOCTOU) attacks that are common in system
27 pointers which constrains all filters to solely evaluating the system
[all …]
|
| /Documentation/admin-guide/ |
| D | initrd.rst | 9 This RAM disk can then be mounted as the root file system and programs
10 can be run from it. Afterwards, a new root file system can be mounted
14 initrd is mainly designed to allow system startup to occur in two phases,
25 When using initrd, the system typically boots as follows:
38 6) init mounts the "real" root file system
39 7) init places the root file system at the root directory using the
40 pivot_root system call
43 9) the initrd file system is removed
65 the "normal" root file system is mounted. initrd data can be read
67 in this case and doesn't necessarily have to be a file system image.
[all …]
|
| /Documentation/devicetree/bindings/power/ |
| D | power-controller.txt | 1 * Generic system power control capability
4 sometimes able to control the system power. The device driver associated with these
6 it can be used to switch off the system. The corresponding device must have the
7 standard property "system-power-controller" in its device node. This property
8 marks the device as able to control the system power. In order to test if this
16 system-power-controller;
|
| /Documentation/crypto/ |
| D | userspace-if.rst | 62 send()/write() system call family. The result of the cipher operation is
63 obtained with the read()/recv() system call family.
77 3. Invoke accept with the socket descriptor. The accept system call
80 system calls to send data to the kernel or obtain data from the
88 the input buffer used for the send/write system call and the output
89 buffer used by the read/recv system call may be one and the same. This
120 Using the send() system call, the application provides the data that
121 should be processed with the message digest. The send system call allows
124 - MSG_MORE: If this flag is set, the send system call acts like a
126 calculated. If the flag is not set, the send system call calculates
[all …]
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | berlin,pinctrl.txt | 3 Pin control registers are part of both chip controller and system
5 either the chip controller or system controller node. The pins
19 "marvell,berlin2-system-pinctrl",
21 "marvell,berlin2cd-system-pinctrl",
23 "marvell,berlin2q-system-pinctrl",
26 "marvell,berlin4ct-system-pinctrl",
36 compatible = "marvell,berlin2q-system-pinctrl";
|
| D | sprd,pinctrl.txt | 8 pad driving level, system control select and so on ("domain pad
11 slect 3.0v, then the pin can output 3.0v. "system control" is used
12 to choose one function (like: UART0) for which system, since we
32 Now we have 4 systems for sleep mode on SC9860 SoC: AP system,
33 PUBCP system, TGLDSP system and AGDSP system. And the pin sleep
44 by hardware when the system specified by sleep mode goes into deep
47 means when PUBCP system goes into deep sleep mode, this pin will be set
51 PUBCP system) do not run linux kernel OS (only AP system run linux
53 when the PUBCP system goes into deep sleep mode. Thus we introduce
|
| /Documentation/driver-api/pm/ |
| D | devices.rst | 22 This writeup gives an overview of how drivers interact with system-wide
34 System Sleep model:
36 Drivers can enter low-power states as part of entering system-wide
46 Some drivers can manage hardware wakeup events, which make the system
51 whole system enter low-power states more often.
55 Devices may also be put into low-power states while the system is
62 states at run time may require special handling during system-wide power
67 the PM core are involved in runtime power management. As in the system
73 very system-specific, and often device-specific. Also, that if enough devices
75 to entering some system-wide low-power state (system sleep) ... and that
[all …]
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | cpuacct.rst | 18 the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup.
21 in the system.
35 CPU time obtained by the cgroup into user and system times. Currently
39 system: Time spent by tasks of the cgroup in kernel mode.
41 user and system are in USER_HZ unit.
44 system times. This has two side effects:
46 - It is theoretically possible to see wrong values for user and system times.
49 - It is possible to see slightly outdated values for user and system times
|
12345678910>>...61