| /OK3568_Linux_fs/kernel/Documentation/input/ |
| H A D | gamepad.rst | 12 document defines how gamepads are supposed to report their data.
44 4 buttons in diamonds-shape (on the right side). The buttons are
56 all devices have both or any, but they are present at most times.
59 Triggers are located on the upper-side of the pad in vertical direction.
60 Not all devices provide them, but the upper buttons are normally named
63 Many devices provide force-feedback features. But are mostly just
79 All new gamepads are supposed to comply with this mapping. Please report any
82 There are a lot of less-featured/less-powerful devices out there, which re-use
103 of the labels on the buttons, the codes are sent according to the
106 Please note that 2- and 3-button pads are fairly rare and old. You might
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/fb/ |
| H A D | api.rst | 13 buffer core are not described.
24 Device and driver capabilities are reported in the fixed screen information
39 When supported, formats are configured using a FOURCC instead of manually
46 Pixels are stored in memory in hardware-dependent formats. Applications need
50 Formats are described by frame buffer types and visuals. Some visuals require
51 additional information, which are stored in the variable screen information
55 macropixels. Types describe how macropixels are stored in memory. The following
56 types and visuals are supported.
60 Macropixels are stored contiguously in a single plane. If the number of bits
61 per macropixel is not a multiple of 8, whether macropixels are padded to the
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/core-api/ |
| H A D | tracepoint.rst | 11 Tracepoints are static probe points that are located in strategic points
13 a callback mechanism. The 'probes' are strictly typed functions that are
17 debug, and understand kernel behavior. There are a number of tools that
21 Tracepoints are defined in a number of header files via various macros.
24 tracepoints are available but also to understand where future
28 ``trace_tracepointname(function parameters)``. These are the tracepoints
29 callbacks that are found throughout the code. Registering and
|
| /OK3568_Linux_fs/kernel/Documentation/ |
| H A D | atomic_bitops.txt | 5 While our bitmap_{}() functions are non-atomic, we have a number of operations
6 operating on single bits in a bitmap that are atomic.
12 The single bit operations are:
55 - non-RMW operations are unordered;
57 - RMW operations that have no return value are unordered;
59 - RMW operations that have a return value are fully ordered.
61 - RMW operations that are conditional are unordered on FAILURE,
70 the same barriers as for atomic_t are used, see atomic_t.txt.
|
| H A D | atomic_t.txt | 5 RMW operations between CPUs (atomic operations on MMIO are not supported and
82 The non-RMW ops are (typically) regular LOADs and STOREs and are canonically
86 and are doing it wrong.
91 C Atomic-RMW-ops-are-atomic-WRT-atomic_set
142 these are limited to the arithmetic operations because those are
143 reversible. Bitops are irreversible and therefore the modified value
150 - misc; the special purpose operations that are commonly used and would,
152 are time critical and can, (typically) on LL/SC architectures, be more
155 All these operations are SMP atomic; that is, the operations (for a single
165 - non-RMW operations are unordered;
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/userspace-api/media/v4l/ |
| H A D | colorspaces.rst | 20 the human eye has color receptors that are sensitive to three different
22 color. Be glad you are not a mantis shrimp as those are sensitive to 12
27 color receptors are stimulated. This is based on the Spectral Power
35 those receptors and are perceived as the same color, even though the SPD
43 After some further mathematical transforms these stimuli are known as
45 color as perceived by a human unambiguously. These X, Y and Z values are
56 The x and y values are the chromaticity coordinates and can be used to
59 colors are specified with lower case 'x' and 'y', then the CIE xyY
64 will find reading resources that go into much more detail if you are
71 phosphors used in the displays. These *color primaries* are part of what
[all …]
|
| H A D | colorspaces-details.rst | 18 are:
46 The red, green and blue chromaticities are also often referred to as the
70 The luminance (Y') and color difference (Cb and Cr) are obtained with
81 Y' is clamped to the range [0…1] and Cb and Cr are clamped to the range
99 and the white reference are:
130 extended gamut xvYCC encoding values outside that range are allowed.
150 The luminance (Y') and color difference (Cb and Cr) are obtained with
161 Y' is clamped to the range [0…1] and Cb and Cr are clamped to the range
171 Two additional extended gamut Y'CbCr encodings are also possible with
176 that are outside the range [0…1]. The resulting Y', Cb and Cr values are
[all …]
|
| H A D | pixfmt-meta-intel-ipu3.rst | 16 an input Bayer frame. Those statistics are obtained from the "ipu3-imgu [01] 3a
18 interface. They are formatted as described by the :c:type:`ipu3_uapi_stats_3a`
21 The statistics collected are AWB (Auto-white balance) RGBS (Red, Green, Blue and
46 The pipeline parameters are passed to the "ipu3-imgu [01] parameters" metadata
47 output video nodes, using the :c:type:`v4l2_meta_format` interface. They are
50 Both 3A statistics and pipeline parameters described here are closely tied to
51 the underlying camera sub-system (CSS) APIs. They are usually consumed and
59 /* Flags which of the settings below are to be applied */
|
| /OK3568_Linux_fs/kernel/Documentation/i2c/ |
| H A D | i2c-topology.rst | 5 There are a couple of reasons for building more complex I2C topologies
20 These constructs are represented as I2C adapter trees by Linux, where
23 I2C transfers, and all adapters with a parent are part of an "i2c-mux"
37 There are two variants of locking available to I2C muxes, they can be
47 all involved gpio pins are controlled by the
56 all involved pinctrl devices are controlled
85 adapter are locked. Mux-locked muxes are mostly interesting if the
99 mux-locked muxes that are not siblings, when there are address
144 These transfers are normal I2C transfers that locks the parent
152 This means that accesses to D2 are lockout out for the full duration
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/driver-api/soundwire/ |
| H A D | stream.rst | 20 interface. Below are some ways a stream can be represented in SoundWire.
57 Slaves are using single port. ::
79 Master. Both of the L and R channels are received by two different
80 Slaves. Master and both Slaves are using single port handling
131 receiving one channel. Both Masters and both Slaves are using single port. ::
197 framework(ASoC DPCM) guarantees that stream operations on a card are
206 typically configure which of the slots are used. For Example 4, the
230 done for each of the stream allocated/released on Bus. Following are the
254 ``SDW_STREAM_DISABLED`` are only relevant when then INFO_PAUSE flag is
280 (2) The resources required for holding stream runtime information are
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/networking/ |
| H A D | ipv6.rst | 8 Options for the ipv6 module are supplied as parameters at load time.
11 or modprobe command, but are usually specified in either
15 The available ipv6 module parameters are listed below. If a parameter
18 The parameters are as follows:
25 IPv6 addresses or operations are desired.
27 The possible values and their effects are:
49 The possible values and their effects are:
65 This might be used when no IPv6 addresses are desired.
67 The possible values and their effects are:
|
| /OK3568_Linux_fs/kernel/Documentation/livepatch/ |
| H A D | livepatch.rst | 28 There are many situations where users are reluctant to reboot a system. It may
39 There are multiple mechanisms in the Linux kernel that are directly related
43 - The kernel probes are the most generic. The code can be redirected by
52 are in any way modified.
56 Most of these problems are solved by using the dynamic ftrace framework as
59 a live patch is called with the help of a custom ftrace handler. But there are
66 Functions are there for a reason. They take some input parameters, get or
73 Most of these changes are self contained and the function presents itself
77 But there are more complex fixes. For example, a patch might change
83 when it is safe to do so, e.g. when the affected locks are released
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/filesystems/ |
| H A D | squashfs.rst | 10 directories. Inodes in the system are very small and all blocks are packed to
11 minimise data overhead. Block sizes greater than 4K are supported up to a
51 directory data are highly compacted, and packed on byte boundaries. Each
100 Compressed data blocks are written to the filesystem as files are read from
103 xattr tables are written.
110 these are stored here.
115 Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each
120 Inodes are packed into the metadata blocks, and are not aligned to block
121 boundaries, therefore inodes overlap compressed blocks. Inodes are identified
126 To maximise compression there are different inodes for each file type
[all …]
|
| H A D | gfs2-glocks.rst | 17 are completed.
20 just the holders) associated with the glock. If there are any
22 of the list. Locks are granted in strictly the order that they
23 are queued, except for those marked LM_FLAG_PRIORITY which are
26 There are three lock states that users of the glock layer can request,
41 operations. The glocks are basically a lock plus some routines which deal
53 These rules are implemented using the various glock operations which
54 are defined for each type of glock. Not all types of glocks use
79 prevent a situation where locks are being bounced around the cluster
81 tends to show up most with shared mmaped files which are being written
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/admin-guide/device-mapper/ |
| H A D | statistics.rst | 6 regions of a DM device. If no regions are defined no statistics are
8 devices are currently supported.
14 The I/O statistics counters for each step-sized area of a region are
16 Documentation/admin-guide/iostats.rst). But two extra counters (12 and 13) are
22 The reported times are in milliseconds and the granularity depends on
24 reported times are in nanoseconds.
65 The following optional arguments are supported:
70 used, the resulting times are in nanoseconds instead of
71 milliseconds. Precise timestamps are a little bit slower
75 numbers n1, n2, etc are times that represent the boundaries
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/arm/nwfpe/ |
| H A D | netwinder-fpe.rst | 17 Note: items enclosed in {} are optional.
28 These instructions are fully implemented.
40 These instructions are fully implemented. They store/load three words
58 FLT/FIX are fully implemented.
60 RFS/WFS are fully implemented.
62 RFC/WFC are fully implemented. RFC/WFC are supervisor only instructions, and
73 These are fully implemented.
87 These are fully implemented.
93 These are fully implemented as well. They use the same algorithm as the
96 to the ARM manual. The manual notes these are defined only for single
[all …]
|
| /OK3568_Linux_fs/kernel/init/ |
| H A D | Kconfig.gki | 14 These are normally selected implicitly when including a
15 DRM module, but for GKI, the modules are built out-of-tree.
23 These are normally selected implicitly when a module
31 These are normally selected implicitly when a module
43 These are normally selected implicitly when a module
56 These are normally selected implicitly when a module
64 These are normally selected implicitly when a module
73 These are normally selected implicitly when a module
84 These are normally selected implicitly when a module
101 These are normally selected implicitly when a module
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/hid/ |
| H A D | hid-transport.rst | 15 drivers on top of it. The transport drivers are responsible of raw data
18 and quirks are handled by all layers depending on the quirk.
62 drivers are not required to register themselves with HID core. HID core is never
63 aware of which transport drivers are available and is not interested in it. It
68 this struct are used by HID core to communicate with the device.
70 Transport drivers are responsible of detecting device failures and unplugging.
100 reports. No management commands or data acknowledgements are sent on this
103 send their input events on this channel. Outgoing events are normally
107 channel and are normally ignored. Instead, devices only send management
111 Outgoing reports are usually sent on the ctrl channel via synchronous
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/driver-api/media/ |
| H A D | camera-sensor.rst | 16 input parameters that are specific to the hardware:: the external clock frequency
17 and the link frequency. The two parameters generally are obtained from system
20 The reason why the clock frequencies are so important is that the clock signals
23 elsewhere. Therefore only the pre-determined frequencies are configurable by the
29 There are two distinct ways to configure the frame size produced by camera
46 they control based on user requests, are limited to a number of preset
48 level are independent. How a driver picks such configuration is based on the
51 Most sensor drivers are implemented this way, see e.g.
57 There are two different methods for obtaining possibilities for different frame
78 Horizontal and vertical blanking are specified by ``V4L2_CID_HBLANK`` and
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/admin-guide/pm/ |
| H A D | suspend-flows.rst | 26 different sleep states of the system are quite similar, but there are some
36 states are mostly identical, so they both together will be referred to as
45 The following steps are taken in order to transition the system from the working
58 Tasks are frozen primarily in order to avoid unchecked hardware accesses
64 All user space tasks are intercepted as though they were sent a signal and
69 specific reasons are frozen subsequently, but they are not intercepted.
70 Instead, they are expected to periodically check whether or not they need
79 Devices are suspended in four phases called *prepare*, *suspend*,
87 phase and high-level ("action") interrupt handlers are prevented from being
90 Interrupts are still handled after that, but they are only acknowledged to
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/devicetree/ |
| H A D | writing-schema.rst | 6 Devicetree bindings are written using json-schema vocabulary. Schema files are
16 top-level json-schema properties used are:
46 schema. By default without 'select', nodes are matched against their possible
56 binding. The exact schema syntax depends on whether properties are known,
57 common properties (e.g. 'interrupts') or are binding/vendor specific properties.
65 Optional. Similar to 'properties', but names are regex.
75 Unless noted otherwise, all properties are required.
82 vocabulary for that property. The properties schemas are what is used for
86 binding schema need to be defined such as how many values are valid or what
87 possible values are valid.
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/security/keys/ |
| H A D | trusted-encrypted.rst | 5 Trusted and Encrypted Keys are two new key types added to the existing kernel
6 key ring service. Both of these new types are variable length symmetric keys,
7 and in both cases all keys are created in the kernel, and user space sees,
10 Keys can be used on any system. All user level blobs, are displayed and loaded
11 in hex ascii for convenience, and are integrity verified.
13 Trusted Keys use a TPM both to generate and to seal the keys. Keys are sealed
17 (future) PCR values, so keys are easily migrated to new pcr values, such as
18 when the kernel and initramfs are updated. The same key can have many saved
19 blobs under different PCR values, so multiple boots are easily supported.
24 By default, trusted keys are sealed under the SRK, which has the default
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/driver-api/ |
| H A D | device-io.rst | 35 are starting with one. Physical addresses are of type unsigned long.
54 historical accident, these are named byte, word, long and quad accesses.
55 Both read and write accesses are supported; there is no prefetch support
58 The functions are named readb(), readw(), readl(), readq(),
64 memcpy_fromio() and memset_io() functions are
65 provided. Do not use memset or memcpy on IO addresses; they are not
68 The read and write functions are defined to be ordered. That is the
73 While the basic functions are defined to be synchronous with respect to
76 are burned by the fact that PCI bus writes are posted asynchronously. A
86 driver would like to ensure the write's effects are visible prior to
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/security/ |
| H A D | lsm.rst | 11 The APIs described in this book are outdated.
65 of security modules that are active on the system.
67 The LSM security fields are simply ``void*`` pointers.
70 Security blobs that are used by more than one security module are
73 program execution security information, security fields are included in
79 information, security fields are included in :c:type:`struct inode
95 32-bit integer. The security modules are required to map or otherwise
98 LSM hooks are maintained in lists. A list is maintained for each
99 hook, and the hooks are called in the order specified by CONFIG_LSM.
107 which are added to the lists.
[all …]
|
| /OK3568_Linux_fs/kernel/Documentation/mhi/ |
| H A D | mhi.rst | 29 which are mapped to the host memory space by the peripheral buses like PCIe.
30 Following are the major components of MMIO register space:
34 MHI BHI registers: BHI (Boot Host Interface) registers are used by the host
41 (DB) registers are used by the host to notify the device when new events are
50 All data structures used by MHI are in the host system memory. Using the
52 structures and data buffers in the host system memory regions are mapped for
55 Channel context array: All channel configurations are organized in channel
59 transfer rings are organized as a circular queue of Transfer Descriptors (TD).
61 Event context array: All event configurations are organized in the event context
67 Command context array: All command configurations are organized in command
[all …]
|