| /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/i2c/ |
| D | smbus-protocol.rst | 5 The following is a summary of the SMBus protocol. It applies to
11 which is a subset from the I2C protocol. Fortunately, many devices use
14 If you write a driver for some I2C device, please try to use the SMBus
21 Below is a list of SMBus protocol operations, and the functions executing
23 don't match these function names. For some of the operations which pass a
25 a different protocol operation entirely.
27 Each transaction type corresponds to a functionality flag. Before calling a
28 transaction function, a device driver should always check (just once) for
41 A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit
43 get a 10 bit I2C address.
[all …]
|
| D | i2c-protocol.rst | 14 A, NA (1 bit) Acknowledge (ACK) and Not Acknowledge (NACK) bit
16 get a 10 bit I2C address.
17 Comm (8 bits) Command byte, a data byte which often selects a register on
19 Data (8 bits) A plain data byte. Sometimes, I write DataLow, DataHigh
21 Count (8 bits) A data byte containing the length of a block operation.
33 S Addr Wr [A] Data [A] Data [A] ... [A] Data [A] P
41 S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
49 They are just like the above transactions, but instead of a stop
50 condition P a start condition S is sent and the transaction continues.
51 An example of a byte read, followed by a byte write::
[all …]
|
| /Documentation/filesystems/nfs/ |
| D | exporting.rst | 9 All filesystem operations require a dentry (or two) as a starting
10 point. Local applications have a reference-counted hold on suitable
12 applications that access a filesystem via a remote filesystem protocol
13 such as NFS may not be able to hold such a reference, and so need a
14 different way to refer to a particular dentry. As the alternative
23 This byte string will be called a "filehandle fragment" as it
26 A filesystem which supports the mapping between filehandle fragments
34 The dcache normally contains a proper prefix of any given filesystem
38 maintained easily (by each object maintaining a reference count on
41 However when objects are included into the dcache by interpreting a
[all …]
|
| D | rpc-cache.rst | 5 This document gives a brief introduction to the caching
13 a wide variety of values to be caches.
15 There are a number of caches that are similar in structure though
16 quite possibly very different in content and use. There is a corpus
42 Creating a Cache
45 - A cache needs a datum to store. This is in the form of a
46 structure definition that must contain a struct cache_head
48 It will also contain a key and some content.
51 - A cache needs a "cache_detail" structure that
60 a pointer to the cache_detail embedded within the
[all …]
|
| /Documentation/filesystems/ |
| D | sharedsubtree.rst | 23 A process wants to clone its own namespace, but still wants to access the CD
36 a. shared mount
42 2a) A shared mount can be replicated to as many mountpoints and all the
47 Let's say /mnt has a mount that is shared::
65 a b c
68 a b c
70 Now let's say we mount a device at /tmp/a::
72 # mount /dev/sd0 /tmp/a
74 #ls /tmp/a
77 #ls /mnt/a
[all …]
|
| /Documentation/maintainer/ |
| D | rebasing-and-merging.rst | 7 Maintaining a subsystem, as a general rule, requires a familiarity with the
8 Git source-code management system. Git is a powerful tool with a lot of
19 maintainers result from a desire to avoid merges, while others come from
20 merging a little too often.
25 "Rebasing" is the process of changing the history of a series of commits
26 within a repository. There are two different types of operations that are
30 - Changing the parent (starting) commit upon which a series of patches is
31 built. For example, a rebase operation could take a patch set built on
36 - Changing the history of a set of patches by fixing (or deleting) broken
42 Used properly, rebasing can yield a cleaner and clearer development
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-bus-rpmsg | 6 Every rpmsg device is a communication channel with a remote
7 processor. Channels are identified with a (textual) name,
18 Every rpmsg device is a communication channel with a remote
19 processor. Channels have a local ("source") rpmsg address,
21 starts listening on one end of a channel, it assigns it with
22 a unique rpmsg address (a 32 bits integer). This way when
24 dispatches them to the listening entity (a kernel driver).
36 Every rpmsg device is a communication channel with a remote
37 processor. Channels have a local ("source") rpmsg address,
39 starts listening on one end of a channel, it assigns it with
[all …]
|
| /Documentation/vm/ |
| D | frontswap.rst | 7 Frontswap provides a "transcendent memory" interface for swap pages.
9 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
14 See the LWN.net article `Transcendent memory in a nutshell`_
15 for a detailed overview of frontswap and related kernel parts)
17 .. _Transcendent memory in a nutshell: https://lwn.net/Articles/454795/
20 a "backing" store for a swap device. The storage is assumed to be
21 a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
31 with the specified swap device number (aka "type"). A "store" will
33 offset associated with the page. A "load" will copy the page, if found,
40 Once a page is successfully stored, a matching load on the page will normally
[all …]
|
| D | cleancache.rst | 10 Cleancache is a new optional feature provided by the VFS layer that
12 many workloads in many environments at a negligible cost.
14 Cleancache can be thought of as a page-granularity victim cache for clean
17 PFRA "evicts" a page, it first attempts to use cleancache code to
22 Later, when a cleancache-enabled filesystem wishes to access a page
23 in a file on disk, it first checks cleancache to see if it already
25 and a disk access is avoided.
36 A cleancache "backend" that provides transcendent memory registers itself
38 passing a pointer to a cleancache_ops structure with funcs set appropriately.
48 Mounting a cleancache-enabled filesystem should call "init_fs" to obtain a
[all …]
|
| /Documentation/driver-api/ |
| D | generic-counter.rst | 10 Counter devices are prevalent among a diverse spectrum of industries.
11 The ubiquitous presence of these devices necessitates a common interface
14 drivers by introducing a generic counter interface for consumption. The
15 Generic Counter interface enables drivers to support and expose a common
23 counter devices consist of a core set of components. This core set of
27 There are three core components to a counter:
33 Association of a Signal, and evaluation trigger, with a Count.
40 A Signal represents a stream of data. This is the input data that is
41 evaluated by the counter to determine the count data; e.g. a quadrature
42 signal output line of a rotary encoder. Not all counter devices provide
[all …]
|
| D | xillybus.rst | 37 An FPGA (Field Programmable Gate Array) is a piece of logic hardware, which
38 can be programmed to become virtually anything that is usually found as a
39 dedicated chipset: For instance, a display adapter, network interface card,
40 or even a processor with its peripherals. FPGAs are the LEGO of hardware:
43 available on the market as a chipset, so FPGAs are mostly used when some
47 The challenge with FPGAs is that everything is implemented at a very low
52 mathematical functions, a functional unit (e.g. a USB interface), an entire
53 processor (e.g. ARM) or anything that might come handy. Think of them as a
57 One of the daunting tasks in FPGA design is communicating with a fullblown
60 (registers, interrupts, DMA etc.) is a project in itself. When the FPGA's
[all …]
|
| /Documentation/driver-api/soundwire/ |
| D | error_handling.rst | 17 restarting from a known position. In the case of such errors outside of a
21 and after a number of such errors are detected the bus might be reset. Note
24 be distinguished, although a recurring bus clash when audio is enabled is a
25 indication of a bus allocation issue. The interrupt mechanism can also help
26 identify Slaves which detected a Bus Clash or a Parity Error, but they may
27 not be responsible for the errors so resetting them individually is not a
30 2. Command status: Each command is associated with a status, which only
33 current frame. A NAK indicates that the command was in error and will not
34 be applied. In case of a bad programming (command sent to non-existent
35 Slave or to a non-implemented register) or electrical issue, no response
[all …]
|
| /Documentation/process/ |
| D | 5.Posting.rst | 8 kernel. Unsurprisingly, the kernel development community has evolved a set
21 There is a constant temptation to avoid posting patches before they are
22 completely "ready." For simple patches, that is not a problem. If the
23 work being done is complex, though, there is a lot to be gained by getting
25 consider posting in-progress work, or even making a git tree available so
28 When posting code which is not yet considered ready for inclusion, it is a
38 There are a number of things which should be done before you consider
50 benchmarks showing what the impact (or benefit) of your change is; a
54 for an employer, the employer likely has a right to the work and must be
57 As a general rule, putting in some extra thought before posting code almost
[all …]
|
| /Documentation/core-api/ |
| D | kobject.rst | 13 place. Dealing with kobjects requires understanding a few different types,
15 easier, we'll take a multi-pass approach, starting with vague terms and
19 - A kobject is an object of type struct kobject. Kobjects have a name
20 and a reference count. A kobject also has a parent pointer (allowing
21 objects to be arranged into hierarchies), a specific type, and,
22 usually, a representation in the sysfs virtual filesystem.
32 - A ktype is the type of object that embeds a kobject. Every structure
33 that embeds a kobject needs a corresponding ktype. The ktype controls
36 - A kset is a group of kobjects. These kobjects can be of the same ktype
42 When you see a sysfs directory full of other directories, generally each
[all …]
|
| /Documentation/userspace-api/media/mediactl/ |
| D | media-controller-model.rst | 8 Discovering a device internal topology, and configuring it at runtime,
14 - An **entity** is a basic media hardware or software building block.
15 It can correspond to a large variety of logical blocks such as
17 hardware devices (a building block in a System-on-Chip image
20 - An **interface** is a graph representation of a Linux Kernel
21 userspace API interface, like a device node or a sysfs file that
24 - A **pad** is a data connection endpoint through which an entity can
30 - A **data link** is a point-to-point oriented connection between two
32 from a source pad to a sink pad.
34 - An **interface link** is a point-to-point bidirectional control
[all …]
|
| /Documentation/locking/ |
| D | rt-mutex-design.rst | 24 Priority inversion is when a lower priority process executes while a higher
26 most of the time it can't be helped. Anytime a high priority process wants
27 to use a resource that a lower priority process has (a mutex for example),
29 with the resource. This is a priority inversion. What we want to prevent
31 priority process is prevented from running by a lower priority process for
35 processes, let's call them processes A, B, and C, where A is the highest
36 priority process, C is the lowest, and B is in between. A tries to grab a lock
38 meantime, B executes, and since B is of a higher priority than C, it preempts C,
39 but by doing so, it is in fact preempting A which is a higher priority process.
40 Now there's no way of knowing how long A will be sleeping waiting for C
[all …]
|
| /Documentation/userspace-api/media/v4l/ |
| D | vidioc-queryctrl.rst | 41 To query the attributes of a control applications set the ``id`` field
42 of a struct :ref:`v4l2_queryctrl <v4l2-queryctrl>` and call the
43 ``VIDIOC_QUERYCTRL`` ioctl with a pointer to this structure. The driver
49 exclusive ``V4L2_CID_LASTP1``. Drivers may return ``EINVAL`` if a control in
81 ``VIDIOC_QUERYMENU`` ioctl with a pointer to this structure. The driver
113 returns the first control with a higher ID. Drivers which do not
120 - Name of the control, a NUL-terminated ASCII string. This
124 - Minimum value, inclusive. This field gives a lower bound for the
127 Note that this a signed 32-bit value.
133 Note that this a signed 32-bit value.
[all …]
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | cgroups.rst | 44 Control Groups provide a mechanism for aggregating/partitioning sets of
50 A *cgroup* associates a set of tasks with a set of parameters for one
53 A *subsystem* is a module that makes use of the task grouping
55 particular ways. A subsystem is typically a "resource controller" that
56 schedules a resource or applies per-cgroup limits, but it may be
57 anything that wants to act on a group of processes, e.g. a
60 A *hierarchy* is a set of cgroups arranged in a tree, such that
62 hierarchy, and a set of subsystems; each subsystem has system-specific
67 cgroups. Each hierarchy is a partition of all tasks in the system.
71 which cgroup a task is assigned, and list the task PIDs assigned to
[all …]
|
| D | devices.rst | 8 Implement a cgroup to track and enforce open and mknod restrictions
9 on device files. A device cgroup associates a device access
10 whitelist with each cgroup. A whitelist entry has 4 fields.
11 'type' is a (all), c (char), or b (block). 'all' means it applies
13 either an integer or * for all. Access is a composition of r
16 The root device cgroup starts with rwm to 'all'. A child device
17 cgroup gets a copy of the parent. Administrators can then remove
18 devices from the whitelist or add new entries. A child cgroup can
19 never receive a device access which is denied by its parent.
32 echo a > /sys/fs/cgroup/1/devices.deny
[all …]
|
| /Documentation/driver-api/driver-model/ |
| D | binding.rst | 5 Driver binding is the process of associating a device with a device
15 The bus type structure contains a list of all devices that are on that bus
16 type in the system. When device_register is called for a device, it is
17 inserted into the end of this list. The bus object also contains a
19 for a driver, it is inserted at the end of this list. These are the
26 When a new device is added, the bus's list of drivers is iterated over
30 Instead of trying to derive a complex state machine and matching
31 algorithm, it is up to the bus driver to provide a callback to compare
32 a device against the IDs of a driver. The bus returns 1 if a match was
37 If a match is found, the device's driver field is set to the driver
[all …]
|
| /Documentation/driver-api/media/ |
| D | rc-core.rst | 12 Every time a key is pressed on a remote controller, a scan code is produced.
13 Also, on most hardware, keeping a key pressed for more than a few dozens of
14 milliseconds produce a repeat key event. That's somewhat similar to what
15 a normal keyboard or mouse is handled internally on Linux\ [#f1]_. So, the
22 produces one event for a key press and another one for key release. On
31 The infrared transmission is done by blinking a infrared emitter using a
36 In other words, a typical IR transmission can be viewed as a sequence of
37 *PULSE* and *SPACE* events, each with a given duration.
41 For example, the NEC protocol uses a carrier of 38kHz, and transmissions
42 start with a 9ms *PULSE* and a 4.5ms SPACE. It then transmits 16 bits of
[all …]
|
| /Documentation/powerpc/ |
| D | cxlflash.rst | 10 on Power 8 systems. CAPI can be thought of as a special tunneling
13 memory and generate page faults. As a result, the host interface to
19 devices as a PCI device by implementing a virtual PCI host bridge.
24 CXL provides a mechanism by which user space applications can
25 directly talk to a device (network or storage) bypassing the typical
26 kernel/device driver stack. The CXL Flash Adapter Driver enables a
29 The CXL Flash Adapter Driver is a kernel module that sits in the
30 SCSI stack as a low level device driver (below the SCSI disk and
40 - Any flash device (LUN) can be configured to be accessed as a
44 user space with a special block library. This mode further
[all …]
|
| /Documentation/security/keys/ |
| D | core.rst | 9 Keyrings are permitted; these are a special type of key that can hold links to
10 other keys. Processes each have three standard keyring subscriptions that a
28 Each key has a number of attributes:
30 - A serial number.
31 - A type.
32 - A description (for matching a key in a search).
35 - A payload.
39 * Each key is issued a serial number of type key_serial_t that is unique for
43 Userspace programs can use a key's serial numbers as a way to gain access
46 * Each key is of a defined "type". Types must be registered inside the
[all …]
|
| /Documentation/kbuild/ |
| D | kconfig-language.rst | 8 The configuration database is a collection of configuration options
9 organized in a tree structure::
31 Most entries define a config option; all other entries help to organize
32 them. A single configuration option is defined like this::
38 Usually, modules have to be recompiled whenever you switch to a new
41 Every line starts with a key word and can be followed by multiple
42 arguments. "config" starts a new config entry. The following lines
45 values. A config option can be defined multiple times with the same
46 name, but every definition can have only a single input prompt and the
52 A menu entry can have a number of attributes. Not all of them are
[all …]
|