/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 …]
|