Searched full:of (Results 1 – 25 of 4406) sorted by relevance
12345678910>>...177
| /Documentation/sound/designs/ |
| D | tracepoints.rst | 12 This subsystem includes two categories of tracepoints; for state of PCM buffer
13 and for processing of PCM hardware parameters. These tracepoints are available
18 Tracepoints for state of PCM buffer
24 Tracepoints for processing of PCM hardware parameters
30 In a design of ALSA PCM core, data transmission is abstracted as PCM substream.
34 interaction between applications and ALSA PCM core. Once decided, runtime of
38 structure includes several types of parameters. Applications set preferable
41 set of parameters. The latter is used for an actual decision of the parameters.
49 Configurable. This type of parameter is described in
50 struct snd_mask and represent mask values. As of PCM protocol
[all …]
|
| /Documentation/process/ |
| D | code-of-conduct-interpretation.rst | 3 Linux Kernel Contributor Covenant Code of Conduct Interpretation
7 provide a set of rules for almost any open source community. Every
9 Because of this, this document describes how we in the Linux kernel
14 to "traditional" ways of developing software. Your contributions and
19 the best possible solution for the overall success of Linux. This
22 quality of submission and eventual result to ever decrease.
27 The Code of Conduct uses the term "maintainers" numerous times. In the
35 The Code of Conduct mentions rights and responsibilities for
43 behave in the parts of the community where they are active. That
44 responsibility is upon all of us, and ultimately the Code of Conduct
[all …]
|
| D | 1.Intro.rst | 9 The rest of this section covers the scope of the kernel development process
10 and the kinds of frustrations that developers and their employers can
14 influence the direction of kernel development. Code contributed to the
18 release cycle, and the mechanics of the merge window. The various phases in
20 discussion of tools and mailing lists. Developers wanting to get started
29 patches are covered, and there is an introduction to some of the tools
32 :ref:`development_posting` talks about the process of posting patches for
40 of the development process; this section offers a number of tips on how to
44 :ref:`development_advancedtopics` introduces a couple of "advanced" topics:
53 The Linux kernel, at over 8 million lines of code and well over 1000
[all …]
|
| D | 4.Coding.rst | 7 process, the proof of any kernel development project is in the resulting
9 (or not) into the mainline tree. So it is the quality of this code which
10 will determine the ultimate success of the project.
13 number of ways in which kernel developers can go wrong. Then the focus
25 :ref:`Documentation/process/coding-style.rst <codingstyle>`. For much of
27 advisory. As a result, there is a substantial amount of code in the kernel
28 which does not meet the coding style guidelines. The presence of that code
31 The first of these is to believe that the kernel coding standards do not
32 matter and are not enforced. The truth of the matter is that adding new
36 requires some uniformity of code to make it possible for developers to
[all …]
|
| D | code-of-conduct.rst | 3 Contributor Covenant Code of Conduct
9 In the interest of fostering an open and welcoming environment, we as
11 our community a harassment-free experience for everyone, regardless of age, body
13 expression, level of experience, education, socio-economic status, nationality,
19 Examples of behavior that contributes to creating a positive environment
23 * Being respectful of differing viewpoints and experiences
29 Examples of unacceptable behavior by participants include:
31 * The use of sexualized language or imagery and unwelcome sexual attention or
44 Maintainers are responsible for clarifying the standards of acceptable behavior
46 any instances of unacceptable behavior.
[all …]
|
| /Documentation/admin-guide/ |
| D | iostats.rst | 16 is mounted on ``/sys``, although of course it may be mounted anywhere.
20 Here are examples of these different formats::
38 a choice of ``cat /sys/block/hda/stat`` or ``grep 'hda ' /proc/diskstats``.
40 The advantage of one over the other is that the sysfs choice works well
41 if you are watching a known, small set of disks. ``/proc/diskstats`` may
42 be a better choice if you are watching a large number of disks because
43 you'll avoid the overhead of 50, 100, or 500 or more opens/closes with
44 each snapshot of your disk statistics.
47 the above example, the first field of statistics would be 446216.
51 minor device numbers, and device name. Each of these formats provides
[all …]
|
| /Documentation/devicetree/bindings/net/ |
| D | micrel-ksz90x1.txt | 4 to clock delays. You can specify clock delay values in the PHY OF
6 also be added to an Ethernet OF device node.
20 change the driver now because of the many existing device trees that have
21 been created using values that go up in increments of 200.
23 The following table shows the actual skew delay you will get for each of the
48 - rxc-skew-ps : Skew control of RXC pad
49 - rxdv-skew-ps : Skew control of RX CTL pad
50 - txc-skew-ps : Skew control of TXC pad
51 - txen-skew-ps : Skew control of TX CTL pad
52 - rxd0-skew-ps : Skew control of RX data 0 pad
[all …]
|
| /Documentation/userspace-api/media/ |
| D | fdl-appendix.rst | 15 The purpose of this License is to make a manual, textbook, or other
16 written document “free” in the sense of freedom: to assure everyone the
23 This License is a kind of “copyleft”, which means that derivative works
24 of the document must themselves be free in the same sense. It
32 used for any textual work, regardless of subject matter or whether it is
47 terms of this License. The “Document”, below, refers to any such manual
48 or work. Any member of the public is a licensee, and is addressed as
54 A “Modified Version” of the Document means any work containing the
55 Document or a portion of it, either copied verbatim, or with
61 A “Secondary Section” is a named appendix or a front-matter section of
[all …]
|
| /Documentation/devicetree/bindings/i2c/ |
| D | renesas,i2c.txt | 5 "renesas,i2c-r8a7742" if the device is a part of a R8A7742 SoC.
6 "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC.
7 "renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC.
8 "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC.
9 "renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC.
10 "renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC.
11 "renesas,i2c-r8a774b1" if the device is a part of a R8A774B1 SoC.
12 "renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC.
13 "renesas,i2c-r8a774e1" if the device is a part of a R8A774E1 SoC.
14 "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC.
[all …]
|
| /Documentation/scheduler/ |
| D | sched-stats.rst | 5 Version 15 of schedstats dropped counters for some sched_yield:
9 Version 14 of schedstats includes support for sched_domains, which hit the
16 In version 14 of schedstat, there is at least one level of domain
21 sometimes balancing only between pairs of cpus. At this time, there
27 of these will need to start with a baseline observation and then calculate
29 which does this for many of the fields is available at
43 1) # of times sched_yield() was called
49 3) # of times schedule() was called
50 4) # of times schedule() left the processor idle
54 5) # of times try_to_wake_up() was called
[all …]
|
| /Documentation/powerpc/ |
| D | associativity.rst | 5 Associativity represents the groupings of the various platform resources into
6 domains of substantially similar mean performance relative to resources outside
7 of that domain. Resources subsets of a given domain that exhibit better
9 are represented as being members of a sub-grouping domain. This performance
10 characteristic is presented in terms of NUMA node distance within the Linux kernel.
13 PAPR interface currently supports different ways of communicating these resource
17 Hypervisor indicates the type/form of associativity used via "ibm,architecture-vec-5 property".
18 Bit 0 of byte 5 in the "ibm,architecture-vec-5" property indicates usage of Form 0 or Form 1.
19 A value of 1 indicates the usage of Form 1 associativity. For Form 2 associativity
20 bit 2 of byte 5 in the "ibm,architecture-vec-5" property is used.
[all …]
|
| /Documentation/input/ |
| D | multi-touch-protocol.rst | 13 In order to utilize the full power of the new multi-touch and multi-user
17 drivers to report details for an arbitrary number of contacts.
19 The protocol is divided into two types, depending on the capabilities of the
22 devices capable of tracking identifiable contacts (type B), the protocol
32 Contact details are sent sequentially as separate packets of ABS_MT
33 events. Only the ABS_MT events are recognized as part of a contact
35 applications, the MT protocol can be implemented on top of the ST protocol
39 input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT
44 input_mt_slot(), with a slot as argument, at the beginning of each packet.
46 prepare for updates of the given slot.
[all …]
|
| /Documentation/admin-guide/mm/ |
| D | hugetlbpage.rst | 10 The intent of this file is to give a brief summary of hugetlbpage support in
11 the Linux kernel. This support is built on top of multiple page size support
15 256M and ppc64 supports 4K and 16M. A TLB is a cache of virtual-to-physical
17 Operating systems try to make best use of limited number of TLB resources.
29 The ``/proc/meminfo`` file provides information about the total number of
31 default huge page size and information about the number of free, reserved
32 and surplus huge pages in the pool of huge pages of default size.
34 size of the arguments to system calls that map huge page regions.
36 The output of ``cat /proc/meminfo`` will include lines like::
48 is the size of the pool of huge pages.
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | intel_idle.rst | 16 ``intel_idle`` is a part of the
19 Nehalem and later generations of Intel processors, but the level of support for
27 logical CPU executing it is idle and so it may be possible to put some of the
29 arguments (passed in the ``EAX`` and ``ECX`` registers of the target CPU), the
30 first of which, referred to as a *hint*, can be used by the processor to
42 .. _intel-idle-enumeration-of-states:
44 Enumeration of Idle States
50 as C-states (in the ACPI terminology) or idle states. The list of meaningful
51 ``MWAIT`` hint values and idle states (i.e. low-power configurations of the
53 depend on the configuration of the platform.
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | group_descr.rst | 6 Each block group on the filesystem has one of these descriptors
9 standard configuration is for each block group to contain a full copy of
13 Notice how the group descriptor records the location of both bitmaps and
18 of the groups' bitmaps and inode tables into one long run in the first
19 group of the flex group.
36 checksum is the crc16 of the FS UUID, the group number, and the group
38 checksum is the lower 16 bits of the checksum of the FS UUID, the group
56 - Lower 32-bits of location of block bitmap.
60 - Lower 32-bits of location of inode bitmap.
64 - Lower 32-bits of location of inode table.
[all …]
|
| /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 …]
|
| /Documentation/security/ |
| D | credentials.rst | 18 userspace programs. Linux has a variety of actionable objects, including:
28 As a part of the description of all these objects there is a set of
29 credentials. What's in the set depends on the type of object.
33 Amongst the credentials of most objects, there will be a subset that
34 indicates the ownership of that object. This is used for resource
42 Also amongst the credentials of those objects, there will be a subset that
43 indicates the 'objective context' of that object. This may or may not be
47 The objective context is used as part of the security calculation that is
54 Most of the objects in the system are inactive: they don't act on other
65 A subject has an additional interpretation of its credentials. A subset
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | statistics.rst | 5 Device Mapper supports the collection of I/O statistics on user-defined
6 regions of a DM device. If no regions are defined no statistics are
14 The I/O statistics counters for each step-sized area of a region are
19 histogram of latencies. All these counters may be accessed by sending
33 The creation of DM statistics will allocate memory via kmalloc or
34 fallback to using vmalloc space. At most, 1/4 of the overall system
50 a range of <length> 512-byte sectors
59 number of areas.
62 The number of optional arguments
69 instead of the "jiffies" variable. When this argument is
[all …]
|
| D | dm-zoned.rst | 9 doing raw block device accesses) the sequential write constraints of
14 For a more detailed description of the zoned block device models and
38 write accesses to the sequential zones of a zoned block device.
43 placed in front of the zones from the zoned block device and will be handled
46 The zones of the device(s) are separated into 2 types:
51 2) Data zones: all remaining zones, the vast majority of which will be
53 zones of the device may be used also for buffering user random writes.
58 dm-zoned exposes a logical device with a sector size of 4096 bytes,
59 irrespective of the physical sector size of the backend zoned block
60 device being used. This allows reducing the amount of metadata needed to
[all …]
|
| D | verity.rst | 5 Device-Mapper's "verity" target provides transparent integrity checking of
21 This is the type of the on-disk hash format.
25 the rest of the block is padded with zeroes.
29 padded with zeroes to the power of two.
32 This is the device containing data, the integrity of which needs to be
47 The size of a hash block in bytes.
50 The number of data blocks on the data device. Additional blocks are
55 This is the offset, in <hash_block_size>-blocks, from the start of hash_dev
56 to the root block of the hash tree.
60 be the name of the algorithm, like "sha1".
[all …]
|
| /Documentation/ABI/testing/ |
| D | configfs-most | 27 configure number of buffers used for this
31 configure type of data that will travel over
43 configure the number of packets that will be
49 name of the device the link is to be attached to
52 name of the channel the link is to be attached to
59 creation of the link. In case of speculative
82 configure number of buffers used for this
86 configure type of data that will travel over
98 configure the number of packets that will be
104 name of the device the link is to be attached to
[all …]
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | blkio-controller.rst | 8 a need of various kinds of IO control policies (like proportional BW, max BW)
39 Above will put a limit of 1MB/second on reads happening for root group
44 # dd iflag=direct if=/mnt/common/zerofile of=/dev/null bs=4K count=1024
92 Details of cgroup files
97 - Specifies per cgroup weight. This is default weight of the group
100 Currently allowed range of weights is from 10 to 1000.
104 These rules override the default value of group weight as specified
135 two fields specify the major and minor number of the device and
140 - number of sectors transferred to/from disk by the group. First
141 two fields specify the major and minor number of the device and
[all …]
|
| /Documentation/devicetree/bindings/gpio/ |
| D | nvidia,tegra186-gpio.txt | 9 The Tegra186 GPIO controller allows software to set the IO direction of, and
10 read/write the value of, numerous GPIO signals. Routing of GPIO signals to
11 package balls is under the control of a separate pin controller HW block. Two
12 major sets of registers exist:
14 a) Security registers, which allow configuration of allowed access to the GPIO
15 register set. These registers exist in a single contiguous block of physical
16 address space. The size of this block, and the security features available,
19 Access to this set of registers is not necessary in all circumstances. Code
24 b) GPIO registers, which allow manipulation of the GPIO signals. In some GPIO
26 address space, each of which access the same underlying state. See the hardware
[all …]
|
| /Documentation/pcmcia/ |
| D | driver-changes.rst | 7 * pcmcia_loop_config() and autoconfiguration (as of 2.6.36)
20 * pcmcia_request_configuration -> pcmcia_enable_device (as of 2.6.36)
26 * pcmcia_request_window changes (as of 2.6.36)
27 Instead of win_req_t, drivers are now requested to fill out
33 * pcmcia_request_io changes (as of 2.6.36)
34 Instead of io_req_t, drivers are now requested to fill out
40 * No dev_info_t, no cs_types.h (as of 2.6.36)
45 * No dev_node_t (as of 2.6.35)
48 * New IRQ request rules (as of 2.6.35)
49 Instead of the old pcmcia_request_irq() interface, drivers may now
[all …]
|
| /Documentation/gpu/ |
| D | msm-crash-dump.rst | 12 and all the contents of a section will be indented two spaces from the header.
13 Each section might have multiple array entries the start of which is designated
35 ID of the GPU that generated the crash formatted as
39 The current value of RBBM_STATUS which shows what top level GPU
40 components are in use at the time of crash.
43 Section containing the contents of each ringbuffer. Each ringbuffer is
50 GPU address of the ringbuffer.
65 Maximum size of the ringbuffer programmed in the hardware.
68 The contents of the ring encoded as ascii85. Only the used
69 portions of the ring will be printed.
[all …]
|
12345678910>>...177