Fix typos in Documentation/: 'B'-'C'
This patch fixes typos in various Documentation txts. This patch addresses some words starting with the letters 'B'-'C'. There are also a few grammar fixes thrown in for Randy. ;) Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>hifive-unleashed-5.1
Matt LaPlante
Adrian Bunk
parent
3f6dee9b2a
commit
6c28f2c0f2
|
|
@ -468,7 +468,7 @@ BMCs specified on the smb_addr line will be detected.
|
|||
Setting smb_dbg_probe to 1 will enable debugging of the probing and
|
||||
detection process for BMCs on the SMBusses.
|
||||
|
||||
Discovering the IPMI compilant BMC on the SMBus can cause devices
|
||||
Discovering the IPMI compliant BMC on the SMBus can cause devices
|
||||
on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
|
||||
message as a block write to the I2C bus and waits for a response.
|
||||
This action can be detrimental to some I2C devices. It is highly recommended
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ of the following three ways.
|
|||
i. For devices which have queue depth greater than 1 (TCQ devices) and
|
||||
support ordered tags, block layer can just issue the barrier as an
|
||||
ordered request and the lower level driver, controller and drive
|
||||
itself are responsible for making sure that the ordering contraint is
|
||||
itself are responsible for making sure that the ordering constraint is
|
||||
met. Most modern SCSI controllers/drives should support this.
|
||||
|
||||
NOTE: SCSI ordered tag isn't currently used due to limitation in the
|
||||
|
|
|
|||
|
|
@ -152,7 +152,7 @@ side during the SCSI error recovery process, the cciss driver only
|
|||
implements the first two of these actions, aborting the command, and
|
||||
resetting the device. Additionally, most tape drives will not oblige
|
||||
in aborting commands, and sometimes it appears they will not even
|
||||
obey a reset coommand, though in most circumstances they will. In
|
||||
obey a reset command, though in most circumstances they will. In
|
||||
the case that the command cannot be aborted and the device cannot be
|
||||
reset, the device will be set offline.
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ The driver supports two types of update mechanism; monolithic and packetized.
|
|||
These update mechanism depends upon the BIOS currently running on the system.
|
||||
Most of the Dell systems support a monolithic update where the BIOS image is
|
||||
copied to a single contiguous block of physical memory.
|
||||
In case of packet mechanism the single memory can be broken in smaller chuks
|
||||
In case of packet mechanism the single memory can be broken in smaller chunks
|
||||
of contiguous memory and the BIOS image is scattered in these packets.
|
||||
|
||||
By default the driver uses monolithic memory for the update type. This can be
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ Some very frequently asked questions about linuxtv-dvb
|
|||
|
||||
- v4l2-common: common functions for Video4Linux-2 drivers
|
||||
|
||||
- v4l1-compat: backward compatiblity layer for Video4Linux-1 legacy
|
||||
- v4l1-compat: backward compatibility layer for Video4Linux-1 legacy
|
||||
applications
|
||||
|
||||
- dvb-core: DVB core module. This provides you with the
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ if the patching step fails (i.e. there are rejected hunks), you can try to
|
|||
figure it out yourself (it shouldn't be hard), or mail the maintainer
|
||||
(Will Dyson <will_dyson@pobox.com>) for help.
|
||||
|
||||
step 2. Configuretion & make kernel
|
||||
step 2. Configuration & make kernel
|
||||
|
||||
The linux kernel has many compile-time options. Most of them are beyond the
|
||||
scope of this document. I suggest the Kernel-HOWTO document as a good general
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
|
||||
configfs - Userspace-driven kernel object configuation.
|
||||
configfs - Userspace-driven kernel object configuration.
|
||||
|
||||
Joel Becker <joel.becker@oracle.com>
|
||||
|
||||
|
|
|
|||
|
|
@ -522,7 +522,7 @@ controller memory. The time between data bytes must be less than 20ms.
|
|||
0x20 ; memory access
|
||||
{ data } ; 6 data bytes starting at ADR
|
||||
|
||||
This comand permits the host to read from the ikbd controller memory.
|
||||
This command permits the host to read from the ikbd controller memory.
|
||||
|
||||
9.26 CONTROLLER EXECUTE
|
||||
|
||||
|
|
|
|||
|
|
@ -93,7 +93,7 @@ Format description:
|
|||
Format specifier
|
||||
'8' : Generic 7 segment digit with individual addressable segments
|
||||
|
||||
Reduced capabillity 7 segm digit, when segments are hard wired together.
|
||||
Reduced capability 7 segm digit, when segments are hard wired together.
|
||||
'1' : 2 segments digit only able to produce a 1.
|
||||
'e' : Most significant day of the month digit,
|
||||
able to produce at least 1 2 3.
|
||||
|
|
|
|||
|
|
@ -222,7 +222,7 @@ rx_timeout=n - Rx DMA wait time for an interrupt.
|
|||
reach timeout of n * 640 nano seconds.
|
||||
Set proper rx_coalesce and rx_timeout can
|
||||
reduce congestion collapse and overload which
|
||||
has been a bottlenect for high speed network.
|
||||
has been a bottleneck for high speed network.
|
||||
|
||||
For example, rx_coalesce=10 rx_timeout=800.
|
||||
that is, hardware assert only 1 interrupt
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ the following process:
|
|||
|
||||
[setup] socket() -------> creation of the capture socket
|
||||
setsockopt() ---> allocation of the circular buffer (ring)
|
||||
mmap() ---------> maping of the allocated buffer to the
|
||||
mmap() ---------> mapping of the allocated buffer to the
|
||||
user process
|
||||
|
||||
[capture] poll() ---------> to wait for incoming packets
|
||||
|
|
@ -93,7 +93,7 @@ The destruction of the socket and all associated resources
|
|||
is done by a simple call to close(fd).
|
||||
|
||||
Next I will describe PACKET_MMAP settings and it's constraints,
|
||||
also the maping of the circular buffer in the user process and
|
||||
also the mapping of the circular buffer in the user process and
|
||||
the use of this buffer.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
|
@ -153,8 +153,8 @@ we will get the following buffer structure:
|
|||
|
||||
A frame can be of any size with the only condition it can fit in a block. A block
|
||||
can only hold an integer number of frames, or in other words, a frame cannot
|
||||
be spawn accross two blocks so there are some datails you have to take into
|
||||
account when choosing the frame_size. See "Maping and use of the circular
|
||||
be spawned accross two blocks, so there are some details you have to take into
|
||||
account when choosing the frame_size. See "Mapping and use of the circular
|
||||
buffer (ring)".
|
||||
|
||||
|
||||
|
|
@ -262,7 +262,7 @@ i386 architecture:
|
|||
<pagesize> = 4096 bytes
|
||||
<max-order> = 11
|
||||
|
||||
and a value for <frame size> of 2048 byteas. These parameters will yield
|
||||
and a value for <frame size> of 2048 bytes. These parameters will yield
|
||||
|
||||
<block number> = 131072/4 = 32768 blocks
|
||||
<block size> = 4096 << 11 = 8 MiB.
|
||||
|
|
@ -311,14 +311,14 @@ the following (from include/linux/if_packet.h):
|
|||
tp_frame_size must be a multiple of TPACKET_ALIGNMENT
|
||||
tp_frame_nr must be exactly frames_per_block*tp_block_nr
|
||||
|
||||
Note that tp_block_size should be choosed to be a power of two or there will
|
||||
Note that tp_block_size should be chosen to be a power of two or there will
|
||||
be a waste of memory.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
+ Maping and use of the circular buffer (ring)
|
||||
+ Mapping and use of the circular buffer (ring)
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
The maping of the buffer in the user process is done with the conventional
|
||||
The mapping of the buffer in the user process is done with the conventional
|
||||
mmap function. Even the circular buffer is compound of several physically
|
||||
discontiguous blocks of memory, they are contiguous to the user space, hence
|
||||
just one call to mmap is needed:
|
||||
|
|
|
|||
|
|
@ -732,12 +732,12 @@ address which can extend beyond that limit.
|
|||
that typically get driven by the same platform code in the
|
||||
kernel, you would use a different "model" property but put a
|
||||
value in "compatible". The kernel doesn't directly use that
|
||||
value (see /chosen/linux,platform for how the kernel choses a
|
||||
value (see /chosen/linux,platform for how the kernel chooses a
|
||||
platform type) but it is generally useful.
|
||||
|
||||
The root node is also generally where you add additional properties
|
||||
specific to your board like the serial number if any, that sort of
|
||||
thing. it is recommended that if you add any "custom" property whose
|
||||
thing. It is recommended that if you add any "custom" property whose
|
||||
name may clash with standard defined ones, you prefix them with your
|
||||
vendor name and a comma.
|
||||
|
||||
|
|
@ -817,7 +817,7 @@ address which can extend beyond that limit.
|
|||
your board. It's a list of addresses/sizes concatenated
|
||||
together, with the number of cells of each defined by the
|
||||
#address-cells and #size-cells of the root node. For example,
|
||||
with both of these properties beeing 2 like in the example given
|
||||
with both of these properties being 2 like in the example given
|
||||
earlier, a 970 based machine with 6Gb of RAM could typically
|
||||
have a "reg" property here that looks like:
|
||||
|
||||
|
|
@ -970,7 +970,7 @@ device-tree in another format. The currently supported formats are:
|
|||
- "asm": assembly language file. This is a file that can be
|
||||
sourced by gas to generate a device-tree "blob". That file can
|
||||
then simply be added to your Makefile. Additionally, the
|
||||
assembly file exports some symbols that can be use
|
||||
assembly file exports some symbols that can be used.
|
||||
|
||||
|
||||
The syntax of the dtc tool is
|
||||
|
|
@ -984,10 +984,10 @@ generated. Supported versions are 1,2,3 and 16. The default is
|
|||
currently version 3 but that may change in the future to version 16.
|
||||
|
||||
Additionally, dtc performs various sanity checks on the tree, like the
|
||||
uniqueness of linux,phandle properties, validity of strings, etc...
|
||||
uniqueness of linux, phandle properties, validity of strings, etc...
|
||||
|
||||
The format of the .dts "source" file is "C" like, supports C and C++
|
||||
style commments.
|
||||
style comments.
|
||||
|
||||
/ {
|
||||
}
|
||||
|
|
|
|||
|
|
@ -163,7 +163,7 @@ s/390 z/Architecture
|
|||
1 1 64 bit
|
||||
|
||||
32 1=31 bit addressing mode 0=24 bit addressing mode (for backward
|
||||
compatibility ), linux always runs with this bit set to 1
|
||||
compatibility), linux always runs with this bit set to 1
|
||||
|
||||
33-64 Instruction address.
|
||||
33-63 Reserved must be 0
|
||||
|
|
@ -239,7 +239,7 @@ they go to 64 Bit.
|
|||
|
||||
On 390 our limitations & strengths make us slightly different.
|
||||
For backward compatibility we are only allowed use 31 bits (2GB)
|
||||
of our 32 bit addresses,however, we use entirely separate address
|
||||
of our 32 bit addresses, however, we use entirely separate address
|
||||
spaces for the user & kernel.
|
||||
|
||||
This means we can support 2GB of non Extended RAM on s/390, & more
|
||||
|
|
@ -1311,7 +1311,7 @@ for finding out when a particular variable changes.
|
|||
|
||||
An alternative way of finding the STD of a currently running process
|
||||
is to do the following, ( this method is more complex but
|
||||
could be quite convient if you aren't updating the kernel much &
|
||||
could be quite convenient if you aren't updating the kernel much &
|
||||
so your kernel structures will stay constant for a reasonable period of
|
||||
time ).
|
||||
|
||||
|
|
@ -2045,13 +2045,13 @@ what gdb does when the victim receives certain signals.
|
|||
list:
|
||||
e.g.
|
||||
list lists current function source
|
||||
list 1,10 list first 10 lines of curret file.
|
||||
list 1,10 list first 10 lines of current file.
|
||||
list test.c:1,10
|
||||
|
||||
|
||||
directory:
|
||||
Adds directories to be searched for source if gdb cannot find the source.
|
||||
(note it is a bit sensititive about slashes )
|
||||
(note it is a bit sensititive about slashes)
|
||||
e.g. To add the root of the filesystem to the searchpath do
|
||||
directory //
|
||||
|
||||
|
|
@ -2123,9 +2123,9 @@ p/x (*(**$sp+56))&0x7fffffff
|
|||
|
||||
Disassembling instructions without debug info
|
||||
---------------------------------------------
|
||||
gdb typically compains if there is a lack of debugging
|
||||
symbols in the disassemble command with
|
||||
"No function contains specified address." to get around
|
||||
gdb typically complains if there is a lack of debugging
|
||||
symbols in the disassemble command with
|
||||
"No function contains specified address." To get around
|
||||
this do
|
||||
x/<number lines to disassemble>xi <address>
|
||||
e.g.
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ The following information is available in this file:
|
|||
|
||||
6.2.34 (May 5th, 2003)
|
||||
- Fix locking regression instroduced in 6.2.29 that
|
||||
could cuase a lock order reversal between the io_request_lock
|
||||
could cause a lock order reversal between the io_request_lock
|
||||
and our per-softc lock. This was only possible on RH9,
|
||||
SuSE, and kernel.org 2.4.X kernels.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@
|
|||
* Implemented suggestions from Alan Cox
|
||||
* Added calculation of resid for sg layer
|
||||
* Better error handling
|
||||
* Added checking underflow condtions
|
||||
* Added checking underflow conditions
|
||||
* Added DATAPROTECT checking
|
||||
* Changed error return codes
|
||||
* Fixed pointer bug in bus reset routine
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ With a miXart8AES/EBU there is in addition 1 stereo digital input
|
|||
Formats
|
||||
-------
|
||||
U8, S16_LE, S16_BE, S24_3LE, S24_3BE, FLOAT_LE, FLOAT_BE
|
||||
Sample rates : 8000 - 48000 Hz continously
|
||||
Sample rates : 8000 - 48000 Hz continuously
|
||||
|
||||
Playback
|
||||
--------
|
||||
|
|
|
|||
|
|
@ -1020,7 +1020,7 @@
|
|||
|
||||
Note that the IP address you assign to the host end of the tap device
|
||||
must be different than the IP you assign to the eth device inside UML.
|
||||
If you are short on IPs and don't want to comsume two per UML, then
|
||||
If you are short on IPs and don't want to consume two per UML, then
|
||||
you can reuse the host's eth IP address for the host ends of the tap
|
||||
devices. Internally, the UMLs must still get unique IPs for their eth
|
||||
devices. You can also give the UMLs non-routable IPs (192.168.x.x or
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ Param[0]
|
|||
Name CX2341X_DEC_GET_XFER_INFO
|
||||
Enum 9/0x09
|
||||
Description
|
||||
This API call may be used to detect an end of stream condtion.
|
||||
This API call may be used to detect an end of stream condition.
|
||||
Result[0]
|
||||
Stream type
|
||||
Result[1]
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ It's worth to note that SONiX has never collaborated with the author during the
|
|||
development of this project, despite several requests for enough detailed
|
||||
specifications of the register tables, compression engine and video data format
|
||||
of the above chips. Nevertheless, these informations are no longer necessary,
|
||||
becouse all the aspects related to these chips are known and have been
|
||||
because all the aspects related to these chips are known and have been
|
||||
described in detail in this documentation.
|
||||
|
||||
The driver relies on the Video4Linux2 and USB core modules. It has been
|
||||
|
|
|
|||
Loading…
Reference in New Issue