Documentation: Fix typo in multiple files in Documentation
Correct multiple spelling typo in Documentation. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Rob Landley <rob@landley.net> Reported-by: Anders Larsen <al@alarsen.net> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This commit is contained in:
parent
3b729f7647
commit
c94bed8e19
16 changed files with 33 additions and 33 deletions
|
@ -189,7 +189,7 @@ Contact: Matthew Garrett <mjg@redhat.com>
|
|||
Description:
|
||||
Some information about whether a given USB device is
|
||||
physically fixed to the platform can be inferred from a
|
||||
combination of hub decriptor bits and platform-specific data
|
||||
combination of hub descriptor bits and platform-specific data
|
||||
such as ACPI. This file will read either "removable" or
|
||||
"fixed" if the information is available, and "unknown"
|
||||
otherwise.
|
|
@ -1289,7 +1289,7 @@ static struct block_device_operations opt_fops = {
|
|||
* Sparc assembly will do this to ya.
|
||||
*/
|
||||
C_LABEL(cputypvar):
|
||||
.asciz "compatability"
|
||||
.asciz "compatibility"
|
||||
|
||||
/* Tested on SS-5, SS-10. Probably someone at Sun applied a spell-checker. */
|
||||
.align 4
|
||||
|
|
|
@ -918,7 +918,7 @@ and other resources, etc.
|
|||
<title>HSM violation</title>
|
||||
<para>
|
||||
This error is indicated when STATUS value doesn't match HSM
|
||||
requirement during issuing or excution any ATA/ATAPI command.
|
||||
requirement during issuing or execution any ATA/ATAPI command.
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
|
|
|
@ -2023,7 +2023,7 @@ Possible values are:</entry>
|
|||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">Cyclic intra macroblock refresh. This is the number of continuous macroblocks
|
||||
refreshed every frame. Each frame a succesive set of macroblocks is refreshed until the cycle completes and starts from the
|
||||
refreshed every frame. Each frame a successive set of macroblocks is refreshed until the cycle completes and starts from the
|
||||
top of the frame. Applicable to H264, H263 and MPEG4 encoder.</entry>
|
||||
</row>
|
||||
|
||||
|
@ -2183,7 +2183,7 @@ Applicable to the MPEG4 and H264 encoders.</entry>
|
|||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">The Video Buffer Verifier size in kilobytes, it is used as a limitation of frame skip.
|
||||
The VBV is defined in the standard as a mean to verify that the produced stream will be succesfully decoded.
|
||||
The VBV is defined in the standard as a mean to verify that the produced stream will be successfully decoded.
|
||||
The standard describes it as "Part of a hypothetical decoder that is conceptually connected to the
|
||||
output of the encoder. Its purpose is to provide a constraint on the variability of the data rate that an
|
||||
encoder or editing process may produce.".
|
||||
|
@ -2196,7 +2196,7 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
|
|||
<entry>integer</entry>
|
||||
</row>
|
||||
<row><entry spanname="descr">The Coded Picture Buffer size in kilobytes, it is used as a limitation of frame skip.
|
||||
The CPB is defined in the H264 standard as a mean to verify that the produced stream will be succesfully decoded.
|
||||
The CPB is defined in the H264 standard as a mean to verify that the produced stream will be successfully decoded.
|
||||
Applicable to the H264 encoder.</entry>
|
||||
</row>
|
||||
|
||||
|
|
|
@ -53,7 +53,7 @@
|
|||
|
||||
3. But there are some exceptions
|
||||
- Kernel permit the identical GPIO be requested both as GPIO and GPIO
|
||||
interrut.
|
||||
interrupt.
|
||||
Some drivers, like gpio-keys, need this behavior. Kernel only print out
|
||||
warning messages like,
|
||||
bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
Flexcan CAN contoller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
|
||||
Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC).
|
||||
|
||||
Required properties:
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ from the windriver disk into this directory.
|
|||
|
||||
Then run
|
||||
|
||||
./get_dvb_firware opera1
|
||||
./get_dvb_firmware opera1
|
||||
|
||||
and after that you have 2 files:
|
||||
|
||||
|
|
|
@ -734,7 +734,7 @@ were done at i7core_edac driver. This chapter will cover those differences
|
|||
associated with a physical CPU socket.
|
||||
|
||||
Each MC have 3 physical read channels, 3 physical write channels and
|
||||
3 logic channels. The driver currenty sees it as just 3 channels.
|
||||
3 logic channels. The driver currently sees it as just 3 channels.
|
||||
Each channel can have up to 3 DIMMs.
|
||||
|
||||
The minimum known unity is DIMMs. There are no information about csrows.
|
||||
|
|
|
@ -93,7 +93,7 @@ The API to the login script is as follows:
|
|||
(allways exists)
|
||||
(More protocols can be defined in the future.
|
||||
The client does not interpret this string it is
|
||||
passed unchanged as recieved from the Server)
|
||||
passed unchanged as received from the Server)
|
||||
-o osdname of the requested target OSD
|
||||
(Might be empty)
|
||||
(A string which denotes the OSD name, there is a
|
||||
|
|
|
@ -17,7 +17,7 @@ concepts of blocks, inodes and directories.
|
|||
On QNX it is possible to create little endian and big endian qnx6 filesystems.
|
||||
This feature makes it possible to create and use a different endianness fs
|
||||
for the target (QNX is used on quite a range of embedded systems) plattform
|
||||
running on a different endianess.
|
||||
running on a different endianness.
|
||||
The Linux driver handles endianness transparently. (LE and BE)
|
||||
|
||||
Blocks
|
||||
|
@ -26,7 +26,7 @@ Blocks
|
|||
The space in the device or file is split up into blocks. These are a fixed
|
||||
size of 512, 1024, 2048 or 4096, which is decided when the filesystem is
|
||||
created.
|
||||
Blockpointers are 32bit, so the maximum space that can be adressed is
|
||||
Blockpointers are 32bit, so the maximum space that can be addressed is
|
||||
2^32 * 4096 bytes or 16TB
|
||||
|
||||
The superblocks
|
||||
|
@ -47,16 +47,16 @@ inactive superblock.
|
|||
Each superblock holds a set of root inodes for the different filesystem
|
||||
parts. (Inode, Bitmap and Longfilenames)
|
||||
Each of these root nodes holds information like total size of the stored
|
||||
data and the adressing levels in that specific tree.
|
||||
If the level value is 0, up to 16 direct blocks can be adressed by each
|
||||
data and the addressing levels in that specific tree.
|
||||
If the level value is 0, up to 16 direct blocks can be addressed by each
|
||||
node.
|
||||
Level 1 adds an additional indirect adressing level where each indirect
|
||||
adressing block holds up to blocksize / 4 bytes pointers to data blocks.
|
||||
Level 2 adds an additional indirect adressig block level (so, already up
|
||||
to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a
|
||||
Level 1 adds an additional indirect addressing level where each indirect
|
||||
addressing block holds up to blocksize / 4 bytes pointers to data blocks.
|
||||
Level 2 adds an additional indirect addressing block level (so, already up
|
||||
to 16 * 256 * 256 = 1048576 blocks that can be addressed by such a tree).
|
||||
|
||||
Unused block pointers are always set to ~0 - regardless of root node,
|
||||
indirect adressing blocks or inodes.
|
||||
indirect addressing blocks or inodes.
|
||||
Data leaves are always on the lowest level. So no data is stored on upper
|
||||
tree levels.
|
||||
|
||||
|
@ -64,7 +64,7 @@ The first Superblock is located at 0x2000. (0x2000 is the bootblock size)
|
|||
The Audi MMI 3G first superblock directly starts at byte 0.
|
||||
Second superblock position can either be calculated from the superblock
|
||||
information (total number of filesystem blocks) or by taking the highest
|
||||
device address, zeroing the last 3 bytes and then substracting 0x1000 from
|
||||
device address, zeroing the last 3 bytes and then subtracting 0x1000 from
|
||||
that address.
|
||||
|
||||
0x1000 is the size reserved for each superblock - regardless of the
|
||||
|
@ -83,8 +83,8 @@ size, number of blocks used, access time, change time and modification time.
|
|||
Object mode field is POSIX format. (which makes things easier)
|
||||
|
||||
There are also pointers to the first 16 blocks, if the object data can be
|
||||
adressed with 16 direct blocks.
|
||||
For more than 16 blocks an indirect adressing in form of another tree is
|
||||
addressed with 16 direct blocks.
|
||||
For more than 16 blocks an indirect addressing in form of another tree is
|
||||
used. (scheme is the same as the one used for the superblock root nodes)
|
||||
|
||||
The filesize is stored 64bit. Inode counting starts with 1. (whilst long
|
||||
|
@ -118,13 +118,13 @@ no block pointers and the directory file record pointing to the target file
|
|||
inode.
|
||||
|
||||
Character and block special devices do not exist in QNX as those files
|
||||
are handled by the QNX kernel/drivers and created in /dev independant of the
|
||||
are handled by the QNX kernel/drivers and created in /dev independent of the
|
||||
underlaying filesystem.
|
||||
|
||||
Long filenames
|
||||
--------------
|
||||
|
||||
Long filenames are stored in a seperate adressing tree. The staring point
|
||||
Long filenames are stored in a separate addressing tree. The staring point
|
||||
is the longfilename root node in the active superblock.
|
||||
Each data block (tree leaves) holds one long filename. That filename is
|
||||
limited to 510 bytes. The first two starting bytes are used as length field
|
||||
|
|
|
@ -63,7 +63,7 @@ Module Parameters
|
|||
Hardware Interfaces
|
||||
-------------------
|
||||
|
||||
All the chips suported by this driver are LPC Super-I/O chips, accessed
|
||||
All the chips supported by this driver are LPC Super-I/O chips, accessed
|
||||
through the LPC bus (ISA-like I/O ports). The IT8712F additionally has an
|
||||
SMBus interface to the hardware monitoring functions. This driver no
|
||||
longer supports this interface though, as it is slower and less reliable
|
||||
|
|
|
@ -341,7 +341,7 @@ Need more implementation yet....
|
|||
--------------------------------
|
||||
8. Memory hotplug event notifier
|
||||
--------------------------------
|
||||
Memory hotplug has event notifer. There are 6 types of notification.
|
||||
Memory hotplug has event notifier. There are 6 types of notification.
|
||||
|
||||
MEMORY_GOING_ONLINE
|
||||
Generated before new memory becomes available in order to be able to
|
||||
|
|
|
@ -649,7 +649,7 @@ solution for a couple of reasons:
|
|||
The CAN device must be configured via netlink interface. The supported
|
||||
netlink message types are defined and briefly described in
|
||||
"include/linux/can/netlink.h". CAN link support for the program "ip"
|
||||
of the IPROUTE2 utility suite is avaiable and it can be used as shown
|
||||
of the IPROUTE2 utility suite is available and it can be used as shown
|
||||
below:
|
||||
|
||||
- Setting CAN device properties:
|
||||
|
|
|
@ -34,6 +34,6 @@ registers interruption handlers read to find out where the machine
|
|||
was interrupted - so if you get an interruption between the instruction
|
||||
that clears the Q bit and the RFI that sets it again you don't know
|
||||
where exactly it happened. If you're lucky the IAOQ will point to the
|
||||
instrucion that cleared the Q bit, if you're not it points anywhere
|
||||
instruction that cleared the Q bit, if you're not it points anywhere
|
||||
at all. Usually Q bit problems will show themselves in unexplainable
|
||||
system hangs or running off the end of physical memory.
|
||||
|
|
|
@ -18,7 +18,7 @@ processing. Support for such hardware has not been very good in Linux,
|
|||
mostly because of a lack of a generic API available in the mainline
|
||||
kernel.
|
||||
|
||||
Rather than requiring a compability break with an API change of the
|
||||
Rather than requiring a compatibility break with an API change of the
|
||||
ALSA PCM interface, a new 'Compressed Data' API is introduced to
|
||||
provide a control and data-streaming interface for audio DSPs.
|
||||
|
||||
|
|
|
@ -235,7 +235,7 @@ label case adds:
|
|||
6 (mov) + 2 (test) + 2 (jne) = 10 - 5 (5 byte jump 0) = 5 addition bytes.
|
||||
|
||||
If we then include the padding bytes, the jump label code saves, 16 total bytes
|
||||
of instruction memory for this small fucntion. In this case the non-jump label
|
||||
of instruction memory for this small function. In this case the non-jump label
|
||||
function is 80 bytes long. Thus, we have have saved 20% of the instruction
|
||||
footprint. We can in fact improve this even further, since the 5-byte no-op
|
||||
really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp.
|
||||
|
|
Loading…
Reference in a new issue