| /linux-4.4.14/fs/kernfs/ |
| D | file.c | 95 struct kernfs_open_file *of = sf->private; in kernfs_seq_stop_active() local
96 const struct kernfs_ops *ops = kernfs_ops(of->kn); in kernfs_seq_stop_active()
100 kernfs_put_active(of->kn); in kernfs_seq_stop_active()
105 struct kernfs_open_file *of = sf->private; in kernfs_seq_start() local
112 mutex_lock(&of->mutex); in kernfs_seq_start()
113 if (!kernfs_get_active(of->kn)) in kernfs_seq_start()
116 ops = kernfs_ops(of->kn); in kernfs_seq_start()
134 struct kernfs_open_file *of = sf->private; in kernfs_seq_next() local
135 const struct kernfs_ops *ops = kernfs_ops(of->kn); in kernfs_seq_next()
155 struct kernfs_open_file *of = sf->private; in kernfs_seq_stop() local
[all …]
|
| /linux-4.4.14/Documentation/filesystems/caching/ |
| D | fscache.txt | 70 FS-Cache does not follow the idea of completely loading every netfs file
72 then serving the pages out of that cache rather than the netfs inode because:
76 (2) The size of any accessible file must not be limited to the size of the
79 (3) The combined size of all opened files (this includes mapped libraries)
80 must not be limited to the size of the cache.
83 one-off access of a small portion of it (such as might be done with the
93 explicitly by use of tags.
109 recursive, stack space is limited, and indices can only be children of
113 indicates that page A is at index B of the data-file represented by cookie
131 and pages are kept. Bits of this tree may actually reside in one or more
[all …]
|
| D | cachefiles.txt | 35 an already mounted filesystem of a local type (such as Ext3).
37 CacheFiles uses a userspace daemon to do some of the cache management - such as
41 The filesystem and data integrity of the cache are only as good as those of the
43 attempt to journal anything since the journalling interfaces of the various
53 CacheFiles attempts to maintain at least a certain percentage of free space on
56 placed on the same medium as a live set of data, and will expand to make use of
57 spare space and automatically contract when the set of data requires more
65 The use of CacheFiles and its daemon requires the following features to be
76 - The use of bmap() to detect a partial page at the end of the file.
104 Specify the directory containing the root of the cache. Mandatory.
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/net/ |
| D | micrel-ksz90x1.txt | 19 - rxc-skew-ps : Skew control of RXC pad
20 - rxdv-skew-ps : Skew control of RX CTL pad
21 - txc-skew-ps : Skew control of TXC pad
22 - txen-skew-ps : Skew control of TX CTL pad
23 - rxd0-skew-ps : Skew control of RX data 0 pad
24 - rxd1-skew-ps : Skew control of RX data 1 pad
25 - rxd2-skew-ps : Skew control of RX data 2 pad
26 - rxd3-skew-ps : Skew control of RX data 3 pad
27 - txd0-skew-ps : Skew control of TX data 0 pad
28 - txd1-skew-ps : Skew control of TX data 1 pad
[all …]
|
| D | sh_eth.txt | 7 - compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
8 "renesas,ether-r8a7778" if the device is a part of R8A7778 SoC.
9 "renesas,ether-r8a7779" if the device is a part of R8A7779 SoC.
10 "renesas,ether-r8a7790" if the device is a part of R8A7790 SoC.
11 "renesas,ether-r8a7791" if the device is a part of R8A7791 SoC.
12 "renesas,ether-r8a7793" if the device is a part of R8A7793 SoC.
13 "renesas,ether-r8a7794" if the device is a part of R8A7794 SoC.
14 "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
15 - reg: offset and length of (1) the E-DMAC/feLic register block (required),
20 - #address-cells: number of address cells for the MDIO bus, must be equal to 1.
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/display/ |
| D | st,stih4xx.txt | 6 - reg: Physical base address of the IP registers and length of memory mapped region.
14 - reg: Physical base address of the IP registers and length of memory mapped region.
16 number of clocks may depend of the SoC type.
18 - clock-names: names of the clocks listed in clocks property in the same
22 This device must be the parent of all the sub-components and is responsible
23 of bind them.
26 - ranges: to allow probing of subdevices
29 must be a child of sti-display-subsystem
32 - reg: Physical base address of the IP registers and length of memory mapped region.
34 number of clocks may depend of the SoC type.
[all …]
|
| /linux-4.4.14/Documentation/scheduler/ |
| D | sched-stats.txt | 1 Version 15 of schedstats dropped counters for some sched_yield:
5 Version 14 of schedstats includes support for sched_domains, which hit the
12 In version 14 of schedstat, there is at least one level of domain
17 sometimes balancing only between pairs of cpus. At this time, there
23 of these will need to start with a baseline observation and then calculate
25 which does this for many of the fields is available at
38 1) # of times sched_yield() was called
43 3) # of times schedule() was called
44 4) # of times schedule() left the processor idle
47 5) # of times try_to_wake_up() was called
[all …]
|
| D | sched-domains.txt | 6 Each scheduling domain spans a number of CPUs (stored in the ->span field).
7 A domain's span MUST be a superset of it child's span (this restriction could
17 pointer. The union of cpumasks of these groups MUST be the same as the
18 domain's span. The intersection of cpumasks from any two of these groups
24 is treated as one entity. The load of a group is defined as the sum of the
25 load of each of its member CPUs, and only when the load of a group becomes
26 out of balance are tasks moved between groups.
39 the parent sched_domain (if it exists), and the parent of the parent and so
43 If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in
46 to our runqueue. The exact number of tasks amounts to an imbalance previously
[all …]
|
| D | sched-deadline.txt | 38 basically an implementation of the Earliest Deadline First (EDF) scheduling
40 that makes it possible to isolate the behavior of tasks between each other.
48 "runtime" microseconds of execution time every "period" microseconds, and
50 from the beginning of the period. In order to implement this behavior,
73 - The state of the task is described by a "scheduling deadline", and
93 - When a SCHED_DEADLINE task executes for an amount of time t, its
105 value of the scheduling deadline;
107 - When the current time is equal to the replenishment time of a
125 * satisfied :P) to be sure of fully understanding all technical details.
128 There are no limitations on what kind of task can exploit this new
[all …]
|
| D | sched-design-CFS.txt | 13 80% of CFS's design can be summed up in a single sentence: CFS basically models
22 introduce the concept of "virtual runtime." The virtual runtime of a task
24 multi-tasking CPU described above. In practice, the virtual runtime of a task
25 is its actual runtime normalized to the total number of running tasks.
37 would ever get "out of balance" from the "ideal" share of CPU time. ]
45 Most of the rest of CFS's design just falls out of this really simple concept,
54 runqueues, but it uses a time-ordered rbtree to build a "timeline" of future
60 runqueue. The total amount of work done by the system is tracked using
62 side of the tree as much as possible.
64 The total number of running tasks in the runqueue is accounted through the
[all …]
|
| /linux-4.4.14/Documentation/ |
| D | iostats.txt | 15 is mounted on /sys, although of course it may be mounted anywhere.
19 Here are examples of these different formats:
35 a choice of "cat /sys/block/hda/stat" or "grep 'hda ' /proc/diskstats".
36 The advantage of one over the other is that the sysfs choice works well
37 if you are watching a known, small set of disks. /proc/diskstats may
38 be a better choice if you are watching a large number of disks because
39 you'll avoid the overhead of 50, 100, or 500 or more opens/closes with
40 each snapshot of your disk statistics.
43 the above example, the first field of statistics would be 446216.
47 minor device numbers, and device name. Each of these formats provides
[all …]
|
| D | unshare.txt | 5 provides an overview of the feature, why it is needed, how it can
27 Most legacy operating system kernels support an abstraction of threads
34 power of implementing threads in this manner comes not only from
36 outside the confinement of all-or-nothing shared resources of legacy
37 threads. On Linux, at the time of thread creation using the clone system
43 shared at the time of their creation. unshare was conceptualized by
44 Al Viro in the August of 2000, on the Linux-Kernel mailing list, as part
45 of the discussion on POSIX threads on Linux. unshare augments the
46 usefulness of Linux threads for applications that would like to control
48 addition to the set of available primitives on Linux that implement
[all …]
|
| D | crc32.txt | 4 and the whole thing (message+CRC) is a multiple of the given
8 is used by a lot of hardware implementations, and is why so many
9 protocols put the end-of-frame flag after the CRC.
23 Note that a CRC is computed over a string of *bits*, so you have
24 to decide on the endianness of the bits within each byte. To get
32 Each step of the division you take one more digit (bit) of the dividend
34 appropriate multiple of the divisor to subtract to being the remainder
36 and to make the XOR cancel, it's just a copy of bit 32 of the remainder.
39 throw the quotient bit away, but subtract the appropriate multiple of
49 Notice how, to get at bit 32 of the shifted remainder, we look
[all …]
|
| D | circular-buffers.txt | 9 Linux provides a number of features that can be used to implement circular
10 buffering. There are two sets of such features:
12 (1) Convenience functions for determining information about power-of-2 sized
15 (2) Memory barriers for when the producer and the consumer of objects in the
27 (*) Measuring power-of-2 buffers.
38 First of all, what is a circular buffer? A circular buffer is a buffer of
53 indices should be wrapped to 0 when they reach the end of the buffer, thus
54 allowing an infinite amount of data to flow through the buffer.
56 Typically, items will all be of the same unit size, but this isn't strictly
60 be careful, however, as a region more than one unit in size may wrap the end of
[all …]
|
| D | memory-hotplug.txt | 6 Add description of notifier of memory hotplug Oct 11 2007
9 Because Memory Hotplug is still under development, contents of this text will
13 1.1 purpose of memory hotplug
14 1.2. Phases of memory hotplug
15 1.3. Unit of Memory online/offline operation
22 5.1. State of memory
40 1.1 purpose of memory hotplug
42 Memory Hotplug allows users to increase/decrease the amount of memory.
45 (A) For changing the amount of memory.
56 1.2. Phases of memory hotplug
[all …]
|
| D | lzo.txt | 10 of this analysis is lib/lzo/lzo1x_decompress_safe.c. No analysis was made on
12 the format matches the standard one. The purpose of this document is to
18 The stream is composed of a series of instructions, operands, and data. The
21 opcode and on the number of literals copied by previous instruction. The
25 - a length (number of bytes to copy from dictionary)
26 - the number of literals to copy, which is retained in variable "state"
27 as a piece of information for next instructions.
33 The first byte of the block follows a different encoding from other bytes, it
38 of bits in the operand. If the number of bits isn't enough to represent the
40 rate of at most 255 per extra byte (thus the compression ratio cannot exceed
[all …]
|
| D | workqueue.txt | 40 number of workers as the number of CPUs. The kernel grew a lot of MT
41 wq users over the years and with the number of CPU cores continuously
45 Although MT wq wasted a lot of resource, the level of concurrency
53 The tension between the provided level of concurrency and resource
58 higher level of concurrency, like async or fscache, had to implement
61 Concurrency Managed Workqueue (cmwq) is a reimplementation of wq with
67 flexible level of concurrency on demand without wasting a lot of
70 * Automatically regulate worker pool and level of concurrency so that
76 In order to ease the asynchronous execution of functions a new
86 off of the queue, one after the other. If no work is queued, the
[all …]
|
| D | stable_api_nonsense.txt | 2 (all of your questions answered and then some)
22 get lots of other good benefits if your driver is in the main kernel
23 tree, all of which has made Linux into such a strong, stable, and mature
32 to worry about the in-kernel interfaces changing. For the majority of
41 the technical issues here (not to make light of the legal issues, they
42 are real, and you do need to be aware of them at all times.)
46 discuss the binary stuff first to get it out of the way.
54 - Depending on the version of the C compiler you use, different kernel
55 data structures will contain different alignment of structures, and
60 - Depending on what kernel build options you select, a wide range of
[all …]
|
| D | this_cpu_ops.txt | 4 this_cpu operations are a way of optimizing access to per cpu
6 done through the use of segment registers (or a dedicated register where
7 the cpu permanently stored the beginning of the per cpu area for a
14 This means that there are no atomicity issues between the calculation of
17 processor is not changed between the calculation of the address and
20 Read-modify-write operations are of particular interest. Frequently
23 sort of relaxed atomicity guarantees. The x86, for example, can execute
35 (remote write operations) of local RMW operations via this_cpu_*.
37 The main use of the this_cpu operations has been to optimize counter
61 Inner working of this_cpu operations
[all …]
|
| D | unaligned-memory-access.txt | 4 Linux runs on a wide variety of architectures which have varying behaviour
10 The definition of an unaligned access
13 Unaligned memory accesses occur when you try to read N bytes of data starting
15 For example, reading 4 bytes of data from address 0x10004 is fine, but
16 reading 4 bytes of data from address 0x10005 would be an unaligned memory
21 or write a number of bytes to or from memory (e.g. movb, movw, movl in x86
31 When accessing N bytes of memory, the base memory address must be evenly
38 of memory access. However, we must consider ALL supported architectures;
46 The effects of performing an unaligned memory access vary from architecture
48 here; a summary of the common scenarios is presented below:
[all …]
|
| D | intel_txt.txt | 11 o Provides dynamic root of trust for measurement (DRTM)
12 o Data protection in case of improper shutdown
13 o Measurement and verification of launched environment
15 Intel TXT is part of the vPro(TM) brand and is also available some
26 years, some of which are:
31 3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
40 uses Intel TXT to perform a measured and verified launch of an OS
55 measure or protect the integrity of a running kernel, they all
58 are examples of such solutions.
61 static root of trust must be used. This bases trust in BIOS
[all …]
|
| D | clk.txt | 6 detailed explanation of the clock api in include/linux/clk.h, but
12 available on various devices today. This may come in the form of clock
17 details of its counterpart. First is the common definition of struct
19 has traditionally been duplicated across a variety of platforms. Second
20 is a common implementation of the clk.h api, defined in
24 The second half of the interface is comprised of the hardware-specific
27 the remainder of this document any reference to a callback in struct
29 implementation of that code. Likewise, references to struct clk_foo
30 serve as a convenient shorthand for the implementation of the
33 Tying the two halves of this interface together is struct clk_hw, which
[all …]
|
| D | vgaarbiter.txt | 6 modern devices allow relocation of such ranges, some "Legacy" VGA devices
17 ideally, being a userspace application, it is not the role of the X server to
18 control bus resources. Therefore an arbitration scheme outside of the X server
19 is needed to control the sharing of these resources. This document introduces
20 the operation of the VGA arbiter implemented for the Linux kernel.
24 I. Details and Theory of Operation
32 I. Details and Theory of Operation
38 The vgaarb is a module of the Linux Kernel. When it is initially loaded, it
40 arbiter then enables/disables the decoding on different devices of the VGA
47 open : open user instance of the arbiter. By default, it's attached to
[all …]
|
| D | HOWTO | 7 contain anything related to the technical aspects of kernel programming,
10 If anything in this document becomes out of date, please send in patches
11 to the maintainer of this file, who is listed at the bottom of the
23 explain some of the reasons why the community works like it does.
26 parts written in assembly. A good understanding of C is required for
29 are not a good substitute for a solid C education and/or years of
36 adheres to the ISO C89 standard, it uses a number of extensions that are
39 portions of the C standard are not supported. Arbitrary long long
47 existing development community. It is a diverse group of people, with
51 possible about these standards ahead of time, as they are well
[all …]
|
| D | assoc_array.txt | 38 Rather, the array is made up of metadata blocks that point to objects.
45 (5) Index keys can be of any length and can be of different lengths.
61 (10) Objects in the array can be looked up by means of their index key.
66 The implementation uses a tree of 16-pointer nodes internally that are indexed
69 what would otherwise be a series of single-occupancy nodes. Further, nodes
94 keeps track of the metadata blocks that will be removed from the tree when the
97 This is also used to keep track of dead blocks and dead objects after the
102 The script appears as outside of the API as a pointer of the type:
131 Various functions take a table of operations:
137 This points to a number of methods, all of which need to be provided:
[all …]
|
| /linux-4.4.14/arch/mips/include/asm/ |
| D | war.h | 82 #error Check setting of R4600_V1_INDEX_ICACHEOP_WAR for your platform
112 #error Check setting of R4600_V1_HIT_CACHEOP_WAR for your platform
128 #error Check setting of R4600_V2_HIT_CACHEOP_WAR for your platform
141 #error Check setting of R5432_CP0_INTERRUPT_WAR for your platform
155 #error Check setting of BCM1250_M3_WAR for your platform
162 #error Check setting of SIBYTE_1956_WAR for your platform
178 #error Check setting of MIPS4K_ICACHE_REFILL_WAR for your platform
197 #error Check setting of MIPS_CACHE_SYNC_WAR for your platform
208 #error Check setting of TX49XX_ICACHE_INDEX_INV_WAR for your platform
218 #error Check setting of ICACHE_REFILLS_WORKAROUND_WAR for your platform
[all …]
|
| /linux-4.4.14/Documentation/isdn/ |
| D | INTERFACE.fax | 4 Description of the fax-subinterface between linklevel and hardwarelevel of
11 command ISDN_CMD_SETL3 (parm.fax). This pointer expires in case of hangup
18 In receive-mode the LL-driver takes care of the bit-order conversion
59 Defines the actual state of fax connection. Set by HL or LL
60 depending on progress and type of connection.
61 If the phase changes because of an AT command, the LL driver
62 changes this value. Otherwise the HL-driver takes care of it, but
64 (one of the constants ISDN_FAX_PHASE_[IDLE,A,B,C,D,E])
80 the end of connection for the +FHNG message.
84 ISDN_TTY_FAX_CFR output of +FCFR message.
[all …]
|
| /linux-4.4.14/Documentation/input/ |
| D | multi-touch-protocol.txt | 9 In order to utilize the full power of the new multi-touch and multi-user
13 drivers to report details for an arbitrary number of contacts.
15 The protocol is divided into two types, depending on the capabilities of the
18 devices capable of tracking identifiable contacts (type B), the protocol
25 Contact details are sent sequentially as separate packets of ABS_MT
26 events. Only the ABS_MT events are recognized as part of a contact
28 applications, the MT protocol can be implemented on top of the ST protocol
32 input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
37 input_mt_slot(), with a slot as argument, at the beginning of each packet.
39 prepare for updates of the given slot.
[all …]
|
| D | iforce-protocol.txt | 3 specify force effects to I-Force 2.0 devices. None of this information comes
18 ** General form of a packet **
21 CS is the checksum. It is equal to the exclusive or of all bytes.
31 This packet is used to indicate the state of each button and the value of each
48 00 ? Bit 1 (Value 2) is the value of the deadman switch
51 03 Address of parameter block changed (lsb)
52 04 Address of parameter block changed (msb)
53 05 Address of second parameter block changed (lsb)
54 ... depending on the number of parameter blocks updated
80 03-04 Duration of effect (little endian encoding, in ms)
[all …]
|
| D | atarikbd.txt | 7 controller that is flexible enough that it can be used in a variety of
10 The ikbd processor also maintains a time-of-day clock with one second
13 variety of new computer products. Product variations in a number of
16 serial interface. It can function in a variety of modes to facilitate
17 different applications of the keyboard, joysticks, or mouse. Limited use of
35 0xFC time-of-day
45 The mouse port should be capable of supporting a mouse with resolution of
46 approximately 200 counts (phase changes or 'clicks') per inch of travel. The
53 The mouse buttons can be treated as part of the mouse or as additional
59 records whenever a mouse event occurs. A mouse event consists of a mouse
[all …]
|
| D | ntrig.txt | 25 activate_slack number of fingers to ignore before processing events
33 deactivate_slack the number of "no contact" frames to ignore before
34 propagating the end of activity events
36 When the last finger is removed from the device, it sends a number of empty
53 All N-Trig devices with product id of 1 report events in the ranges of
56 However not all of these devices have the same physical dimensions. Most
58 at least one model (Dell Studio 17) has a 17" sensor. The ratio of physical
65 With the release of the early multi-touch firmwares it became increasingly
71 not address the problem of dropping one of more contacts while other contacts
75 As observed ghost contacts are similar to actual use of the sensor, but they
[all …]
|
| /linux-4.4.14/Documentation/early-userspace/ |
| D | buffer-format.txt | 12 expanded into a ramfs filesystem; this document details the format of
17 archive can be compressed using gzip(1). One valid version of an
20 The full format of the initramfs buffer is defined by the following
22 * is used to indicate "0 or more occurrences of"
25 GZIP() indicates the gzip(1) of the operand
39 In human terms, the initramfs buffer contains a collection of
44 The cpio "TRAILER!!!" entry (cpio end-of-archive) is optional, but is
45 not ignored; see "handling of hard links" below.
47 The structure of the cpio_header is as follows (all fields contain
49 full width of the field, for example, the integer 4780 is represented
[all …]
|
| /linux-4.4.14/arch/x86/math-emu/ |
| D | README | 9 | it under the terms of the GNU General Public License version 2 as |
13 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
17 | You should have received a copy of the GNU General Public License |
26 which was my 80387 emulator for early versions of djgpp (gcc under
33 facets of the functioning of the FPU are not well covered in the
36 possible to be sure that all of the peculiarities of the 80486 have
38 in the detailed behaviour of the emulator and a real 80486.
40 wm-FPU-emu does not implement all of the behaviour of the 80486 FPU,
41 but is very close. See "Limitations" later in this file for a list of
56 ----------------------- Internals of wm-FPU-emu -----------------------
[all …]
|
| /linux-4.4.14/Documentation/RCU/ |
| D | trace.txt | 4 The rcutree and rcutiny implementations of RCU provide debugfs trace
6 debugging RCU itself, and can sometimes also help to debug abuses of RCU.
13 These implementations of RCU provide several debugfs directories under the
20 Each directory contains files for the corresponding flavor of RCU.
27 of "cat rcu/rcutorture" looks as follows:
32 The first line shows the number of rcutorture tests that have completed
34 string will appear as shown above. The second line shows the number of
51 Displays counts of the reasons rcu_pending() decided that RCU had
57 The output of "cat rcu/rcu_preempt/rcudata" looks as follows:
59 …0!c=30455 g=30456 cnq=1/0:1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 …
[all …]
|
| D | torture.txt | 21 restart the tests, regardless of the initial state specified by the
33 fqs_duration Duration (in microseconds) of artificially induced bursts
34 of force_quiescent_state() invocations. In RCU
43 of calls to force_quiescent_state().
56 done via timers. Defaults to "1" for variants of RCU that
57 permit this. (Or, more accurately, variants of RCU that do
61 in which case n_barrier_cbs specifies the number of
65 synchronous RCU implementation (one for which a member of
70 nfakewriters This is the number of RCU fake writer threads to run. Fake
72 current readers" function of the interface selected by
[all …]
|
| /linux-4.4.14/Documentation/sound/alsa/ |
| D | compress_offload.txt | 16 reduction of power consumption compared to host-based
18 mostly because of a lack of a generic API available in the mainline
21 Rather than requiring a compatibility break with an API change of the
25 The design of this API was inspired by the 2-year experience with the
27 API in the mainline kernel instead of the staging tree and make it
37 estimate reliably the duration of audio buffers when handling
40 reporting of the number of samples rendered at any given time.
42 - Handling of multiple formats. PCM data only requires a specification
43 of the sampling rate, number of channels and bits per sample. In
44 contrast, compressed data comes in a variety of formats. Audio DSPs
[all …]
|
| /linux-4.4.14/Documentation/block/ |
| D | stat.txt | 4 This file documents the contents of the /sys/block/<dev>/stat file.
6 The stat file provides several statistics about the state of block
12 represent a consistent snapshot of the state of the device. If the
14 each, it would be impossible to guarantee that a set of readings
17 The stat file consists of a single line of text containing 11 decimal
23 read I/Os requests number of read I/Os processed
24 read merges requests number of read I/Os merged with in-queue I/O
25 read sectors sectors number of sectors read
27 write I/Os requests number of write I/Os processed
28 write merges requests number of write I/Os merged with in-queue I/O
[all …]
|
| D | biovecs.txt | 7 As of 3.13, biovecs should never be modified after a bio has been submitted.
8 Instead, we have a new struct bvec_iter which represents a range of a biovec -
14 bv_len by the number of bytes completed in that biovec.
16 In the new scheme of things, everything that must be mutated in order to
18 bi_size and bi_idx have been moved there; and instead of modifying bv_offset
19 and bv_len, struct bvec_iter has bi_bvec_done, which represents the number of
22 There are a bunch of new helper macros for hiding the gory details - in
23 particular, presenting the illusion of partially completed biovecs so that
32 instead of an integer (that corresponded to bi_idx); for a lot of code the
33 conversion just required changing the types of the arguments to
[all …]
|
| D | cfq-iosched.txt | 4 The main aim of CFQ scheduler is to provide a fair allocation of the disk
8 operation(synchronous requests). In case of asynchronous requests, all the
23 single spindle SATA/SAS disks where we can cut down on overall number of
29 side is that isolation provided from WRITES also goes down and notion of
33 In general I think for SATA/SAS disks and software RAID of SATA/SAS disks
42 The distance is the amount of space from the current head location to the
43 sectors that are backward in terms of distance.
51 This parameter is used to compute the cost of backward seeking. If the
52 backward distance of request is just 1/back_seek_penalty from a "front"
53 request, then the seeking cost of two requests is considered equivalent.
[all …]
|
| D | biodoc.txt | 14 These are some notes describing some aspects of the 2.5 block layer in the
15 context of the bio rewrite. The idea is to bring out some of the key
16 changes and a glimpse of the rationale behind those changes.
26 Many aspects of the generic block layer redesign were driven by and evolved
27 over discussions, prior patches and the collective experience of several
28 people. See sections 8 and 9 for a list of some related references.
42 Description of Contents:
45 1. Scope for tuning of logic to various needs
56 (instead of using buffer heads at the i/o layer)
72 5.1 Granular locking: Removal of io_request_lock
[all …]
|
| D | queue-sysfs.txt | 15 value of this file is '1'(on).
19 This shows the size of internal allocation of the device in bytes, if
20 reported by the device. A value of '0' means device does not support
26 the number of bytes that can be trimmed or unmapped in a single operation.
28 number of bytes that can be discarded in a single operation. Discard
30 value of 0 means that the device does not support discard functionality.
47 This is the hardware sector size of the device, in bytes.
51 This file is used to control (on/off) the iostats accounting of the
56 This is the logcal block size of the device, in bytes.
60 This is the maximum number of kilobytes supported in a single data transfer.
[all …]
|
| /linux-4.4.14/Documentation/vm/ |
| D | hugetlbpage.txt | 2 The intent of this file is to give a brief summary of hugetlbpage support in
3 the Linux kernel. This support is built on top of multiple page size support
7 256M and ppc64 supports 4K and 16M. A TLB is a cache of virtual-to-physical
9 Operating systems try to make best use of limited number of TLB resources.
21 The /proc/meminfo file provides information about the total number of
23 information about the number of free, reserved and surplus huge pages and the
25 proper alignment and size of the arguments to system calls that map huge page
28 The output of "cat /proc/meminfo" will include lines like:
38 HugePages_Total is the size of the pool of huge pages.
39 HugePages_Free is the number of huge pages in the pool that are not yet
[all …]
|
| D | numa_memory_policy.txt | 8 document attempts to describe the concepts and APIs of the 2.6 memory policy
14 memory may be allocated by a set of processes. Memory policies are a
15 programming interface that a NUMA-aware application can take advantage of. When
16 both cpusets and policies are applied to a task, the restrictions of the cpuset
21 Scope of Memory Policies
23 The Linux kernel supports _scopes_ of memory policy, described here from
28 by one of the more specific policy scopes discussed below. When the
37 on behalf of the task that aren't controlled by a more specific scope.
42 The task policy applies to the entire address space of a task. Thus,
46 executable image that has no awareness of memory policy. See the
[all …]
|
| D | 00-INDEX | 10 - Outline frontswap, part of the transcendent memory frontend.
12 - Outline of highmem and common issues.
14 - a brief summary of hugetlbpage support in the Linux kernel.
18 - description of the idle page tracking feature.
24 - documentation of concepts and APIs of the 2.6 memory policy support.
26 - description of the Linux kernels overcommit handling modes.
28 - description of page migration in NUMA systems.
36 - Separate per-table lock to improve scalability of the old page_table_lock.
38 - Transparent Hugepage Support, alternative way of using hugepages.
|
| D | zsmalloc.txt | 9 any object of size PAGE_SIZE/2 or larger would occupy an entire page.
10 This was one of the major issues with its predecessor (xvmalloc).
12 To overcome these issues, zsmalloc allocates a bunch of 0-order pages
18 For simplicity, zsmalloc can only allocate objects of size up to PAGE_SIZE
19 since this satisfies the requirements of all its current users (in the
26 location of the allocated object. The reason for this indirection is that
37 /sys/kernel/debug/zsmalloc/<user name>. Here is a sample of stat output:
54 almost_empty: the number of ZS_ALMOST_EMPTY zspages(see below)
55 almost_full: the number of ZS_ALMOST_FULL zspages(see below)
56 obj_allocated: the number of objects allocated
[all …]
|
| D | balance | 9 overhead of page reclaim. This may happen for opportunistic high-order
15 In the absence of non sleepable allocation requests, it seems detrimental
17 is, only when needed (aka zone free memory is 0), instead of making it
21 mapped pages from the direct mapped pool, instead of falling back on
24 OTOH, if there is a lot of free dma pages, it is preferable to satisfy
26 of incurring the overhead of regular zone balancing.
29 _total_ number of free pages fell below 1/64 th of total memory. With the
30 right ratio of dma and regular memory, it is quite possible that balancing
32 been running production machines of varying memory sizes, and seems to be
33 doing fine even with the presence of this problem. In 2.3, due to
[all …]
|
| D | highmem.txt | 16 (*) Cost of temporary mappings.
25 High memory (highmem) is used when the size of physical memory approaches or
26 exceeds the maximum size of virtual memory. At that point it becomes
27 impossible for the kernel to keep all of the available physical memory mapped
28 at all times. This means the kernel needs to start using temporary mappings of
29 the pieces of physical memory that it wants to access.
31 The part of (physical) memory not covered by a permanent mapping is what we
51 This means that the kernel can at most map 1GiB of physical memory at any one
53 temporary maps to access the rest of the physical memory - the actual direct
65 The kernel contains several ways of creating temporary mappings:
[all …]
|
| D | page_migration | 4 Page migration allows the moving of the physical location of pages between
7 system rearranges the physical location of those pages.
9 The main intend of page migration is to reduce the latency of memory access
15 a new memory policy via mbind(). The pages of process can also be relocated
17 migrate_pages function call takes two sets of nodes and moves pages of a
23 migration. cat /proc/<pid>/numa_maps allows an easy review of where the
24 pages of a process are located. See also the numa_maps documentation in the
29 administrator may detect the situation and move the pages of the process
33 "move_pages" allows the moving of individual pages within a process.
39 sections of nodes. Paul Jackson has equipped cpusets with the ability to
[all …]
|
| /linux-4.4.14/Documentation/ABI/testing/ |
| D | sysfs-class-net-statistics | 6 Indicates the number of collisions seen by this network device.
14 Indicates the number of multicast packets received by this
22 Indicates the number of bytes received by this network device.
23 See the network driver for the exact meaning of when this
31 Indicates the number of compressed packets received by this
40 Indicates the number of packets received with a CRC (FCS) error
49 Indicates the number of packets received by the network device
52 meaning of this value.
59 Indicates the number of receive FIFO errors seen by this
61 meaning of this value.
[all …]
|
| D | sysfs-fs-nilfs2 | 6 Show current revision of NILFS file system driver.
14 Describe attributes of /sys/fs/nilfs2/features group.
40 Show count of free blocks on volume.
58 Describe attributes of /sys/fs/nilfs2/<device> group.
64 Show last write time of super block in human-readable
71 Show last write time of super block in seconds.
77 Show current write count of super block.
83 Show/Set interval of periodical update of superblock
90 Describe attributes of /sys/fs/nilfs2/<device>/superblock
97 Show start block number of the latest segment.
[all …]
|
| D | sysfs-ata | 6 Provide a place in sysfs for storing the ATA topology of the system. This allows
12 For each port, a directory ataX is created where X is the ata_port_id of
17 Number of IRQ received by the port while idle [some ata HBA only].
21 If a SATA Port Multiplier (PM) is connected, number of link behind it.
30 ata_port_id of the port.
32 of the parent port and Y the PM port.
44 Current speed of the link [1.5, 3Gps,...].
50 The name of the directory is devX[.Y].Z where:
51 - X is ata_port_id of the port where the device is connected,
52 - Y the port of the PM if any, and
[all …]
|
| D | sysfs-bus-pci-devices-cciss | 6 Y of controller X.
13 drive Y of controller X.
20 drive Y of controller X.
27 Y of controller X.
39 Description: Kicks of a rescan of the controller to discover logical
47 drive Y of controller X.
53 Description: Displays the RAID level of logical drive Y of
60 Description: Displays the usage count (number of opens) of logical drive Y
61 of controller X.
67 Description: Value of 1 indicates the controller can honor the reset_devices
[all …]
|
| D | sysfs-class-mtd | 32 Major and minor numbers of the character device corresponding
41 Major and minor numbers of the character device corresponding
42 to the read-only variant of thie MTD device (in
82 provides the total number of erase regions. Otherwise,
90 Number of OOB bytes per page.
97 Total size of the device/partition, in bytes.
104 One of the following ASCII strings, representing the device
117 In the case of NOR flash it is 1 (even though individual
120 In the case of NAND flash it is one NAND page (or a
123 In the case of ECC NOR, it is the ECC block size.
[all …]
|
| D | sysfs-firmware-acpi | 6 to obtain a copy of the firmware boot splash and
15 version: The version of the BGRT. Currently 1.
16 xoffset: The number of pixels between the left of the screen
17 and the left edge of the image.
18 yoffset: The number of pixels between the top of the screen
19 and the top edge of the image.
25 There are separate hotplug profiles for different classes of
28 class of devices is a collection of settings defining the way
29 that class of devices will be handled by the ACPI core hotplug
31 of /sys/firmware/acpi/hotplug/.
[all …]
|
| D | configfs-usb-gadget-uvc | 46 iTerminal - index of string descriptor
47 bSourceID - id of the terminal to which this terminal
49 bAssocTerminal - id of the input terminal to which this output
52 bTerminalID - a non-zero id of this terminal
67 wOcularFocalLength - the value of Locular
68 wObjectiveFocalLengthMax- the value of Lmin
69 wObjectiveFocalLengthMin- the value of Lmax
70 iTerminal - index of string descriptor
71 bAssocTerminal - id of the output terminal to which
74 bTerminalID - a non-zero id of this terminal
[all …]
|
| D | sysfs-class-extcon | 7 The name of extcon object denoted as ... is the name given
12 attached simultaneously. Many of docks, cradles, and
14 the 30-pin port of Nuri board (/arch/arm/mach-exynos)
26 The /sys/class/extcon/.../name shows the name of the extcon
36 attach/detach information of the corresponding extcon object.
52 In order to update the state of an extcon device, enter a hex
56 This updates the whole state of the extcon device.
57 Inputs of all the methods are required to meet the
63 multiple cable states of an extcon device simultaneously.
69 The /sys/class/extcon/.../cable.x/name shows the name of cable
[all …]
|
| D | sysfs-firmware-dmi-entries | 10 The kernel itself does not rely on the majority of the
15 DMI is structured as a large table of entries, where
17 length of the entry, as well as a firmware-provided
27 Multiple entries of the same type are allowed. In order
44 Instance numbers are used in lieu of the firmware
56 length : The length of the entry, as presented in the
58 total count of bytes associated with the
59 entry_. This value represents the length of
60 the "formatted" portion of the entry. This
62 the "unformatted" region composed of nul
[all …]
|
| D | debugfs-pfo-nx-crypto | 14 - A u32 providing a total count of errors since the driver was loaded. The
22 - The process ID of the process who received the most recent error from the
29 - The total number of bytes encrypted using AES in any of the driver's
33 - The total number of AES operations submitted to the hardware.
36 - The total number of bytes hashed by the hardware using SHA-256.
39 - The total number of SHA-256 operations submitted to the hardware.
42 - The total number of bytes hashed by the hardware using SHA-512.
45 - The total number of SHA-512 operations submitted to the hardware.
|
| D | sysfs-devices | 5 The /sys/devices tree contains a snapshot of the
6 internal state of the kernel device tree. Devices will
8 and between different kernel versions, the layout of the
11 Please do not rely on the format of this tree because of
15 within the /sys/devices tree of the individual devices.
16 Or rely on the uevent messages to notify programs of
18 the location of those devices.
|
| /linux-4.4.14/Documentation/development-process/ |
| D | 1.Intro | 3 The purpose of this document is to help developers (and their managers)
4 work with the development community with a minimum of frustration. It is
9 discussion which does not require a deep knowledge of kernel programming to
15 The rest of this section covers the scope of the kernel development process
16 and the kinds of frustrations that developers and their employers can
20 influence the direction of kernel development. Code contributed to the
24 the mechanics of the merge window. The various phases in the patch
26 discussion of tools and mailing lists. Developers wanting to get started
35 patches are covered, and there is an introduction to some of the tools
38 Section 5 talks about the process of posting patches for review. To be
[all …]
|
| D | 4.Coding | 4 process, the proof of any kernel development project is in the resulting
6 (or not) into the mainline tree. So it is the quality of this code which
7 will determine the ultimate success of the project.
10 number of ways in which kernel developers can go wrong. Then the focus
20 Documentation/CodingStyle. For much of that time, the policies described
22 a substantial amount of code in the kernel which does not meet the coding
23 style guidelines. The presence of that code leads to two independent
26 The first of these is to believe that the kernel coding standards do not
27 matter and are not enforced. The truth of the matter is that adding new
31 requires some uniformity of code to make it possible for developers to
[all …]
|
| D | 2.Process | 4 with relatively small numbers of users and developers involved. With a
6 course of one year, the kernel has since had to evolve a number of
7 processes to keep development happening smoothly. A solid understanding of
8 how the process works is required in order to be an effective part of it.
26 changesets with changes to several hundred thousand lines of code. 2.6 is
27 thus the leading edge of Linux kernel development; the kernel uses a
31 merging of patches for each release. At the beginning of each development
34 community) is merged into the mainline kernel. The bulk of changes for a
35 new development cycle (and all of the major changes) will be merged during
40 merge window do not come out of thin air; they have been collected, tested,
[all …]
|
| D | 3.Early-stage | 5 though, much of the groundwork for success is best laid before the first
6 line of code is written. Some time spent in early planning and
13 clear description of the problem to be solved. In some cases, this step is
14 easy: when a driver is needed for a specific piece of hardware, for
28 misuse of the LSM framework (which is not intended to confer privileges
37 entire kernel development process; one of them went back to an audio list
40 There are a number of very good Linux kernel developers, but they
41 tend to get outshouted by a large crowd of arrogant fools. Trying
42 to communicate user requirements to these people is a waste of
47 The reality of the situation was different; the kernel developers were far
[all …]
|
| D | 5.Posting | 6 of conventions and procedures which are used in the posting of patches;
32 There are a number of things which should be done before you consider
35 - Test the code to the extent that you can. Make use of the kernel's
37 combinations of configuration options, use cross-compilers to build for
44 benchmarks showing what the impact (or benefit) of your change is; a
45 summary of the results should be included with the patch.
57 The preparation of patches for posting can be a surprising amount of work,
61 Patches must be prepared against a specific version of the kernel. As a
69 on the area of your patch and what is going on elsewhere, basing a patch
70 against these other trees can require a significant amount of work
[all …]
|
| D | 8.Conclusion | 3 There are numerous sources of information on Linux kernel development and
10 documents in HTML or PDF format (though the version of TeX shipped by some
14 Various web sites discuss kernel development at all levels of detail. Your
25 And, of course, one should not forget http://kernel.org/, the definitive
28 There are a number of books on kernel development:
38 All of these books suffer from a common fault, though: they tend to be
40 the shelves for a while now. Still, there is quite a bit of good
53 document. Hopefully it has provided a helpful understanding of how the
57 project is no more than the sum of what its contributors put into it. The
59 been helped by an impressively large group of developers, all of whom are
[all …]
|
| /linux-4.4.14/Documentation/pcmcia/ |
| D | driver-changes.txt | 2 * pcmcia_loop_config() and autoconfiguration (as of 2.6.36)
14 * pcmcia_request_configuration -> pcmcia_enable_device (as of 2.6.36)
20 * pcmcia_request_window changes (as of 2.6.36)
21 Instead of win_req_t, drivers are now requested to fill out
27 * pcmcia_request_io changes (as of 2.6.36)
28 Instead of io_req_t, drivers are now requested to fill out
34 * No dev_info_t, no cs_types.h (as of 2.6.36)
39 * No dev_node_t (as of 2.6.35)
42 * New IRQ request rules (as of 2.6.35)
43 Instead of the old pcmcia_request_irq() interface, drivers may now
[all …]
|
| /linux-4.4.14/Documentation/filesystems/pohmelfs/ |
| D | network_protocol.txt | 11 __u32 size; /* Size of the attached data */
14 __u64 start; /* Start of the object. */
41 NETFS_CAPABILITIES, /* Capabilities of the client, for example supported crypto */
47 like partial size of the embedded objects or creation flags.
49 @size - size of the attached data. For NETFS_READ_PAGE and NETFS_READ_PAGES no data is attached,
50 but size of the requested data is incorporated here. It does not include size of the command
53 @id - id of the object this command operates on. Each command can use it for own purpose.
55 @start - start of the object this command operates on. Each command can use it for own purpose.
57 @csize, @cpad - size and padding size of the (attached if needed) crypto information.
62 This command is used to sync content of the remote dir to the client.
[all …]
|
| /linux-4.4.14/tools/perf/Documentation/ |
| D | callchain-overhead-calculation.txt | 5 adding all period values of the entry - usually a function (symbol).
6 This is the value that perf shows traditionally and sum of all the
9 The 'children' overhead is calculated by adding all period values of
10 the child functions so that it can show the total overhead of the
15 It might be confusing that the sum of all the 'children' overhead
16 values exceeds 100% since each of them is already an accumulation of
17 'self' overhead of its child functions. But with this enabled, users
39 In this case 'foo' is a child of 'bar', and 'bar' is an immediate
40 child of 'main' so 'foo' also is a child of 'main'. In other words,
41 'main' is a parent of 'foo' and 'bar', and 'bar' is a parent of 'foo'.
[all …]
|
| D | perf-report.txt | 30 Show the number of samples for each symbol
42 file://filename entries. This option will affect the percentage of
52 file://filename entries. This option will affect the percentage of
57 file://filename entries. This option will affect the percentage of
75 - comm: command (name) of the task which can be read via /proc/<pid>/comm
76 - pid: command and tid of the task
77 - dso: name of library or module executed at the time of sample
78 - symbol: name of function executed at the time of sample
79 - parent: name of function matched to the parent regex filter. Unmatched
81 - cpu: cpu number the task ran at the time of sample
[all …]
|
| D | perf-bench.txt | 21 Specify amount of times to repeat the run (default 10).
67 Suite for evaluating performance of scheduler and IPC mechanisms.
70 Options of *messaging*
74 Use pipe() instead of socketpair()
78 Be multi thread instead of multi process
82 Specify number of groups
86 Specify number of loops
88 Example of *messaging*
109 Options of *pipe*
113 Specify number of loops.
[all …]
|
| D | perf-script-perl.txt | 18 displays the results of the trace analysis implemented in the given
24 You can avoid reading the rest of this document by running 'perf script
26 That will generate a starter script containing a handler for each of
34 attempts to exercise all of the main scripting features.
45 Most of the event's field values are passed as arguments to the
46 handler function; some of the less common ones aren't - those are
87 The $common_* arguments in the handler's argument list are the set of
88 arguments passed to all event handlers; some of the fields correspond
90 and some of the common_* fields aren't common enough to to be passed
93 Here's a brief description of each of the invariant event args:
[all …]
|
| D | perf-top.txt | 30 Monitor only on the list of CPUs provided. Multiple CPUs can be provided as a
31 comma-separated list with no space: 0,1. Ranges of CPUs are specified with -: 0-2.
36 Number of seconds to delay between refreshes.
42 event (eventsel+umask) in the form of rNNN where NNN is a
70 Number of mmap data pages (must be a power of two) or size
72 size is rounded up to have nearest pages power of two value.
120 Please see description of --sort in the perf-report man page.
133 Show a column with the number of samples.
136 Show a column with the sum of periods.
140 percentage of the overhead column. See --percentage for more info.
[all …]
|
| /linux-4.4.14/Documentation/device-mapper/ |
| D | statistics.txt | 4 Device Mapper supports the collection of I/O statistics on user-defined
5 regions of a DM device. If no regions are defined no statistics are
13 The I/O statistics counters for each step-sized area of a region are
18 histogram of latencies. All these counters may be accessed by sending
32 The creation of DM statistics will allocate memory via kmalloc or
33 fallback to using vmalloc space. At most, 1/4 of the overall system
49 "<start_sector>+<length>" - a range of <length> 512-byte sectors
56 number of areas.
59 The number of optional arguments
64 instead of the "jiffies" variable. When this argument is
[all …]
|
| D | verity.txt | 4 Device-Mapper's "verity" target provides transparent integrity checking of
17 This is the type of the on-disk hash format.
21 the rest of the block is padded with zeros.
25 padded with zeros to the power of two.
28 This is the device containing data, the integrity of which needs to be
43 The size of a hash block in bytes.
46 The number of data blocks on the data device. Additional blocks are
51 This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
52 to the root block of the hash tree.
56 be the name of the algorithm, like "sha1".
[all …]
|
| D | switch.txt | 5 arbitrary mapping of fixed-size regions of I/O across a fixed set of
10 number of fixed-sized address regions but there is no simple pattern
11 that would allow for a compact representation of the mapping such as
19 consists of a number of distinct storage arrays ("members") each having
21 is created it is spread across multiple members. The details of the
32 This architecture simplifies the management and configuration of both
35 interfaces on both the host and target to take advantage of the
41 A device-mapper table already lets you map different regions of a
43 spread with an address region size on the order of 10s of MBs, which
53 The lower tier consists of a single dm multipath device for each member.
[all …]
|
| D | dm-io.txt | 5 types of I/O services available, and each type has a sync and an async
9 of the I/O. Each io_region indicates a block-device along with the starting
10 sector and size of the region.
19 to multiple regions are specified by an array of io_region structures.
21 The first I/O service type takes a list of memory pages as the data buffer for
36 The second I/O service type takes an array of bio vectors as the data buffer
38 but wants to direct different portions of the bio to different devices.
49 I/O to a large region but doesn't want to allocate a large number of individual
57 Callers of the asynchronous I/O services must include the name of a completion
63 all of the synchronous versions, is a bitset (instead of a simple error value).
[all …]
|
| D | cache.txt | 7 It aims to improve performance of a block device (eg, a spindle) by
8 dynamically migrating some of its data to a faster, smaller device
12 different levels of the dm stack, for instance above the data device for
20 policy module. Several of these have been written as we experiment,
27 Migration - Movement of the primary copy of a logical block from one
32 The origin device always contains a copy of the logical block, which
33 may be out of date or kept in sync with the copy on the cache device
59 The origin is divided up into blocks of a fixed size. This block size
61 using block sizes of 256KB - 1024KB. The block size must be between 64
62 (32KB) and 2097152 (1GB) and a multiple of 64 (32KB).
[all …]
|
| D | dm-raid.txt | 34 - RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
39 Reference: Chapter 4 of
42 <#raid_params>: The number of parameters that follow.
44 <raid_params> consists of
56 Interval between runs of the bitmap daemon that
66 The region_size multiplied by the number of regions is the
67 logical size of the array. The bitmap records the device
72 These two options are used to alter the default layout of
73 a RAID10 configuration. The number of copies is can be
76 is "near". Near copies are what most people think of with
[all …]
|
| /linux-4.4.14/Documentation/arm/ |
| D | Setup | 11 should not be referenced outside of arch/arm/kernel/setup.c:setup_arch().
13 There are a lot of parameters listed in there, and they are described
18 This parameter must be set to the page size of the machine, and
23 This is the total number of pages of memory in the system. If
25 of pages in the system.
44 major/minor number pair of device to mount as the root filesystem.
49 These two together describe the character size of the dummy console,
54 the equivalent character size of your fbcon display. This then allows
60 This describes the character position of cursor on VGA console, and
76 Number of ADFS/MFM disks. May be used differently by different
[all …]
|
| /linux-4.4.14/Documentation/ABI/stable/ |
| D | sysfs-bus-firewire | 11 Contents of the Configuration ROM register.
12 Binary attribute; an array of host-endian u32.
15 The node's EUI-64 in the bus information block of
17 Hexadecimal string representation of an u64.
30 Summary of all units present in an IEEE 1394 node.
31 Contains space-separated tuples of specifier_id and
32 version of each unit present in the node. Specifier_id
33 and version are hexadecimal string representations of
34 u24 of the respective unit directory entries.
38 Users: udev rules to set ownership and access permissions or ACLs of
[all …]
|
| D | sysfs-firmware-opal-dump | 14 0xXX-0xYYYY: A directory for dump of type 0xXX and
15 id 0xYYYY (in hex). The name of this
19 and ID of the dump, use the id and type files.
20 Do not rely on any particular size of dump
24 id: An ASCII representation of the dump ID
26 type: An ASCII representation of the type of
28 in hex and a description of the dump type
34 The size of the dump is the size of this file.
40 Reading this file will get a list of
|
| /linux-4.4.14/arch/powerpc/boot/dts/fsl/ |
| D | b4420qds.dts | 8 * * Redistributions of source code must retain the above copyright
9 * notice, this list of conditions and the following disclaimer.
11 * notice, this list of conditions and the following disclaimer in the
13 * * Neither the name of Freescale Semiconductor nor the
14 * names of its contributors may be used to endorse or promote products
18 * ALTERNATIVELY, this software may be distributed under the terms of the
20 * Foundation, either version 2 of that License or (at your option) any
25 * warranties of merchantability and fitness for a particular purpose are
28 * (including, but not limited to, procurement of substitute goods or services;
29 * loss of use, data, or profits; or business interruption) however caused and
[all …]
|
| D | b4420si-pre.dtsi | 8 * * Redistributions of source code must retain the above copyright
9 * notice, this list of conditions and the following disclaimer.
11 * notice, this list of conditions and the following disclaimer in the
13 * * Neither the name of Freescale Semiconductor nor the
14 * names of its contributors may be used to endorse or promote products
18 * ALTERNATIVELY, this software may be distributed under the terms of the
20 * Foundation, either version 2 of that License or (at your option) any
25 * warranties of merchantability and fitness for a particular purpose are
28 * (including, but not limited to, procurement of substitute goods or services;
29 * loss of use, data, or profits; or business interruption) however caused and
[all …]
|
| D | p5040si-pre.dtsi | 8 * * Redistributions of source code must retain the above copyright
9 * notice, this list of conditions and the following disclaimer.
11 * notice, this list of conditions and the following disclaimer in the
13 * * Neither the name of Freescale Semiconductor nor the
14 * names of its contributors may be used to endorse or promote products
18 * ALTERNATIVELY, this software may be distributed under the terms of the
20 * Foundation, either version 2 of that License or (at your option) any
25 * warranties of merchantability and fitness for a particular purpose are
28 * (including, but not limited to, procurement of substitute goods or services;
29 * loss of use, data, or profits; or business interruption) however caused and
[all …]
|
| D | b4420si-post.dtsi | 8 * * Redistributions of source code must retain the above copyright
9 * notice, this list of conditions and the following disclaimer.
11 * notice, this list of conditions and the following disclaimer in the
13 * * Neither the name of Freescale Semiconductor nor the
14 * names of its contributors may be used to endorse or promote products
18 * ALTERNATIVELY, this software may be distributed under the terms of the
20 * Foundation, either version 2 of that License or (at your option) any
25 * warranties of merchantability and fitness for a particular purpose are
28 * (including, but not limited to, procurement of substitute goods or services;
29 * loss of use, data, or profits; or business interruption) however caused and
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/pinctrl/ |
| D | samsung-pinctrl.txt | 5 and also provides ability to multiplex and configure the output of various
9 - compatible: should be one of the following.
23 - reg: Base address of the pin controller hardware module and length of
26 - Pin banks as child nodes: Pin banks of the controller are represented by child
27 nodes of the controller node. Bank name is taken from name of the node. Each
31 - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
32 binding is used, the amount of cells must be specified as 2. See the below
33 mentioned gpio binding representation for description of particular cells.
36 <[phandle of the gpio controller node]
47 as child nodes of the pin-controller node. There should be atleast one
[all …]
|
| D | cnxt,cx92755-pinctrl.txt | 3 This document describes the device tree binding of the pin mapping hardware
4 modules in the Conexant Digicolor CX92755 SoCs. The CX92755 in one of the
5 Digicolor series of SoCs.
12 - reg: Base address of the General Purpose Pin Mapping register block and the
13 size of the block.
32 For a general description of GPIO bindings, please refer to ../gpio/gpio.txt.
36 Each pin configuration node is a sub-node of the pin controller node and is a
37 container of an arbitrary number of subnodes, called pin group nodes in this
40 Please refer to the pinctrl-bindings.txt in this directory for details of the
41 common pinctrl bindings used by client devices, including the definition of a
[all …]
|
| D | pinctrl-sirf.txt | 5 - reg : Address range of the pinctrl registers
10 - sirf,pullups : if n-th bit of m-th bank is set, set a pullup on GPIO-n of bank m
11 - sirf,pulldowns : if n-th bit of m-th bank is set, set a pulldown on GPIO-n of bank m
13 Please refer to pinctrl-bindings.txt in this directory for details of the common
16 SiRFprimaII's pinmux nodes act as a container for an arbitrary number of subnodes.
17 Each of these subnodes represents some desired configuration for a group of pins.
20 - sirf,pins : An array of strings. Each string contains the name of a group.
21 - sirf,function: A string containing the name of the function to mux to the
|
| D | lantiq,pinctrl-falcon.txt | 5 - reg: Should contain the physical address and length of the gpio/pinmux
8 Please refer to pinctrl-bindings.txt in this directory for details of the
9 common pinctrl bindings used by client devices, including the meaning of the
12 Lantiq's pin configuration nodes act as a container for an arbitrary number of
13 subnodes. Each of these subnodes represents some desired configuration for a
14 pin, a group, or a list of pins or groups. This configuration can include the
18 The name of each subnode is not important as long as it is unique; all subnodes
27 We support 2 types of nodes.
29 Definition of mux function groups:
32 - lantiq,groups : An array of strings. Each string contains the name of a group.
[all …]
|
| D | rockchip,pinctrl.txt | 8 Please refer to pinctrl-bindings.txt in this directory for details of the
9 common pinctrl bindings used by client devices, including the meaning of the
12 The Rockchip pin configuration node is a node of a group of pins which can be
14 config of the pins in that group. The 'pins' selects the function mode(also
19 defined as gpio sub-nodes of the pinmux controller.
22 - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
30 as some SoCs carry parts of the iomux controller registers there.
35 - reg: first element is the general register space of the iomux controller
37 second element is the separate pull register space of the rk3188.
42 - reg: register of the gpio bank (different than the iomux registerset)
[all …]
|
| D | lantiq,pinctrl-xway.txt | 5 - reg: Should contain the physical address and length of the gpio/pinmux
8 Please refer to pinctrl-bindings.txt in this directory for details of the
9 common pinctrl bindings used by client devices, including the meaning of the
12 Lantiq's pin configuration nodes act as a container for an arbitrary number of
13 subnodes. Each of these subnodes represents some desired configuration for a
14 pin, a group, or a list of pins or groups. This configuration can include the
18 The name of each subnode is not important as long as it is unique; all subnodes
27 We support 2 types of nodes.
29 Definition of mux function groups:
32 - lantiq,groups : An array of strings. Each string contains the name of a group.
[all …]
|
| /linux-4.4.14/Documentation/sysctl/ |
| D | fs.txt | 13 miscellaneous and general things in the operation of the Linux
14 kernel. Since some of the files _can_ be used to screw up your
47 aio-nr is the running total of the number of events specified on the
51 of any kernel data structures.
81 The file dquot-max shows the maximum number of cached disk
84 The file dquot-nr shows the number of allocated disk quota
85 entries and the number of free disk quota entries.
87 If the number of free cached disk quotas is very low and
88 you have some awesome number of simultaneous system users,
95 The value in file-max denotes the maximum number of file-
[all …]
|
| D | vm.txt | 13 of the virtual memory (VM) subsystem of the Linux kernel and
14 the writeout of dirty data to disk.
16 Default values and initialization routines for most of these
67 The amount of free memory in the system that should be reserved for users
70 admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
76 for the full Virtual Memory Size of programs used to recover. Otherwise,
86 For overcommit 'never', we can take the max of their virtual sizes (VSZ)
87 and add the sum of their RSS.
105 blocks where possible. This can be important for example in the allocation of
122 Contains the amount of dirty memory at which the background kernel
[all …]
|
| /linux-4.4.14/Documentation/trace/ |
| D | events-kmem.txt | 6 o Slab allocation of small objects of unknown type (kmalloc)
7 o Slab allocation of small objects of known type
12 This document describes what each of the tracepoints is and why they
15 1. Slab allocation of small objects of unknown type
23 internal fragmented as a result of the allocation pattern. By correlating
28 2. Slab allocation of small objects of known type
36 of writing, no information is available on what slab is being allocated from,
47 a simple indicator of page allocator activity. Pages may be allocated from
52 amounts of activity imply high activity on the zone->lock. Taking this lock
57 is triggered. Significant amounts of activity here could indicate that the
[all …]
|
| /linux-4.4.14/ |
| D | COPYING | 4 of the kernel, and does *not* fall under the heading of "derived work".
6 Foundation, but the instance of code that it refers to (the Linux
9 Also note that the only valid version of the GPL as far as the kernel
10 is concerned is _this_ particular version of the license (ie v2, not
23 of this license document, but changing it is not allowed.
31 General Public License applies to most of the Free Software
37 When we speak of free software, we are referring to freedom, not
39 have the freedom to distribute copies of free software (and charge for
41 if you want it, that you can change the software or use pieces of it
47 distribute copies of the software, or if you modify it.
[all …]
|
| /linux-4.4.14/fs/sysfs/ |
| D | file.c | 44 struct kernfs_open_file *of = sf->private; in sysfs_kf_seq_show() local
45 struct kobject *kobj = of->kn->parent->priv; in sysfs_kf_seq_show()
46 const struct sysfs_ops *ops = sysfs_file_ops(of->kn); in sysfs_kf_seq_show()
63 count = ops->show(kobj, of->kn->priv, buf); in sysfs_kf_seq_show()
82 static ssize_t sysfs_kf_bin_read(struct kernfs_open_file *of, char *buf, in sysfs_kf_bin_read() argument
85 struct bin_attribute *battr = of->kn->priv; in sysfs_kf_bin_read()
86 struct kobject *kobj = of->kn->parent->priv; in sysfs_kf_bin_read()
87 loff_t size = file_inode(of->file)->i_size; in sysfs_kf_bin_read()
102 return battr->read(of->file, kobj, battr, buf, pos, count); in sysfs_kf_bin_read()
106 static ssize_t sysfs_kf_read(struct kernfs_open_file *of, char *buf, in sysfs_kf_read() argument
[all …]
|
| /linux-4.4.14/Documentation/networking/ |
| D | LICENSE.qlcnic | 5 GNU General Public License (a copy of which is attached hereto as
17 of this license document, but changing it is not allowed.
25 General Public License applies to most of the Free Software
31 When we speak of free software, we are referring to freedom, not
33 have the freedom to distribute copies of free software (and charge for
35 if you want it, that you can change the software or use pieces of it
41 distribute copies of the software, or if you modify it.
43 For example, if you distribute copies of such a program, whether
61 patents. We wish to avoid the danger that redistributors of a free
74 under the terms of this General Public License. The "Program", below,
[all …]
|
| D | LICENSE.qlge | 5 GNU General Public License (a copy of which is attached hereto as
17 of this license document, but changing it is not allowed.
25 General Public License applies to most of the Free Software
31 When we speak of free software, we are referring to freedom, not
33 have the freedom to distribute copies of free software (and charge for
35 if you want it, that you can change the software or use pieces of it
41 distribute copies of the software, or if you modify it.
43 For example, if you distribute copies of such a program, whether
61 patents. We wish to avoid the danger that redistributors of a free
74 under the terms of this General Public License. The "Program", below,
[all …]
|
| D | altera_tse.txt | 11 for status and simple configuration of the embedded system.
16 the maintainer of this driver, found in MAINTAINERS.
26 probe function then installs the appropriate set of DMA routines to
31 years as of this writing in early 2014) in favor of the MSGDMA component.
56 dma_rx_num: Number of descriptors in the RX list (default is 64);
57 dma_tx_num: Number of descriptors in the TX list (default is 64).
70 completion in the context of the interrupt handling chain by recycling
83 The driver is able to mitigate the number of its DMA interrupts
94 4.7) List of source files:
123 The controller and driver support a mix of IEEE standard defined statistics,
[all …]
|
| D | z8530drv.txt | 1 This is a subset of the documentation. To use this driver you MUST have the
12 A new version of the documentation, along with links to other important
32 1. Initialization of the driver
38 2. Setup of hardware, MODEM and KISS parameters with sccinit
42 driver. If you want to run xNOS instead of our fine kernel AX.25
50 (If you're going to compile the driver as a part of the kernel image,
59 You should include the insmod in one of the /etc/rc.d/rc.* files,
60 and don't forget to insert a call of sccinit after that. It
67 of your rc.*-files. This has to be done BEFORE you can
72 The file itself consists of two main sections.
[all …]
|
| D | fib_trie.txt | 6 An end node with data. This has a copy of the relevant key, along
11 An internal node, holding an array of child (leaf or tnode) pointers,
12 indexed through a subset of the key. See Level Compression.
17 The number of bits in the key segment used for indexing into the
21 The position (in the key) of the key segment used for indexing into
25 Any given tnode is linked to from the child array of its parent, using
26 a segment of the key specified by the parent's "pos" and "bits"
37 children of a full child (see "full_children") up one level, so that
38 instead of a pure binary tree, each internal node ("tnode") may
39 contain an arbitrarily large array of links to several children.
[all …]
|
| D | udplite.txt | 7 is a variable-length checksum. This has advantages for transport of multimedia
9 fed into the codec instead of being discarded due to a failed checksum test.
41 very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)
54 To make use of the partial checksum coverage facilities requires setting a
74 that of a traffic filter: when enabled, it instructs the kernel to drop
77 packets with a minimum coverage of 20 are admitted:
86 A detailed discussion of UDP-Lite checksum coverage options is in section IV.
116 If the sender specifies a value of 0 as coverage length, the module
117 assumes full coverage, transmits a packet with coverage length of 0
125 The receiver specifies the minimum value of the coverage length it
[all …]
|
| D | vxlan.txt | 5 problem of limited VLAN IDs (4096) in IEEE 802.1q. With VXLAN the
6 size of the identifier is expanded to 24 bits (16777216).
9 number of vendors. The protocol runs over UDP using a single
11 device, there is also a separate implementation of VXLAN for
15 point. A VXLAN device can learn the IP address of the other endpoint
17 use of statically-configured forwarding entries.
19 The management of vxlan is done in a manner similar to its two closest
20 neighbors GRE and VLAN. Configuring VXLAN requires the version of
30 the IANA-assigned value of 4789. The Linux implementation of VXLAN
31 pre-dates the IANA's selection of a standard destination port number
|
| D | proc_net_tcp.txt | 2 Note that these interfaces are deprecated in favor of tcp_diag.
9 TCP connections. A typical entry of /proc/net/tcp would look like this (split
10 up into 3 parts because of the length of the line):
18 |----------------------------------> number of entry
21 | | | | |--> number of unrecovered RTO timeouts
22 | | | |----------> number of jiffies until timer expires
33 | | | | | | |---------> Predicted tick of soft clock
36 | | | | |------------------> location of socket in memory
|
| D | ip-sysctl.txt | 14 Default value of TTL field (Time To Live) for outgoing (but not
36 TCP path mtu must still work but path MTU information of other
60 Controls the fwmark of kernel-generated IPv4 reply packets that are not
62 If unset, these packets have a fwmark of zero. If set, they have the
63 fwmark of the packet they are replying to.
67 Maximum number of routes allowed in the kernel. Increase
68 this when using large numbers of interfaces and/or routes.
73 Minimum number of entries to keep. Garbage collector will not
84 Maximum number of neighbor entries allowed. Increase this
85 when using large numbers of interfaces and when communicating
[all …]
|
| D | radiotap-headers.txt | 7 Radiotap headers are variable-length and extensible, you can get most of the
15 Structure of the header
20 of the it_present member of ieee80211_radiotap_header is set, it means that
29 we run out of space in the u32 it_present member, it is defined that b31 set
31 argument bitmap extensions..." above), and the start of the arguments is moved
34 Note also that the it_len member __le16 is set to the total number of bytes
41 After the fixed part of the header, the arguments follow for each argument
42 index whose matching bit is set in the it_present member of
50 breakdown of all the argument sizes
52 - the arguments must be aligned to a boundary of the argument size using
[all …]
|
| /linux-4.4.14/Documentation/scsi/ |
| D | LICENSE.qla4xxx | 6 GNU General Public License (a copy of which is attached hereto as
18 of this license document, but changing it is not allowed.
26 General Public License applies to most of the Free Software
32 When we speak of free software, we are referring to freedom, not
34 have the freedom to distribute copies of free software (and charge for
36 if you want it, that you can change the software or use pieces of it
42 distribute copies of the software, or if you modify it.
44 For example, if you distribute copies of such a program, whether
62 patents. We wish to avoid the danger that redistributors of a free
75 under the terms of this General Public License. The "Program", below,
[all …]
|
| D | LICENSE.qla2xxx | 6 GNU General Public License (a copy of which is attached hereto as
19 of this license document, but changing it is not allowed.
27 General Public License applies to most of the Free Software
33 When we speak of free software, we are referring to freedom, not
35 have the freedom to distribute copies of free software (and charge for
37 if you want it, that you can change the software or use pieces of it
43 distribute copies of the software, or if you modify it.
45 For example, if you distribute copies of such a program, whether
63 patents. We wish to avoid the danger that redistributors of a free
76 under the terms of this General Public License. The "Program", below,
[all …]
|
| D | scsi-parameters.txt | 8 "modinfo -p ${modulename}" shows a current list of all parameters of a loadable
10 reveal their parameters in /sys/module/${modulename}/parameters/. Some of these
16 See header of drivers/scsi/advansys.c.
41 See header of drivers/scsi/fdomain.c.
44 See header of drivers/scsi/gdth.c.
49 See header of drivers/scsi/in2000.c.
52 See header of drivers/scsi/ips.c.
57 max_luns= [SCSI] Maximum number of LUNs to probe.
61 [SCSI] Maximum number of LUNs received.
65 See header of drivers/scsi/NCR_D700.c.
[all …]
|
| D | dpti.txt | 4 * permitted provided that redistributions of source code must retain the
5 * above copyright notice, this list of conditions and the following disclaimer.
9 * implied warranties of merchantability and fitness for a particular purpose,
12 * consequential damages (including, but not limited to, procurement of
13 * substitute goods or services; loss of use, data, or profits; or business
14 * interruptions) however caused and on any theory of liability, whether in
16 * arising in any way out of the use of this driver software, even if advised
17 * of the possibility of such damage.
24 * Dell Computer. It was ported from Bob Pasteur's (of DPT) original
28 * 2.0 version of the driver by Deanna Bonds and Mark Salyzyn.
[all …]
|
| /linux-4.4.14/Documentation/security/ |
| D | credentials.txt | 11 (*) Types of credentials.
25 (*) Overriding the VFS's use of credentials.
38 userspace programs. Linux has a variety of actionable objects, including:
48 As a part of the description of all these objects there is a set of
49 credentials. What's in the set depends on the type of object.
53 Amongst the credentials of most objects, there will be a subset that
54 indicates the ownership of that object. This is used for resource
62 Also amongst the credentials of those objects, there will be a subset that
63 indicates the 'objective context' of that object. This may or may not be
67 The objective context is used as part of the security calculation that is
[all …]
|
| D | IMA-templates.txt | 10 necessary to extend the current version of IMA by defining additional
12 the inode UID/GID or the LSM labels either of the inode and of the process
21 management from the remaining IMA code. The core of this solution is the
22 definition of two new data structures: a template descriptor, to determine
24 field, to generate and display data of a given type.
30 specifying the template format (a string of field identifiers separated
33 by translating the format into an array of template fields structures taken
34 from the set of the supported ones.
41 It is during this phase that the advantages of the new architecture are
43 a given template but, instead, it simply calls the init() method of the template
[all …]
|
| /linux-4.4.14/drivers/staging/rtl8192u/ |
| D | copying | 7 of this license document, but changing it is not allowed.
15 General Public License applies to most of the Free Software
21 When we speak of free software, we are referring to freedom, not
23 have the freedom to distribute copies of free software (and charge for
25 if you want it, that you can change the software or use pieces of it
31 distribute copies of the software, or if you modify it.
33 For example, if you distribute copies of such a program, whether
51 patents. We wish to avoid the danger that redistributors of a free
64 under the terms of this General Public License. The "Program", below,
67 that is to say, a work containing the Program or a portion of it,
[all …]
|
| /linux-4.4.14/tools/usb/usbip/ |
| D | COPYING | 7 of this license document, but changing it is not allowed.
15 General Public License applies to most of the Free Software
21 When we speak of free software, we are referring to freedom, not
23 have the freedom to distribute copies of free software (and charge for
25 if you want it, that you can change the software or use pieces of it
31 distribute copies of the software, or if you modify it.
33 For example, if you distribute copies of such a program, whether
51 patents. We wish to avoid the danger that redistributors of a free
64 under the terms of this General Public License. The "Program", below,
67 that is to say, a work containing the Program or a portion of it,
[all …]
|
| /linux-4.4.14/drivers/staging/rtl8192e/ |
| D | license | 13 Everyone is permitted to copy and distribute verbatim copies of this license
22 to most of the Free Software Foundation's software and to any other program
27 When we speak of free software, we are referring to freedom, not price. Our
29 to distribute copies of free software (and charge for this service if you
31 can change the software or use pieces of it in new free programs; and that
37 copies of the software, or if you modify it.
39 For example, if you distribute copies of such a program, whether gratis or
56 wish to avoid the danger that redistributors of a free program will
68 terms of this General Public License. The "Program", below, refers to any
71 work containing the Program or a portion of it, either verbatim or with
[all …]
|
| /linux-4.4.14/Documentation/cgroups/ |
| D | memory.txt | 19 Benefits and Purpose of the memory controller
21 The memory controller isolates the memory behaviour of a group of tasks
22 from the rest of the system. The article on LWN [12] mentions some probable
23 uses of the memory controller. The memory controller can be used to
25 a. Isolate an application or a group of applications
27 amount of memory.
28 b. Create a cgroup with a limited amount of memory; this can be used
30 c. Virtualization solutions can control the amount of memory they want
32 d. A CD/DVD burner could control the amount of memory used by the
33 rest of the system to ensure that burning does not fail due to lack
[all …]
|
| D | blkio-controller.txt | 6 a need of various kinds of IO control policies (like proportional BW, max BW)
12 weight time based division of disk policy. It is implemented in CFQ. Hence
20 Proportional Weight division of bandwidth
22 You can do a very simple testing of running two dd threads in two different
41 - Set weights of group test1 and test2
51 dd if=/mnt/sdb/zerofile1 of=/dev/null &
55 dd if=/mnt/sdb/zerofile2 of=/dev/null &
60 on looking at (with the help of script), at blkio.disk_time and
61 blkio.disk_sectors files of both test1 and test2 groups. This will tell how
63 group dispatched to the disk. We provide fairness in terms of disk time, so
[all …]
|
| D | cpusets.txt | 40 Cpusets provide a mechanism for assigning a set of CPUs and Memory
41 Nodes to a set of tasks. In this document "Memory Node" refers to
44 Cpusets constrain the CPU and Memory placement of tasks to only
63 virtual file system, manage the attributes and permissions of these
72 The management of large computer systems, with many processors (CPUs),
75 the efficient scheduling and memory placement of processes.
84 can benefit from explicitly placing jobs on properly sized subsets of
89 * Web Servers running multiple instances of the same web application,
97 executing jobs. The location of the running jobs pages may also be moved
111 Memory Nodes are used by a process or set of processes.
[all …]
|
| /linux-4.4.14/Documentation/accounting/ |
| D | taskstats.txt | 10 - efficiently provide statistics during lifetime of a task and on its exit
23 use of tgid, there is no special treatment for the task that is thread group
31 The response contains statistics for a task (if pid is specified) or the sum of
32 statistics for all tasks of the process (if tgid is specified).
36 one of the cpus in the cpumask, its per-pid statistics are sent to the
43 The latter contains the sum of per-pid stats for all threads in the thread
46 getdelays.c is a simple utility demonstrating usage of the taskstats interface
58 an outline of the current version is given. taskstats.h always overrides the
75 The taskstats payload is one of the following three kinds:
78 a pid/tgid consist of one attribute, of type TASKSTATS_CMD_ATTR_PID/TGID,
[all …]
|
| D | taskstats-struct.txt | 4 This document contains an explanation of the struct taskstats fields.
6 There are three different groups of fields in the struct taskstats:
11 delivery at do_exit() of a task.
31 Future extension should add fields to the end of the taskstats struct, and
32 should not change the relative position of each field within the struct.
38 /* The version number of this struct. This field is always set to
44 /* The exit code of a task. */
47 /* The accounting flags of a task as defined in <linux/acct.h>
52 /* The value of task_nice() of a task. */
55 /* The name of the command that started this task. */
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/powerpc/fsl/ |
| D | dcsr.txt | 6 to change. Some of the compatible strings that contain only generic names
8 the integration of the block with the rest of the chip.
30 Definition: A standard property. Defines the number of cells
36 Definition: A standard property. Defines the number of cells
37 or representing the size of physical addresses in
44 range of the DCSR space.
57 This node represents the region of DCSR space allocated to the EPU
70 The value of the interrupts property consists of three
71 interrupt specifiers. The format of the specifier is defined
79 The EPU unit can also be configured to assert either or both of
[all …]
|
| /linux-4.4.14/Documentation/filesystems/ |
| D | proc.txt | 15 Table of Contents
57 This documentation is part of a soon (or so we hope) to be released book on
70 We'd like to thank Alan Cox, Rik van Riel, and Alexey Kuznetsov and a lot of
75 and helped create a great piece of software... :)
81 The latest version of this document is available online at
91 We don't guarantee the correctness of this document, and if you come to us
92 complaining about how you screwed up your system because of incorrect
102 * Investigating the properties of the pseudo file system /proc and its
114 First, we'll take a look at the read-only parts of /proc. In Chapter 2, we
134 environ Values of environment variables
[all …]
|
| D | xfs-self-describing-metadata.txt | 7 The largest scalability problem facing XFS is not one of algorithmic
8 scalability, but of verification of the filesystem structure. Scalabilty of the
10 adequate for supporting PB scale filesystems with billions of inodes, however it
18 verify, and this in turn limits the supportable size of an XFS filesystem.
20 For example, it is entirely possible to manually use xfs_db and a bit of
21 scripting to analyse the structure of a 100TB filesystem when trying to
22 determine the root cause of a corruption problem, but it is still mainly a
23 manual task of verifying that things like single bit errors or misplaced writes
24 weren't the ultimate cause of a corruption event. It may take a few hours to a
29 to analyse and so that analysis blows out towards weeks/months of forensic work.
[all …]
|
| D | quota.txt | 6 number of used inodes (inode is a filesystem structure which is associated with
8 of used inodes there are actually two limits. The first one is called softlimit
11 softlimit but only for limited period of time. This period is called "grace
13 more space/inodes until he frees enough of them to get below softlimit.
15 Quota limits (and amount of grace time) are set independently for each
23 When user exceeds a softlimit, runs out of grace time or reaches hardlimit,
24 quota subsystem traditionally printed a message to the controlling terminal of
33 details about this layer). The name of the quota generic netlink interface
34 is "VFS_DQUOT". Definitions of constants below are in <linux/quota.h>.
39 This command is used to send a notification about any of the above mentioned
[all …]
|
| D | nilfs2.txt | 5 snapshotting. In addition to versioning capability of the entire file
11 NILFS2 creates a number of checkpoints every few seconds or per
17 There is no limit on the number of snapshots until the volume gets
50 barrier(*) This enables/disables the use of write barriers. This
57 cp=n Specify the checkpoint-number of the snapshot to be
65 is equivalent to the ordered data mode of the ext3
70 of all file operations including overwriting of data
72 overtaking of events occurs in the recovered file
74 norecovery Disable recovery of the filesystem on mount.
78 discard This enables/disables the use of discard/TRIM commands.
[all …]
|
| D | ext2.txt | 6 Theodore Ts'o and Stephen Tweedie, it was a major rewrite of the
20 check=none, nocheck (*) Don't do extra checking of bitmaps on mount
34 nogrpid, sysvgroups New objects have the group ID of their creator.
69 the concepts of blocks, inodes and directories. It has space in the
80 a fixed size, of 1024, 2048 or 4096 bytes (8192 bytes on Alpha systems),
83 and also impose other limits on the size of files and the filesystem.
89 and minimise the amount of head seeking when reading a large amount
90 of consecutive data. Information about each block group is kept in a
92 Two blocks near the start of each group are reserved for the block usage
95 that the maximum size of a block group is 8 times the size of a block.
[all …]
|
| D | f2fs.txt | 13 addressing the fundamental issues in LFS, which are snowball effect of wandering
41 implementation of a log-structured file system", ACM Trans. Computer Systems
46 In LFS, when a file data is updated and written to the end of log, its direct
58 Since LFS is based on out-of-place writes, it produces so many obsolete blocks
63 The process consists of three operations as follows.
65 2. It loads parent index structures of all the data in the victim identified by
72 amount of valid data to be moved, and move them quickly as well.
87 - Introduce Node Address Table (NAT) containing the locations of all the “node”
114 segments for data from the beginning of main area, while
115 for node from the end of main area.
[all …]
|
| D | ubifs.txt | 8 Ext2, XFS, JFS, etc. UBIFS represents a separate class of file-systems
10 file-system of this class is JFFS2.
12 To make it more clear, here is a small comparison of MTD devices and
15 1 MTD devices represent flash devices and they consist of eraseblocks of
16 rather large size, typically about 128KiB. Block devices consist of
24 4 Eraseblocks become worn out after some number of erase cycles -
35 UBIFS works on top of UBI. UBI is a separate software layer which may be
38 level abstraction than a MTD device. The programming model of UBI devices
39 is very similar to MTD devices - they still consist of large eraseblocks,
40 they have read/write/erase operations, but UBI devices are devoid of
[all …]
|
| D | gfs2-uevents.txt | 4 During the lifetime of a GFS2 mount, a number of uevents are generated.
8 A list of GFS2 uevents
21 of the filesystem respectively.
34 successful mount of the filesystem by the first node (FIRSTMOUNT=Done).
38 The other CHANGE uevent is used to inform of the completion
39 of journal recovery for one of the filesystems journals. It has
42 success (or otherwise) of the operation. These uevents are generated
44 process or as the result of gfs_controld requesting a specific journal
47 Because the CHANGE uevent was used (in early versions of gfs_controld)
49 cannot add any more functions to it without running the risk of
[all …]
|
| D | gfs2-glocks.txt | 4 This documents the basic principles of the glock state machine
9 as gl_state, gl_target and the list of holders (gl_holders)
19 of the list. Locks are granted in strictly the order that they
23 There are three lock states that users of the glock layer can request,
47 are defined for each type of glock. Not all types of glocks use
50 Table of glock operations and per type constants:
57 go_demote_ok | Returns boolean value of whether its ok to demote a glock
59 go_lock | Called for the first local holder of a lock
60 go_unlock | Called on the final local unlock of a lock
61 go_dump | Called to print content of object for debugfs file, or on
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/interrupt-controller/ |
| D | st,spear3xx-shirq.txt | 4 of devices. The multiplexor provides a single interrupt to parent
5 interrupt controller (VIC) on behalf of a group of devices.
8 exceeding 4. The number of devices in a group can differ, further they
9 may share same set of status/mask registers spanning across different
20 - compatible: should be, either of
26 (starting from 0) of interrupts for all the groups.
27 - reg: Base address and size of shirq registers.
28 - interrupts: The list of interrupts generated by the groups which are
30 associated with one of the interrupts, hence number of interrupts (to
31 parent) is equal to number of groups. The format of the interrupt
[all …]
|
| D | msi.txt | 4 Message Signaled Interrupts (MSIs) are a class of interrupts generated by a
9 those busses to the MSI controllers which they are capable of using,
12 MSIs are distinguished by some combination of:
17 they can address. An MSI controller may feature a number of doorbells.
27 taken through the memory system (i.e. it is a property of the combination of
28 MSI controller and device rather than a property of either in isolation).
35 address by some master. An MSI controller may feature a number of doorbells.
45 - #msi-cells: The number of cells in an msi-specifier, required if not zero.
50 The meaning of the msi-specifier is defined by the device tree binding of
64 - msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
[all …]
|
| D | mrvl,intc.txt | 6 - reg : Address and length of the register set of the interrupt controller.
8 of the whold interrupt controller. If the interrupt controller is mux-intc,
9 address and length means one register. Since address of mux-intc is in the
10 range of intc. mux-intc is secondary interrupt controller.
11 - reg-names : Name of the register set of the interrupt controller. It's
16 - #interrupt-cells : Specifies the number of cells needed to encode an
18 - mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt
46 - #interrupt-cells: Specifies the number of cells needed to encode an
49 - reg : Interrupt mask address. A list of 4 byte ranges, one per controller.
|
| D | marvell,orion-intc.txt | 7 - reg: base address(es) of interrupt registers starting with CAUSE register
9 - #interrupt-cells: number of cells to encode an interrupt source, shall be 1
13 - 0 maps to bit 0 of first base address,
14 - 1 maps to bit 1 of first base address,
15 - 32 maps to bit 0 of second base address, and so on.
30 - reg: base address of bridge interrupt registers starting with CAUSE register
31 - interrupts: bridge interrupt of the main interrupt controller
33 - #interrupt-cells: number of cells to encode an interrupt source, shall be 1
36 - marvell,#interrupts: number of interrupts provided by bridge interrupt
|
| /linux-4.4.14/drivers/lguest/ |
| D | README | 3 Lguest is an adventure, with you, the reader, as Hero. I can't think of many
4 5000-line projects which offer both such capability and glimpses of future
7 But be warned; this is an arduous journey of several hours or more! And as we
19 taste of its scope. Suitable for the armchair coders and other such
20 persons of faint constitution.
23 - Where we encounter the first tantalising wisps of code, and come to
24 understand the details of the life of a Guest kernel.
28 understanding of the Guest is completed.
31 - Where we trace back to the creation of the Guest, and thus begin our
32 understanding of the Host.
[all …]
|
| /linux-4.4.14/drivers/net/wireless/mwifiex/ |
| D | README | 4 # Ltd. under the terms of the GNU General Public License Version 2, June 1991
6 # accordance with the terms and conditions of the License, a copy of which
106 num_tx_bytes = <number of bytes sent to device>
107 num_rx_bytes = <number of bytes received from device and sent to kernel>
108 num_tx_pkts = <number of packets sent to device>
109 num_rx_pkts = <number of packets received from device and sent to kernel>
110 num_tx_pkts_dropped = <number of Tx packets dropped by driver>
111 num_rx_pkts_dropped = <number of Rx packets dropped by driver>
112 num_tx_pkts_err = <number of Tx packets failed to send to device>
113 num_rx_pkts_err = <number of Rx packets failed to receive from device>
[all …]
|
| /linux-4.4.14/Documentation/locking/ |
| D | rt-mutex-design.txt | 9 This document tries to describe the design of the rtmutex.c implementation.
15 The goal of this document is to help others understand the priority
25 most of the time it can't be helped. Anytime a high priority process wants
31 an undetermined amount of time.
33 The classic example of unbounded priority inversion is where you have three
37 meantime, B executes, and since B is of a higher priority than C, it preempts C,
39 Now there's no way of knowing how long A will be sleeping waiting for C
60 There are several ways to solve this issue, but other ways are out of scope
63 PI is where a process inherits the priority of another process if the other
68 of A. So now if B becomes runnable, it would not preempt C, since C now has
[all …]
|
| D | lockdep-design.txt | 10 The basic object the validator operates upon is a 'class' of locks.
12 A class of locks is a group of locks that are logically the same with
14 tens of thousands of) instantiations. For example a lock in the inode
15 struct is one class, while each inode has its own instantiation of that
18 The validator tracks the 'state' of lock-classes, and it tracks
24 and all subsequent uses of that lock-class will be attached to this
37 Where STATE can be either one of (kernel/locking/lockdep_states.h)
54 The bit position indicates STATE, STATE-read, for each of the states listed
62 Unused mutexes cannot be part of the cause of an error.
69 following states are exclusive, and only one of them is allowed to be
[all …]
|
| D | locktorture.txt | 14 This torture test consists of creating a number of kernel threads which
15 acquire the lock and hold it for specific amount of time, thus simulating
16 different critical region behaviors. The amount of contention on the lock
28 nwriters_stress Number of kernel threads that will stress exclusive lock
30 of online CPUs.
32 nreaders_stress Number of kernel threads that will stress shared lock
33 ownership (readers). The default is the same amount of writer
35 both readers and writers be the amount of online CPUs.
37 torture_type Type of lock to torture. By default, only spinlocks will
68 shutdown_secs The number of seconds to run the test before terminating
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/input/touchscreen/ |
| D | ti-tsc-adc.txt | 9 ti,coordinate-readouts: The sequencer supports a total of 16
14 A value of 5 means, 5 reads for X, 5 for
16 of the 16 software steps available. The
28 ti,adc-channels: List of analog inputs available for ADC.
33 ti,charge-delay: Length of touch screen charge delay step in terms of
42 hardware knob for adjusting the amount of "settling
46 ti,chan-step-opendelay: List of open delays for each channel of
47 ADC in the order of ti,adc-channels. The
48 value corresponds to the number of ADC
51 sending the start of ADC conversion.
[all …]
|
| /linux-4.4.14/Documentation/power/ |
| D | swsusp-and-swap-files.txt | 5 partitions and there are only two differences between these two types of swap
8 (2) the header of a swap file is not in the first block of the partition that
9 holds it. From the swsusp's point of view (1) is not a problem, because it is
10 already taken care of by the swap-handling code, but (2) has to be taken into
13 In principle the location of a swap file's header may be determined with the
14 help of appropriate filesystem driver. Unfortunately, however, it requires the
17 identify a swap file swsusp uses the name of the partition that holds the file
18 and the offset from the beginning of the partition at which the swap file's
26 # dd if=/dev/zero of=<swap_file_path> bs=1024 count=<swap_file_size_in_k>
30 2) Use an application that will bmap the swap file with the help of the
[all …]
|
| D | basic-pm-debugging.txt | 14 test at least a couple of times in a row for confidence. [This is necessary,
24 which is the default and recommended mode of hibernation.
26 Unfortunately, the "platform" mode of hibernation does not work on some systems
27 with broken BIOSes. In such cases the "shutdown" mode of hibernation might
39 a) Test modes of hibernation
47 - test the freezing of processes
50 - test the freezing of processes and suspending of devices
53 - test the freezing of processes, suspending of devices and platform
57 - test the freezing of processes, suspending of devices, platform
58 global control methods(*) and the disabling of nonboot CPUs
[all …]
|
| /linux-4.4.14/Documentation/acpi/ |
| D | namespace.txt | 1 ACPI Device Tree - Representation of ACPI Namespace
14 This document illustrates the structure of the ACPI device tree.
30 of the hardware. The FADT contains a pointer to the DSDT
36 blocks that contain definitions of various objects, including ACPI
38 of the DSDT along with the contents of SSDTs represents a hierarchical
40 structure of the underlying hardware platform.
80 is a hierarchy of objects identified by names and paths.
84 2. The first byte of a name must be one of 'A' - 'Z', '_'.
85 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
88 5. The '\' symbol represents the root of the namespace (i.e. names
[all …]
|
| D | scan_handlers.txt | 7 is scanned in search of device objects that generally represent various pieces
8 of hardware. This causes a struct acpi_device object to be created and
10 and the hierarchy of those struct acpi_device objects reflects the namespace
15 parsing code (although their role is analogous to the role of those objects).
17 During ACPI-based device hot-remove device nodes representing pieces of hardware
21 initialization of device nodes, such as retrieving common configuration
23 appropriate data, but some of them require additional handling after they have
30 Those additional configuration tasks usually depend on the type of the hardware
32 basis of the device node's hardware ID (HID). They are performed by objects
42 where ids is the list of IDs of device nodes the given handler is supposed to
[all …]
|
| /linux-4.4.14/Documentation/frv/ |
| D | README.txt | 6 port of Linux.
12 A description of the basic features inherent in this architecture port.
17 A summary of the configuration options particular to this architecture.
22 A description of how to boot the kernel image and a summary of the kernel
28 A description of how to debug the kernel using GDB attached by serial
29 port, and a summary of the services available.
34 A description of the virtual and physical memory layout used in the
46 A description of the CPU clock scaling interface.
51 A description of how the FR-V kernel's atomic operations work.
|
| /linux-4.4.14/Documentation/timers/ |
| D | hrtimers.txt | 8 (kernel/timers.c), why do we need two timer subsystems? After a lot of
18 - the forced handling of low-resolution and high-resolution timers in
19 the same way leads to a lot of compromises, macro magic and #ifdef
29 - the unpredictable [O(N)] overhead of cascading leads to delays which
30 necessitate a more complex handling of high resolution timers, which
32 timing inaccuracies. Cascading is a fundamental property of the timer
34 degrading other portions of the timers.c code in an unacceptable way.
36 - the implementation of the current posix-timer subsystem on top of
37 the timer wheel has already introduced a quite complex handling of
38 the required readjusting of absolute CLOCK_REALTIME timers at
[all …]
|
| D | highres.txt | 4 Further information can be found in the paper of the OLS 2006 talk "hrtimers
5 and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can
14 design of the Linux time(r) system before hrtimers and other building blocks
32 The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of
39 - independent of ticks (the processing is based on nanoseconds)
45 John Stultz's Generic Time Of Day (GTOD) framework moves a large portion of
46 code out of the architecture-specific areas into a generic management
48 specific portion is reduced to the low level hardware details of the clock
72 period defined at compile time. The setup and selection of the event device
75 makes it extremely difficult to change the configuration of the system to use
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/display/exynos/ |
| D | exynos_mixer.txt | 4 - compatible: value should be one of the following:
11 - reg: physical base address of the mixer and length of memory mapped
14 - clocks: list of clock IDs from SoC clock driver.
15 a) mixer: Gate of Mixer IP bus clock.
16 b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of
18 c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi.
|
| D | exynos_hdmi.txt | 9 - reg: physical base address of the hdmi and length of memory mapped
13 a) phandle of the gpio controller node.
16 - clocks: list of clock IDs from SoC clock driver.
17 a) hdmi: Gate of HDMI IP bus clock.
18 b) sclk_hdmi: Gate of HDMI special clock.
19 c) sclk_pixel: Pixel special clock, one of the two possible inputs of
21 d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
|
| /linux-4.4.14/Documentation/ABI/ |
| D | README | 2 userspace, and the relative stability of these interfaces. Due to the
3 everchanging nature of Linux, and the differing maturity levels, these
6 We have four different levels of ABI stability, as shown by the four
8 of stability according to the rules described below.
10 The different levels of stability are:
22 as the main development of this interface has been completed.
27 aware of changes that can occur before these interfaces move to
29 strongly encouraged to add their name to the description of
31 notify them if any changes occur (see the description of the
32 layout of the files below for details on how to do this.)
[all …]
|
| /linux-4.4.14/fs/cramfs/ |
| D | README | 23 null-padded to a multiple of 4 bytes.
25 The order of inode traversal is described as "width-first" (not to be
26 confused with breadth-first); i.e. like depth-first but listing all of
38 regular file of non-zero st_size.
44 padding to multiple of 4 bytes
46 The i'th <block_pointer> for a file stores the byte offset of the
47 *end* of the i'th <block> (i.e. one past the last byte, which is the
48 same as the start of the (i+1)'th <block> if there is one). The first
52 The order of <file_data>'s is a depth-first descent of the directory
57 <block>: The i'th <block> is the output of zlib's compress function
[all …]
|
| /linux-4.4.14/Documentation/video4linux/ |
| D | videobuf | 3 Current as of 2.6.33
5 The videobuf layer functions as a sort of glue layer between a V4L2 driver
6 and user space. It handles the allocation and management of buffers for
7 the storage of video frames. There is a set of functions which can be used
8 to implement many of the standard POSIX I/O system calls, including read(),
9 poll(), and, happily, mmap(). Another set of functions can be used to
10 implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
13 author, but the payback comes in the form of reduced code in the driver and
14 a consistent implementation of the V4L2 user-space API.
18 Not all video devices use the same kind of buffers. In fact, there are (at
[all …]
|
| D | cpia2_overview.txt | 1 Programmer's View of Cpia2
4 division of ST Microelectronics). There are two versions. The first is the
5 STV0672, which is capable of up to 30 frames per second (fps) in frame sizes
12 running two different versions of firmware. The 672 runs the VP4 video
15 header files are marked with VP4 or VP5 as part of the symbol name.
17 The cameras appear externally as three sets of registers. Setting register
20 try to make note of all of these cases.
29 compressed as Motion JPEG (JPEGA). The VC controls all of the compression
31 of these registers and the possible values for most of them.
35 of contiguous registers. Random mode reads or writes random registers with
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/c6x/ |
| D | dscr.txt | 4 TI C6X SoCs contain a region of miscellaneous registers which provide various
30 SoCs which do support a given property, leaving the property out of the
35 offset of the devstat register
38 offset, start bit, and bitsize of silicon revision field
41 offset and bitmask of RMII reset field. May have multiple tuples if more
46 a lock register. Each tuple consists of the register offset, lock register
50 offset and key values of two "kick" registers used to write protect other
56 MAC addresses are contained in two registers. Each element of a MAC address
59 most significant to least. The value of these four cells is the MAC byte
60 index (1-6) of the byte within the register. A value of 0 means the byte
[all …]
|
| /linux-4.4.14/drivers/staging/speakup/ |
| D | spkguide.txt | 14 under the terms of the GNU Free Documentation License, Version 1.2 or
17 copy of the license is included in the section entitled "GNU Free
22 The purpose of this document is to familiarize users with the user
25 http://linux-speakup.org/. Speakup is a set of patches to the standard
26 Linux kernel source tree. It can be built as a series of modules, or as
27 a part of a monolithic kernel. These details are beyond the scope of
28 this manual, but the user may need to be aware of the module
30 Speakup. If Speakup is built as a part of a monolithic kernel, and the
35 of its kernel, you will be able, as a blind person, to install Linux
37 are beyond the scope of this manual, but the user should be aware of
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/usb/ |
| D | samsung-hsotg.txt | 5 It gives functionality of OTG-compliant USB 2.0 host and device with
18 interrupt signal of the HSOTG block is routed,
19 - interrupts: specifier of interrupt signal of interrupt controller,
20 according to bindings of interrupt controller,
21 - clocks: contains an array of clock specifiers:
23 - clock-names: contains array of clock names:
25 - vusb_d-supply: phandle to voltage regulator of digital section,
26 - vusb_a-supply: phandle to voltage regulator of analog section.
|
| D | ci-hdrc-usb2.txt | 4 - compatible: should be one of:
10 - reg: base address and length of the registers
14 - phy_type: the type of the phy connected to the core. Should be one
15 of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
17 - dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
21 - fsl,usbphy: phandle of usb phy that connects to the port. Use "phys" instead.
35 spec for meaning of each value. If this property is not existed, it
38 (4 bytes), This register represents the maximum length of a the burst
40 bus, the value of this property will only take effect if property
42 default of the hardware implementation will be used.
[all …]
|
| /linux-4.4.14/Documentation/fb/ |
| D | udlfb.txt | 8 pairing that with a hardware framebuffer (16MB) on the other end of the
13 result with a local shadow of the remote hardware framebuffer to identify
14 the minimal set of pixels that have changed; and compresses and sends those
17 Because of the efficiency of bulk transfers and a protocol on top that
25 Advantages of USB graphics in general:
27 * Ability to add a nearly arbitrary number of displays to any USB 2.0
28 capable system. On Linux, number of displays is limited by fbdev interface
32 Advantages of supporting DisplayLink chips with kernel framebuffer interface:
34 * The actual hardware functionality of DisplayLink chips matches nearly
45 In the case of USB graphics, it is just an allocated (virtual) buffer.
[all …]
|
| /linux-4.4.14/Documentation/thermal/ |
| D | sysfs-api.txt | 13 The generic thermal sysfs provides a set of interfaces for thermal zone
15 with the thermal management solution and to be a part of it.
19 This solution is platform independent and any type of thermal zone devices
20 and cooling devices should be able to make use of the infrastructure.
22 The main task of the thermal sysfs driver is to expose thermal zone attributes
45 trips: the total number of trip points this thermal zone supports.
51 .get_temp: get the current temperature of the thermal zone.
52 .get_mode: get the current mode (enabled/disabled) of the thermal zone.
55 so that user applications can take charge of thermal management.
56 .set_mode: set the mode (enabled/disabled) of the thermal zone.
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/regulator/ |
| D | max8997-regulator.txt | 7 describes the bindings for 'pmic' sub-block of max8997.
11 - reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
13 - max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
17 - max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
21 - max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
25 [1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
30 If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
35 - interrupt-parent: Specifies the phandle of the interrupt controller to which
44 Additional properties required if either of the optional properties are used:
46 multiple bucks, changing the voltage value of one of the bucks may affect
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/iommu/ |
| D | arm,smmu.txt | 3 ARM SoCs may contain an implementation of the ARM System Memory
5 of address translation to bus masters external to the CPU.
12 - compatible : Should be one of:
21 version of the architecture implemented.
23 - reg : Base address and size of the SMMU.
25 - #global-interrupts : The number of global interrupts exposed by the
31 specified in order of their indexing by the SMMU.
34 interrupt per context bank. In the case of a single,
37 - mmu-masters : A list of phandles to device nodes representing bus
41 "#stream-id-cells" property, indicating the number of
[all …]
|
| /linux-4.4.14/Documentation/blockdev/ |
| D | zram.txt | 9 good amounts of memory savings. Some of the usecases include /tmp storage,
29 Following shows a typical sequence of steps for using zram.
33 For the sake of simplicity we skip error checking parts in most of the
36 zram sysfs attributes always return negative values in case of errors.
37 The list of possible return codes:
61 2) Set max number of compression streams
78 the value of max_comp_streams because single stream compression backend
110 There is little point creating a zram of greater than twice the size of memory
111 since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
112 size of the disk when not in use so a huge zram is wasteful.
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/clock/ |
| D | silabs,si5351.txt | 9 3 output clocks are accessible. The internal structure of the clock
15 - compatible: shall be one of "silabs,si5351{a,a-msop,b,c}".
18 - clocks: from common clock binding; list of parent clock
26 - silabs,pll-source: pair of (number, source) for each pll. Allows
27 to overwrite clock source of pll A (number=0) or B (number=1).
31 Each of the clock outputs can be overwritten individually by
36 - reg: number of clock output.
39 - silabs,clock-source: source clock of the output divider stage N, shall be
44 - silabs,drive-strength: output drive strength in mA, shall be one of {2,4,6,8}.
45 - silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
[all …]
|
| /linux-4.4.14/Documentation/virtual/kvm/ |
| D | timekeeping.txt | 16 One of the most complicated parts of the X86 platform, and specifically,
17 the virtualization of this platform is the plethora of timing devices available
18 and the complexity of emulating those devices. In addition, virtualization of
19 time introduces a new set of challenges because it introduces a multiplexed
20 division of time beyond the control of the guest CPU.
23 present some of the problems which arise and solutions available, giving
24 specific recommendations for certain classes of KVM guests.
26 The purpose of this document is to collect data and information relevant to
40 One of the first timer devices available is the programmable interrupt timer,
46 speaker. Now the PIT is typically integrated as part of an emulated chipset
[all …]
|
| D | msr.txt | 5 KVM makes use of some custom MSRs to service some requests.
18 data: 4-byte alignment physical address of a memory area which must be
19 in guest RAM. This memory is expected to hold a copy of the following
29 guaranteed to update this data at the moment of MSR write.
37 sec: number of seconds for wallclock at time of boot.
39 nsec: number of nanoseconds for wallclock at time of boot.
44 Note that although MSRs are per-CPU entities, the effect of this
47 Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid
52 data: 4-byte aligned physical address of a memory area which must be in
54 a copy of the following structure:
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/power_supply/ |
| D | charger-manager.txt | 7 - cm-num-chargers : number of chargers
8 - cm-chargers : name of chargers
9 - cm-fuel-gauge : name of battery fuel gauge
11 - cm-regulator-name : name of charger regulator
13 - cm-cable-name : name of charger cable
14 - cm-cable-extcon : name of extcon dev
15 (optional) - cm-cable-min : minimum current of cable
16 (optional) - cm-cable-max : maximum current of cable
24 - cm-thermal-zone : name of external thermometer's thermal zone
26 -cold : critical cold temperature of battery for charging
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/phy/ |
| D | apm-xgene-phy.txt | 4 PHY (pair of lanes) has its own node.
10 the mode of the PHY. Possible values are 0 (SATA),
17 - apm,tx-eye-tuning : Manual control to fine tune the capture of the serial
19 Two set of 3-tuple setting for each (up to 3)
21 127 in unit of one bit period. Default is 10.
25 Two set of 3-tuple setting for each (up to 3)
28 gain control. Two set of 3-tuple setting for each
30 between 0 to 31 in unit of dB. Default is 3.
31 - apm,tx-amplitude : Amplitude control. Two set of 3-tuple setting for
33 Range is between 0 to 199500 in unit of uV.
[all …]
|
| /linux-4.4.14/Documentation/networking/mac80211_hwsim/ |
| D | README | 1 mac80211_hwsim - software simulator of 802.11 radio(s) for mac80211
5 it under the terms of the GNU General Public License version 2 as
12 arbitrary number of IEEE 802.11 radios for mac80211. It can be used to
13 test most of the mac80211 functionality and user space tools (e.g.,
15 the normal case of using real WLAN hardware. From the mac80211 view
22 of real hardware, so it is easy to generate an arbitrary test setup
25 tests regardless of regulatory rules.
29 configuration of both very simply setups (e.g., just a single access
31 hundreds of stations).
33 mac80211_hwsim works by tracking the current channel of each virtual
[all …]
|
| /linux-4.4.14/Documentation/ia64/ |
| D | efirtc.txt | 11 The purpose of this driver is to supply an API for kernel and user applications
16 driver. We describe those calls as well the design of the driver in the
22 at first, the time of day service. This is required in order to access, in a
24 to initialize the system view of the time during boot.
33 EFI uses a slightly different way of representing the time, noticeably
36 expose this new way of representing time. Instead we use something very
38 One of the reasons for doing it this way is to allow for EFI to still evolve
39 without necessarily impacting any of the user applications. The decoupling
42 The driver exposes two interfaces, one via the device file and a set of
45 As of today we don't offer a /proc/sys interface.
[all …]
|
| /linux-4.4.14/firmware/matrox/ |
| D | g200_warp.H16 | 4 * - T stands for computation of texture stage 0
5 * - T2 stands for computation of both texture stage 0 and texture stage 1
6 * - G stands for computation of triangle intensity (Gouraud interpolation)
7 * - Z stands for computation of Z buffer interpolation
8 * - S stands for computation of specular highlight
9 * - A stands for computation of the alpha channel
10 * - F stands for computation of vertex fog interpolation
|
| D | g400_warp.H16 | 4 * - T stands for computation of texture stage 0
5 * - T2 stands for computation of both texture stage 0 and texture stage 1
6 * - G stands for computation of triangle intensity (Gouraud interpolation)
7 * - Z stands for computation of Z buffer interpolation
8 * - S stands for computation of specular highlight
9 * - A stands for computation of the alpha channel
10 * - F stands for computation of vertex fog interpolation
|
| /linux-4.4.14/Documentation/devicetree/ |
| D | booting-without-of.txt | 11 Table of Contents
26 III - Required content of the device tree
44 1) Defining child nodes of an SOC
66 clarifies the fact that a lot of things are
92 "simple" insertion of properties using
97 compiler and the textural representation of
108 - Add some definitions of interrupt tree (simple/complex)
114 - Compare FSL SOC use of PCI to standard and make sure no new
123 During the development of the Linux/ppc64 kernel, and more
124 specifically, the addition of new platform types outside of the old
[all …]
|
| D | usage-model.txt | 7 This article describes how Linux uses the device tree. An overview of
15 is a description of hardware that is readable by an operating system
16 so that the operating system doesn't need to hard code details of the
20 nodes may have an arbitrary number of named properties encapsulating
22 links from one node to another outside of the natural tree structure.
24 Conceptually, a common set of usage conventions, called 'bindings',
30 maximize use of existing support code, but since property and node
33 however, of creating a new binding without first doing some homework
41 The DT was originally created by Open Firmware as part of the
44 Device Tree to discover the topology of the hardware at runtime, and
[all …]
|
| /linux-4.4.14/drivers/net/can/sja1000/ |
| D | sja1000_platform.c | 99 static void sp_populate_of(struct sja1000_priv *priv, struct device_node *of) in sp_populate_of() argument
104 err = of_property_read_u32(of, "reg-io-width", &prop); in sp_populate_of()
123 err = of_property_read_u32(of, "nxp,external-clock-frequency", &prop); in sp_populate_of()
129 err = of_property_read_u32(of, "nxp,tx-output-mode", &prop); in sp_populate_of()
135 err = of_property_read_u32(of, "nxp,tx-output-config", &prop); in sp_populate_of()
141 err = of_property_read_u32(of, "nxp,clock-out-frequency", &prop); in sp_populate_of()
153 if (!of_property_read_bool(of, "nxp,no-comparator-bypass")) in sp_populate_of()
165 struct device_node *of = pdev->dev.of_node; in sp_probe() local
168 if (!pdata && !of) { in sp_probe()
186 if (of) in sp_probe()
[all …]
|
| /linux-4.4.14/drivers/staging/most/Documentation/ABI/ |
| D | sysfs-class-most.txt | 6 List of AIMs that have been loaded.
14 This is used to establish a connection of a channel and the
32 List of attached MOST interfaces.
41 location of the device. Hardware attached via USB, for instance,
50 Indicates the type of peripheral interface the current device
59 For every channel of the device a directory is created, whose
78 Indicates the directions the current channel is capable of.
86 Indicates the number of packet buffers the current channel can
95 Indicates the number of streaming buffers the current channel can
104 Indicates the size of a packet buffer the current channel can
[all …]
|
| /linux-4.4.14/drivers/block/paride/ |
| D | Transition-notes | 4 Proof: All assignments to ps_tq_active and all scheduling of ps_tq happen
7 Consider the sequnce of these events. A can not be preceded by
11 IOW, the sequence is A?(BA|BC|B)*. OTOH, number of B can not exceed
12 the sum of numbers of A and C, since each call of ps_tq_int() is
13 the result of ps_tq execution. Therefore, the sequence starts with
16 since at any time number of B can not exceed the number of these
17 moments which, in turn, can not exceed the number of A and C.
18 In other words, the sequence of events is (A or C set ps_tq_active to
24 * in do_pd_request1(): to calls of pi_do_claimed() and return in
26 * in next_request(): to call of do_pd_request1()
[all …]
|
| /linux-4.4.14/Documentation/video4linux/cx2341x/ |
| D | README.vbi | 2 Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data
5 This document describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data
7 hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6
11 The advantage of this format is it is very compact and that all VBI data for
14 The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is
23 'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the first
24 unsigned long denote which lines of the first field are captured. Bits 18-31 of
25 the first unsigned long and bits 0-3 of the second unsigned long are used for the
31 After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the
34 For each line the least significant 4 bits of the first byte contain the data type.
[all …]
|
| D | fw-encoder-api.txt | 16 Commences the capture of video, audio and/or VBI data. All encoding
18 continuously or until a predefined number of frames have been captured.
43 0=stop at end of GOP (generates IRQ)
46 Stream type to stop, see param[0] of API 0x81
48 Subtype, see param[1] of API 0x81
55 Assigns the transport stream ID of the encoded audio stream
82 Set video frames per second. Change occurs at start of new GOP.
127 Number of B frames between the I and P frame, plus 1.
128 For example: IBBPBBPBBPBB --> GOP size: 12, number of B frames: 2+1 = 3
129 Note that GOP size must be a multiple of (B-frames + 1).
[all …]
|
| D | README.hm12 | 2 format of a YUV frame is specific to this chip and is called HM12. 'HM' stands
12 The Y plane is divided into blocks of 16x16 pixels from left to right
15 So the first 16 bytes are the first line of the top-left block, the
16 second 16 bytes are the second line of the top-left block, etc. After
17 transmitting this block the first line of the block on the right to the
20 The UV plane is divided into blocks of 16x8 UV values going from left
23 So the first 16 bytes are the first line of the top-left block and
25 second line of 8 UV pairs of the top-left block, etc. After transmitting
26 this block the first line of the block on the right to the first block is
30 Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels.
[all …]
|
| /linux-4.4.14/Documentation/driver-model/ |
| D | binding.txt | 4 Driver binding is the process of associating a device with a device
8 structures, most of the binding can take place using common code.
14 The bus type structure contains a list of all devices that are on that bus
16 inserted into the end of this list. The bus object also contains a
17 list of all drivers of that bus type. When driver_register is called
18 for a driver, it is inserted at the end of this list. These are the
25 When a new device is added, the bus's list of drivers is iterated over
27 ID of the device must match one of the device IDs that the driver
29 Instead of trying to derive a complex state machine and matching
31 a device against the IDs of a driver. The bus returns 1 if a match was
[all …]
|
| D | overview.txt | 12 The Linux Kernel Driver Model is a unification of all the disparate driver
14 bus-specific drivers for bridges and devices by consolidating a set of data
17 Traditional driver models implemented some sort of tree-like structure
23 model includes a set of common attributes which all busses carry, and a set
24 of common callbacks, such as device discovery during bus probing, bus
27 The common device and bridge interface reflects the goals of the modern
33 buses support most of those operations.
39 Common data fields have been moved out of individual bus layers into a common
57 front of the pci_dev structure. This is to make people think about what
61 The PCI bus layer freely accesses the fields of struct device. It knows about
[all …]
|
| /linux-4.4.14/Documentation/cdrom/ |
| D | cdrom-standard.tex | 35 the widest variety of hardware devices. The reasons for this are
39 The large list of hardware devices available for the many platforms
42 The open design of the operating system, such that anybody can write a
45 There is plenty of source code around as examples of how to write a driver.
47 The openness of \linux, and the many different types of available
50 all these different devices has also allowed the behavior of each
52 This divergence of behavior has been very significant for \cdrom\
55 their drivers totally inconsistent, the writers of \linux\ \cdrom\
63 drivers should implement them. Currently (as of the \linux\ 2.1.$x$
69 different \cdrom\ interfaces were developed. Some of them had their
[all …]
|
| /linux-4.4.14/Documentation/netlabel/ |
| D | draft-ietf-cipso-ipsecurity-01.txt | 14 the CIPSO IETF Working Group. Distribution of this memo is unlimited.
17 of the Internet Engineering Task Force (IETF), its Areas, and its Working
21 Internet Drafts are draft documents valid for a maximum of six months.
28 directory to learn the current status of this or any other Internet Draft.
35 Currently the Internet Protocol includes two security options. One of
38 provides sixteen security classifications and a variable number of handling
49 for use in a variety of government and civil sector environments.
51 The small number of ESO format codes can not support all the possible
52 applications of a commercial security option. The BSO and ESO were
77 systems within a single Domain of Interpretation (DOI). A DOI is a
[all …]
|
| /linux-4.4.14/Documentation/sound/oss/ |
| D | PSS-updates | 1 This file contains notes for users of PSS sound cards who wish to use the
2 newly added features of the newest version of this driver.
4 The major enhancements present in this new revision of this driver is the
5 addition of two new module parameters that allow you to take full advantage of
14 with systems that were using previous versions of this driver. If you wish to
26 use of the newly enabled CDROM port. Like the joystick port option above,
33 setting of this parameter leaves the CDROM port disabled to maintain full
34 compatibility with systems using previous versions of this driver.
37 of the user. These options are only available if this driver is loaded as a
46 and/or CDROM port(s) of his PSS sound card. If this driver is loaded with this
[all …]
|
| /linux-4.4.14/drivers/mtd/ubi/ |
| D | Kconfig | 5 UBI is a software layer above MTD layer which admits of LVM-like
6 logical volumes on top of MTD devices, hides some complexities of
19 erase counter value and the lowest erase counter value of eraseblocks
20 of UBI devices. When this threshold is exceeded, UBI starts performing
21 wear leveling by means of moving data from eraseblock with low erase
26 However, in case of MLC NAND flashes which typically have eraseblock
28 to 128 or 256, although it does not have to be power of 2).
37 flash does not admit of bad eraseblocks (e.g. NOR flash), this value
40 NAND datasheets often specify the minimum and maximum NVM (Number of
44 (MaxNVB is basically the total count of eraseblocks on the chip).
[all …]
|
| /linux-4.4.14/Documentation/s390/ |
| D | DASD | 4 driver. It is valid for all types of DASDs and represents them to
15 in order of appearance and a minor number is reserved for any device
18 DASD driver registers all supported DASDs of your system to a minor
19 number in ascending order of the subchannel number.
22 support of the FBA and CKD architectures. For the FBA architecture
25 We performed our testing on 3380 and 3390 type disks of different
27 of the multiprise as well as a RAMAC virtual array. Disks exported by
33 accessibility of the DASD from other OSs. In a later stage we will
34 provide support of partitions, maybe VTOC oriented or using a kind of
51 disk is formatted to a blocksize of 1024 bytes. Otherwise start_unit
[all …]
|
| D | monreader.txt | 12 This item delivers a new Linux API in the form of a misc char device that is
14 collected by the *MONITOR System Service of z/VM.
28 location of the monitor DCSS with the Class E privileged CP command Q NSS MAP
29 (the values BEGPAG and ENDPAG are given in units of 4K pages).
38 guest virtual storage around the address range of the DCSS.
42 This defines two blocks of storage, the first is 140MB in size an begins at
44 resulting in a total storage of 340MB. Note that the first block should
49 Your guest virtual storage has to end below the starting address of the DCSS
51 value greater than the ending address of the DCSS.
64 to specify the name of the monitor DCSS. If the module is compiled into the
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/pci/ |
| D | ralink,rt3883-pci.txt | 9 - reg: specifies the physical base address of the controller and
10 the length of the memory mapped region.
12 - #address-cells: specifies the number of cells needed to encode an
15 - #size-cells: specifies the number of cells used to represent the size
16 of an address. The value must be 1.
23 - status: indicates the operational status of the device.
37 - #address-cells: specifies the number of cells needed to encode an
41 - #interrupt-cells: specifies the number of cells needed to encode an
47 - interrupts: specifies the interrupt source of the parent interrupt
48 controller. The format of the interrupt specifier depends on the
[all …]
|
| /linux-4.4.14/Documentation/kbuild/ |
| D | kconfig-language.txt | 4 The configuration database is a collection of configuration options
21 to determine the visibility of an entry. Any child entry is only
39 define attributes for this config option. Attributes can be the type of
48 A menu entry can have a number of attributes. Not all of them are
68 A config option can have any number of default values. If multiple
99 While normal dependencies reduce the upper limit of a symbol (see
100 below), reverse dependencies can be used to force a lower limit of
101 another symbol. The value of the current menu symbol is used as the
121 entries. Default value of "visible" is true.
124 This allows to limit the range of possible input values for int
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/crypto/ |
| D | fsl-sec4.txt | 23 SEC 4 h/w can process requests from 2 types of sources.
30 such as the P4080. The number of simultaneous dequeues the QI can make is
31 equal to the number of Descriptor Controller (DECO) engines in a particular
46 Node defines the base address of the SEC 4 block.
47 This block specifies the address range of all global
62 Definition: A standard property. Define the 'ERA' of the SEC
68 Definition: A standard property. Defines the number of cells
74 Definition: A standard property. Defines the number of cells
75 for representing the size of physical addresses in
82 address and length of the SEC4 configuration registers.
[all …]
|
| /linux-4.4.14/drivers/staging/most/Documentation/ |
| D | driver_usage.txt | 9 for the efficient and low-cost transport of control, real-time and packet
21 provides excellent Quality of Service and seamless connectivity for
23 of Automotive Grade Linux to create open source software solutions for
26 The driver consists basically of three layers. The hardware layer, the
27 core layer and the application layer. The core layer consists of the core
29 layers, the configuration of the driver, the configuration interface
31 For each of the other two layers a selection of modules is provided. These
32 modules can arbitrarily be combined to meet the needs of the desired
33 system architecture. A module of the hardware layer is referred to as an
34 HDM (hardware dependent module). Each module of this layer handles exactly
[all …]
|
| /linux-4.4.14/Documentation/hwmon/ |
| D | vexpress | 8 * "Hardware Description" sections of the Technical Reference Manuals
11 * Section "4.4.14. System Configuration registers" of the V2M-P1 TRM:
21 from a wide range of boards, each of them containing (apart of the main
22 chip/FPGA) a number of microcontrollers responsible for platform
24 board and its environment by a number of internal and external sensors,
26 temperature and power usage. Some of them also calculate consumed energy
33 Tree passed to the kernel. Details of the DT binding for them can be found
|
| /linux-4.4.14/Documentation/devicetree/bindings/media/ |
| D | video-interfaces.txt | 6 Video data pipelines usually consist of external devices, e.g. camera sensors,
11 blocks. External devices are represented as child nodes of their respective
15 Configuration of a port depends on other devices participating in the data
34 bus, an 'endpoint' child node must be provided for each of them. If more than
45 phandles. An endpoint subnode of a device contains all properties needed for
46 configuration of this device for data exchange with other device. In most
52 where supported by a device. For example, in case where a data interface of
66 - #address-cells : number of cells required to define port/endpoint
73 - remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
78 mode the data source device is also the source of the synchronization signals.
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/mfd/ |
| D | max8998.txt | 11 The PMIC sub-block contains a number of voltage and current regulators,
17 - compatible: Should be one of the following:
20 - reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
23 - interrupt-parent: Specifies the phandle of the interrupt controller to which
29 for buck 1 dvs. The format of the gpio specifier depends on the gpio
32 for buck 2 dvs. The format of the gpio specifier depends on the gpio
35 the possible 4 options selectable by the dvs gpios. The value of this
36 property should be 0, 1, 2 or 3. If not specified or out of range,
37 a default value of 0 is taken.
39 the possible 2 options selectable by the dvs gpios. The value of this
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/reserved-memory/ |
| D | reserved-memory.txt | 21 Each child of the reserved-memory node specifies one or more regions of
23 specify a specific range of reserved memory, or a 'size' property with
24 optional constraints to request a dynamically allocated block of memory.
27 reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
37 - Size in bytes of memory to reserve.
39 - Address boundary for alignment of allocation.
41 - Specifies regions of memory that are
50 - shared-dma-pool: This indicates a region of memory meant to be
51 used as a shared pool of DMA buffers for a set of devices. It can
57 of the region as part of its standard mapping of system memory,
[all …]
|
| /linux-4.4.14/Documentation/devicetree/bindings/arm/ |
| D | l2cc.txt | 4 implementations of the L2 cache controller with compatible programming models.
5 Some of the properties that are just prefixed "cache-*" are taken from section
6 3.7.3 of the ePAPR v1.1 specification which can be found at:
13 - compatible : should be one of:
31 - reg : Physical base address and size of cache controller's memory mapped
36 - arm,data-latency : Cycles of latency for Data RAM accesses. Specifies 3 cells of
38 without setup latency control should use a value of 0.
39 - arm,tag-latency : Cycles of latency for Tag RAM accesses. Specifies 3 cells of
43 - arm,dirty-latency : Cycles of latency for Dirty RAMs. This is a single cell.
44 - arm,filter-ranges : <start length> Starting address and length of window to
[all …]
|
| /linux-4.4.14/Documentation/fmc/ |
| D | mezzanine.txt | 5 gateware. As such, it is expected to be independent of the carrier
6 being used: it will perform I/O accesses only by means of
9 The matching between device and driver is based on the content of the
15 FPGA registers, by means of the `fpga_base' field of the device
18 by means of Etherbone), the `fpga_base' pointer will be NULL.
26 which is the current carrier and make use of the `carrier_data'
30 their own carriers. An example use of carrier names is in GPIO setup
41 which it is able to drive. This is usually done by means of a device
42 table, but in FMC we can match hardware based either on the contents of
44 Therefore, we have two tables of identifiers.
[all …]
|
| /linux-4.4.14/Documentation/m68k/ |
| D | kernel-options.txt | 24 1) Overview of the Kernel's Option Processing
27 The kernel knows three kinds of options on its command line:
33 To which of these classes an argument belongs is determined as
37 argument contains an '=', it is of class 2, and the definition is put
42 the version mentioned at the start of this file. Later revisions may
45 In general, the value (the part after the '=') of an option is a
46 list of values separated by commas. The interpretation of these values
47 is up to the driver that "owns" the option. This association of
71 combination of two or three letters, followed by a decimal number.
85 partition number. Internally, the value of the number is just
[all …]
|
| /linux-4.4.14/Documentation/usb/ |
| D | usbmon.txt | 4 used to collect traces of I/O on the USB bus. This function is analogous
98 of '1t' format.
104 Any text format data consists of a stream of events, such as URB submission,
106 of whitespace separated words. The number or position of words may depend
107 on the event type, but there is a set of words, common for all types.
109 Here is the list of words, from left to right:
112 of the URB structure in hexadecimal, but can be a sequence number or any
119 - Event Type. This type refers to the format of the event, not URB type.
122 - "Address" word (formerly a "pipe"). It consists of four fields, separated by
130 have leading zeros, for the sake of human readers.
[all …]
|
| /linux-4.4.14/Documentation/PCI/ |
| D | MSI-HOWTO.txt | 12 This guide describes the basics of Message Signaled Interrupts (MSIs),
13 the advantages of using MSI over traditional interrupt mechanisms, how
81 Most of the hard work is done for the driver in the PCI layer. It simply
90 of how many MSIs the device supports. The device is switched from
95 different from the vector of a pin-based interrupt.
101 This function allows a device driver to request any number of MSI
104 If this function returns a positive number it indicates the number of
107 updates dev->irq to be the lowest of the new interrupts assigned to it.
110 number of successfully allocated MSI interrupts to further allocate
119 from the vector of a pin-based interrupt.
[all …]
|