forked from Minki/linux
doc: fix misspellings with 'codespell' tool
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
parent
7e21f14d17
commit
f884ab15af
@ -434,7 +434,7 @@ char *date;</synopsis>
|
||||
The DRM core includes two memory managers, namely Translation Table Maps
|
||||
(TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
|
||||
manager to be developed and tried to be a one-size-fits-them all
|
||||
solution. It provides a single userspace API to accomodate the need of
|
||||
solution. It provides a single userspace API to accommodate the need of
|
||||
all hardware, supporting both Unified Memory Architecture (UMA) devices
|
||||
and devices with dedicated video RAM (i.e. most discrete video cards).
|
||||
This resulted in a large, complex piece of code that turned out to be
|
||||
@ -701,7 +701,7 @@ char *date;</synopsis>
|
||||
<para>
|
||||
Similar to global names, GEM file descriptors are also used to share GEM
|
||||
objects across processes. They offer additional security: as file
|
||||
descriptors must be explictly sent over UNIX domain sockets to be shared
|
||||
descriptors must be explicitly sent over UNIX domain sockets to be shared
|
||||
between applications, they can't be guessed like the globally unique GEM
|
||||
names.
|
||||
</para>
|
||||
@ -1154,7 +1154,7 @@ int max_width, max_height;</synopsis>
|
||||
</para>
|
||||
<para>
|
||||
The <methodname>page_flip</methodname> operation schedules a page flip.
|
||||
Once any pending rendering targetting the new frame buffer has
|
||||
Once any pending rendering targeting the new frame buffer has
|
||||
completed, the CRTC will be reprogrammed to display that frame buffer
|
||||
after the next vertical refresh. The operation must return immediately
|
||||
without waiting for rendering or page flip to complete and must block
|
||||
|
@ -233,7 +233,7 @@ typedef enum fe_status {
|
||||
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_SYNC</entry>
|
||||
<entry align="char">Syncronization bytes was found</entry>
|
||||
<entry align="char">Synchronization bytes was found</entry>
|
||||
</row><row>
|
||||
<entry align="char">FE_HAS_LOCK</entry>
|
||||
<entry align="char">The DVB were locked and everything is working</entry>
|
||||
|
@ -3147,7 +3147,7 @@ giving priority to the center of the metered area.</entry>
|
||||
<entry>A multi-zone metering. The light intensity is measured
|
||||
in several points of the frame and the the results are combined. The
|
||||
algorithm of the zones selection and their significance in calculating the
|
||||
final value is device dependant.</entry>
|
||||
final value is device dependent.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</entrytbl>
|
||||
|
@ -83,7 +83,7 @@
|
||||
</para>
|
||||
<para>
|
||||
Because each different protocol causes a new driver to be created, I have
|
||||
written a generic USB driver skeleton, modeled after the pci-skeleton.c
|
||||
written a generic USB driver skeleton, modelled after the pci-skeleton.c
|
||||
file in the kernel source tree upon which many PCI network drivers have
|
||||
been based. This USB skeleton can be found at drivers/usb/usb-skeleton.c
|
||||
in the kernel source tree. In this article I will walk through the basics
|
||||
|
@ -181,7 +181,7 @@ want for getting the best possible numbers when benchmarking.
|
||||
|
||||
In practice this isn't an issue because as soon as a write comes along it'll
|
||||
cause the btree node to be split, and you need almost no write traffic for
|
||||
this to not show up enough to be noticable (especially since bcache's btree
|
||||
this to not show up enough to be noticeable (especially since bcache's btree
|
||||
nodes are huge and index large regions of the device). But when you're
|
||||
benchmarking, if you're trying to warm the cache by reading a bunch of data
|
||||
and there's no other traffic - that can be a problem.
|
||||
@ -222,7 +222,7 @@ running
|
||||
it's in passthrough mode or caching).
|
||||
|
||||
sequential_cutoff
|
||||
A sequential IO will bypass the cache once it passes this threshhold; the
|
||||
A sequential IO will bypass the cache once it passes this threshold; the
|
||||
most recent 128 IOs are tracked so sequential IO can be detected even when
|
||||
it isn't all done at once.
|
||||
|
||||
@ -296,7 +296,7 @@ cache_miss_collisions
|
||||
since the synchronization for cache misses was rewritten)
|
||||
|
||||
cache_readaheads
|
||||
Count of times readahead occured.
|
||||
Count of times readahead occurred.
|
||||
|
||||
SYSFS - CACHE SET:
|
||||
|
||||
@ -359,7 +359,7 @@ unregister
|
||||
SYSFS - CACHE SET INTERNAL:
|
||||
|
||||
This directory also exposes timings for a number of internal operations, with
|
||||
separate files for average duration, average frequency, last occurence and max
|
||||
separate files for average duration, average frequency, last occurrence and max
|
||||
duration: garbage collection, btree read, btree node sorts and btree splits.
|
||||
|
||||
active_journal_entries
|
||||
@ -414,7 +414,7 @@ freelist_percent
|
||||
space.
|
||||
|
||||
io_errors
|
||||
Number of errors that have occured, decayed by io_error_halflife.
|
||||
Number of errors that have occurred, decayed by io_error_halflife.
|
||||
|
||||
metadata_written
|
||||
Sum of all non data writes (btree writes and all other metadata).
|
||||
|
@ -93,7 +93,7 @@ To avoid priority inversion through request starvation, a request
|
||||
queue maintains a separate request pool per each cgroup when
|
||||
CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
|
||||
per-block-cgroup request pool. IOW, if there are N block cgroups,
|
||||
each request queue may have upto N request pools, each independently
|
||||
each request queue may have up to N request pools, each independently
|
||||
regulated by nr_requests.
|
||||
|
||||
optimal_io_size (RO)
|
||||
|
@ -304,7 +304,7 @@ kernel memory, we prevent new processes from being created when the kernel
|
||||
memory usage is too high.
|
||||
|
||||
* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
|
||||
of each kmem_cache is created everytime the cache is touched by the first time
|
||||
of each kmem_cache is created every time the cache is touched by the first time
|
||||
from inside the memcg. The creation is done lazily, so some objects can still be
|
||||
skipped while the cache is being created. All objects in a slab page should
|
||||
belong to the same memcg. This only fails to hold when a task is migrated to a
|
||||
|
@ -87,7 +87,7 @@ Migration throttling
|
||||
|
||||
Migrating data between the origin and cache device uses bandwidth.
|
||||
The user can set a throttle to prevent more than a certain amount of
|
||||
migration occuring at any one time. Currently we're not taking any
|
||||
migration occurring at any one time. Currently we're not taking any
|
||||
account of normal io traffic going to the devices. More work needs
|
||||
doing here to avoid migrating during those peak io moments.
|
||||
|
||||
|
@ -5,7 +5,7 @@ can combine interrupt sources as a group and provide a single interrupt request
|
||||
for the group. The interrupt request from each group are connected to a parent
|
||||
interrupt controller, such as GIC in case of Exynos4210.
|
||||
|
||||
The interrupt combiner controller consists of multiple combiners. Upto eight
|
||||
The interrupt combiner controller consists of multiple combiners. Up to eight
|
||||
interrupt sources can be connected to a combiner. The combiner outputs one
|
||||
combined interrupt for its eight interrupt sources. The combined interrupt
|
||||
is usually connected to a parent interrupt controller.
|
||||
@ -14,8 +14,8 @@ A single node in the device tree is used to describe the interrupt combiner
|
||||
controller module (which includes multiple combiners). A combiner in the
|
||||
interrupt controller module shares config/control registers with other
|
||||
combiners. For example, a 32-bit interrupt enable/disable config register
|
||||
can accommodate upto 4 interrupt combiners (with each combiner supporting
|
||||
upto 8 interrupt sources).
|
||||
can accommodate up to 4 interrupt combiners (with each combiner supporting
|
||||
up to 8 interrupt sources).
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "samsung,exynos4210-combiner".
|
||||
|
@ -14,7 +14,7 @@ A single node in the device tree is used to describe the shared
|
||||
interrupt multiplexor (one node for all groups). A group in the
|
||||
interrupt controller shares config/control registers with other groups.
|
||||
For example, a 32-bit interrupt enable/disable config register can
|
||||
accommodate upto 4 interrupt groups.
|
||||
accommodate up to 4 interrupt groups.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be, either of
|
||||
|
@ -4,7 +4,7 @@ Reference
|
||||
[1] Si5351A/B/C Data Sheet
|
||||
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
|
||||
|
||||
The Si5351a/b/c are programmable i2c clock generators with upto 8 output
|
||||
The Si5351a/b/c are programmable i2c clock generators with up to 8 output
|
||||
clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
|
||||
3 output clocks are accessible. The internal structure of the clock
|
||||
generators can be found in [1].
|
||||
|
@ -51,7 +51,7 @@ Optional properties:
|
||||
* card-detect-delay: Delay in milli-seconds before detecting card after card
|
||||
insert event. The default value is 0.
|
||||
|
||||
* supports-highspeed: Enables support for high speed cards (upto 50MHz)
|
||||
* supports-highspeed: Enables support for high speed cards (up to 50MHz)
|
||||
|
||||
* broken-cd: as documented in mmc core bindings.
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
4xx/Axon EMAC ethernet nodes
|
||||
|
||||
The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
|
||||
the Axon bridge. To operate this needs to interact with a ths
|
||||
the Axon bridge. To operate this needs to interact with a this
|
||||
special McMAL DMA controller, and sometimes an RGMII or ZMII
|
||||
interface. In addition to the nodes and properties described
|
||||
below, the node for the OPB bus on which the EMAC sits must have a
|
||||
|
@ -2,7 +2,7 @@ Broadcom BCM2835 SPI0 controller
|
||||
|
||||
The BCM2835 contains two forms of SPI master controller, one known simply as
|
||||
SPI0, and the other known as the "Universal SPI Master"; part of the
|
||||
auxilliary block. This binding applies to the SPI0 controller.
|
||||
auxiliary block. This binding applies to the SPI0 controller.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "brcm,bcm2835-spi".
|
||||
|
@ -44,7 +44,7 @@ Example 1: In this example, the system uses only the first global timer
|
||||
};
|
||||
|
||||
Example 2: In this example, the MCT global and local timer interrupts are
|
||||
connected to two seperate interrupt controllers. Hence, an
|
||||
connected to two separate interrupt controllers. Hence, an
|
||||
interrupt-map is created to map the interrupts to the respective
|
||||
interrupt controllers.
|
||||
|
||||
|
@ -12,7 +12,7 @@ AM33XX MUSB GLUE
|
||||
represents PERIPHERAL.
|
||||
- port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
|
||||
represents PERIPHERAL.
|
||||
- power : Should be "250". This signifies the controller can supply upto
|
||||
- power : Should be "250". This signifies the controller can supply up to
|
||||
500mA when operating in host mode.
|
||||
|
||||
Example:
|
||||
|
@ -16,7 +16,7 @@ OMAP MUSB GLUE
|
||||
specifying ULPI and UTMI respectively.
|
||||
- mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
|
||||
represents PERIPHERAL.
|
||||
- power : Should be "50". This signifies the controller can supply upto
|
||||
- power : Should be "50". This signifies the controller can supply up to
|
||||
100mA when operating in host mode.
|
||||
- usb-phy : the phandle for the PHY device
|
||||
|
||||
|
@ -279,7 +279,7 @@ The dyndbg option is a "fake" module parameter, which means:
|
||||
|
||||
- modules do not need to define it explicitly
|
||||
- every module gets it tacitly, whether they use pr_debug or not
|
||||
- it doesnt appear in /sys/module/$module/parameters/
|
||||
- it doesn't appear in /sys/module/$module/parameters/
|
||||
To see it, grep the control file, or inspect /proc/cmdline.
|
||||
|
||||
For CONFIG_DYNAMIC_DEBUG kernels, any settings given at boot-time (or
|
||||
|
@ -55,7 +55,7 @@ Version 1.9.4.4
|
||||
* Overhaul color register routines.
|
||||
* Associated with the above, console colors are now obtained from a LUT
|
||||
called 'palette' instead of from the VGA registers. This code was
|
||||
modeled after that in atyfb and matroxfb.
|
||||
modelled after that in atyfb and matroxfb.
|
||||
* Code cleanup, add comments.
|
||||
* Overhaul SR07 handling.
|
||||
* Bug fixes.
|
||||
|
@ -42,7 +42,7 @@ nodiscard(*) block device when blocks are freed. This is useful for SSD
|
||||
devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
|
||||
command is also available together with the nodiscard option.
|
||||
The value of minlen specifies the minimum blockcount, when
|
||||
a TRIM command to the block device is considered usefull.
|
||||
a TRIM command to the block device is considered useful.
|
||||
When no value is given to the discard option, it defaults to
|
||||
64 blocks, which means 256KiB in JFS.
|
||||
The minlen value of discard overrides the minlen value given
|
||||
|
@ -148,7 +148,7 @@ smaller than addressing space in the bitmap.
|
||||
Bitmap system area
|
||||
------------------
|
||||
|
||||
The bitmap itself is devided into three parts.
|
||||
The bitmap itself is divided into three parts.
|
||||
First the system area, that is split into two halfs.
|
||||
Then userspace.
|
||||
|
||||
|
@ -307,7 +307,7 @@ the following:
|
||||
|
||||
<proceeding files...>
|
||||
<slot #3, id = 0x43, characters = "h is long">
|
||||
<slot #2, id = 0x02, characters = "xtension whic">
|
||||
<slot #2, id = 0x02, characters = "xtension which">
|
||||
<slot #1, id = 0x01, characters = "My Big File.E">
|
||||
<directory entry, name = "MYBIGFIL.EXT">
|
||||
|
||||
|
@ -2,7 +2,7 @@
|
||||
* dslm.c
|
||||
* Simple Disk Sleep Monitor
|
||||
* by Bartek Kania
|
||||
* Licenced under the GPL
|
||||
* Licensed under the GPL
|
||||
*/
|
||||
#include <unistd.h>
|
||||
#include <stdlib.h>
|
||||
|
@ -18,7 +18,7 @@ Abstract media device model
|
||||
|
||||
Discovering a device internal topology, and configuring it at runtime, is one
|
||||
of the goals of the media framework. To achieve this, hardware devices are
|
||||
modeled as an oriented graph of building blocks called entities connected
|
||||
modelled as an oriented graph of building blocks called entities connected
|
||||
through pads.
|
||||
|
||||
An entity is a basic media hardware building block. It can correspond to
|
||||
|
@ -189,7 +189,7 @@ call:
|
||||
|
||||
64-bit arguments are placed in matching pairs of registers (i.e. the same
|
||||
register number in both D0 and D1 units), with the least significant half in D0
|
||||
and the most significant half in D1, leaving a gap where necessary. Futher
|
||||
and the most significant half in D1, leaving a gap where necessary. Further
|
||||
arguments are stored on the stack in reverse order (earlier arguments at higher
|
||||
addresses):
|
||||
|
||||
|
@ -120,7 +120,7 @@ The Intel MEI Driver supports the following IOCTL command:
|
||||
Notes:
|
||||
max_msg_length (MTU) in client properties describes the maximum
|
||||
data that can be sent or received. (e.g. if MTU=2K, can send
|
||||
requests up to bytes 2k and received responses upto 2k bytes).
|
||||
requests up to bytes 2k and received responses up to 2k bytes).
|
||||
|
||||
Intel ME Applications:
|
||||
==============
|
||||
|
@ -183,7 +183,7 @@ tcp_early_retrans - INTEGER
|
||||
for triggering fast retransmit when the amount of outstanding data is
|
||||
small and when no previously unsent data can be transmitted (such
|
||||
that limited transmit could be used). Also controls the use of
|
||||
Tail loss probe (TLP) that converts RTOs occuring due to tail
|
||||
Tail loss probe (TLP) that converts RTOs occurring due to tail
|
||||
losses into fast recovery (draft-dukkipati-tcpm-tcp-loss-probe-01).
|
||||
Possible values:
|
||||
0 disables ER
|
||||
|
@ -54,7 +54,7 @@ it will use an allocated socket buffer as usual and the contents will be
|
||||
copied to the ring on transmission, nullifying most of the performance gains.
|
||||
Dumps of kernel databases automatically support memory mapped I/O.
|
||||
|
||||
Conversion of the transmit path involves changing message contruction to
|
||||
Conversion of the transmit path involves changing message construction to
|
||||
use memory from the TX ring instead of (usually) a buffer declared on the
|
||||
stack and setting up the frame header approriately. Optionally poll() can
|
||||
be used to wait for free frames in the TX ring.
|
||||
@ -65,8 +65,8 @@ Structured and definitions for using memory mapped I/O are contained in
|
||||
RX and TX rings
|
||||
----------------
|
||||
|
||||
Each ring contains a number of continous memory blocks, containing frames of
|
||||
fixed size dependant on the parameters used for ring setup.
|
||||
Each ring contains a number of continuous memory blocks, containing frames of
|
||||
fixed size dependent on the parameters used for ring setup.
|
||||
|
||||
Ring: [ block 0 ]
|
||||
[ frame 0 ]
|
||||
@ -80,7 +80,7 @@ Ring: [ block 0 ]
|
||||
[ frame 2 * n + 1 ]
|
||||
|
||||
The blocks are only visible to the kernel, from the point of view of user-space
|
||||
the ring just contains the frames in a continous memory zone.
|
||||
the ring just contains the frames in a continuous memory zone.
|
||||
|
||||
The ring parameters used for setting up the ring are defined as follows:
|
||||
|
||||
@ -91,7 +91,7 @@ struct nl_mmap_req {
|
||||
unsigned int nm_frame_nr;
|
||||
};
|
||||
|
||||
Frames are grouped into blocks, where each block is a continous region of memory
|
||||
Frames are grouped into blocks, where each block is a continuous region of memory
|
||||
and holds nm_block_size / nm_frame_size frames. The total number of frames in
|
||||
the ring is nm_frame_nr. The following invariants hold:
|
||||
|
||||
@ -113,7 +113,7 @@ Some parameters are constrained, specifically:
|
||||
|
||||
- nm_frame_nr must equal the actual number of frames as specified above.
|
||||
|
||||
When the kernel can't allocate phsyically continous memory for a ring block,
|
||||
When the kernel can't allocate physically continuous memory for a ring block,
|
||||
it will fall back to use physically discontinous memory. This might affect
|
||||
performance negatively, in order to avoid this the nm_frame_size parameter
|
||||
should be chosen to be as small as possible for the required frame size and
|
||||
|
@ -298,7 +298,7 @@ Since the pin controller subsystem have its pinspace local to the pin
|
||||
controller we need a mapping so that the pin control subsystem can figure out
|
||||
which pin controller handles control of a certain GPIO pin. Since a single
|
||||
pin controller may be muxing several GPIO ranges (typically SoCs that have
|
||||
one set of pins but internally several GPIO silicon blocks, each modeled as
|
||||
one set of pins but internally several GPIO silicon blocks, each modelled as
|
||||
a struct gpio_chip) any number of GPIO ranges can be added to a pin controller
|
||||
instance like this:
|
||||
|
||||
|
@ -20,7 +20,7 @@ When it's enabled, sysfs node will be created as
|
||||
The sysfs node, 'emul_node', will contain value 0 for the initial state. When you input any
|
||||
temperature you want to update to sysfs node, it automatically enable emulation mode and
|
||||
current temperature will be changed into it.
|
||||
(Exynos also supports user changable delay time which would be used to delay of
|
||||
(Exynos also supports user changeable delay time which would be used to delay of
|
||||
changing temperature. However, this node only uses same delay of real sensing time, 938us.)
|
||||
|
||||
Exynos emulation mode requires synchronous of value changing and enabling. It means when you
|
||||
|
@ -1683,7 +1683,7 @@ The parameter is defined like this:
|
||||
|
||||
This ioctl maps the memory at "user_addr" with the length "length" to
|
||||
the vcpu's address space starting at "vcpu_addr". All parameters need to
|
||||
be alligned by 1 megabyte.
|
||||
be aligned by 1 megabyte.
|
||||
|
||||
|
||||
4.66 KVM_S390_UCAS_UNMAP
|
||||
@ -1703,7 +1703,7 @@ The parameter is defined like this:
|
||||
|
||||
This ioctl unmaps the memory in the vcpu's address space starting at
|
||||
"vcpu_addr" with the length "length". The field "user_addr" is ignored.
|
||||
All parameters need to be alligned by 1 megabyte.
|
||||
All parameters need to be aligned by 1 megabyte.
|
||||
|
||||
|
||||
4.67 KVM_S390_VCPU_FAULT
|
||||
@ -2019,7 +2019,7 @@ be OR'ed into the "vsid" argument of the slbmte instruction.
|
||||
The "enc" array is a list which for each of those segment base page
|
||||
size provides the list of supported actual page sizes (which can be
|
||||
only larger or equal to the base page size), along with the
|
||||
corresponding encoding in the hash PTE. Similarily, the array is
|
||||
corresponding encoding in the hash PTE. Similarly, the array is
|
||||
8 entries sorted by increasing sizes and an entry with a "0" shift
|
||||
is an empty entry and a terminator:
|
||||
|
||||
|
@ -147,5 +147,5 @@ once.
|
||||
Other notes:
|
||||
|
||||
Reading from any of the files will return -EINVAL if you are not starting
|
||||
the read on an 8-byte boundary (e.g., if you seeked an odd number of bytes
|
||||
the read on an 8-byte boundary (e.g., if you sought an odd number of bytes
|
||||
into the file), or if the size of the read is not a multiple of 8 bytes.
|
||||
|
@ -24,7 +24,7 @@ Memory Access
|
||||
|
||||
A write operation on the "eeprom" file writes the given byte sequence
|
||||
to the EEPROM of the DS28E04. If CRC checking mode is enabled only
|
||||
fully alligned blocks of 32 bytes with valid CRC16 values (in bytes 30
|
||||
fully aligned blocks of 32 bytes with valid CRC16 values (in bytes 30
|
||||
and 31) are allowed to be written.
|
||||
|
||||
PIO Access
|
||||
|
Loading…
Reference in New Issue
Block a user