| /Documentation/scheduler/ |
| D | sched-stats.rst | 10 mainline kernel in 2.6.20 although it is identical to the stats from version
11 12 which was in the kernel from 2.6.13-2.6.19 (version 13 never saw a kernel
16 In version 14 of schedstat, there is at least one level of domain
18 domain. Domains have no particular names in this implementation, but
23 field in the domain stats is a bit map indicating which cpus are affected
28 the change in the counters at each subsequent observation. A perl script
34 reason to change versions is changes in the output format. For those wishing
47 2) This field is a legacy array expiration count field used in the O(1)
59 7) sum of all time spent running by tasks on this processor (in nanoseconds)
60 8) sum of all time spent waiting to run by tasks on this processor (in
[all …]
|
| /Documentation/hwmon/ |
| D | lt7182s.rst | 38 It can also be instantiated by declaring an entry in device tree.
56 in[1-2]_label "vin[12]"
57 in[1-2]_input Measured input voltage
58 in[1-2]_highest Highest measured input voltage
59 in[1-2]_crit Critical maximum input voltage
60 in[1-2]_crit_alarm Input voltage critical high alarm
61 in[1-2]_min Minimum input voltage
62 in[1-2]_min_alarm Input voltage low alarm
63 in[1-2]_rated_min Rated minimum input voltage
64 in[1-2]_rated_max Rated maximum input voltage
[all …]
|
| /Documentation/filesystems/ |
| D | idmappings.rst | 16 in userspace is::
20 ``u`` indicates the first element in the upper idmapset ``U`` and ``k``
21 indicates the first element in the lower idmapset ``K``. The ``r`` parameter
24 we're talking about an id in the upper or lower idmapset.
26 To see what this looks like in practice, let's take the following idmapping::
38 order isomorphic. In fact, ``U`` and ``K`` are always well-ordered subsets of
59 ``u1000`` from the upper idmapset down to ``k11000`` in the lower idmapset.
62 what id ``k11000`` corresponds to in the second or third idmapping. The
78 contain ``u1000`` in the upper idmapset ``U``. This is equivalent to not having
79 an id mapped. We can simply say that ``u1000`` is unmapped in the second and
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | pixfmt-intro.rst | 7 In order to exchange images between drivers and applications, it is
11 image data formats in V4L2.
14 formats are possible. In that case the application may depend on a codec
16 data can still be stored and retrieved in the proprietary format. For
18 Applications can still capture and save the data in the compressed
27 are always arranged in memory from left to right, and from top to
28 bottom. The first byte of data in the image buffer is always for the
37 In V4L2 each format has an identifier which looks like ``PIX_FMT_XXX``,
38 defined in the :ref:`videodev2.h <videodev>` header file. These
41 listed below, however they are not the same as those used in the Windows
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | DSD-properties-rules.rst | 10 The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1,
12 namespace. In principle, the format of the data may be arbitrary, but it has to
15 the ACPI subsystem in the Linux kernel which automatically processes the data
22 In the ACPI _DSD context it is an element of the sub-package following the
23 generic Device Properties UUID in the _DSD return package as specified in the
25 "Device Properties UUID" in _DSD (Device Specific Data) Implementation Guide
29 that can be returned by _DSD in the Device Properties UUID sub-package for a
33 like a device. In the ACPI _DSD context it is the set of all properties that
34 can be returned in the Device Properties UUID sub-package for the device in
40 representation of property subsets is via the mechanism specified in the
[all …]
|
| /Documentation/admin-guide/ |
| D | sysfs-rules.rst | 1 Rules on how to access information in sysfs
10 To minimize the risk of breaking users of sysfs, which are in most cases
24 implementation details in its own API. Therefore it is not better than
26 Also, it is not actively maintained, in the sense of reflecting the
29 violates many of the rules in this document.
40 interfaces, and such that you can rely on in userspace. Everything is
43 applications that look for devices in sysfs.
49 - identical to the DEVPATH value in the event sent from the kernel
51 - the unique key to the device at that point in time
59 - using or exposing symlink values as elements in a devpath string
[all …]
|
| /Documentation/networking/ |
| D | checksum-offloads.rst | 11 This document describes a set of techniques in the Linux networking stack to
29 The interface for offloading a transmit checksum to a device is explained in
30 detail in comments near the top of include/linux/skbuff.h.
32 In brief, it allows to request the device fill in a single ones-complement
35 'IP-style' checksum) from csum_start to the end of the packet, and fill in the
39 the checksum field is included in the checksum computation, thus it can be used
44 encapsulation is used, the packet may have multiple checksum fields in
52 No offloading of the IP header checksum is performed; it is always done in
54 in cache, so summing it isn't expensive. It's also rather short.
61 A driver declares its offload capabilities in netdev->hw_features; see
[all …]
|
| D | strparser.rst | 12 parser works in conjunction with an upper layer in the kernel to provide
17 The strparser works in one of two modes: receive callback or general
20 In receive callback mode, the strparser is called from the data_ready
24 In general mode, a sequence of skbs are fed to strparser from an
35 parsing (e.g. BPF parsing in case of KCM), and a rcv_msg function
49 callback mode; in general mode this is set to NULL. Callbacks
88 strp_process is called in general mode for a stream parser to
122 in the stream. The upper layer must implement this function. It
124 next application layer message in the stream.
126 The skb->cb in the input skb is a struct strp_msg. Only
[all …]
|
| /Documentation/kbuild/ |
| D | kconfig-macro-language.rst | 9 two languages in one. One language describes dependency graphs consisting of
32 The idea is quite similar in Kconfig - it is possible to describe a Kconfig
40 The macro language in Kconfig processes the source file into the following
47 dependency as explained in kconfig-language.rst.
53 Like in Make, a variable in Kconfig works as a macro variable. A macro
54 variable is expanded "in place" to yield a text string that may then be
55 expanded further. To get the value of a variable, enclose the variable name in
57 a syntax error. The curly brace form as in ${CC} is not supported either.
68 expanding it in any way. Instead, the expansion is performed when the variable
76 The variable reference can take parameters, in the following form::
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | strategies.rst | 15 One of them is based on using global low-power states of the whole system in
19 and the system stays in it until a special signal is received from one of
20 designated devices, triggering a transition to the ``working state`` in which
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
31 the individual components of it can be either ``active`` (in use) or
32 ``inactive`` (idle). If they are active, they have to be in power states
33 allowing them to process data and to be accessed by software. In turn, if they
34 are inactive, ideally, they should be in low-power states in which they may not
[all …]
|
| D | cpuidle.rst | 19 Modern processors are generally able to enter states in which the execution of
23 Since part of the processor hardware is not used in idle states, entering them
24 generally allows power drawn by the processor to be reduced and, in consequence,
35 work in the system). In its view, CPUs are *logical* units. That is, they need
37 software as individual single-core processors. In other words, a CPU is an
43 program) at a time, it is a CPU. In that case, if the hardware is asked to
46 Second, if the processor is multi-core, each core in it is able to follow at
49 work physically in parallel with each other, so if each of them executes only
51 time. The entire cores are CPUs in that case and if the hardware is asked to
52 enter an idle state, that applies to the core that asked for it in the first
[all …]
|
| /Documentation/devicetree/bindings/memory-controllers/ddr/ |
| D | jedec,lpddr3-timings.yaml | 19 Maximum DDR clock frequency for the speed-bin, in Hz.
26 Maximum DDR clock frequency for the speed-bin, in Hz.
31 Minimum DDR clock frequency for the speed-bin, in Hz.
36 CKE minimum pulse width (HIGH and LOW pulse width) in pico seconds.
42 SELF REFRESH) in pico seconds.
47 Four-bank activate window in pico seconds.
52 Mode register set command delay in pico seconds.
57 Additional READ-to-READ delay in chip-to-chip cases in pico seconds.
62 Row active time in pico seconds.
67 ACTIVATE-to-ACTIVATE command period in pico seconds.
[all …]
|
| /Documentation/security/keys/ |
| D | ecryptfs.rst | 8 Each FEK is in turn encrypted with a File Encryption Key Encryption Key (FEKEK)
9 either in kernel space or in user space with a daemon called 'ecryptfsd'. In
11 using a key, the FEKEK, derived from a user prompted passphrase; in the latter
12 the FEK is encrypted by 'ecryptfsd' with the help of external libraries in order
17 FEK decryption is called authentication token and, currently, can be stored in a
18 kernel key of the 'user' type, inserted in the user's session specific keyring
23 format 'ecryptfs' in order to be used in conjunction with the eCryptfs
25 authentication token in its payload with a FEKEK randomly generated by the
28 In order to avoid known-plaintext attacks, the datablob obtained through
30 authentication token, which content is well known, but only the FEKEK in
[all …]
|
| /Documentation/admin-guide/mm/ |
| D | userfaultfd.rst | 20 region(s) result in a message being delivered to the userfaultfd, notifying
30 registered in the ``userfaultfd`` that allows userland to efficiently
32 memory in the background
35 management of mremap/mprotect is that the userfaults in all their
36 operations never involve heavyweight structures like vmas (in fact the
61 userfaultfd(2) syscall. Access to this is controlled in several ways:
67 - In order to also trap kernel page faults for the address space, either the
102 other than page faults are supported. These events are described in more
103 detail below in the `Non-cooperative userfaultfd`_ section.
124 ioctl should be invoked (if present in the returned ``uffdio_api.ioctls``
[all …]
|
| /Documentation/networking/device_drivers/ethernet/altera/ |
| D | altera_tse.rst | 22 the maintainer of this driver, found in MAINTAINERS.
36 The SGDMA component is to be deprecated in the near future (over the next 1-2
37 years as of this writing in early 2014) in favor of the MSGDMA component.
38 SGDMA support is included for existing designs and reference in case a
53 tested for 1Gbps. This support will be added in a future maintenance update.
67 - dma_rx_num: Number of descriptors in the RX list (default is 64);
68 - dma_tx_num: Number of descriptors in the TX list (default is 64).
73 Driver parameters can be also passed in command line by using::
86 completion in the context of the interrupt handling chain by recycling
103 for transmit operations, but will be added in a future maintenance release.
[all …]
|
| /Documentation/powerpc/ |
| D | booting.rst | 9 bootloader <-> kernel interfaces, in order to avoid the degeneration that had
12 this scheme, but no new board support will be accepted in the main tree that
13 doesn't follow them properly. In addition, since the advent of the arch/powerpc
18 The main requirement that will be defined in more detail below is the presence
20 However, in order to make life easier to embedded board vendors, the kernel
21 doesn't require the device-tree to represent every device in the system and only
23 not require you to create a node for every PCI device in the system. It is a
24 requirement to have a node for PCI host bridges in order to provide interrupt
27 in an existing OF specification. This creates a great flexibility in the way the
53 trampoline located in arch/powerpc/kernel/prom_init.c to
[all …]
|
| /Documentation/arch/arm/ |
| D | booting.rst | 11 In order to boot ARM Linux, you require a boot loader, which is a small
36 kernel will use for volatile data storage in the system. It performs
37 this in a machine dependent manner. (It may use internal algorithms
39 the RAM in the machine, or any other method the boot loader designer
58 serial format options as described in
76 should be passed to the kernel in register r1.
92 boot data is passed to the kernel in register r2.
103 Any number of tags can be placed in the list. It is undefined
105 previous tag, or whether it replaces the information in its
120 The tagged list should be stored in system RAM.
[all …]
|
| D | cluster-pm-race-avoidance.rst | 12 algorithm in use.
18 In a system containing multiple CPUs, it is desirable to have the
22 In a system containing multiple clusters of CPUs, it is also desirable
28 means that we need some coordination in order to ensure that critical
37 methods of coordination are required in order to guarantee safe
40 The mechanism presented in this document describes a coherent memory
77 level. A CPU in this state is not necessarily being used
86 Each CPU has one of these states assigned to it at any point in time.
87 The CPU states are described in the "CPU state" section, below.
91 to introduce additional states in order to avoid races between different
[all …]
|
| /Documentation/netlink/specs/ |
| D | devlink.yaml | 35 # TODO: fill in the attributes in between
42 # TODO: fill in the attributes in between
54 # TODO: fill in the attributes in between
61 # TODO: fill in the attributes in between
68 # TODO: fill in the attributes in between
75 # TODO: fill in the attributes in between
106 # TODO: fill in the attributes in between
113 # TODO: fill in the attributes in between
120 # TODO: fill in the attributes in between
131 # TODO: fill in the attributes in between
[all …]
|
| /Documentation/sound/designs/ |
| D | tracepoints.rst | 2 Tracepoints in ALSA
8 Tracepoints in ALSA PCM core
30 In a design of ALSA PCM core, data transmission is abstracted as PCM substream.
33 substream. In this procedure, PCM hardware parameters are decided by
37 The parameters are described in struct snd_pcm_hw_params. This
49 Configurable. This type of parameter is described in
57 Configurable. This type of parameter is described in
80 Read-only. After returning from ioctl(2), buffer in user space for
90 Read-only. This value represents available bit width in MSB side of
93 it. Else, zero. But this behaviour depends on implementations in driver
[all …]
|
| /Documentation/ABI/ |
| D | README | 4 interfaces should be used by userspace programs in different ways.
7 different subdirectories in this location. Interfaces may change levels
25 errors or security problems are found in them. Userspace
35 This directory documents interfaces that are still remaining in
36 the kernel, but are marked to be removed at some later point in
44 Every file in these directories will contain the following information:
48 KernelVersion: Kernel version this feature first showed up in.
52 it changes. This is very important for interfaces in
55 break in ways that are unacceptable. It is also
57 sure they are working in a proper way and do not need to
[all …]
|
| /Documentation/devicetree/bindings/sound/ |
| D | mt2701-cs42448.txt | 11 - i2s1-in-sel-gpio1, i2s1-in-sel-gpio2: Should specify two gpio pins to
12 control I2S1-in mux.
31 "AIN2L", "Tuner In",
32 "AIN2R", "Tuner In",
33 "AIN3L", "Satellite Tuner In",
34 "AIN3R", "Satellite Tuner In",
35 "AIN3L", "AUX In",
36 "AIN3R", "AUX In";
41 i2s1-in-sel-gpio1 = <&pio 53 0>;
42 i2s1-in-sel-gpio2 = <&pio 54 0>;
|
| /Documentation/virt/hyperv/ |
| D | overview.rst | 8 management service running in the parent partition (roughly
9 equivalent to KVM and QEMU, for example). Guest VMs run in child
10 partitions. In this documentation, references to Hyper-V usually
21 Linux guests communicate with Hyper-V in four different ways:
30 and returns control to the caller. Parameters are passed in
31 processor registers or in memory shared between the Linux guest and
37 synthetic registers. On x86/x64 these registers appear as MSRs in
49 The first three communication mechanisms are documented in the
73 GPAs, which usually do not need to be contiguous in the guest
75 of GPAs varies. In some cases, a single GPA is written to a
[all …]
|
| /Documentation/input/devices/ |
| D | edt-ft5x06.rst | 6 focaltec ft5x06 devices, since they contain vendor-specific firmware. In
18 allows setting the "click"-threshold in the range from 0 to 80.
21 allows setting the sensitivity in the range from 0 to 31. Note that
25 allows setting the edge compensation in the range from 0 to 31.
28 allows setting the report rate in the range from 3 to 14.
31 For debugging purposes the driver provides a few files in the debug
32 filesystem (if available in the kernel). In /sys/kernel/debug/edt_ft5x06
36 (readonly) contains the number of sensor fields in X- and
41 mode" by writing "1" or "0" to it. In factory mode (1) it is
42 possible to get the raw data from the sensor. Note that in factory
[all …]
|
| /Documentation/hid/ |
| D | hiddev.rst | 8 In addition to the normal input type HID devices, USB also uses the
29 In addition, other subsystems (apart from USB) can potentially feed
67 This description should be read in conjunction with the HID
75 each of which can have one or more "usages". In the hid-core,
85 the report. In its basic mode, the hiddev will make these individual
129 also returns the level the collection lives in the hierarchy.
130 The user passes in a hiddev_collection_info struct with the index
131 field set to the index that should be returned. The ioctl fills in
143 Gets a string descriptor from the device. The caller must fill in the
152 changes. Note that the use of this ioctl is unnecessary in general,
[all …]
|