mirror of
https://github.com/adulau/aha.git
synced 2024-12-27 19:26:25 +00:00
misc doc and kconfig typos
Fix various typos in kernel docs and Kconfigs, 2.6.21-rc4. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
This commit is contained in:
parent
148e423f90
commit
a982ac06b0
29 changed files with 40 additions and 40 deletions
|
@ -480,8 +480,8 @@ The PCI stack provides 3 possible levels of MSI disabling:
|
|||
|
||||
6.1. Disabling MSI on a single device
|
||||
|
||||
Under some circumstances, it might be required to disable MSI on a
|
||||
single device, It may be achived by either not calling pci_enable_msi()
|
||||
Under some circumstances it might be required to disable MSI on a
|
||||
single device. This may be achieved by either not calling pci_enable_msi()
|
||||
or all, or setting the pci_dev->no_msi flag before (most of the time
|
||||
in a quirk).
|
||||
|
||||
|
@ -492,7 +492,7 @@ being able to route MSI between busses. In this case, MSI have to be
|
|||
disabled on all devices behind this bridge. It is achieves by setting
|
||||
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
|
||||
subordinate bus. There is no need to set the same flag on bridges that
|
||||
are below the broken brigde. When pci_enable_msi() is called to enable
|
||||
are below the broken bridge. When pci_enable_msi() is called to enable
|
||||
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
|
||||
flag in all parent busses of the device.
|
||||
|
||||
|
|
|
@ -6,10 +6,10 @@ Intro
|
|||
-----
|
||||
|
||||
With the introduction of cfq v3 (aka cfq-ts or time sliced cfq), basic io
|
||||
priorities is supported for reads on files. This enables users to io nice
|
||||
processes or process groups, similar to what has been possible to cpu
|
||||
scheduling for ages. This document mainly details the current possibilites
|
||||
with cfq, other io schedulers do not support io priorities so far.
|
||||
priorities are supported for reads on files. This enables users to io nice
|
||||
processes or process groups, similar to what has been possible with cpu
|
||||
scheduling for ages. This document mainly details the current possibilities
|
||||
with cfq; other io schedulers do not support io priorities thus far.
|
||||
|
||||
Scheduling classes
|
||||
------------------
|
||||
|
|
|
@ -17,7 +17,7 @@ Contents
|
|||
|
||||
1. Introduction
|
||||
|
||||
cpufreq-stats is a driver that provices CPU frequency statistics for each CPU.
|
||||
cpufreq-stats is a driver that provides CPU frequency statistics for each CPU.
|
||||
These statistics are provided in /sysfs as a bunch of read_only interfaces. This
|
||||
interface (when configured) will appear in a separate directory under cpufreq
|
||||
in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU.
|
||||
|
|
|
@ -16,7 +16,7 @@ host bridges to peripheral buses, and most controllers integrated
|
|||
into system-on-chip platforms. What they usually have in common
|
||||
is direct addressing from a CPU bus. Rarely, a platform_device will
|
||||
be connected through a segment of some other kind of bus; but its
|
||||
registers will still be directly addressible.
|
||||
registers will still be directly addressable.
|
||||
|
||||
Platform devices are given a name, used in driver binding, and a
|
||||
list of resources such as addresses and IRQs.
|
||||
|
|
|
@ -17,7 +17,7 @@ How to use it?
|
|||
==============
|
||||
|
||||
Imacfb does not have any kind of autodetection of your machine.
|
||||
You have to add the fillowing kernel parameters in your elilo.conf:
|
||||
You have to add the following kernel parameters in your elilo.conf:
|
||||
Macbook :
|
||||
video=imacfb:macbook
|
||||
MacMini :
|
||||
|
|
|
@ -290,7 +290,7 @@ History
|
|||
2.07 More fixes for Warp Server. Now it really works
|
||||
2.08 Creating new files is not so slow on large disks
|
||||
An attempt to sync deleted file does not generate filesystem error
|
||||
2.09 Fixed error on extremly fragmented files
|
||||
2.09 Fixed error on extremely fragmented files
|
||||
|
||||
|
||||
vim: set textwidth=80:
|
||||
|
|
|
@ -349,7 +349,7 @@ end of the line.
|
|||
Note the "Should sync?" parameter "nosync" means that the two mirrors are
|
||||
already in sync which will be the case on a clean shutdown of Windows. If the
|
||||
mirrors are not clean, you can specify the "sync" option instead of "nosync"
|
||||
and the Device-Mapper driver will then copy the entirey of the "Source Device"
|
||||
and the Device-Mapper driver will then copy the entirety of the "Source Device"
|
||||
to the "Target Device" or if you specified multipled target devices to all of
|
||||
them.
|
||||
|
||||
|
|
|
@ -351,7 +351,7 @@ If the current buffer is full, i.e. all sub-buffers remain unconsumed,
|
|||
the callback returns 0 to indicate that the buffer switch should not
|
||||
occur yet, i.e. until the consumer has had a chance to read the
|
||||
current set of ready sub-buffers. For the relay_buf_full() function
|
||||
to make sense, the consumer is reponsible for notifying the relay
|
||||
to make sense, the consumer is responsible for notifying the relay
|
||||
interface when sub-buffers have been consumed via
|
||||
relay_subbufs_consumed(). Any subsequent attempts to write into the
|
||||
buffer will again invoke the subbuf_start() callback with the same
|
||||
|
|
|
@ -19,7 +19,7 @@ completely. With execute-in-place, read&write type operations are performed
|
|||
directly from/to the memory backed storage device. For file mappings, the
|
||||
storage device itself is mapped directly into userspace.
|
||||
|
||||
This implementation was initialy written for shared memory segments between
|
||||
This implementation was initially written for shared memory segments between
|
||||
different virtual machines on s390 hardware to allow multiple machines to
|
||||
share the same binaries and libraries.
|
||||
|
||||
|
|
|
@ -126,5 +126,5 @@ GDB stub and the debugger:
|
|||
|
||||
Furthermore, the GDB stub will intercept a number of exceptions automatically
|
||||
if they are caused by kernel execution. It will also intercept BUG() macro
|
||||
invokation.
|
||||
invocation.
|
||||
|
||||
|
|
|
@ -179,7 +179,7 @@ reporting mode for joystick 1, with both buttons being logically assigned to
|
|||
the mouse. After any joystick command, the ikbd assumes that joysticks are
|
||||
connected to both Joystick0 and Joystick1. Any mouse command (except MOUSE
|
||||
DISABLE) then causes port 0 to again be scanned as if it were a mouse, and
|
||||
both buttons are logically connected to it. If a mouse diable command is
|
||||
both buttons are logically connected to it. If a mouse disable command is
|
||||
received while port 0 is presumed to be a mouse, the button is logically
|
||||
assigned to Joystick1 (until the mouse is reenabled by another mouse command).
|
||||
|
||||
|
|
|
@ -65,15 +65,15 @@ of buttons, see section 0.3 - Unknown Controllers
|
|||
I've tested this with Stepmania, and it works quite well.
|
||||
|
||||
|
||||
0.3 Unkown Controllers
|
||||
0.3 Unknown Controllers
|
||||
----------------------
|
||||
If you have an unkown xbox controller, it should work just fine with
|
||||
If you have an unknown xbox controller, it should work just fine with
|
||||
the default settings.
|
||||
|
||||
HOWEVER if you have an unknown dance pad not listed below, it will not
|
||||
work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
|
||||
|
||||
PLEASE if you have an unkown controller, email Dom <binary1230@yahoo.com> with
|
||||
PLEASE, if you have an unknown controller, email Dom <binary1230@yahoo.com> with
|
||||
a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
|
||||
whether it is a dance pad or normal controller) so that we can add your pad
|
||||
to the list of supported devices, ensuring that it will work out of the
|
||||
|
|
|
@ -160,7 +160,7 @@ on current cpu. This primitive is called by dev->poll(), when
|
|||
it completes its work. The device cannot be out of poll list at this
|
||||
call, if it is then clearly it is a BUG(). You'll know ;->
|
||||
|
||||
All these above nethods are used below. So keep reading for clarity.
|
||||
All of the above methods are used below, so keep reading for clarity.
|
||||
|
||||
Device driver changes to be made when porting NAPI
|
||||
==================================================
|
||||
|
|
|
@ -335,7 +335,7 @@ REVISION HISTORY
|
|||
creating applications using BiSync
|
||||
streaming.
|
||||
|
||||
2.0.5 Aug 04, 1999 CHDLC initializatin bug fix.
|
||||
2.0.5 Aug 04, 1999 CHDLC initialization bug fix.
|
||||
PPP interrupt driven driver:
|
||||
Fix to the PPP line hangup problem.
|
||||
New PPP firmware
|
||||
|
@ -372,7 +372,7 @@ REVISION HISTORY
|
|||
o cfgft1 GUI csu/dsu configurator
|
||||
o wancfg GUI configuration file
|
||||
configurator.
|
||||
o Architectual directory changes.
|
||||
o Architectural directory changes.
|
||||
|
||||
beta-2.1.4 Jul 2000 o Dynamic interface configuration:
|
||||
Network interfaces reflect the state
|
||||
|
|
|
@ -140,7 +140,7 @@ Plug and Play but it is planned to be in the near future.
|
|||
Requirements for a Linux PnP protocol:
|
||||
1.) the protocol must use EISA IDs
|
||||
2.) the protocol must inform the PnP Layer of a devices current configuration
|
||||
- the ability to set resources is optional but prefered.
|
||||
- the ability to set resources is optional but preferred.
|
||||
|
||||
The following are PnP protocol related functions:
|
||||
|
||||
|
|
|
@ -1633,7 +1633,7 @@ platforms are moved over to use the flattened-device-tree model.
|
|||
- assignment : function number of the pin according to the Pin Assignment
|
||||
tables in User Manual. Each pin can have up to 4 possible functions in
|
||||
QE and two options for CPM.
|
||||
- has_irq : indicates if the pin is used as source of exteral
|
||||
- has_irq : indicates if the pin is used as source of external
|
||||
interrupts.
|
||||
|
||||
Example:
|
||||
|
|
|
@ -40,7 +40,7 @@ The following information is available in this file:
|
|||
2. Multi-function Twin Channel Device - Two controllers on one chip.
|
||||
3. Command Channel Secondary DMA Engine - Allows scatter gather list
|
||||
and SCB prefetch.
|
||||
4. 64 Byte SCB Support - Allows disconnected, unttagged request table
|
||||
4. 64 Byte SCB Support - Allows disconnected, untagged request table
|
||||
for all possible target/lun combinations.
|
||||
5. Block Move Instruction Support - Doubles the speed of certain
|
||||
sequencer operations.
|
||||
|
|
|
@ -356,7 +356,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
|
|||
or enable Tagged Command Queueing (TCQ) on specific devices. As of
|
||||
driver version 5.1.11, TCQ is now either on or off by default
|
||||
according to the setting you choose during the make config process.
|
||||
In order to en/disable TCQ for certian devices at boot time, a user
|
||||
In order to en/disable TCQ for certain devices at boot time, a user
|
||||
may use this boot param. The driver will then parse this message out
|
||||
and en/disable the specific device entries that are present based upon
|
||||
the value given. The param line is parsed in the following manner:
|
||||
|
|
|
@ -1260,7 +1260,7 @@ then the request of the IRQ obviously will not succeed for all the drivers.
|
|||
15.1 Problem tracking
|
||||
|
||||
Most SCSI problems are due to a non conformant SCSI bus or to buggy
|
||||
devices. If infortunately you have SCSI problems, you can check the
|
||||
devices. If unfortunately you have SCSI problems, you can check the
|
||||
following things:
|
||||
|
||||
- SCSI bus cables
|
||||
|
|
|
@ -587,7 +587,7 @@ devices, ... may cause a SCSI signal to be wrong when te driver reads it.
|
|||
15.1 Problem tracking
|
||||
|
||||
Most SCSI problems are due to a non conformant SCSI bus or too buggy
|
||||
devices. If infortunately you have SCSI problems, you can check the
|
||||
devices. If unfortunately you have SCSI problems, you can check the
|
||||
following things:
|
||||
|
||||
- SCSI bus cables
|
||||
|
|
|
@ -221,7 +221,7 @@ Controls the kernel's behaviour when an oops or BUG is encountered.
|
|||
|
||||
0: try to continue operation
|
||||
|
||||
1: panic immediatly. If the `panic' sysctl is also non-zero then the
|
||||
1: panic immediately. If the `panic' sysctl is also non-zero then the
|
||||
machine will be rebooted.
|
||||
|
||||
==============================================================
|
||||
|
|
|
@ -107,7 +107,7 @@ config ARCH_AT91SAM9260_SAM9XE
|
|||
depends on ARCH_AT91SAM9260
|
||||
help
|
||||
Select this if you are using Atmel's AT91SAM9XE System-on-Chip.
|
||||
They are basicaly AT91SAM9260s with various sizes of embedded Flash.
|
||||
They are basically AT91SAM9260s with various sizes of embedded Flash.
|
||||
|
||||
comment "AT91SAM9260 / AT91SAM9XE Board Type"
|
||||
|
||||
|
|
|
@ -84,7 +84,7 @@ config MACH_OMAP_PALMTE
|
|||
Support for the Palm Tungsten E PDA. Currently only the LCD panel
|
||||
is supported. To boot the kernel, you'll need a PalmOS compatible
|
||||
bootloader; check out http://palmtelinux.sourceforge.net for more
|
||||
informations.
|
||||
information.
|
||||
Say Y here if you have such a PDA, say NO otherwise.
|
||||
|
||||
config MACH_NOKIA770
|
||||
|
|
|
@ -17,7 +17,7 @@ config CAPI_TRACE
|
|||
help
|
||||
If you say Y here, the kernelcapi driver can make verbose traces
|
||||
of CAPI messages. This feature can be enabled/disabled via IOCTL for
|
||||
every controler (default disabled).
|
||||
every controller (default disabled).
|
||||
This will increase the size of the kernelcapi module by 20 KB.
|
||||
If unsure, say Y.
|
||||
|
||||
|
|
|
@ -54,9 +54,9 @@ fps
|
|||
Specifies the desired framerate. Is an integer in the range of 4-30.
|
||||
|
||||
fbufs
|
||||
This paramter specifies the number of internal buffers to use for storing
|
||||
This parameter specifies the number of internal buffers to use for storing
|
||||
frames from the cam. This will help if the process that reads images from
|
||||
the cam is a bit slow or momentarely busy. However, on slow machines it
|
||||
the cam is a bit slow or momentarily busy. However, on slow machines it
|
||||
only introduces lag, so choose carefully. The default is 3, which is
|
||||
reasonable. You can set it between 2 and 5.
|
||||
|
||||
|
@ -209,7 +209,7 @@ trace
|
|||
|
||||
128 0x80 PWCX debugging Off
|
||||
|
||||
For example, to trace the open() & read() fuctions, sum 8 + 4 = 12,
|
||||
For example, to trace the open() & read() functions, sum 8 + 4 = 12,
|
||||
so you would supply trace=12 during insmod or modprobe. If
|
||||
you want to turn the initialization and probing tracing off, set trace=0.
|
||||
The default value for trace is 35 (0x23).
|
||||
|
|
|
@ -571,7 +571,7 @@ mpi_fc.h
|
|||
* 11-02-00 01.01.01 Original release for post 1.0 work
|
||||
* 12-04-00 01.01.02 Added messages for Common Transport Send and
|
||||
* Primitive Send.
|
||||
* 01-09-01 01.01.03 Modifed some of the new flags to have an MPI prefix
|
||||
* 01-09-01 01.01.03 Modified some of the new flags to have an MPI prefix
|
||||
* and modified the FcPrimitiveSend flags.
|
||||
* 01-25-01 01.01.04 Move InitiatorIndex in LinkServiceRsp reply to a larger
|
||||
* field.
|
||||
|
|
|
@ -60,7 +60,7 @@ config MTD_PHYSMAP_BANKWIDTH
|
|||
(i.e., run-time calling physmap_configure()).
|
||||
|
||||
config MTD_PHYSMAP_OF
|
||||
tristate "Flash device in physical memory map based on OF descirption"
|
||||
tristate "Flash device in physical memory map based on OF description"
|
||||
depends on PPC_OF && (MTD_CFI || MTD_JEDECPROBE || MTD_ROM)
|
||||
help
|
||||
This provides a 'mapping' driver which allows the NOR Flash and
|
||||
|
|
|
@ -146,7 +146,7 @@ config SND_VERBOSE_PROCFS
|
|||
default y
|
||||
help
|
||||
Say Y here to include code for verbose procfs contents (provides
|
||||
usefull information to developers when a problem occurs). On the
|
||||
useful information to developers when a problem occurs). On the
|
||||
other side, it makes the ALSA subsystem larger.
|
||||
|
||||
config SND_VERBOSE_PRINTK
|
||||
|
|
Loading…
Reference in a new issue